Ansible vs Terraform: Alin ang Kailangan Mo?

Ansible at Terraform sa isang pangungusap

Ang Ansible at Terraform ay hindi pagpili sa pagitan ng dalawang tool na pareho ang ginagawa. Idinedeklara ng Terraform kung anong infrastructure ang umiiral: mga server, disk, network, at DNS record. Idinedeklara naman ng Ansible kung ano ang dapat na kalagayan sa loob ng isang machine na umiiral na: mga package, user, config file, at tumatakbong service. Lumilikha ang Terraform ng VPS. Ginagawang web server ng Ansible ang VPS na iyon.

Pareho silang declarative, at pareho silang tinatawag na infrastructure as code (IaC). Ang tunay na pagkakaiba ay kung ano ang naaalala ng mga ito. Gumagawa ang Terraform ng state file na nagmamapa sa bawat resource sa code mo papunta sa aktuwal na object na ginawa nito sa pamamagitan ng API. Dahil dito, malalaman nitong ang pagbura ng limang linya ay nangangahulugang kailangang i-destroy ang isang server. Walang inaalala ang Ansible sa pagitan ng mga run. Kumokonekta ito sa pamamagitan ng SSH, iniinspeksyon ang machine, at binabago lamang ang mga bagay na hindi pa tumutugma sa playbook.

Ipinapaliwanag ng nag-iisang pagkakaibang ito ang iba pang bahagi ng guide na ito, pati kung bakit nagkakaproblema kapag pinaghalo sa iisang tool ang dalawang tungkulin.

Ano talaga ang ginagawa ng Terraform

Nakikipag-ugnayan ang Terraform sa isang API sa pamamagitan ng provider plugin. Tinutukoy sa registry page ng provider mo ang mga resource type na maaari mong isulat. Kaya magkaiba ang resource name at mga argument para sa isang server sa isang host at sa isang server sa ibang host.

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

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

Palitan ang cloud_server ng resource type na nakadokumento sa provider mo. Ang output block ang mahalagang bahagi para sa guide na ito, dahil dito lumalabas sa Terraform ang address.

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

Idini-download ng terraform init ang provider at nagsusulat ito ng lock file. Ipinapakita ng terraform plan ang pagkakaiba sa pagitan ng code mo at ng state file. Nagtatapos ito sa linyang gaya ng Plan: 1 to add, 0 to change, 0 to destroy. Basahin ang linyang iyon sa bawat pagkakataon. May ilang argument na hindi maaaring baguhin nang hindi nire-recreate ang resource. Ipinapakita ito ng plan gamit ang # forces replacement sa tabi ng attribute, na sinusundan ng 1 to add, 0 to change, 1 to destroy. Kapag inilapat ang plan na iyon, dine-delete ang server at gumagawa ng bagong walang laman na server. Ganito nawawala ang data na inakala ng mga tao na ligtas.

Kapag sine-save ang plan sa isang file at inilalapat ang file, sa halip na direktang patakbuhin ang terraform apply, ang nire-review mong pagbabago ang siyang tumatakbo. Sa pagitan ng dalawang command, maaaring may ibang taong nagbago sa infrastructure.

Ang terraform.tfstate ang memory. Kapag nawala ito, hindi na alam ng Terraform na sa iyo ang mga server na iyon, kaya susubukan ng susunod na apply na gumawa ng mga duplicate. Itago ito sa isang remote backend kapag higit sa isang tao ang nagpapatakbo ng mga command, dahil kapag sabay na nag-apply ang dalawang tao, lalabas ito:

Error: Error acquiring the state lock

Ang OpenTofu ay isang fork ng Terraform na may parehong command at parehong file format. Simula Hulyo 2026, gumagana ang lahat sa guide na ito kapag nag-type ka ng tofu sa halip na terraform.

Ang aktuwal na ginagawa ng Ansible

Hindi nangangailangan ang Ansible ng agent o API. Nagbubukas ito ng koneksiyong SSH, kumokopya ng maliit na Python module sa target, pinapatakbo ito, at dine-delete pagkatapos. Anumang maaabot mo gamit ang SSH at sudo password ay maaaring i-configure ng Ansible.

