البنية الأساسية كتعليمات برمجية
- 11 دقائق
قبل السحابة، عندما احتاجت المنظمة إلى بناء بنيتها الأساسية الحاسوبية، قامت بنشر خوادم فعلية جديدة وإضافتها إلى الشبكة خلف موازن التحميل وجدار الحماية. عندما كان على مدير العمليات «Operations Manager» تقدير النفقات الرأسمالية المطلوبة لدعم السعة المضافة، تم تقديم هذه التقديرات من حيث الخوادم بأكملها. تم إجراء "التصميم" بواسطة الآلة الحاسبة. كانت إحدى النصائح المتعلقة بتخطيط السعة في ذلك الوقت هي إضافة "حد"، أو المبالغة في تقديره، بنسبة 20 في المئة في حال كانت التقديرات الأولية منخفضة للغاية.
غيرت السحابة ذلك من خلال تقديم البنية الأساسية للحوسبة كخدمة. أصبحت إضافة السعة فجأة بسهولة النقر على الأزرار في المدخل، أو كتابة الأوامر في وحدة التحكم، أو تشغيل البرامج النصية. وقد خلقت هذه السهولة مجموعة جديدة من التحديات. بالنظر إلى حل كامل يتكون من العشرات أو حتى المئات من الخدمات السحابية يمكن نشرها في دقائق بواسطة شخص واحد، كيف يمكنك التأكد من نشر الحلول بشكل صحيح، وتهيئة الموارد الفردية بشكل صحيح، وعدم ارتكاب المشغل لخطأ؟ كيف يمكنك تعديل الحل بشكل موثوق بعد نشره مع تقليل احتمالية حدوث خطأ بشري؟ تعتبر البرمجة النصية أحد الحلول، ولكن كما تعلمنا في الدرس السابق، فإنها تحل بعض المشكلات في أثناء تقديم أخرى.
الخطوة التالية في رحلة أتمتة العمليات المستخدمة لإدارة البنية الأساسية السحابية هي Infrastructure-as-code، أو IaC. تتمثل فكرة IaC في التحديد الصريح للحل الذي يتم نشره على السحابة بطريقة حيوية، مثل البرنامج. قم بتشغيل البرنامج وتقوم بإنشاء حل؛ تغيير البرنامج وتغيير الحل. يوفر IaC آلية لتحديد شكل الحل. يحتوي على العديد من عناصر البرنامج دون الاعتماد بالضرورة على لغة البرمجة: إعلان الأصول (المتغيرات)، والوظائف والإجراءات القابلة لإعادة الاستخدام، وتعويض الأخطاء واستردادها، والأهم من ذلك كله، الدعم الرسمي للاختبار وتصحيح الأخطاء (الشكل 3).
الشكل 3: أوجه التشابه بين البنية التحتية كخدمة والبرمجيات.
تعتمد IaC على ملفات التكوين التي تشبه التعليمة البرمجية المصدرية لبرامج التطبيقات. قد لا يبدو ملف تكوين IaC مثل التعليمة البرمجية المصدرية، وربما لم تتم كتابته بلغة Python أو أي لغة برمجة تقليدية أخرى. ومع ذلك، فإن جميع المكونات الرئيسية التي سيبحث عنها مطور البرامج موجودة، فقط بصيغة مختلفة. قد يفتقر ملف التكوين إلى أوامر أو إجراءات خطوة بخطوة يمتلكها برنامج Python أو برنامج PowerShell النصي، ولكنه يحدد كلاً من النتيجة والعملية لتحقيق هذه النتيجة بنفس الطريقة.
هذه الاستراتيجية هي مفهوم البنية التحتية كخدمة. تجعل ديناميكيات السحابة موارد الحل سلسة وغير مقيدة بحدود الأجهزة التي تدعمها. لا ينبغي أن يكون النظام الذي يشرف على إدارتها مقيدًا بهذه الحدود أيضًا، حيث يتعامل مع مركز البيانات بأكمله، في أماكن العمل وخارجها، كما لو كان جهازًا واحدًا قابلاً للبرمجة والتكوين.
مقدمة إدارة التكوين
تستفيد العديد من الصناعات إلى جانب تكنولوجيا المعلومات من إدارة التكوين (CM)، لا سيما في التصنيع والإنتاج. في إنتاج السيارات، يشير CM إلى الأساليب والعمليات المستخدمة لتصنيع منتج يلبي معايير محددة أو متطلبات العملاء. في تصنيع المعدات الصناعية، التي تنتج الأجزاء المستخدمة في بناء الآلات، توجد أنظمة ترقيم الأجزاء وأنظمة إدارة الإصدار وأنظمة إدارة التغيير وأنظمة محاسبة الحالة، والتي يجب تنسيقها جميعًا لإنتاج نتيجة قابلة للتكرار.
لا تختلف أتمتة إدارة التكوين في تكنولوجيا المعلومات. أنه ينطوي على إدارة الأنظمة في الدول الانتقالية. وتنطوي على تنسيق أنظمة فرعية مختلفة حتى تعمل معًا. الأسئلة الفلسفية هي مشكلة حالية لمسؤولي تكنولوجيا المعلومات: هل يجب على النظام الحفاظ على العمليات التي يتم من خلالها توفير البنية الأساسية المستندة إلى السحابة وتجميعها والحفاظ عليها؟ أم ينبغي بدلاً من ذلك تحديد مكونات البنية الأساسية اللازمة لتلبية متطلبات العميل أو المستخدم، ومعرفة كيفية تلبية هذه المتطلبات بناءً على الوضع الحالي للبنية التحتية؟ هناك أنظمة CM قيد الاستخدام اليوم، والتي تتبع طريقة أو أخرى.
في عام 1993، بينما كانت فكرة المحاكاة الافتراضية في مركز البيانات لا تزال في بدايتها، أنتج باحث في نظرية المجال الحصي بجامعة أوسلو يدعى مارك بورغيس في وقت فراغه، وبين المشاريع الممولة من الحكومة في نظرية المجال الحراري1، ما يُعتقد أنه أول أداة حديثة لإدارة التكوين. أطلق عليها اسم CFEngine، وبدأت كلغة خاصة بالمجال نفذت اختبارات شرطية بناءً على معايير من تكوين الكمبيوتر. تم استخدام هذه الاختبارات لتحديد التعليمات التي يجب تنفيذها للوصول بالنظام إلى حالة التكوين المطلوبة.
مع تطورها، أصبحت معايير هذه الاختبارات الشرطية تتم صياغتها مثل الإعلانات والعبارات التي تصف ما يجب أن تكون عليه الحالة المرغوب فيها للنظام. حتى ذلك الحين، تم وصف تكوين النظام على أنه حالة أولية لنظام يخضع لسلسلة من التحولات. يمكن استخدام نفس الشيء لوصف نص إداري نموذجي: قائمة بكل ما يحتاج مترجم CLI القيام به لتعديل حالة النظام الحالي، أو لبناء شيء ما في حالة تبدأ بلا شيء.
بعد سبع سنوات، في كتابه المهم عن إدارة الشبكة والنظام 2، عرّف بورغيس بشكل فعال استخدام مصطلح "البنية التحتية" للإشارة إلى الموارد التي تشكل بشكل جماعي وتدعم مركز البيانات. هناك، طرح أيضًا متطلباته الخمسة لأي بنية أساسية لأي مركز بيانات تعتبر مستقرة: قابلية التوسع، والموثوقية، والتكرار، والتجانس، والتكاثر.
اعتقد بورغيس أنه من الممكن تلبية هذه المتطلبات من خلال نظام إدارة التكوين الذي يبدأ مطور لغته بالحالة النهائية المرغوب فيها، والسماح للنظام بتوجيه التطوير إلى الوراء نحو الحالة الحالية. في مقال نُشر على موقعه الشخصي على الويب3، يصف بورغيس الاتجاه الذي تميل فيه البرمجة النصية التقليدية إلى التطابق، والذي شبهه بتعليمات تقود شخصًا عبر خطوات كيفية بناء شيء ما دون وصف ذلك الشيء. الاتجاه الذي يفضله هو التقارب، والذي يقارنه باستخدام خريطة توضح الوجهة وتخطيط طريق يؤدي إلى ما أنت عليه الآن.
إدارة تكوين الجيل التالي
في عام 2006، أطلق مطور البرامج مفتوح المصدر لوك كاني بموجب الرخصة العامة (GPL) أداة أطلق عليها Puppet. وصفها بأنها "إدارة تكوين الجيل التالي 4"، وقدمها لزملائه من المتخصصين في تكنولوجيا المعلومات على أنها "طبقة تجريدية لنظام التشغيل". لم تشتهر هذه العبارة، ولكن الفكرة اشتهرت. كانت فرضيته هي أن لغة نظام إدارة التكوين يجب أن تعلن عن المكونات المطلوبة لنوع من الموارد مثل الأجهزة الظاهرية. يمكن للنظام بعد ذلك أن يكون مسؤولاً عن اتخاذ أي خطوات ضرورية لتلبية تلك المتطلبات، أو شيء قريب منها، حتى عندما يكون من المحتمل أن يتغير تسلسل تلك الخطوات. مزيد من التفاصيل حول لغة الدمى وكيفية عمل النظام مقدمة في الدرس التالي.
باستخدام Puppet، يمكن للمشغل تحديد فئة الخدمة، والتي تتكون من حزم التطبيقات والموارد الأخرى المطلوبة لتقديم شيء ما للمستخدمين. تصبح وظيفة نظام إدارة التكوين توفير الموارد المناسبة اللازمة لتقديم تلك الخدمة، حيث تم تصنيفها ضمن Puppet. قد يتضمن ذلك توفير أجهزة افتراضية أو باستخدام أنظمة حاويات أكثر حداثة، إنشاء مثيل للحاويات والموارد التي تدعمها.
DevOps - المطوّرون والمشغلون
في اللحظة نفسها تقريباً التي تبدأ فيها المؤسسة في التفكير بشأن استخدام البنية التحتية كتعليمة برمجية، تبدأ في مناقشة ما إذا كان ينبغي أن تتحد إدارتان منفصلتان تاريخياً --- إدارة تكنولوجيا المعلومات وتطوير البرامج ---. نشأت حركة DevOps من فكرة أنه لا يمكن تنفيذ أي خطة على هذا المستوى من العمل من قبل فريقين منفصلين تنظيميًا.
يُعزى مصطلح "DevOps" إلى الإلهام من مؤتمر صناعة الكمبيوتر لعام 2009، حيث كان اثنان من المتحدثين هما جون أولسباو، رئيس العمليات الفنية في ذلك الوقت، وبول هاموند، رئيس الفريق الهندسي، في خدمة مشاركة الصور Flickr. قدمت جلستهما المشتركة هذه الفكرة، والتي كانت في ذلك الوقت جذرية: إذا كان من الممكن جعل البنية الأساسية لمركز البيانات قابلة للتكيف والاستجابة للاحتياجات المتغيرة لأحمال العمل، يمكن عندئذٍ دعم التطبيقات والخدمات بدورات إصدار أقصر بكثير، ومعدلات أسرع بكثير من النشر والتحسين المستمر.
تم ضم IaC، والتكامل المستمر والنشر المستمر (CI/CD)، وإعادة تنظيم الفرق حول المشاريع والأهداف بدلاً من المديرين والمخططات التنظيمية، كجزء من نفس الاتجاه التطوري. يؤدي هذا الاتجاه إلى تغييرات تنظيمية في الأعمال يمكن للأشخاص خارج قسم تكنولوجيا المعلومات التعرف عليها وتقديرها:
تأثير DevOps
- يجري تطوير البرمجيات بشكل أسرع
- يتم التعامل مع الاختبار بشكل أكثر جدية وصرامة.
- تُدمج أدوات إدارة البنية التحتية مع خوادم الأتمتة
- تُستخدم أساليب إدارة فِرق البرامج لفِرق تكنولوجيا المعلومات
يجري تطوير البرمجيات بشكل أسرع
أو بالنسبة لتلك المنظمات التي لم تُطوِّر تطبيقاتها أو خدماتها الخاصة مُطلقاً، يتم تطوير البرامج بداية من النقطة حيث لم يتم تطويرها من قبل. تم تمديد دورات إصدار البرامج لأشهر، وحتى سنوات، حتى وقت التسليم المحدد في خط سير الرحلة الذي كان مناسبًا للمؤسسة بأكملها. كان أحد أسباب مثل هذه الامتدادات هو السماح بنوافذ الفرصة لترقية الأجهزة أو استبدالها، أو إنشاء مراكز بيانات جديدة تمامًا، قبل إصدار البرنامج الذي قد يتأثر بخلاف ذلك بتحويل البنية الأساسية في منتصف الدورة. مع تمكين الأنظمة الأساسية السحابية المشغلين الآن من إجراء المزيد من التغييرات المتزايدة على بنيتهم الأساسية بشكل متكرر، لم يعد هناك سبب لتأخير دورات إصدار البرامج.
يتم التعامل مع الاختبار بشكل أكثر جدية وصرامة
في بيئة مركز البيانات التي اعتمدت CI/CD، يتم اختبار البرنامج في مرحلة منفصلة واحدة على الأقل، ربما تكون مرحلتين، قبل طرحه للإنتاج. قد لا يكون من العملي إنشاء مراحل تطوير ومرحلة مماثلة للبنية الأساسية السحابية، ولكن أدوات IaC تسمح بتخطيط "التشغيل الاختباري"، حيث يمكن للمسؤولين مراقبة تأثيرات التغييرات المطبقة على الحلول السحابية والتنبؤ بها قبل الالتزام بها.
تُدمج أدوات إدارة البنية التحتية مع خوادم الأتمتة
تُستخدم خوادم الأتمتة مثل Jenkins لتقديم تغييرات في البنية التحتية. نتيجةً لذلك، تتم مزامنة نفس خط سير الرحلة "المخطَّط" المستخدم لتخطيط دورات الإصدار للتطبيقات والخدمات مع خطط البنية الأساسية أو التعليمات (Chef) أو أدلة المبادئ (Ansible)، ومن ثم فإن حالة البنية الأساسية دائمًا ما تكون متوافقة مع أحمال العمل التي تدعمها.
تُستخدم أساليب إدارة فِرق البرامج لفِرق تكنولوجيا المعلومات
تمتد منهجيات Agile لتشمل فِرق العمليات. في إطار عمل Agile، يحدد الفريق الأصغر مع قائد المشروع أهدافًا أبسط يمكن تحقيقها في فترات زمنية أقصر، ما يؤدي إلى تحقيق هذه الأهداف بشكل أكثر منهجية. قد تنسق فرق متعددة مع بعضها، ومن ثم قد تقيس بشكل أكثر دقة تقدمهم. قد يكون فريق عمليات Agile، أو فريق مشابه له أكثر توافقًا مع فريق البرمجيات في ضمان توفر موارد البنية الأساسية ويمكن الاعتماد عليها.
يكون IaC مجرد مفهوم مجرد دون وجود أدوات لتنفيذه. يقدم الدرس التالي بعضًا من أدوات إدارة التكوين المعتمدة على نطاق واسع، والتي تتبنى جميعها مفهوم البنية التحتية كخدمة بدرجات متفاوتة.
المراجع
صفحة الويب الشخصية لمارك بورغيس. http://markburgess.org/bio.html.
وايلي للنشر. مبادئ إدارة الشبكة والنظام. https://www.wiley.com/Principles+of+Network+and+System+Administration%2C+2nd+Edition-p-9780470868072.
مدوّنة مارك بورغيس. http://markburgess.org/blog_cd.html.
usenix. Puppet: إدارة تكوين الجيل التالي. https://www.usenix.org/publications/login/february-2006-volume-31-number-1/puppet-next-generation-configuration-management.
اختبر معلوماتك
الملاحظات
هل كانت هذه الصفحة مفيدة؟
لا
هل تحتاج إلى مساعدة مع هذا الموضوع؟
هل تريد محاولة استخدام Ask Learn لتوضيح هذا الموضوع أو إرشادك خلاله؟