Ansible विरुद्ध Terraform: तुम्हाला कोणते हवे?

एका वाक्यात Ansible विरुद्ध Terraform

Ansible विरुद्ध Terraform म्हणजे समान काम करणाऱ्या दोन साधनांपैकी एकाची निवड नव्हे. 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 लिहिते. या file मध्ये तुमच्या code मधील प्रत्येक resource आणि API द्वारे तयार केलेला प्रत्यक्ष object यांचा संबंध नोंदवला जातो. त्यामुळे पाच lines हटवल्याचा अर्थ एक server नष्ट करायचा आहे हे Terraform ओळखू शकते. Ansible runs दरम्यान काहीही लक्षात ठेवत नाही. ते SSH द्वारे जोडते, 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 ऐवजी तुमच्या provider च्या दस्तऐवजात दिलेला resource type लिहा. output block हा या मार्गदर्शकासाठी महत्त्वाचा आहे, कारण त्याद्वारे address Terraform मधून बाहेर पाठवला जातो.

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

terraform init provider डाउनलोड करते आणि lock file लिहिते. terraform plan तुमच्या code आणि state file मधील फरक दाखवते आणि शेवटी Plan: 1 to add, 0 to change, 0 to destroy. सारख्या ओळीने समाप्त होते. ती ओळ प्रत्येक वेळी वाचा. काही arguments विद्यमान resource मध्ये बदलता येत नाहीत. अशा वेळी plan attribute च्या बाजूला # forces replacement दाखवते आणि त्यानंतर 1 to add, 0 to change, 1 to destroy दाखवते. हा plan लागू केल्यास server हटवला जातो आणि नवीन रिकामा server तयार केला जातो. सुरक्षित असल्याचे तुम्हाला वाटलेला data अशा प्रकारे गमावला जाऊ शकतो.

नुसते terraform apply चालवण्याऐवजी plan file मध्ये जतन करून ती file लागू केल्यास तुम्ही तपासलेलीच configuration प्रत्यक्षात लागू होते. या दोन commands दरम्यान दुसऱ्या व्यक्तीने infrastructure मध्ये बदल केलेले असू शकतात.

terraform.tfstate ही Terraform ची स्मृती आहे. ती गमावल्यास ते servers तुमच्या मालकीचे आहेत हे Terraform ला कळत नाही. त्यामुळे पुढील apply duplicate servers तयार करण्याचा प्रयत्न करते. एकापेक्षा अधिक व्यक्ती commands चालवत असतील, तर ती remote backend मध्ये त्वरित जतन करा. कारण दोन व्यक्तींनी एकाच वेळी apply केल्यास पुढील परिणाम होतो:

Error: Error acquiring the state lock

OpenTofu हा Terraform चा fork आहे. त्याच commands आणि त्याच file format चा तो वापर करतो. July 2026 पर्यंत, terraform ऐवजी tofu टाइप केल्यास या मार्गदर्शकातील सर्व काही कार्य करते.

Ansible प्रत्यक्षात काय करते

Ansible ला agent किंवा APIची गरज नसते. ते SSH connection उघडते, target वर एक लहान Python module copy करते, ते चालवते आणि नंतर ते delete करते. SSH आणि sudo password वापरून ज्या system पर्यंत पोहोचता येते, ते 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सारखे आहे: त्यात प्रत्यक्ष बदल न करता कोणते बदल केले गेले असते हे दाखवले जाते. मात्र आधीच्या task वर अवलंबून असलेले task check modeमध्ये चुकीचा अहवाल देऊ शकतात, कारण आधीचा बदल प्रत्यक्षात झालेला नसतो.

प्रत्येक runचा शेवट ok=6 changed=2 unreachable=0 failed=0 सारख्या recapने होतो. तोच playbook दोनदा चालवा. दुसऱ्या runमध्ये changed=0 असा अहवाल यायला हवा. प्रत्येक runमध्ये changed असा अहवाल देणारे task idempotent नसतात. सहसा ते command किंवा shell task असतात; त्यांच्या ऐवजी योग्य module वापरायला हवा. हा विषय नवीन असल्यास, एका single VPS वरचा पहिला Ansible playbook यापासून सुरुवात करा आणि त्यावर पुढे विस्तार करा.

दोन्ही साधनांचा वापर कुठे एकमेकांशी जुळतो आणि कुठे संघर्ष होतो

Terraform नवीन सर्व्हरवर remote-exec provisioner वापरून commands चालवू शकते. HashiCorp च्या स्वतःच्या documentation मध्ये provisioners हा शेवटचा पर्याय असल्याचे म्हटले आहे. यामागे योग्य कारणे आहेत.

Provisioner resource तयार केल्यावरच चालतो. Script संपादित केली तरी विद्यमान सर्व्हरवर काहीही घडत नाही, कारण Terraform च्या दृष्टीने resource code शी आधीच जुळत असतो. Provisioner मधील steps terraform plan मध्ये कधीही दिसत नाहीत. त्यामुळे review मध्ये त्यांचा कोणताही पुरावा दिसत नाही. Script अयशस्वी झाल्यास Terraform resource ला tainted म्हणून चिन्हांकित करते. त्यानंतरच्या apply मध्ये सर्व्हर नष्ट करून पुन्हा तयार केला जातो, जरी तो बहुधा योग्यरीत्या कार्यरत असला तरी.

