أذكرها وكأنها البارحة، تلك الليلة التي كادت أن تقضي على ما تبقى من شعري. كنا، أنا وفريقي، على وشك إطلاق نسخة جديدة ومهمة من أحد تطبيقاتنا. قضينا أسابيع طويلة في التطوير والاختبار على بيئة التطوير (Development) وبيئة التجريب (Staging). كل شيء كان يعمل كالساعة، “زي الحلاوة” كما نقول. الثقة كانت في السماء، والقهوة تملأ الأكواب استعدادًا لسهرة الإطلاق.
الساعة دقت الثانية عشرة ليلًا، حان وقت الضغط على زر النشر (Deploy). بضع دقائق من الانتظار والترقب، ثم… بدأت الكارثة. إشعارات الأخطاء تنهال من كل حدب وصوب، المستخدمون يشتكون من تعطل الخدمة، ولوحة المراقبة (Dashboard) تشتعل باللون الأحمر. فجأة، تحولت جنة التطوير التي عشنا فيها إلى جحيم حقيقي في بيئة الإنتاج (Production).
بدأ السباق المحموم مع الزمن. “لكنها كانت تعمل على جهازي!”، “البيئة التجريبية كانت ممتازة!”، هذه الجمل ترددت في كل زاوية من المكتب. بعد ساعات من البحث والتدقيق، اكتشفنا السبب التافه والمحبط في نفس الوقت: نسخة مكتبة (library) معينة على خادم الإنتاج كانت أقدم ببضعة إصدارات بسيطة من تلك التي استخدمناها في التطوير، وإعداد في جدار الحماية (Firewall) كان مختلفًا، ومتغير بيئة (Environment Variable) كان ناقصًا. اختلافات صغيرة، لكنها كانت كافية لنسف كل شيء.
في تلك الليلة، أقسمت أنني لن أسمح لهذا “الوجع الراس” أن يتكرر. كانت تلك هي اللحظة التي بدأت فيها رحلتي الحقيقية مع مفهوم غيّر طريقة تفكيري وعملي إلى الأبد: البنية التحتية كشيفرة (Infrastructure as Code – IaC).
ما هي ‘البنية التحتية كشيفرة’ (IaC) وليش هي الحل؟
بكل بساطة، تخيل أنك تبني بيتًا. الطريقة التقليدية (اليدوية) هي أن تأتي بالعمال وتقول لهم: “ابنوا لي جدارًا هنا، وضعوا نافذة هناك”، وكل مرة تبني بيتًا جديدًا، تعيد نفس التعليمات الشفهية، مع احتمال كبير للخطأ والنسيان.
أما طريقة “البنية التحتية كشيفرة”، فهي أشبه بوجود مخطط هندسي دقيق ومفصل (Blueprint). هذا المخطط هو عبارة عن ملفات نصية (شيفرة)، تصف كل جزء من البيت بالتفصيل: أبعاد الجدران، نوع النوافذ، أماكن تمديدات الكهرباء والماء. إذا أردت بناء بيت آخر مطابق تمامًا، كل ما عليك هو أن تعطي العمال نفس المخطط. وإذا أردت تعديل شيء، فأنت تعدل المخطط أولًا، ثم يتم تطبيق التعديل على البيت.
هذا بالضبط ما تفعله IaC مع البنية التحتية لتطبيقاتك (الخوادم، قواعد البيانات، الشبكات، موازنات التحميل، إلخ). بدلًا من إعدادها يدويًا عبر واجهات الويب والنقرات (التي نسميها أحيانًا بسخرية “ClickOps”)، أنت تكتب شيفرة تصف هذه البنية التحتية. هذه الشيفرة تصبح المصدر الوحيد للحقيقة (Single Source of Truth).
مقارنة سريعة: الطريقة اليدوية مقابل IaC
- الإعداد اليدوي: بطيء، عرضة للأخطاء البشرية، صعب التكرار، مستحيل التوثيق بدقة، ويؤدي حتمًا إلى ما يسمى “انحراف البيئات” (Environment Drift) حيث تختلف بيئة التطوير عن الإنتاج مع مرور الوقت.
- البنية التحتية كشيفرة: سريعة وآلية، متسقة وقابلة للتكرار، موثقة ذاتيًا (الشيفرة هي التوثيق)، ويمكن مراجعتها وتتبع تغييراتها باستخدام أنظمة مثل Git، تمامًا مثل شيفرة التطبيق.
دخول Terraform إلى الساحة: المنقذ الذي انتظرته
هناك العديد من الأدوات لتطبيق مفهوم IaC، مثل AWS CloudFormation, Azure Resource Manager, Ansible، وغيرها. لكن الأداة التي وقعت في حبها والتي أنصح بها بشدة هي Terraform من شركة HashiCorp.
لماذا Terraform بالذات؟
- محايدة تجاه السحابة (Cloud-Agnostic): يمكنك استخدامها لإدارة البنية التحتية على AWS, Google Cloud, Azure, DigitalOcean وحتى على خوادمك الخاصة (On-premise). نفس المبادئ ونفس طريقة الكتابة تقريبًا.
- لغة تعريفية (Declarative): أنت تصف “الحالة النهائية” التي تريد أن تكون عليها بنيتك التحتية، وTerraform تتكفل بمعرفة “كيف” تصل إلى هذه الحالة. لا تخبرها “أنشئ خادمًا”، بل قل لها “أريد أن يكون هناك خادم بهذه المواصفات”.
- مجتمع ضخم ودعم واسع: أي شيء يخطر ببالك، غالبًا ستجد له “مزود خدمة” (Provider) جاهزًا في Terraform.
مثال عملي: بناء بيئة بسيطة متطابقة باستخدام Terraform
دعونا نأخذ مثالًا عمليًا بسيطًا يوضح قوة Terraform. لنفترض أننا نريد إنشاء بيئة تطوير وبيئة إنتاج، كل منهما تحتوي على خادم ويب بسيط على أحد مزودي الخدمات السحابية (سأستخدم AWS كمثال، لكن المبدأ يطبق على غيره).
الفكرة هي أننا سنكتب شيفرة Terraform مرة واحدة، ونستخدمها لإنشاء بيئتين متطابقتين تمامًا، مع تغييرات بسيطة فقط (مثل اسم البيئة).
الخطوة 1: تنظيم الملفات
من أفضل الممارسات هو فصل البيئات. هيكل الملفات قد يبدو كالتالي:
project/
├── modules/
│ └── webserver/
│ ├── main.tf
│ └── variables.tf
├── environments/
│ ├── development/
│ │ └── main.tf
│ └── production/
│ └── main.tf
الخطوة 2: كتابة الوحدة النمطية (Module) القابلة لإعادة الاستخدام
في ملف modules/webserver/main.tf، سنصف الخادم. استخدام الوحدات النمطية (Modules) يجعل الشفرة نظيفة وقابلة لإعادة الاستخدام.
# modules/webserver/main.tf
# تعريف متغيرات للتحكم في الوحدة
variable "instance_type" {
description = "The type of the EC2 instance"
type = string
default = "t2.micro"
}
variable "env_name" {
description = "The name of the environment (e.g., dev, prod)"
type = string
}
# إنشاء مجموعة أمان (جدار حماية) للسماح بحركة مرور الويب
resource "aws_security_group" "web_sg" {
name = "${var.env_name}-web-sg"
description = "Allow HTTP and SSH traffic"
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # للمثال فقط، في الواقع يجب تحديد IP معين
}
}
# إنشاء الخادم نفسه
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # مثال لـ Amazon Linux 2 AMI
instance_type = var.instance_type
security_groups = [aws_security_group.web_sg.name]
tags = {
Name = "${var.env_name}-web-server"
Environment = var.env_name
}
}
الخطوة 3: استخدام الوحدة لإنشاء بيئة التطوير والإنتاج
الآن، سنستخدم هذه الوحدة في كل بيئة. لاحظ كيف أن الشيفرة أصبحت بسيطة جدًا.
لبيئة التطوير (environments/development/main.tf):
# environments/development/main.tf
# تهيئة مزود الخدمة
provider "aws" {
region = "us-east-1"
}
# استدعاء الوحدة النمطية لإنشاء خادم التطوير
module "dev_webserver" {
source = "../../modules/webserver" # المسار إلى الوحدة
env_name = "development"
instance_type = "t2.micro" # يمكننا استخدام خادم صغير للتطوير
}
لبيئة الإنتاج (environments/production/main.tf):
# environments/production/main.tf
# تهيئة مزود الخدمة
provider "aws" {
region = "us-east-1"
}
# استدعاء نفس الوحدة لإنشاء خادم الإنتاج
module "prod_webserver" {
source = "../../modules/webserver" # نفس الوحدة تمامًا
env_name = "production"
instance_type = "t3.small" # قد نحتاج خادمًا أقوى للإنتاج
}
لاحظ الجمال هنا! نفس الشيفرة الأساسية بالضبط استخدمت لإنشاء البيئتين. الاختلاف الوحيد هو في المتغيرات التي نمررها (اسم البيئة وحجم الخادم). هذا يضمن أن قواعد جدار الحماية، ونوع نظام التشغيل، وكل الإعدادات الدقيقة الأخرى متطابقة 100%. لا مجال للخطأ البشري.
نصيحة من أبو عمر: في بيئة الإنتاج الحقيقية، ستكون هناك اختلافات مقصودة (مثل حجم الخادم)، لكن IaC تضمن أن هذه الاختلافات مقصودة وموثقة في الشيفرة، وليست نتيجة نسيان أو خطأ عشوائي.
نصائح أبو عمر الذهبية للبدء مع IaC
بعد سنوات من العمل مع Terraform، هذه بعض النصائح التي أتمنى لو أخبرني بها أحدهم في البداية:
- ابدأ صغيرًا: لا تحاول تحويل كل بنيتك التحتية الحالية إلى شيفرة دفعة واحدة. ابدأ بمشروع جديد، أو جزء صغير ومنعزل من بنيتك الحالية.
- خزّن ملف الحالة (State File) عن بعد: ملف الحالة هو “ذاكرة” Terraform. لا تخزنه على جهازك المحلي أبدًا! استخدم التخزين عن بعد (Remote Backend) مثل Amazon S3 أو Terraform Cloud. هذا يسمح للفريق بالعمل معًا ويمنع فقدان حالة البنية التحتية.
- استخدم Git لكل شيء: تعامل مع شيفرة البنية التحتية كما تتعامل مع شيفرة تطبيقك. ضعها في Git، استخدم الفروع للميزات الجديدة، وقم بمراجعة الشيفرة (Code Review) قبل دمج أي تغيير.
- لا تكرر نفسك (DRY): إذا وجدت نفسك تنسخ وتلصق كتلًا من الشيفرة، فهذا هو الوقت المناسب لإنشاء “وحدة نمطية” (Module) كما في مثالنا.
- ضع وسومًا (Tags) على كل شيء: الوسوم هي صديقك المفضل لتنظيم الموارد وتتبع التكاليف. اجعل وضع الوسوم جزءًا إلزاميًا من شيفرتك.
الخلاصة: من الجحيم إلى الجنة المنظمة
التحول إلى “البنية التحتية كشيفرة” لم يكن مجرد حل لمشكلة تقنية، بل كان تحولًا في العقلية. لقد نقلنا من عالم الفوضى والإطفاء اليدوي للحرائق إلى عالم من النظام والهدوء والثقة. الآن، عندما نطلق نسخة جديدة، نحن على يقين تام بأن البيئة التي سننشر عليها مطابقة لتلك التي اختبرنا عليها، لأن كلتيهما تم بناؤهما من نفس المخطط الهندسي، من نفس الشيفرة.
قد تبدو البداية معقدة، وهناك منحنى تعلمي، لكن صدقني، الجهد الذي ستبذله في البداية سيوفر عليك أضعافه من ساعات العمل الإضافية، والضغط النفسي، وليالي الإطلاق الكارثية. بالآخر، راحة البال لا تقدر بثمن. 👍
