يا مية أهلاً وسهلاً فيكم يا جماعة الخير. اسمي أبو عمر، وقصتي اليوم مش عن خوارزمية معقدة أو شبكة عصبونية جديدة، لا.. قصتي عن “الطنجرة” اللي كنا نطبخ فيها كل يوم، عن البنية التحتية اللي فجأة صارت مثل حقل الألغام، وكل خطوة فيها ممكن تكون الأخيرة للمشروع.
بتذكر هداك اليوم جيداً، كان يوم خميس، وكنا بنستعد لإطلاق ميزة جديدة ومهمة في تطبيقنا. الأمور كانت تبدو تمام في بيئة الاختبار (Staging). لكن لما عملنا إطلاق (Deploy) على البيئة الحقيقية (Production)، صارت الكارثة. الخدمة الأساسية توقفت، والتطبيق كله “نام”.
بدأ السباق مع الزمن. فريق هنا وفريق هناك، والكل بحاول يعرف “شو القصة؟”. بعد ساعات من التوتر والضغط، اكتشفنا المشكلة. واحد من زملائنا، بنيّة حسنة طبعاً، كان قد أجرى تعديلاً يدوياً سريعاً على إعدادات الشبكة في السيرفر الرئيسي قبل أسبوعين ليحل مشكلة مؤقتة. “تعديل سريع وما بسوى”، هكذا قال لنفسه، ونسي الموضوع تماماً. هذا التعديل البسيط، الذي لم يتم توثيقه أو تسجيله في أي مكان، هو الذي تسبب في تعارض كارثي مع الإطلاق الجديد.
هنا كانت صرخة الفريق المدوية: “لازم نلاقي حل! مش معقول نضل نشتغل زي اللي برقع في بنطلون مهتري!”. هذه الحادثة كانت القشة التي قصمت ظهر البعير، وكانت بداية رحلتنا للبحث عن منقذ، وهذا المنقذ كان اسمه Terraform.
ما هو “الانجراف التكويني” (Configuration Drift)؟ وليش هو كابوس؟
قبل ما نحكي عن الحل، خلينا نفهم أصل المشكلة. “الانجراف التكويني” أو بالإنجليزية “Configuration Drift”، هو مصطلح يمكن يبدو غريب، لكنه ببساطة يعني أن الحالة الحقيقية للبنية التحتية (السيرفرات، قواعد البيانات، الشبكات…) أصبحت مختلفة عن الحالة اللي إحنا بنعرفها أو اللي وثقناها.
تخيل إنك بتبني بيت بناءً على مخطط هندسي دقيق. بعد فترة، بيجي واحد بغير مكان شباك، والثاني بضيف جدار صغير، والثالث بغير تمديدات الكهرباء… وكل واحد بيعمل هالتغيير “على السريع” وبدون ما يحدّث المخطط الهندسي الأصلي. بعد سنة، لما تيجي تعمل توسعة بناءً على المخطط القديم، راح تلاقي كوارث لأن المخطط بطل يعكس الواقع. هذا بالضبط هو الانجراف التكويني.
فخ “التعديل اليدوي السريع”
هذه هي البوابة الرئيسية للجحيم. مبرمج أو مسؤول نظام بيواجه مشكلة عاجلة، وبدل ما يتبع الإجراءات الصحيحة، بيدخل على السيرفر مباشرةً وبعمل تغيير. المشكلة بتنحل مؤقتاً، والكل بكون سعيد، لكن هذا التغيير بصير قنبلة موقوتة، لأنه غير موثق وغير معروف لباقي الفريق.
متلازمة “شغال عندي!”، نسخة السيرفرات
الانجراف التكويني هو السبب الرئيسي إنه بيئة الاختبار (Staging) تكون مختلفة عن بيئة الإنتاج (Production). بنختبر الكود على بيئة الاختبار، وكل شيء بكون تمام. لكن لما ننقله للإنتاج، بتظهر أخطاء غريبة. ليش؟ لأنه في تغييرات يدوية صارت على بيئة الإنتاج خلال الأشهر الماضية، حولتها لوحش فريد من نوعه لا يشبه أي بيئة أخرى.
الكابوس الأمني
“كل منفذ (Port) مفتوح يدوياً و”بشكل مؤقت” هو دعوة مفتوحة للمخترقين لتناول العشاء في سيرفراتك.” – أبو عمر
من أخطر نتائج الانجراف التكويني هي الثغرات الأمنية. شخص بيفتح منفذ في الجدار الناري (Firewall) عشان يجرب إشي معين، وبينسى يسكره. أو بيعطي صلاحيات واسعة لمستخدم معين “عشان يمشي شغله”، وما برجع بسحبها. هذه التغييرات غير الموثقة هي جنة المخترقين.
مرحباً بـ Terraform: شرطي السيرفرات الجديد
بعد الحادثة اللي حكيتلكم عنها، قررنا إنه “خلص بكفي!”. وبدأنا رحلة البحث عن حل جذري، وهنا تعرفنا على مفهوم “البنية التحتية كشيفرة” (Infrastructure as Code – IaC) وأفضل من يمثله في الساحة: Terraform.
ما هي “البنية التحتية كشيفرة” (IaC)؟
الفكرة عبقرية وبسيطة: بدل ما ننشئ وندير سيرفراتنا وقواعد بياناتنا بشكل يدوي عبر واجهات رسومية أو أوامر متفرقة، بنقوم بكتابة “كود” يصف كل مكونات البنية التحتية. هذا الكود بصير هو “المصدر الوحيد للحقيقة” (Single Source of Truth). بدك سيرفر جديد؟ بتضيفه للكود. بدك تغير إعدادات قاعدة البيانات؟ بتعدل الكود. تماماً مثل ما بتتعامل مع كود التطبيق تبعك.
كيف يعمل Terraform سحره؟
Terraform هي أداة مفتوحة المصدر من شركة HashiCorp تتيح لك تعريف وإدارة البنية التحتية بأمان وكفاءة. سحرها يكمن في عدة نقاط:
- لغة تعريفية (Declarative): أنت لا تخبر Terraform “كيف” ينشئ الأشياء خطوة بخطوة (هذا أسلوب إجرائي/Imperative). بل أنت ببساطة “تصف” له الحالة النهائية التي تريدها (Declarative). مثلاً، تقول له: “أريد سيرفر بالمواصفات الفلانية، وقاعدة بيانات من نوع كذا، وشبكة بهذه الإعدادات”. وهو يتكفل بالباقي.
- ملف الحالة (State File): هذا هو قلب Terraform النابض. عندما تنفذ الكود، يقوم Terraform بإنشاء ملف اسمه
terraform.tfstate. هذا الملف يسجل كل الموارد التي أنشأها ويربطها بالكود تبعك. إنه بمثابة ذاكرة Terraform، وهو السلاح السري ضد الانجراف التكويني. - التخطيط قبل التنفيذ: قبل تطبيق أي تغيير، يمكنك تشغيل أمر
terraform plan. هذا الأمر يقارن بين الكود تبعك (الحالة المرغوبة)، وملف الحالة (الحالة المسجلة سابقاً)، والحالة الحقيقية للموارد على السحابة. ثم يعطيك تقريراً مفصلاً جداً: “سأقوم بإنشاء هذا، وتعديل ذاك، وحذف هذا”. لا مفاجآت بعد اليوم.
خطة معركتنا: ترويض الانجراف باستخدام Terraform
بعدما اقتنعنا بالفكرة، وضعنا خطة عمل واضحة لتحويل فوضانا إلى نظام. “شغل مرتب” زي ما بحكوها.
الخطوة الأولى: تدوين كل شيء (Codifying Everything)
أصعب خطوة كانت في البداية. كان علينا أن نمر على بنيتنا التحتية الحالية، التي تم إنشاؤها يدوياً على مدار سنوات، ونقوم بكتابة كود Terraform يصفها بدقة. كانت عملية شاقة، لكنها ضرورية. قمنا بتوثيق كل سيرفر، كل قاعدة بيانات، كل إعداد شبكة، وكل سياسة أمان في ملفات .tf.
مثال بسيط: إدارة حاوية تخزين (S3 Bucket) على AWS
لنفترض أننا نريد إنشاء حاوية تخزين آمنة على AWS. بدلاً من الدخول للوحة تحكم AWS والنقر هنا وهناك، نكتب الكود التالي:
# provider.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
# s3.tf
resource "aws_s3_bucket" "b_abu_omar_data" {
bucket = "abu-omar-secret-data-bucket-unique-name" # يجب أن يكون الاسم فريداً عالمياً
tags = {
Name = "My secret data bucket"
Environment = "Production"
ManagedBy = "Terraform"
}
}
resource "aws_s3_bucket_public_access_block" "b_abu_omar_data_access" {
bucket = aws_s3_bucket.b_abu_omar_data.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
هذا الكود البسيط والواضح يضمن لنا إنشاء حاوية S3 ومنع أي وصول عام إليها. هذا الكود يمكن مراجعته، تخزينه في Git، وتطبيقه في أي بيئة عمل بنفس النتيجة كل مرة.
الخطوة الثانية: طقوس “كشف الانجراف”
هنا تكمن قوة Terraform الحقيقية. أصبحنا نشغل أمر terraform plan بشكل دوري كجزء من عملياتنا الآلية. ماذا يحدث لو قام أحدهم، مرة أخرى، بتغيير شيء ما يدوياً؟
لنفترض أن أحدهم دخل إلى AWS وقام بإضافة “tag” جديد يدوياً على الحاوية التي أنشأناها سابقاً. في المرة التالية التي نشغل فيها terraform plan، سنرى شيئاً كهذا:
Terraform will perform the following actions:
# aws_s3_bucket.b_abu_omar_data will be updated in-place
~ resource "aws_s3_bucket" "b_abu_omar_data" {
id = "abu-omar-secret-data-bucket-unique-name"
tags = {
"Name" = "My secret data bucket"
"Environment" = "Production"
"ManagedBy" = "Terraform"
- "ManualTag" = "temp-fix" -> null # Terraform detects the manual tag and will remove it
}
# ... other attributes
}
Plan: 0 to add, 1 to change, 0 to destroy.شفتوا كيف؟ Terraform كشف التغيير اليدوي فوراً! يخبرنا بأن الواقع (يحتوي على “ManualTag”) مختلف عن الكود (لا يحتوي عليه)، ويقترح العودة إلى الحالة الموصوفة في الكود. بهذه الطريقة، أصبح الانجراف مكشوفاً ويمكن إصلاحه بضغطة زر عبر terraform apply.
الخطوة الثالثة: القاعدة الذهبية: ممنوع اللمس!
أهم خطوة كانت تغيير الثقافة في الفريق. صار الاتفاق يا جماعة: “أي تغيير، مهما كان صغيراً، يجب أن يمر من خلال الكود”. لا مزيد من الدخول المباشر للسيرفرات لإجراء تعديلات. كل تغيير يجب أن يكون عبر Pull Request في Git، تتم مراجعته من قبل الزملاء، ثم يتم تطبيقه بشكل آلي.
نصائح من أبو عمر
من خلال رحلتنا هذه، تعلمت بعض الدروس التي أحب أن أشاركها معكم:
- ابدأ صغيراً: لا تحاول تحويل كل بنيتك التحتية دفعة واحدة. اختر خدمة صغيرة غير حرجة، وتعلم عليها. هذا يقلل المخاطر ويعطي فريقك الثقة.
- ملف الحالة مقدس: تعامل مع ملف
.tfstateكأنه من أسرار الدولة. لا تقم بتعديله يدوياً أبداً. والأهم، قم بتخزينه عن بعد (Remote Backend) في مكان آمن مثل S3 Bucket مع تفعيل قفل الحالة (State Locking) لمنع أي شخصين من تشغيل Terraform في نفس الوقت. - استخدم الوحدات (Modules): عندما يكبر الكود، استخدم Terraform Modules لتنظيم الكود وتجنب التكرار. يمكنك إنشاء وحدة خاصة بالسيرفرات، وأخرى بقواعد البيانات، وهكذا.
- اربط كل شيء بـ CI/CD: الهدف النهائي هو أتمتة كل شيء. قم بإعداد pipeline بحيث يتم تشغيل
terraform planتلقائياً مع كل Pull Request، وتشغيلterraform applyبعد الموافقة والدمج في الفرع الرئيسي.
الخلاصة: من الفوضى إلى النظام ordenada
رحلة تبني Terraform لم تكن سهلة، وتطلبت تغييراً في الأدوات والعقليات على حد سواء. لكن النتيجة كانت تستحق كل هذا العناء. انتقلنا من بيئة عمل فوضوية، مليئة بالمفاجآت والقنابل الموقوتة، إلى بيئة عمل منظمة، موثوقة، ويمكن التنبؤ بسلوكها.
لم نعد نخاف من الانجراف التكويني، لأنه ببساطة لم يعد بإمكانه الاختباء. أصبح الكود هو مصدر الحقيقة، وأي انحراف عن هذا المصدر يتم كشفه وإصلاحه على الفور. إذا كنتم تعانون من نفس المشاكل التي عانينا منها، فأنصحكم بشدة أن تبدأوا رحلتكم مع “البنية التحتية كشيفرة”. صدقوني، نومكم في الليل سيصبح أعمق بكثير. 😉
