مقدمة

لمعظم تاريخ الحوسبة السحابية المبكر، كان تخصيص البنية التحتية يعني مزيجًا من النقر يدويًا عبر لوحة تحكم ويب لمزود سحابي وتشغيل نصوص شل مخصصة تُؤتمت أجزاء من تلك العملية، نهج عمل بشكل مقبول لحفنة من الخوادم يديرها مهندس واحد لكنه توسع بشكل رديء مع نمو تعقيد البنية التحتية. لم تترك التغييرات اليدوية عبر لوحة التحكم أثرًا تدقيقيًا يشرح لماذا هُيِّئ إعداد معين بطريقة معينة، ولم يكن بالإمكان مراجعتها بمعنى ذي دلالة قبل تطبيقها، وكانت سيئة السمعة في صعوبة إعادة إنتاجها بشكل متطابق عبر بيئات التطوير والاختبار والإنتاج.

تعالج البنية التحتية ككود هذا بمعاملة تعريفات البنية التحتية بنفس الطريقة التي يعامل بها مهندسو البرمجيات كود التطبيق: مكتوبة في ملف مُتحكَّم بإصداره، مُراجَعة عبر نفس عملية طلب السحب كأي تغيير آخر، ومُطبَّقة عبر عملية آلية وقابلة للتكرار بدلاً من إجراء يدوي. يفحص هذا المقال النموذج التصريحي الذي يميز أدوات IaC الحديثة عن نُهج البرمجة النصية الحتمية السابقة، ومشكلة إدارة الحالة التي تقع في جوهر كيفية عمل هذه الأدوات فعليًا، والانضباط التشغيلي الحقيقي المطلوب لتشغيل البنية التحتية ككود بأمان بمجرد أن يتجاوز الفريق حفنة من الموارد البسيطة، إلى جانب نظرة صادقة على انحراف التهيئة، نمط الفشل الشائع باستمرار حيث ينحرف الواقع بصمت عما يعتقد الكود أنه صحيح.

التصريحي مقابل الحتمي في إدارة البنية التحتية

كانت أدوات أتمتة البنية التحتية المبكرة حتمية إلى حد كبير: يحدد نص برمجي صراحة تسلسل الخطوات اللازمة للوصول لحالة مرغوبة - أنشئ هذا الخادم، ثم أرفق هذا القرص، ثم هيّئ قاعدة الشبكة هذه - واضعًا العبء على مؤلف النص للتعامل بشكل صحيح مع كل حالة بداية ممكنة. تتخذ أدوات IaC الحديثة، التي يُجسّدها Terraform وبشكل متزايد Pulumi، نهجًا تصريحيًا مختلفًا جوهريًا: يصف المهندس الحالة النهائية المرغوبة للبنية التحتية، وتحسب الأداة نفسها التسلسل المحدد من استدعاءات API اللازمة لنقل البنية التحتية الفعلية من حالتها الحالية لتلك الحالة المرغوبة.

يحاكي هذا النموذج التصريحي عن كثب نمط حلقة التوفيق الذي أثبت متانته الكبيرة في Kubernetes: بدلاً من تتبع مهندس يدويًا لما تم تخصيصه بالفعل وكتابة منطق شرطي للتعامل مع كل حالة بداية ممكنة، تُجري الأداة نفسها مقارنة فرق بين التهيئة المُعلَنة والبنية التحتية الفعلية، وتُولِّد خطة تنفيذ تصف بالضبط ما سيتغير. يمكن مراجعة هذه الخطة من قبل بشري قبل تطبيقها، مانحة المهندسين معاينة حقيقية لنطاق تأثير تغيير قبل أن يلمس ذلك التغيير الإنتاج على الإطلاق.

ملف الحالة: التعقيد المركزي لـIaC

