بتذكرها زي كأنها مبارح. كانت الساعة وحدة بعد نص الليل، والجو هادي، وأنا يا دوب مخلص فنجان الميرمية وبدي أروح أنام. فجأة، التلفون برنّ، والمتصل هو مدير المشروع. لما المدير يرن بهيك ساعة، اعرف إنه المصيبة كبيرة. “أبو عمر، الموقع واقع! كل إشي واقع! العملاء معصبين والدنيا مقلوبة!”.
في ثواني، كنت قدام اللابتوب. دخلت على لوحة تحكم AWS، وكل فريق المهندسين معي على الخط، كل واحد فينا بحاول يفهم شو اللي صار. السيرفرات شغالة، قواعد البيانات موجودة، بس ما في إشي بوصل ببعضه. بعد ساعة من البحث والتحليل والضغط النفسي، اكتشفنا الكارثة: مهندس مبتدئ، بنيّة حسنة، عمل “تعديل بسيط” على إعدادات الشبكة (VPC Security Group) عشان يفتح بورت لاختبار معين… ونسي يرجّعه. تعديل يدوي صغير، بكبسة زر، عطّل نظام كامل بيخدم آلاف المستخدمين.
هذيك الليلة، واحنا بنصلح الخراب تحت ضغط هائل، أخذت قرار. قلت للفريق: “يا جماعة، شغلنا هاد ما بنفع يضل هيك. بنيتنا التحتية هاي عبارة عن قصر من ورق، أي نسمة هوا بتوقّعه. من بكرة، بدنا نغير كل إشي”. وكانت هاي بداية رحلتنا مع Terraform.
الجحيم الذي كنا نعيشه: إدارة البنية التحتية يدوياً
قبل ما أحكي عن الحل، خلوني أوصفلكم طبيعة “الجحيم” اللي كنا فيه. يمكن كتير منكم بعيش نفس التجربة حالياً. الإدارة اليدوية للبنية التحتية، سواء عن طريق لوحات التحكم في الخدمات السحابية (AWS Console, Azure Portal) أو عن طريق كتابة سكربتات Bash عشوائية، هي وصفة مضمونة للكوارث.
الانحراف التكويني (Configuration Drift)
هذا المصطلح الفخم هو مجرد طريقة لوصف مشكلة بسيطة: مع الوقت، بيئة الإنتاج (Production) بتصير مختلفة عن بيئة التطوير (Staging). ليش؟ لأنه كل يوم في تعديل يدوي صغير هون، و”إصلاح سريع” هناك. بعد كم شهر، بصير عندك نسختين مختلفتين تماماً من البنية التحتية، ولما تطلق ميزة جديدة بتشتغل تماماً في بيئة التطوير، بتكتشف إنها بتنفجر في بيئة الإنتاج لأسباب غامضة.
غياب التوثيق والمراجعة
لما كل إشي يتم بكبسات الأزرار، مين آخر واحد غيّر إعدادات الـ Firewall؟ ومتى؟ وليش؟ الجواب غالباً ما بكون “الله أعلم”. ما في سجل واضح، ما في Version Control، وما في طريقة لعمل مراجعة (Code Review) لتغييرات البنية التحتية قبل ما تتطبق. البنية التحتية كلها بتصير عايشة في عقول كم واحد من أعضاء الفريق، وإذا واحد منهم أخذ إجازة أو ترك الشغل، بتضيع المعرفة معه.
الخطأ البشري… حتمي!
زي ما صار معنا في القصة اللي حكيتها. كلنا بشر، وكلنا بنغلط. الفرق إنه غلطة في كود التطبيق ممكن يتم اكتشافها باختبارات الوحدة (Unit Tests)، أما غلطة في البنية التحتية ممكن تحذف قاعدة البيانات الرئيسية كلها بكبسة زر واحدة. الاعتماد على التركيز البشري بنسبة 100% في مهام متكررة وحساسة هو مجرد انتظار للكارثة القادمة.
شروق شمس جديدة: مفهوم البنية التحتية كشيفرة (IaC)
وهون بيجي الحل السحري: البنية التحتية كشيفرة (Infrastructure as Code – IaC). الفكرة بسيطة وعبقرية بنفس الوقت: بدل ما نبني السيرفرات والشبكات وقواعد البيانات يدوياً، بنكتب “وصفة” أو “مخطط” لهي البنية التحتية على شكل كود برمجي.
هذا الكود بصير هو المصدر الوحيد للحقيقة (Single Source of Truth). بدك تغير إشي؟ بتعدل الكود، مش السيرفر مباشرة. بدك تعرف حالة البنية التحتية؟ بتقرأ الكود. هاد الأسلوب بحوّل البنية التحتية من عمل فني غامض إلى عملية هندسية منظمة وقابلة للتكرار.
ولماذا Terraform بالذات؟
يوجد العديد من الأدوات لتطبيق مفهوم الـ IaC، مثل AWS CloudFormation أو Ansible. لكن بالنسبة إلي ولفريقي، وقع اختيارنا على Terraform من شركة HashiCorp، ولأسباب وجيهة جداً.
مفتوح المصدر ومستقل عن المنصات (Cloud-Agnostic)
Terraform لا يكترث إذا كنت تستخدم AWS, Google Cloud, Azure, DigitalOcean, أو حتى VMware في مركز بياناتك الخاص. لديه “مزودين” (Providers) لكل هاي المنصات وغيرها الكثير. هذا يعني أنك بتتعلم أداة واحدة بتقدر تستخدمها في كل مكان، وما بتكون محبوس مع مزود خدمة سحابية واحد.
لغة تعريفية بسيطة (Declarative Language)
Terraform بيستخدم لغة اسمها HCL (HashiCorp Configuration Language)، وهي لغة سهلة القراءة والكتابة. الأهم من هيك، إنها لغة “تعريفية” (Declarative). شو يعني؟
نصيحة أبو عمر: الفرق بين التعريفي (Declarative) والأمري (Imperative) هو كالفرق بين إنك تطلب بيتزا جاهزة (بتوصف النتيجة النهائية: بدي بيتزا بيبروني) وبين إنك تعطي الشيف وصفة خطوة بخطوة (اعجن العجينة، افردها، حط الصلصة…). Terraform هو الأول، أنت تصف “ماذا” تريد، وهو يتكفل بـ “كيف”.
أنت فقط تصف الحالة النهائية التي تريد أن تكون عليها بنيتك التحتية، وTerraform ذكي كفاية ليعرف الخطوات اللازمة للوصول لهي الحالة.
التخطيط قبل التنفيذ (Plan Before You Apply)
هاي الميزة لحالها بتستاهل استخدام Terraform. قبل ما يطبق أي تغيير، بتنفذ أمر terraform plan. هذا الأمر بيعطيك تقرير مفصل بكل التغييرات اللي راح تصير: شو الموارد اللي راح يتم إنشاؤها (+)، شو اللي راح يتعدل (~)، وشو اللي راح ينحذف (-). هذا بيعطيك فرصة ذهبية لمراجعة التغييرات وتجنب الكوارث قبل وقوعها.
يالله نشتغل شغل مرتب: أول خطواتنا مع Terraform
الكلام النظري حلو، بس خلينا نشوف الموضوع بشكل عملي. لنفترض أننا نريد إنشاء سيرفر ويب بسيط (EC2 instance) على AWS.
الخطوة الأولى: تعريف المزود (Provider)
أول إشي، بنعمل ملف اسمه main.tf وبنخبر Terraform إننا رح نشتغل مع AWS.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
# تعريف إعدادات المزود، مثل المنطقة الجغرافية
provider "aws" {
region = "eu-west-1" # منطقة أيرلندا على سبيل المثال
}
الخطوة الثانية: إنشاء أول مورد (Resource)
الآن، نضيف “مورد” جديد في نفس الملف لوصف السيرفر اللي بدنا إياه.
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # هذا مثال، يجب استخدام AMI صحيح لمنطقتك
instance_type = "t2.micro" # أصغر وأرخص نوع سيرفر
tags = {
Name = "MyFirstWebServer-Terraform"
Owner = "Abu Omar"
}
}
لاحظوا كيف الكود وصفي جداً: “أريد مورد من نوع aws_instance، اسمه المنطقي web_server، بهذه المواصفات”.
الخطوة الثالثة: دورة حياة Terraform
الآن تأتي المتعة. افتح الطرفية (Terminal) في نفس المجلد الذي يحتوي على ملفك ونفذ الأوامر التالية بالترتيب:
terraform init: هذا الأمر يقرأ ملفك، ويرى أنك بحاجة لمزود AWS، ويقوم بتحميله. تنفذه مرة واحدة فقط في بداية المشروع.terraform plan: هذا الأمر سيقوم بمقارنة الكود الذي كتبته مع الحالة الحقيقية في حسابك على AWS (اللي هي حالياً لا شيء)، وسيخبرك: “سأقوم بإنشاء سيرفرaws_instanceواحد جديد”.terraform apply: بعد أن تتأكد من خطة العمل، اكتبyesللتأكيد، واذهب لإعداد فنجان قهوة. خلال دقائق، سيقوم Terraform بإنشاء السيرفر لك تماماً كما وصفته في الكود.
الآن، إذا أردت تغيير نوع السيرفر من t2.micro إلى t2.small، كل ما عليك فعله هو تغيير سطر واحد في الكود، ثم تنفيذ plan و apply مرة أخرى. سيقوم Terraform بتعديل السيرفر الموجود دون تدميره.
نصائح من الخبير (أو الختيار، زي ما بدكم)
بعد سنوات من استخدام Terraform في مشاريع صغيرة وكبيرة، تعلمت بعض الدروس بالطريقة الصعبة. خذوا مني هاي النصائح العملية:
لا تلمس ملف الحالة (State File) يدوياً!
Terraform يخزن “ذاكرته” عن البنية التحتية التي بناها في ملف اسمه terraform.tfstate. هذا الملف مقدس! إياك ثم إياك أن تعدله يدوياً. للعمل كفريق، لا تخزن هذا الملف على جهازك، بل استخدم ما يسمى بـ “Remote State Backends” مثل Amazon S3 لتخزينه بشكل مركزي وآمن.
نظم شيفرتك باستخدام الوحدات (Modules)
عندما يكبر مشروعك، لا تضع كل الكود في ملف واحد. استخدم الوحدات (Modules) لتقسيم بنيتك التحتية إلى مكونات منطقية قابلة لإعادة الاستخدام (مثلاً، وحدة للشبكة، وحدة للسيرفرات، وحدة لقاعدة البيانات). فكر فيها كأنها “وظائف” (functions) في عالم البنية التحتية.
استخدم Git دائماً وأبداً
بما أن بنيتك التحتية أصبحت الآن كوداً، عاملها ككود! ضع كل ملفات Terraform في مستودع Git. هذا يعطيك تاريخاً كاملاً للتغييرات، القدرة على التراجع (revert)، والعمل مع فريقك من خلال Pull Requests لمراجعة التغييرات قبل تطبيقها.
الخلاصة: من قصر الورق إلى قلعة منيعة
التحول إلى Terraform لم يكن مجرد تغيير تقني، بل كان تحولاً في العقلية والثقافة داخل الفريق. انتقلنا من حالة الخوف الدائم من التغيير، والاجتماعات الطارئة في منتصف الليل، إلى حالة من الثقة والهدوء.
اليوم، بنيتنا التحتية لم تعد قصراً من ورق، بل أصبحت قلعة منيعة موثقة، مؤتمتة، وقابلة للتطوير. عندما نريد إضافة خدمة جديدة أو تغيير إعدادات 50 سيرفر دفعة واحدة، لا نفتح أي لوحة تحكم، بل نفتح محرر الكود، نكتب بضعة أسطر، ونشرب الشاي بينما Terraform يقوم بالعمل الشاق عنا. 😉
نصيحتي الأخيرة لك: لا تخف من البداية. ابدأ بمشروع صغير، ربما سيرفر شخصي أو بيئة تطوير. أتمتة جزء واحد صغير من بنيتك التحتية اليوم. صدقني، راحة البال التي ستحصل عليها تستحق كل سطر كود ستكتبه.
