البنية التحتية كرمز (Infrastructure as Code — اختصارًا IaC) هي إحدى أهم الممارسات في DevOps الحديثة. هذه الصفحة هي المرجع المفاهيمي لمسار IaC و Terraform؛ هدفها أن تفهم الفكرة والمبادئ أولًا، قبل تعلّم أداة بعينها. المفهوم هنا أوسع من Terraform، والأداة مجرّد مثال عليه.
ما هي البنية التحتية كرمز؟
البنية التحتية كرمز هي إدارة موارد البنية التحتية — خوادم، شبكات، قواعد بيانات، أذونات — عبر ملفات تعريف مقروءة آليًا بدلًا من الإعداد اليدوي عبر لوحات التحكّم أو الأوامر المتفرّقة.
بدل أن يدخل مهندس إلى لوحة تحكّم المزوّد ويُنشئ خادمًا بالنقر، يصف البنية المطلوبة في ملف نصّي (كود)، ثم تتولّى أداة IaC إنشاء تلك الموارد وتحديثها مطابِقةً للوصف.
ملف التعريف يصبح المصدر الوحيد للحقيقة لما يجب أن تكون عليه بنيتك التحتية.
لماذا وُجدت IaC؟
الإعداد اليدوي يسبّب مشكلات متكرّرة:
- خوادم «ندفة الثلج» (Snowflake servers): كل خادم أُعدّ يدويًا يختلف قليلًا عن غيره، فيصعب تكراره أو استبداله.
- غياب قابلية إعادة الإنتاج: بيئة الاختبار لا تطابق بيئة الإنتاج، فتظهر أعطال «تعمل عندي ولا تعمل عندك».
- بطء وخطأ بشري: بناء بيئة كاملة بالنقر يستغرق ساعات وعرضة للنسيان والخطأ.
- غياب التوثيق والتتبّع: من غيّر إعداد الجدار الناري الأسبوع الماضي؟ لا سجلّ.
IaC يحلّ ذلك: البنية موصوفة بالكود، تُنشأ آليًا، ومتطابقة في كل مرة، وتغييراتها موثّقة ومُراجَعة.
التصريحي مقابل الأمري
هناك أسلوبان لوصف البنية:
- الأمري (Imperative): تصف الخطوات خطوة بخطوة للوصول للنتيجة. مثاله سكربت: «أنشئ خادمًا، ثم افتح المنفذ 80، ثم ثبّت الحزمة...». أنت مسؤول عن الترتيب والتحقّق من الحالة الحالية.
# أسلوب أمري (مبسّط): أنت تحدّد الخطوات
aws ec2 run-instances --image-id ami-xxxx --instance-type t3.micro
- التصريحي (Declarative): تصف الحالة النهائية المطلوبة، وتترك للأداة معرفة كيف تصل إليها ابتداءً من الوضع الحالي. أدوات مثل Terraform و CloudFormation تصريحية.
# أسلوب تصريحي: تصف "ماذا تريد" لا "كيف"
resource "aws_instance" "web" {
ami = "ami-xxxx" # قيمة توضيحية؛ المعرّف الحقيقي يختلف حسب المنطقة
instance_type = "t3.micro"
tags = { Name = "web-server" }
}
الميزة الكبرى للتصريحي: تكتب النتيجة المطلوبة مرّة واحدة، وتتكفّل الأداة بمقارنة الواقع بالمطلوب وتطبيق الفارق فقط. معظم أدوات IaC الحديثة تصريحية لهذا السبب.
سير عمل IaC
الدورة النموذجية في الأدوات التصريحية:
- الكتابة (Write): تصف البنية المطلوبة في ملفات الكود.
- المعاينة (Plan): تطلب من الأداة أن تعرض ما الذي ستغيّره قبل تنفيذ أي شيء — أي فرق بين الواقع والمطلوب.
- التطبيق (Apply): توافق، فتُنفّذ الأداة التغييرات لتطابق الوصف.
- التدمير (Destroy) عند الحاجة: إزالة كل الموارد المُدارة بأمر واحد.
خطوة المعاينة قبل التطبيق هي ما يجعل IaC آمنًا: ترى الأثر قبل حدوثه.
التحكّم بالإصدارات وقابلية إعادة الإنتاج
بما أنّ البنية أصبحت كودًا، فهي تُخزَّن في نظام تحكّم بالإصدارات مثل Git. يمنحك هذا:
- سجلّ كامل لكل تغيير: من غيّر ماذا ومتى ولماذا.
- قابلية إعادة الإنتاج: من الملفات نفسها تُنشئ بيئة مطابقة (تطوير/اختبار/إنتاج) في أي وقت.
- التراجع (Rollback): العودة إلى حالة سابقة معروفة بالرجوع إلى commit أقدم.
Idempotency (الثبات عند التكرار)
خاصية جوهرية في IaC: تطبيق الوصف نفسه عدّة مرّات يعطي النتيجة نفسها. إن كان الخادم موجودًا ومطابقًا للوصف، فإعادة التطبيق لا تُنشئ خادمًا ثانيًا ولا تُحدث تغييرًا — تبقى النتيجة ثابتة. هذا ما يجعل الأدوات التصريحية آمنة للتشغيل المتكرّر دون خوف من التكرار غير المقصود.
الحالة (State) والانحراف (Drift)
- الحالة (State): تحتفظ الأداة بسجلّ لما تُديره من موارد وربطها بما في الكود. هذا السجلّ يُمكّنها من معرفة ما تغيّر وما يجب إنشاؤه أو حذفه. ملف الحالة حسّاس ويجب حمايته (سنعود إليه في الاعتبارات الأمنية).
- الانحراف (Drift): حين يتغيّر الواقع يدويًا خارج الكود — مثلًا يعدّل أحدهم إعدادًا مباشرةً في لوحة التحكّم — فيصبح الواقع مختلفًا عمّا يصفه الكود. أدوات IaC تكشف هذا الانحراف عند المعاينة، فتعيده إلى ما يصفه الكود. الدرس: كل تغيير يمرّ عبر الكود، لا يدويًا.
المراجعة وإدارة التغيير
لأنّ البنية كود، تنطبق عليها ممارسات هندسة البرمجيات:
- مراجعة الأقران (Pull Request): يُراجَع أي تغيير على البنية قبل دمجه.
- المعاينة في CI: تشغيل خطوة «المعاينة» آليًا داخل خطّ التكامل المستمر لإظهار الأثر ضمن طلب الدمج.
- بيئات متدرّجة: تطبيق التغيير على بيئة اختبار قبل الإنتاج.
اعتبارات أمنية
- لا تُودِع الأسرار في الكود: مفاتيح الوصول وكلمات المرور لا تُكتب في ملفات IaC؛ استخدم إدارة أسرار مخصّصة.
- احمِ ملف الحالة (State): قد يحوي بيانات حسّاسة؛ خزّنه في موقع مشترك آمن ومشفّر مع آلية قفل، لا محليًا ولا في Git.
- مبدأ الأقلّ امتيازًا (Least Privilege): امنح الأدوار الصلاحيات الضرورية فقط لتنفيذ التغييرات.
Terraform كمثال (لا كموضوع الصفحة)
Terraform من HashiCorp أشهر أدوات IaC التصريحية، ويعمل عبر مزوّدين متعدّدين (AWS، Azure، Google Cloud وغيرها) بلغة وصف تُدعى HCL. لكنّه ليس الخيار الوحيد: هناك أيضًا AWS CloudFormation و Pulumi و Ansible و Bicep. كلّها تجسّد المبادئ نفسها التي شرحناها هنا؛ ما يتغيّر هو الصياغة والنظام البيئي.
ℹ️ الأمثلة بلغة HCL أعلاه توضيحية للمفهوم فقط. تعلّم Terraform عمليًا يأتي في صفحات لاحقة من هذا المسار.
علاقتها بمواضيع IaC القادمة
تُمهّد هذه الصفحة لمسار متكامل: ما هو Terraform وكيف يعمل، ثم ملفات الحالة (State)، فـالمزوّدون (Providers) والوحدات (Modules)، وصولًا إلى مشروع عملي.
وقد تناول مسار DevOps لدينا IaC من زاوية عمليّة ضمن خطّ CI/CD في درس البنية التحتية كرمز في DevOps؛ اعتبر تلك الصفحة تطبيقًا ضمن سياق النشر، وهذه الصفحة المرجع المفاهيمي الأشمل. للتوسّع في النشر والأمان انظر استراتيجيات النشر وأمان خطّ الأنابيب.