अपयशाची वेळही अयोग्य असते. API ने सर्व्हर तयार झाल्याचे सांगताच provider सर्व्हर तयार झाल्याचे नोंदवतो. त्या वेळी 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 सर्व्हर तयार करू शकतात आणि काही मोजक्या मशीनसाठी ही पद्धत कार्य करते. मात्र dependency graph आणि state file उपलब्ध राहत नाहीत. Ansible resource तयार करेल; पण playbook मधून task काढून टाकल्यावरही resource कार्यरत राहतो आणि त्यासाठी billing सुरू राहते. कारण तो resource तुमच्या मालकीचा होता, याची कोणतीही नोंद Ansible ने ठेवलेली नसते.

यातून पुढील नियम स्पष्ट होतो: API द्वारे तयार आणि नष्ट होणाऱ्या objects ची मालकी Terraform कडे द्या. Boot झालेल्या operating system मधील सर्व गोष्टींची मालकी Ansible कडे द्या.

हस्तांतरणाचे कार्य

हस्तांतरण ही एक सीमा आहे, integration नाही. Terraform आपले काम पूर्ण करते, पत्ता प्रकाशित करते आणि थांबते. Ansible त्या पत्त्यापासून सुरू होते.

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 एक मूल्य कोणत्याही अवतरणचिन्हांशिवाय आणि JSON wrapper शिवाय print करते. Shell substitution मध्ये हेच आवश्यक असते. अनेक servers साठी terraform output -json वापरा आणि त्यावरून inventory तयार करा, कारण -raw एकाच string, number किंवा boolean वर प्रक्रिया करते.

दोन्ही tools मधील ping step ठेवणे उपयुक्त ठरते. त्यामुळे “Terraform ने मला चुकीचा पत्ता दिला” आणि “माझ्या playbook मध्ये bug आहे” हे वेगळे ओळखता येते. नवीन box ला पहिल्यांदा हाताळणारी गोष्ट playbook असेल, तर या दोन्ही समस्यांचे स्वरूप सारखे दिसते.

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 अयशस्वी होते. हे plugin तुमच्या server resources मधून hosts आपोआप तयार करत नाही. ते ansible_host आणि ansible_group resources वाचते. हे resources तुम्ही Terraform code मध्ये Ansible provider वापरून declare करता. तुम्ही ते जोडेपर्यंत ansible-inventory --graph मध्ये काहीही दिसत नाही.

साधी generated inventory file debug करणे सोपे असते आणि ती कोणत्याही provider सोबत कार्य करते. Inventory काही मोजक्या machines पेक्षा मोठी झाल्यावर आणि manually editing मुळे typos होऊ लागल्यावर plugin उपयुक्त ठरते. याच टप्प्यावर एका control machine मधून अनेक Linux servers व्यवस्थापित करणे ही सवय न राहता प्रत्यक्ष workflow बनते.

तुम्हाला खरोखर Terraform ची गरज आहे का?

हे वाचणाऱ्या बहुतेक लोकांना Terraform ची गरज नाही, किमान आत्तातरी नाही. Infrastructure तयार करणे आणि नष्ट करणे हेच वारंवार करावे लागणारे काम असेल, तेव्हा Terraform चा अतिरिक्त खर्च आणि गुंतागुंत योग्य ठरते. तुम्ही control panel वापरून एक VPS घेतला आणि तो दोन वर्षे ठेवण्याचा विचार केला, तर Terraform अशा गोष्टीचे वर्णन करते जी एकदाच घडते. त्यासोबत तुम्हाला एक state file जपून ठेवावी लागते.

तुम्ही environments वारंवार पुन्हा तयार करत असाल, staging ने production शी अगदी तंतोतंत जुळणे आवश्यक असेल, अनेक लोक infrastructure मध्ये बदल करत असतील आणि काहीही delete करण्यापूर्वी review करता येईल असा plan हवा असेल, किंवा तुम्ही manage करत असलेली साधने servers च्या पलीकडे जाऊन provider API मध्ये असलेल्या DNS records, load balancers आणि firewall rules पर्यंत पोहोचत असतील, तेव्हा Terraform वापरा.

Servers दीर्घकाळ चालणारे आणि कमी संख्येचे असतील, आणि दररोजचा प्रश्न "हा box योग्यरीत्या configured आहे का" असा असेल, "हा box अस्तित्वात आहे का" असा नसेल, तर केवळ Ansible वापरत राहा. Fresh server ला harden करणारे एक playbook नवीन VPS वरील पहिल्या दहा मिनिटांतील काम एवढेच काम कव्हर करते. त्याचा फायदा असा की पुढील 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}

sshd ऐकू लागण्यापूर्वी API ने address परत केला. fixed sleep जोडण्याऐवजी port साठी प्रतीक्षा करा. Ansible मध्ये यासाठीच ansible.builtin.wait_for_connection आहे; ते play चे पहिले task म्हणून चालवा.

