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

يا أهلاً وسهلاً فيكم يا جماعة الخير. خلوني اليوم أحكيلكم قصة صارت معي زمان، قصة من أيام ما كان الشعر أسود والهمّة توزن بلاد. كنا قاعدين في المكتب، فريق صغير بقلب كبير، وبنجهز لإطلاق منتج جديد اشتغلنا عليه ليل نهار. كل شي كان جاهز على سيرفر التجربة (Staging)، شغال زي الساعة، الله وكيلكم.

قبل يوم الإطلاق، قعدنا أنا والشباب نجهز السيرفر الإنتاجي (Production). فتحنا ملف `instructions.txt` المقدس، اللي فيه مئات الأوامر اللي لازم ننسخها ونلصقها بالترتيب. أمر ورا أمر، تثبيت برامج، تعديل ملفات إعدادات… شغل أربع خمس ساعات متواصلة. خلصنا شغلنا، فحصنا كل شي بشكل سريع، وبدا كل شي تمام. قلنا “الحمد لله” وروحنا ننام عشان نصحى لليوم الكبير.

وفي يوم الإطلاق، ومع أول ضغط من المستخدمين، بلّش الموقع ينهار. أخطاء غريبة، بطء قاتل، وخدمات بتوقع وبتقوم لحالها. قضيناها ليلة ما يعلم فيها إلا ربنا، بنقارن ملفات الإعدادات بين سيرفر الإنتاج وسيرفر التجربة سطر بسطر. بعد ساعات من التوتر والقهوة البايتة، اكتشفنا المصيبة: نسخة مكتبة (library) معينة كانت مختلفة بين السيرفرين، فرق بسيط في رقم الإصدار كان سبب كل هالكابوس. وقتها ضربت إيدي على مكتبي وقلت: “لازم نلاقي حل، هالشغل اليدوي هاد مش رح يوصلنا لمحل!”. ومن هنا بدأت رحلتي مع ما يسمى “البنية التحتية كشيفرة”.

ما هو جحيم الإعداد اليدوي؟

قبل ما نحكي عن الحل، خلونا نوصف المشكلة بوضوح. الطريقة القديمة في إدارة الخوادم، اللي أنا بسميها “شغل العَجَلَة”، كانت بتعتمد على الخطوات التالية:

• تشتري سيرفر جديد من أي مزود خدمة (AWS, DigitalOcean, etc).
• تتصل فيه عن طريق SSH.
• تبدأ حفلة النسخ واللصق من ملف نصي أو “ويكي” داخلي.
• sudo apt-get update، sudo apt-get install nginx php mysql...
• تفتح ملفات الإعدادات باستخدام `vim` أو `nano` وتعدل فيها يدوياً.
• إذا نسيت فاصلة منقوطة أو كتبت حرف غلط… الله يكون في عونك.

مشاكل هذه الطريقة “العتيقة”

هذه الطريقة، يا جماعة، هي وصفة مضمونة للمشاكل. ليش؟

• عدم الاتساق (Inconsistency): زي ما صار معنا، أقل اختلاف بين بيئة التطوير والإنتاج ممكن يسبب كوارث. “شغالة عندي” بتصير جملة بتسمعها كل يوم.
• بطيئة وعرضة للخطأ: العملية بتاخد وقت طويل، وكل خطوة يدوية هي فرصة جديدة لخطأ بشري.
• صعبة التوثيق: مين يضمن إن ملف التعليمات محدّث؟ ومين يتذكر ليش ضفنا هذاك السطر الغريب في ملف الإعدادات قبل ست شهور؟
• كارثة عند التوسع (Scalability): إذا احتجت فجأة 10 سيرفرات جديدة لمواجهة ضغط مفاجئ، هل رح تقضي أسبوع كامل في إعدادهم يدوياً؟
• خوادم “ندفات الثلج” (Snowflake Servers): كل سيرفر بصير قطعة فنية فريدة من نوعها، مستحيل إعادة إنتاجها بالضبط لو تعطل. إذا راح السيرفر، بتروح معه أسراره.

البنية التحتية كشيفرة (Infrastructure as Code – IaC): الحل السحري

تخيل معي لو بتقدر توصف كل البنية التحتية تبعتك (سيرفرات، قواعد بيانات، شبكات، جدران نارية) في ملفات نصية، زي ما بتكتب كود التطبيق تبعك بالضبط. تخيل لو بتقدر تحفظ هاي الملفات في Git، تراجع التغييرات، تتعاون مع فريقك، وبضغطة زر واحدة، تبني كل هاي البنية التحتية من الصفر بشكل متطابق 100% في كل مرة.

هذا هو جوهر الـ IaC. ببساطة، هي معاملة البنية التحتية كأنها برمجيات.

نصيحة من أبو عمر: التحول لـ IaC هو تحول في العقلية قبل ما يكون تحول في الأدوات. لازم تقتنع إن أي تغيير على السيرفرات لازم يتم من خلال الكود، مش بتسجيل الدخول اليدوي. انسى أمر الـ SSH إلا للطوارئ القصوى.

مرحباً بـ Terraform: المنقذ

هناك أدوات كثيرة في عالم الـ IaC، لكن اللي سرق قلبي وعقلي هو Terraform من شركة HashiCorp. ليش بالذات Terraform؟

