Gumagawa ako ng maraming pagsusuri sa Ansible code ng ibang tao at marami akong isinusulat. Sa kurso ng pag-aaral ng mga pagkakamali (kapwa ng ibang tao at sarili ko), pati na rin ang ilang mga panayam, napagtanto ko ang pangunahing pagkakamali na nagagawa ng mga user ng Ansible - napupunta sila sa mga kumplikadong bagay nang hindi pinagkadalubhasaan ang mga pangunahing.

Upang itama ang unibersal na kawalang-katarungang ito, nagpasya akong magsulat ng panimula sa Ansible para sa mga nakakaalam na nito. Binabalaan kita, hindi ito muling pagsasalaysay ng mga tao, ito ay isang mahabang pagbasa na maraming mga titik at walang mga larawan.

Ang inaasahang antas ng mambabasa ay ilang libong linya ng yamla ang naisulat na, mayroon nang ginagawa, ngunit "sa anumang paraan ang lahat ay baluktot."

Mga Pangalan

Ang pangunahing pagkakamali ng isang Ansible na gumagamit ay hindi alam kung ano ang tawag sa isang bagay. Kung hindi mo alam ang mga pangalan, hindi mo maintindihan kung ano ang sinasabi ng dokumentasyon. Isang buhay na halimbawa: sa isang pakikipanayam, ang isang tao na tila nagsabi na marami siyang isinulat sa Ansible ay hindi makasagot sa tanong na "anong mga elemento ang binubuo ng isang playbook?" At nang iminungkahi ko na "inaasahan ang sagot na ang playbook ay binubuo ng paglalaro," sumunod ang nakapipinsalang komento na "hindi namin ginagamit iyon." Nagsusulat ang mga tao ng Ansible para sa pera at hindi gumagamit ng paglalaro. Talagang ginagamit nila ito, ngunit hindi alam kung ano ito.

Kaya magsimula tayo sa isang bagay na simple: ano ang tawag dito? Marahil alam mo ito, o marahil ay hindi mo alam, dahil hindi mo binigyang pansin noong binasa mo ang dokumentasyon.

ansible-playbook ang nagpapatupad ng playbook. Ang playbook ay isang file na may extension na yml/yaml, kung saan mayroong ganito:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Napagtanto na namin na ang buong file na ito ay isang playbook. Maipapakita natin kung nasaan ang mga tungkulin at kung nasaan ang mga gawain. Ngunit nasaan ang paglalaro? At ano ang pagkakaiba ng play at role o playbook?

Lahat ng ito ay nasa dokumentasyon. At nami-miss nila ito. Mga nagsisimula - dahil marami at hindi mo maaalala ang lahat nang sabay-sabay. Nakaranas - dahil "mga bagay na walang kuwenta". Kung may karanasan ka, muling basahin ang mga pahinang ito kahit isang beses bawat anim na buwan, at ang iyong code ay magiging nangungunang klase.

Kaya, tandaan: Ang Playbook ay isang listahan na binubuo ng paglalaro at import_playbook.
Ito ay isang dula:

- hosts: group1
  roles:
    - role1

at ito ay isa pang dula:

- hosts: group2,group3
  tasks:
    - debug:

Ano ang play? Bakit siya?

Ang paglalaro ay isang mahalagang elemento para sa isang playbook, dahil ang paglalaro at paglalaro lamang ay nag-uugnay ng isang listahan ng mga tungkulin at/o mga gawain sa isang listahan ng mga host kung saan sila dapat isagawa. Sa malalim na lalim ng dokumentasyon maaari mong makita ang pagbanggit delegate_to, mga local lookup plugin, network-cli-specific na setting, jump host, atbp. Pinapayagan ka nitong bahagyang baguhin ang lugar kung saan isinasagawa ang mga gawain. Pero, kalimutan mo na. Ang bawat isa sa mga matalinong opsyon na ito ay may napakaspesipikong paggamit, at tiyak na hindi ito pangkalahatan. At pinag-uusapan natin ang mga pangunahing bagay na dapat malaman at gamitin ng lahat.

Kung gusto mong magsagawa ng "isang bagay" "sa isang lugar", sumulat ka ng play. Hindi papel. Hindi isang tungkulin sa mga module at delegado. Kunin mo ito at isulat ang laro. Kung saan, sa field ng mga host ay inilista mo kung saan isasagawa, at sa mga tungkulin/gawain - kung ano ang isasagawa.

