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

ایک جملے میں Ansible بمقابلہ Terraform

Ansible بمقابلہ Terraform کا مطلب ایسے دو tools میں سے انتخاب نہیں ہے جو ایک ہی کام کرتے ہوں۔ Terraform یہ اعلان کرتا ہے کہ infrastructure میں کیا موجود ہونا چاہیے: servers، disks، networks اور DNS records۔ Ansible یہ اعلان کرتا ہے کہ پہلے سے موجود machine کے اندر کیا حالت ہونی چاہیے: packages، users، config files اور running services۔ Terraform VPS بناتا ہے۔ Ansible اس VPS کو web server میں تبدیل کرتا ہے۔

دونوں declarative ہیں، اور دونوں کو infrastructure as code (IaC) کہا جاتا ہے۔ اصل فرق یہ ہے کہ دونوں کیا یاد رکھتے ہیں۔ Terraform ایک state file لکھتا ہے جو آپ کے code میں موجود ہر resource کو اس حقیقی object سے map کرتی ہے جسے اس نے API کے ذریعے بنایا ہو۔ اسی لیے وہ سمجھ سکتا ہے کہ پانچ lines حذف کرنے کا مطلب ایک server کو destroy کرنا ہے۔ Ansible runs کے درمیان کچھ یاد نہیں رکھتا۔ یہ SSH کے ذریعے connect ہوتا ہے، machine کا معائنہ کرتا ہے، اور صرف وہی چیز تبدیل کرتا ہے جو playbook سے پہلے ہی مطابقت نہیں رکھتی۔

یہی ایک فرق اس guide کی باقی باتوں کی وضاحت کرتا ہے، جس میں یہ بھی شامل ہے کہ دونوں کاموں کو ایک ہی tool میں ملانے سے مسائل کیوں پیدا ہوتے ہیں۔

Terraform اصل میں کیا کرتا ہے

Terraform ایک provider plugin کے ذریعے API سے رابطہ کرتا ہے۔ آپ کے provider کا registry صفحہ ان resource types کی وضاحت کرتا ہے جنہیں آپ لکھ سکتے ہیں۔ اس لیے ایک host پر موجود server اور دوسرے host پر موجود server مختلف resource names اور مختلف arguments رکھتے ہیں۔

resource "cloud_server" "web" {
  name  = "web1"
  image = "ubuntu-24.04"
  type  = "small"
}

output "web_ip" {
  value = cloud_server.web.ipv4_address
}

cloud_server کو اس resource type سے تبدیل کریں جس کی آپ کا provider دستاویز میں وضاحت کرتا ہے۔ output block اس guide کا اہم حصہ ہے، کیونکہ اسی کے ذریعے address Terraform سے باہر جاتا ہے۔

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan

terraform init provider download کرتا ہے اور lock file لکھتا ہے۔ terraform plan آپ کے code اور state file کے درمیان فرق دکھاتا ہے اور ایسی line پر ختم ہوتا ہے: Plan: 1 to add, 0 to change, 0 to destroy. ہر بار یہ line پڑھیں۔ کچھ arguments کو موجودہ resource میں تبدیل نہیں کیا جا سکتا۔ plan attribute کے ساتھ # forces replacement لکھ کر یہ بات ظاہر کرتا ہے، جس کے بعد 1 to add, 0 to change, 1 to destroy آتا ہے۔ اس plan کو apply کرنے سے server delete ہو جاتا ہے اور نیا خالی server بنایا جاتا ہے۔ اسی طرح لوگ وہ data کھو دیتے ہیں جسے وہ محفوظ سمجھتے تھے۔

plan کو file میں محفوظ کرکے اس file کو apply کرنا، صرف terraform apply چلانے کے بجائے، اس بات کو یقینی بناتا ہے کہ جس چیز کا آپ نے جائزہ لیا تھا وہی چلائی جائے۔ دونوں commands کے درمیان کوئی دوسرا شخص infrastructure تبدیل کر سکتا ہے۔

terraform.tfstate یادداشت ہے۔ اسے کھو دینے پر Terraform کو معلوم نہیں رہتا کہ وہ servers آپ کے ہیں۔ اس کے نتیجے میں اگلا apply duplicate servers بنانے کی کوشش کرتا ہے۔ جیسے ہی ایک سے زیادہ افراد commands چلائیں، اسے remote backend میں محفوظ کریں، کیونکہ بیک وقت دو افراد کے apply کرنے سے یہ صورت حال پیدا ہوتی ہے:

Error: Error acquiring the state lock

OpenTofu، Terraform کا fork ہے جس میں وہی commands اور وہی file format استعمال ہوتا ہے۔ July 2026 تک، اس guide میں موجود ہر چیز اس وقت بھی کام کرتی ہے جب آپ terraform کے بجائے tofu لکھیں۔

Ansible اصل میں کیا کرتا ہے

Ansible کو کسی agent یا API کی ضرورت نہیں ہوتی۔ یہ SSH connection کھولتا ہے، target پر ایک چھوٹا Python module copy کرتا ہے، اسے چلاتا ہے، اور پھر اسے delete کر دیتا ہے۔ جس بھی target تک آپ SSH اور sudo password کے ذریعے پہنچ سکتے ہیں، Ansible اسے configure کر سکتا ہے۔

- name: Base web server
  hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Ensure nginx is running at boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

ansible -i inventory.ini web -m ansible.builtin.ping
ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml

ping module playbook کی debugging شروع کرنے سے پہلے SSH، Python اور sudo کی تصدیق کرتا ہے۔ صحت مند نتیجہ web1 | SUCCESS => {"ping": "pong"} ہوتا ہے۔ --check --diff run Ansible میں plan کے قریب ترین چیز ہے: یہ بتاتا ہے کہ کیا تبدیل ہوگا، مگر خود کچھ تبدیل نہیں کرتا۔ تاہم، جو tasks پہلے والے tasks پر منحصر ہوں، وہ check mode میں غلط رپورٹ دے سکتے ہیں، کیونکہ پچھلی تبدیلی حقیقت میں لاگو نہیں ہوئی ہوتی۔

ہر run کا اختتام ok=6 changed=2 unreachable=0 failed=0 جیسے recap پر ہوتا ہے۔ اسی playbook کو دو بار چلائیں۔ دوسرے run میں changed=0 رپورٹ ہونا چاہیے۔ جو task ہر run میں changed رپورٹ کرے، وہ idempotent نہیں ہے۔ عموماً یہ command یا shell task ہوتا ہے، جس کے بجائے حقیقی module استعمال کیا جانا چاہیے تھا۔ اگر یہ آپ کے لیے نیا موضوع ہے تو ایک VPS پر پہلا Ansible playbook سے شروع کریں اور پھر اسے بتدریج وسیع کریں۔

جہاں دونوں tools کا دائرۂ کار ایک دوسرے سے ملتا ہے، اور جہاں ان میں ٹکراؤ پیدا ہوتا ہے

Terraform نئے server پر `remote-exec` provisioner کے ذریعے commands چلا سکتا ہے۔ HashiCorp کی اپنی documentation provisioners کو آخری حل قرار دیتی ہے۔ اس کی معقول وجوہات ہیں۔

Provisioner صرف resource بناتے وقت چلتا ہے۔ Script میں ترمیم کریں تو موجودہ server پر کچھ نہیں ہوتا، کیونکہ Terraform کے نقطۂ نظر سے resource پہلے ہی code سے مطابقت رکھتا ہے۔ Provisioner کے مراحل کبھی `terraform plan` میں ظاہر نہیں ہوتے، اس لیے review میں ان کا کوئی نشان نہیں ملتا۔ اگر script ناکام ہو جائے تو Terraform resource کو tainted قرار دیتا ہے، اور اگلا apply ایسے server کو destroy کرکے دوبارہ بناتا ہے جو غالباً درست کام کر رہا تھا۔

Failure کا وقت بھی ناموزوں ہوتا ہے۔ API کے server بننے کی اطلاع دیتے ہی provider اسے created بتا دیتا ہے، حالانکہ operating system ابھی boot ہو رہا ہوتا ہے اور `sshd` ابھی listening نہیں کر رہا ہوتا۔

Error: remote-exec provisioner error
timeout - last error: dial tcp 203.0.113.10:22: connect: connection refused

