ما البنية التحتية الثابتة؟

يمكن للمجموعات إدارة البنية التحتية من خلال نهجين: قابل للتغيير وغير قابل للتغيير. وتحل البنية التحتية الثابتة محل الخوادم بالكامل بدلاً من تعديلها. كما تقوم البنية التحتية الثابتة بتعديل الخوادم في مكانها، وتطبيق التحديثات والتصحيحات وتغييرات التكوين مباشرة على خوادم الإنتاج.

نظرًا لأنها تقوم بشكل أساسي بتعديل الخوادم الحالية، يمكن أن تبدو البنية التحتية الثابتة أكثر كفاءة. ومع ذلك، هناك عاملان غالبًا ما يجعلان البنية التحتية الثابتة أكثر عملية وأفضل.

أولاً، أدت الحوسبة السحابية والنقل بالحاويات إلى تغيير سرعة النشر. ويمكن للمجموعات الآن استبدال الأجهزة الافتراضية (VMs) والحاويات في دقائق بدلاً من الساعات المطلوبة للخوادم المادية. كما يمكن لأدوات أتمتة البنية التحتية توفير خوادم وموارد تكنولوجيا المعلومات الجديدة وتكوينها وتطبيق تغييرات موحدة على نطاق واسع.

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

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

تتبع البنية التحتية الحصينة غير القابلة للتغيير سير عمل من ثلاث مراحل: توفير موارد جديدة ونشرها وتمكين الاسترداد الفوري عند الحاجة.

ينطبق سير العمل هذا على الخوادم أو الحاويات أو الأجهزة الافتراضية أو الوظائف أو أي موارد بنية تحتية أخرى طوال دورة حياتها.

يؤدي التجهيز تلقائيًا إلى إنشاء عناصر جديدة للبنية الأساسية لتكنولوجيا المعلومات التي تستخدم البنية الأساسية كرمز (IaC)—وهي ممارسة تستخدم قوالب أو رمز إعلاني لتحديد حالات البنية التحتية المقصودة.

لتحديث بيئة غير قابلة للتغيير، تنشئ الفرق موردًا جديدًا بالكامل مع التكوين المحدد بدلاً من استخدام SSH (بروتوكول شبكة للوصول الآمن إلى الخادم عن بُعد) لتعديل الموارد الموجودة. 

ثم يتم توثيق جميع تغييرات البنية التحتية في أنظمة التحكم في الإصدار مثل Git، ما يضمن اختبارها وإعادة إنتاجها.

تتضمن أدوات التزويد الشائعة ما يأتي: 

• Terraform: منصة البنية التحتية كرمز من HashiCorp توفر البنية التحتية وتديرها عبر AWS وGoogle Cloud وAzure والبيئات المحلية من خلال واجهات برمجة التطبيقات الخاصة بها، مع بناء جملة HCL توضيحية وملفات الحالة لتتبع التغييرات.

• Docker: يبني صور حاويات خفيفة الوزن استنادًا إلى أنظمة الملفات الطبقية والمحاكاة الافتراضية على مستوى نظام التشغيل، بشكل أساسي على أنظمة Linux ولكن أيضًا على أنظمة Windows وmacOS، ما يتيح النشر بشكل أسرع من الآلات الافتراضية التقليدية.

• Packer: أداة HashiCorp التي تنشئ صور آلات متطابقة في وقت واحد للعديد من مزودي السحابة والمنصات (AMIs لـ AWS، وقوالب VMware، وحاويات Docker) من تكوين JSON أو HCL واحد.

• AWS CloudFormation: أداة AWS الأصلية المستندة إلى قوالب JSON/YAML لتوفير الموارد مع إمكانية التراجع المدمج وكشف الانحراف. 

• Pulumi: منصة IaC التي تستخدم لغات البرمجة المألوفة (Python وTypeScript وGo) بدلاً من اللغات الخاصة بالمجال، ما يسمح للمطورين باستخدام تراكيب البرمجة القياسية مثل الحلقات والشروط.

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

إن عمليات النشر في البنية التحتية الثابتة هي عمليات ذرية—إما أن تنجح بشكل كامل أو لا تحدث على الإطلاق. يتماشى هذا النهج مع ممارسات عمليات التطوير ومسار بيانات التكامل المستمر، التي تؤكد على الاختبار المؤتمت والتكرار السريع والنشر الموثوق.

تنشر أدوات الأتمتة الإصدار الجديد من الموارد، وتعيد توجيه حركة المرور إليها، ثم توقف تشغيل الإصدار القديم. وفي حالة ظهور مشكلات في أثناء النشر، يظل المورد القديم دون مساس ويتم تشغيله، ما يحد من مخاطر فترة التعطل والتبعية.