Host key बदलली आहे. तुम्ही सर्व्हर नष्ट करून पुन्हा तयार केला, आणि नवीन सर्व्हर त्याच address वर नवीन key सह प्रतिसाद देत आहे.

Host key verification failed.

ssh-keygen -R 203.0.113.10 वापरून जुनी entry काढा. Terraform पुनर्बांधणी करत असताना हे वारंवार घडते. त्यामुळे data असलेल्या machines वर rebuilds क्वचितच करणे योग्य ठरते.

Sudo अयशस्वी होते. fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} म्हणजे त्या host वर become: true साठी password आवश्यक आहे. deploy user साठी passwordless sudo configure करा किंवा --ask-become-pass pass करा.

तुम्ही बदललेले नसलेले काहीतरी destroy करण्याची Terraform ची इच्छा आहे. plan मध्ये तुम्ही कधीही लिहिलेले नसलेले बदल दिसतात. याचा अर्थ real infrastructure code पासून drift झाले आहे. हे सहसा provider च्या web panel मध्ये कोणीतरी setting बदलल्यामुळे होते. हा फरक स्वतंत्रपणे पाहण्यासाठी terraform plan -refresh-only चालवा. त्यानंतर code चुकीचा आहे की live resource, हे ठरवा. प्रत्येक ओळ समजावून सांगता येत नाही असा destructive plan कधीही apply करू नका.

प्रत्येक run मध्ये Ansible changed दाखवते. creates किंवा when guard नसलेले shell task अटीशिवाय चालते. ही केवळ cosmetic समस्या नाही. कारण server अपेक्षित state मध्ये आहे हे दर्शवण्यासाठी तुम्ही changed=0 वर आता अवलंबून राहू शकत नाही.

FAQ

Terraform, Ansible ची जागा घेऊ शकते का?

सर्व्हरमधील configuration साठी नाही. Terraform, remote-exec provisioner वापरून scripts चालवू शकते; परंतु ती scripts फक्त resource तयार करताना चालतात, terraform plan मध्ये कधीही दिसत नाहीत आणि अयशस्वी झाल्यास resource tainted होते. त्यामुळे पुढील apply वेळी destroy आणि rebuild नियोजित होतात. nginx आधीपासून installed आहे का ते तपासून installed असल्यास काहीही न करणाऱ्या module चा Terraform मध्ये समतुल्य पर्याय नाही. मशीन तयार करण्यासाठी Terraform वापरा आणि त्यानंतर नियंत्रण Ansible कडे द्या.

Ansible, Terraform ची जागा घेऊ शकते का?

कमी संख्येतील दीर्घकाळ चालणाऱ्या सर्व्हरसाठी होय. Ansible मध्ये servers तयार करणारे cloud modules आहेत. तुम्ही दोन VPS instances मागवून ते कायम ठेवणार असाल, तर ते पुरेसे आहे. मात्र state file आणि dependency graph उपलब्ध राहत नाहीत. Playbook मधून एखादे task काढले, तरी resource चालू राहते आणि त्यासाठी billing सुरू राहते, कारण Ansible ने ते तयार केल्याची नोंद कधीच केली नव्हती. Terraform अशा वेळी destroy नियोजित केले असते.

मी प्रथम कोणते शिकावे?

तुमच्याकडे सध्या servers असतील, तर Ansible शिका. पहिल्याच मशीनवर त्याचा फायदा मिळतो. त्यासाठी SSH व्यतिरिक्त काहीही आवश्यक नाही. हाताने मागवलेल्या सर्व्हरवरही हे कौशल्य लागू होते. तुम्ही environments वारंवार पुन्हा तयार करत असाल किंवा servers व्यतिरिक्त DNS records आणि firewall rules यांसारखी provider resources व्यवस्थापित करत असाल, तेव्हा Terraform चा फायदा मिळतो.

Terraform मधून नवीन सर्व्हरचा IP Ansible मध्ये कसा द्यावा?

तुमच्या Terraform code मध्ये output declare करा आणि apply नंतर ते read करा. Shell substitution साठी terraform output -raw web_ip केवळ value छापते. अनेक hosts असतील, तर terraform output -json सर्व outputs एकाच वेळी देते. ही माहिती inventory file मध्ये लिहा किंवा cloud.terraform collection install करून ansible-inventory -i terraform.yml --graph ला project directory दाखवा.

Terraform पूर्ण झाल्यानंतर लगेच माझे playbook अयशस्वी का होते?

Provider च्या API ने server तयार झाल्याचे कळवताच तो server तयार झाल्याचे provider सांगतो. त्या वेळी operating system अजून boot होत असते. त्यामुळे पहिल्या काही सेकंदांत SSH नाकारले जाते. UNREACHABLE! मधील error Connection refused सह येतो. अंदाजाने sleep duration देण्याऐवजी play मधील पहिले task म्हणून ansible.builtin.wait_for_connection वापरा. Boot time image आणि plan नुसार बदलतो.