Ansible میں اس کے برعکس آزمائش موجود ہوتی ہے۔ Cloud modules servers بنا سکتے ہیں، اور چند machines کے لیے یہ طریقہ کام کرتا ہے۔ لیکن اس کے بدلے dependency graph اور state file دستیاب نہیں رہتے۔ Ansible کسی resource کو آسانی سے بنا دے گا، لیکن playbook سے task حذف کرنے کے باوجود resource چلتا رہے گا اور اس کا bill آتا رہے گا، کیونکہ کوئی ریکارڈ موجود نہیں ہوتا کہ وہ resource کبھی آپ کی ملکیت تھا۔

اس سے حاصل ہونے والا اصول یہ ہے: ایسے objects کی ownership Terraform کو دیں جنہیں API بناتی اور destroy کرتی ہے، جبکہ booted operating system کے اندر موجود ہر چیز کی ownership Ansible کو دیں۔

ہینڈ آف کا عملی طریقہ

ہینڈ آف integration نہیں بلکہ ایک حد ہے۔ Terraform اپنا کام مکمل کرتا ہے، ایک address جاری کرتا ہے، اور رک جاتا ہے۔ Ansible اسی address سے کام شروع کرتا ہے۔

terraform apply -auto-approve
terraform output -raw web_ip
printf '[web]\n%s ansible_user=root\n' "$(terraform output -raw web_ip)" > inventory.ini
ansible -i inventory.ini web -m ansible.builtin.ping
ansible-playbook -i inventory.ini site.yml

terraform output -raw ایک value کو quotes اور JSON wrapper کے بغیر print کرتا ہے۔ Shell substitution کے اندر یہی مطلوب ہوتا ہے۔ متعدد servers کے لیے terraform output -json استعمال کریں اور اس کی بنیاد پر inventory بنائیں، کیونکہ -raw صرف ایک string، number یا boolean کو handle کرتا ہے۔

دونوں tools کے درمیان ping کا مرحلہ برقرار رکھنا مفید ہے۔ اس سے "Terraform نے مجھے غلط address دیا" اور "میرے playbook میں bug ہے" کے درمیان فرق واضح رہتا ہے۔ جب playbook نئے box کو پہلی بار access کرنے والی چیز ہو، تو دونوں مسائل ایک جیسے دکھائی دیتے ہیں۔

Terraform state کو Ansible inventory کے طور پر پڑھنا

اگر آپ inventory file بالکل نہیں لکھنا چاہتے تو cloud.terraform collection state کو براہِ راست پڑھتی ہے۔

ansible-galaxy collection install cloud.terraform

اپنی playbook کے ساتھ terraform.yml لکھیں:

plugin: cloud.terraform.terraform_provider
project_path: /home/deploy/infra

ansible-inventory -i terraform.yml --graph
ansible-playbook -i terraform.yml site.yml

اس پر انحصار کرنے سے پہلے دو باتیں جان لیں۔ یہ plugin project_path کے خلاف terraform show چلاتا ہے، اس لیے وہ directory پہلے سے initialized ہونی چاہیے، ورنہ plugin ناکام ہو جائے گا۔ یہ آپ کے server resources سے hosts خود نہیں بناتا۔ یہ ansible_host اور ansible_group resources پڑھتا ہے، جنہیں آپ Terraform code میں Ansible provider استعمال کرتے ہوئے declare کرتے ہیں۔ جب تک آپ انہیں شامل نہ کریں، ansible-inventory --graph میں کچھ ظاہر نہیں ہوگا۔

سادہ generated inventory file کو debug کرنا آسان ہے اور یہ کسی بھی provider کے ساتھ کام کرتی ہے۔ جب inventory چند machines سے بڑھ جائے اور دستی editing میں typos ہونے لگیں تو plugin مفید ثابت ہوتا ہے۔ یہی وہ مرحلہ ہے جب ایک control machine سے متعدد Linux servers کا انتظام محض عادت کے بجائے باقاعدہ workflow بن جاتا ہے۔

کیا آپ کو واقعی Terraform کی ضرورت ہے؟

اسے پڑھنے والے زیادہ تر لوگوں کو کم از کم ابھی تو Terraform کی ضرورت نہیں ہوتی۔ Terraform اس وقت اپنی لاگت پوری کرتا ہے جب infrastructure بنانا اور ختم کرنا خود ایک بار بار دہرایا جانے والا کام ہو۔ اگر آپ نے control panel کے ذریعے ایک VPS آرڈر کیا ہے اور اسے 2 سال تک برقرار رکھنے کا ارادہ رکھتے ہیں، تو Terraform ایسی چیز بیان کرتا ہے جو صرف ایک بار ہوتی ہے، اور ساتھ ایک state file شامل کرتا ہے جسے آپ کھو نہیں سکتے۔

