كانت بنيتنا التحتية قصرًا من ورق: كيف أنقذنا Terraform من جحيم التغييرات اليدوية وانحراف الإعدادات؟

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

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

في تلك الليلة، ونحن بنحاول نرجع كل شي زي ما كان، ونقارن ملفات الكونفيج بين سيرفر الإنتاج وسيرفر التجربة (Staging)، أدركت حقيقة مُرّة: بنيتنا التحتية كانت زي قصر من ورق. أي نسمة هواء، أي تغيير يدوي صغير، كان كفيل يهدها فوق رؤوسنا. كانت هذيك الليلة هي القشة التي قصمت ظهر البعير. قلنا لحالنا: “خلص، بكفي! لازم نلاقي حل جذري لهالغلبة”. وهون بلشت رحلتنا مع المنقذ: Terraform.

ما هو جحيم التغييرات اليدوية؟

قبل ما نحكي عن الحل، خلينا نفصّل أكتر بالمشكلة اللي كنا عايشين فيها، واللي أنا متأكد كتير منكم بعاني منها. المشكلة إلها وجهين رئيسيين:

انحراف الإعدادات (Configuration Drift)

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

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

“عندي شغال!” على مستوى السيرفرات

كلنا بنعرف جملة المبرمج الشهيرة “It works on my machine” أو “عندي شغال!”. انحراف الإعدادات هو النسخة الاحترافية من هالجملة على مستوى البنية التحتية. بصير فريق العمل يضيع وقته في مطاردة أشباح ومشاكل غامضة سببها اختلافات خفية بين السيرفرات بدل ما يركز على تطوير ميزات جديدة.

المنقذ Terraform: البنية التحتية كشيفرة (IaC)

وسط هذا الجحيم، ظهر لنا ضوء في آخر النفق اسمه “البنية التحتية كشيفرة” أو Infrastructure as Code (IaC). الفلسفة بسيطة وعبقرية: عامل البنية التحتية (سيرفراتك، قواعد بياناتك، شبكاتك، كل شي) بنفس الطريقة اللي بتعامل فيها كود التطبيق تبعك.

• اكتبها في ملفات نصية.
• خزنها في نظام إدارة نسخ مثل Git.
• راجع التغييرات (Code Review).
• اعملها اختبارات.
• طبقها بشكل آلي ومتكرر.

وهنا يأتي دور Terraform، الأداة الأشهر والأقوى في عالم الـ IaC من شركة HashiCorp.

ما هو Terraform بالضبط؟

ببساطة، Terraform هو أداة بتسمح لك توصف بنيتك التحتية على شكل كود في ملفات سهلة القراءة (باستخدام لغة HCL). أنت بتوصف “الحالة النهائية” اللي بدك ياها (مثلاً: بدي سيرفرين بمواصفات كذا، وقاعدة بيانات، وموازن أحمال بينهم)، وTerraform بتكفل بالباقي. هو اللي بحاكي الـ API تبع مزود الخدمة السحابية (مثل AWS, Azure, Google Cloud) وبنفذ اللي طلبته.

أجمل ما في الموضوع أنه “تعريفي” (Declarative). أنت لا تأمر “كيف” تبني، بل تصف “ماذا” تريد أن تبني.

كيف يعمل تيرافورم؟

دورة حياة Terraform تتلخص في ثلاث خطوات ساحرة:

1. Write (كتابة): أنت كمطور تكتب كود HCL لوصف البنية التحتية المطلوبة.
2. Plan (تخطيط): بتشغل أمر terraform plan. هنا يحدث السحر. Terraform يقرأ الكود تبعك، ويقارنه بالحالة الحالية للبنية التحتية (اللي هو مخزنها في ملف خاص اسمه state file)، وبعطيك خطة مفصلة: “سأقوم بإنشاء المورد الفلاني، وتعديل المورد العلاني، وحذف هذا المورد”. ما في مفاجآت!
3. Apply (تطبيق): إذا عجبتك الخطة، بتشغل أمر terraform apply. بتأكد عليك مرة تانية، وبس تعطيه الموافقة، بروح ينفذ الخطة بحذافيرها.

لنُشمّر عن سواعدنا: مثال عملي بسيط

الحكي النظري حلو، بس خلينا نشوف الكود. لنفترض أننا نريد إنشاء سيرفر ويب بسيط (EC2 instance) على AWS.

الكود: ملف main.tf

هذا هو كل ما تحتاجه للبدء. أنشئ ملفًا اسمه main.tf وضع فيه الكود التالي:

# تحديد مزود الخدمة السحابية (AWS) والمنطقة
provider "aws" {
  region = "us-east-1"
}

# تعريف مورد: سيرفر EC2
resource "aws_instance" "web_server" {
  # Amazon Machine Image - نظام التشغيل
  ami           = "ami-0c55b159cbfafe1f0" # هذا AMI لـ Ubuntu 20.04 في us-east-1
  
  # نوع السيرفر (حجمه ومواصفاته)
  instance_type = "t2.micro" # هذا النوع ضمن الطبقة المجانية لـ AWS

  # إضافة "وسم" أو Tag لتمييز السيرفر
  tags = {
    Name = "MyFirstWebServer"
  }
}

التنفيذ: الأوامر السحرية

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

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

وإذا أردت حذف هذا السيرفر؟ بكل بساطة، نفذ أمر terraform destroy.

نقطة مهمة: لاحظ ملف terraform.tfstate الذي تم إنشاؤه. هذا هو “عقل” Terraform وذاكرته. يحتوي على حالة البنية التحتية التي يديرها. لا تحذفه أو تعدله يدويًا أبدًا!

نصائح من قلب الميدان (من خبرة أبو عمر)

الانتقال لـ Terraform كان نقلة نوعية، لكن الطريق ما كان مفروش بالورود. إليكم بعض النصائح اللي تعلمتها بالطريقة الصعبة:

ابدأ صغيرًا، ولكن ابدأ الآن

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

القاعدة الذهبية: لا تلمس الواجهة الرسومية!

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

إدارة الحالة (State Management) بشكل احترافي

ملف tfstate على جهازك المحلي جيد للتعلم، لكنه كارثة للعمل ضمن فريق. لو اثنين حاولوا يطبقوا تغييرات بنفس الوقت، راح تصير مصيبة. الحل؟ استخدم “الواجهة الخلفية عن بعد” (Remote Backend). أبسط مثال هو تخزين ملف الحالة في مكان مشترك مثل AWS S3 Bucket مع تفعيل القفل (Locking) باستخدام DynamoDB. هذا يضمن أن شخصًا واحدًا فقط يمكنه إجراء تغييرات في كل مرة.

اجعل شيفرتك قابلة لإعادة الاستخدام (Modules)

بعد فترة، ستلاحظ أنك تكرر نفس الكود لإنشاء “سيرفر ويب”. هنا يأتي دور الـ Modules. يمكنك تجميع كود إنشاء سيرفر الويب مع كل إعداداته في “Module”، ثم استدعاؤه بسهولة لإنشاء سيرفرات لبيئة التطوير، التجربة، والإنتاج، مع تمرير متغيرات بسيطة لكل بيئة.

الخلاصة: من قصر الورق إلى قلعة الصخر

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

نعم، هناك منحنى تعلم، ولكن الاستثمار في تعلم Terraform و IaC هو أفضل استثمار يمكن أن يقوم به أي فريق DevOps أو مطور يهتم باستقرار وجودة عمله. إنه الفرق بين بناء قصر من ورق يمكن أن ينهار في أي لحظة، وبناء قلعة من صخر، أساسها الكود، وعمادها الأتمتة. 💪