- 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

Pinatutunayan ng ping module ang SSH, Python, at sudo bago ka magsimulang mag-debug ng playbook. Ang maayos na resulta ay web1 | SUCCESS => {"ping": "pong"}. Ang --check --diff run ang pinakamalapit na katumbas ng plan ng Ansible: iniuulat nito kung ano ang magbabago nang hindi aktuwal na nagbabago, ngunit maaaring mali ang ulat ng mga task na nakadepende sa mga naunang task kapag nasa check mode, dahil hindi talaga nangyari ang naunang pagbabago.

Nagtatapos ang bawat run sa recap gaya ng ok=6 changed=2 unreachable=0 failed=0. Patakbuhin ang parehong playbook nang dalawang beses. Dapat iulat ng ikalawang run ang changed=0. Ang task na nag-uulat ng changed sa bawat run ay hindi idempotent. Karaniwan itong command o shell task na dapat ay gumamit ng totoong module. Kung bago sa iyo ang paksang ito, magsimula sa unang Ansible playbook sa iisang VPS at palawakin ito mula roon.

Kung saan nagsasapawan ang dalawang tool, at kung saan nagkakaroon ng problema

Maaaring magpatakbo ang Terraform ng mga command sa bagong server gamit ang remote-exec provisioner. Itinuturing ng sariling documentation ng HashiCorp na huling paraan ang mga provisioner. May mabubuting dahilan dito.

Isang beses lang tumatakbo ang provisioner, kapag ginagawa ang resource. Kapag in-edit mo ang script, walang mangyayari sa kasalukuyang server dahil para sa Terraform, tumutugma na ang resource sa code. Hindi lumalabas sa terraform plan ang mga hakbang ng provisioner, kaya walang bakas nito sa iyong review. Kapag nag-fail ang script, minamarkahan ng Terraform ang resource bilang tainted. Sa susunod na apply, ide-delete at ire-rebuild nito ang server kahit malamang ay maayos naman ito.

Hindi rin maganda ang timing ng failure. Iniuulat ng provider na nagawa na ang server sa sandaling magbigay ng ganoong tugon ang API, habang nagbo-boot pa ang operating system at hindi pa nakikinig ang sshd.

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

Kabaligtaran naman ang tukso sa Ansible. Maaaring gumawa ng mga server ang mga cloud module, at gumagana ito para sa kakaunting machine. Ang mawawala sa iyo ay ang dependency graph at state file. Gagawa ang Ansible ng resource, pero kapag inalis mo ang task sa playbook, mananatiling tumatakbo at patuloy na sisingilin ang resource dahil walang nagtala na pagmamay-ari mo ito.

Ito ang praktikal na tuntunin: Terraform ang dapat mamahala sa mga object na ginagawa at dini-delete ng isang API, at Ansible ang dapat mamahala sa lahat ng nasa loob ng naka-boot na operating system.

Ang handoff, isinagawa

Ang handoff ay isang boundary, hindi isang integration. Tinatapos ng Terraform ang gawain nito, naglalabas ng address, at hihinto. Magsisimula ang Ansible gamit ang address na iyon.

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

Nagpi-print ang terraform output -raw ng isang value nang walang quotes at walang JSON wrapper. Ito ang kailangan sa loob ng isang shell substitution. Para sa maraming server, gamitin ang terraform output -json at buuin ang inventory mula rito, dahil isang string, number, o boolean lang ang kayang pangasiwaan ng -raw.

Mahalagang panatilihin ang hakbang na ping sa pagitan ng dalawang tool. Tinutulungan nitong paghiwalayin ang sitwasyong "maling address ang ibinigay ng Terraform" mula sa "may bug ang playbook." Magkapareho ang hitsura ng dalawang problemang ito kapag ang playbook ang unang kumikilos sa bagong server.

Pagbasa ng Terraform state bilang Ansible inventory

