Ansible au Terraform: ipi ya kuchagua kwa miundombinu?

Ansible dhidi ya Terraform katika sentensi moja

Ansible dhidi ya Terraform si chaguo kati ya zana mbili zinazofanya kazi sawa. Terraform hutangaza miundombinu iliyopo: seva, diski, mitandao, rekodi za DNS. Ansible hutangaza hali inayopaswa kuwepo ndani ya mashine iliyopo tayari: vifurushi, watumiaji, faili za usanidi, huduma zinazoendelea. Terraform huunda VPS. Ansible huigeuza VPS hiyo kuwa seva ya wavuti.

Zote mbili ni za kiutangazaji (declarative), na zote huitwa miundombinu kama msimbo (IaC). Tofauti ya kweli ni kile wanachokikumbuka. Terraform huandika faili ya hali (state file) inayochora ramani ya kila rasilimali katika msimbo wako kuelekea kitu halisi ilichounda kupitia API, hivyo inaweza kusema kuwa kufuta mistari mitano inamaanisha seva moja lazima iharibiwe. Ansible haikumbuki chochote kati ya uendeshaji mmoja na mwingine. Huunganisha kupitia SSH, hukagua mashine, na kubadilisha tu kile ambacho hakilingani na playbook.

Tofauti hiyo moja inaelezea sehemu iliyobaki ya mwongozo huu, ikiwemo sababu kwa nini kuchanganya kazi hizo mbili kwenye zana moja huleta matatizo.

Kile ambacho Terraform hufanya kwa hakika

Terraform huwasiliana na API kupitia plugin ya provider. Ukurasa wa registry wa provider wako hufafanua aina za resource unazoweza kuandika, kwa hivyo seva kwenye host moja na seva kwenye host nyingine ni majina tofauti ya resource yenye hoja (arguments) tofauti.

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

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

Badilisha cloud_server na aina ya resource ambayo provider wako anaiandika kwenye nyaraka zake. Block ya output ndiyo sehemu muhimu kwa mwongozo huu, kwa sababu ndiyo njia ambayo anwani huondoka kwenye Terraform.

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

terraform init hupakua provider na kuandika faili ya lock. terraform plan huchapisha tofauti kati ya code yako na faili ya state, na kuishia kwenye mstari kama Plan: 1 to add, 0 to change, 0 to destroy.. Soma mstari huo kila wakati. Hoja nyingine haziwezi kubadilishwa bila kufuta na kuunda upya (in place), na mpango (plan) husema hivyo kwa # forces replacement karibu na attribute husika, ikifuatiwa na 1 to add, 0 to change, 1 to destroy. Kutekeleza (apply) mpango huo hufuta seva na kuunda mpya tupu, jambo ambalo ndilo husababisha watu kupoteza data walizodhani ziko salama.

Kuhifadhi mpango kwenye faili na kuitekeleza faili hiyo, badala ya kuendesha terraform apply pekee, inamaanisha kuwa kitu ulichokikagua ndicho kinachotekelezwa. Kati ya amri hizo mbili, mtu mwingine anaweza kuwa amebadilisha miundombinu.

terraform.tfstate ndiyo kumbukumbu. Ukiipoteza, Terraform haitajua tena kuwa seva hizo ni zako, kwa hivyo apply inayofuata itajaribu kuunda nakala (duplicates). Ihifadhi kwenye backend ya mbali (remote backend) mara tu zaidi ya mtu mmoja anapoanza kuendesha amri hizo, kwa sababu watu wawili wakifanya apply kwa wakati mmoja husababisha hili:

Error: Error acquiring the state lock

OpenTofu ni fork ya Terraform yenye amri zilezile na muundo wa faili uleule. Kufikia Julai 2026, kila kitu katika mwongozo huu hufanya kazi ukiandika tofu badala ya terraform.

Kile ambacho Ansible hufanya kwa hakika

Ansible haihitaji agent wala API. Hufungua muunganisho wa SSH, hunakili moduli ndogo ya Python kwenye lengwa, huiendesha, kisha huifuta. Kila kitu unachoweza kukifikia kwa SSH na nenosiri la sudo, Ansible inaweza kukisanidi.

- 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

