تثبيت Terraform وربطه مع مزود خدمة سحابي (AWS أو DigitalOcean) عبر الـ API

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

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

في هذا الدليل سنثبت Terraform، ثم نربطه مع مزود سحابي عبر API باستخدام AWS أو DigitalOcean، مع شرح معماري لطريقة عمل Providers، وآلية المصادقة، وأفضل الممارسات الأمنية اللازمة قبل دمجه لاحقاً داخل CI/CD.

كيف يعمل Terraform مع المزودات السحابية؟

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

هذا التصميم يمنحك ثلاث مزايا مهمة:

• إمكانية توحيد إدارة عدة منصات سحابية بأداة واحدة.
• إعادة استخدام نفس أسلوب العمل عبر البيئات المختلفة.
• سهولة دمج البنية مع أنظمة الأتمتة وخطوط النشر.

بعد فهم هذه الفكرة، يصبح الربط عبر API Token أو بيانات اعتماد Access Keys خطوة منطقية، لأن كل عملية إنشاء أو تحديث أو حذف ستُنفذ برمجياً وليس من لوحة التحكم الرسومية.

تثبيت Terraform على Linux

أفضل ممارسة هي تثبيت النسخة الرسمية من المصدر المعتمد لضمان التحديثات والتوافق مع إضافات المزودات. على توزيعات Ubuntu أو Debian يمكن التثبيت كالتالي:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt-get update && sudo apt-get install -y terraform
terraform -version

إذا ظهرت نسخة الأداة بشكل صحيح، فهذا يعني أن التثبيت ناجح وأن النظام أصبح جاهزاً لتنزيل Providers المطلوبة عند تهيئة المشروع.

بناء هيكل مشروع Terraform نظيف

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

mkdir terraform-cloud-project
cd terraform-cloud-project
touch main.tf variables.tf outputs.tf .gitignore

أما ملف .gitignore فمن المهم أن يمنع رفع الملفات الحساسة أو الملفات المؤقتة:

echo ".terraform/
terraform.tfstate
terraform.tfstate.backup
*.tfvars" > .gitignore

لا ترفع ملف terraform.tfstate إلى مستودع عام، لأنه قد يحتوي معرفات بنية داخلية، عناوين IP، وأحياناً بيانات حساسة حسب نوع الموارد المستخدمة.

ربط Terraform مع DigitalOcean عبر API Token

يعد DigitalOcean مناسباً للتعلم السريع بسبب بساطة موارده ووضوح واجهته. ابدأ بإنشاء Personal Access Token من لوحة التحكم، ثم خزنه محلياً كمتغير بيئي:

export DIGITALOCEAN_TOKEN="your_digitalocean_token"

بعدها اكتب ملف main.tf بهذا الشكل:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

variable "do_token" {
  type      = string
  sensitive = true
}

resource "digitalocean_droplet" "web" {
  name   = "tf-web-01"
  region = "fra1"
  size   = "s-1vcpu-1gb"
  image  = "ubuntu-22-04-x64"
}

output "droplet_ip" {
  value = digitalocean_droplet.web.ipv4_address
}

ثم مرر قيمة المتغير أثناء التنفيذ:

terraform init
terraform plan -var="do_token=$DIGITALOCEAN_TOKEN"
terraform apply -var="do_token=$DIGITALOCEAN_TOKEN"

أمر init يقوم بتنزيل الإضافة المناسبة، بينما plan يعرض الفرق بين المطلوب والحالي، وapply ينفذ الإنشاء فعلياً.

ربط Terraform مع AWS عبر Access Keys

في بيئة AWS تكون المرونة أعلى، لكن التعقيد كذلك أكبر بسبب تعدد الخدمات مثل EC2 وVPC وIAM. أنشئ مستخدماً برمجياً بصلاحيات محدودة، ثم خزّن مفاتيحه في متغيرات بيئية:

export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_DEFAULT_REGION="eu-central-1"

بعد ذلك استخدم ملف main.tf التالي:

terraform {
  required_version = ">= 1.5.0"

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

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

resource "aws_instance" "web" {
  ami           = "ami-0ec7f9846da6b0f61"
  instance_type = "t3.micro"

  tags = {
    Name = "tf-ec2-web-01"
  }
}

output "instance_public_ip" {
  value = aws_instance.web.public_ip
}

نفّذ بعدها الأوامر المعتادة:

terraform init
terraform plan
terraform apply

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

فهم دورة العمل: Plan ثم Apply ثم Destroy

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

ودورة التشغيل السليمة تكون عادة كالتالي:

1. كتابة تعريف الموارد داخل الملفات.
2. تشغيل terraform fmt لتوحيد التنسيق.
3. تشغيل terraform validate لاكتشاف أخطاء الصياغة.
4. مراجعة plan.
5. تنفيذ apply بعد التأكد.
6. تنفيذ destroy عند الحاجة لإزالة البيئة بشكل منظم.

terraform fmt
terraform validate
terraform plan
terraform apply
terraform destroy

أفضل الممارسات الأمنية قبل إدخال Terraform في CI/CD

عندما تنقل هذه العملية إلى منصات الأتمتة، يجب أن تتعامل مع الأسرار بحذر شديد. لهذا يُنصح بمراجعة إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة قبل وضع أي مفاتيح داخل مسارات النشر.

استخدم مبدأ Least Privilege عند إنشاء حسابات API. لا تمنح حساب Terraform صلاحيات حذف شامل أو إدارة موارد لا يحتاجها، لأن أي خطأ في السكربت أو المسار قد يسبب Downtime أو فقدان بنية إنتاجية كاملة.

كما يُفضّل دمج فحوصات البنية داخل خط أنابيب آلي مشابه لما يحدث في ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟، بحيث لا يتم تطبيق أي تغيير قبل اجتياز التحقق، والمراجعة، والموافقة البشرية عند الحاجة.

خلاصة عملية

تثبيت Terraform وربطه مع AWS أو DigitalOcean ليس مجرد خطوة تقنية معزولة، بل هو حجر أساس لبناء بنية قابلة للتكرار، والمراجعة، والتوسع. عندما تصبح الخوادم والشبكات معرفة داخل ملفات، يمكنك اختبارها، أرشفتها، ومزامنتها مع فرق العمل بثقة أعلى بكثير من الإدارة اليدوية.

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