تتضمن أدوات النشر والتنسيق الشائعة ما يأتي: 

• Kubernetes: منصة تنسيق حاويات مفتوحة المصدر تدير التطبيقات السحابية الأصلية في حاويات على نطاق واسع من خلال الشفاء الذاتي والتوسع التلقائي والتحديثات المتجددة عبر مجموعات من الأجهزة.

• Jenkins: مسار بيانات CI/CD  المستندة إلى الخادم والتي تعمل على أتمتة البناء والاختبار والنشر باستخدام نظام بنائي إضافي واسع النطاق (أكثر من 1,800 مكون إضافي) لتخصيص مسار بيانات البناء والاختبار والنشر.

• إجراءات GitHub: منصة CI/CD المدمجة في مستودعات GitHub، والتي يتم تشغيلها من خلال التزامات التعليمات البرمجية أو طلبات السحب أو الجداول الزمنية دون الحاجة إلى خوادم خارجية.

• Ansible (Red Hat): أداة لإدارة التكوين في المقام الأول ولكنها تُستخدم أيضًا للنشر. وتستخدم دليل YAML للأتمتة من دون وكيل، ولا تتطلب تثبيت أي برنامج على العُقد المُدارة، على عكس Puppet أوChef. 

نظرًا لأن الخوادم في البنية التحتية الثابتة سريعة الزوال—يتم استبدالها باستمرار—ويجب تخزين البيانات الدائمة خارجيًا. تستخدم المجموعات خدمات Cloud Databases أو Block Storage أو Object Storage للحفاظ على البيانات بشكل منفصل عن الخوادم التي يتم استبدالها. 

عندما يأتي خادم جديد متصلاً بالإنترنت، فإنه يعيد الاتصال بالبيانات الموجودة من خلال أنظمة التخزين الخارجية هذه. وغالبًا ما توجد التكوينات والبيانات الوصفية في أنظمة التحكم في الإصدار مثل Git. 

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

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

تعمل البنية التحتية الثابتة على التخلص من حالات الخوادم الغامضة من خلال عمليات النشر الذرية—فالتحديثات إما أن تنجح تمامًا أو لا تنجح على الإطلاق.

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

تلغي البنية التحتية الثابتة إمكانية حدوث مثل هذه الحالة. وفي حالة فشل التحديث، يظل الخادم في حالة موثقة جيدًا. وإذا نجح، يصل الخادم الجديد الذي تم تكوينه واختباره بالكامل.

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

يتم تحقيق هذا النهج باستخدام موازنات التحميل، التي توزع حركة مرور الشبكة عبر خوادم متعددة لتحسين الأداء. وتساعد أدوات مثل Nginx وAWS Elastic Load Balancing (ELB) من Amazon على دعم هذه الممارسة باستخدام خوارزمية لتعيين طلبات المستخدم إلى الخادم الأكثر كفاءة في أي لحظة معينة.

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

تعمل البنية التحتية الثابتة على تعزيز الأمان من خلال التخلص من "حالات ندفة الثلج" التي لا يمكن التنبؤ بها—الخوادم ذات التكوينات غير المعروفة بعد التحديثات الفاشلة—والحفاظ على مسارات تدقيق كاملة لجميع التغييرات.

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

وتلغي البنية التحتية الثابتة أيضًا الحاجة إلى استخدام عمليات تسجيل الدخول Secure Shell (SSH) لتحرير الخوادم الموجودة في مكانها، ما يقلل من سطح الهجوم العام للشبكة.

تتميز الميزة أيضًا بمقايضات مقارنةً بالبنية التحتية التقليدية القابلة للتغيير، خاصةً في ما يتعلق بتخزين البيانات.

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

يمكن القيام بهذه الطريقة باستخدام تخزين البيانات مثل Cloud Databases أو Block Storage أو Object Storage. عندما يتصل جهاز افتراضي جديد بالإنترنت، يمكنه بعد ذلك إعادة الاتصال بسلاسة مع البيانات الموجودة من خلال التخزين الخارجي. وتحتفظ المجموعات بشكل عام بالتكوين والبيانات الوصفية في أنظمة التحكم في الإصدار مثل Git.

ومع ذلك، فإن "الثبات" الحقيقي للبنية التحتية الثابتة موضع نواع في بعض الأحيان. وتعود هذه القيود إلى أن بيانات مستخدم الشبكة المخزّنة خارجيًا تكون في حالة تغير مستمر وبالتالي لا يمكن مقارنتها بحالة معروفة.