Terraform مقابل Ansible: أيهما تحتاج فعلاً؟

الأشخاص الجدد في Infrastructure as Code عادة ما يطرحون هذا بإحدى طريقتين: "أي أداة يجب أن أتعلمها أولاً" أو "لماذا تستخدم الفرق كليهما." الإجابة المختصرة أن Terraform و Ansible يحلان مشاكل مختلفة، وأغلب الإعدادات الإنتاجية تستخدمهما معاً بدلاً من اختيار واحدة.

ما الذي Terraform مخصص له فعلاً

Terraform هي أداة provisioning. تصرح بما يجب أن توجد عليه البنية التحتية: VPC، ثلاث instances من EC2، قاعدة بيانات RDS، S3 bucket بسياسة معينة. تكتب HCL يوضح الحالة النهائية، تشغل terraform plan لترى ما سيتغير، ثم terraform apply لتنفيذ ذلك. Terraform تحافظ على ملف state (محلياً أو في backend مثل S3 bucket مع قفل DynamoDB) يربط الإعدادات بمعرفات الموارد الحقيقية عند مزود الخدمة.

القوة هنا في حل التبعيات عبر المزودين. إذا قلت لـ Terraform أن تنشئ مجموعة أمان وتربطها بـ EC2 instance، فإنها تحدد الترتيب تلقائياً. كما أنها تعمل مع AWS و Azure و GCP و Cloudflare و Datadog وعشرات المزودين الآخرين من خلال نفس سير العمل، وهذا مهم عندما تمتد البنية التحتية لأكثر من بائع واحد.

Terraform سيئة في أي شيء يحدث داخل الآلة بعد أن توجد. لا تثبت packages، ولا تعدل ملفات الإعدادات، ولا تعيد تشغيل الخدمات بأي طريقة ذات معنى مستمرة. provisioners مثل remote-exec موجودة لكن HashiCorp نفسها توصي بتجنبها لأي شيء خارج البدء الأولي.

ما الذي Ansible مخصصة له فعلاً

Ansible هي أداة configuration management. تتصل عبر SSH (أو WinRM للـ Windows) وتشغل مهام على آلات موجودة بالفعل: تثبت nginx، تعد قالب ملف إعدادات، تنشئ مستخدم، تعيد تشغيل خدمة، تفرض أن cron job موجود. Playbooks هي YAML، والوحدات idempotent بالتصميم، لذا تشغيل نفس playbook مرتين لا يجب أن يغير أي شيء في المرة الثانية إذا كان النظام يطابق الحالة المطلوبة بالفعل.

Ansible لا تحتاج agents على الأجهزة المستهدفة، فقط Python و SSH access، وهذا يجعل من السهل إضافتها إلى البنية التحتية الموجودة. كما أنها جيدة في مهام التنسيق التي ليست بالضرورة "provisioning" — إعادة تشغيل متدرجة عبر أسطول، خطوات blue-green deploy، تشغيل migration قاعدة بيانات على جهز واحد ثم تحديث load balancer.

حيث تتقاطع وحيث يحدث التخبط

كلا الأداتين يمكنهما تقنياً أن تفعلا بعض عمل الأخرى. Ansible لديها cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) يمكنها أن تشغل البنية التحتية. Terraform لديها provisioners يمكنها تشغيل shell commands على instance جديد. لكن استخدام Ansible للـ provisioning يعني التخلي عن state tracking و plan/diff workflow من Terraform، واستخدام Terraform provisioners للـ configuration يعني التخلي عن idempotent و repeatable config management.

التقسيم العملي الذي تصل إليه أغلب الفرق:

• Terraform تبني البنية التحتية: الشبكات، compute instances، load balancers، managed databases، IAM roles.
• Ansible تعد ما فوقها: تثبيت البرامج، المستخدمون، ملفات الإعدادات، حالة الخدمة، خطوات deployment التطبيق.

مثال ملموس للتسليم

لنقل أنك تنشئ ثلاث web servers خلف load balancer على AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform تنشئ instances وتعطيك عناوين IPs. يمكنك تمرير هذا الناتج إلى Ansible inventory ديناميكي (amazon.aws.aws_ec2 inventory plugin يقرأ EC2 tags مباشرة، بدون نسخ لصق يدوي) ثم تشغيل:

ansible-playbook -i aws_ec2.yml site.yml

حيث site.yml تثبت nginx، تضع إعدادات التطبيق، وتشغل الخدمة. Terraform لا تلمس nginx أبداً. Ansible لا تلمس VPC. كل أداة تبقى في مجالها، ولكل منها نموذج state/idempotency الخاص بها الذي لا يتضارب مع نموذج الأخرى.

أخطاء شائعة تستحق تجنبها

تخزين Terraform state في git هو الخطأ الأولي الأكثر شيوعاً — ملفات state يمكن أن تحتوي على secrets في plaintext وتسبب merge conflicts تفسد نموذج البنية التحتية. استخدم remote backend منذ اليوم الأول.

مع Ansible، الخطأ هو كتابة playbooks ليست idempotent بالفعل — استخدام shell أو command modules لأشياء لديها module مناسب (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) يتعامل بالفعل مع check-then-act logic بشكل صحيح.

إذا كنت تقرر ما تتعلمه أولاً: تعلم Terraform إذا كنت تفعل cloud provisioning و multi-environment setups، تعلم Ansible إذا كنت تدير config drift على servers لديك بالفعل. أغلب DevOps roles تتوقع معرفة بكليهما في السنة الأولى.

للمزيد عن state management، dynamic inventories، وبناء full CI/CD pipeline حول هذه الأدوات، تحقق من DevOps و Cloud segments ذات الصلة على Korra Studio.