بنيتنا التحتية كانت قلاعًا من رمل: كيف أنقذتنا ‘البنية التحتية كشيفرة برمجية’ (IaC) من جحيم البيئات غير المتطابقة؟

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

وما هي إلا دقايق، وبدأت الإشعارات تنهال علينا زي المطر: “System Down”، “502 Bad Gateway”، “Connection Error”. قلوبنا وقعت في رجلينا. شو اللي صار؟ كيف كل شي كان شغال تمام وهلأ انهار؟

بدأ السباق مع الزمن، واحد بفحص السيرفرات، والتاني براجع سجلات الأخطاء (Logs)، وأنا كنت براجع الكود مرة ومرتين وعشرة. الكل يصرخ في وجه التاني: “عندي شغّال تمام!” (It works on my machine!). قضينا ساعات طويلة ونحنا بنقارن كل شي يدويًا، سطر بسطر، إعداد بإعداد، بين بيئة التجربة والإنتاج. وبالآخر، شو كانت المشكلة؟ يا زلمة اشي بسيط لدرجة بضحّك وببكّي بنفس الوقت. مجرد متغير بيئة (Environment Variable) صغير مسؤول عن الاتصال بقاعدة البيانات كان إله قيمة مختلفة في بيئة الإنتاج. تغيير يدوي صغير تم قبل أسابيع ونسي الجميع توثيقه.

في هذيك الليلة، أدركت إن بنيتنا التحتية اللي بنبنيها بإيدينا، بالنقرات والتعديلات اليدوية، ما هي إلا قلاع من رمل. جميلة من بعيد، لكن أي موجة بسيطة (أو خطأ بشري) قادرة على هدمها في لحظات. هنا كانت بداية رحلتنا مع مفهوم غيّر طريقة عملنا تمامًا: البنية التحتية كشيفرة برمجية (Infrastructure as Code).

ما هي حكاية “البنية التحتية كشيفرة برمجية” (IaC)؟

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

هذا المخطط تقدر تحفظه، تشاركه مع فريقك، تضع عليه إصدارات (Versioning) باستخدام Git زي أي كود برمجي عادي، والأهم من كل هاد، تقدر تطلب من أداة متخصصة إنها تقرأ هاد المخطط وتبني لك البنية التحتية بشكل آلي 100%.

باختصار، IaC هي تطبيق ممارسات تطوير البرمجيات (مثل التحكم في الإصدارات والمراجعة والأتمتة) على إدارة البنية التحتية.

الطريقة القديمة: كوابيس “ClickOps” وقلاع الرمل

قبل الـ IaC، كنا عايشين في عالم أُطلق عليه تهكمًا اسم “ClickOps”. وهو أن كل عمليات إدارة البنية التحتية تتم عبر النقرات (Clicks) داخل واجهات المستخدم الرسومية لمزودي الخدمات السحابية. هذه الطريقة، ورغم بساطتها الظاهرية، تخفي خلفها مشاكل قاتلة:

• البيئات غير المتطابقة: هذه هي أم المشاكل. بيئة التطوير (Development)، التجربة (Staging)، والإنتاج (Production) لا تكون متطابقة 100% أبدًا. دائمًا هناك “تعديل صغير” هنا أو “إعداد مؤقت” هناك، وهذا هو سبب الكوارث عند الإطلاق.
• الانحراف في الإعدادات (Configuration Drift): مع مرور الوقت، تتراكم التغييرات اليدوية الصغيرة وغير الموثقة. بعد سنة، لا أحد يتذكر لماذا تم فتح هذا البورت (Port) أو تغيير حجم ذاكرة هذا السيرفر. تصبح البنية التحتية صندوقًا أسود غامضًا.
• غياب التحكم في الإصدارات: لو قمت بتغيير يدوي سبب مشكلة، كيف يمكنك العودة للإصدار السابق؟ لا توجد طريقة سهلة. عليك أن تتذكر ما غيرته وتصلحه يدويًا، هذا إن تذكرت أصلًا!
• البطء والخطأ البشري: البشر يخطئون، خاصة تحت الضغط. إنشاء بنية تحتية معقدة يدويًا هو وصفة أكيدة للخطأ والنسيان. كما أنها عملية بطيئة جدًا.

ثورة الـ IaC: بناء الحصون الرقمية

