كانت بيئاتنا السحابية فوضى: كيف أنقذتنا ‘البنية التحتية كود’ (IaC) من جحيم ‘الانحراف التكويني’؟

بتذكرها زي كأنه امبارح… كانت ليلة خميس، والساعة داخلة على وحدة بعد نص الليل. أنا وباقي الفريق كنا بنحاول نصلّح مشكلة “عويصة” في المنصة الرئيسية. التطبيق على بيئة الاختبار (Staging) شغال زي الحلاوة، بس على بيئة الإنتاج (Production) بضرب خطأ غريب ما إله أي معنى. قضينا ساعات بنقارن الكود، إعدادات التطبيق، كل شي… وما فيه فايدة.

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

ما هو “الجحيم” الذي كنا نعيش فيه؟ تعريف الانحراف التكويني (Configuration Drift)

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

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

من أين يأتي هذا “الانحراف” اللعين؟

• الإصلاحات السريعة (Hotfixes): الحاجة لإصلاح مشكلة حرجة في بيئة الإنتاج بشكل فوري، مما يدفع المهندسين للدخول على الخادم مباشرة وتغيير ملف تكوين أو تثبيت حزمة برمجية دون توثيق.
• التحديثات اليدوية: تحديث نظام التشغيل أو المكتبات على خادم واحد ونسيان تطبيق نفس التحديث على الخوادم الأخرى المماثلة.
• غياب مصدر الحقيقة الواحد (Single Source of Truth): عندما لا يكون هناك مكان مركزي وموثوق يصف كيف يجب أن تكون البنية التحتية، يصبح كل شخص “يجتهد” من عنده.
• الوصول غير المنضبط: منح عدد كبير من المطورين صلاحيات الدخول (SSH) على خوادم الإنتاج.

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

الضوء في آخر النفق: مرحبًا بك في عالم “البنية التحتية كود” (IaC)

بعد هذيك الليلة، أخذنا قرارًا حاسمًا: “خلص، بكفي!”. لا يمكن أن نستمر في إدارة عشرات، بل مئات، الخوادم والخدمات بهذه الطريقة البدائية. وهنا بدأنا رحلتنا مع مفهوم غيّر حياتنا: البنية التحتية كود (Infrastructure as Code – IaC).

الفكرة بسيطة لكنها عبقرية: عامل بنيتك التحتية (خوادم، شبكات، قواعد بيانات، جدران حماية) بنفس الطريقة التي تعامل بها كود التطبيق الخاص بك. بدلاً من النقر على الأزرار في واجهة AWS أو Azure أو Google Cloud، أو كتابة أوامر يدوية على الخوادم، تقوم بكتابة “وصف” للبنية التحتية التي تريدها في ملفات نصية (كود).

ببساطة، الكود يصبح هو “المصدر الوحيد للحقيقة” الذي يصف حالة البنية التحتية. أي تغيير يجب أن يتم عبر تعديل الكود، وليس عبر أي تدخل يدوي.

فوائد هذا التحول كانت فورية وتقريبًا سحرية:

• القضاء على الانحراف التكويني: بما أن الكود هو المرجع، يمكننا دائمًا مقارنة الحالة الفعلية للبنية التحتية مع الكود، واكتشاف أي “انحراف” وتصحيحه تلقائيًا.
• التكرار والاتساق (Repeatability & Consistency): يمكننا الآن إنشاء بيئة تطوير أو اختبار أو إنتاج جديدة مطابقة 100% للأخرى بكبسة زر. لا مزيد من “شغالة عندي بس مش شغالة عندك”.
• السرعة والأتمتة: ما كان يأخذ منا أيامًا من الإعداد اليدوي، أصبح الآن يستغرق دقائق.
• التوثيق الذاتي: ملفات الكود نفسها أصبحت أفضل توثيق للبنية التحتية. أي شخص جديد في الفريق يمكنه قراءة الكود وفهم تصميم النظام.
• المراجعة والمساءلة (Review & Accountability): تمامًا مثل كود التطبيق، يمكننا استخدام Git لمراجعة تغييرات البنية التحتية قبل تطبيقها (عبر Pull Requests)، ونعرف بالضبط من غيّر ماذا ومتى ولماذا.

أداتنا السحرية: لمحة عن Terraform وكيف غيّر قواعد اللعبة

عندما قررنا تبني IaC، كان السؤال هو: أي أداة نستخدم؟ بعد بحث وتقصي، وقع اختيارنا على Terraform من شركة HashiCorp، ولأسباب وجيهة.

Terraform هي أداة مفتوحة المصدر تسمح لك بتعريف البنية التحتية السحابية والمحلية باستخدام لغة تعريفية بسيطة ومقروءة تسمى HCL (HashiCorp Configuration Language). ما يميزها هو:

• النهج التعريفي (Declarative): أنت تصف “ماذا” تريد (مثلاً: أريد خادمًا بهذه المواصفات وقاعدة بيانات من هذا النوع)، وTerraform تتكفل بمعرفة “كيف” تحققه. هذا عكس النهج الأمري (Imperative) مثل كتابة سكربتات Shell التي يجب أن تخبره بالخطوات بالتفصيل.
• متعددة المنصات (Multi-Cloud): تدعم Terraform مئات “المزودين” (Providers)، مما يعني أنه يمكنك استخدامها لإدارة الموارد على AWS, Azure, Google Cloud, DigitalOcean وحتى خدمات مثل Cloudflare وDatadog، كل ذلك من نفس المكان.
• إدارة الحالة (State Management): تحتفظ Terraform بملف يسمى “ملف الحالة” (State File) يسجل كل الموارد التي أنشأتها. هذا الملف حيوي لأنه يسمح لـ Terraform بمعرفة الوضع الحالي للبنية التحتية وتخطيط التغييرات المستقبلية بدقة.

