Ansible au Terraform: ipi ya kuchagua kwa seva yako?

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 zinazoendeshwa. 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 wanachokumbuka. 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 utekelezaji. Huunganisha kupitia SSH, huchunguza 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 katika 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 iliyo kwenye host moja na seva iliyo kwenye 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 anaiandikia nyaraka. 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 msimbo wako na faili ya state, ikimalizia na 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 plan husema hivyo kwa # forces replacement karibu na attribute, ikifuatiwa na 1 to add, 0 to change, 1 to destroy. Kutekeleza (apply) plan hiyo hufuta seva na kujenga mpya tupu, jambo ambalo ndilo husababisha watu kupoteza data walizodhani ziko salama.

Kuhifadhi plan kwenye faili na kuitekeleza faili hiyo, badala ya kuendesha terraform apply tupu, 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). Iweke kwenye remote backend mara tu zaidi ya mtu mmoja anapoendesha amri hizo, kwa sababu watu wawili wanaotekeleza (apply) kwa wakati mmoja huzalisha hili:

Error: Error acquiring the state lock

OpenTofu ni fork ya Terraform yenye amri zilezile na umbizo la faili lilelile. Kufikia Julai 2026, kila kitu katika mwongozo huu hufanya kazi ukichapa tofu badala ya terraform.

Kile ambacho Ansible hufanya kwa hakika

Ansible haihitaji agent wala API yoyote. Inafungua muunganisho wa SSH, inanakili moduli ndogo ya Python kwenye lengwa, inaiendesha, kisha inaiifuta. Kila kitu unachoweza kukifikia kupitia 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 za playbook. Matokeo mazuri ni web1 | SUCCESS => {"ping": "pong"}. Uendeshaji wa --check --diff ndio kitu kinachokaribia mpango katika Ansible: inaripoti kile ambacho kingebadilika bila kukibadilisha, ingawa kazi zinazotegemea kazi za awali zinaweza kutoa ripoti isiyo sahihi katika check mode, 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 kuwa njia ya mwisho. Kuna sababu nzuri za kufanya hivyo.

Provisioner huendeshwa tu wakati rasilimali inapoundwa. Ukibadilisha hati (script) hakuna kinachotokea kwenye seva iliyopo, kwa sababu kwa mtazamo wa Terraform rasilimali hiyo tayari inalingana na msimbo (code). Hatua za provisioner hazionekani kamwe kwenye terraform plan, kwa hivyo ukaguzi wako hauonyeshi dalili zozote zake. Ikiwa hati itafeli, Terraform huweka alama ya tainted kwenye rasilimali hiyo, na kitendo kinachofuata cha apply kitaharibu na kuunda upya seva ambayo pengine ilikuwa sawa.

Kufeli huku pia hutokea wakati usiofaa. Mtoa huduma (provider) huripoti seva kama iliyoundwa mara tu API inaposema hivyo, wakati mfumo wa uendeshaji bado unawaka na sshd haijasikiliza (listening) 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 task hiyo kutoka kwenye playbook yako, rasilimali hiyo itaendelea kufanya kazi na kuendelea kutozwa gharama, kwa sababu hakuna kilichorekodi kuwa ilikuwa yako.

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

Uhamisho, umefanikiwa

Uhamisho ni mpaka, siyo muunganisho. Terraform inamaliza kazi, inachapisha anwani, na kusimama. Ansible inaanza kazi kuanzia 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 unalohitaji ndani ya shell substitution. Kwa seva nyingi, 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 state ya Terraform kama inventory ya Ansible

Ikiwa hutaki kuandika faili ya inventory kabisa, mkusanyiko wa cloud.terraform husoma state 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 itafeli. 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 kurekebisha makosa (debug) na hufanya 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, ambayo ndiyo hatua ile ile ambapo kusimamia seva kadhaa za Linux kutoka mashine moja ya udhibiti inakuwa mtiririko halisi wa kazi badala ya mazoea.

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 inaongeza faili ya state ambayo hupaswi kuipoteza.

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

Baki na Ansible pekee wakati seva ni za muda mrefu na ni chache, na wakati swali la kila siku ni "je, mashine hii imesanidiwa kwa usahihi" badala ya "je, mashine hii ipo". Playbook moja inayolinda seva mpya inafanya kazi sawa na dakika kumi za kwanza kwenye VPS mpya, ikiwa na faida kwamba inafanya kazi kwa njia ile ile kwenye seva inayofuata.

Mpangilio wa kujifunza unatokana na hayo. 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 ya kazi hii, iendeshe kama kazi ya kwanza ya play.

Host key imebadilika. Uliharibu na kuunda upya seva, na seva 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 kufanya rebuilds kwenye mashine zenye data.

Sudo inafeli. fatal: [web1]: FAILED! => {"msg": "Missing sudo password"} inamaanisha become: true inahitaji nenosiri kwenye host hiyo. 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 miundombinu halisi imepotoka kutoka kwenye code, kwa kawaida kwa sababu mtu alibadilisha mipangilio kwenye paneli ya wavuti ya provider. Endesha terraform plan -refresh-only ili kuona tofauti hiyo yenyewe, kisha amua kama code au rasilimali iliyo hai ndiyo yenye makosa. Usiwahi kutekeleza (apply) mpango wa uharibifu ambao huwezi kuuelezea mstari kwa mstari.

Ansible inaripoti mabadiliko kila inapoendeshwa. Kazi ya shell isiyo na creates au when huendeshwa bila masharti. Hili si tatizo la kijuujuu 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 huchafua rasilimali ikifeli, jambo linalopanga kufutwa na kuundwa upya kwenye output inayofuata. Terraform haina mfumo sawa na moduli inayokagua kama nginx imesakinishwa tayari na kutofanya chochote 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 kuzitunza, hiyo inatosha. Unachopoteza ni faili ya state na grafu ya utegemezi: ukiondoa task kwenye playbook, rasilimali itaendelea kufanya kazi na kuendelea kutoza gharama, kwa sababu Ansible haijawahi kurekodi kuwa iliiumba. Terraform ingepanga kuifuta.

Ni ipi ninayopaswa kujifunza kwanza?

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

Ninawezaje kupitisha IP ya seva mpya kutoka Terraform kwenda Ansible?

Tangaza output kwenye msimbo wako wa Terraform, kisha isome baada ya apply. terraform output -raw web_ip huchapisha thamani halisi kwa ajili ya shell substitution, na terraform output -json hukupa kila output kwa wakati mmoja ikiwa kuna hosts kadhaa. Iandike hiyo kwenye faili ya inventory, au sakinisha cloud.terraform collection 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 inaposema hivyo, wakati mfumo wa uendeshaji bado unawaka, kwa hivyo SSH hukataliwa kwa sekunde za kwanza. Hitilafu ni UNREACHABLE! pamoja na Connection refused. Fanya ansible.builtin.wait_for_connection iwe task ya kwanza kwenye play badala ya kukisia muda wa kusubiri, kwa sababu muda wa kuwaka hutofautiana kulingana na image na mpango.