• تعريفية (Declarative): إنت بتوصف “الحالة النهائية” اللي بدك ياها، و Terraform هو اللي بيفكر في “كيف” يوصل لهاي الحالة. ما بتحكيله “اعمل الخطوة 1 ثم 2 ثم 3″، لأ، بتحكيله “أنا بدي سيرفر بهاي المواصفات، وقاعدة بيانات بهاي المواصفات، اربطهم ببعض”. وهو بتكفل بالباقي.
• متعددة المنصات (Multi-Cloud): بتقدر تستخدم نفس الأداة ونفس طريقة التفكير لإدارة بنيتك التحتية على AWS, Google Cloud, Azure, DigitalOcean وغيرها كتير. ما بتحصر حالك مع مزود واحد.
• إدارة الحالة (State Management): هاي هي الميزة القاتلة. Terraform بحافظ على ملف اسمه “state” بسجل فيه كل الموارد اللي أنشأها. وبهيك، هو بيعرف شو الموجود على أرض الواقع، ولما تعدل الكود، هو بيقارن الكود الجديد مع الحالة المسجلة وبيعرف بالضبط شو لازم يضيف أو يعدل أو يحذف.

يلا نشوف الكود: مثال عملي بسيط

الكلام النظري حلو، بس “الحكي ما بيطعمي خبز”. خلونا نشوف مثال حقيقي بسيط لإنشاء سيرفر (Droplet) على DigitalOcean باستخدام Terraform.

أول شي، منعمل ملف اسمه `main.tf`.

# 1. تحديد المزود (Provider) اللي رح نشتغل عليه
# بنحكيله إنه رح نستخدم DigitalOcean
terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

# هون بتحط الـ API Token تبعك
# الأفضل تستخدم متغيرات البيئة عشان الأمان
provider "digitalocean" {
  token = var.do_token
}

# 2. تعريف متغير عشان ما نكتب التوكن مباشرة في الكود
variable "do_token" {
  description = "DigitalOcean API Token"
  type        = string
  sensitive   = true # هاي بتمنع التيرافورم من طباعة القيمة على الشاشة
}

# 3. تعريف المورد (Resource) اللي بدنا ننشئه
# هون بنحكي لتيرافورم: "أنشئ لنا سيرفر Droplet"
resource "digitalocean_droplet" "web_server" {
  image    = "ubuntu-22-04-x64" # نوع النظام
  name     = "my-first-web-server" # اسم السيرفر
  region   = "fra1" # المنطقة (فرانكفورت كمثال)
  size     = "s-1vcpu-1gb" # حجم السيرفر
  tags     = ["web", "terraform-demo"]
}

# 4. (اختياري) إخراج عنوان IP الخاص بالسيرفر الجديد
output "server_ip" {
  value = digitalocean_droplet.web_server.ipv4_address
  description = "The public IP address of the web server."
}

دورة حياة Terraform: ثلاث أوامر تغير حياتك

بعد ما كتبنا الكود، كيف نحوله لسيرفر حقيقي؟ العملية بسيطة ومكونة من 3 خطوات رئيسية:

1. terraform init: هذا الأمر بتشغله مرة واحدة في كل مشروع. بيقوم بتنزيل الـ provider (في حالتنا DigitalOcean) وبيجهز مجلد العمل.
2. terraform plan: هذا هو “بر الأمان”. الأمر هاد بقرأ الكود تبعك، وبقارنه بالحالة الحالية، وبعطيك خطة مفصلة بكل شي رح يعمله: “أنا رح أضيف السيرفر الفلاني، ورح أحذف الإعداد الفلاني…”. بتقرأ الخطة وبتتأكد إن كل شي تمام قبل ما تنفذ أي شي. نصيحة: “قيس قبل ما تغطس”، وهذا الأمر هو أداة القياس.
3. terraform apply: إذا عجبتك الخطة، بتكتب هذا الأمر. Terraform رح يسألك مرة ثانية للتأكيد، وبعدها رح يقوم بتنفيذ الخطة وإنشاء البنية التحتية على أرض الواقع. اقعد واشرب فنجان قهوة وشوف السحر وهو بصير.

ولو بدك تهدم كل شي وتنظف وراك، عشان ما تدفع فاتورة على الفاضي، في أمر رابع هدية: terraform destroy. بيمسح كل شي أنشأه Terraform في هذا المشروع.

نصائح عملية من خبرة أبو عمر

• لا تخزن ملف الحالة (State File) على جهازك: ملف `terraform.tfstate` هو روح المشروع. إذا كنت بتشتغل لحالك ممكن تمشيها، بس لو في فريق، لازم تخزنوا الملف هاد في مكان مشترك وآمن زي AWS S3 أو Azure Blob Storage. هذا ما يسمى بـ “Remote Backend”.
• قسّم شغلَك: لا تحط كل البنية التحتية في ملف `main.tf` واحد عملاق. استخدم “الموديلات” (Modules) لتقسيم الكود لوحدات منطقية قابلة لإعادة الاستخدام (موديل للشبكة، موديل للسيرفرات، موديل لقاعدة البيانات).
• المتغيرات هي صديقك الصدوق: استخدم ملف `variables.tf` لتعريف كل المتغيرات (زي المنطقة، حجم السيرفر، اسم البيئة). هيك بتقدر تعيد استخدام نفس الكود لبيئة التجربة والإنتاج، بس بتمرير قيم مختلفة للمتغيرات.
• إياك ثم إياك كتابة الأسرار في الكود: كلمات المرور، مفاتيح الـ API، وغيرها من المعلومات الحساسة مكانها مش في الكود. استخدم أدوات إدارة الأسرار مثل HashiCorp Vault أو خدمات إدارة الأسرار المدمجة في المنصات السحابية.

الخلاصة: استثمر في راحة بالك ✅

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

القصة مش قصة كود وأتمتة وبس، القصة قصة بناء أنظمة قوية وموثوقة بتسمحلك تركز على الأهم: كتابة كود يحل مشاكل حقيقية ويضيف قيمة للمستخدمين. من الآخر، Terraform أعطانا مش بس سيرفرات متطابقة، بل أعطانا أهم شي للمبرمج: راحة البال. 🚀