SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-30

Ansible vs Terraform: మీకు ఏది అవసరం?

Terraform VPS ను సృష్టిస్తుంది, Ansible దాన్ని configure చేస్తుంది. Provisioner సమస్యలు, handoff commands, రెండింటిలో ఒక్క Ansible ఎప్పుడు సరిపోతుందో తెలుసుకోండి.

ఒక వాక్యంలో Ansible vs Terraform

Ansible vs Terraform అనేది ఒకే పని చేసే రెండు tools మధ్య ఎంపిక కాదు. Terraform ఏ infrastructure ఉండాలో నిర్వచిస్తుంది: servers, disks, networks, DNS records. Ansible ఇప్పటికే ఉన్న machine లో ఏ స్థితి ఉండాలో నిర్వచిస్తుంది: packages, users, config files, running services. Terraform VPS ను సృష్టిస్తుంది. Ansible ఆ VPS ను web server గా మారుస్తుంది.

రెండూ declarative tools, మరియు రెండింటినీ infrastructure as code (IaC) అని పిలుస్తారు. వాటి మధ్య అసలు తేడా అవి ఏ విషయాన్ని గుర్తుంచుకుంటాయన్నదే. Terraform ఒక state file ను రాస్తుంది. అందులో మీ code లోని ప్రతి resource ను API ద్వారా సృష్టించిన వాస్తవ object తో map చేస్తుంది. అందువల్ల మీరు ఐదు lines తొలగిస్తే ఒక server ను destroy చేయాలని అది గుర్తించగలదు. Ansible runs మధ్య ఏదీ గుర్తుంచుకోదు. ఇది SSH ద్వారా connect అయి machine ను పరిశీలిస్తుంది. తరువాత playbook కు ఇప్పటికే సరిపోని వాటిని మాత్రమే మారుస్తుంది.

ఈ ఒక్క తేడానే ఈ guide లోని మిగతా అంశాలను వివరిస్తుంది. రెండు పనులను ఒకే tool లో కలపడం ఎందుకు సమస్యలకు దారితీస్తుందో కూడా ఇది వివరిస్తుంది.

Terraform వాస్తవంగా ఏమి చేస్తుంది

Terraform, provider plugin ద్వారా APIతో కమ్యూనికేట్ చేస్తుంది. మీరు వ్రాయగల resource types ను మీ provider యొక్క registry page నిర్వచిస్తుంది. అందువల్ల ఒక hostలోని server కు, మరో hostలోని server కు వేర్వేరు arguments కలిగిన వేర్వేరు resource names ఉంటాయి.

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

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

cloud_server స్థానంలో మీ provider documentationలో ఉన్న resource type ను ఉంచండి. ఈ guideలో output block ముఖ్యమైనది, ఎందుకంటే 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కు మధ్య ఉన్న తేడాను చూపిస్తుంది. చివర్లో Plan: 1 to add, 0 to change, 0 to destroy. వంటి line కనిపిస్తుంది. ఆ lineను ప్రతిసారి చదవండి. కొన్ని argumentsను ఉన్న serverపైనే మార్చలేరు. అలాంటి సందర్భంలో plan, attribute పక్కన # forces replacement ను చూపించి, దాని తరువాత 1 to add, 0 to change, 1 to destroy ను చూపిస్తుంది. ఆ planను apply చేస్తే server తొలగిపోయి, కొత్త ఖాళీ server సృష్టించబడుతుంది. సురక్షితంగా ఉందని భావించిన dataను ప్రజలు ఈ విధంగానే కోల్పోతారు.

ఖాళీ terraform apply నడపడానికి బదులుగా planను fileలో save చేసి, ఆ fileను apply చేయండి. అప్పుడు మీరు review చేసినదే అమలవుతుంది. ఈ రెండు commands మధ్యలో మరొకరు infrastructureను మార్చి ఉండవచ్చు.

terraform.tfstate memoryగా పనిచేస్తుంది. దాన్ని కోల్పోతే ఆ 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 టైప్ చేస్తే ఈ guideలోని ప్రతిదీ పనిచేస్తుంది.

Ansible వాస్తవంగా ఏమి చేస్తుంది

