أذكرها وكأنها البارحة، ليلة إطلاق نسخة جديدة ومهمة من أحد تطبيقاتنا. كنا فريقًا صغيرًا، قلوبنا مليئة بالحماس وعيوننا تملؤها الأحلام… وقلة النوم. كانت الساعة قد تجاوزت الثانية صباحًا، وأنا وزميلي “أبو خليل” نجلس أمام شاشاتنا في سباق مع الزمن لإعداد البنية التحتية الجديدة على AWS.
كانت العملية أشبه بطقوس سحرية معقدة: افتح عشرين “تاب” في المتصفح، هنا ننشئ سيرفر EC2، وهناك نضبط الـ Security Group، لا تنسَ يا أبو عمر الـ IAM Role، وبالك يا أبو خليل حجم الـ EBS Volume. كل نقرة كانت مصحوبة بدعاء خافت: “يا رب تظبط”، “يا رب ما نكون نسينا إشي”. كانت بنيتنا التحتية تُبنى فعليًا بالدعاء والنقرات المتوترة.
وبالطبع، في خضم هذه الفوضى اليدوية، حدث ما كنا نخشاه. خطأ بسيط، خانة لم نؤشر عليها، صلاحية ناقصة… لا أحد يعلم بالضبط. والتطبيق لا يعمل. بدأ العرق يتصبب، والتوتر سيد الموقف. قضينا الساعات الثلاث التالية في عملية “تحقيق جنائي” رقمية، نقارن بين الشاشات والإعدادات، حتى اكتشفنا أننا نسينا فتح منفذ (Port) معين في أحد الـ Security Groups. خطأ تافه كلفنا ساعات من القلق وتأخيرًا في الإطلاق.
في تلك الليلة، بعد أن حُلّت المشكلة أخيرًا، نظر لي أبو خليل بعينين مُجهدتين وقال جملته التي لم أنسها: “يا زلمة، لازم يكون في طريقة أحسن من هالمعجنة!”. وكان معه كل الحق. تلك الليلة كانت بداية رحلتي للبحث عن “الطريقة الأحسن”، وهي الرحلة التي انتهت بي عند باب أداة غيّرت حياتي المهنية: Terraform.
ما هو جحيم النقرات اليدوية (Manual Clicking Hell)؟
قبل أن نغوص في الحل، دعونا نعترف بالمشكلة. “جحيم النقرات” الذي عشت فيه لسنوات هو ببساطة الاعتماد الكامل على واجهات الويب الرسومية (Web UI) لمزودي الخدمات السحابية (مثل AWS, Azure, Google Cloud) لإعداد وإدارة البنية التحتية.
قد تبدو هذه الواجهات صديقة للمبتدئين، لكنها تخفي خلفها كوارث حقيقية على المدى الطويل:
- الأخطاء البشرية: كما حدث معي، نسيان خطوة واحدة أو نقرة خاطئة يمكن أن يسبب مشاكل كارثية يصعب تتبعها.
- غياب التوثيق: بعد ستة أشهر، لا أحد يتذكر لماذا تم فتح هذا المنفذ أو سبب اختيار هذا النوع من السيرفرات. البنية التحتية تصبح صندوقًا أسود غامضًا.
- صعوبة التكرار: ماذا لو أردت إنشاء بيئة اختبار (Staging) مطابقة تمامًا للبيئة الإنتاجية (Production)؟ عليك إعادة طقوس النقرات والدعاء من جديد، مع أمل كبير في أن تكون متطابقة.
- بطء كارثي: بناء بيئة معقدة يدويًا يستغرق ساعات أو أيامًا. تعديلها؟ يا ويلك!
هنا يأتي مفهوم “البنية التحتية كشيفرة” أو Infrastructure as Code (IaC) ليقول: “كفى!”.
مفهوم البنية التحتية كشيفرة (IaC): الحل الشافي
تخيل معي لو أنك تستطيع وصف كل مكونات بنيتك التحتية – السيرفرات، قواعد البيانات، الشبكات، أسماء النطاقات – داخل ملفات نصية بسيطة، تمامًا كما تكتب كود تطبيقك. هذا هو جوهر الـ IaC.
بدلًا من النقر، أنت تكتب كودًا يصف الحالة النهائية التي تريد أن تكون عليها بنيتك التحتية. ثم تأتي أداة متخصصة، تقرأ هذا الكود، وتتحدث مع مزود الخدمة السحابية لتحويل هذا الوصف إلى حقيقة.
وهنا، يظهر بطل قصتنا: Terraform.
ما هو التيرافورم (Terraform) يا جماعة؟
Terraform هي أداة مفتوحة المصدر من شركة HashiCorp، أصبحت المعيار الفعلي في عالم الـ IaC. يمكن تشبيهها بالمترجم السحري الذي يأخذ “رغباتك” المكتوبة بلغة بسيطة (لغة HCL)، ويترجمها إلى أوامر يفهمها أكثر من 3000 مزود خدمة وتقنية، من AWS و Azure إلى Cloudflare و DigitalOcean.
لماذا Terraform بالذات؟
- لغة تعريفية (Declarative): أنت لا تخبر Terraform “كيف” ينشئ السيرفر خطوة بخطوة. أنت فقط تصف له “ماذا” تريد: “أنا بدي سيرفر بهاي المواصفات، وهي اسمه، وهاي الشبكة تبعته… ودبّر حالك”. هو يتكفل بالباقي.
- التخطيط قبل التنفيذ (Plan before Apply): هذه هي الميزة القاتلة. قبل أن يلمس Terraform أي شيء في حسابك، يقوم بتشغيل أمر
terraform planالذي يريك بالتفصيل الممل ما الذي سيتم إنشاؤه، أو تعديله، أو حذفه. لا مزيد من المفاجآت الخطيرة! - إدارة الحالة (State Management): يحتفظ Terraform بملف خاص يسمى “ملف الحالة” (State File)، يسجل فيه كل ما قام ببنائه. هذا يسمح له بمعرفة التغييرات المستقبلية وتطبيقها بذكاء.
- غير مرتبط بمزود واحد (Provider Agnostic): يمكنك استخدام نفس الأداة ونفس المبادئ لإدارة بنيتك التحتية سواء كانت على AWS أو GCP أو حتى خليط بينهما.
المشوار بيبدأ بخطوة: أول بنية تحتية لك مع Terraform
كلام جميل يا أبو عمر، لكن “فرجيني الشغل”. حسنًا، لنقم ببناء سيرفر ويب بسيط (EC2 Instance) على AWS باستخدام Terraform. لا تخف، العملية أبسط مما تتخيل.
الخطوة 1: كتابة الكود (ملف main.tf)
أنشئ ملفًا جديدًا باسم main.tf واكتب فيه الكود التالي. لقد أضفت تعليقات بالعربية لتوضيح كل جزء:
# main.tf
# -----------------------------------------------------
# إعدادات التيرافورم نفسه ومزود الخدمة (Provider)
# -----------------------------------------------------
terraform {
# نحدد هنا أننا سنستخدم مزود خدمة AWS
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0" # نحدد إصدار المزود لضمان الاستقرار
}
}
}
# هنا نقوم بتهيئة إعدادات الاتصال مع AWS
# مثل المنطقة (Region) التي سنعمل بها
provider "aws" {
region = "us-east-1" # يمكنك تغييرها لمنطقتك المفضلة
}
# -----------------------------------------------------
# تعريف الموارد (Resources) التي نريد إنشاءها
# -----------------------------------------------------
# هذا هو تعريف السيرفر (EC2 Instance)
# "aws_instance" هو نوع المورد
# "web_server" هو اسم منطقي نستخدمه داخل التيرافورم
resource "aws_instance" "web_server" {
# Amazon Machine Image (AMI) - هذا هو نظام التشغيل
# هذا الـ ID خاص بـ Amazon Linux 2 في منطقة us-east-1
ami = "ami-0c55b159cbfafe1f0"
# نوع السيرفر (حجمه وقدراته)
instance_type = "t2.micro" # هذا النوع مجاني ضمن Free Tier
# اسم السيرفر الذي سيظهر في واجهة AWS
tags = {
Name = "MyFirstWebServer-Terraform"
}
}
الخطوة 2: الثالوث المقدس (init, plan, apply)
الآن افتح الطرفية (Terminal) في نفس المجلد الذي يوجد به ملف main.tf وقم بتنفيذ الأوامر التالية بالترتيب:
terraform init
هذا الأمر يقوم بتهيئة المشروع وتنزيل “التعريفات” الخاصة بمزود AWS. فكّر فيه كأمرnpm installأوpip install. لن تحتاجه إلا مرة واحدة في البداية.terraform plan
الآن يبدأ السحر. سيقوم Terraform بتحليل الكود ومقارنته بالواقع (بما أنه لا يوجد شيء بعد)، ثم يعرض عليك خطة عمل مفصلة. سترى شيئًا كهذا:
Terraform will perform the following actions:
# aws_instance.web_server will be created
+ resource “aws_instance” “web_server” { … }Plan: 1 to add, 0 to change, 0 to destroy.
يا سلام! يخبرك بوضوح أنه سيقوم بإنشاء مورد واحد جديد.
terraform apply
إذا كانت الخطة تعجبك، نفّذ هذا الأمر. سيطلب منك تأكيدًا أخيرًا بكتابةyes. اكتبها واضغط Enter، ثم شاهد Terraform وهو يبني لك السيرفر في ثوانٍ معدودة.
مبارك! لقد قمت للتو ببناء أول قطعة من بنيتك التحتية باستخدام الكود. ولحذف كل شيء وتنظيف حسابك، ما عليك سوى تنفيذ أمر واحد: terraform destroy.
نصائح من العبد الفقير لله (أبو عمر)
بعد سنوات من استخدام Terraform في مشاريع صغيرة وكبيرة، تعلمت بعض الدروس بالطريقة الصعبة أحيانًا. إليك خلاصة خبرتي:
1. ملف الحالة (State File): قدس الأقداس!
ملف terraform.tfstate الذي يتم إنشاؤه هو عقل Terraform. لا، وألف لا، تقم بتعديله يدويًا أبدًا! هذا الملف هو مصدر الحقيقة الوحيد. وللعمل ضمن فريق، لا تخزنه على جهازك المحلي. استخدم ما يسمى بـ “الخلفيات البعيدة” (Remote Backends) مثل AWS S3 لتخزين هذا الملف مركزيًا وحمايته من الحذف أو التضارب.
2. نظّم شغلك، الله يرضى عليك
لا تضع كل شيء في ملف main.tf. مع نمو المشروع، ستصبح الأمور فوضوية. قسّم الكود إلى ملفات منطقية:
variables.tf: لتعريف المتغيرات (مثل اسم المنطقة، نوع السيرفر).outputs.tf: لعرض المخرجات المهمة (مثل عنوان IP العام للسيرفر).providers.tf: لتعريف المزودين.
3. لا تكرر نفسك: استخدم الوحدات (Modules)
إذا كنت تحتاج لإنشاء نفس مجموعة الموارد (مثلاً: سيرفر + قاعدة بيانات + Load Balancer) مرارًا وتكرارًا، فقم بتغليفها في “وحدة” (Module). الوحدة هي مجلد يحتوي على كود Terraform قابل لإعادة الاستخدام. “بتصير تبني العمارة بالطوب الجاهز مش تقعد تجبل طينة ورمل”.
4. الكود في Git، والبنية التحتية في أمان
منذ اللحظة الأولى، ضع كود Terraform الخاص بك في نظام إدارة الإصدارات مثل Git. هذا يمنحك قوة هائلة: سجل تاريخي لكل تغيير، معرفة من غيّر ماذا ومتى، والقدرة على التراجع بسهولة. هذا هو قلب ثقافة DevOps.
الخلاصة: من الدعاء إلى الكود 🙏
الرحلة من “جحيم النقرات” إلى عالم IaC المنظم مع Terraform كانت نقلة نوعية في مسيرتي المهنية. لم نعد نخشى عمليات الإطلاق، بل أصبحنا قادرين على إنشاء بيئات كاملة ومعقدة في دقائق، وتكرارها بثقة، وتعديلها بأمان. تخلصنا من الأخطاء البشرية القاتلة، وأصبح الكود هو الوثيقة الحية لبنيتنا التحتية.
نعم، هناك منحنى تعلم في البداية. ولكن صدقني، كل ساعة تقضيها في تعلم Terraform اليوم، ستوفر عليك أيامًا من القلق والعمل اليدوي المضني في المستقبل. ابدأ صغيرًا، بسيرفر واحد كما فعلنا، ولا تخف من التجربة. مستقبلك المهني، وراحتك النفسية قبل الإطلاقات القادمة، سيشكرانك. 🚀