جاءت الـ IaC لتقدم حلًا جذريًا لهذه المشاكل. فهي تحول البنية التحتية إلى كود، وهذا الكود يصبح هو “مصدر الحقيقة الوحيد” (Single Source of Truth). دعونا نفصّل أكثر.

النهج التقريري (Declarative) مقابل النهج الأمري (Imperative)

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

• النهج الأمري (The “How”): أنت تكتب سكربت يحدد الخطوات بالتفصيل للوصول للحالة المطلوبة. مثلًا: “أنشئ سيرفرًا، ثم ثبّت عليه أباتشي، ثم افتح البورت 80”. أدوات مثل سكربتات Bash تتبع هذا النهج. مشكلته أنه يجب عليك تتبع الحالة الحالية بنفسك.
• النهج التقريري (The “What”): وهذا هو الأقوى. أنت فقط تصف الحالة النهائية التي تريدها، والأداة هي التي تتكفل بمعرفة كيفية الوصول إليها. مثلًا: “أريد سيرفرًا واحدًا بالمواصفات كذا، وعليه أباتشي، والبورت 80 مفتوح”. الأداة ستنظر إلى الوضع الحالي، وتقارنه بالوضع المطلوب، وتنفذ التغييرات اللازمة فقط (إنشاء، تحديث، أو حذف).

أهلاً بـ Terraform: مطرقتنا المخلصة

Terraform من شركة HashiCorp هي أشهر أداة تتبع النهج التقريري. أصبحت بسرعة أداتنا المفضلة لعدة أسباب: هي مفتوحة المصدر، تدعم تقريبًا كل مزودي الخدمات السحابية (Cloud-Agnostic)، ولديها مجتمع ضخم، ولغة كتابتها (HCL) سهلة القراءة والكتابة.

لترى كيف يعمل، إليك مثال بسيط جدًا لإنشاء سيرفر (EC2 Instance) على AWS باستخدام Terraform:

# 1. تحديد مزود الخدمة السحابية الذي سنستخدمه
provider "aws" {
  region = "us-east-1"  # المنطقة التي سيتم إنشاء الموارد فيها
}

# 2. تعريف "مورد" - في هذه الحالة، سيرفر EC2 افتراضي
resource "aws_instance" "web_server" {
  # ami هو معرف صورة نظام التشغيل الذي سيتم استخدامه
  ami           = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
  
  # instance_type هو حجم ونوع السيرفر (CPU, RAM, etc.)
  instance_type = "t2.micro"

  # Tags هي علامات تعريفية تساعد في تنظيم الموارد
  tags = {
    Name = "MyWebServer-Prod"
    Env  = "Production"
  }
}

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

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

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

نصائح عملية من خبرة أبو عمر في الـ IaC

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

نصيحة 1: ابدأ صغيرًا، لكن ابدأ الآن

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

نصيحة 2: حافظ على ملف الحالة (State File) كما تحافظ على حياتك!

Terraform يستخدم ملفًا اسمه terraform.tfstate ليتذكر حالة البنية التحتية التي يديرها. هذا الملف حساس جدًا! لا تقم بحفظه على جهازك المحلي أبدًا، خاصة عند العمل في فريق. استخدم ما يسمى بـ “Remote Backends” لحفظه في مكان مركزي وآمن (مثل AWS S3) مع تفعيل القفل (Locking) لمنع شخصين من إجراء تغييرات في نفس الوقت.

نصيحة 3: الوحدات (Modules) هي صديقك المفضل

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

نصيحة 4: ادمج الـ IaC في مسار الـ CI/CD الخاص بك

هذه هي قمة الـ DevOps. قم بأتمتة العملية: عندما يقوم مطور بفتح طلب سحب (Pull Request) بتغيير على كود البنية التحتية، اجعل نظام الـ CI/CD ينفذ terraform plan تلقائيًا ويضيف نتيجة الخطة كتعليق على طلب السحب. وعند دمج التغيير في الفرع الرئيسي، اجعل النظام ينفذ terraform apply لتطبيق التغييرات. هذا يضمن أن كل تغيير يتم مراجعته وتطبيقه بشكل آلي وموثوق.

الخلاصة: من الفوضى إلى النظام ✅

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

نصيحتي الأخيرة لك: لا تخف من هذه الأدوات. ابدأ اليوم، ولو بخطوة صغيرة. بنيتك التحتية المستقبلية وفريقك (وصحتك النفسية) سيشكرونك على ذلك. 🚀