{"id":87084,"date":"2020-07-03T13:42:34","date_gmt":"2020-07-03T11:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron"},"modified":"2020-07-03T13:42:34","modified_gmt":"2020-07-03T11:42:34","slug":"osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/osnovy-ansible-bez-kotoryh-vashi-plejbuki-komok-slipshihsya-makaron","title":{"rendered":"Ansible'i alusp\u00f5him\u00f5tted, ilma milleta on teie m\u00e4nguplaanid nagu \u00fchte klombist pastat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ma teen palju \u00fclevaateid teiste Ansible'i koodidest ja kirjutan ise ka palju. Veateavet anal\u00fc\u00fcsides (nii oma kui ka teiste omi) ja m\u00f5nedel vestlustel olen aru saanud, et Ansible'i kasutajad teevad \u00fche peamise vea \u2014 nad sukeldusid keeruliseks, ilma p\u00f5hit\u00f5desid omandamata.<\/p>\n

<\/p>\n

Selle universaalse eba\u00f5igluse parandamiseks otsustasin kirjutada Ansible'i sissejuhatuse neile, kes seda juba tunnevad. Hoian ette, et see ei ole manuaalide kokkuv\u00f5te, vaid mahukas artikkel, kus on palju s\u00f5nu ja ei ole pilte.<\/p>\n

<\/p>\n

Oodatav lugemise tase \u2014 olete kirjutanud juba paar tuhat YAML-rida, midagi on juba tootmises, aga \"mingil moel on k\u00f5ik vildakas\".<\/p>\n

<\/a><\/noindex><\/p>\n

Pealkirjad<\/h1>\n

<\/p>\n

Peamine viga Ansible'i kasutaja juures on see, et ta ei tea, kuidas asju nimetatakse. Kui te ei tea nimede t\u00e4hendust, ei suuda te m\u00f5ista, mis dokumentatsioonis on kirjas. Elu n\u00e4ide: t\u00f6\u00f6intervjuul ei suutnud inimene, kes n\u00e4iliselt v\u00e4itis, et ta on palju Ansible'iga t\u00f6\u00f6tanud, vastata k\u00fcsimusele \"millistest elementidest koosneb playbook?\". Ja kui ma vihjasin, et \"oodati vastust, et playbook koosneb play'ist\", j\u00e4rgnes p\u00f5hjalik kommentaar \"me ei kasuta seda\". Inimesed kirjutavad Ansible'is raha eest ja ei kasuta play'd. Tegelikult kasutatakse, aga ei teata, mis see on.<\/em><\/p>\n

<\/p>\n

Alustame seega lihtsast: kuidas asju nimetatakse. V\u00f5ib-olla teate seda, aga v\u00f5ib-olla ei tea, sest ei pannud t\u00e4hele, kui lugesite dokumentatsiooni.<\/p>\n

<\/p>\n

ansible-playbook t\u00e4idab playbooki. Playbook on fail laiendiga yml\/yaml, mille sees on midagi sellist:<\/p>\n

<\/p>\n

---\n- hosts: group1\n  roles:\n    - role1\n\n- hosts: group2,group3\n  tasks:\n    - debug:<\/code><\/pre>\n
<\/p>\n
Me oleme juba aru saanud, et kogu see fail on playbook. Saame n\u00e4idata, kus on rolled (roles), kus on \u00fclesanded (tasks). Aga kus on play? Ja kuidas erineb play rollist v\u00f5i playbookist?<\/p>\n
<\/p>\n
Dokumentatsioonis on k\u00f5ik olemas. Ja seda j\u00e4etakse t\u00e4helepanuta. Algajad - sest seal on liiga palju ja pole v\u00f5imalik k\u00f5ike korraga meeles pidada. Kogenud - sest \"triviaalne kraam\". Kui olete kogenud, siis loe neid lehti v\u00e4hemalt kord poolaastas, ja teie kood muutub klassi v\u00f5rra paremaks.<\/p>\n
<\/p>\n
Nii et pidage meeles: Playbook on nimekiri, mis koosneb m\u00e4ngudest ja import_playbook<\/code>.
\nSee on \u00fcks m\u00e4ng:<\/p>\n
<\/p>\n
- hosts: group1\n  roles:\n    - role1<\/code><\/pre>\n
<\/p>\n
ja see on ka veel \u00fcks m\u00e4ng:<\/p>\n
<\/p>\n
- hosts: group2,group3\n  tasks:\n    - debug:<\/code><\/pre>\n
<\/p>\n
Mis siis on m\u00e4ng? Miks see on vajalik?<\/p>\n
<\/p>\n
M\u00e4ng on playbooki v\u00f5tmeelement, kuna m\u00e4ng ja ainult m\u00e4ng seob rollide ja\/v\u00f5i \u00fclesannete nimekirja hostide nimekirjaga, millel neid teha tuleb. Dokumentatsiooni s\u00fcgavas nurgas v\u00f5ib leida mainimisi delegate_to<\/code>, kohalike lookup-pluginide, v\u00f5rgukliendi-spetsiifiliste seadistuste, h\u00fcppamis-hostide jne. kohta. Need v\u00f5imaldavad \u00fclesannete t\u00e4itmise kohta natuke muuta. Kuid unustage see. Igal neist keerulistest valikutest on v\u00e4ga spetsiifilised rakendused, ja need ei ole universaalsed. R\u00e4\u00e4gime p\u00f5hilistest asjadest, mida peaksid teadma ja kasutama k\u00f5ik.<\/p>\n
<\/p>\n
Kui soovite \"midagi\" t\u00e4ita \"kusagil\" \u2014 kirjutate play. Mitte roll. Mitte roll koos moodulite ja delegaatidega. Te v\u00f5tate ja kirjutate play. Milles, v\u00e4ljale hosts, loetlete, kus t\u00e4itmine toimub, ja roles\/tasks, mida t\u00e4ita.<\/p>\n
<\/p>\n
Lihtne, eks? Kuidas saab olla teisiti?<\/p>\n
<\/p>\n
\u00dcks selge m\u00e4rk, mis paneb inimesi otsustama mitte kasutada play'd, on \"roll, mis k\u00f5ike seadistab\". Soovid, et sul oleks roll, mis seadistab ja serverile<\/a> esimese t\u00fc\u00fcbi ja teise t\u00fc\u00fcbi serverid.<\/p>\n
<\/p>\n
Arhet\u00fc\u00fcpne n\u00e4ide on monitooring. Tahaks, et oleks roll monitoring, mis seadistab monitooringu. Rolli monitoring m\u00e4\u00e4ratakse monitooringu hostidele (vastavas play's). Kuid selgub, et monitooringu jaoks tuleb installida paketid hostidele, mida me monitoorime. Miks mitte kasutada delegaati? Ja veel peab seadistama iptables. Delegaati? Ja veel peab kirjutama\/korrigeerima andmebaasi konfiguratsiooni, et monitooring saaks t\u00f6\u00f6tada. Delegaati! Ja kui loominguline m\u00f5te hakkab voolama, v\u00f5ib teha delegatsiooni include_role<\/code> sisemise ts\u00fckli kaudu keerulise filtri kaudu grupi nimekirja peale, ja sees include_role<\/code> v\u00f5ib veel teha delegate_to<\/code> uuesti. Ja l\u00e4ks lahti...<\/p>\n
<\/p>\n
Hea soov on omada \u00fchte ainukest monitoring rolli, mis \"k\u00f5ike teeb\" \u2014 viib meid olukorda, millest enamikul juhtudel on ainus v\u00e4ljap\u00e4\u00e4s: k\u00f5ik kirjutada nullist \u00fcmber.<\/p>\n
<\/p>\n
Kus see viga juhtus? Siis, kui sa avastasid, et \u00fclesande \"x\" t\u00e4itmiseks hostil X pead minema hostile Y ja seal tegema \"y\", oleksid pidanud tegema lihtsa harjutuse: minna ja kirjutada play, mis hostil Y teeb y. Mitte midagi \"x\"-sse lisada, vaid kirjutada nullist. Olgu isegi k\u00f5vakonfigureeritud muutujatega.<\/p>\n
<\/p>\n
Tundub, et eelnevatel l\u00f5ikudest on k\u00f5ik \u00f5igesti \u00f6eldud. Aga see ei ole teie juhtum! Sest te soovite kirjutada taaskasutatavat koodi, mis on DRY ja sarnaneb raamatukogule, ning tuleb leida meetod, kuidas seda teha.<\/p>\n
<\/p>\n
Siin peidus on veel \u00fcks t\u00f5sine viga. Viga, mis muutis mitmed projektid talutavalt kirjutatutest (v\u00f5ib teha paremini, aga k\u00f5ik t\u00f6\u00f6tab ja on lihtne juurde kirjutada) t\u00e4ielikuks \u00f5uduseks, milles isegi autor ei suuda orienteeruda. See t\u00f6\u00f6tab, aga jumal hoidku kui midagi muuta.<\/p>\n
<\/p>\n
See viga k\u00f5lab nii: roll on raamatukogufunktsioon. See analoogia on p\u00f6\u00f6ranud nii palju h\u00e4id algatusi, et on lihtsalt kurb vaadata. Roll ei ole raamatukogufunktsioon. Ta ei saa teha arvutusi ja ei saa teha otsuseid tasemel play. Tuletage mulle meelde, milliseid otsuseid play teeb?<\/p>\n
<\/p>\n
Ait\u00e4h, te olete \u00f5ige. Play teeb otsuse (t\u00e4psemalt, sisaldab teavet) selle kohta, milliseid \u00fclesandeid ja rolle millistel hostidel t\u00e4ita.<\/p>\n
<\/p>\n
Kui m\u00e4\u00e4rate selle otsuse rollile, veel koos arvutuste tegemisega, siis m\u00e4\u00e4rate endale (ja sellele, kes teie koodi p\u00fc\u00fcab lahti harutada) vaese eksistentsi. Roll ei otsusta, kus ta t\u00e4idetakse. Selle otsuse teeb play. Roll teeb seda, mida talle \u00f6eldi, seal, kus talle \u00f6eldi.<\/p>\n
<\/p>\n
Miks on Ansible'i programmeerimisega tegelemine ohtlik ja miks on COBOL parem kui Ansible, arutame peat\u00fckis muutujate ja jinja kohta. Praegu \u00fctleme ainult, et iga sinu arvutus j\u00e4tab maha kustutamatu j\u00e4lje globaalsete muutujate muutmisest, ja sa ei saa sellega midagi ette v\u00f5tta. Niikaua kui kaks \"jalaj\u00e4lge\" on kattunud \u2014 on k\u00f5ik kadunud.<\/p>\n
<\/p>\n
T\u00e4helepanek t\u00e4psetele: roll v\u00f5ib m\u00f5jutada control flow'd. delegate_to<\/code> ja on m\u00f5istlikud rakendused. On meta: l\u00f5pp host\/play<\/code>. Kuid! Kas m\u00e4letate, et \u00f5pime aluseid? Unustasite delegate_to<\/code>. R\u00e4\u00e4gime k\u00f5ige lihtsamast ja k\u00f5ige ilusamast koodist Ansible'is. Mis on lihtne lugeda, lihtne kirjutada, lihtne debugeerida, lihtne testida ja lihtne t\u00e4iendada. Niisiis, veel kord:<\/p>\n
<\/p>\n
play ja ainult play otsustab, millistel hostidel midagi t\u00e4idetakse.<\/strong><\/p>\n
<\/p>\n
Selles jaos oleme arutanud play ja rolli vastandlikkust. N\u00fc\u00fcd r\u00e4\u00e4gime \u00fclesannete (tasks) ja rollide (role) suhetest.<\/p>\n
<\/p>\n
\u00dclesanded ja rollid<\/h1>\n
<\/p>\n
Vaadakem play'd:<\/p>\n
<\/p>\n
- hosts: somegroup\n  pre_tasks:\n    - some_tasks1:\n  roles:\n     - role1\n     - role2\n  post_tasks:\n     - some_task2:\n     - some_task3:<\/code><\/pre>\n
<\/p>\n
Oletame, et peate tegema foo. Ja see n\u00e4eb v\u00e4lja nagu foo: name=foobar state=present<\/code>. Kuhu see kirjutada? pre? post? Luua roll?<\/p>\n
<\/p>\n
\u2026 Ja kuhu j\u00e4id \u00fclesanded?<\/p>\n
<\/p>\n
Alustame taas algusest \u2014 play seadistamisest. Kui te ei tea, kuidas play kasutada, ei saa see olla teie \u00fclej\u00e4\u00e4nud t\u00f6\u00f6 alus ja teie tulemus on \"ebakindel\".<\/p>\n
<\/p>\n
Play struktuur: direktiiv hosts, play seadistused ja sektsioonid pre_tasks, tasks, roles, post_tasks. \u00dclej\u00e4\u00e4nud parameetrid play jaoks ei ole meile praegu olulised.<\/p>\n
<\/p>\n
Nende sektsioonide j\u00e4rjestus \u00fclesannete ja rollide osas: pre_tasks<\/code>, roles<\/code>, tasks<\/code>, post_tasks<\/code>. Kuna semantiliselt on t\u00e4itmise j\u00e4rjekord nende vahel tasks<\/code> ja roles<\/code> ei ole selge, siis parim tava \u00fctleb, et lisame sektsiooni tasks<\/code>, ainult kui pole roles<\/code>. Kui on olemas roles<\/code>, siis k\u00f5ik seotud \u00fclesanded paigutatakse sektsiooni pre_tasks<\/code>\/post_tasks<\/code>.<\/p>\n
<\/p>\n
J\u00e4\u00e4b vaid see, mis on semantiliselt arusaadav: k\u00f5igepealt pre_tasks<\/code>, seej\u00e4rel roles<\/code>, seej\u00e4rel post_tasks<\/code>.<\/p>\n
<\/p>\n
Aga me ei ole endiselt vastanud k\u00fcsimusele: kuhu kirjutada mudeli foo<\/code> kasutamine? Kas peame iga mudeli jaoks kirjutama terve rolli? V\u00f5i on parem omada \u00fcht suurt rolli k\u00f5igeks? Kui mitte roll, siis kuhu kirjutada \u2013 pre v\u00f5i post?<\/p>\n
<\/p>\n
Kui nendele k\u00fcsimustele ei ole argumenteeritud vastust, siis see viitab intuitsiooni puudumisele, see t\u00e4hendab, et need on need \"ebakindlad alused\". Alustame uurimist. Esmalt kontrollk\u00fcsimus: Kui playl on pre_tasks<\/code> ja post_tasks<\/code> (ja ei ole ei \u00fclesandeid ega rolle), kas midagi v\u00f5ib katki minna, kui ma viin esimese \u00fclesande post_tasks<\/code> l\u00f5ppu pre_tasks<\/code>?<\/p>\n
<\/p>\n
Muidugi, k\u00fcsimuse s\u00f5nastus viitab, et see v\u00f5ib puruneda. Aga mis t\u00e4pselt?<\/p>\n
<\/p>\n
\u2026 K\u00e4itlejad. Aluste lugemine toob v\u00e4lja olulise fakti: k\u00f5ik k\u00e4itlejad flush'itakse automaatselt p\u00e4rast iga sektsiooni. See t\u00e4hendab, et k\u00f5ik \u00fclesanded, pre_tasks<\/code>, siis k\u00f5ik k\u00e4itlejad, mis on olnud notify. Seej\u00e4rel t\u00e4idetakse k\u00f5ik rollid ja k\u00f5ik k\u00e4itlejad, mis on olnud notify rollides. Siis post_tasks<\/code> ja nende k\u00e4itlejad.<\/p>\n
<\/p>\n
Seega, kui liigutate \u00fclesande post_tasks<\/code> \u00fches pre_tasks<\/code>n\u00f5uab, et teil oleks v\u00f5imalus seda teha enne k\u00e4itleja t\u00e4itmist. N\u00e4iteks, kui pre_tasks<\/code> paigaldatakse ja konfigureeritakse veebiserver<\/a>, ja seej\u00e4rel m\u00e4\u00e4ratleme selle, takistades seel\u00e4bi kasutajal selgelt selle v\u00e4ljaid muuta. See on \u00fcks andmete peitmise mustritest post_tasks<\/code> millesse midagi saadetakse, siis selle \u00fclesande liigutamine sektsiooni pre_tasks<\/code> see toob kaasa olukorra, kus \"saatmise\" ajal server pole veel k\u00e4ivitatud ja k\u00f5ik kukub kokku.<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd m\u00f5tleme veel kord, miks me vajame pre_tasks<\/code> ja post_tasks<\/code>? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u0432\u044b\u043f\u043e\u043b\u043d\u0438\u0442\u044c \u0432\u0441\u0451 \u043d\u0443\u0436\u043d\u043e\u0435 (\u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0445\u044d\u043d\u0434\u043b\u0435\u0440\u044b) \u0434\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0440\u043e\u043b\u0438. \u0410 post_tasks<\/code> aitab meil t\u00f6\u00f6tada rollide t\u00e4itmise tulemustega (sealhulgas k\u00e4itlejatega).<\/p>\n
<\/p>\n
Tark Ansible'i tunner \u00fctleb meile, et on olemas meta: flush_handlers<\/code>, aga miks me vajame flush_handlers, kui me saame loota sektsioonide t\u00e4itmise j\u00e4rjekorrale m\u00e4ngus? Veelgi enam, meta: flush_handlers'i kasutamine v\u00f5ib tuua meile ootamatuid ja korduvaid k\u00e4itlejaid, tekitada kummalisi hoiatusi, kui kasutatakse when<\/code> on blokki<\/code> jne. Mida paremini te ansible'it tunnete, seda rohkem n\u00fcansse suudate \"nutika\" lahenduse jaoks tuua. Ja lihtne lahendus \u2014 looduslike jaotuste kasutamine pre\/roles\/post vahel \u2014 ei tekita n\u00fcansse.<\/p>\n
<\/p>\n
Ja, naasime meie 'foo' juurde. Kuhu see paigutada? pre, post v\u00f5i rollidesse? Loomulikult s\u00f5ltub see sellest, kas vajame foo t\u00f6\u00f6tlemise tulemusi. Kui mitte, siis ei pea foo olema ei pre ega post - neid sektsioone kasutatakse erilise t\u00e4hendusega - \u00fclesannete t\u00e4itmiseks enne ja p\u00e4rast p\u00f5hikoodi massiivi.<\/p>\n
<\/p>\n
N\u00fc\u00fcd s\u00f5ltub k\u00fcsimusele 'roll v\u00f5i \u00fclesanne' vastus sellest, mis on juba plays olemas - kui seal on \u00fclesandeid, siis tuleb need lisada \u00fclesannetes. Kui on rolle - tuleb luua roll (isegi kui see on vaid \u00fchest \u00fclesandest). Tuletan meelde, et \u00fclesandeid ja rolle ei kasutata korraga.<\/p>\n
<\/p>\n
Ansible'i p\u00f5hialuste m\u00f5istmine annab p\u00f5hjendatud vastused, mis n\u00e4ivad olevat maitse k\u00fcsimused.<\/p>\n
<\/p>\n
\u00dclesanded ja rollid (teine osa)<\/h1>\n
<\/p>\n
R\u00e4\u00e4kigem n\u00fc\u00fcd olukorrast, kus te alles alustate playbooki kirjutamist. Teil on vaja teha foo, bar ja baz. Kas need on kolm \u00fclesannet, \u00fcks roll v\u00f5i kolm rolli? \u00dcldistades k\u00fcsimust: millal tuleks hakata rolle kirjutama? Mis m\u00f5te on rollide kirjutamisel, kui saab kirjutada \u00fclesandeid?\u2026 Mis on roll?<\/p>\n
<\/p>\n
\u00dcks suurimaid vigu (millest olen juba r\u00e4\u00e4kinud) on arvata, et roll on nagu funktsioon programmis. Kuidas n\u00e4eb v\u00e4lja funktsiooni \u00fcldine kirjeldus? Ta v\u00f5tab sisenditeks argumendid, suheldes k\u00f5rvaltoimetega, tekitab k\u00f5rvalm\u00f5jusid ja tagastab v\u00e4\u00e4rtuse.<\/p>\n
<\/p>\n
N\u00fc\u00fcd, t\u00e4helepanu. Mis sellest saab rollis teha? Kutsuda esile k\u00f5rvalefekte - alati, palun, see on kogu Ansible sisuks - k\u00f5rvalefektide loomine. Kas olla k\u00f5rvalp\u00f5hjuseid? Elementaarne. Kuid '\u00fclekandmine ja tagastamine' osas - siin ei saa. Esiteks, te ei saa v\u00e4\u00e4rtust rolli edasi anda. Saate m\u00e4\u00e4rata globaalmuutuja, mille eluiga on plays, role'i vars sektsioonis. Saate m\u00e4\u00e4rata globaalmuutuja eluaja plays sees rollis. V\u00f5i isegi playsi eluiga.set_fact<\/code>\/register<\/code>). Kuid te ei saa omada "kohalikku muutujat". Te ei saa "v\u00e4\u00e4rtust vastu v\u00f5tta" ja "tagastada seda".<\/p>\n
<\/p>\n
Kandub v\u00e4lja peamine: Ansible'i jaoks ei saa midagi kirjutada ja mitte tekitada k\u00f5rvaltoimeid. Globaalsete muutujate muutmine on alati k\u00f5rvaltoime funktsioonis. N\u00e4iteks Rustis on globaalsete muutujate muutmine unsafe<\/code>. Kuid Ansible'is on ainus viis rollide v\u00e4\u00e4rtuste m\u00f5jutamiseks. Pange t\u00e4hele kasutatud s\u00f5nu: mitte "edastada v\u00e4\u00e4rtust rollile", vaid "muuta v\u00e4\u00e4rtusi, mida roll kasutab". Rollide vahel ei ole isoleeritust. \u00dclesannete ja rollide vahel ei ole isoleeritust.<\/p>\n
<\/p>\n
Kokku: roll ei ole funktsioon<\/strong>.<\/p>\n
<\/p>\n
Mis on head rollides? Esiteks, rollidel on default values (\/default\/main.yaml<\/code>), teiseks on rollidel t\u00e4iendavad kataloogid failide salvestamiseks.<\/p>\n
<\/p>\n
Miks on default values head? Sest Maslow p\u00fcramiidis on Ansible'i muutuja prioriteetide tabelis rolli default'id k\u00f5ige v\u00e4hem prioriteetsed (v\u00e4lja arvatud Ansible'i k\u00e4surea parameetrid). See t\u00e4hendab, et kui soovite pakkuda vaikimisi v\u00e4\u00e4rtusi ja mitte muretseda, et need h\u00e4gustavad inventari v\u00f5i grupivariable\u2019id, on rollide default\u2019id ainus \u00f5ige koht, kuhu minna. (Ma valetan natuke \u2014 on veel |d(your_default_here)<\/code>, aga kui r\u00e4\u00e4kida staatilisest kohast \u2014 siis ainult rollide default'id).<\/p>\n
<\/p>\n
Mis veel on head rollides? Need, et neil on oma kataloogid. Need on kataloogid muutujatele, nii p\u00fcsivatele (st rollile arvutatud) kui ka d\u00fcnaamilistele (on olemas selline pattern v\u00f5i anti-pattern \u2014 include_vars<\/code> (autoriseerimiskoodiga). {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Need on kataloogid files\/<\/code>, templates\/<\/code>. Samuti v\u00f5imaldab see rollidel omada oma mooduleid ja pluginaid (library\/<\/code>). Kuid v\u00f5rreldes playbook’de \u00fclesannetega (kus see k\u00f5ik v\u00f5ib samuti olla), on siin ainus kasu see, et failid ei ole kuhjunud \u00fchte kuhja, vaid mitmesse eraldi kuhja.<\/p>\n
<\/p>\n
Veel \u00fcks detail: on v\u00f5imalik proovida teha rolle, mis on kergesti taaskasutatavad (galaxy kaudu). P\u00e4rast kogude tekkimist v\u00f5ib rollide levikut peaaegu unustatuks pidada.<\/p>\n
<\/p>\n
Seega on rollidel kaks olulist omadust: neil on vaikeseaded (ainulaadne omadus) ja nad v\u00f5imaldavad koodi struktureerimist.<\/p>\n
<\/p>\n
Tagasi algse k\u00fcsimuse juurde: millal teha \u00fclesandeid ja millal rolle? \u00dclesandeid m\u00e4nguraamatus kasutatakse enamasti kas \"liimina\" enne v\u00f5i p\u00e4rast rolle, v\u00f5i iseseisva ehituselemendina (siis ei tohiks koodis olla rolle). Palju normaalseid \u00fclesandeid koos rollidega \u2014 see on selgelt lohakus. Tuleb j\u00e4\u00e4da kindlasse stiili \u2014 kas \u00fclesanded v\u00f5i rollid. Rollid pakuvad eristust entiteetide ja vaikev\u00e4\u00e4rtuste vahel, \u00fclesanded v\u00f5imaldavad koodi kiiremini lugeda. T\u00fc\u00fcpiliselt pannakse rollidesse enam \"staatilist\" (olulist ja keerulist) koodi, samas kui \u00fclesannete stiilis kirjutatakse abiskripte.<\/p>\n
<\/p>\n
On olemas v\u00f5imalus import_role'i kasutada \u00fclesandena, kuid kui te seda kirjutate, olge valmis oma esteetiliste tunnete \u00f5igustamiseks, miks te soovite seda teha.<\/p>\n
<\/p>\n
T\u00fc\u00fctud lugejad v\u00f5ivad \u00f6elda, et rollid v\u00f5ivad importida rolle, rollidel v\u00f5ib olla s\u00f5ltuvus l\u00e4bi galaxy.yml, ja lisaks on veel hirmus ja \u00f5udne. include_role<\/code> \u2014 meenutan, et me arendame oma p\u00f5hioskusi Ansible'is, mitte iluv\u00f5imlemises.<\/p>\n
<\/p>\n
Handler'id ja \u00fclesanded<\/h1>\n
<\/p>\n
R\u00e4\u00e4gime \u00fchest ilmsest asjast: handler'idest. Nende \u00f5igesti kasutamise oskus on peaaegu kunst. Mis vahe on handler'i ja \u00fclesande vahel?<\/p>\n
<\/p>\n
Kuna me meenutame p\u00f5hialuseid, siis siin on n\u00e4ide:<\/p>\n
<\/p>\n
- hosts: group1\n  tasks:\n    - foo:\n      notify: handler1\n  handlers:\n     - name: handler1\n       bar:<\/code><\/pre>\n
<\/p>\n
Rollide handler'id asuvad rolename\/handlers\/main.yaml. Handler'id jagatakse k\u00f5ikide m\u00e4ngus osalejatega: pre\/post_tasks v\u00f5ivad kutsuda rolli handler'id, ja roll v\u00f5ib kutsuda m\u00e4ngu handler'id. Siiski, \"ristrollide\" handler'ite kutsumine p\u00f5hjustab palju suuremat wtf-d, kui triviaalsete handler'ite kordamine. (Veel \u00fcks parimate praktikate element \u2014 proovida mitte korrata handler'ite nimesid).<\/p>\n
<\/p>\n
P\u00f5hiline erinevus seisneb selles, et \u00fclesanne t\u00e4idetakse (idempotentselt) alati (pluss\/minus sildid ja when<\/code>), ja k\u00e4itleja \u2014 staatuse muutmise jaoks (notify aktiveerub ainult siis, kui on olnud muutus). Miks see on probleem? N\u00e4iteks, et korduva k\u00e4ivitamise korral, kui ei olnud muutust, ei tule ka k\u00e4itlejat. Aga miks v\u00f5ib olla nii, et me peame k\u00e4itlejat t\u00e4itma, isegi kui genereeriva \u00fclesande puhul ei olnud muutust? N\u00e4iteks sellep\u00e4rast, et midagi l\u00e4ks valesti ja muutus oli olnud, kuid k\u00e4itlejani ei j\u00f5udnud. N\u00e4iteks, kuna v\u00f5rk oli ajutiselt maas. Konfigureerimine muutus, teenust ei k\u00e4ivitatud uuesti. J\u00e4rgmisel k\u00e4ivitamisel konfigureerimine enam ei muutu ja teenus j\u00e4\u00e4b vana konfigureerimise versiooni peale.<\/p>\n
<\/p>\n
Konfiguratsiooni olukord ei ole lahendatav (t\u00e4psemalt, saab ise v\u00e4lja m\u00f5elda spetsiaalse k\u00e4ivitamisprotokolli failiflagidega jne, kuid see pole enam \u2018basic ansible\u2019 mitte mingil viisil). Siiski on teisest k\u00fcljest teine sagedane lugu: me paigaldasime rakenduse, kirja panime selle .service<\/code>-faili, ja n\u00fc\u00fcd tahame seda daemon_reload<\/code> ja state=started<\/code>. Ja loomulik koht selle jaoks n\u00e4ib olevat k\u00e4itleja. Kuid kui muuta see k\u00e4itlejast \u00fclesandeks \u00fclesannete loendi l\u00f5pus v\u00f5i rolliks, siis t\u00e4idetakse see igal korral ideempotentselt. Isegi kui m\u00e4nguraamat katkeb keskel. See ei lahenda probleemiga seotud restarted (\u00fclesannet ei saa teha restarted atribuudi, kuna ideempotentsus kaob), kuid kindlasti tasub seadistada state=started, seet\u00f5ttu t\u00f5useb m\u00e4nguraamatude \u00fcldine stabiilsus, kuna v\u00e4heneb seoste ja d\u00fcnaamilise oleku arv.<\/p>\n
<\/p>\n
Veel \u00fcks positiivne omadus handler'i juures on see, et see ei ummistata v\u00e4ljundit. Muutusi ei olnud \u2014 ei ole \u00fcleliigseid skipped v\u00f5i ok v\u00e4ljundis \u2014 lihtsam lugeda. Samas on see ka negatiivne omadus \u2014 kui leiate tr\u00fckivea sirgjooneliselt t\u00e4idetavas \u00fclesandes esimese k\u00e4igu k\u00e4igus, siis handler'id t\u00e4idetakse ainult muutumisel, st teatud tingimustel \u2014 v\u00e4ga harva. N\u00e4iteks esmakordselt elus viie aasta p\u00e4rast. Ja muidugi, seal on tr\u00fckiviga nimega ja k\u00f5ik l\u00e4heb katki. Teisel korral ei saa neid k\u00e4ivitada \u2014 muudatusi lihtsalt ei ole.<\/p>\n
<\/p>\n
Erinevate muutujate k\u00e4ttesaadavusest tuleb kindlasti r\u00e4\u00e4kida. N\u00e4iteks, kui teete notify ts\u00fckli\u00fclesande jaoks, siis mis on muutuja v\u00e4\u00e4rtused? Anal\u00fc\u00fctiliselt on v\u00f5imalik j\u00e4reldada, kuid see ei ole alati triviaalne, eriti kui muutujad tulevad erinevatest kohtadest.<\/p>\n
<\/p>\n
\u2026 Nii et handler'id on tunduvalt v\u00e4hem kasulikud ja palju probleemsemad, kui see tundub. Kui midagi saab ilusasti (ilma peenutsemata) kirjutada ilma handlers'ideta, on parem teha seda ilma nendeta. Kui ilusasti ei \u00f5nnestu \u2014 siis on parem nendega.<\/p>\n
<\/p>\n
Peenest lugija m\u00e4rgib \u00f5igusega, et me ei arutanud kuula<\/code>, et handler v\u00f5ib kutsuda notify teise handler’ile, et handler v\u00f5ib sisaldada import_tasks (mis v\u00f5ib teha include_role koos with_items), et h\u00e4lendite s\u00fcsteem Ansible'is on Turingi t\u00e4ielik, et include_role h\u00e4lendid \u00fcllatavalt kattuvad m\u00e4ngude h\u00e4lenditega jne \u2014 see k\u00f5ik ei ole ilmselgelt "alused").<\/p>\n
<\/p>\n
Kuid on \u00fcks konkreetne WTF, mis on tegelikult funktsioon ja mida tuleks meeles pidada. Kui teil on \u00fclesanne, mis t\u00e4itub delegate_to<\/code> ja sellel on notify, siis vastav handler t\u00e4idetakse ilma delegate_to<\/code>, st hostis, kus m\u00e4ng on m\u00e4\u00e4ratud. (Kuigi handler'il v\u00f5ib loomulikult olla delegate_to<\/code> ka).<\/p>\n
<\/p>\n
Soovin r\u00e4\u00e4kida natuke uuesti kasutatavatest rollidest. Enne kogude loomist oli idee, et v\u00f5iks luua universaalsed rollid, mida saab ansible-galaxy install<\/code> ja asusime teele. T\u00f6\u00f6tab k\u00f5igis ops\u00fcsteemides igasugustes olukordades. Niisiis, minu arvamus: see ei toimi. Iga roll, mis katab tonni include_vars<\/code>, toetamata 100500 juhtumit on hukule m\u00e4\u00e4ratud corner case vigade l\u00f5ksudesse. Neid saab nagu iga testimise korral summutades katta massiivse testimisega, aga nagu igasuguse testimise puhul, kas teil on dekartov toode sisendite vahel ja totaalfunktsioon v\u00f5i on teil "katetud \u00fcksikud stsenaariumid". Minu arvates on parem, kui roll on lineaarne (ts\u00fckliline keerukus 1).<\/p>\n
<\/p>\n
Mida v\u00e4hem if’e (\u00e4gedad v\u00f5i deklaratiivsed \u2014 vormis when<\/code> v\u00f5i kujul include_vars<\/code> t\u00fc\u00fcpide kogum), seda parem on roll. M\u00f5nikord tuleb harude loomine, kuid, pean kordama, mida v\u00e4hem neid on, seda parem. Nii et n\u00e4iliselt hea roll galaxy's (see t\u00f6\u00f6tab ju!) koos hulga when<\/code> v\u00f5ib olla v\u00e4hem eelistatav kui "oma" roll viie \u00fclesande korral. Moment, mil galaxy roll on parem \u2014 kui hakkate midagi kirjutama. Moment, mil see halveneb \u2014 kui midagi katki l\u00e4heb, ja kahtlustate, et see on "galaxy rolli" t\u00f5ttu. Avate selle, ja seal on viis kaasamist, kaheksa \u00fclesande nimekirja ja virn when<\/code>‘idest... Ja sellega tuleb hakkama saada. Selle asemel, et olla 5 \u00fclesannet lineaarse nimekirjana, kus polegi millelegi katki minna.<\/p>\n
<\/p>\n
J\u00e4rgmistes osades<\/h1>\n
<\/p>\n