Ansible కు agent లేదా API అవసరం లేదు. ఇది SSH connection ను తెరిచి, ఒక చిన్న Python module ను target కు copy చేసి, దాన్ని run చేసి, తరువాత delete చేస్తుంది. 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

మీరు playbook ను debug చేయడం ప్రారంభించే ముందు SSH, Python మరియు sudo అందుబాటులో ఉన్నాయని ping module నిర్ధారిస్తుంది. ఆరోగ్యకరమైన ఫలితం 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 చేయండి. రెండవ run changed=0 ను నివేదించాలి. ప్రతి run లో changed అని నివేదించే task idempotent కాదు. సాధారణంగా అది నిజమైన module గా ఉండాల్సిన command లేదా shell task అవుతుంది. ఇది మీకు కొత్త విషయం అయితే, ఒకే VPS పై మొదటి Ansible playbook తో ప్రారంభించి, అక్కడి నుంచి దాన్ని విస్తరించండి.

రెండు సాధనాలు ఎక్కడ ఒకే పని చేస్తాయి, ఎక్కడ పరస్పరం విరుద్ధంగా పనిచేస్తాయి

Terraform కొత్త server పై commands ను remote-exec provisioner తో అమలు చేయగలదు. HashiCorp యొక్క స్వంత documentation provisioners ను చివరి మార్గంగా మాత్రమే ఉపయోగించాలని చెబుతుంది. దీనికి మంచి కారణాలు ఉన్నాయి.

ఒక provisioner resource సృష్టించినప్పుడు మాత్రమే అమలవుతుంది. Script ను సవరించినా, ఇప్పటికే ఉన్న server పై ఏమీ జరగదు. Terraform దృష్టిలో ఆ resource ఇప్పటికే code కు సరిపోతుంది. Provisioner దశలు ఎప్పుడూ terraform plan లో కనిపించవు. అందువల్ల మీ review లో వాటికి సంబంధించిన సూచన కనిపించదు. Script విఫలమైతే Terraform ఆ resource ను tainted గా గుర్తిస్తుంది. తరువాతి apply సమయంలో సాధారణంగా సరిగానే ఉన్న server ను తొలగించి మళ్లీ సృష్టిస్తుంది.

విఫలం జరిగే సమయం కూడా సమస్యాత్మకంగా ఉంటుంది. API server సృష్టించబడిందని చెప్పగానే provider దానిని created గా నివేదిస్తుంది. అయితే ఆ సమయంలో operating system ఇంకా boot అవుతుండవచ్చు. sshd ఇంకా listening state లో ఉండకపోవచ్చు.

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

Ansible విషయంలో దీనికి విరుద్ధమైన ప్రమాదం ఉంటుంది. Cloud modules serverలను సృష్టించగలవు. కొద్ది machines కు ఇది పనిచేస్తుంది. కానీ dependency graph మరియు state file ను మీరు కోల్పోతారు. Ansible ఒక resource ను సృష్టిస్తుంది. అయితే మీ playbook నుంచి ఆ task ను తొలగించినా resource నడుస్తూనే ఉంటుంది, దానికి billing కొనసాగుతూనే ఉంటుంది. అది ఎప్పుడైనా మీదని ఏదీ నమోదు కాలేదు.

దీనినుంచి వచ్చే నియమం ఇది: API సృష్టించి తొలగించే objects ను Terraform నిర్వహించాలి. Boot అయిన operating system లోపల ఉన్న ప్రతిదాన్ని Ansible నిర్వహించాలి.

handoff, సరిగ్గా పనిచేసే విధానం

handoff అనేది 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 ను మాత్రమే నిర్వహిస్తుంది.

రెండు tools మధ్య ఉన్న ping step ను ఉంచడం ఉపయోగకరం. దీని ద్వారా "Terraform నాకు తప్పు address ఇచ్చింది" అనే సమస్యను "నా playbook లో bug ఉంది" అనే సమస్య నుంచి వేరు చేయవచ్చు. New 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 విఫలమవుతుంది. అలాగే ఇది మీ server resources ఆధారంగా hosts ను స్వయంగా సృష్టించదు. Terraform codeలో Ansible provider ఉపయోగించి మీరు declare చేసిన ansible_host మరియు ansible_group resources ను మాత్రమే ఇది చదువుతుంది. మీరు వాటిని జోడించే వరకు ansible-inventory --graph లో ఏదీ కనిపించదు.

