أذكرها وكأنها البارحة، ليلة شتاء باردة، والساعة تقترب من الثانية صباحاً. كنا في خضم إطلاق ميزة جديدة ومهمة في نظامنا، وفجأة، انهار أحد السيرفرات الرئيسية في بيئة الإنتاج (Production). لا مشكلة، فكرت في نفسي، “عادي بتصير”، لدينا سكربتاتنا الآلية وصور الأنظمة الجاهزة (Golden Images) لإعادة بناء السيرفر في دقائق.
لكن الدقائق تحولت إلى ساعة، ثم ساعتين. كلما حاولنا تشغيل السيرفر الجديد، كان يفشل في مرحلة معينة. التطبيق لا يعمل، خدمات معينة لا تستجيب، شيء ما كان خاطئاً بشكل جذري. الأدهى من ذلك، أن السيرفر الجديد كان “نظرياً” مطابقاً تماماً للسيرفر القديم الذي كان يعمل قبل دقائق من انهياره.
بعد ساعات من البحث والتدقيق وشرب أكواب لا تنتهي من القهوة، اكتشفنا الكارثة. قبل ثلاثة أشهر، قام أحد المطورين الجدد – خلينا نسميه سامر – بعمل تعديل يدوي “سريع” على السيرفر مباشرةً لحل مشكلة توافق في إحدى المكتبات. تغيير بسيط، لم يستغرق منه خمس دقائق، وبالطبع، لم يوثّقه في أي مكان ولم يقم بتحديث السكربتات أو الصورة الأساسية. هذا التعديل الصغير المنسي كان هو سبب فشلنا الذريع في تلك الليلة. لقد كنا ضحايا لما يُعرف في عالمنا بـ “جحيم الانحراف التكويني” أو الـ Configuration Drift.
ما هو “الانحراف التكويني” (Configuration Drift)؟ وليش هو كابوس كل مهندس DevOps؟
ببساطة يا جماعة الخير، الانحراف التكويني هو لما تصير البنية التحتية الحية عندك (Live Infrastructure) مختلفة عن التكوين الأصلي الموثق أو المكتوب في السكربتات. تخيل أنك بنيت بيتاً بناءً على مخطط هندسي دقيق، ومع مرور الوقت، يأتي كل فرد من العائلة ويضيف نافذة هنا، يزيل جداراً هناك، يغير نوع البلاط، وكل هذا بدون تحديث المخطط الأصلي. بعد سنة، لو حاولت بناء بيت جديد مطابق باستخدام المخطط القديم، ستحصل على شيء مختلف تماماً عن البيت الذي تعيش فيه الآن. هذا هو بالضبط الانحراف التكويني.
أسباب هذا الانحراف اللعين
- التعديلات اليدوية السريعة (Hotfixes): مثل قصة صاحبنا سامر، الحاجة لإصلاح مشكلة طارئة تدفعنا للتعديل مباشرة على السيرفرات.
- التحديثات الأمنية: تطبيق تحديث أمني على سيرفر واحد ونسيان تطبيقه على البقية أو على القالب الأساسي.
- غياب مصدر الحقيقة الواحد (Single Source of Truth): عندما لا يكون هناك مكان واحد وموحد يصف كيف “يجب” أن تكون البنية التحتية، يصبح كل سيرفر قصة بحد ذاتها.
- تعدد الفرق والأفراد: كلما زاد عدد الأشخاص الذين يملكون صلاحية الوصول والتعديل، زادت فرصة حدوث تغييرات غير متتبعة.
النتيجة؟ بنية تحتية هشة، غير متوقعة، وصعبة الإدارة. عمليات النشر تفشل بشكل غامض، واستعادة النظام بعد الكوارث (Disaster Recovery) تصبح مهمة شبه مستحيلة.
الطريق إلى الخلاص: مفهوم “البنية التحتية كشيفرة” (Infrastructure as Code – IaC)
بعد ليلتنا الطويلة هذيك، جلسنا كفريق وقلنا “خلص، بكفي هيك”. الطريقة القديمة في إدارة السيرفرات يدوياً أو عبر سكربتات متفرقة لم تعد تنفع. كان لا بد من تبني فلسفة جديدة، وهنا تعرفنا على مفهوم غيّر حياتنا المهنية: البنية التحتية كشيفرة (IaC).
الفكرة عبقرية في بساطتها: تعامل مع البنية التحتية (سيرفرات، شبكات، قواعد بيانات، إلخ) بنفس الطريقة التي تتعامل بها مع شيفرة التطبيق البرمجية. بدلاً من النقر على واجهات المستخدم في AWS أو Azure أو تشغيل أوامر يدوية، أنت تكتب “كود” يصف الحالة النهائية للبنية التحتية التي تريدها.
هذا الكود يصبح هو “مصدر الحقيقة” الوحيد. تريد تغييراً؟ لا تلمس السيرفر، بل عدّل الكود. هذا يمنحنا فوائد هائلة:
- التكرارية (Repeatability): يمكننا بناء نفس البنية التحتية 100 مرة والحصول على نفس النتيجة في كل مرة.
- التوثيق الذاتي (Self-documenting): الكود نفسه هو أفضل توثيق للبنية التحتية.
- التحكم في الإصدارات (Version Control): يمكننا استخدام Git لتتبع كل تغيير، معرفة من غير ماذا ومتى، والعودة لإصدار سابق بسهولة.
- المراجعة والتعاون (Code Review): يمكن للزملاء مراجعة تغييرات البنية التحتية قبل تطبيقها، تماماً مثل مراجعة كود التطبيق.
Terraform: الأداة التي أعادت لنا السيطرة
يوجد العديد من الأدوات لتطبيق مفهوم الـ IaC، مثل AWS CloudFormation, Azure ARM Templates, Ansible, Pulumi. لكن الأداة التي وقع اختيارنا عليها والتي أثبتت فعاليتها بشكل مذهل هي Terraform من شركة HashiCorp.
لماذا Terraform بالذات؟
Terraform تتميز بكونها “Declarative” (تصريحية) و “Cloud-Agnostic” (غير معتمدة على سحابة معينة).
- تصريحية: أنت تصف “ماذا” تريد (أريد سيرفر بهذه المواصفات)، وTerraform تتكفل بمعرفة “كيف” تصل لهذه الحالة. هذا يختلف عن الأدوات الأمرية (Imperative) التي تطلب منك كتابة الخطوات خطوة بخطوة.
- غير معتمدة على سحابة معينة: يمكنك استخدام نفس الأداة ونفس طريقة التفكير لإدارة بنيتك التحتية على AWS, Azure, Google Cloud, وحتى على خوادمك الخاصة (On-premise).
كيف يقضي Terraform على الانحراف التكويني؟
السر يكمن في دورة حياة Terraform البسيطة والفعالة: `plan` و `apply`.
- كتابة الكود (Write): تكتب تكوين بنيتك التحتية باستخدام لغة HCL السهلة القراءة.
- التخطيط (Plan): تشغل أمر
terraform plan. هنا يحدث السحر! Terraform تقارن بين الحالة التي تريدها (المكتوبة في الكود) والحالة الفعلية للبنية التحتية، وتعطيك تقريراً مفصلاً بما ستقوم به: “سأقوم بإنشاء هذا السيرفر، وسأحذف مجموعة الأمان هذه، وسأعدل حجم هذا القرص”. - التطبيق (Apply): إذا كان التقرير يبدو صحيحاً، تشغل أمر
terraform applyلتنفيذ تلك التغييرات فعلياً.
هذا يعني أنه لو قام “سامر” مرة أخرى بتغيير شيء ما يدوياً، في المرة التالية التي نشغل فيها terraform plan، ستكتشف Terraform هذا “الانحراف” فوراً وستقترح إعادة الوضع إلى ما هو عليه في الكود. لقد أصبح الكود هو الحاكم والمصدر الوحيد للحقيقة.
مثال عملي: كشف الانحراف بالفِعل
لنفترض أننا نريد إنشاء سيرفر بسيط (EC2 instance) على AWS. الكود في Terraform سيبدو هكذا في ملف اسمه `main.tf`:
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
instance_type = "t2.micro"
tags = {
Name = "WebServer-Prod"
}
}
نقوم بتشغيل terraform apply ويتم إنشاء السيرفر بالتاج `Name = “WebServer-Prod”`. كل شيء تمام.
الآن، تخيل أني ذهبت إلى واجهة AWS الرسومية وقمت بإضافة تاج جديد يدوياً للسيرفر، مثلاً `Owner = “AbuOmar”`. هنا حدث الانحراف!
في المرة القادمة، وقبل أي تغيير، سأقوم بتشغيل terraform plan. انظروا ماذا ستكون النتيجة (بشكل مبسط):
# aws_instance.web_server will be updated in-place
~ resource "aws_instance" "web_server" {
id = "i-0123456789abcdef0"
tags = {
"Name" = "WebServer-Prod"
- "Owner" = "AbuOmar" -> null # هذا التاج سيتم حذفه
}
# ... other attributes
}
Plan: 0 to add, 1 to change, 0 to destroy.
لاحظ كيف اكتشف Terraform التاج الإضافي `Owner` واقترح حذفه ليعيد السيرفر مطابقاً للكود. بهذه الطريقة، لا مجال للمفاجآت. أي تغيير يدوي يتم كشفه وتصحيحه تلقائياً في الدورة التالية.
نصائح من خبرة أبو عمر
الانتقال إلى Terraform رحلة، وهذه بعض النصائح العملية لتجعلها أسهل:
- ابدأ صغيراً: لا تحاول نقل كل بنيتك التحتية دفعة واحدة. ابدأ بمشروع جديد أو خدمة غير حرجة. تعلم، ارتكب الأخطاء على نطاق صغير، ثم توسع.
- إدارة ملف الحالة (State File) بحكمة: ملف
terraform.tfstateهو ذاكرة Terraform، وهو حساس جداً. إياك ثم إياك أن تضعه في Git. استخدم “الواجهات الخلفية البعيدة” (Remote Backends) مثل Amazon S3 أو Azure Blob Storage لتخزينه بشكل آمن ومركزي، وقم بتفعيل القفل (Locking) لمنع فريقك من تشغيل الأوامر في نفس الوقت. - استخدم الوحدات (Modules): كما في البرمجة، لا تكرر نفسك. إذا كنت تبني نفس النوع من السيرفرات مراراً وتكراراً، حوّل الكود الخاص به إلى “وحدة” (Module) قابلة لإعادة الاستخدام.
- كل شيء في Git: كود Terraform هو كود برمجي. يجب أن يعيش في نظام تحكم بالإصدارات مثل Git. استخدم فروعاً (branches)، طلبات سحب (pull requests)، ومراجعات للكود.
- الأتمتة مع CI/CD: ادمج Terraform في مسار التكامل والنشر المستمر (CI/CD). مثلاً، اجعل نظام الـ CI يقوم بتشغيل `terraform plan` تلقائياً مع كل طلب سحب (Pull Request) ليظهر تأثير التغييرات المقترحة كتعليق.
الخلاصة: استعادة السلام النفسي 😴
يا جماعة، قصة الانحراف التكويني ليست مجرد مشكلة تقنية، إنها حالة من الفوضى تسرق منك ومن فريقك راحة البال والثقة في نظامكم. الانتقال إلى “البنية التحتية كشيفرة” باستخدام أداة مثل Terraform لم يكن مجرد حل لمشكلة، بل كان نقلة نوعية في طريقة تفكيرنا وعملنا.
صحيح أن هناك منحنى تعلم في البداية، لكن المردود هائل. القدرة على بناء وتغيير وتدمير بيئات كاملة بثقة وسرعة، ومعرفة أن الكود هو المرجع الوحيد، هي قوة لا تقدر بثمن. إنها تعني ليالي نوم هانئة أكثر، ووقت أقل في إطفاء الحرائق، ووقت أطول في الإبداع والابتكار.
نصيحتي الأخيرة: لا تخف من البدء. ابدأ اليوم، ولو بخطوة صغيرة. فالسلام النفسي الذي ستحصل عليه عندما تعلم أن بنيتك التحتية صلبة كالصخر وموثقة بالكود يستحق كل دقيقة من الجهد. ✅
