مشروع التخرج (الجزء 1): استخدام Terraform لبناء سيرفرات المشروع الآلية

مقدمة: لماذا يبدأ مشروع التخرج من البنية التحتية وليس من الكود فقط؟

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

لهذا السبب أصبحت البنية التحتية ككود (IaC): لماذا يجب أن نتخلى عن إنشاء السيرفرات يدوياً؟ خطوة تأسيسية في أي مشروع جاد. باستخدام Terraform نستطيع تعريف الشبكات، السيرفرات، عناوين IP، وقواعد الوصول في ملفات واضحة وقابلة للمراجعة.

هذا النهج لا يختصر الوقت فقط، بل يرفع موثوقية المشروع بالكامل. وعندما نربط هذا المسار لاحقاً مع CI/CD وعمليات التهيئة باستخدام Ansible، يتحول مشروع التخرج من مجرد تطبيق إلى منصة تشغيل حقيقية قابلة للتوسع.

التصميم المعماري المقترح لمشروع تخرج قابل للنمو

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

مكونات البنية الأساسية

• شبكة خاصة VPC لعزل الموارد.
• سيرفر تطبيق App Server لتشغيل الواجهة الخلفية.
• سيرفر عكسي Nginx Reverse Proxy أو نقطة دخول وحيدة.
• قاعدة بيانات مُدارة أو معزولة عن السيرفرات العامة.
• مجموعة قواعد أمان Security Groups لتقييد المنافذ.

هذا التقسيم يسهّل لاحقاً الانتقال من التشغيل التقليدي إلى الحاويات. وإذا كنت قد قرأت مشكلة “الكود يعمل على جهازي فقط” وكيف يحلها Docker نهائياً؟ فستدرك أن توحيد بيئة التشغيل يبدأ من طبقة البنية، وليس من الحاوية فقط.

لا تفتح المنفذ 22 للعالم كله في بيئة الإنتاج. الأفضل قصر الوصول عبر SSH Keys ومن IP إداري معروف فقط لتقليل سطح الهجوم.

هيكلة ملفات Terraform داخل المشروع

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

• provider.tf لتعريف المزود السحابي.
• variables.tf للمتغيرات.
• network.tf للشبكات والجدران النارية.
• compute.tf للسيرفرات.
• outputs.tf لإخراج القيم مثل public_ip.

وعند كبر المشروع، ستحتاج غالباً إلى استخدام الوحدات (Modules) في Terraform لتنظيم الكود وإعادة استخدامه حتى لا تكرر نفس منطق البناء لكل بيئة.

مثال عملي: إنشاء مزود وشبكة وسيرفر تطبيق

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

terraform {
  required_version = ">= 1.5.0"

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

provider "aws" {
  region = var.aws_region
}

variable "aws_region" {
  default = "eu-central-1"
}

variable "project_name" {
  default = "graduation-project"
}

variable "instance_type" {
  default = "t3.micro"
}

variable "my_ip" {
  description = "Admin IP in CIDR format"
  type        = string
}

resource "aws_vpc" "main" {
  cidr_block           = "10.10.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "${var.project_name}-vpc"
  }
}

resource "aws_security_group" "app_sg" {
  name        = "${var.project_name}-app-sg"
  description = "Security group for app server"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.my_ip]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "app_server" {
  ami                    = "ami-xxxxxxxx"
  instance_type          = var.instance_type
  vpc_security_group_ids = [aws_security_group.app_sg.id]

  tags = {
    Name = "${var.project_name}-app"
    Role = "application"
  }
}

output "app_server_public_ip" {
  value = aws_instance.app_server.public_ip
}

إذا كنت ما زلت في المراحل الأولى، فراجع أيضاً كتابة أول ملف Terraform لإنشاء سيرفر (VPS) سحابي برمجياً وأوامر Terraform الأساسية المذهلة (Init, Plan, Apply, Destroy) لفهم دورة التنفيذ قبل توسيع البنية.

كيف نربط Terraform مع التهيئة الآلية بعد الإنشاء؟

وظيفة Terraform هي بناء الموارد، لا إدارة كل تفصيلة داخل نظام التشغيل. لذلك من الممارسات السليمة استخدامه لإنشاء السيرفرات، ثم تمرير المخرجات إلى Ansible لتثبيت الحزم وتهيئة الخدمات.

هذا الفصل بين مرحلتي Provisioning وConfiguration Management يجعل الصيانة أوضح. فمثلاً يمكن لـ Terraform إنشاء سيرفر التطبيق، ثم يتولى أول Playbook لك: تثبيت البرامج (مثل Nginx و Node) آلياً بلغة YAML تجهيز البيئة البرمجية.

تسلسل العمل الموصى به

1. تنفيذ terraform init.
2. مراجعة خطة التغييرات عبر terraform plan.
3. بناء الموارد باستخدام terraform apply.
4. سحب قيم outputs.
5. تمرير عنوان السيرفر إلى Ansible Inventory.
6. تشغيل Playbook التهيئة.

أهمية إدارة الحالة وعدم تخزينها بعشوائية

أحد أخطر الأخطاء في مشاريع الطلبة هو تجاهل ملف terraform.tfstate. هذا الملف هو مصدر الحقيقة الذي يخبر الأداة بما تم إنشاؤه فعلياً في السحابة. ضياعه أو العبث به قد يؤدي إلى إعادة إنشاء موارد أو فقدان السيطرة عليها.

لهذا من الأفضل منذ البداية فهم إدارة حالة البنية التحتية (Terraform State) وكيف تحافظ عليها من الضياع. في البيئات الجادة يتم استخدام remote backend مع قفل للملف حتى لا يكتب أكثر من شخص على الحالة نفسها في الوقت ذاته.

لا تقم برفع ملفات الحالة أو متغيرات الأسرار إلى المستودع العام على GitHub. بعض هذه الملفات قد تحتوي على معرفات حساسة أو بنية داخلية تسهّل استهداف البيئة.

العلاقة بين Terraform و CI/CD في مشروع التخرج

القيمة الحقيقية تظهر عندما تنتقل من التنفيذ اليدوي إلى المسارات المؤتمتة. يمكن تشغيل اختبارات التطبيق أولاً، ثم في مرحلة لاحقة تنفيذ تحديثات البنية عبر مسار مدروس داخل GitHub Actions أو Jenkins.

إذا كنت قد اطلعت على ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ ومشروع عملي: بناء CI/CD كامل يختبر وينشر تطبيق ويب إلى السيرفر آلياً فستلاحظ أن البنية المؤتمتة تجعل دورة التسليم أكثر أماناً، لأن كل تغيير يصبح قابلاً للتتبع والمراجعة والرجوع عنه.

أفضل ممارسة عملية

• افصل بين بيئة staging وproduction.
• نفّذ plan تلقائياً، واسمح بـ apply بعد موافقة بشرية.
• خزّن المفاتيح عبر إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة.

خاتمة: بناء السيرفرات آلياً هو أول دليل على نضج المشروع

استخدام Terraform في مشروع التخرج لا يعني فقط إنشاء سيرفر بسرعة، بل يعني أنك تصمم بيئة قابلة للتكرار، قابلة للتدقيق، وقابلة للتسليم لفريق آخر دون فوضى. هذه هي الروح الحقيقية للعمل السحابي الحديث كما شرحنا سابقاً في ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟.

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