సాధారణంగా generate చేసిన inventory file ను debug చేయడం సులభం. ఇది ఏ provider తోనైనా పనిచేస్తుంది. Inventory కొన్ని machines ను మించినప్పుడు plugin ఉపయోగకరంగా ఉంటుంది. చేతితో editing చేయడం వల్ల typos మొదలవుతాయి. ఇదే దశలో ఒక control machine నుంచి అనేక Linux servers ను నిర్వహించడం అలవాటు కాకుండా నిజమైన workflowగా మారుతుంది.

మీకు నిజంగా Terraform అవసరమా?

ఇది చదువుతున్న చాలా మందికి, కనీసం ఇప్పటికైతే, Terraform అవసరం ఉండదు. Infrastructure ను సృష్టించడం, తొలగించడం తరచుగా చేసే పనిగా మారినప్పుడు Terraform ఉపయోగం సమర్థించబడుతుంది. మీరు control panel ద్వారా ఒక VPS ను ఆర్డర్ చేసి, దాన్ని రెండు సంవత్సరాలు కొనసాగించాలనుకుంటే, Terraform ఒక్కసారి మాత్రమే జరిగే పనిని వివరించడానికి ఉపయోగపడుతుంది. అదనంగా, మీరు కోల్పోకూడని state file ను నిర్వహించాలి.

మీరు environments ను తరచుగా మళ్లీ నిర్మించినప్పుడు Terraform ను ఉపయోగించండి. Staging, production కు ఖచ్చితంగా సరిపోవాల్సి వచ్చినప్పుడు కూడా ఇది ఉపయోగకరం. అనేక మంది infrastructure ను మార్చేటప్పుడు, ఏదైనా తొలగించే ముందు review చేయగల plan కావాలంటే Terraform ను ఎంచుకోండి. మీరు నిర్వహించేది servers ను దాటి provider API లో ఉన్న DNS records, load balancers, firewall rules వరకు విస్తరించినప్పుడు కూడా Terraform ఉపయోగపడుతుంది.

Servers ఎక్కువకాలం ఉండేవి, సంఖ్యలో తక్కువగా ఉన్నప్పుడు Ansible తోనే కొనసాగండి. రోజువారీ ప్రశ్న "ఈ server సరిగ్గా configure అయిందా" అనేదే అయితే, "ఈ server ఉందా" అనేది కాకపోతే, Ansible సరిపోతుంది. కొత్త server ను harden చేసే ఒకే playbook కొత్త VPS పై మొదటి పది నిమిషాల పనిని కవర్ చేస్తుంది. అదే playbook ను తరువాతి 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 listening ప్రారంభించకముందే API ఒక address ను అందించింది. స్థిరమైన sleep జోడించకుండా, port కోసం వేచి ఉండండి. Ansible లో దీని కోసమే ansible.builtin.wait_for_connection ఉంది; దీన్ని play లో మొదటి task గా అమలు చేయండి. అదే playbook ఒక కొత్త box కు బదులుగా ఒక group ను లక్ష్యంగా చేసుకున్నప్పుడు, ఒక host అందుబాటులో లేకపోతే ఏం జరగాలో ముందుగానే నిర్ణయించండి. ఎందుకంటే Ansible ఆ host ను మిగతా run నుంచి తొలగిస్తుంది, మరియు recap line లో మాత్రమే ఆ విషయాన్ని తెలియజేస్తుంది.

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 చేయండి.

మీరు మార్చని దాన్ని Terraform తొలగించాలనుకుంటోంది. మీరు code లో ఎప్పుడూ రాయకపోయిన మార్పులను plan చూపిస్తోంది. అంటే సాధారణంగా provider యొక్క web panel లో ఎవరో setting మార్చడం వల్ల వాస్తవ infrastructure code నుంచి విభిన్నంగా మారిందని అర్థం. ఆ తేడాను మాత్రమే చూడటానికి terraform plan -refresh-only ను అమలు చేయండి. తరువాత code తప్పా లేదా live resource తప్పా నిర్ణయించండి. ప్రతి line ను వివరించలేని destructive plan ను ఎప్పుడూ apply చేయవద్దు.

