ما المقصود بالبنية التحتية ككود (IaC)؟

تتعامل IaC مع البنية التحتية كبرنامج. تستخدم الفِرَق IaC لإصدار البنية التحتية واختبارها ونشرها باستخدام الممارسات نفسها التي يستخدمونها في التعليمات البرمجية للتطبيق. 

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

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

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

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

تساعد بنية IaC على إدارة هذه البيئات المعقدة بثلاث طرق أساسية:

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

على سبيل المثال، قد تكون شركة بيع بالتجزئة تستعد لموسم الجمعة البيضاء، مضطرة إلى زيادة عدد الخوادم من 100 إلى 1,000 خلال بضع ساعات. باستخدام IaC، تتم عملية التوسع هذه تلقائيًا عبر البنية التحتية المحلية والسحابية استنادًا إلى قوالب محددة مسبقًا. تساعد هذه القدرة على توسيع النطاق على ضمان احتفاظ كل خادم جديد بتكوينات الأمان والامتثال المتطابقة.

وفقًا لمعهد IBM Institute for Business Value، أفاد 65% من التنفيذيين بأن تقنيات الأتمتة مثل IaC تعزز إنتاجية فِرَق تكنولوجيا المعلومات لديهم.

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

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

يتَّبِع سير عمل IaC أربع مراحل:

يُنشئ المطورون نصوص IaC باستخدام لغات مثل HCL أو YAML أو JSON، تمامًا كما يكتبون كود التطبيقات بلغات مثل Java أو Python. تكتب الفِرَق تعريفات البنية التحتية التي تحدِّد الموارد المطلوبة وكيفية تكوينها. غالبًا ما تكتب الفِرَق هذه الملفات في بيئات التطوير المتكاملة (IDEs)، التي توفِّر ميزات مثل التحقق من الأخطاء والإكمال التلقائي.

يتم تخزين الكود في أنظمة التحكم في الإصدارات -المعروفة أيضًا باسم التحكم في المصدر أو مستودعات الكود المصدر- مثل Git أو GitHub. يتتبَّع نظام التحكم في الإصدارات التغييرات، ويحافظ على إصدارات بديلة، ويمكِّن الفرق من العودة إلى الإصدارات السابقة عند حدوث مشكلات.

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

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

توفِّر الأدوات المؤتمتة آليات لتحديد البنية التحتية وتتبُّعها وإنشائها من خلال التعليمات البرمجية.

تحدِّد ملفات التكوين البنية التحتية. يمكن كتابتها بلغة HCL أو JSON أو YAML أو لغات خاصة بالمجال. تُعَد هذه الملفات مخططات تَصِف بدقة البنية التحتية المطلوبة -عدد الخوادم وحجمها وإعدادات الشبكة- وذلك بتنسيق يمكن لأدوات الأتمتة قراءته وتنفيذه.

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

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

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

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

بعض المحركات مخصَّصة لسحابة معينة، مثل AWS CloudFormation وAzure Resource Manager وGoogle Cloud Deployment Manager. بينما يعمل البعض الآخر على جميع السُحب، مثل Terraform وOpenTofu (وهو تفرُّع مفتوح المصدر من Terraform) أو Pulumi (الذي يستخدم لغات برمجة عامة مثل Python).

غالبًا ما يتم إقران محركات الأتمتة هذه بأدوات التنسيق مثل Kubernetes لتنسيق الموارد وأعباء العمل على نطاق واسع.

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

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

عند تنفيذ البنية التحتية ككود (IaC)، تتخذ المؤسسات خيارين أساسيين: كيفية تعريف البنية التحتية (وصفية أم إجرائية)، إذا ما كان يمكن تعديل البنية التحتية بعد النشر (قابلة للتغيير أم غير قابلة للتغيير).

يختلف النهجان الوصفي والإجرائي في الطريقة التي يُكتَب بها كود البنية التحتية.

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

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

يمكن تعديل البنية التحتية القابلة للتغيير بعد التوفير، بينما لا يمكن تعديل البنية التحتية غير القابلة للتغيير بعد التوفير.

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

تختار معظم المؤسسات البنية التحتية غير القابلة للتغيير. لتغيير خادم أو تكوين، يجب على الفِرَق استبدال البنية التحتية بأكملها بموارد جديدة.

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

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

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

من خلال أتمتة إدارة البنية التحتية التي تستخدم التعليمات البرمجية، توفِّر IaC العديد من الفوائد:

تُعَد IaC أساسية لممارسات عمليات التطوير لأنها تمكِّن البنية التحتية من التحرك بسرعة تطوير البرمجيات.

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

تقضي IaC على هذه الفجوة من خلال تطبيق التكامل المستمر والتسليم المستمر (CI/CD) على عمليات نشر البنية التحتية. يمكن اختبار كود البنية التحتية والتطبيق والتحقق منهما ونشرهما معًا بشكل متوازٍ، بدلًا من تنفيذهما كعمليات منفصلة.

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

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

تنقسم أدوات IaC إلى فئتين رئيسيتين: أدوات التوفير التي تعمل على إنشاء البنية التحتية ونشرها، وأدوات إدارة التكوين التي تحافظ على البنية التحتية بعد النشر.

