بنيتنا التحتية كانت قلاعًا من رمل: كيف أنقذنا Terraform من جحيم الـ ‘ClickOps’ اليدوي؟

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

بدأ السباق مع الزمن لإعادة بناء السيرفر يدويًا من خلال واجهة AWS. أنا وزميلي “أبو كريم”، كل واحد في بيته، نصرخ عبر مكالمة الفيديو: “يا زلمة، هل فتحت بورت 443 في الـ Security Group؟” يرد هو: “فتحتها، متأكد!”. وبعد نصف ساعة من الدوران في حلقة مفرغة، نكتشف أنه فتحها في مجموعة أمنية أخرى بالخطأ. وفي خضم الفوضى، نسينا تمامًا إرفاق “IAM Role” معين كان ضروريًا للوصول إلى خدمات أخرى.

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

ما هو جحيم الـ “ClickOps” الذي كنا نعيش فيه؟

قبل أن نغوص في الحل، دعوني أشرح لكم الوحش الذي كنا نحاربه. ما فعلناه في تلك الليلة يسمى في عالم التقنية “ClickOps”. إنه ببساطة مصطلح يصف عملية إدارة البنية التحتية (سيرفرات، قواعد بيانات، شبكات، إلخ) عن طريق النقر على الأزرار والقوائم في الواجهات الرسومية لمزودي الخدمات السحابية مثل AWS, Azure, أو Google Cloud.

قد يبدو الأمر سهلاً ومغريًا في البداية، ولكن مع نمو النظام، يتحول إلى كابوس حقيقي. لماذا؟

لماذا هو “جحيم”؟

• عرضة للخطأ البشري: كما حدث معنا، من السهل جدًا نسيان خطوة، أو النقر على الخيار الخاطئ تحت الضغط. ذاكرة الإنسان ليست وثيقة يمكن الاعتماد عليها.
• بطيء وغير فعال: تخيل أنك تحتاج إلى إنشاء بيئة تطوير جديدة مطابقة تمامًا للبيئة الإنتاجية. كم من الوقت سيستغرق ذلك يدويًا؟ ساعات؟ أيام؟ مع خطر عدم تطابق البيئتين في النهاية.
• غياب التوثيق والشفافية: من الذي أضاف قاعدة جدار الحماية هذه؟ ومتى؟ ولماذا؟ مع ClickOps، الإجابة غالبًا ما تكون “لا أحد يعلم”. لا يوجد سجل تغييرات واضح مثل الذي نحصل عليه مع Git.
• صعوبة التكرار والاستنساخ: كل سيرفر يتم إعداده يدويًا هو “ندفة ثلج” فريدة من نوعها (Snowflake Server). من المستحيل تقريبًا ضمان أن سيرفرين تم إعدادهما يدويًا متطابقان 100%.
• مخاطر أمنية: نسيان إغلاق منفذ تجريبي، أو تطبيق صلاحيات أوسع من اللازم… كلها أخطاء شائعة في عالم النقرات اليدوية.

Terraform: المخلّص من فوضى النقرات

هنا يدخل البطل إلى القصة: Terraform. أداة مفتوحة المصدر من شركة HashiCorp تسمح لك بتطبيق مفهوم يسمى البنية التحتية كود (Infrastructure as Code – IaC).

الفكرة بسيطة وعبقرية: بدلًا من النقر لإنشاء مواردك، أنت تكتب كودًا يصف هذه الموارد. أنت تعامل بنيتك التحتية بنفس الطريقة التي تعامل بها كود تطبيقك: تضعه في نظام إدارة نسخ (مثل Git)، تراجعه مع زملائك، وتقوم بتطبيقه بشكل آلي ومتكرر.

كيف يعمل Terraform؟

يعتمد Terraform على نهج “تعريفي” (Declarative). هذا يعني أنك لا تكتب الأوامر خطوة بخطوة (هذا يسمى النهج “الأمري” – Imperative). بدلًا من ذلك، أنت ببساطة تصف الحالة النهائية التي تريد أن تكون عليها بنيتك التحتية، وTerraform يتولى معرفة كيفية الوصول إلى تلك الحالة.

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

دورة العمل الأساسية في Terraform تتكون من ثلاث خطوات:

1. Write (اكتب): تقوم بكتابة الكود الذي يصف بنيتك التحتية باستخدام لغة HCL (HashiCorp Configuration Language)، وهي لغة سهلة القراءة والكتابة.
2. Plan (خطط): تقوم بتشغيل أمر terraform plan. هذا الأمر لن يغير أي شيء، ولكنه سيعرض لك بالضبط ما الذي سيقوم Terraform بفعله (ماذا سيضيف، ماذا سيعدل، وماذا سيحذف). هذه هي شبكة الأمان الخاصة بك.
3. Apply (طبّق): بعد مراجعة الخطة والتأكد من صحتها، تقوم بتشغيل أمر terraform apply لتنفيذ التغييرات وإنشاء بنيتك التحتية.

من النظرية إلى التطبيق: بناء أول سيرفر لنا بـ Terraform

الكلام النظري جميل، ولكن دعونا نرى كيف يبدو هذا على أرض الواقع. لنقم بإنشاء سيرفر (EC2 Instance) بسيط على AWS باستخدام Terraform.

الخطوة الأولى: تهيئة المشروع

كل مشروع Terraform يبدأ بملف يحدد “المزوّد” (Provider) الذي سنتعامل معه (AWS, Azure, Google Cloud, وغيرها الكثير). سننشئ ملفًا باسم main.tf ونضع فيه الكود التالي:

# تحديد المزود الذي سنستخدمه (في حالتنا AWS)
# وتحديد المنطقة التي سيتم إنشاء الموارد فيها
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

هذا الكود يخبر Terraform أننا سنتعامل مع AWS في منطقة “us-east-1”.

الخطوة الثانية: تعريف الموارد

الآن، لنضف “المورد” (Resource) الذي نريد إنشاءه، وهو السيرفر. سنضيف الكود التالي إلى نفس ملف main.tf:

resource "aws_instance" "web_server" {
  # Amazon Machine Image (AMI) - نظام التشغيل
  ami           = "ami-0c55b159cbfafe1f0" # Ubuntu 22.04 LTS for us-east-1

  # نوع السيرفر (حجمه وقدراته)
  instance_type = "t2.micro"

  # الوسوم (Tags) لتنظيم الموارد
  tags = {
    Name        = "MyFirstTerraformServer"
    Environment = "Development"
  }
}

نصيحة من أبو عمر: يا جماعة، استخدموا الـ tags دائمًا! لا تستهينوا بها. هي ليست مجرد زخرفة. الوسوم تساعدكم على تنظيم شغلكم، وفلترة الموارد، ومعرفة تكلفة كل مشروع أو بيئة على حدة. إنها تنقذكم من فوضى كبيرة في المستقبل.

الخطوة الثالثة: التنفيذ والمشاهدة

الآن بعد أن أصبح الكود جاهزًا، افتح الطرفية (Terminal) في مجلد المشروع وقم بتشغيل الأوامر التالية بالترتيب:

1. terraform init: هذا الأمر يتم تشغيله مرة واحدة في البداية. يقوم بتنزيل الإضافات اللازمة للمزوّد (provider) الذي حددناه (AWS في حالتنا).
2. terraform plan: هذا هو أمر “الفحص الأخير”. سيقوم Terraform بتحليل الكود وعرض خطة التنفيذ. سترى شيئًا كهذا:

   An execution plan has been generated and is shown below.
   Resource actions are indicated with the following symbols:
     + create
   
   Terraform will perform the following actions:
   
     # aws_instance.web_server will be created
     + resource "aws_instance" "web_server" {
         + ami           = "ami-0c55b159cbfafe1f0"
         + instance_type = "t2.micro"
         + tags          = {
             + "Environment" = "Development"
             + "Name"        = "MyFirstTerraformServer"
           }
         # (many other attributes will be created)
       }
   
   Plan: 1 to add, 0 to change, 0 to destroy.

   لاحظ علامة + الخضراء، التي تعني أن هذا المورد سيتم إنشاؤه.

3. terraform apply: إذا كانت الخطة تبدو صحيحة، قم بتشغيل هذا الأمر. سيطلب منك Terraform تأكيد التنفيذ بكتابة “yes”. بعد لحظات، سيتم إنشاء السيرفر الخاص بك في حساب AWS!