لحساب فرق دقيق بين البنية التحتية المرغوبة والفعلية، تحتاج أداة IaC تصريحية لسجل بما أنشأته سابقًا وكيف تُطابق تلك الموارد مدخلات في التهيئة - هذا السجل هو ملف الحالة، وإدارته بشكل صحيح هو على الأرجح الانضباط التشغيلي الأكثر أهمية منفردًا في تشغيل البنية التحتية ككود على أي نطاق ذي معنى. ملف حالة Terraform، مثلاً، وثيقة JSON تتتبع كل مورد تديره الأداة، بما في ذلك بيانات حساسة محتملة مثل كلمات مرور قواعد البيانات مُضمَّنة في سمات الموارد.

فساد أو فقدان ملف الحالة أحد أنماط الفشل الأكثر أهمية في عمليات IaC، إذ أن أداة فقدت تتبع ما أنشأته سابقًا لم يعد بإمكانها حساب خطة دقيقة، مما قد يؤدي بها لمحاولة إعادة إنشاء موارد موجودة بالفعل أو، أسوأ، لاستنتاج أن بنية تحتية قائمة يجب تدميرها لأنها لم تعد تظهر في سجلات الأداة. تعالج الفرق الناضجة هذا عبر تخزين حالة بعيد ومُتحكَّم بإصداره - عادة حاوية تخزين كائنات بإصدار وتشفير مُفعَّلين - مقترنة بقفل الحالة لمنع مهندسين اثنين من تطبيق تغييرات متضاربة على نفس البنية التحتية في آن واحد.

Terraform مقابل Pulumi: لغة التهيئة كقرار تصميمي

كانت لغة تهيئة HashiCorp الخاصة بـTerraform، المبنية خصيصًا لوصف البنية التحتية تصريحيًا، الخيار السائد في مجال IaC لسنوات، مقدمة صياغة مُحسَّنة خصيصًا للتعبير عن علاقات الموارد وتبعياتها بوضوح، إلى جانب نظام بيئي واسع من إضافات مزودين مُصانة مجتمعيًا تغطي تقريبًا كل خدمة سحابية رئيسية. طبيعتها المبنية لغرض محدد هي أيضًا قيدها الأساسي: HCL ليست لغة برمجة عامة الغرض.

يتخذ Pulumi نهجًا مختلفًا، مُتيحًا للمهندسين تعريف البنية التحتية باستخدام لغات برمجة عامة الغرض حقيقية - Python وTypeScript وGo وC# - بدلاً من لغة تهيئة خاصة بمجال، مما يسمح للفرق بتطبيق التعبيرية الكاملة للغة برمجة حقيقية، إلى جانب أطر اختبارها القائمة وأدوات IDE، مباشرة على تعريفات البنية التحتية. هذه المفاضلة ذات حدين حقًا: نفس التعبيرية التي تجعل المنطق المعقد أسهل كتابة في Pulumi تجعل أيضًا كتابة كود بنية تحتية معقد بلا داعٍ أسهل.

التجزئة إلى وحدات وخطر الكتلة الأحادية للبنية التحتية

مع نمو بنية تحتية مؤسسة، تصبح تهيئة Terraform أو Pulumi واحدة وغير متمايزة تغطي البصمة السحابية بأكملها محفوفة بالمخاطر تشغيليًا وغير عملية تنظيميًا، عاكسة بدقة نفس عنق زجاجة التنسيق الذي حفّز التحول من التطبيقات الأحادية للخدمات المصغرة. تغيير بنية تحتية واحد يقترحه فريق واحد يتطلب التخطيط مقابل، وربما الانتظار خلف، كل تغيير بنية تحتية معلق لكل فريق آخر إذا شاركوا جميعًا تهيئة واحدة وملف حالة واحد.