Simple lang diba? Paano ito maaaring iba?

Ang isa sa mga katangiang sandali kung kailan ang mga tao ay may pagnanais na gawin ito hindi sa pamamagitan ng paglalaro ay ang "papel na nagtatakda ng lahat." Gusto kong magkaroon ng tungkulin na nagko-configure sa parehong mga server ng unang uri at mga server ng pangalawang uri.

Ang isang archetypal na halimbawa ay ang pagsubaybay. Gusto kong magkaroon ng tungkulin sa pagsubaybay na magko-configure ng pagsubaybay. Ang tungkulin sa pagsubaybay ay itinalaga sa pagsubaybay sa mga host (ayon sa paglalaro). Ngunit lumalabas na para sa pagsubaybay kailangan naming maghatid ng mga pakete sa mga host na aming sinusubaybayan. Bakit hindi gumamit ng delegado? Kailangan mo ring i-configure ang mga iptable. delegado? Kailangan mo ring magsulat/magtama ng config para sa DBMS para mapagana ang pagsubaybay. delegado! At kung kulang ang pagkamalikhain, maaari kang gumawa ng delegasyon include_role sa isang nested loop gamit ang nakakalito na filter sa isang listahan ng mga grupo, at sa loob include_role marami ka pang magagawa delegate_to muli. At umalis na kami...

Ang isang magandang hangarin - na magkaroon ng isang solong tungkulin sa pagsubaybay, na "ginagawa ang lahat" - ay humahantong sa amin sa kumpletong impiyerno kung saan kadalasan ay mayroon lamang isang paraan: upang muling isulat ang lahat mula sa simula.

Saan nangyari ang pagkakamali dito? Sa sandaling natuklasan mo na upang gawin ang gawaing "x" sa host X kailangan mong pumunta sa host Y at gawin ang "y" doon, kailangan mong gumawa ng isang simpleng ehersisyo: pumunta at magsulat ng play, na sa host Y ay y. Huwag magdagdag ng isang bagay sa "x", ngunit isulat ito mula sa simula. Kahit na may mga naka-hardcode na variable.

Tila lahat ng bagay sa mga talata sa itaas ay sinabi nang tama. Ngunit hindi ito ang iyong kaso! Dahil gusto mong magsulat ng reusable code na DRY at parang library, at kailangan mong maghanap ng paraan kung paano ito gagawin.