ప్రతి run లో Ansible changed అని నివేదిస్తుంది. creates లేదా when guard లేని shell task షరతుల్లేకుండా అమలవుతుంది. ఇది కేవలం రూపకల్పన సమస్య కాదు. ఎందుకంటే server మీరు కోరిన state లో ఉందని సూచించే సంకేతంగా changed=0 ను ఇక ఉపయోగించలేరు.

FAQ

Terraform ను Ansible భర్తీ చేయగలదా?

సర్వర్‌లోని configuration విషయంలో కాదు. Terraform `remote-exec provisioner తో scripts ను అమలు చేయగలదు. అయితే అవి resource creation సమయంలో మాత్రమే ఒకసారి అమలవుతాయి. అవి terraform plan` లో కనిపించవు. అవి విఫలమైతే resource tainted అవుతుంది. దాంతో తదుపరి apply సమయంలో దాన్ని తొలగించి మళ్లీ నిర్మించే ప్రక్రియ షెడ్యూల్ అవుతుంది. nginx ఇప్పటికే install అయిందో లేదో తనిఖీ చేసి, install అయి ఉంటే ఏమీ చేయకుండా ఉండే module కు Terraformలో సమానమైనది లేదు. machine ను సృష్టించడానికి Terraform ను ఉపయోగించండి. తరువాత configuration బాధ్యతను Ansibleకు అప్పగించండి.

Ansible Terraform ను భర్తీ చేయగలదా?

కొద్దిమంది దీర్ఘకాలం ఉపయోగించే servers కోసం అవును. Ansibleలో servers ను సృష్టించే cloud modules ఉన్నాయి. మీరు రెండు VPS instances ను order చేసి, వాటిని అలాగే ఉంచితే అది సరిపోతుంది. అయితే state file మరియు dependency graph మీకు ఉండవు. playbook నుంచి ఒక task ను తొలగించినా resource నడుస్తూనే ఉంటుంది, billing కూడా కొనసాగుతుంది. ఎందుకంటే దాన్ని సృష్టించింది తానే అని Ansible ఎప్పుడూ నమోదు చేయలేదు. Terraform అయితే destroy చర్యను plan చేసేది.

ముందుగా ఏది నేర్చుకోవాలి?

మీ వద్ద ప్రస్తుతం servers ఉంటే Ansible నేర్చుకోండి. మొదటి machine పైనే దాని ప్రయోజనం కనిపిస్తుంది. దీనికి SSH తప్ప మరేమీ అవసరం లేదు. మీరు చేతితో order చేసిన serverకూ ఈ నైపుణ్యం ఉపయోగపడుతుంది. environments ను పదేపదే rebuild చేసినప్పుడు లేదా servers కాకుండా DNS records, firewall rules వంటి ఇతర provider resources ను నిర్వహించినప్పుడు Terraform ప్రయోజనం కనిపిస్తుంది.

Terraform నుంచి కొత్త server IPని Ansibleలోకి ఎలా పంపాలి?

మీ Terraform codeలో `output ను declare చేయండి. తరువాత apply పూర్తయిన తర్వాత దాన్ని చదవండి. Shell substitution కోసం terraform output -raw web_ip bare value ను print చేస్తుంది. అనేక hosts ఉన్నప్పుడు terraform output -json అన్ని outputs ను ఒకేసారి ఇస్తుంది. ఆ విలువను inventory fileలో రాయండి. లేదా cloud.terraform collection ను install చేసి, ansible-inventory -i terraform.yml --graph` ను project directoryకి point చేయండి.

Terraform పూర్తైన వెంటనే నా playbook ఎందుకు విఫలమవుతుంది?

Provider యొక్క API server సృష్టించబడిందని చెప్పగానే, operating system ఇంకా boot అవుతున్నప్పటికీ, serverను createdగా report చేస్తుంది. అందువల్ల మొదటి కొన్ని secondsలో SSH తిరస్కరించబడుతుంది. `UNREACHABLE! లో Connection refused కారణంగా ఈ error వస్తుంది. ఊహించి sleep duration పెట్టడం బదులు, playలో ansible.builtin.wait_for_connection` ను మొదటి taskగా ఉంచండి. ఎందుకంటే boot time image మరియు plan ఆధారంగా మారుతుంది.