Kung ayaw mong magsulat ng inventory file, direktang binabasa ng cloud.terraform collection ang state.

ansible-galaxy collection install cloud.terraform

Isulat ang terraform.yml sa tabi ng iyong playbook:

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

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

May dalawang bagay kang kailangang malaman bago mo ito gamitin. Pinapatakbo ng plugin ang terraform show laban sa project_path, kaya dapat ay initialized na ang directory na iyon. Kung hindi, mabibigo ang plugin. Hindi rin ito awtomatikong gumagawa ng mga host mula sa server resources mo. Binabasa nito ang ansible_host at ansible_group resources, na idinedeklara mo sa Terraform code gamit ang Ansible provider. Walang lilitaw sa ansible-inventory --graph hangga't hindi mo idinadagdag ang mga ito.

Mas madaling i-debug ang isang plain generated inventory file, at gumagana ito sa anumang provider. Mas kapaki-pakinabang ang plugin kapag lumampas na sa ilang machine ang inventory at nagsisimula nang magkaroon ng typo sa manual na pag-edit. Ito rin ang punto kung kailan nagiging aktuwal na workflow, sa halip na nakasanayan lamang, ang pamamahala ng ilang Linux server mula sa iisang control machine.

Kailangan mo ba talaga ang Terraform?

Karamihan sa mga nagbabasa nito ay hindi pa nangangailangan nito, kahit sa ngayon. Sulit ang Terraform kapag paulit-ulit na gawain mismo ang paggawa at pagtanggal ng infrastructure. Kung nag-order ka ng isang VPS sa pamamagitan ng control panel at balak mo itong panatilihin sa loob ng dalawang taon, isang beses lang inilalarawan ng Terraform ang gagawing infrastructure. Nagdaragdag din ito ng state file na hindi mo dapat mawala.

Gamitin ang Terraform kapag madalas kang nagre-rebuild ng mga environment, kapag kailangang eksaktong magkapareho ang staging at production, kapag maraming taong nagbabago ng infrastructure at gusto mo ng planong maaaring i-review bago may matanggal, o kapag higit pa sa mga server ang mina-manage mo—kabilang ang DNS records, load balancers, at firewall rules na nasa provider API.

Manatili sa Ansible lamang kapag matagal nang ginagamit at kakaunti ang mga server, at kapag ang karaniwang tanong ay “tama ba ang configuration ng server na ito” sa halip na “umiiral ba ang server na ito.” Sinasaklaw ng isang playbook na nagha-harden ng bagong server ang parehong mga hakbang gaya ng unang sampung minuto sa isang bagong VPS, at pareho rin itong tatakbo sa susunod na server.

Dito nakabatay ang tamang pagkakasunod-sunod ng pag-aaral. Nagbibigay na ng pakinabang ang Ansible sa unang server na pagmamay-ari mo. Nagbibigay naman ng pakinabang ang Terraform sa ikatlong environment na muli mong bina-build.

Ano ang nasisira sa handoff

Hindi pa handa ang server. Matagumpay ang Terraform, pero agad na nabibigo ang 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}

Nagbalik ang API ng address bago nakikinig ang sshd. Hintayin ang port sa halip na magdagdag ng fixed sleep. May ansible.builtin.wait_for_connection ang Ansible para mismo rito; patakbuhin ito bilang unang task ng play. Kapag nagta-target na ang parehong playbook ng isang group sa halip na isang bagong box, pagpasiyahan nang maaga kung ano ang dapat mangyari kapag nananatiling hindi maaabot ang isang host, dahil inaalis ng Ansible ang host na iyon sa natitirang run at ang recap line lang ang nagsasabi nito.

Nagbago ang host key. Sinira at ginawa mong muli ang server, at sumasagot ang bago sa parehong address gamit ang bagong key.

Host key verification failed.

Alisin ang lumang entry gamit ang ssh-keygen -R 203.0.113.10. Palagi itong nangyayari kapag Terraform na ang gumagawa ng rebuild, kaya makatuwirang bihira lamang mag-rebuild ng mga machine na naglalaman ng data.

