كانت بنيتنا التحتية قصراً من رمال: كيف أنقذتنا “البنية التحتية ككود” (IaC) من جحيم البيئات المتضاربة؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.

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

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

بعد ساعات من البحث والتحليل والضغط النفسي، اكتشفنا المصيبة: بيئة الإنتاج كانت مختلفة تمامًا عن بيئة الاختبار. نسخة قاعدة البيانات أقدم، بعض المنافذ (Ports) في جدار الحماية (Firewall) كانت مغلقة، متغيرات البيئة (Environment Variables) ناقصة. كل هاي التعديلات اليدوية اللي عملها زميل إلنا قبل أشهر “بشكل سريع” عشان يحل مشكلة مؤقتة، ونسي يوثقها أو يطبقها على باقي البيئات. بنيتنا التحتية كانت حرفيًا قصرًا من رمال، كل واحد ببني فيه على كيفه، ومع أول موجة… انهار كل شيء.

تلك الليلة كانت جحيم، لكنها كانت أيضًا نقطة تحول. قررنا إنه “خلص، بكفي!”. ومن هنا بدأت رحلتنا مع مفهوم غيّر طريقة عملنا بالكامل: البنية التحتية ككود (Infrastructure as Code – IaC).

ما هي مشكلة “البيئات غير المتطابقة”؟

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

أسبابها كثيرة، وأشهرها:

• التعديلات اليدوية (ClickOps): كل مرة بتدخل على لوحة تحكم AWS أو Azure أو Google Cloud وبتعمل تغيير “بإيدك” بدون توثيق أو أتمتة، أنت بتزرع بذرة كارثة مستقبلية.
• غياب مصدر الحقيقة الواحد: لا يوجد مكان مركزي وموثوق يصف كيف يجب أن تكون البنية التحتية. الحقيقة موزعة في رؤوس الموظفين والمستندات المنسية.
• صعوبة التكرار: هل يمكنك إعادة بناء بيئة الإنتاج بالكامل من الصفر خلال ساعة في حال حدوث كارثة؟ إذا كانت إجابتك “لا”، فأنت في ورطة.

“البنية التحتية التي تُدار يدويًا هي ديون تقنية تنتظر اللحظة المناسبة لتفلس مشروعك.” – أبو عمر

البنية التحتية ككود (IaC): الحل الجذري

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

ليش IaC هي المنقذ؟

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

أشهر الأدوات: Terraform هي أداة الساحر

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

ليش Terraform بالذات؟

• محايدة للسحابة (Cloud Agnostic): تدعم معظم مزودي الخدمات السحابية (AWS, Azure, GCP) وغيرهم الكثير. تتعلمها مرة وتستخدمها في كل مكان.
• لغة تعريفية (Declarative): أنت تصف “ماذا” تريد (أريد خادمًا بهذه المواصفات)، وTerraform تتكفل بـ “كيفية” تحقيق ذلك.
• خطة التنفيذ (Execution Plan): قبل تطبيق أي تغيير، يعرض عليك Terraform خطة مفصلة بما سيتم إنشاؤه أو تعديله أو حذفه. هذه الميزة وحدها تمنع كوارث لا حصر لها.
• إدارة الحالة (State Management): تحتفظ Terraform بملف “حالة” (State) يربط الموارد في الكود بالموارد الحقيقية في السحابة. هذا هو عقلها المدبر.

يلا نكتب كود: بناء أول خادم ويب بـ Terraform

حكينا كثير، وهسا إجا وقت الشغل. لنفترض أننا نريد بناء خادم ويب بسيط على AWS (EC2 Instance) يسمح بالوصول عبر بروتوكول HTTP.

هذا ما سيبدو عليه الكود باستخدام Terraform (لغة HCL):

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

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

# 3. إنشاء مجموعة أمان (Security Group) للسماح بالوصول
# هذا هو جدار الحماية المصغر للخادم
resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTP inbound traffic"

  # قاعدة للسماح بالوصول من أي مكان عبر بروتوكول HTTP (Port 80)
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # قاعدة للسماح بكل الترافيك الصادر
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "WebServerSG"
  }
}

# 4. إنشاء الخادم (EC2 Instance) وربطه بمجموعة الأمان
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
  instance_type = "t2.micro"            # نوع الخادم (Free Tier)
  
  # ربط الخادم بمجموعة الأمان التي أنشأناها
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  tags = {
    Name = "MyWebServer"
  }
}

لتحويل هذا الكود إلى بنية تحتية حقيقية، كل ما عليك فعله هو تشغيل ثلاثة أوامر:

1. terraform init: لتحميل الـ provider الخاص بـ AWS.
2. terraform plan: لعرض خطة التنفيذ (ماذا سيفعل Terraform).
3. terraform apply: لتنفيذ الخطة وإنشاء الموارد.

وهيك، صار عندك بنية تحتية موثقة، قابلة للتكرار، ومحفوظة في Git. لو بدك تعمل 100 خادم بنفس المواصفات، بتغير سطر واحد في الكود. ولو بدك تدمر كل شي عشان توفر مصاريف، بتستخدم أمر terraform destroy.

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

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

1. إياك والتعامل مع ملف الحالة (State File) يدويًا

ملف terraform.tfstate هو روح Terraform. لا تعدله يدويًا أبدًا، ولا تحفظه على جهازك المحلي في المشاريع الحقيقية. استخدم Backend Remotes مثل Amazon S3 أو Terraform Cloud. هذا يسمح للفريق بالعمل معًا ويوفر قفلًا (Locking) لمنع شخصين من تطبيق التغييرات في نفس الوقت.

2. قسّم عملك إلى وحدات (Modules)

لا تكتب كل شي في ملف main.tf واحد. عندما يكبر مشروعك، قسّم البنية التحتية إلى وحدات منطقية قابلة لإعادة الاستخدام (مثلاً: وحدة للشبكة، وحدة للخوادم، وحدة لقاعدة البيانات). هذا يسهل الصيانة والتطوير.

3. استخدم متغيرات لكل شيء

لا تضع قيمًا ثابتة (Hardcoded values) في الكود، مثل أسماء المناطق أو أنواع الخوادم. استخدم ملفات المتغيرات (variables.tf و .tfvars). هذا يجعل الكود مرنًا وقابلًا لإعادة الاستخدام في بيئات مختلفة بسهولة.

4. ادمج IaC في مسار CI/CD الخاص بك

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

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

العودة إلى تلك الليلة الكارثية، لو كانت بنيتنا التحتية مُعرفة ككود، لكانت القصة مختلفة تمامًا. كنا سنكتشف عدم التطابق في مرحلة الـ plan. كنا سننشر نفس الكود الموثوق على الإنتاج بثقة تامة. كنا سننام في بيوتنا بدلاً من قضاء ليلة بيضاء في المكتب.

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

نصيحتي لك: لا تنتظر وقوع الكارثة. ابدأ اليوم. ابدأ بمشروع صغير، تعلم الأساسيات، وجرّب. قد تكون الرحلة صعبة في البداية، لكنها استثمار سيؤتي ثماره أضعافًا مضاعفة في المستقبل. بالتوفيق يا جماعة! 💪