كان كل سيرفر جديد مغامرة: كيف أنقذنا Terraform من جحيم التكوين اليدوي؟

يا جماعة، السلام عليكم ورحمة الله وبركاته، معكم أبو عمر.

خلوني أحكيلكم قصة صارت معي قبل كم سنة، أيام ما كنا “نطبخ” السيرفرات على إيدينا. كانت ليلة خميس، وكنا على وشك إطلاق ميزة جديدة ومهمة في تطبيقنا. فجأة، ومع زيادة الضغط على الموقع، قررنا إنه لازم نضيف سيرفر جديد فورًا عشان يستوعب الحمل. طبعًا، كانت الساعة 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.

المتطلبات الأساسية

  1. تثبيت Terraform CLI على جهازك.
  2. حساب على 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) في نفس المجلد اللي فيه الملف، ونفذ الأوامر التالية بالترتيب:

  1. terraform init

    هذا الأمر بجهز بيئة العمل. Terraform بيقرأ الكود، وبيشوف إنك بدك تستخدم مزود الخدمة AWS، فبيقوم بتنزيل الإضافات اللازمة له. بتعمله مرة وحدة بس في كل مشروع.

  2. terraform plan

    هذا أهم أمر في Terraform برأيي. الأمر هذا بيعمل “محاكاة”. بيقارن الكود اللي كتبته مع الوضع الحالي (اللي هو لا شيء في البداية)، وبيحكيلك بالضبط شو راح يعمل: “أنا راح أنشئ مورد واحد من نوع aws_instance بالاسم app_server”. بيعطيك خطة مفصلة قبل ما يلمس أي شي.

    نصيحة من أبو عمر: إياك ثم إياك أن تنفذ apply بدون ما تقرأ وتفهم كل سطر في مخرجات plan. هذا الأمر هو شبكة الأمان تبعتك.

  3. 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 في عالم اليوم.

بالتوفيق يا جماعة الخير!

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التكنلوجيا المالية Fintech

من الكوابيس الورقية إلى الحلول الرقمية: كيف حررتنا تقنية OCR من جحيم التحقق من الهوية (KYC)؟

التحقق من هوية العميل (KYC) كان عملية يدوية مرهقة ومصدرًا للأخطاء الكارثية. في هذه المقالة، أشارككم كـ "أبو عمر" قصتي مع هذا الكابوس، وكيف أنقذتنا...

11 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كان الجميع يهز رأسه موافقاً: كيف أنقذتنا ‘ثقافة الأمان النفسي’ من جحيم الإجماع الزائف؟

في عالم تطوير البرمجيات، قد يكون الاتفاق السريع والمُجامل أخطر من الخلاف الواضح. هذه قصتي كـ "أبو عمر" مع "الإجماع الزائف" وكيف أصبحت ثقافة الأمان...

11 مايو، 2026 قراءة المزيد
اختبارات الاداء والجودة

كنا نطلق الميزات على أمل ألا ينهار النظام: كيف أنقذنا اختبار الحِمل (Load Testing) باستخدام k6 من جحيم التخمين؟

هل تطلق ميزات جديدة وأنت تدعو الله ألا ينهار الخادم؟ في هذه المقالة، أشارككم قصة حقيقية عن كيف انتقلنا من التخمين والقلق إلى الثقة والبيانات...

11 مايو، 2026 قراءة المزيد
أتمتة العمليات

كانت ‘ليالي الإطلاق’ كابوساً: كيف أنقذنا ‘خط أنابيب CI/CD’ من جحيم النشر اليدوي؟

أتذكر جيداً تلك الليالي المليئة بالتوتر والأخطاء الكارثية. في هذه المقالة، أشارككم قصة حقيقية ومفصلة حول كيف انتقلنا كفريق من فوضى النشر اليدوي إلى عالم...

10 مايو، 2026 قراءة المزيد
نصائح برمجية

كان إطلاق الميزات الجديدة كابوساً: كيف أنقذتنا ‘أعلام الميزات’ (Feature Flags) من جحيم عمليات النشر عالية المخاطر؟

تذكرون تلك الليالي الطوال التي نقضيها في إصلاح الأخطاء بعد كل عملية نشر؟ في هذه المقالة، أشارككم قصة كيف حولت 'أعلام الميزات' (Feature Flags) عمليات...

10 مايو، 2026 قراءة المزيد
​معمارية البرمجيات

لماذا اتخذنا هذا القرار؟: كيف أنقذتنا ‘سجلات القرارات المعمارية’ (ADRs) من جحيم النسيان

أشارككم قصة حقيقية من قلب المعركة البرمجية، وكيف أن أداة بسيطة تُدعى "سجلات القرارات المعمارية" (ADRs) أصبحت طوق النجاة لفريقي. اكتشفوا كيف يمكن لتوثيق "لماذا"...

10 مايو، 2026 قراءة المزيد
خوارزميات

كان البحث في موقعنا كالبحث عن إبرة في كومة قش: كيف أنقذتنا ‘خوارزمية البحث الثنائي’ من جحيم تجربة المستخدم البطيئة؟

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

10 مايو، 2026 قراءة المزيد
البودكاست