من الفوضى إلى التنظيم: مثال عملي بسيط

دعنا نرى كيف يبدو الأمر على أرض الواقع. تخيل أننا نريد إنشاء خادم ويب بسيط على AWS.

الطريقة القديمة (النقرات اليدوية): كنت ستفتح لوحة تحكم AWS، تذهب إلى EC2، تضغط “Launch Instance”، ثم تمر عبر 7-8 شاشات لاختيار نوع الخادم، والشبكة، والأمان، والتخزين… عملية مملة وعرضة للخطأ والنسيان.

طريقة Terraform (البنية التحتية كود):

كل ما تحتاجه هو ملف نصي واحد، لنسميه `main.tf`:

# main.tf - ملف تعريف البنية التحتية

# 1. تحديد مزود الخدمة الذي سنتعامل معه (AWS) وتحديد المنطقة
provider "aws" {
  region = "eu-central-1" # فرانكفورت كمثال
}

# 2. تعريف المورد (Resource) الذي نريد إنشاءه
# هنا، سنقوم بإنشاء خادم EC2
resource "aws_instance" "app_server" {
  # Amazon Machine Image (AMI) - صورة نظام التشغيل
  ami           = "ami-0f2545d3c58252277" 

  # نوع الخادم (حجم المعالج والذاكرة)
  instance_type = "t2.micro"

  # الوسوم (Tags) مهمة جدًا لتنظيم مواردك
  tags = {
    Name        = "WebServer-Prod"
    Environment = "Production"
    ManagedBy   = "Terraform"
  }
}

الآن، كل ما عليك فعله هو فتح الطرفية (Terminal) في نفس المجلد وكتابة ثلاثة أوامر بسيطة:

1. terraform init: هذا الأمر يقوم بتحميل “مزود” AWS، يجب تشغيله مرة واحدة في بداية كل مشروع.
2. terraform plan: هذا هو أمر الأمان المفضل لدي. سيقوم Terraform بقراءة الكود ومقارنته بالحالة الحالية (في البداية، لا شيء)، ثم يعرض لك “خطة” مفصلة بما سيقوم به (مثلاً: “سأقوم بإنشاء خادم EC2 واحد بهذه المواصفات”). لن يتم تنفيذ أي شيء بعد، إنها مجرد معاينة.
3. terraform apply: إذا كانت الخطة تبدو صحيحة، اكتب هذا الأمر، وافق على التنفيذ، وشاهد Terraform وهو يبني لك البنية التحتية أمام عينيك.

والأجمل؟ إذا أردت تغيير نوع الخادم من `t2.micro` إلى `t3.small`، كل ما عليك فعله هو تغيير سطر واحد في الكود، وتشغيل `plan` و `apply` مرة أخرى. Terraform ذكي بما يكفي ليعرف أنه يحتاج فقط لتعديل الخادم الموجود بدلاً من هدمه وبنائه من جديد (إذا أمكن).

نصائح “أبو عمر” الذهبية لتبني البنية التحتية كود

بعد سنين من الممارسة والتعلم من أخطائنا، هذه بعض النصائح العملية التي أتمنى لو أخبرني بها أحد في البداية:

• ابدأ صغيراً، ولكن ابدأ الآن: لا تحاول تحويل كل بنيتك التحتية المعقدة إلى كود في يوم واحد. ابدأ بمشروع جديد صغير، أو بمكون منفصل مثل إعدادات DNS. المهم أن تبدأ وتتعلم. “ما حدا بنولد معلم”.
• الكود هو المصدر الوحيد للحقيقة: هذه قاعدة لا يمكن كسرها. بمجرد أن تبدأ بإدارة مورد عبر Terraform، امنع تمامًا أي تعديل يدوي عليه. أي تغيير، مهما كان صغيراً، يجب أن يمر عبر الكود ومراجعته.
• خزّن “الحالة” عن بعد وبشكل آمن (Remote State): افتراضيًا، يحفظ Terraform ملف الحالة على جهازك المحلي. هذا كابوس عند العمل في فريق. تعلم فورًا كيفية إعداد “حالة عن بعد” (Remote State) باستخدام خدمات مثل Amazon S3 أو Terraform Cloud. هذا يسمح للفريق بمشاركة الحالة ويمنع التضارب.
• قسّم الكود إلى وحدات (Modules): عندما يكبر مشروعك، لا تضع كل شيء في ملف واحد. تعلم استخدام “الوحدات” (Modules) في Terraform. الوحدة هي مجموعة من الموارد التي يمكنك إعادة استخدامها، تمامًا مثل “الدوال” (Functions) في البرمجة. يمكنك إنشاء وحدة لـ “خادم الويب” أو “قاعدة البيانات” واستدعائها عند الحاجة.
• لا تخترع العجلة: قبل أن تبني وحدة معقدة بنفسك، ألق نظرة على Terraform Registry الرسمي. هناك آلاف الوحدات الجاهزة والموثوقة التي يمكنك استخدامها لتسريع عملك.

الخلاصة: من “يا ويل قلبي” إلى “كله تمام”

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

إذا كنت لا تزال تدير بنيتك التحتية يدويًا، نصيحتي لك كأخ: استثمر في تعلم IaC وTerraform. قد يبدو الأمر شاقًا في البداية، لكنه استثمار في استقرار نظامك، وفي سرعة فريقك، والأهم من ذلك كله، في راحة بالك. “مشوار الألف ميل بيبدأ بخطوة”، فلتكن خطوتك الأولى اليوم. 💪