كانت بيئاتنا غير متطابقة: كيف أنقذنا “الكود كبنية تحتية” (IaC) من جحيم “لكنه يعمل على جهازي”؟

يا جماعة الخير، مسّاكم الله بالخير. اسمحوا لي اليوم أحكي لكم قصة صارت معي ومع فريقي قبل كم سنة، قصة من هذيك القصص اللي بتعلّمك درس ما بتنساه طول عمرك. كنّا سهرانين في المكتب، الساعة كانت داخلة على 2 بعد نص الليل، بنجهز لإطلاق تحديث كبير لتطبيق مهم لأحد العملاء. القهوة ما عادت تجيب نتيجة، والتوتر سيّد الموقف.

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

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

بعد ليلة طويلة من البحث والتنقيب، اكتشفنا المشكلة: إصدار مكتبة صغيرة (library) على خوادم الإنتاج كان أقدم من الإصدار اللي استخدمناه في التطوير. فرق بسيط، لكنه كان كافياً ليعمل كل هاي “العجقة”. يومها، قررت أن هذا الوضع لا يمكن أن يستمر. ومن هنا بدأت رحلتنا مع ما يُعرف بـ “الكود كبنية تحتية” أو Infrastructure as Code (IaC).

ما هي مشكلة “لكنه يعمل على جهازي”؟

قبل ما ندخل في الحل، خلينا نفصّل المشكلة الأساسية. المشكلة اللي واجهناها، واللي بتواجهها آلاف الفرق البرمجية كل يوم، اسمها التقني هو “انحراف البيئات” (Environment Drift). ببساطة، مع مرور الوقت، تصبح بيئة التطوير وبيئة الاختبار وبيئة الإنتاج مختلفة عن بعضها البعض بشكل خفي وتدريجي.

هذا الانحراف يحدث لعدة أسباب، كلها تتعلق بالطريقة اليدوية التقليدية في إدارة البنية التحتية:

• الإعداد اليدوي: قيام مسؤول الأنظمة (SysAdmin) بالدخول على لوحة تحكم مزود الخدمة السحابية (مثل AWS, Azure) والضغط على الأزرار لإنشاء خادم جديد.
• التحديثات اليدوية: الدخول عبر SSH على الخادم لتثبيت حزمة، أو تحديث برنامج، أو تغيير إعداد بسيط “على السريع” لحل مشكلة طارئة.
• غياب التوثيق: من يتذكر كل تغيير يدوي تم على خادم يعمل منذ ثلاث سنوات؟ لا أحد. التوثيق يصبح قديماً وغير دقيق بسرعة.

هذه الفوضى اليدوية هي الوصفة المثالية لكوارث النشر، وساعات العمل الضائعة في تصحيح الأخطاء، والثغرات الأمنية التي لا يلاحظها أحد.

الحل السحري: الكود كبنية تحتية (Infrastructure as Code – IaC)

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

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

ببساطة، الـ IaC يعامل البنية التحتية بنفس الطريقة التي نعامل بها كود التطبيق.

لماذا يجب أن تهتم بـ IaC؟

التحول إلى IaC ليس مجرد موضة تقنية، بل هو ضرورة حتمية لأي فريق يريد أن يكون فعالاً ومحترفاً. وهذه أهم الفوائد:

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

أشهر الأدوات في عالم الـ IaC: نظرة على Terraform

هناك العديد من الأدوات في هذا المجال مثل AWS CloudFormation, Azure Resource Manager, Ansible, وغيرها. لكن الأداة التي أصبحت معياراً في السوق، والتي أنصح بها بشدة، هي Terraform من شركة HashiCorp.

لماذا Terraform؟

• غير مرتبط بمزوّد سحابي معين (Cloud-Agnostic): يمكنك استخدامه لإدارة البنية التحتية على AWS, Azure, Google Cloud, وغيرها الكثير بنفس الطريقة.
• لغة تعريفية (Declarative Syntax): أنت تصف “الحالة النهائية” التي تريد أن تكون عليها البنية التحتية، وTerraform يتكفل بمعرفة كيفية الوصول إليها. أنت لا تكتب “كيف” بل “ماذا”.
• مجتمع ضخم ودعم قوي: ستجد حلولاً ومكتبات جاهزة لأي شيء يخطر ببالك تقريباً.

مثال عملي بسيط: لنبني خادم ويب باستخدام Terraform

لتقريب الصورة، دعنا نرى كيف يمكننا إنشاء خادم ويب بسيط (EC2 instance) على Amazon Web Services (AWS) باستخدام Terraform. لا تقلق إذا لم تفهم كل شيء، المهم هو أن تستوعب الفكرة العامة.

أولاً، ننشئ ملفاً باسم main.tf ونكتب فيه الكود التالي:

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

# تعريف متغير لصورة النظام (AMI)
variable "ami_id" {
  type    = string
  default = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI in us-east-1
  description = "The AMI ID for the EC2 instance."
}

# تعريف متغير لنوع الخادم
variable "instance_type" {
  type    = string
  default = "t2.micro"
  description = "The type of EC2 instance."
}

# هذا هو "المورد" الذي نريد إنشاءه: خادم EC2
resource "aws_instance" "web_server" {
  ami           = var.ami_id
  instance_type = var.instance_type

  # سكربت بسيط يتم تشغيله عند بدء تشغيل الخادم لأول مرة
  # لتثبيت خادم ويب Apache وعرض صفحة بسيطة
  user_data = <<EOF
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>مرحباً من خادمي الذي بناه Terraform!</h1>" > /var/www/html/index.html
EOF

  # إضافة "وسم" للخادم لتسهيل التعرف عليه
  tags = {
    Name = "WebServer-Terraform-Demo"
  }
}

# إخراج عنوان IP العام للخادم بعد إنشائه
output "instance_public_ip" {
  value = aws_instance.web_server.public_ip
  description = "The public IP address of the web server."
}

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

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

ببساطة، هذا الكود القصير هو وثيقتك ووصفتك لإنشاء خادم ويب. يمكنك الآن أخذ هذا الملف وتشغيله في أي حساب AWS لإنشاء نفس الخادم بالضبط، مرة تلو الأخرى.

نصائح من خبرة أبو عمر لتطبيق IaC بنجاح

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

ابدأ صغيراً (Start Small)

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

اجعل الكود معيارياً وقابلاً لإعادة الاستخدام (Use Modules)

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

خزّن “الحالة” عن بعد (Store State Remotely)

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

لا تضع الأسرار في الكود! (Don’t Hardcode Secrets)

إياك ثم إياك أن تكتب كلمات المرور، أو مفاتيح الـ API، أو أي معلومات حساسة مباشرة في كود Terraform. هذا الكود سيتم تخزينه في Git وسيكون مكشوفاً. استخدم أدوات إدارة الأسرار مثل HashiCorp Vault، أو AWS Secrets Manager، أو متغيرات البيئة (Environment Variables) لتمرير هذه المعلومات الحساسة بأمان وقت التشغيل.

اجعل مراجعة كود البنية التحتية جزءاً من ثقافتك (Make IaC Reviews Part of Your Culture)

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

الخلاصة: من الفوضى إلى الأتمتة

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

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

نصيحتي لك: لا تنتظر حتى تقع الكارثة. ابدأ اليوم في تعلم وتطبيق مبادئ الكود كبنية تحتية. الاستثمار المبدئي في الوقت والجهد سيعود عليك براحة بال، وكفاءة، وثقة لا تقدر بثمن في المستقبل. صدقني، أبو عمر ما بنصحك إلا باللي فيه مصلحتك. 😉