إعداداتنا كانت تتغير من تلقاء نفسها: كيف أنقذتنا ‘البنية التحتية كشيفرة’ (IaC) من جحيم الانحراف التكويني؟

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

خلوني أحكي لكم قصة صارت معي قبل كم سنة، قصة علمتني درس ما بنساه طول عمري. كانت ليلة ثلاثاء، الساعة تقريبًا 2 بعد منتصف الليل، والتلفون برن… على الطرف الثاني كان صوت مهندس شاب في فريقي، صوته كله توتر: “أبو عمر، الحقنا! خدمة الدفع الرئيسية واقعة!”.

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

شو القصة؟ حدا، بطريقة ما، غيّر صلاحية وصول (permission) على مستوى قاعدة البيانات الفرعية اللي بتستخدمها الخدمة. تغيير بسيط، سطر واحد في إعدادات السيرفر، لكنه كان كفيل بإنه يوقف كل عمليات الدفع. السؤال اللي حيّرنا كلنا: مين غيرها؟ ومتى؟ وليش؟ بعد تحقيق طويل، اكتشفنا إنه مهندس ثاني كان بحاول يحل مشكلة ثانية على سيرفر ثاني، وبطريق الخطأ طبّق التغيير على السيرفر الغلط. خطأ بشري بسيط، لكنه كلفنا كثير.

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

ما هو “الانحراف التكويني” (Configuration Drift)؟ شبح السيرفرات الصامت

المشكلة اللي واجهناها هذيك الليلة لها اسم تقني معروف: الانحراف التكويني (Configuration Drift).

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

أسباب الانحراف التكويني الشائعة:

• الإصلاحات العاجلة (Hotfixes): لما تصير مشكلة طارئة، أول إشي بنعمله هو الدخول على السيرفر مباشرةً وتغيير الإعدادات يدويًا لحل المشكلة بسرعة. وغالبًا ما ننسى توثيق هذا التغيير.
• التغييرات اليدوية غير الموثقة: مهندس بحاجة يفتح بورت (Port) معين بشكل مؤقت لتجربة شيء ما، وينسى يسكره.
• فرق عمل متعددة: كل فريق أو شخص له طريقته في العمل، مما يؤدي إلى عدم تناسق في الإعدادات بين السيرفرات المختلفة التي من المفترض أن تكون متطابقة.
• غياب مصدر الحقيقة الواحد (Single Source of Truth): عندما لا يكون هناك مكان مركزي وموثوق يصف كيف يجب أن تكون البنية التحتية، يصبح كل سيرفر “جزيرة” قائمة بذاتها.

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

البنية التحتية كشيفرة (IaC): الحل السحري والمنظّم

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

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

لماذا IaC هي الحل؟

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

Terraform: مطرقتنا الفعالة في عالم الـ IaC

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

Terraform هي أداة مفتوحة المصدر تسمح لك بتعريف البنية التحتية باستخدام لغة تعريفية بسيطة وسهلة القراءة تسمى HCL (HashiCorp Configuration Language). جمال Terraform يكمن في أنها “agnostic” أي أنها لا تنتمي لمزود خدمة سحابية معين، بل تدعم معظم المزودين الكبار مثل AWS, Azure, Google Cloud، وحتى البيئات المحلية (On-premise).

مثال عملي: لنبني سيرفرًا صغيرًا باستخدام Terraform

لنفترض أننا نريد إنشاء سيرفر ويب بسيط (Virtual Machine) على أحد مزودي الخدمات السحابية. بدلًا من الدخول للوحة التحكم والنقر على عشرات الأزرار، سنكتب ملفًا بسيطًا اسمه main.tf.

ملاحظة: هذا المثال للتوضيح، وهو يستخدم مزود AWS كمثال، لكن المبدأ يطبق على أي مزود آخر.

# main.tf

# 1. تحديد مزود الخدمة السحابية الذي سنعمل عليه
provider "aws" {
  region = "eu-west-1" # مثال: منطقة أيرلندا
}

# 2. تعريف "مجموعة أمان" للسماح بالاتصالات
# هذا بمثابة جدار ناري (Firewall) بسيط
resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTP and SSH traffic"

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

  # السماح بالوصول عبر بروتوكول SSH (للإدارة)
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["YOUR_IP_ADDRESS/32"] # استبدل هذا بالـ IP الخاص بك للأمان
  }
}

# 3. تعريف السيرفر نفسه (EC2 Instance)
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0" # مثال: Amazon Linux 2 AMI
  instance_type = "t2.micro"             # حجم السيرفر (صغير ومناسب للتجارب)
  
  # ربط السيرفر بمجموعة الأمان التي أنشأناها
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  # إضافة وسم (Tag) لسهولة التعرف على السيرفر
  tags = {
    Name = "MyFirstWebServer-Terraform"
  }
}

دورة حياة Terraform: الخطة ثم التنفيذ

بعد كتابة الكود، العملية بسيطة وتتكون من 3 خطوات رئيسية:

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

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

نصائح من خبرة أبو عمر

بعد سنوات من استخدام IaC و Terraform، هذه بعض النصائح العملية التي أود مشاركتها معكم:

• ابدأ صغيرًا ولكن ابدأ الآن: لا تحاول تحويل كل بنيتك التحتية إلى كود في يوم واحد. اختر مكونًا صغيرًا غير حرج، مثل سيرفر تطوير، وحاول بناءه باستخدام Terraform. مع الوقت، ستكتسب الثقة وتتوسع.
• ملف الحالة (State File) مقدس: يقوم Terraform بحفظ حالة البنية التحتية في ملف يسمى terraform.tfstate. هذا الملف بالغ الأهمية. يجب أن تقوم بتخزينه في مكان آمن ومشترك (مثل AWS S3 Bucket أو Azure Storage Account)، وليس على جهازك المحلي.
• لا تكرر نفسك: استخدم الوحدات (Modules): إذا كنت تبني نفس النوع من السيرفرات مرارًا وتكرارًا، قم بإنشاء “وحدة” (Module) قابلة لإعادة الاستخدام. هذا يجعل الكود أنظف وأسهل في الصيانة.
• اجعل IaC جزءًا من الـ CI/CD Pipeline: أفضل ممارسة هي أتمتة عملية الـ `plan` و `apply` من خلال أدوات التكامل والنشر المستمر مثل Jenkins أو GitLab CI. هذا يضمن أن أي تغيير يمر بعملية مراجعة واختبار آلية قبل تطبيقه.

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

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

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