البنية التحتية كمغامرة: كيف أنقذنا Terraform من جحيم “لقد كانت تعمل على جهازي”؟

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

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

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

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

ما هي “البنية التحتية كشيفرة” (Infrastructure as Code)؟

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

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

فوائد هذا النهج؟

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

لماذا Terraform بالذات؟ “الختيار” الذي حسم الأمر

يوجد العديد من الأدوات في ساحة الـ IaC، لكن Terraform من شركة HashiCorp كان له نكهة خاصة جعلتنا نختاره. هو ليس مجرد أداة، بل فلسفة عمل متكاملة.

فلسفة Terraform تقوم على “الحالة الوصفية” (Declarative State). أنت لا تأمره خطوة بخطوة (Imperative)، بل تصف له النتيجة النهائية التي تريدها: “بدي سيرفر بهاي المواصفات، وقاعدة بيانات من هذا النوع، مربوطين ببعض بهالشكل”. وهو “بدبر حاله” لمعرفة كيفية الوصول لهذه النتيجة بأفضل طريقة.

أهم مميزات Terraform:

• محايد تجاه السحابة (Cloud-Agnostic): هذه كانت ميزة قاتلة. يمكن لـ Terraform التعامل مع AWS, Azure, Google Cloud, DigitalOcean وغيرها الكثير بنفس الطريقة ونفس اللغة (HCL). هذا يعطيك حرية ومرونة لا تقدر بثمن.
• خطة التنفيذ (Execution Plan): قبل تطبيق أي تغيير، يقوم أمر terraform plan بعرض تقرير مفصل يخبرك بالضبط بما سيتم إنشاؤه، تعديله، أو حذفه. هذه الميزة وحدها كانت كفيلة بمنع كارثة ليلة الخميس تلك. لا مفاجآت بعد اليوم!
• إدارة الحالة (State Management): يحتفظ Terraform بملف خاص (state file) يسجل فيه كل الموارد التي قام بإنشائها. هذا الملف هو “ذاكرة” Terraform، ويعرف من خلاله الوضع الحالي للبنية التحتية لكي يقرر التغييرات اللازمة في المرة القادمة.

من النقر العشوائي إلى الشيفرة المنظمة: خطواتنا الأولى

كان الانتقال تجربة ممتعة ومفيدة. سأشارككم خريطة الطريق التي اتبعناها.

1. تجهيز العدة والشاي (التنصيب والإعداد)

الخطوة الأولى كانت بسيطة: تنزيل Terraform من موقعه الرسمي. هو مجرد ملف تنفيذي واحد، لا يحتاج لتثبيت معقد. ثم قمنا بإعداد مفاتيح الوصول الخاصة بمزود السحابة (AWS في حالتنا) كمتغيرات بيئة (Environment Variables) على أجهزتنا. هذه خطوة أمنية مهمة.

نصيحة أبو عمر: إياك ثم إياك أن تضع مفاتيح الوصول السرية (Access Keys) داخل الكود مباشرة. استخدم متغيرات البيئة أو أدوات إدارة الأسرار المخصصة.

2. كتابة أول “وصفة” (ملف main.tf)

قمنا بإنشاء مجلد جديد، وبداخله ملف واحد باسم main.tf. هذا الملف يحتوي على وصفتنا لإنشاء سيرفر بسيط من نوع EC2 على AWS. كان الكود يشبه هذا:

# 1. تحديد مزود الخدمة السحابية والمنطقة
provider "aws" {
  region = "eu-central-1" # منطقة فرانكفورت
}

# 2. وصف المورد الذي نريد إنشاءه (سيرفر EC2)
resource "aws_instance" "web_server" {
  # نوع "الآلة الافتراضية" - هذه من النسخ المجانية
  ami           = "ami-04e601abe3e1a060c" 
  instance_type = "t2.micro"

  # إضافة "وسم" أو "تاغ" لتمييز السيرفر
  tags = {
    Name = "WebServer-From-Terraform"
  }
}

الكود واضح ومقروء حتى لغير المبرمجين. يصف ببساطة أننا نريد “موردًا” من نوع “aws_instance” بمواصفات معينة.

3. دورة حياة Terraform السحرية

هنا يأتي الجزء العملي والممتع. داخل المجلد الذي يحتوي على ملف main.tf، قمنا بتنفيذ ثلاثة أوامر غيرت طريقة عملنا للأبد:

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

وبعد دقائق، كان السيرفر الجديد يعمل في حسابنا على AWS، مع الوسم الذي حددناه، وبالمواصفات الدقيقة التي كتبناها في الكود. ولو أردنا حذفه، فالأمر بسيط: terraform destroy.

نصائح أبو عمر الذهبية من قلب الميدان

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

• لا تلمس ملف الحالة بيدك (state file): ملف terraform.tfstate هو بمثابة الصندوق الأسود للطائرة. لا تحاول تعديله يدويًا أبدًا. للعمل كفريق، استخدم “الواجهة الخلفية البعيدة” (Remote Backend) مثل Amazon S3 لتخزين هذا الملف مركزيًا، مما يمنع التعارضات ويسمح بقفله أثناء التنفيذ.
• جزّئ ولا تسُد (استخدم الوحدات – Modules): كما في البرمجة، لا تكتب كل شيء في ملف واحد ضخم. قسم بنيتك التحتية إلى وحدات منطقية قابلة لإعادة الاستخدام (وحدة للشبكة، وحدة للسيرفرات، وحدة لقاعدة البيانات). هذا يجعل الكود أنظف وأسهل في الإدارة والتطوير. “مش كل طبخة بدك تخترع العجلة من أول وجديد”.
• اجعل الكود مرنًا بالمتغيرات (Variables): بدلًا من تثبيت القيم (مثل نوع السيرفر t2.micro) في الكود، استخدم متغيرات. هذا يسمح لك بإعادة استخدام نفس الكود لإنشاء بيئات مختلفة (مثلاً، سيرفر صغير للتطوير وسيرفر كبير للإنتاج) فقط عن طريق تمرير قيم مختلفة للمتغيرات.
• الأتمتة الكاملة مع CI/CD: ادمج Terraform في مسار التكامل والنشر المستمر (CI/CD). الإعداد المثالي: عند فتح Pull Request لتغيير في كود Terraform، يتم تشغيل terraform plan تلقائيًا وتُضاف الخطة كتعليق على الـ PR. وبعد دمج الـ PR في الفرع الرئيسي، يتم تشغيل terraform apply تلقائيًا لتنفيذ التغييرات. هذا هو قمة الأتمتة والأمان.

الخلاصة: من الخوف إلى الثقة ✅

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

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