Terraform اس وقت استعمال کریں جب آپ environments کو اکثر دوبارہ بناتے ہوں، جب staging کا production سے عین مطابق ہونا ضروری ہو، جب متعدد لوگ infrastructure میں تبدیلیاں کرتے ہوں اور آپ چاہتے ہوں کہ کچھ بھی حذف ہونے سے پہلے قابلِ جائزہ plan موجود ہو، یا جب آپ کے زیرِ انتظام چیزیں servers سے آگے بڑھ کر DNS records، load balancers اور firewall rules تک پہنچ جائیں جو کسی provider API میں موجود ہوں۔

Ansible کو اکیلے استعمال کرتے رہیں جب servers طویل مدت تک برقرار رہتے ہوں اور تعداد میں کم ہوں، اور جب روزمرہ کا سوال یہ ہو کہ "کیا یہ box درست طور پر configured ہے؟" نہ کہ یہ کہ "کیا یہ box موجود ہے؟" تازہ server کو harden کرنے والا ایک playbook اسی دائرے کا احاطہ کرتا ہے جو نئے VPS پر پہلے 10 منٹ میں ہوتا ہے، اور اس کا فائدہ یہ ہے کہ اگلے server پر بھی یہ اسی طریقے سے چلتا ہے۔

سیکھنے کی ترتیب بھی اسی سے واضح ہوتی ہے۔ آپ کے اپنے پہلے server پر Ansible کا فائدہ ملنا شروع ہو جاتا ہے۔ تیسرے environment کو دوبارہ بنانے پر Terraform کا فائدہ ملتا ہے۔

منتقلی کے مرحلے میں کیا خراب ہوتا ہے

سرور تیار نہیں ہے۔ Terraform کامیاب ہو جاتا ہے، لیکن Ansible فوراً ناکام ہو جاتا ہے۔

fatal: [web1]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 203.0.113.10 port 22: Connection refused", "unreachable": true}

API نے sshd کے listening شروع کرنے سے پہلے ہی ایک address واپس کر دیا۔ مقررہ مدت تک sleep شامل کرنے کے بجائے port کا انتظار کریں۔ Ansible میں اس مقصد کے لیے بالکل ansible.builtin.wait_for_connection موجود ہے؛ اسے play کے پہلے task کے طور پر چلائیں۔ جب یہی playbook کسی نئے سرور کے بجائے host group کو target کرے تو پہلے سے طے کریں کہ جب کوئی host ناقابل رسائی رہے تو کیا ہونا چاہیے، کیونکہ Ansible اس host کو run کے باقی حصے سے خارج کر دیتا ہے اور recap line ہی وہ واحد جگہ ہے جہاں یہ بات بتائی جاتی ہے۔

Host key تبدیل ہو گئی ہے۔ آپ نے سرور ختم کرکے دوبارہ بنایا، اور نیا سرور اسی address پر نئی key کے ساتھ جواب دے رہا ہے۔

Host key verification failed.

پرانا entry ssh-keygen -R 203.0.113.10 کے ذریعے حذف کریں۔ Terraform کے ذریعے rebuilding ہونے پر یہ صورت حال مسلسل پیش آتی ہے۔ اسی لیے ایسے machines پر rebuilds کم رکھیں جن پر data موجود ہو۔

Sudo ناکام ہو جاتا ہے۔ fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} کا مطلب ہے کہ اس host پر become: true کے لیے password درکار ہے۔ یا تو deploy user کے لیے passwordless sudo configure کریں، یا --ask-become-pass فراہم کریں۔

Terraform کسی ایسی چیز کو destroy کرنا چاہتا ہے جسے آپ نے تبدیل نہیں کیا۔ plan میں ایسی تبدیلیاں دکھائی دیتی ہیں جو آپ نے code میں نہیں لکھیں۔ اس کا مطلب ہے کہ حقیقی infrastructure code سے مختلف ہو چکا ہے، عموماً اس لیے کہ کسی نے provider کے web panel میں setting تبدیل کی ہے۔ صرف یہ فرق دیکھنے کے لیے terraform plan -refresh-only چلائیں، پھر فیصلہ کریں کہ code غلط ہے یا live resource۔ ایسی destructive plan کبھی apply نہ کریں جس کی ہر line کی وضاحت آپ نہ کر سکیں۔