تعالج ممارسات IaC الناضجة هذا عبر تجزئة متعمدة لوحدات: تقسيم البنية التحتية لتهيئات منفصلة منطقيًا - غالبًا مُنظَّمة حسب البيئة أو الفريق أو حدود التطبيق - لكل منها ملف حالة مُدار بشكل مستقل، مقترنة بوحدات قابلة لإعادة الاستخدام تُغلِّف أنماط بنية تحتية شائعة، مثل تهيئة قياسية ومُحصَّنة أمنيًا لقاعدة بيانات، يمكن استهلاكها باتساق عبر تهيئات منفصلة عديدة دون حاجة كل فريق لإعادة اكتشاف أفضل ممارسات الأمان والموثوقية للمؤسسة من الصفر في كل مرة.

دراسة حالة: دروس هجرة HashiCorp الخاصة

نشرت HashiCorp، مُبتكرة Terraform نفسها، بشكل مكثف حول الدروس التشغيلية التي تعلمتها فرقها الداخلية الخاصة أثناء توسيع استخدام Terraform عبر بصمة بنية تحتية كبيرة ومتنامية بسرعة، وأحد أكثر الدروس تكرارًا باستمرار هو أن حدود ملف الحالة يجب أن تُرسَم حول حدود نطاق تأثير وملكية حقيقية بدلاً من الراحة، إذ أن ملف حالة يمتد عبر بيئة تطوير منخفضة المخاطر لفريق وبيئة إنتاج عالية المخاطر يعني أن خطأ في تغيير تطوير روتيني يحمل نفس الإمكانية الكارثية لخطأ في تغيير إنتاجي.

أصبح هذا الدرس قريبًا من ممارسة معيارية عبر مجتمع IaC الأوسع: فصل ملفات الحالة لكل بيئة كحد أدنى، وغالبًا فصل أبعد حسب الفريق أو حدود التطبيق ضمن بيئة واحدة، مقبولين العبء التشغيلي الإضافي المتواضع لإدارة ملفات حالة أكثر مقابل نطاق تأثير أصغر ومفهوم بشكل أفضل ذا معنى لأي تغيير واحد.

انحراف التهيئة: خطر التغييرات اليدوية الصامتة

انحراف التهيئة - حالة لم تعد فيها البنية التحتية الفعلية تُطابق ما تعتقد أدوات IaC أنها تديره، عادة لأن شخصًا أجرى تغييرًا يدويًا مباشرة عبر لوحة تحكم سحابية بدلاً من خط أنابيب IaC - من أكثر المشكلات التشغيلية شيوعًا وإحباطًا باستمرار التي تواجهها الفرق مع توسع تبني IaC. مهندس حسن النية يُعدّل قاعدة جدار حماية يدويًا أثناء حادثة عاجلة، مُخططًا لتحديث تهيئة Terraform لاحقًا "لاحقًا"، قصة أصل شائعة للغاية للانحراف.

تعالج المؤسسات الناجحة في إدارة الانحراف هذا عادة بالجمع بين سياسة تنظيمية صارمة - لا تغييرات لوحة تحكم يدوية على موارد مُدارة بـIaC إلا في حالة طوارئ مُعلَنة - مع أدوات كشف انحراف آلية تقارن دوريًا البنية التحتية الفعلية مقابل الحالة المُعلَنة وتُنبِّه عند اكتشاف انحراف.

الخاتمة

جلبت البنية التحتية ككود انضباطات هندسة البرمجيات الأساسية - التحكم بالإصدار، مراجعة الكود، التنفيذ الآلي القابل للتكرار - لمجال اعتمد لسنوات على العمل اليدوي والذاكرة المؤسسية التي عاشت في رؤوس مهندسين أفراد بدلاً من أي قطعة أثرية دائمة وقابلة للمراجعة. نموذجها التصريحي، الذي يحسب المسار من الحالة الفعلية للمرغوبة آليًا بدلاً من مطالبة مهندس بكتابة نص لكل خطوة يدويًا، هو ما يجعل أدوات IaC الحديثة أكثر أمانًا وقابلية للصيانة بشكل ذي معنى من البرمجة النصية الحتمية التي استبدلتها.