أذكرها وكأنها البارحة، ليلة ثلاثاء شتوية قاسية. كنت قد أنهيت يوم عمل طويل، وجلست أخيراً مع العائلة لأحتسي كوب الشاي بالمرمية الذي لا يكتمل اليوم بدونه. فجأة، رنّ الهاتف. على الطرف الآخر كان صوت أحد المطورين الشباب في الفريق، متوتراً ومذعوراً: “أبو عمر، الحقنا! الموقع واقع! كل شيء لا يعمل!”.
شعرت بالدم يغلي في عروقي. “شو القصة يا زلمة؟ شو اللي صار؟”. هرولت إلى مكتبي، فتحت اللابتوب، وبدأت رحلة البحث عن الإبرة في كومة قش. السيرفرات تعمل، قواعد البيانات تستجيب، لكن التطبيق نفسه يصرخ بأخطاء غامضة. بعد ساعتين من البحث المحموم، والضغط النفسي، والقهوة التي بردت بجانبي، اكتشفنا المشكلة: أحدهم، بنية حسنة على الأغلب، قام بتغيير إعداد بسيط في “Security Group” على AWS أثناء محاولته حل مشكلة أخرى، مما أدى إلى قطع الاتصال بين سيرفر التطبيق وقاعدة البيانات.
في تلك اللحظة، لم يكن السؤال “من فعل هذا؟” بقدر ما كان “كيف نمنع هذا الجحيم من التكرار؟”. كانت بنيتنا التحتية بأكملها مبنية على النقرات في واجهة AWS الرسومية، بلا توثيق، بلا تاريخ، وبلا أي طريقة لمعرفة “مين غيّر هالإعداد؟”. كانت قصراً من رمال، ينهار مع كل موجة تغيير غير متوقعة. هنا قررنا أن هذا الوضع لا يمكن أن يستمر، وكانت تلك الليلة هي نقطة التحول التي قادتنا إلى عالم الـ Infrastructure as Code، وتحديداً إلى Terraform.
ما هي “البنية التحتية ككود” (IaC)؟
ببساطة، تخيل أنك بدل ما تدخل على لوحة تحكم أمازون (AWS) أو جوجل (GCP) أو أزور (Azure) وتبدأ بالضغط على الأزرار لإنشاء سيرفر جديد، أو قاعدة بيانات، أو شبكة افتراضية… أنت تكتب ملفاً نصياً بسيطاً يصف كل هذه المكونات.
هذا الملف هو “الكود” الذي يمثل بنيتك التحتية. تريد سيرفر بمواصفات معينة؟ اكتبها في الكود. تريد فتح منفذ (port) محدد؟ اكتبه في الكود. تريد إنشاء 5 سيرفرات متشابهة؟ سطر واحد في الكود يفي بالغرض.
هذا المفهوم يحل مشاكلنا الجذرية:
- التوثيق التلقائي: الكود نفسه هو أفضل توثيق للبنية التحتية.
- تاريخ التغييرات: عندما تضع هذا الكود في نظام مثل Git، يمكنك معرفة من غيّر ماذا ومتى ولماذا. لا مزيد من ألغاز “مين اللي لعب بالإعدادات؟”.
- التكرار والاتساق: يمكنك إعادة بناء نفس البنية التحتية بالضبط في أي وقت، على بيئة التطوير أو الإنتاج، بضغطة زر.
- المراجعة والتعاون: يمكن للمطورين مراجعة تغييرات البنية التحتية (Pull Requests) قبل تطبيقها، تماماً مثل كود التطبيق.
أهلاً بـ Terraform: المنقذ من فوضى الإعدادات اليدوية
Terraform هي أداة مفتوحة المصدر من شركة HashiCorp، وهي أشهر وأقوى أداة لتطبيق مفهوم الـ IaC. جمال Terraform يكمن في بساطته وقوته في آن واحد.
لماذا Terraform بالذات؟
- لغة وصفية (Declarative): أنت لا تخبر Terraform “كيف” ينشئ الأشياء خطوة بخطوة (هذا يسمى Imperative). بل تخبره “ماذا” تريد في النهاية (End State)، وهو يتكفل بمعرفة كيفية الوصول إلى تلك الحالة. هذا يقلل من التعقيد بشكل هائل.
- متعدد المنصات (Multi-Cloud): هل تستخدم AWS؟ ممتاز. هل تريد إضافة بعض الخدمات من DigitalOcean؟ لا مشكلة. هل لديك سيرفرات في مركز بياناتك الخاص؟ Terraform يدعم كل هذا وأكثر عبر ما يسمى بالـ “Providers”. أنت لست مقيداً بمزود خدمة واحد.
- إدارة الحالة (State Management): يحتفظ Terraform بملف خاص (اسمه `terraform.tfstate`) يسجل فيه كل ما قام بإنشائه. هذا الملف هو “ذاكرة” Terraform. من خلاله، يعرف ما هي الموارد الموجودة حالياً، وعندما تقوم بتغيير الكود، يقارن الحالة الجديدة بالحالة المسجلة ويخبرك بالضبط بما سيقوم بإنشائه، أو تعديله، أو حذفه.
من القول إلى الفعل: لنبني أول سيرفر لنا بـ Terraform
يكفي كلام نظري، “الحكي ما بطعمي خبز”. دعونا نرى كيف يمكننا إنشاء سيرفر (EC2 instance) على AWS باستخدام Terraform في خطوات بسيطة.
الخطوة الأولى: التحضيرات (ما تحتاجه لتبدأ)
قبل كل شيء، تحتاج إلى شيئين:
- تثبيت Terraform على جهازك (يمكنك تحميله من موقعه الرسمي).
- إعداد حساب AWS وتهيئة بيانات الاعتماد (Access Keys) على جهازك حتى يتمكن Terraform من التواصل مع حسابك.
الخطوة الثانية: كتابة الكود (ملف main.tf)
أنشئ مجلداً جديداً لمشروعك، وبداخله أنشئ ملفاً باسم main.tf. الصق الكود التالي بداخله:
# نحدد إصدار Terraform المطلوب ومزود الخدمة (Provider)
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
}
}
# تهيئة مزود الخدمة AWS وتحديد المنطقة (Region)
provider "aws" {
region = "eu-west-1" # يمكنك تغييرها إلى المنطقة التي تفضلها
}
# هنا نصف "المورد" (Resource) الذي نريد إنشاءه
# في حالتنا، هو سيرفر EC2
resource "aws_instance" "my_first_server" {
# Amazon Machine Image (AMI) - يحدد نظام التشغيل
# هذا الـ AMI خاص بـ Ubuntu 20.04 في منطقة eu-west-1
ami = "ami-0d16c2e81fe339d2c"
# نوع السيرفر (Instance Type) - يحدد قوة المعالج والذاكرة
instance_type = "t2.micro" # هذا النوع ضمن الطبقة المجانية لـ AWS
# إضافة وسم (Tag) لتمييز السيرفر
tags = {
Name = "MyFirstTerraformServer"
}
}
نصيحة أبو عمر: الـ `ami` يختلف من منطقة لأخرى. تأكد من استخدام الـ AMI ID الصحيح للمنطقة ونظام التشغيل الذي اخترته.
الخطوة الثالثة: التنفيذ (الأوامر السحرية الثلاثة)
الآن افتح الطرفية (Terminal) في مجلد مشروعك وقم بتنفيذ الأوامر التالية بالترتيب:
-
terraform init
هذا الأمر مثل “تجهيز العدّة”. يقوم بتحميل الـ provider الخاص بـ AWS الذي حددناه في الكود ويجهز بيئة العمل. لن تحتاجه إلا مرة واحدة في البداية. -
terraform plan
هذا هو الأمر المفضل عندي. يقوم Terraform بتحليل الكود ومقارنته بالحالة الحالية (في البداية، لا شيء) ويخبرك بالضبط بما سيقوم بفعله. سترى مخرجات توضح أنه سيقوم بإنشاء “resource” جديد من نوع `aws_instance`. هذا الأمر هو شبكة الأمان الخاصة بك، لا مفاجآت بعد اليوم! -
terraform apply
“نفّذ يا كبير!”. بعد أن رأيت الخطة ووافقت عليها، هذا الأمر يقوم بتنفيذها فعلياً. سيطلب منك تأكيداً بكتابة `yes`. بعد لحظات، اذهب إلى لوحة تحكم AWS وستجد سيرفرك الجديد بانتظارك!
وإذا أردت تدمير ما بنيته؟ ببساطة نفذ أمر terraform destroy.
نصائح من قلب الميدان: كيف تستخدم Terraform كالمحترفين
بعد سنوات من استخدام Terraform في مشاريع صغيرة وكبيرة، هذه بعض النصائح التي تعلمتها بالطريقة الصعبة أحياناً:
1. لا تلمس ملف الحالة (State File) بيدك!
ملف `terraform.tfstate` مقدس. تعديله يدوياً هو وصفة لكارثة. والأهم، عندما تعمل ضمن فريق، لا تترك هذا الملف على جهازك المحلي. استخدم “Remote State Backend” مثل AWS S3. هذا يضمن أن كل أعضاء الفريق يعملون على نفس الحالة المحدثة ويمنع تضارب التغييرات.
2. نظّم الكود باستخدام الوحدات (Modules)
عندما يكبر مشروعك، سيصبح ملف `main.tf` ضخماً وفوضوياً. الـ Modules في Terraform هي مثل الدوال (Functions) في البرمجة. تسمح لك بتغليف أجزاء من البنية التحتية (مثلاً، سيرفر مع إعدادات الشبكة والأمان الخاصة به) في وحدة قابلة لإعادة الاستخدام. هذا يجعل الكود أنظف وأسهل في الإدارة.
3. كل شيء في Git… كل شيء!
كود Terraform الخاص بك يجب أن يعيش في نظام إدارة إصدارات مثل Git. هذا هو جوهر الموضوع. الآن، أي تغيير في البنية التحتية يجب أن يمر عبر Pull Request. يمكنك مراجعته، مناقشته، واختباره قبل دمجه وتطبيقه. أمر `git blame` على ملف `.tf` سيخبرك بالضبط “مين غيّر هالإعداد؟” ومتى ولماذا. لقد أغلقنا دائرة الجحيم تلك.
4. ابدأ صغيراً وتوسع
لا تحاول نقل كل بنيتك التحتية الحالية إلى Terraform دفعة واحدة. هذا طريق طويل ومتعب. ابدأ بمشروع جديد، أو بخدمة صغيرة غير حرجة. تعلم، اكتسب الثقة، ثم ابدأ بنقل الأجزاء الأهم تدريجياً.
الخلاصة: من قصر الرمال إلى قلعة صخرية 🏰
التحول إلى Terraform لم يكن مجرد تغيير تقني، بل كان تغييراً في العقلية والثقافة. انتقلنا من الخوف والقلق مع كل عملية نشر (Deployment)، إلى الثقة والسرعة. لم نعد نخشى السؤال “من غيّر هذا؟”، لأن الإجابة أصبحت موثقة وواضحة في تاريخ Git. لقد حوّلنا قصرنا الرملي الذي كان ينهار باستمرار إلى قلعة صخرية، أساسها الكود، وأسوارها عمليات المراجعة، وبرج مراقبتها هو أمر `terraform plan`.
إذا كنت لا تزال تدير بنيتك التحتية يدوياً، أتمنى أن تكون قصتي دافعاً لك. نعم، هناك منحنى تعلم في البداية، ولكن العائد على الاستثمار هائل. ابدأ اليوم، ابدأ صغيراً، ولن تندم أبداً. بالتوفيق يا جماعة!
