Ansible vs Terraform: Alin ang Kailangan Mo?

Ansible kumpara sa Terraform sa isang pangungusap

Ang Ansible kumpara sa 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 maging estado sa loob ng isang umiiral nang machine: mga package, user, config file, at tumatakbong service. Lumilikha ang Terraform ng VPS. Ginagawang web server ng Ansible ang VPS na iyon.

Parehong declarative ang mga ito, at parehong tinatawag na infrastructure as code (IaC). Ang tunay na pagkakaiba ay kung ano ang kanilang naaalala. Nagsusulat ang Terraform ng state file na nagmamapa sa bawat resource sa iyong code patungo sa isang aktuwal na object na nilikha nito sa pamamagitan ng API. Kaya nitong malaman na kapag nagtanggal ka ng limang linya, isang server ang kailangang i-destroy. Walang naaalala ang Ansible sa pagitan ng mga run. Kumokonekta ito sa pamamagitan ng SSH, sinusuri ang machine, at binabago lamang ang hindi pa tumutugma sa playbook.

Ipinapaliwanag ng pagkakaibang ito ang iba pang bahagi ng gabay na ito, kabilang kung bakit nagkakaproblema kapag pinaghahalo sa iisang tool ang dalawang trabahong ito.

Ano talaga ang ginagawa ng Terraform

Nakikipag-ugnayan ang Terraform sa isang API sa pamamagitan ng provider plugin. Tinutukoy sa registry page ng iyong provider ang mga uri ng resource na maaari mong isulat. Kaya magkaibang resource name at magkaibang argument ang server sa isang host at ang 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 dokumentado ng iyong provider. Ang output block ang mahalagang bahagi para sa gabay na ito, dahil ito ang paraan kung paano lumalabas sa Terraform ang address.

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

Dina-download ng terraform init ang provider at nagsusulat ito ng lock file. Ipinapakita ng terraform plan ang pagkakaiba sa pagitan ng iyong code at ng state file. Nagtatapos ito sa linyang tulad ng Plan: 1 to add, 0 to change, 0 to destroy. Basahin ang linyang iyon sa bawat pagkakataon. Hindi maaaring baguhin ang ilang argument nang hindi muling ginagawa ang resource. Ipinapakita ito ng plan sa pamamagitan ng # 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. Sa ganitong paraan 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 nasuri mo ang siyang aktuwal na tatakbo. Sa pagitan ng dalawang command, maaaring may ibang taong nagbago sa infrastructure.

Ang terraform.tfstate ang nagsisilbing memorya. Kapag nawala ito, hindi na alam ng Terraform na pagmamay-ari mo ang mga server na iyon. Kaya susubukan ng susunod na apply na gumawa ng mga duplicate. Itago ito sa remote backend kapag higit sa isang tao ang nagpapatakbo ng mga command. Kapag sabay na nag-a-apply ang dalawang tao, lalabas ito:

Error: Error acquiring the state lock

Ang OpenTofu ay fork ng Terraform na gumagamit ng parehong mga command at parehong file format. Simula Hulyo 2026, gumagana ang lahat sa gabay na ito kapag tofu ang tina-type mo sa halip na terraform.

Ang aktuwal na ginagawa ng Ansible

Hindi nangangailangan ang Ansible ng agent o API. Nagbubukas ito ng SSH connection, kumokopya ng maliit na Python module sa target, pinapatakbo ito, at pagkatapos ay dine-delete. 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 na gumagana ang SSH, Python, at sudo bago ka magsimulang mag-debug ng playbook. Ang wastong resulta ay web1 | SUCCESS => {"ping": "pong"}. Ang --check --diff run ang pinakamalapit na katumbas ng Ansible sa isang plan: iniuulat nito kung ano ang magbabago nang hindi talaga ito binabago. Gayunman, maaaring mali ang ulat ng mga task na umaasa sa mga naunang task kapag check mode, dahil hindi aktuwal na naganap ang naunang pagbabago.

Nagtatapos ang bawat run sa recap na gaya ng ok=6 changed=2 unreachable=0 failed=0. Patakbuhin nang dalawang beses ang parehong playbook. 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 isang VPS at palawakin ito mula roon.

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

Maaaring magpatakbo ang Terraform ng mga command sa bagong server gamit ang remote-exec provisioner. Itinuturing mismo ng dokumentasyon ng HashiCorp na huling paraan ang mga provisioner. May mabubuting dahilan para rito.

Tumatakbo lamang ang isang provisioner kapag ginawa ang resource. Kapag in-edit mo ang script, walang mangyayari sa kasalukuyang server dahil, mula sa pananaw ng Terraform, tumutugma na ang resource sa code. Hindi lumalabas sa terraform plan ang mga hakbang ng provisioner, kaya walang palatandaan ng mga ito sa iyong review. Kapag nag-fail ang script, minamarkahan ng Terraform ang resource bilang tainted. Sa susunod na apply, sisirain at muling bubuuin nito ang isang server na malamang ay maayos naman.

Hindi rin tama ang timing ng failure. Iniuulat ng provider na nagawa na ang server sa sandaling sabihin iyon ng 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 tuksong dala ng Ansible. Maaaring gumawa ng mga server ang mga cloud module, at gumagana ito para sa kakaunting machine. Ngunit isinusuko mo ang dependency graph at state file. Masaya nitong gagawin ang isang resource, pero kapag inalis mo ang task sa iyong playbook, mananatiling tumatakbo at sinisingil ang resource dahil walang nagtala na pagmamay-ari mo ito.

