Terraform بمقابل Ansible: آپ کو دراصل کون سا چاہیے؟

Infrastructure as Code میں نئے لوگ عام طور پر یہ سوال دونوں میں سے کسی نہ کسی طریقے سے پوچھتے ہیں: "مجھے پہلے کون سا ٹول سیکھنا چاہیے" یا "ٹیمیں دونوں کو کیوں استعمال کرتے ہیں۔" مختصر جواب یہ ہے کہ Terraform اور Ansible مختلف مسائل حل کرتے ہیں، اور بیشتر پروڈکشن سیٹ اپس انہیں ایک ساتھ استعمال کرتے ہیں بجائے ایک کو منتخب کرنے کے۔

Terraform اصل میں کس لیے ہے

Terraform ایک provisioning ٹول ہے۔ یہ بیان کرتا ہے کہ انفراسٹرکچر موجود ہونا چاہیے: ایک VPC، تین EC2 instances، ایک RDS ڈیٹا بیس، ایک S3 bucket ایک مخصوص policy کے ساتھ۔ آپ HCL میں اختتام کی حالت کو بیان کرتے ہیں، terraform plan چلاتے ہیں کہ دیکھیں کہ کیا بدلے گا، پھر terraform apply کرتے ہیں یہ ہونے دیں۔ Terraform ایک state فائل رکھتا ہے (مقامی طور پر یا ایک backend میں جیسے S3 bucket DynamoDB locking کے ساتھ) جو آپ کی config کو cloud provider میں حقیقی resource IDs سے منسلک کرتا ہے۔

اس میں طاقت یہ ہے کہ providers میں منحصر حل ہو جانا۔ اگر آپ Terraform کو ایک security group بنانے کے لیے کہتے ہیں اور پھر اسے ایک EC2 instance سے منسلک کریں، تو یہ ترتیب خود بخود سمجھ لیتا ہے۔ یہ AWS، Azure، GCP، Cloudflare، Datadog، اور درجنوں دوسرے providers میں ایک جیسے workflow کے ذریعے کام کرتا ہے، جو اہم ہے جب آپ کا انفراسٹرکچر ایک سے زیادہ فروخت کنندگان پر پھیلا ہوا ہو۔

Terraform اس میں برا ہے جو مشین کے اندر ہوتا ہے اگر وہ موجود ہے۔ یہ packages انسٹال نہیں کرتا، config فائلوں میں ترمیم نہیں کرتا، یا کسی بھی معنی خیز جاری طریقے سے services کو دوبارہ شروع نہیں کرتا۔ Provisioners جیسے remote-exec موجود ہیں لیکن خود HashiCorp bootstrap سے باہر کسی چیز کے لیے ان سے بچنے کی سفارش کرتا ہے۔

Ansible اصل میں کس لیے ہے

Ansible ایک configuration management ٹول ہے۔ یہ SSH کے ذریعے جڑتا ہے (یا Windows کے لیے WinRM) اور اسطاریل کو چلاتا ہے جو پہلے سے موجود machines کے خلاف: nginx انسٹال کریں، config فائل کو ٹیمپلیٹ کریں، ایک user بنائیں، ایک service دوبارہ شروع کریں، نافذ کریں کہ ایک cron job موجود ہے۔ Playbooks YAML ہیں، اور modules idempotent طریقے سے ڈیزائن کیے گئے ہیں، تو ایک ہی playbook کو دوبارہ چلانے سے دوسری بار کچھ نہیں بدلنا چاہیے اگر system پہلے سے مطلوبہ حالت سے مماثل ہے۔

Ansible کو target hosts پر agents انسٹال کرنے کی ضرورت نہیں، صرف Python اور SSH رسائی، جو اسے موجودہ انفراسٹرکچر میں لگانا آسان بناتا ہے۔ یہ orchestration tasks میں بھی اچھا ہے جو سختی سے "provisioning" نہیں ہیں — ایک fleet میں rolling restarts، blue-green deploy steps، ایک host پر database migration چلانا اور پھر ایک load balancer اپ ڈیٹ کرنا۔

وہ جہاں overlap کرتے ہیں اور لوگ کہاں confusion میں پڑتے ہیں

دونوں tools تکنیکی طور پر دوسرے کے کام کا کچھ حصہ کر سکتے ہیں۔ Ansible کے پاس cloud modules ہیں (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) جو انفراسٹرکچر spin کر سکتے ہیں۔ Terraform کے پاس provisioners ہیں جو ایک نئے instance پر shell commands چلا سکتے ہیں۔ لیکن provisioning کے لیے Ansible کا استعمال کرنے کا مطلب Terraform کی state tracking اور plan/diff workflow سے محروم ہونا ہے، اور configuration کے لیے Terraform provisioners کا استعمال کرنے کا مطلب idempotent، قابل دہرائے جانے والی config management سے محروم ہونا ہے۔

عملی split جو زیادہ تر teams کو ملتا ہے:

• Terraform انفراسٹرکچر بناتا ہے: networks، compute instances، load balancers، managed databases، IAM roles۔
• Ansible اس کے اوپر کیا ہے اسے configure کرتا ہے: software installs، users، config files، service state، application deployment steps۔

handoff کی ایک ٹھوس مثال

کہو کہ آپ AWS پر ایک load balancer کے پیچھے تین web servers کو کھڑا کر رہے ہیں۔

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 output کرتا ہے۔ آپ اس output کو ایک dynamic Ansible inventory میں feed کر سکتے ہیں (amazon.aws.aws_ec2 inventory plugin EC2 tags کو براہ راست پڑھتا ہے، کوئی manual copy-paste نہیں) اور پھر چلائیں:

ansible-playbook -i aws_ec2.yml site.yml

jہاں site.yml nginx انسٹال کرتا ہے، app config drop کرتا ہے، اور service شروع کرتا ہے۔ Terraform کبھی nginx کو نہیں چھوتا۔ Ansible کبھی VPC کو نہیں چھوتا۔ ہر tool اپنی lane میں رہتا ہے، اور ہر کے پاس اپنا state/idempotency model ہے جو دوسرے سے conflict نہیں کرتا۔

عام غلطیاں جن سے بچنے کے قابلِ غور ہیں

Terraform state کو git میں store کرنا سب سے عام ابتدائی غلطی ہے — state files plaintext میں secrets contain کر سکتے ہیں اور merge conflicts کا سبب بن سکتے ہیں جو آپ کے انفراسٹرکچر model کو corrupt کرتے ہیں۔ دن ایک سے ایک 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 سیکھیں اگر آپ servers کے لیے config drift کو manage کر رہے ہیں جو آپ کے پاس پہلے سے ہیں۔ زیادہ تر DevOps roles پہلے سال میں دونوں کے ساتھ familiarity کی توقع کرتے ہیں۔

State management، dynamic inventories، اور ان tools کے گرد ایک مکمل CI/CD pipeline بنانے کے بارے میں مزید کے لیے، Korra Studio پر متعلقہ DevOps اور Cloud segments دیکھیں۔