Dito nakatago ang isa pang seryosong pagkakamali. Isang error na naging isang kumpletong kakila-kilabot na kahit na ang may-akda ay hindi maisip ang isang error na ginawa ang maraming mga proyekto mula sa mapagpasensya na nakasulat (maaaring mas mahusay ito, ngunit lahat ay gumagana at madaling tapusin. Ito ay gumagana, ngunit ipinagbabawal ng Diyos na baguhin mo ang anuman.

Ang error ay: ang tungkulin ay isang function ng library. Ang pagkakatulad na ito ay sumira ng napakaraming magagandang simula kaya't nakakalungkot lamang panoorin. Ang tungkulin ay hindi isang function ng library. Hindi siya makakagawa ng mga kalkulasyon at hindi siya makakagawa ng mga desisyon sa antas ng paglalaro. Paalalahanan ako kung anong mga desisyon ang ginagawa ng paglalaro?

Salamat, tama ka. Gumagawa ng desisyon ang Play (mas tiyak, naglalaman ito ng impormasyon) tungkol sa kung aling mga gawain at tungkulin ang gagawin sa kung aling mga host.

Kung italaga mo ang desisyong ito sa isang tungkulin, at kahit na may mga kalkulasyon, ipahamak mo ang iyong sarili (at ang isa na susubukan na i-parse ang iyong code) sa isang miserableng pag-iral. Ang tungkulin ay hindi nagpapasya kung saan ito ginagampanan. Ang desisyong ito ay ginawa sa pamamagitan ng paglalaro. Ginagawa ng papel kung ano ang sinabi nito, kung saan ito sinabi.

Bakit mapanganib ang programa sa Ansible at kung bakit mas mahusay ang COBOL kaysa sa Ansible, pag-uusapan natin sa kabanata ang tungkol sa mga variable at jinja. Sa ngayon, sabihin natin ang isang bagay - ang bawat isa sa iyong mga kalkulasyon ay nag-iiwan ng isang hindi maalis na bakas ng mga pagbabago sa mga pandaigdigang variable, at wala kang magagawa tungkol dito. Sa sandaling nagsalubong ang dalawang "bakas", nawala ang lahat.

Tandaan para sa makulit: ang papel ay tiyak na makakaimpluwensya sa daloy ng kontrol. Kumain delegate_to at ito ay may mga makatwirang gamit. Kumain meta: end host/play. Ngunit! Tandaan na itinuturo namin ang mga pangunahing kaalaman? Nakalimutan na delegate_to. Pinag-uusapan natin ang pinakasimple at pinakamagandang Ansible code. Alin ang madaling basahin, madaling isulat, madaling i-debug, madaling subukan at madaling kumpletuhin. Kaya, muli:

play and only play ang magpapasya kung aling mga host ang ipapatupad.

Sa seksyong ito, hinarap namin ang pagsalungat sa pagitan ng paglalaro at papel. Ngayon pag-usapan natin ang mga gawain kumpara sa relasyon sa tungkulin.

Mga Gawain at Tungkulin

Isaalang-alang ang paglalaro:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

Sabihin nating kailangan mong gawin ang foo. At parang foo: name=foobar state=present. Saan ko dapat isulat ito? sa pre? post? Gumawa ng papel?

...At saan napunta ang mga gawain?

Nagsisimula kaming muli sa mga pangunahing kaalaman - ang play device. Kung lumutang ka sa isyung ito, hindi mo magagamit ang paglalaro bilang batayan para sa lahat ng iba pa, at magiging "shaky" ang iyong resulta.

Play device: nagho-host ng direktiba, mga setting para sa paglalaro mismo at mga seksyong pre_tasks, tasks, roles, post_tasks. Ang natitirang mga parameter para sa paglalaro ay hindi mahalaga sa amin ngayon.

Ang pagkakasunud-sunod ng kanilang mga seksyon na may mga gawain at tungkulin: pre_tasks, roles, tasks, post_tasks. Dahil semantically ang pagkakasunud-sunod ng pagpapatupad ay nasa pagitan tasks и roles ay hindi malinaw, pagkatapos ay sinasabi ng pinakamahuhusay na kagawian na nagdaragdag kami ng isang seksyon tasks, kung hindi lang roles... Kung meron roles, pagkatapos ang lahat ng mga nakalakip na gawain ay inilalagay sa mga seksyon pre_tasks/post_tasks.

Ang natitira na lang ay ang lahat ay malinaw sa semantiko: una pre_tasks, pagkatapos roles, pagkatapos post_tasks.

Ngunit hindi pa rin namin sinasagot ang tanong: nasaan ang module call? foo magsulat? Kailangan ba nating magsulat ng isang buong tungkulin para sa bawat modyul? O mas mabuting magkaroon ng makapal na papel para sa lahat? At kung hindi isang papel, kung gayon saan ako dapat sumulat - sa pre o post?

Kung walang makatwirang sagot sa mga tanong na ito, kung gayon ito ay isang tanda ng kakulangan ng intuwisyon, iyon ay, ang parehong "mga nanginginig na pundasyon." Alamin natin ito. Una, isang katanungang panseguridad: Kung mayroon ang paglalaro pre_tasks и post_tasks (at walang mga gawain o tungkulin), pagkatapos ay maaaring masira ang isang bagay kung gagawin ko ang unang gawain mula sa post_tasks Ililipat ko ito hanggang dulo pre_tasks?

Siyempre, ang mga salita ng tanong ay nagpapahiwatig na ito ay masira. Ngunit ano nga ba?

... Mga Handler. Ang pagbabasa ng mga pangunahing kaalaman ay nagpapakita ng isang mahalagang katotohanan: lahat ng mga humahawak ay awtomatikong namumula pagkatapos ng bawat seksyon. Yung. lahat ng gawain mula sa pre_tasks, pagkatapos lahat ng mga handler na naabisuhan. Pagkatapos ang lahat ng mga tungkulin at lahat ng mga handler na naabisuhan sa mga tungkulin ay isinasagawa. Pagkatapos post_tasks at ang kanilang mga humahawak.

Kaya, kung i-drag mo ang isang gawain mula sa post_tasks в pre_tasks, pagkatapos ay potensyal na isasagawa mo ito bago isagawa ang handler. halimbawa, kung sa pre_tasks ang web server ay naka-install at na-configure, at post_tasks may ipinadala dito, pagkatapos ay ilipat ang gawaing ito sa seksyon pre_tasks ay hahantong sa katotohanan na sa oras ng "pagpapadala" ang server ay hindi pa tatakbo at lahat ay masisira.

Ngayon isipin natin muli, bakit kailangan natin pre_tasks и post_tasks? Halimbawa, upang makumpleto ang lahat ng kailangan (kabilang ang mga humahawak) bago gampanan ang tungkulin. A post_tasks ay magbibigay-daan sa amin na magtrabaho kasama ang mga resulta ng pagpapatupad ng mga tungkulin (kabilang ang mga humahawak).

Sasabihin sa amin ng isang matalinong eksperto sa Ansible kung ano ito. meta: flush_handlers, ngunit bakit kailangan natin ng mga flush_handler kung maaari tayong umasa sa pagkakasunud-sunod ng pagpapatupad ng mga seksyon sa paglalaro? Bukod dito, ang paggamit ng meta: flush_handlers ay maaaring magbigay sa amin ng mga hindi inaasahang bagay na may mga duplicate na humahawak, na nagbibigay sa amin ng kakaibang babala kapag ginamit. when у block atbp. Ang mas mahusay na alam mo ang ansible, mas maraming mga nuances ang maaari mong pangalanan para sa isang "mapanlinlang" na solusyon. At ang isang simpleng solusyon - gamit ang isang natural na dibisyon sa pagitan ng pre/role/post - ay hindi nagiging sanhi ng mga nuances.

At, bumalik sa aming 'foo'. Saan ko ito ilalagay? Sa pre, post o roles? Malinaw, depende ito sa kung kailangan natin ang mga resulta ng handler para sa foo. Kung wala sila, hindi kailangang ilagay ang foo sa alinman sa pre o post - ang mga seksyong ito ay may espesyal na kahulugan - pagsasagawa ng mga gawain bago at pagkatapos ng pangunahing katawan ng code.

Ngayon ang sagot sa tanong na "papel o gawain" ay bumababa sa kung ano ang nasa laro - kung may mga gawain doon, kailangan mong idagdag ang mga ito sa mga gawain. Kung may mga tungkulin, kailangan mong lumikha ng isang tungkulin (kahit na mula sa isang gawain). Hayaan mong ipaalala ko sa iyo na ang mga gawain at tungkulin ay hindi ginagamit sa parehong oras.

Ang pag-unawa sa mga pangunahing kaalaman ng Ansible ay nagbibigay ng mga makatwirang sagot sa mga tila tanong ng panlasa.

Mga gawain at tungkulin (ikalawang bahagi)

Ngayon talakayin natin ang sitwasyon kung kailan nagsisimula ka pa lamang magsulat ng playbook. Kailangan mong gumawa ng foo, bar at baz. Ang tatlong gawain ba ito, isang tungkulin o tatlong tungkulin? Upang ibuod ang tanong: sa anong punto ka dapat magsimulang magsulat ng mga tungkulin? Ano ang silbi ng pagsulat ng mga tungkulin kung maaari kang sumulat ng mga gawain?... Ano ang tungkulin?

Isa sa mga pinakamalaking pagkakamali (napag-usapan ko na ito) ay ang isipin na ang isang tungkulin ay parang isang function sa library ng isang programa. Ano ang hitsura ng isang pangkalahatang paglalarawan ng function? Tumatanggap ito ng mga input argument, nakikipag-ugnayan sa mga side cause, gumagawa ng side effect, at nagbabalik ng value.

Ngayon, pansin. Ano ang maaaring gawin mula dito sa papel? Palagi kang malugod na tumawag sa mga side effect, ito ang kakanyahan ng buong Ansible - upang lumikha ng mga side effect. May side cause? elementarya. Ngunit sa "ipasa ang isang halaga at ibalik ito" - kung saan hindi ito gumagana. Una, hindi ka maaaring magpasa ng halaga sa isang tungkulin. Maaari kang magtakda ng pandaigdigang variable na may habambuhay na laki ng paglalaro sa seksyong vars para sa tungkulin. Maaari kang magtakda ng pandaigdigang variable na may panghabambuhay na paglalaro sa loob ng tungkulin. O kahit na sa buhay ng mga playbook (set_fact/register). Ngunit hindi ka maaaring magkaroon ng "mga lokal na variable". Hindi mo maaaring "kumuha ng isang halaga" at "ibalik ito."

Ang pangunahing bagay ay sumusunod mula dito: hindi ka maaaring magsulat ng isang bagay sa Ansible nang hindi nagiging sanhi ng mga side effect. Ang pagpapalit ng mga pandaigdigang variable ay palaging isang side effect para sa isang function. Sa Rust, halimbawa, ang pagbabago ng isang global variable ay unsafe. At sa Ansible ito ang tanging paraan upang maimpluwensyahan ang mga halaga para sa isang tungkulin. Tandaan ang mga salitang ginamit: hindi "ipasa ang isang halaga sa tungkulin", ngunit "baguhin ang mga halaga na ginagamit ng tungkulin". Walang paghihiwalay sa pagitan ng mga tungkulin. Walang paghihiwalay sa pagitan ng mga gawain at tungkulin.

Kabuuan: ang isang tungkulin ay hindi isang tungkulin.

Ano ang maganda sa role? Una, ang papel ay may mga default na halaga (/default/main.yaml), pangalawa, ang papel ay may karagdagang mga direktoryo para sa pag-iimbak ng mga file.

Ano ang mga pakinabang ng mga default na halaga? Dahil sa pyramid ni Maslow, ang medyo baluktot na talahanayan ng mga variable na priyoridad ng Ansible, ang mga default ng tungkulin ay ang pinakamababang priyoridad (minus Ansible command line parameter). Nangangahulugan ito na kung kailangan mong magbigay ng mga default na halaga at huwag mag-alala tungkol sa pag-override ng mga ito sa mga halaga mula sa imbentaryo o mga variable ng pangkat, kung gayon ang mga default ng tungkulin ay ang tanging tamang lugar para sa iyo. (Medyo nagsisinungaling ako - marami pa |d(your_default_here), ngunit kung pag-uusapan natin ang tungkol sa mga nakatigil na lugar, ang mga default na tungkulin lamang).

Ano pa ang maganda sa mga roles? Dahil mayroon silang sariling mga katalogo. Ito ay mga direktoryo para sa mga variable, parehong pare-pareho (i.e. kinakalkula para sa papel) at dynamic (mayroong alinman sa isang pattern o isang anti-pattern - include_vars may {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Ito ang mga direktoryo para sa files/, templates/. Gayundin, pinapayagan ka nitong magkaroon ng sarili mong mga module at plugin (library/). Ngunit, kung ihahambing sa mga gawain sa isang playbook (na maaari ding magkaroon ng lahat ng ito), ang tanging pakinabang dito ay ang mga file ay hindi itinatapon sa isang tumpok, ngunit ilang magkakahiwalay na mga tambak.

Isa pang detalye: maaari mong subukang gumawa ng mga tungkulin na magagamit muli (sa pamamagitan ng galaxy). Sa pagdating ng mga koleksyon, ang pamamahagi ng papel ay maaaring ituring na halos nakalimutan.

Kaya, ang mga tungkulin ay may dalawang mahalagang tampok: mayroon silang mga default (isang natatanging tampok) at pinapayagan ka nitong buuin ang iyong code.

Pagbabalik sa orihinal na tanong: kailan gagawa ng mga gawain at kailan gagawa ng mga tungkulin? Ang mga gawain sa isang playbook ay kadalasang ginagamit bilang "glue" bago/pagkatapos ng mga tungkulin, o bilang isang independiyenteng elemento ng gusali (kung gayon ay walang mga tungkulin sa code). Ang isang tumpok ng mga normal na gawain na may halong mga tungkulin ay hindi malabo na sloppiness. Dapat kang sumunod sa isang partikular na istilo - alinman sa isang gawain o isang tungkulin. Nagbibigay ang mga tungkulin ng paghihiwalay ng mga entity at mga default, nagbibigay-daan sa iyo ang mga gawain na magbasa ng code nang mas mabilis. Karaniwan, mas maraming "nakatigil" (mahalaga at kumplikado) na code ang inilalagay sa mga tungkulin, at ang mga pantulong na script ay isinusulat sa istilo ng gawain.

Posibleng gawin ang import_role bilang isang gawain, ngunit kung isusulat mo ito, pagkatapos ay maging handa na ipaliwanag sa sarili mong pakiramdam ng kagandahan kung bakit mo gustong gawin ito.

Maaaring sabihin ng isang matalinong mambabasa na ang mga tungkulin ay maaaring mag-import ng mga tungkulin, ang mga tungkulin ay maaaring magkaroon ng mga dependency sa pamamagitan ng galaxy.yml, at mayroon ding isang kakila-kilabot at kakila-kilabot include_role — Ipinaaalala ko sa iyo na pinahuhusay namin ang mga kasanayan sa pangunahing Ansible, at hindi sa figure gymnastics.

Mga handler at mga gawain

Talakayin natin ang isa pang malinaw na bagay: mga humahawak. Ang pag-alam kung paano gamitin ang mga ito nang tama ay halos isang sining. Ano ang pagkakaiba ng handler at drag?

Dahil naaalala natin ang mga pangunahing kaalaman, narito ang isang halimbawa:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

Ang mga humahawak ng tungkulin ay matatagpuan sa rolename/handlers/main.yaml. Naghahalungkat ang mga humahawak sa lahat ng kalahok sa paglalaro: ang mga pre/post_tasks ay maaaring humila ng mga humahawak ng tungkulin, at ang isang tungkulin ay maaaring humila ng mga humahawak mula sa paglalaro. Gayunpaman, ang "cross-role" na mga tawag sa mga humahawak ay nagdudulot ng higit na wtf kaysa sa pag-uulit ng isang maliit na handler. (Ang isa pang elemento ng pinakamahuhusay na kagawian ay ang subukang huwag ulitin ang mga pangalan ng handler).

Ang pangunahing pagkakaiba ay ang gawain ay palaging isinasagawa (idempotently) (plus/minus tag at when), at ang handler - ayon sa pagbabago ng estado (abisuhan lamang ang mga sunog kung ito ay nabago). Ano ang ibig sabihin nito? Halimbawa, ang katotohanan na kapag nag-restart ka, kung walang nagbago, pagkatapos ay walang handler. Bakit kaya kailangan nating magsagawa ng handler kung walang pagbabago sa pagbuo ng gawain? Halimbawa, dahil may nasira at nagbago, ngunit ang pagpapatupad ay hindi umabot sa handler. Halimbawa, dahil pansamantalang down ang network. Ang config ay nagbago, ang serbisyo ay hindi na-restart. Sa susunod na simulan mo ito, hindi na magbabago ang config, at mananatili ang serbisyo sa lumang bersyon ng config.

Ang sitwasyon sa config ay hindi malulutas (mas tiyak, maaari kang mag-imbento ng isang espesyal na restart protocol para sa iyong sarili na may mga flag ng file, atbp., ngunit hindi na ito 'basic ansible' sa anumang anyo). Ngunit may isa pang karaniwang kuwento: na-install namin ang application, naitala ito .service-file, at ngayon gusto namin ito daemon_reload и state=started. At ang natural na lugar para dito ay tila ang handler. Ngunit kung gagawin mo itong hindi isang handler ngunit isang gawain sa dulo ng isang tasklist o tungkulin, kung gayon ito ay isasagawa nang walang kakayahan sa bawat oras. Kahit nabasag ang playbook sa gitna. Hindi nito malulutas ang na-restart na problema sa lahat (hindi ka makakagawa ng isang gawain na may na-restart na katangian, dahil ang idempotency ay nawala), ngunit ito ay talagang nagkakahalaga ng paggawa ng state=started, ang pangkalahatang katatagan ng mga playbook ay tumataas, dahil bumababa ang bilang ng mga koneksyon at dynamic na estado.

Ang isa pang positibong pag-aari ng handler ay hindi nito barado ang output. Walang mga pagbabago - walang dagdag na nilaktawan o ok sa output - mas madaling basahin. Isa rin itong negatibong pag-aari - kung makakita ka ng typo sa isang linearly na naisakatuparan na gawain sa pinakaunang pagtakbo, ang mga humahawak ay isasagawa lamang kapag binago, i.e. sa ilalim ng ilang mga kundisyon - napakabihirang. Halimbawa, sa unang pagkakataon sa aking buhay makalipas ang limang taon. At, siyempre, magkakaroon ng typo sa pangalan at lahat ay masisira. At kung hindi mo patakbuhin ang mga ito sa pangalawang pagkakataon, walang pagbabago.

Hiwalay, kailangan nating pag-usapan ang pagkakaroon ng mga variable. Halimbawa, kung aabisuhan mo ang isang gawain na may loop, ano ang magiging sa mga variable? Maaari mong hulaan ang analytically, ngunit hindi ito palaging mahalaga, lalo na kung ang mga variable ay nagmumula sa iba't ibang lugar.

... Kaya ang mga humahawak ay hindi gaanong kapaki-pakinabang at mas may problema kaysa sa kanilang nakikita. Kung maaari kang magsulat ng isang bagay na maganda (nang walang mga frills) nang walang mga humahawak, mas mahusay na gawin ito nang wala sila. Kung hindi ito gumana nang maganda, mas mabuti sa kanila.

Ang kinakaing unti-unti na mambabasa ay wastong itinuro na hindi natin napag-usapan listenna maaaring tumawag ang isang handler ng notify para sa isa pang handler, na ang isang handler ay maaaring magsama ng import_tasks (na maaaring magsama ng_role with with_items), na ang handler system sa Ansible ay Turing-complete, na ang mga handler mula sa include_role ay nagsalubong sa isang kakaibang paraan sa mga handler mula sa paglalaro, atbp. .d. - lahat ng ito ay malinaw na hindi ang "mga pangunahing kaalaman").

Bagaman mayroong isang tiyak na WTF na talagang isang tampok na kailangan mong tandaan. Kung ang iyong gawain ay naisakatuparan sa delegate_to at ito ay nag-abiso, pagkatapos ay ang kaukulang handler ay isinasagawa nang wala delegate_to, ibig sabihin. sa host kung saan nakatalaga ang laro. (Kahit na ang handler, siyempre, ay maaaring mayroon delegate_to Pareho).

Hiwalay, gusto kong magsabi ng ilang salita tungkol sa mga reusable na tungkulin. Bago lumitaw ang mga koleksyon, may ideya na maaari kang gumawa ng mga pangkalahatang tungkulin na maaaring maging ansible-galaxy install at nagpunta. Gumagana sa lahat ng OS ng lahat ng variant sa lahat ng sitwasyon. Kaya, ang aking opinyon: hindi ito gumagana. Anumang papel na may masa include_vars, na sumusuporta sa 100500 mga kaso, ay tiyak na mapapahamak sa kailaliman ng mga sulok na mga bug sa kaso. Maaaring saklawin ang mga ito ng napakalaking pagsubok, ngunit tulad ng anumang pagsubok, mayroon kang Cartesian na produkto ng mga halaga ng input at isang kabuuang function, o mayroon kang "mga indibidwal na senaryo na sakop." Ang aking opinyon ay mas mabuti kung ang papel ay linear (cyclomatic complexity 1).

Ang mas kaunting mga ifs (hayag o paturol - sa form when o anyo include_vars sa pamamagitan ng hanay ng mga variable), mas mahusay ang papel. Minsan kailangan mong gumawa ng mga sanga, ngunit, inuulit ko, mas kakaunti ang mayroon, mas mabuti. Kaya tila isang magandang papel sa kalawakan (ito gumagana!) na may isang grupo ng when maaaring hindi gaanong kanais-nais kaysa sa "sariling tungkulin" mula sa limang gawain. Ang sandali kung kailan mas maganda ang papel sa galaxy ay kapag nagsimula kang magsulat ng isang bagay. Ang sandali kung kailan ito lumalala ay kapag may nasira at may hinala ka na ito ay dahil sa "role with galaxy". Binuksan mo ito, at mayroong limang inklusyon, walong task sheet at isang stack when'ov... At kailangan nating malaman ito. Sa halip na 5 gawain, isang linear na listahan kung saan walang masisira.

Sa mga sumusunod na bahagi

• Kaunti tungkol sa imbentaryo, mga variable ng pangkat, host_group_vars plugin, hostvars. Paano itali ang isang Gordian knot na may spaghetti. Saklaw at nauuna na mga variable, Ansible memory model. "Kaya saan namin iniimbak ang username para sa database?"
• jinja: {{ jinja }} — nosql notype nosense soft plasticine. Ito ay kahit saan, kahit na kung saan hindi mo ito inaasahan. Medyo tungkol sa !!unsafe at masarap yaml.

Pinagmulan: www.habr.com