Moduli ya ping huthibitisha SSH, Python na sudo kabla ya kuanza kutatua hitilafu kwenye playbook. Matokeo mazuri ni web1 | SUCCESS => {"ping": "pong"}. Uendeshaji wa --check --diff ndio kitu cha karibu zaidi na mpango katika Ansible: huripoti kile ambacho kingebadilika bila kukibadilisha, ingawa kazi zinazotegemea kazi za awali zinaweza kuripoti vibaya katika hali ya check, kwa sababu mabadiliko ya awali hayakutokea kwa hakika.

Kila uendeshaji huishia na muhtasari kama ok=6 changed=2 unreachable=0 failed=0. Endesha playbook ileile mara mbili. Uendeshaji wa pili unapaswa kuripoti changed=0. Kazi inayoripoti changed katika kila uendeshaji si idempotent, na kwa kawaida ni kazi ya command au shell ambayo ilipaswa kuwa moduli halisi. Ikiwa hili ni jambo geni kwako, anza na playbook ya kwanza ya Ansible kwenye VPS moja na uendeleze kutoka hapo.

Mahali ambapo zana hizi mbili huingiliana, na mahali zinapogongana

Terraform inaweza kuendesha amri kwenye seva mpya kwa kutumia remote-exec provisioner. Nyaraka za HashiCorp zenyewe zinaita provisioners kama njia ya mwisho. Kuna sababu nzuri za kufanya hivyo.

Provisioner huendeshwa tu wakati rasilimali inapoundwa. Ukibadilisha hati (script) hakuna kitakachotokea kwenye seva iliyopo, kwa sababu kwa mtazamo wa Terraform rasilimali tayari inalingana na msimbo (code). Hatua za provisioner hazionekani kamwe kwenye terraform plan, kwa hivyo ukaguzi wako hauonyeshi ishara yoyote ya hatua hizo. Ikiwa hati itashindwa, Terraform huweka alama ya tainted kwenye rasilimali, na amri inayofuata ya apply itaharibu na kuunda upya seva ambayo pengine ilikuwa sawa.

Kushindwa huku pia hutokea wakati usiofaa. Mtoa huduma (provider) huripoti seva kama iliyoundwa mara tu API inapothibitisha, wakati mfumo wa uendeshaji bado unawaka na sshd haijasikiliza bado.

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

Ansible ina kishawishi cha kinyume. Moduli za wingu (cloud modules) zinaweza kuunda seva, na kwa mashine chache hilo hufanya kazi. Unachopoteza ni grafu ya utegemezi (dependency graph) na faili ya hali (state file). Ansible itaunda rasilimali kwa furaha, lakini ukifuta kazi hiyo kutoka kwenye playbook yako, rasilimali hiyo itaendelea kufanya kazi na utaendelea kutozwa gharama, kwa sababu hakuna rekodi iliyoonyesha kuwa ilikuwa yako.

Kanuni inayotokana na hili ni: iache Terraform imiliki vitu ambavyo API huunda na kuharibu, na iache Ansible imiliki kila kitu ndani ya mfumo wa uendeshaji uliokwisha kuwaka.

Uhamisho umefanikiwa

Uhamisho ni mpaka, siyo muunganisho. Terraform inamaliza kazi, inachapisha anwani, na kusimama. Ansible inaanza kutumia anwani hiyo.

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 huchapisha thamani moja bila alama za kunukuu na bila kanga ya JSON, jambo ambalo unahitaji ndani ya shell substitution. Kwa seva kadhaa, tumia terraform output -json na ujenge inventory kutoka hapo, kwa sababu -raw inashughulikia string, namba au boolean moja pekee.

Hatua ya ping kati ya zana hizi mbili inafaa kuhifadhiwa. Inatenganisha tatizo la "Terraform imenipa anwani isiyo sahihi" na "playbook yangu ina hitilafu", na matatizo hayo mawili yanaonekana sawa kabisa wakati playbook ndiyo kitu cha kwanza kugusa seva mpya.

Kusoma hali ya Terraform kama inventory ya Ansible

Ikiwa hutaki kuandika faili ya inventory kabisa, mkusanyiko wa cloud.terraform husoma hali hiyo moja kwa moja.

