يا جماعة، السلام عليكم ورحمة الله وبركاته، معكم أبو عمر.
خلوني أحكيلكم قصة صارت معي قبل كم سنة، أيام ما كنا “نطبخ” السيرفرات على إيدينا. كانت ليلة خميس، وكنا على وشك إطلاق ميزة جديدة ومهمة في تطبيقنا. فجأة، ومع زيادة الضغط على الموقع، قررنا إنه لازم نضيف سيرفر جديد فورًا عشان يستوعب الحمل. طبعًا، كانت الساعة 11 بالليل، والكل تعبان وبده يروّح.
تطوع واحد من الشباب الشاطرين، خلينا نسميه “سامر”، وقال “ولا يهمكم، نص ساعة وبتكون جاهزة”. وبدأ سامر الشغلانة: دخل على لوحة تحكم مزود الخدمة السحابية، أنشأ الجهاز الوهمي (VM)، وبعدها دخل عليه عن طريق SSH وبدأ يثبت الحزم وحدة ورا التانية: Nginx، PHP، MySQL client، وكل المكتبات اللي بنحتاجها. كان يشتغل من الذاكرة ومن ملف `notes.txt` قديم عنده على الجهاز.
بعد حوالي ساعة ونص، صرخ سامر “خلصت! السيرفر جاهز!”. ضفناه لموازن الأحمال (Load Balancer) وتنفسنا الصعداء. لكن الفرحة ما كملت… بعد دقايق، بدأ السيرفر الجديد يرجع أخطاء 502 Bad Gateway. طلعنا السيرفر من الخدمة بسرعة وبدأنا نحقق. قضينا ساعتين زيادة بس عشان نكتشف إنه سامر نسي يفتح بورت معين في الجدار الناري (Firewall) وكمان نسخة PHP اللي ثبتها كانت أقدم بشوي من النسخة اللي على باقي السيرفرات.
هذيك الليلة، وأنا مروّح على البيت الساعة 3 الفجر، كنت أفكر: “بزبطش هيك! لازم يكون في طريقة أحسن وأضمن”. كانت هذي الحادثة هي الشرارة اللي خلتنا نبحث عن حل جذري، وهذا الحل كان اسمه Terraform.
الجحيم اليدوي: أيام ما كانت السيرفرات شغلانة باليد
قبل ما نحكي عن الحل، خلينا نتذكر مع بعض ليش الطريقة اليدوية كانت “وجعة راس” كبيرة. اللي عاشوا هذيك الأيام بيعرفوا عن شو بحكي:
1. البيئات غير المتطابقة (Inconsistent Environments)
زي ما صار معنا في قصة سامر، كل سيرفر جديد هو مغامرة. يمكن تنسى حزمة، أو تثبت نسخة مختلفة، أو تضبط إعداد بشكل خاطئ. والنتيجة؟ بيئة التطوير شغالة تمام، بيئة الاختبار نص نص، وبيئة الإنتاج فيها مشاكل غريبة ما حدا عارف من وين جاية. هاي هي أشهر جملة كانت تتردد: “غريبة، شغالة على جهازي!”.
2. البطء والخطأ البشري
إعداد سيرفر واحد يدويًا ممكن ياخذ من نص ساعة لساعتين، حسب تعقيده. طيب لو بدك 10 سيرفرات؟ بدك يوم كامل! ومع كل خطوة يدوية، بتزيد فرصة الخطأ. الإنسان بطبيعته مش مصمم عشان يكرر نفس المهام الروتينية بدقة 100%.
3. التوثيق المفقود و “عامل الحافلة”
مين اللي بيعرف بالضبط كيف السيرفر الفلاني تم إعداده؟ غالبًا شخص واحد أو اثنين في الفريق. كل المعرفة موجودة في عقولهم أو في ملفات نصية متناثرة. هذا الوضع خطير جدًا ويعرف بـ “عامل الحافلة” (Bus Factor): لو هذا الشخص “خبطته حافلة” (لا سمح الله) أو ترك الشغل، بتضيع كل المعرفة معه، وبصير أي تغيير في البنية التحتية كابوس.
4. صعوبة التوسع والكوارث
تخيل لو صار عندك كارثة والسيرفرات كلها وقعت. كم من الوقت بيلزمك عشان ترجع تبني كل شيء من الصفر يدويًا؟ أيام؟ أسابيع؟ في عالم اليوم، هذا يعني خسارة فلوس وسمعة ما بتتعوض.
المنقذ Terraform: البنية التحتية كشيفرة برمجية (IaC)
هنا يأتي دور مفهوم “البنية التحتية كشيفرة برمجية” أو Infrastructure as Code (IaC). الفكرة بسيطة وعبقرية: بدل ما تضغط على أزرار في واجهة رسومية أو تكتب أوامر بشكل يدوي، أنت بتوصف البنية التحتية اللي بدك إياها (سيرفرات، قواعد بيانات، شبكات، جدران نارية) في ملفات نصية، زي ما بتكتب كود برمجي بالضبط.
و Terraform هي أشهر أداة بتطبق هذا المفهوم.
ما هو Terraform بالضبط؟
Terraform هي أداة مفتوحة المصدر من شركة HashiCorp بتسمحلك تعرف وتنشئ وتدير البنية التحتية بطريقة آمنة ومتوقعة. أهم مميزاتها:
- لغة تعريفية (Declarative): أنت بتوصف “الحالة النهائية” اللي بدك توصلها (مثلاً: بدي سيرفر بالمواصفات الفلانية)، و Terraform هي اللي بتكتشف كيف توصل لهذي الحالة. ما بتحكيلها “اعمل خطوة 1 ثم خطوة 2″، وهذا بيقلل التعقيد بشكل كبير.
- متعدد المنصات (Multi-Cloud): بتقدر تستخدمه مع أغلب مزودي الخدمات السحابية الكبار (AWS, Azure, Google Cloud) وغيرهم كثير، وحتى مع خدمات محلية (On-premise) مثل VMware. يعني بتتعلم أداة وحدة وبتستخدمها في كل مكان.
- إدارة الحالة (State Management): Terraform بتحتفظ بملف اسمه “ملف الحالة” (State File) بيوصف الوضع الحالي للبنية التحتية اللي هي بتديرها. لما تيجي تعمل أي تغيير، بتقارن الكود الجديد مع ملف الحالة وبتعرف بالضبط شو لازم تضيف أو تعدل أو تحذف.
يلا نشتغل عملي: أول خطواتك مع Terraform
الكلام النظري حلو، بس خلينا نشوف الموضوع بشكل عملي. تخيل إنه بدنا نعمل نفس اللي حاول يعمله سامر، بس بالطريقة الصح. بدنا ننشئ سيرفر (EC2 instance) على AWS.
المتطلبات الأساسية
- تثبيت Terraform CLI على جهازك.
- حساب على AWS مع صلاحيات لإنشاء موارد (Access Key و Secret Key).
كتابة أول ملف تكوين (main.tf)
أنشئ ملف جديد اسمه main.tf واكتب فيه الكود التالي:
# تحديد مزود الخدمة (Provider) اللي راح نستخدمه، وهو AWS في حالتنا
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
}
}
# إعداد معلومات الدخول لمزود الخدمة
provider "aws" {
region = "us-east-1"
# يفضل استخدام متغيرات البيئة لتمرير مفاتيح الدخول
# export AWS_ACCESS_KEY_ID="YOUR_KEY"
# export AWS_SECRET_ACCESS_KEY="YOUR_SECRET"
}
# تعريف المورد (Resource) الأول: سيرفر EC2
resource "aws_instance" "app_server" {
ami = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI
instance_type = "t2.micro" # نوع الجهاز (حجمه)
# إضافة وسوم (Tags) لتنظيم الموارد
tags = {
Name = "MyFirstTerraformServer"
}
}
شوف البساطة! في أقل من 20 سطر، وصفنا سيرفر كامل. هذا الكود هو “المصدر الوحيد للحقيقة” (Single Source of Truth).
الأوامر السحرية الثلاثة
الآن، افتح الطرفية (Terminal) في نفس المجلد اللي فيه الملف، ونفذ الأوامر التالية بالترتيب:
-
terraform initهذا الأمر بجهز بيئة العمل. Terraform بيقرأ الكود، وبيشوف إنك بدك تستخدم مزود الخدمة AWS، فبيقوم بتنزيل الإضافات اللازمة له. بتعمله مرة وحدة بس في كل مشروع.
-
terraform planهذا أهم أمر في Terraform برأيي. الأمر هذا بيعمل “محاكاة”. بيقارن الكود اللي كتبته مع الوضع الحالي (اللي هو لا شيء في البداية)، وبيحكيلك بالضبط شو راح يعمل: “أنا راح أنشئ مورد واحد من نوع aws_instance بالاسم app_server”. بيعطيك خطة مفصلة قبل ما يلمس أي شي.
نصيحة من أبو عمر: إياك ثم إياك أن تنفذ
applyبدون ما تقرأ وتفهم كل سطر في مخرجاتplan. هذا الأمر هو شبكة الأمان تبعتك. -
terraform applyإذا كانت الخطة (plan) تمام وعجبتك، اكتب هذا الأمر. Terraform راح يسألك مرة ثانية للتأكيد، اكتب
yesواضغط Enter. الآن اجلس وشاهد السحر. Terraform راح يتواصل مع AWS وينشئ السيرفر تمامًا حسب المواصفات اللي حددتها. خلال دقيقة أو دقيقتين، السيرفر بكون جاهز.
ولو بدك تحذف كل شي؟ بسيطة، نفذ أمر terraform destroy. راح يحذف كل الموارد اللي أنشأها.
من خبرتي: نصائح ذهبية لترويض Terraform
بعد سنوات من استخدام Terraform في مشاريع صغيرة وكبيرة، تعلمت كم شغلة بحب أشاركها معكم:
1. لا تلمس الواجهة الرسومية (UI)!
بعد ما تبدأ تستخدم Terraform لإدارة مورد معين، اعتبر الواجهة الرسومية لمزود الخدمة للقراءة فقط. لو دخلت على AWS Console وغيرت إعداد في السيرفر يدويًا، أنت بتعمل إشي اسمه “Configuration Drift”. في المرة الجاية اللي بتشغل فيها Terraform، راح يكتشف هذا التغيير ويحاول يرجعه للحالة اللي في الكود. هذا بيسبب فوضى. خلي الكود هو المصدر الوحيد للحقيقة دائمًا.
2. استخدم المتغيرات (Variables) والملفات المنفصلة
لا تكتب القيم بشكل ثابت في الكود (Hardcoding). مثلاً، بدل ما تكتب region = "us-east-1" مباشرة، عرفها كمتغير. هذا بخلي الكود تبعك قابل لإعادة الاستخدام في بيئات مختلفة (تطوير، اختبار، إنتاج).
مثال: ملف `variables.tf`
variable "aws_region" {
description = "The AWS region to create resources in."
type = string
default = "us-east-1"
}
وفي ملف `main.tf` تستخدمه هكذا:
provider "aws" {
region = var.aws_region
}
3. ملف الحالة (State File): احمه كأنه حياتك!
ملف terraform.tfstate هو أخطر وأهم ملف. لا تحفظه أبدًا على جهازك المحلي لو بتشتغل في فريق. استخدم “الحالة عن بعد” (Remote State). أفضل ممارسة هي حفظه في مكان آمن ومشترك مثل AWS S3 Bucket مع تفعيل القفل (Locking) عشان ما يصير شخصين يغيروا على البنية التحتية بنفس الوقت.
4. ابدأ صغيرًا وتوسع تدريجيًا
لا تحاول تبني كل البنية التحتية العملاقة تبعتك في ملف Terraform واحد من أول يوم. ابدأ بجزء صغير، مثلاً الشبكة (VPC). بعدين أضف السيرفرات، ثم قواعد البيانات. قسم الكود تبعك لوحدات منطقية (Modules) كلما كبر المشروع.
الخلاصة: من الفوضى إلى الأوركسترا 🎼
الانتقال من الإعداد اليدوي إلى Terraform كان مثل الانتقال من فرقة موسيقية كل واحد فيها يعزف على كيفه، إلى أوركسترا متناغمة يقودها مايسترو واحد. بطلنا نخاف من إطلاق سيرفر جديد، بالعكس، صارت العملية بتاخذ دقايق وبضغطة زر، وبثقة 100% إن النتيجة راح تكون مطابقة تمامًا لكل السيرفرات الثانية.
صحيح، في البداية راح تحتاج وقت عشان تتعلم اللغة والمفاهيم، ويمكن تحس الموضوع معقد شوي. لكن صدقني، الجهد اللي راح تبذله في البداية راح يوفر عليك أضعاف مضاعفة من الوقت و”وجع الراس” في المستقبل.
نصيحتي الأخيرة: لا تنتظر لحد ما تصير معك “حادثة سامر” عشان تقتنع. ابدأ اليوم. أنشئ حساب مجاني على أي منصة سحابية، ونزل Terraform، وجرب بنفسك. هذه المهارة لم تعد رفاهية، بل أصبحت ضرورة أساسية لكل مطور ومهندس DevOps في عالم اليوم.
بالتوفيق يا جماعة الخير!