كانت بيئاتنا نسخاً مشوهة: كيف أنقذتنا ‘البنية التحتية كوداً’ (IaC) من جحيم ‘لكنها تعمل على جهازي’؟

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

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

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

ما قبل الـ IaC: جحيم الإعدادات اليدوية و”البيئات المسكونة”

قبل أن ندخل في الحل، دعونا نعترف بالمشكلة التي عشناها جميعاً. الطريقة التقليدية لإدارة البنية التحتية كانت أشبه بالعمل في ورشة فوضوية. كنت تفتح لوحة تحكم AWS أو Azure أو Google Cloud، وتبدأ بالضغط على الأزرار لإنشاء سيرفر جديد، ثم تتصل به عبر SSH، وتقوم بتثبيت الحزم يدوياً بالأمر apt-get install أو yum install، وتعدّل ملفات الإعدادات واحداً تلو الآخر.

هذه الطريقة، التي نسميها “ClickOps”، كانت مصدراً لمشاكل لا تنتهي:

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

البنية التحتية كوداً (IaC): المفهوم السحري الذي غيّر اللعبة

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

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

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

Terraform: كيف نترجم البنية التحتية إلى أسطر من الكود؟

Terraform هي أشهر أداة IaC تصريحية اليوم، وهي الأداة التي اعتمدناها لإنقاذنا. تسمح لك بوصف مكونات البنية التحتية الخاصة بك بلغة بسيطة وواضحة تسمى HCL (HashiCorp Configuration Language).

المثال الأول: “أهلاً بالعالم” في عالم الـ IaC

لنفترض أننا نريد إنشاء سيرفر ويب بسيط (EC2 instance) على AWS. بدلاً من الدخول إلى لوحة تحكم AWS والضغط على 20 زراً، سنكتب ملفاً بسيطاً اسمه main.tf:

# 1. تحديد مزود الخدمة السحابية (AWS) وإصداره
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

# 2. إعداد معلومات الاتصال بمزود الخدمة (مثل المنطقة)
provider "aws" {
  region = "us-east-1"
}

# 3. وصف المورد الذي نريد إنشاءه: سيرفر EC2
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
  instance_type = "t2.micro"             # نوع السيرفر (حجمه وقدرته)

  tags = {
    Name = "MyFirstWebServer"
  }
}

هذا كل شيء! هذا الكود هو الوصف الكامل للسيرفر. الآن، كل ما علينا فعله هو تشغيل ثلاثة أوامر بسيطة في الطرفية (Terminal):

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

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

نصيحة أبو عمر: لا تكرر نفسك واستخدم المتغيرات والوحدات (Modules)

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

يمكننا تعديل الكود السابق ليصبح أكثر مرونة:

# ملف variables.tf
variable "instance_type" {
  description = "The type of EC2 instance to launch"
  type        = string
  default     = "t2.micro"
}

# ملف main.tf (معدّل)
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type # استخدام المتغير هنا

  tags = {
    Name = "MyWebServer"
  }
}

الآن، يمكننا تطبيق نفس الكود على بيئات مختلفة، فقط بتمرير قيمة مختلفة للمتغير. على سبيل المثال:

• لتطبيق بيئة الاختبار (صغيرة): terraform apply -var="instance_type=t2.micro"
• لتطبيق البيئة الإنتاجية (كبيرة): terraform apply -var="instance_type=m5.large"

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

الفوائد الحقيقية على أرض الواقع: ما الذي كسبناه؟

بعد تبني IaC وتحديداً Terraform، تغيرت طريقة عملنا بالكامل. لم تعد عمليات النشر مصدراً للرعب:

• السرعة والثقة: أصبحنا ننشئ بيئات اختبار كاملة ومعقدة لأي فرع جديد في Git خلال دقائق، ونتخلص منها بنفس السرعة. هذا سمح للمطورين باختبار أعمالهم في بيئة معزولة وشبيهة بالإنتاج تماماً.
• الشفافية والتعاون: أصبحت البنية التحتية في مستودع Git. أي تغيير يجب أن يمر عبر Pull Request، مما يعني أن الفريق كله يمكنه مراجعة التغيير والموافقة عليه قبل تطبيقه. لا مزيد من التعديلات الغامضة في منتصف الليل.
• التحكم في الإصدارات: هل سبب تحديث جديد مشكلة؟ لا بأس. تماماً كما تفعل git revert للكود، يمكنك العودة إلى إصدار سابق من كود البنية التحتية وإعادة تطبيق الحالة المستقرة.
• أتمتة كاملة (DevOps): أصبح كود البنية التحتية جزءاً من مسار CI/CD. عندما يتم دمج كود جديد للتطبيق، يمكن للنظام أن يقوم تلقائياً بتحديث البنية التحتية اللازمة له.

الخلاصة: من الفوضى إلى النظام بفضل الكود 🚀

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

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