تعمل بعض الأدوات على جميع السحابات (تعمل عبر العديد من موفري الخدمات)، في حين أن البعض الآخر خاص بمنصات محددة.

عادةً ما تجمع المؤسسات بين الأدوات من كِلتا الفئتين لبناء مسارات IaC متكاملة.

تعمل أدوات التوفير على إنشاء ونشر موارد البنية التحتية - الخوادم و الشبكات وأنظمة التخزين. وتركِّز على الإعداد الأوَّلي وتكوين عناصر البنية التحتية، وتحويل متطلبات البنية التحتية إلى موارد تشغيلية. 

تُعَد Terraform من HashiCorp، وهي إحدى شركات IBM، أداة IaC يمكن تشغيلها على جميع السحابات وتستخدم تكوينًا وصفيًّا لإدارة البنية التحتية عبر منصات متعددة.

تكتب الفِرَق تعريفات البنية التحتية بلغة HCL (لغة تكوين HashiCorp) ويمكنها نشر الكود نفسه على AWS أو Azure أو Google Cloud أو مراكز البيانات المحلية. تُتيح هذه القدرة على النقل للمؤسسات تجنُّب الاعتماد على مزوِّد واحد ودمج مقدِّمي الخدمات السحابية بناءً على نقاط قوتهم - على سبيل المثال، استخدام AWS للحوسبة وGoogle Cloud للتعلم الآلي.

تعمل Terraform أيضًا على تسريع عمليات النشر من خلال توفير الموارد عبر العديد من المزوِّدين في الوقت نفسه. وتعمل على تحليل التبعيات بين الموارد وإنشاء الموارد المستقلة بشكل متوازٍ. على سبيل المثال، إذا كان يتم نشر 10 خوادم AWS و5 قواعد بيانات Azure دون أي تبعيات، تعمل Terraform على إنشاء جميع الموارد الـ 15 دفعة واحدة بدلًا من تنفيذها بالتسلسل، ما يقلل من وقت النشر.

يُعَد AWS CloudFormation حل IaC أصليًا من Amazon للبنية التحتية على AWS. تحدِّد الفرق حِزَم التطبيقات بأكملها -من خوادم EC2 إلى قواعد بيانات Rational Directory Server- باستخدام قوالب JSON أو YAML. تتولى CloudFormation إدارة تبعيات الموارد تلقائيًا، حيث تُنشئها بالترتيب الصحيح وتعيدها إذا حدثت أخطاء.

بالرغم من اقتصارها على AWS، توفِّر CloudFormation تكاملًا عميقًا مع خدمات AWS ودعمًا فوريًا للخدمات الجديدة. قد تفضِّل المؤسسات التي تعتمد على AWS أداءَها الأصلي والوصول إلى الميزات الحصرية.

يُعَد Azure Resource Manager (ARM) أداة IaC الأصلية من Microsoft للبنية التحتية على Azure. ورغم اقتصارها على Azure، فإنها توفِّر تكاملًا عميقًا مع المنصة.

تستخدم المؤسسات قوالب ARM بتنسيق JSON لتحديد موارد Azure ونشرها وإدارتها. توفِّر ARM ميزات مدمجة تشمل التحكم في الوصول القائم على الأدوار للأمان ووضع علامات على الموارد للتنظيم وأقفال لمنع الحذف العرضي، ورسم خرائط التبعيات لضمان نشر الموارد بالترتيب الصحيح. 

يُعَد Google Cloud Deployment Manager أداة IaC الأصلية من Google، ويستخدم قوالب YAML أو Python لتنظيم عمليات النشر على Google Cloud. رغم أنها مخصصة لمنصة معينة، فإنها تعمل على إنشاء وتكوين الموارد عبر خدمات متعددة -مثل Cloud Storage للبيانات، وCompute Engine للأجهزة الافتراضية، وCloud SQL لقواعد البيانات- ما يضمن عملها معًا كمجموعة متكاملة.

تحافظ أدوات إدارة التكوين على البنية التحتية بعد التوفير، ما يضمن بقاء الأنظمة مهيأة بشكل صحيح ومحدَّثة ومتسقة. 

تُعَد Ansible أداة أتمتة من Red Hat تُدير التكوين دون الحاجة إلى وكلاء على الأنظمة المستهدفة. بمعنى آخر، لا تحتاج Ansible إلى برنامج خاص مثبَّت على الخوادم التي تُديرها. فهي تتصل مباشرةً باستخدام SSH لتنفيذ الأوامر.

يعني هذا النهج الخالي من الوكلاء أن Ansible تعمل عبر البيئات السحابية والمحلية والهجينة. تكتب الفِرَق الدلائل بصيغة YAML لتحديد الحالات المطلوبة، وتساعد Ansible على ضمان توافق الأنظمة مع هذه الحالات. وهي شائعة بشكل كبير في إدارة حاويات Docker وعمليات نشر Kubernetes.

تستخدم Puppet التكوين الوصفي لإدارة البنى التحتية الكبيرة عبر البيئات السحابية والمحلية ومراكز البيانات.

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

تعتمد Chef على "أدلة" و"وصفات" لتحديد تكوينات البنية التحتية في جميع البيئات، سواء أكانت سحابية أم محلية أم هجينة.

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