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

ఒక వాక్యంలో 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 కు అనుసంధానిస్తుంది. అందువల్ల ఐదు lines తొలగిస్తే ఒక server ను నాశనం చేయాలని అది గుర్తించగలదు. Ansible runs మధ్య ఏదీ గుర్తుంచుకోదు. అది SSH ద్వారా connect అవుతుంది, machine ను inspect చేస్తుంది, playbook కు ఇప్పటికే సరిపోని వాటినే మారుస్తుంది.

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

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

Terraform, provider plugin ద్వారా APIతో అనుసంధానమవుతుంది. మీరు వ్రాయగల resource typesను మీ provider registry పేజీ నిర్వచిస్తుంది. అందువల్ల ఒక 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పైనే మార్చలేరు. అలాంటి attribute పక్కన # forces replacement చూపించి, దాని తర్వాత 1 to add, 0 to change, 1 to destroy వస్తుంది. ఆ planను apply చేస్తే server తొలగిపోయి, కొత్త ఖాళీ server సృష్టించబడుతుంది. సురక్షితంగా ఉందని భావించిన dataను ప్రజలు ఈ విధంగా కోల్పోతారు.

సాధారణ terraform apply commandను నడపడానికి బదులుగా 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 చేస్తుంది, దాన్ని అమలు చేసి, తర్వాత తొలగిస్తుంది. 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 కాదు. సాధారణంగా అది command లేదా shell task అయి ఉంటుంది. దాని స్థానంలో నిజమైన moduleను ఉపయోగించాలి. ఇది మీకు కొత్త విషయం అయితే, ఒకే VPSపై మొదటి Ansible playbookతో ప్రారంభించి, అక్కడి నుంచి విస్తరించండి.

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

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ను తొలగించి మళ్లీ నిర్మిస్తుంది.

విఫలమయ్యే సమయం కూడా సమస్యాత్మకంగా ఉంటుంది. API server సృష్టించబడిందని చెప్పగానే provider serverను సృష్టించినట్లు నివేదిస్తుంది. అయితే అప్పటికీ 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 అమలులోనే ఉంటుంది మరియు దానికి billing కొనసాగుతుంది. అది ఎప్పుడైనా మీ సొత్తుగా ఉందని నమోదు చేసిన వ్యవస్థ ఏదీ ఉండదు.

దీనినుంచి వచ్చే నియమం ఇది: API సృష్టించి తొలగించే objectsను Terraform నిర్వహించాలి. Boot అయిన operating systemలోని ప్రతిదాన్ని 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 ఎలాంటి quotes మరియు JSON wrapper లేకుండా ఒక విలువను ప్రింట్ చేస్తుంది. Shell substitution లో మీకు కావలసింది ఇదే. అనేక servers కోసం terraform output -json ను ఉపయోగించి, దాని ఆధారంగా inventory ను రూపొందించండి. ఎందుకంటే -raw ఒకే string, number లేదా boolean ను మాత్రమే నిర్వహిస్తుంది.

రెండు tools మధ్య ping దశను ఉంచడం ఉపయోగకరం. దీని ద్వారా "Terraform నాకు తప్పు address ఇచ్చింది" అనే సమస్యను "నా playbook లో bug ఉంది" అనే సమస్య నుంచి వేరు చేయవచ్చు. కొత్త box ను playbook మొదటిసారి తాకినప్పుడు, ఈ రెండు సమస్యలు ఒకేలా కనిపిస్తాయి.

Ansible inventoryగా Terraform stateను చదవడం

మీరు inventory ఫైల్‌ను అసలు రాయకూడదనుకుంటే, 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కి ఇప్పటికే initialize చేసి ఉండాలి. లేకపోతే plugin విఫలమవుతుంది. అలాగే ఇది మీ server resources నుంచి hostsను స్వయంగా సృష్టించదు. ఇది ansible_host మరియు ansible_group resourcesను చదువుతుంది. వీటిని Terraform codeలో Ansible providerను ఉపయోగించి మీరు ప్రకటించాలి. వాటిని జోడించే వరకు ansible-inventory --graphలో ఏదీ కనిపించదు.

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

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

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

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

Servers ఎక్కువకాలం ఉండేవి, సంఖ్యలో తక్కువగా ఉండేవి అయితే, అలాగే రోజువారీ ప్రశ్న "ఈ box సరిగ్గా configure చేయబడిందా" అనే దానికంటే "ఈ box ఉందా" అనేది కాకపోతే, Ansible తోనే కొనసాగండి. కొత్త server ను సురక్షితం చేసే ఒక 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 listening ప్రారంభించకముందే API ఒక addressను అందించింది. నిర్ణీత వ్యవధి 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 rebuild చేయడం ప్రారంభించిన తర్వాత ఇది తరచుగా జరుగుతుంది. అందువల్ల data ఉన్న యంత్రాలపై rebuildలను అరుదుగా చేయాలి.

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గా report చేస్తోంది. creates లేదా when guard లేని shell task షరతులేమీ లేకుండా అమలవుతుంది. ఇది కేవలం cosmetic సమస్య కాదు. మీరు కోరిన stateలో server ఉందని సూచించడానికి changed=0ను ఇక ఉపయోగించలేరని దీని అర్థం.

FAQ

Terraform, Ansible స్థానంలో పనిచేయగలదా?

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

Ansible, Terraform స్థానంలో పనిచేయగలదా?

కొన్ని long-lived 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కు మించిన provider resources, ఉదాహరణకు DNS records మరియు firewall rulesను నిర్వహించినప్పుడు 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 సృష్టించబడిందని చెప్పగానే దాన్ని createdగా report చేస్తుంది. అయితే అప్పటికీ operating system boot అవుతూనే ఉంటుంది. అందువల్ల మొదటి కొన్ని secondsలో SSH తిరస్కరించబడుతుంది. UNREACHABLE!తో వచ్చే లోపం Connection refused. నిద్ర వ్యవధిని ఊహించి నిర్ణయించకుండా, playలో ansible.builtin.wait_for_connectionను మొదటి taskగా ఉంచండి. ఎందుకంటే boot time image మరియు planపై ఆధారపడి మారుతుంది.