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

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

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

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

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

ما هو “شبح البيئة التجريبية”؟ ولماذا هو كابوس المطورين؟

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

تخيل أن البنية التحتية لتطبيقك هي وصفة طبخ معقدة. في البداية، الكل يتبع نفس الوصفة. لكن مع الوقت، يأتي أحدهم ويضيف “رشة ملح” هنا لإصلاح مشكلة عاجلة (Hotfix) ولا يوثقها. ويأتي آخر ويغير درجة حرارة الفرن قليلاً عبر الواجهة الرسومية لمزوّد الخدمة السحابية (AWS, Azure, GCP) وينسى أن يخبر أحداً. بعد أشهر، تصبح لديك ثلاث “طبخات” مختلفة تماماً، مع أن الوصفة الأصلية واحدة. هذا بالزبط ما يحدث لخوادمنا وقواعد بياناتنا وشبكاتنا.

الأسباب الشائعة لظهور هذا الشبح:

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

– التحديثات غير المتزامنة: تحديث نسخة قاعدة البيانات في بيئة التطوير دون تحديثها في البيئة التجريبية.

– غياب مصدر الحقيقة الواحد: لا يوجد مكان مركزي وموثوق يصف كيف يجب أن تبدو البنية التحتية.

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

المنقذ: البنية التحتية كشيفرة (Infrastructure as Code – IaC)

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

ما هي الـ IaC ببساطة؟

بدلاً من الدخول إلى لوحة تحكم AWS أو Azure والبدء في النقر على الأزرار لإنشاء خادم جديد أو قاعدة بيانات، أنت تقوم بكتابة ملف نصي (شيفرة/كود) يصف كل مكونات بنيتك التحتية والإعدادات الخاصة بها. هذا الملف يصبح هو “المصدر الوحيد للحقيقة” (Single Source of Truth). تريد خادماً جديداً؟ أضف بضعة أسطر إلى الكود. تريد تغيير حجم قاعدة البيانات؟ عدّل سطراً واحداً في الكود.

“الـ IaC تحوّل البنية التحتية من عمل يدوي فني غامض إلى عملية هندسية دقيقة، موثقة، وقابلة للتكرار.” – أبو عمر

لماذا هي الحل الجذري لمشكلة “بتشتغل عندي”؟

• الاتساق (Consistency): نفس الكود سينشئ بيئة تطوير وبيئة تجريبية وبيئة إنتاج متطابقة 100%. وداعاً لـ “انحراف التكوين”.
• إدارة الإصدارات (Version Control): يمكنك تخزين كود البنية التحتية في نظام Git مثل كود تطبيقك تماماً. هذا يعني أنك تستطيع رؤية تاريخ كل تغيير: من غيّر ماذا، متى، ولماذا. هل التحديث الأخير سبب مشكلة؟ بكل بساطة، يمكنك العودة إلى الإصدار السابق والمستقر.
• الأتمتة والسرعة (Automation & Speed): يمكنك إنشاء بيئة كاملة ومعقدة من الصفر خلال دقائق بمجرد تنفيذ أمر واحد. كما يمكنك تدميرها بنفس السهولة لتوفير التكاليف (مثلاً، بيئة خاصة لاختبار فرع برمجي معين).
• المراجعة والتعاون (Review & Collaboration): يمكن للمطورين الآن مراجعة تغييرات البنية التحتية من خلال طلبات السحب (Pull Requests) تماماً مثل الكود. هذا يكسر الحواجز بين فرق التطوير (Dev) والعمليات (Ops) ويعزز ثقافة الـ DevOps.

لنكن عمليين: تعرف على Terraform، مطرقة ثور في عالم الـ DevOps

هناك العديد من الأدوات الرائعة لتطبيق الـ IaC مثل AWS CloudFormation و Azure Bicep و Pulumi. لكن الأداة التي أفضلها شخصياً وأستخدمها في معظم المشاريع هي Terraform من شركة HashiCorp، وذلك لأنها “agnostic” أي أنها لا تنتمي لمزود خدمة سحابية معين، ويمكنها التعامل مع AWS, GCP, Azure وغيرها الكثير بنفس الطريقة.

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

لنفترض أننا نريد إنشاء خادم ويب بسيط (EC2 Instance) على AWS. بدلاً من 15 نقرة في واجهة AWS، يمكننا كتابة ملف بسيط اسمه main.tf:

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

provider "aws" {
  region = "us-east-1" # منطقة شرق الولايات المتحدة
}

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

  tags = {
    Name = "MyWebServer-Prod" # اسم الخادم ليظهر في واجهة AWS
  }
}

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

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

وإذا أردت حذف هذا الخادم بعد الانتهاء منه لتوفير المال، كل ما عليك هو تنفيذ أمر واحد: terraform destroy.

نصائح من مطبخ أبو عمر: كيف تتبنى الـ IaC بنجاح؟

الانتقال إلى الـ IaC رحلة ممتعة ومجزية، ولكنها تحتاج لبعض التخطيط. إليك بعض النصائح من خبرتي الشخصية:

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

لا تحاول تحويل كل بنيتك التحتية القديمة إلى كود في يوم وليلة. ابدأ بمشروع جديد، أو بمكون صغير ومنعزل من مشروع قائم. مثلاً، ابدأ بكتابة كود لإدارة إعدادات الـ DNS أو S3 Buckets. عندما تكتسب الثقة، توسع تدريجياً.

لا تكرر نفسك (Don’t Repeat Yourself – DRY)

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

خزّن “الحالة” عن بعد وبشكل آمن (Store Your State Remotely)

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

الأسرار ليست للنشر! (Secrets are Secrets)

إياك ثم إياك أن تكتب كلمات المرور أو مفاتيح الـ API أو أي معلومات حساسة أخرى بشكل مباشر في كود الـ IaC. هذا الكود سيتم تخزينه في Git وقد يراه الكثيرون. استخدم أدوات إدارة الأسرار مثل AWS Secrets Manager أو HashiCorp Vault، وقم باستدعاء هذه الأسرار ديناميكياً عند الحاجة.

الخلاصة: وداعاً للأشباح، ومرحباً بالثقة والسرعة 👻✌️

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

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