ansible-galaxy collection install cloud.terraform

Andika terraform.yml karibu na playbook yako:

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

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

Mambo mawili ya kuzingatia kabla ya kuitegemea. Plugin hii huendesha terraform show dhidi ya project_path, kwa hivyo saraka hiyo lazima iwe imeshaanzishwa (initialized) au plugin itashindwa kufanya kazi. Pia, haitengenezi hosts kutoka kwa rasilimali za seva yako: inasoma rasilimali za ansible_host na ansible_group, ambazo unazitangaza katika msimbo wako wa Terraform kwa kutumia Ansible provider. Hakuna kitakachoonekana katika ansible-inventory --graph hadi utakapoziongeza.

Faili ya inventory iliyotengenezwa kwa njia ya kawaida ni rahisi zaidi kutatua hitilafu (debug) na inafanya kazi na provider yoyote. Plugin hii inaleta faida pindi inventory inapokuwa kubwa zaidi ya mashine chache na uhariri wa mikono unapoanza kusababisha makosa ya chapa (typos), ambayo ndiyo hatua ile ile ambapo kusimamia seva kadhaa za Linux kutoka mashine moja ya udhibiti inakuwa mtiririko wa kazi halisi badala ya mazoea tu.

Je, unahitaji kweli Terraform?

Watu wengi wanaosoma hapa hawahitaji, angalau kwa sasa. Terraform inaleta faida pale ambapo kuunda na kufuta miundombinu ni kazi inayojirudia. Ikiwa umeagiza VPS moja kupitia paneli ya udhibiti na unakusudia kuitumia kwa miaka miwili, Terraform inaelezea kitu kinachotokea mara moja tu, na kuongeza faili ya state ambayo hupaswi kuipoteza.

Tumia Terraform pale unapojenga upya mazingira mara kwa mara, pale staging inapopaswa kufanana kabisa na production, pale watu kadhaa wanapobadilisha miundombinu na unataka mpango unaoweza kupitiwa kabla ya kitu chochote kufutwa, au pale unachokisimamia kinapovuka mipaka ya seva na kuingia kwenye DNS records, load balancers na sheria za firewall zinazopatikana kwenye API ya mtoa huduma.

Baki na Ansible pekee pale seva zinapokuwa za muda mrefu na chache, na pale swali la kila siku linapokuwa "je, mashine hii imesanidiwa kwa usahihi" badala ya "je, mashine hii ipo". Playbook moja inayolinda seva mpya inashughulikia mambo yaleyale kama dakika kumi za kwanza kwenye VPS mpya, ikiwa na faida kwamba inafanya kazi kwa njia ileile kwenye seva inayofuata.

Mpangilio wa kujifunza unatokana na hilo. Ansible inaleta faida kwenye seva ya kwanza unayomiliki. Terraform inaleta faida kwenye mazingira ya tatu unayojenga upya.

Nini kinaharibika wakati wa makabidhiano

Seva haijawa tayari. Terraform inafanikiwa, lakini Ansible inafeli mara moja.

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}

API ilirejesha anwani kabla ya sshd kuanza kusikiliza. Subiri port ifunguke badala ya kuongeza muda wa kusubiri (sleep) usiobadilika. Ansible ina ansible.builtin.wait_for_connection kwa ajili hiyo, iendeshe kama task ya kwanza ya play. Mara tu playbook inapowalenga kundi la seva badala ya mashine moja mpya, amua mapema nini kifanyike wakati host mmoja anaposhindwa kufikika, kwa sababu Ansible humtoa host huyo kwenye mzunguko uliobaki na mstari wa muhtasari ndio sehemu pekee inayokupa taarifa hiyo.

Host key imebadilika. Umeivunja na kuijenga upya seva, na ile mpya inajibu kwenye anwani ileile ikiwa na key mpya.

Host key verification failed.

Ondoa entry ya zamani kwa kutumia ssh-keygen -R 203.0.113.10. Hili hutokea mara kwa mara wakati Terraform inapofanya ujenzi upya, jambo ambalo ni sababu nzuri ya kuepuka ujenzi wa mara kwa mara kwenye mashine zenye data.