Ansible ہر run میں changed رپورٹ کرتا ہے۔ creates یا when guard کے بغیر shell task ہر بار بلاشرط چلتا ہے۔ یہ صرف ظاہری مسئلہ نہیں، کیونکہ اس کا مطلب ہے کہ آپ اب changed=0 کو اس signal کے طور پر استعمال نہیں کر سکتے کہ سرور مطلوبہ state میں ہے۔

FAQ

کیا Terraform، Ansible کی جگہ لے سکتا ہے؟

سرور کے اندر configuration کے لیے نہیں۔ Terraform، remote-exec provisioner کے ذریعے scripts چلا سکتا ہے، لیکن یہ scripts صرف resource بناتے وقت چلتی ہیں، terraform plan میں کبھی ظاہر نہیں ہوتیں، اور ناکام ہونے پر resource کو tainted کر دیتی ہیں۔ اس کے نتیجے میں اگلے apply کے دوران اسے destroy کرکے دوبارہ build کرنے کا عمل schedule ہو جاتا ہے۔ Terraform میں module کے مساوی ایسی سہولت نہیں جو یہ چیک کرے کہ nginx پہلے سے installed ہے یا نہیں، اور installed ہونے کی صورت میں کچھ نہ کرے۔ machine بنانے کے لیے Terraform استعمال کریں، پھر configuration کا کام Ansible کے حوالے کریں۔

کیا Ansible، Terraform کی جگہ لے سکتا ہے؟

کم تعداد میں طویل عرصے تک چلنے والے servers کے لیے ہاں۔ Ansible میں cloud modules موجود ہیں جو servers بناتے ہیں۔ اگر آپ 2 VPS instances order کرکے انہیں برقرار رکھتے ہیں تو یہ کافی ہے۔ لیکن state file اور dependency graph دستیاب نہیں رہتے۔ playbook سے کوئی task ہٹانے پر resource چلتا رہتا ہے اور billing جاری رہتی ہے، کیونکہ Ansible یہ record نہیں کرتا کہ resource اسی نے بنایا تھا۔ Terraform ایسی صورت میں destroy کا منصوبہ بناتا۔

مجھے پہلے کون سا سیکھنا چاہیے؟

اگر آج آپ servers manage کرتے ہیں تو Ansible سیکھیں۔ یہ پہلے machine پر ہی فائدہ دینا شروع کر دیتا ہے، صرف SSH درکار ہوتا ہے، اور اس کی مہارت اس server پر بھی کام آتی ہے جسے آپ نے دستی طور پر order کیا ہو۔ Terraform بعد میں زیادہ فائدہ دیتا ہے، جب آپ environments بار بار rebuild کریں یا servers کے علاوہ provider resources بھی manage کریں، مثلاً DNS records اور firewall rules۔

Terraform سے نئے server کا IP، Ansible میں کیسے منتقل کروں؟

اپنے Terraform code میں output declare کریں، پھر apply کے بعد اسے پڑھیں۔ terraform output -raw web_ip shell substitution کے لیے صرف value print کرتا ہے، جبکہ متعدد hosts ہونے پر terraform output -json تمام outputs ایک ساتھ دیتا ہے۔ اس value کو inventory file میں لکھیں، یا cloud.terraform collection install کرکے ansible-inventory -i terraform.yml --graph کو project directory کی طرف point کریں۔

Terraform مکمل ہونے کے فوراً بعد میرا playbook کیوں ناکام ہو جاتا ہے؟

Provider server کو اسی وقت created report کرتا ہے جب اس کی API ایسا بتاتی ہے، جبکہ operating system ابھی boot ہو رہا ہوتا ہے۔ اس لیے ابتدائی چند seconds میں SSH refused ہو جاتا ہے۔ Connection refused کے ساتھ error UNREACHABLE! آتا ہے۔ اندازے سے sleep duration مقرر کرنے کے بجائے play میں ansible.builtin.wait_for_connection کو پہلا task بنائیں، کیونکہ boot time image اور plan کے مطابق مختلف ہوتا ہے۔