بوم! خلال دقائق، وبأوامر بسيطة، أصبح لديك سيرفر موثّق في الكود، يمكنك إعادة إنشائه في أي وقت بنفس المواصفات بالضبط. وإذا أردت تدميره، فكل ما عليك هو تشغيل terraform destroy.

ما بعد الأساسيات: الارتقاء بلعبة الـ IaC

إنشاء سيرفر واحد هو مجرد البداية. قوة Terraform الحقيقية تظهر في بناء أنظمة معقدة وإدارتها بكفاءة.

المتغيرات (Variables) والمخرجات (Outputs)

بدلًا من كتابة القيم مثل t2.micro مباشرة في الكود، من الأفضل استخدام المتغيرات. هذا يجعل الكود أكثر مرونة وقابلية لإعادة الاستخدام. يمكنك إنشاء ملف variables.tf:

variable "instance_type" {
  description = "The type of EC2 instance to launch."
  type        = string
  default     = "t2.micro"
}

ثم تستخدمه في ملف main.tf هكذا: instance_type = var.instance_type.

وبالمثل، يمكنك استخدام المخرجات (Outputs) للحصول على معلومات من الموارد التي تم إنشاؤها، مثل عنوان IP العام للسيرفر. أنشئ ملف outputs.tf:

output "instance_public_ip" {
  description = "Public IP address of the web server instance."
  value       = aws_instance.web_server.public_ip
}

الحالة (State) – قلب Terraform النابض

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

نصيحة أبو عمر الحاسمة: أوعك، ثم أوعك، ثم أوعك تحفظ ملف الـ state على جهازك الشخصي أو ترفعه على Git مباشرة! هذا الملف قد يحتوي على معلومات حساسة، وإذا عملت في فريق، فسيؤدي إلى فوضى عارمة. الحل الصحيح هو استخدام “Remote Backend”، مثل تخزين ملف الحالة في AWS S3 bucket مع تفعيل القفل (Locking) باستخدام DynamoDB. هذا يضمن أن شخصًا واحدًا فقط يمكنه إجراء تغييرات في كل مرة، ويحافظ على أمان الحالة وتوافرها للفريق بأكمله.

الوحدات (Modules) – لا تكرر نفسك

عندما تبدأ بنيتك التحتية في النمو، ستجد نفسك تكرر نفس الكتل البرمجية مرارًا وتكرارًا (مثلًا، كود إنشاء سيرفر مع مجموعة أمنية مرتبطة به). هنا تأتي قوة الوحدات (Modules). الوحدة هي مجموعة من ملفات Terraform التي يتم تجميعها معًا كوحدة منطقية واحدة. يمكنك إنشاء وحدة “web-server” قابلة لإعادة الاستخدام، ثم استدعاؤها عدة مرات لإنشاء سيرفرات متعددة، كل منها بإعدادات مختلفة قليلًا.

خلاصة الكلام: من قلاع الرمل إلى حصون الكود 🏰

الرحلة من تلك الليلة المليئة بالتوتر والنقرات العشوائية إلى اليوم الذي ندير فيه بنيتنا التحتية بالكامل عبر كود Terraform كانت تحويلية. لم نعد نخاف من الأعطال، لأننا نستطيع إعادة بناء أي جزء من نظامنا في دقائق، وبشكل موثوق 100%. لم نعد نتجادل حول من غيّر ماذا، لأن كل تغيير مسجل في Git. أصبحت عملية إنشاء بيئات جديدة أمرًا روتينيًا لا يستغرق سوى بضعة أوامر.

الانتقال إلى البنية التحتية كود (IaC) باستخدام Terraform ليس مجرد “موضة” تقنية أو رفاهية. إنه استثمار أساسي في استقرار وأمان وسرعة أي مشروع تقني جاد. إنه ينقل بنيتك التحتية من كونها قلاعًا هشة من رمل إلى حصون منيعة مبنية على الكود.

نصيحتي الأخيرة لك: لا تخف من البداية. ابدأ صغيرًا. خذ مكونًا واحدًا بسيطًا من بنيتك التحتية الحالية وحاول إعادة بنائه باستخدام Terraform. جرب، ارتكب الأخطاء، تعلم من ملف الـ plan، واقرأ التوثيق الرسمي الممتاز. الخطوة الأولى هي الأصعب دائمًا، لكن العائد على المدى الطويل لا يقدر بثمن. يلا، شدوا حيلكم! 💪