البنية التحتية ككود بـ Terraform: وقّف ضبط السيرفرات بإيدك

المستوى: متوسط. الشرح يفترض إنك تعرف يعني إيه سيرفر و SSH، لكن معملتش Infrastructure as Code قبل كده. الافتراض كمان إن بنيتك على مزوّد سحابي بيدعمه Terraform (AWS أو GCP أو Azure أو DigitalOcean) وإن عندك أقل من بضع مئات من الموارد.

البنية التحتية ككود: يعني إيه، وليه Terraform؟

لو بتظبط كل سيرفر بإيدك من كونسول المزوّد، إنت بتضيّع وقت وبتراكم أخطاء متنسهاش. الكلام اللي جاي هيخلّيك تكتب بنيتك مرة واحدة في ملف نصّي، وتعيد إنشاءها بنفس النتيجة بالظبط في أقل من دقيقتين.

المشكلة باختصار

الضبط اليدوي بيفشل في حاجتين: التكرار والتوثيق. لو حبيت تعمل بيئة staging مطابقة للـ production، هتفضل تدوّس أزرار في الكونسول وتنسى إعداد أو اتنين. وبعد 6 شهور محدش هيفتكر ليه الـ security group مفتوح على بورت معيّن. النتيجة: بيئات مختلفة بشكل غامض، و«بيشتغل عندي مش عندك».

مثال يقرّب الفكرة

تخيّل إنك بتفرش شقة. الطريقة اليدوية: تروح المحل، تختار كل قطعة، وتركّبها بإيدك. لو حبيت تفرش شقة تانية بالظبط زيها، هتعيد كل الخطوات من الأول، وأكيد هتنسى تفصيلة. الطريقة التانية: تكتب «قايمة تجهيز» فيها كل قطعة ومكانها، وتدّي القايمة لشركة تفرشلك أي عدد شقق متطابقة. لو غيّرت سطر في القايمة، الفرش يتعدّل من غير ما تلمس حاجة بإيدك.

الـ Infrastructure as Code هي «القايمة» دي، بس للسيرفرات والشبكات وقواعد البيانات.

التعريف العلمي

الـ Infrastructure as Code هي وصف موارد البنية التحتية في ملفات نصّية تُدار بنظام إصدارات (زي Git)، بحيث تبقى البنية قابلة للمراجعة والتكرار والتراجع. Terraform أداة مفتوحة من HashiCorp بتقرأ الملفات دي وتخلّي الواقع مطابق للمطلوب. هي تصريحية (declarative): إنت بتوصف «الحالة النهائية» اللي عايزها، وهي بتحسب الخطوات اللازمة توصلها، مش إنت اللي بتكتب الخطوات.

مثال تنفيذي: 3 سيرفرات في ملف واحد

الملف ده بيوصف مزوّد AWS وثلاث نسخ EC2 متطابقة. احفظه باسم main.tf.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

resource "aws_instance" "web" {
  count         = 3
  ami           = "ami-0abc12345example"
  instance_type = "t3.micro"

  tags = {
    Name = "web-${count.index}"
  }
}

بعدها تشغّل ثلاث أوامر بالترتيب:

# 1) تنزيل المزوّد وتجهيز المجلد
terraform init

# 2) معاينة اللي هيحصل — من غير ما يلمس أي مورد
terraform plan

# 3) تنفيذ التغييرات فعليًا على السحابة
terraform apply

الفرق بين plan و apply — ركّز هنا

الـ plan بيقارن الحالة الحالية باللي انت طالبه في الملف، ويطبعلك الفرق (diff) بالظبط: هيضيف إيه، هيعدّل إيه، هيمسح إيه. مفيش أي تغيير بيحصل في الخطوة دي. الـ apply هو اللي بينفّذ الفرق ده على المزوّد. القاعدة العملية: اقرا مخرجات plan كويس قبل أي apply على production.

الـ State: دفتر الحسابات بتاع Terraform

Terraform بيحتفظ بملف اسمه terraform.tfstate، وده «الدفتر» اللي بيسجّل فيه إيه اللي أنشأه فعلاً. من غير الدفتر ده، هو مش هيعرف إن الـ 3 سيرفرات موجودين أصلاً، فيحاول ينشئهم تاني. لو بتشتغل مع فريق، ممنوع تسيب الـ state على جهازك المحلي — خزّنه remote مع قفل (locking) عشان اتنين ما يعملوش apply في نفس اللحظة ويبوّظوا الحالة.

terraform {
  backend "s3" {
    bucket         = "my-tfstate-bucket"
    key            = "prod/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
}

الأرقام اللي بتفرق

إنشاء 3 سيرفرات متطابقة يدويًا من الكونسول بياخد 15 إلى 20 دقيقة، وعرضة لخطأ بشري في أي إعداد. terraform apply بيعملها في أقل من دقيقتين وبنفس النتيجة كل مرة. وأهم من ده: إعادة بناء بيئة staging كاملة من الصفر بتنزل من ساعات ضبط يدوي لـ أمر واحد. دي أرقام تقديرية بتختلف حسب حجم البنية ومزوّدك، لكن الترتيب بيفضل ثابت.

الـ trade-offs بصراحة

• بتكسب: تكرار مضمون، توثيق حي للبنية، مراجعة عبر Pull Requests، وتراجع سريع لو تغيير وقع حاجة.
• بتخسر: منحنى تعلّم للغة HCL ومفاهيم الـ providers، ووقت إعداد أولي.
• خطر لازم تنتبه له: ملف الـ state ممكن يحتوي قيم حساسة، ولو اتسرّب أو بُوظ تدخل في مشكلة. اعزله remote، شفّره، وامنع الوصول له.

متى لا تستخدم Terraform

لو عندك سيرفر واحد ثابت مش بيتغير أبدًا، أو بتعمل تجربة سريعة use-and-throw، فالـ IaC overhead مالوش لازمة. وأهم شرط: لو الفريق مش هيلتزم إن كل تغيير يعدّي على Terraform. أول ما حد يعدّل مورد يدوي من الكونسول، بيحصل «انحراف» (drift) بين الملف والواقع، وساعتها الأداة بتكدب عليك بدل ما تساعدك.

الخطوة التالية

افتح حساب سحابي تجريبي، حط ملف main.tf اللي فوق، وشغّل terraform plan بس — من غير apply. اقرا الـ diff اللي هيطلعلك سطر بسطر؛ ده هيوريك بالظبط Terraform ناوي يعمل إيه قبل ما يلمس أي مورد. لو الخطة عجبتك، ساعتها بس اعمل apply.

المصادر

• توثيق Terraform الرسمي — HashiCorp: developer.hashicorp.com/terraform/docs
• مقدمة Terraform و Infrastructure as Code: developer.hashicorp.com/terraform/intro
• أمر terraform plan: developer.hashicorp.com/terraform/cli/commands/plan
• إدارة الـ State و الـ Remote Backends: developer.hashicorp.com/terraform/language/state/remote
• موفّر AWS على Terraform Registry: registry.terraform.io/providers/hashicorp/aws/latest/docs