Ito ang prinsipyong nabubuo: ipaubaya sa Terraform ang pamamahala sa mga object na ginagawa at sinisira ng isang API, at ipaubaya sa Ansible ang lahat ng nasa loob ng isang naka-boot na operating system.

Maayos ang handoff

Ang handoff ay isang boundary, hindi integration. Tinatapos ng Terraform ang trabaho nito, naglalabas ng address, at humihinto. Nagsisimula naman 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

Ang terraform output -raw ay nagpi-print ng isang value nang walang quotes at walang JSON wrapper. Ito ang format na kailangan sa loob ng 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 hawakan ng -raw.

Mahalagang panatilihin ang hakbang na ping sa pagitan ng dalawang tool. Tinutulungan nitong paghiwalayin ang “maling address ang ibinigay ng Terraform” sa “may bug ang playbook.” Magmumukhang magkapareho ang dalawang problemang ito kapag ang playbook ang unang kumikilos sa bagong server.

Pagbasa sa 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 katabi 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 2 bagay na dapat mong malaman bago ito gamitin. Direktang pinapatakbo ng plugin ang terraform show laban sa project_path, kaya dapat na-initialize na ang directory na iyon; kung hindi, magfa-fail ang plugin. Hindi rin ito awtomatikong lumilikha ng mga host mula sa iyong server resources. Binabasa nito ang ansible_host at ansible_group resources, na dine-declare mo sa iyong Terraform code gamit ang Ansible provider. Walang lalabas sa ansible-inventory --graph hangga’t hindi mo idinaragdag ang mga ito.

Mas madaling i-debug ang plain generated inventory file at gumagana ito sa anumang provider. Nagiging kapaki-pakinabang ang plugin kapag lumampas na sa iilang machine ang inventory at nagsisimula nang magkaroon ng typo sa mano-manong pag-edit. Ito rin ang puntong ang pamamahala ng ilang Linux server mula sa iisang control machine ay nagiging aktuwal na workflow sa halip na nakasanayan lamang.

Kailangan mo ba talaga ang Terraform?

Karamihan sa nagbabasa nito ay hindi pa nangangailangan nito. Sulit ang Terraform kapag paulit-ulit na gawain mismo ang paglikha at pagtanggal ng infrastructure. Kung nag-order ka ng isang VPS sa pamamagitan ng control panel at balak mong gamitin ito sa loob ng dalawang taon, isang beses lang ilalarawan ng Terraform ang resource na iyon, at magdaragdag 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 minamanage mo—kabilang ang DNS records, load balancers, at firewall rules na nasa provider API.

Manatili sa Ansible lamang kapag matagal gamitin ang mga server at kakaunti ang mga ito, at kapag ang pang-araw-araw na tanong ay “tama ba ang configuration ng server na ito” sa halip na “umiiral ba ang server na ito”. Sinasaklaw ng iisang playbook na nagse-secure sa bagong server ang kaparehong gawain ng unang sampung minuto sa bagong VPS, at may dagdag na pakinabang na pareho itong tumatakbo sa susunod na server.

Nakasunod dito ang tamang pagkakasunod-sunod ng pag-aaral. Nagbabalik ng pakinabang ang Ansible sa unang server na pagmamay-ari mo. Nagbabalik ng pakinabang ang Terraform sa ikatlong environment na nire-rebuild mo.

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 pa nakikinig ang sshd. Hintayin ang port sa halip na magdagdag ng fixed sleep. May ansible.builtin.wait_for_connection ang Ansible para rito; patakbuhin ito bilang unang task ng play.

Nagbago ang host key. Sinira at muling ginawa mo 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. Madalas itong mangyari kapag ang Terraform na ang gumagawa ng rebuilding. Isa itong magandang dahilan para bihirang mag-rebuild ng mga machine na may 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 pagbabago sa plan na hindi mo isinulat. Ibig sabihin, nagkaroon ng drift ang aktuwal na infrastructure kumpara 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 tukuyin kung mali ang code o ang live resource. Huwag kailanman mag-apply ng destructive plan na hindi mo maipaliwanag line by line.

Nag-uulat ang Ansible ng changed sa bawat run. Ang shell task na walang creates o when guard ay palaging tumatakbo. Hindi lamang ito cosmetic na problema, dahil hindi mo na magagamit ang changed=0 bilang signal 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 scripts gamit ang remote-exec provisioner, pero tumatakbo lamang ang mga iyon kapag ginagawa ang resource. Hindi kailanman lumalabas ang mga ito 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 na module na tumitingin kung naka-install na ang nginx at walang ginagawa kung naka-install na ito. Gamitin ang Terraform para gawin ang machine, pagkatapos ay ipasa ang pamamahala sa Ansible.

Maaari bang palitan ng Ansible ang Terraform?

Para sa maliit na bilang ng mga server na pangmatagalang gagamitin, oo. May cloud modules ang Ansible para gumawa ng mga server. Kung nag-order ka ng dalawang VPS instance at pananatilihin 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 gumawa nito. Sa Terraform, naka-plano sana ang destroy.

Alin ang dapat kong unang pag-aralan?

Ansible, kung ikaw ang kasalukuyang namamahala sa mga server. Agad itong kapaki-pakinabang sa unang machine, SSH lang 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 record at firewall rule.

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

Magdeklara ng output sa iyong Terraform code, pagkatapos ay basahin ito matapos ang apply. Ipi-print ng terraform output -raw web_ip ang bare value para sa shell substitution, at ibinibigay ng terraform output -json ang lahat ng output nang sabay-sabay kapag maraming host. Isulat ito 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 pagkatapos 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-reject 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.