Sudo inafeli. fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} inamaanisha become: true inahitaji nenosiri kwenye host huyo. Sanidi sudo isiyo na nenosiri kwa mtumiaji wa deploy, au pitisha --ask-become-pass.

Terraform inataka kuharibu kitu ambacho hukugusa. Mpango (plan) unaonyesha mabadiliko ambayo hukuyaandika, jambo linalomaanisha kuwa miundombinu halisi imepotoka kutoka kwenye code, kwa kawaida kwa sababu mtu amebadilisha mpangilio kwenye paneli ya mtandao ya provider. Endesha terraform plan -refresh-only ili kuona tofauti hiyo yenyewe, kisha amua kama code au resource iliyopo ndiyo yenye makosa. Usiwahi kutekeleza (apply) mpango wa uharibifu ambao huwezi kuuelezea mstari kwa mstari.

Ansible inaripoti mabadiliko (changed) kila inapoendeshwa. Task ya shell isiyo na creates au when huendeshwa bila masharti. Hilo si tatizo la kurembesha tu, kwa sababu inamaanisha huwezi tena kutumia changed=0 kama ishara kwamba seva iko katika hali uliyoiomba.

FAQ

Je, Terraform inaweza kuchukua nafasi ya Ansible?

Hapana kwa usanidi wa ndani ya seva. Terraform inaweza kuita hati kwa kutumia remote-exec provisioner, lakini hizo huendeshwa wakati wa kuunda rasilimali pekee, hazionekani kamwe kwenye terraform plan, na husababisha rasilimali kuwekewa alama ya "taint" ikifeli, jambo linalopanga kufutwa na kuundwa upya katika output inayofuata. Terraform haina mfumo sawa na moduli inayokagua kama nginx imesakinishwa tayari na kutochukua hatua yoyote ikiwa imesakinishwa. Tumia Terraform kuunda mashine, kisha kabidhi kazi kwa Ansible.

Je, Ansible inaweza kuchukua nafasi ya Terraform?

Kwa idadi ndogo ya seva zinazodumu kwa muda mrefu, ndiyo. Ansible ina moduli za wingu zinazounda seva, na ukiagiza VPS mbili na kuzihifadhi, hiyo inatosha. Unachopoteza ni faili ya hali (state file) na grafu ya utegemezi: ukiondoa kazi kwenye playbook, rasilimali itaendelea kufanya kazi na kuendelea kutoza gharama, kwa sababu Ansible haikurekodi kamwe kuwa iliiumba. Terraform ingepanga kuifuta.

Ni ipi ninayopaswa kujifunza kwanza?

Ansible, ikiwa unamiliki seva leo. Inaleta faida kwenye mashine ya kwanza, haihitaji chochote isipokuwa SSH, na ujuzi huo unatumika kwenye seva uliyoiagiza kwa mikono. Terraform inaleta faida baadaye, unapojenga upya mazingira mara kwa mara au kusimamia rasilimali za mtoa huduma nje ya seva, kama vile DNS records na sheria za firewall.

Ninawezaje kupitisha IP ya seva mpya kutoka Terraform kwenda Ansible?

Tangaza output katika msimbo wako wa Terraform, kisha isome baada ya kutekeleza (apply). terraform output -raw web_ip huchapisha thamani tupu kwa ajili ya uingizwaji wa shell, na terraform output -json hukupa kila pato (output) mara moja wakati kuna hosts kadhaa. Iandike hiyo kwenye faili ya inventory, au sakinisha mkusanyiko wa cloud.terraform na uelekeze ansible-inventory -i terraform.yml --graph kwenye saraka ya mradi.

Kwa nini playbook yangu inafeli mara tu baada ya Terraform kumaliza?

Mtoa huduma huripoti seva kama iliyoundwa mara tu API yake inaposema hivyo, wakati mfumo wa uendeshaji bado unawaka (booting), kwa hivyo SSH hukataliwa kwa sekunde za kwanza. Hitilafu hiyo ni UNREACHABLE! pamoja na Connection refused. Fanya ansible.builtin.wait_for_connection kuwa kazi ya kwanza katika play badala ya kukisia muda wa kusubiri, kwa sababu muda wa kuwaka hutofautiana kulingana na image na mpango.