Nabibigo ang Sudo. Ibig sabihin ng fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} na nangangailangan ng password ang become: true sa host na iyon. I-configure ang passwordless sudo para sa deploy user, o ipasa ang --ask-become-pass.

Gustong mag-destroy ng Terraform ng bagay na hindi mo ginalaw. May mga pagbabagong ipinapakita ang plan na hindi mo isinulat. Ibig sabihin, lumihis ang aktuwal na infrastructure mula sa code, karaniwan dahil may nagbago ng setting sa web panel ng provider. Patakbuhin ang terraform plan -refresh-only upang makita lamang ang pagkakaibang iyon, pagkatapos ay pagpasiyahan kung mali ang code o ang live resource. Huwag kailanman mag-apply ng destructive plan na hindi mo maipaliwanag sa bawat linya.

Nagrereport ang Ansible ng changed sa bawat run. Palaging tumatakbo ang isang shell task na walang creates o when guard. Hindi lang ito usaping kosmetiko, dahil hindi mo na magagamit ang changed=0 bilang palatandaan na nasa hinihingi mong state ang server.

FAQ

Maaari bang palitan ng Terraform ang Ansible?

Hindi para sa configuration sa loob ng server. Maaaring magpatakbo ang Terraform ng mga script gamit ang remote-exec provisioner, pero tumatakbo lamang ang mga ito kapag ginagawa ang resource, hindi kailanman lumalabas sa terraform plan, at tina-taint ang resource kapag nag-fail ang mga ito. Dahil dito, naka-schedule ang destroy at rebuild sa susunod na apply. Walang katumbas ang Terraform ng module na tumitingin kung naka-install na ang nginx at walang ginagawa kung naka-install na ito. Gamitin ang Terraform para likhain ang machine, pagkatapos ay ipasa ito sa Ansible.

Maaari bang palitan ng Ansible ang Terraform?

Oo, para sa kaunting bilang ng mga server na matagal mong patatakbuhin. May cloud modules ang Ansible na lumilikha ng mga server. Kung nag-order ka ng dalawang VPS instance at pananatilihin mo ang mga ito, sapat na iyon. Ang mawawala sa iyo ay ang state file at dependency graph. Kapag nag-alis ka ng task sa playbook, patuloy na tatakbo ang resource at patuloy na sisingilin, dahil hindi itinala ng Ansible na ito ang lumikha sa resource. Magpaplano sana ang Terraform ng destroy.

Alin ang dapat kong unang pag-aralan?

Ansible, kung namamahala ka na ng mga server ngayon. Agad itong kapaki-pakinabang sa unang machine, SSH lamang ang kailangan, at magagamit ang skill sa server na mano-mano mong in-order. Mas kapaki-pakinabang ang Terraform sa paglaon, kapag paulit-ulit kang nagre-rebuild ng mga environment o namamahala ng provider resource bukod sa mga server, gaya ng DNS records at firewall rules.

Paano ko ipapasa ang bagong IP ng server mula Terraform papunta sa Ansible?

Magdeklara ng output sa Terraform code mo, pagkatapos ay basahin ito pagkatapos ng apply. Ipi-print ng terraform output -raw web_ip ang bare value para sa shell substitution, at ibibigay ng terraform output -json ang lahat ng output nang sabay-sabay kapag maraming host. Isulat iyon sa isang inventory file, o i-install ang cloud.terraform collection at ituro ang ansible-inventory -i terraform.yml --graph sa project directory.

Bakit nagfa-fail ang playbook ko kaagad matapos matapos ang Terraform?

Iniuulat ng provider na nagawa na ang server sa sandaling sabihin iyon ng API nito, habang nagbo-boot pa ang operating system. Dahil dito, nire-refuse ang SSH sa unang mga segundo. Ang error ay UNREACHABLE! kasama ang Connection refused. Gawing unang task sa play ang ansible.builtin.wait_for_connection sa halip na manghula ng tagal ng sleep, dahil nag-iiba ang boot time depende sa image at sa plan.