Ég geri mikið af umsögnum um Ansible kóða annarra og skrifa mikið sjálfur. Við greiningu á mistökum (bæði annarra og mín eigin), auk fjölda viðtala, áttaði ég mig á helstu mistökunum sem Ansible notendur gera - þeir lenda í flóknum hlutum án þess að ná tökum á þeim grundvallaratriðum.

Til að leiðrétta þetta alhliða óréttlæti ákvað ég að skrifa inngang að Ansible fyrir þá sem þegar þekkja það. Ég vara þig við, þetta er ekki endursögn af mönnum, þetta er langlestur með fullt af stöfum og engum myndum.

Væntanlegt stig lesandans er að nokkur þúsund línur af yamla hafi þegar verið skrifaðar, eitthvað er þegar í framleiðslu, en "einhvern veginn er allt skakkt."

Nöfn

Helstu mistökin sem Ansible notandi gerir er að vita ekki hvað eitthvað heitir. Ef þú veist ekki nöfnin geturðu ekki skilið hvað segir í skjölunum. Lifandi dæmi: í viðtali gat einstaklingur sem virtist segjast hafa skrifað mikið í Ansible ekki svarað spurningunni „úr hvaða þáttum samanstendur leikbók? Og þegar ég stakk upp á því að „svarið væri að búast við því að leikritið væri leikrit,“ fylgdi hin vítaverða athugasemd „við notum það ekki“. Fólk skrifar Ansible fyrir peninga og notar ekki leik. Þeir nota það í raun, en vita ekki hvað það er.

Svo við skulum byrja á einhverju einföldu: hvað er það kallað. Kannski veistu þetta, eða kannski ekki, vegna þess að þú gafst ekki gaum þegar þú lest skjölin.

ansible-playbook keyrir leikbókina. Leikbók er skrá með yml/yaml endingunni, inni í henni er eitthvað á þessa leið:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Við höfum þegar áttað okkur á því að öll þessi skrá er leikbók. Við getum sýnt hvar hlutverkin eru og hvar verkefnin eru. En hvar er leikurinn? Og hver er munurinn á leik og hlutverki eða leikbók?

Það er allt í skjölunum. Og þeir sakna þess. Byrjendur - því það er of mikið og þú munt ekki muna allt í einu. Reyndur - vegna þess að „léttvægir hlutir“. Ef þú ert reyndur skaltu lesa þessar síður aftur að minnsta kosti einu sinni á sex mánaða fresti, og kóðinn þinn verður fremstur í flokki.

Svo, mundu: Playbook er listi sem samanstendur af leik og import_playbook.
Þetta er eitt leikrit:

- hosts: group1
  roles:
    - role1

og þetta er líka annað leikrit:

- hosts: group2,group3
  tasks:
    - debug:

Hvað er leikur? Af hverju er hún það?

Leikur er lykilatriði í leikbók, því leikur og aðeins leikur tengir lista yfir hlutverk og/eða verkefni við lista yfir gestgjafa sem þarf að framkvæma á. Í djúpu dýpi skjalanna má finna minnst á delegate_to, staðbundin uppflettingarviðbætur, netkerfissértækar stillingar, stökkhýsingar osfrv. Þeir gera þér kleift að breyta aðeins stað þar sem verkefni eru unnin. En, gleymdu því. Hver af þessum snjöllu valkostum hefur mjög sérstaka notkun og þeir eru örugglega ekki alhliða. Og við erum að tala um grundvallaratriði sem allir ættu að vita og nota.

Ef þú vilt flytja „eitthvað“ „einhvers staðar“ skrifarðu leikrit. Ekki hlutverk. Ekki hlutverk með einingum og fulltrúa. Þú tekur það og skrifar leikrit. Í hvaða, í hýsingarreitnum sem þú listar hvar á að framkvæma, og í hlutverkum/verkefnum - hvað á að framkvæma.

Einfalt, ekki satt? Hvernig gat það verið annað?

Eitt af einkennandi augnablikunum þegar fólk hefur löngun til að gera þetta ekki í gegnum leik er „hlutverkið sem setur allt upp“. Ég myndi vilja hafa hlutverk sem stillir bæði netþjóna af fyrstu gerð og netþjóna af annarri gerð.

Erkitýpískt dæmi er vöktun. Ég myndi vilja hafa eftirlitshlutverk sem mun stilla eftirlit. Eftirlitshlutverkið er úthlutað til að fylgjast með gestgjöfum (samkvæmt leik). En það kemur í ljós að til að fylgjast með þurfum við að afhenda pakka til gestgjafanna sem við erum að fylgjast með. Af hverju ekki að nota delegate? Þú þarft líka að stilla iptables. fulltrúa? Þú þarft líka að skrifa/leiðrétta stillingu fyrir DBMS til að virkja vöktun. fulltrúa! Og ef sköpunargáfuna vantar, þá geturðu skipað sendinefnd include_role í hreiðri lykkju með því að nota erfiða síu á lista yfir hópa, og inni include_role þú getur gert meira delegate_to aftur. Og í burtu förum við...

Góð ósk - að hafa eitt eftirlitshlutverk, sem "gerir allt" - leiðir okkur inn í algjört helvíti sem oftast er aðeins ein leið út úr: að endurskrifa allt frá grunni.

Hvar urðu mistökin hér? Um leið og þú uppgötvaðir að til að gera verkefni "x" á gestgjafa X þú þurftir að fara til gestgjafa Y og gera "y" þar, þá þurftir þú að gera einfalda æfingu: Farðu og skrifaðu leikrit, sem á gestgjafa Y gerir y. Ekki bæta einhverju við „x“ heldur skrifa það frá grunni. Jafnvel með harðkóðaðar breytur.

Svo virðist sem allt í málsgreinunum hér að ofan sé rétt sagt. En þetta er ekki þitt mál! Vegna þess að þú vilt skrifa einnota kóða sem er DRY og bókasafnslíkur og þú þarft að leita að aðferð til að gera það.

Þetta er þar sem önnur alvarleg mistök leynast. Villa sem breytti mörgum verkefnum úr þolanlegu skrifum (gæti verið betra, en allt virkar og er auðvelt að klára) í algjöran hrylling sem jafnvel höfundur getur ekki skilið. Það virkar, en guð forði þér að breyta neinu.

Villan er: hlutverk er bókasafnsaðgerð. Þessi samlíking hefur eyðilagt svo mörg góð byrjun að það er einfaldlega sorglegt á að horfa. Hlutverkið er ekki bókasafnsaðgerð. Hún getur ekki gert útreikninga og hún getur ekki tekið ákvarðanir á leikstigi. Minntu mig á hvaða ákvarðanir leikur tekur?

Takk, það er rétt hjá þér. Leikur tekur ákvörðun (nánar tiltekið, hann inniheldur upplýsingar) um hvaða verkefni og hlutverk á að sinna á hvaða gestgjöfum.

Ef þú framselur þessa ákvörðun í hlutverk, og jafnvel með útreikningum, dæmir þú sjálfan þig (og þann sem mun reyna að flokka kóðann þinn) til ömurlegrar tilveru. Hlutverkið ræður ekki hvar það er sinnt. Þessi ákvörðun er tekin með leik. Hlutverkið gerir það sem því er sagt, þar sem því er sagt.

Af hverju er hættulegt að forrita í Ansible og hvers vegna COBOL er betra en Ansible munum við ræða í kaflanum um breytur og jinja. Í bili skulum við segja eitt - hver útreikningur þinn skilur eftir sig óafmáanleg ummerki um breytingar á alþjóðlegum breytum og þú getur ekki gert neitt í því. Um leið og „sporin“ tvö skárust var allt horfið.

Athugið fyrir svekktina: hlutverkið getur vissulega haft áhrif á stjórnflæðið. Borða delegate_to og það hefur sanngjarna notkun. Borða meta: end host/play. En! Manstu að við kennum grunnatriðin? Gleymdi delegate_to. Við erum að tala um einfaldasta og fallegasta Ansible kóðann. Sem er auðvelt að lesa, auðvelt að skrifa, auðvelt að kemba, auðvelt að prófa og auðvelt að klára. Svo, enn og aftur:

spila og aðeins leikur ræður á hvaða gestgjöfum hvað er framkvæmt.

Í þessum kafla fjölluðum við um andstöðu leiks og hlutverks. Nú skulum við tala um verkefnin vs hlutverkatengsl.

Verkefni og hlutverk

Íhugaðu leik:

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

Segjum að þú þurfir að gera foo. Og það lítur út fyrir foo: name=foobar state=present. Hvar á ég að skrifa þetta? í pre? færslu? Búa til hlutverk?

...Og hvert fóru verkefnin?

Við byrjum aftur með grunnatriðin - leiktækið. Ef þú svífur um þetta mál geturðu ekki notað leik sem grunn fyrir allt annað, og niðurstaðan þín verður "skjálfti".

Leiktæki: hýsingartilskipun, stillingar fyrir sjálfan leik og forverkefni, verkefni, hlutverk, hlutar eftir_verkefni. Eftirstöðvar leiksins eru ekki mikilvægar fyrir okkur núna.

Röð hluta þeirra með verkefnum og hlutverkum: pre_tasks, roles, tasks, post_tasks. Þar sem merkingarlega séð er framkvæmdaröðin á milli tasks и roles er ekki ljóst, þá segja bestu starfsvenjur að við séum að bæta við kafla tasks, aðeins ef ekki roles... Ef það er roles, þá eru öll meðfylgjandi verkefni sett í hluta pre_tasks/post_tasks.

Það eina sem er eftir er að allt er merkingarlega skýrt: fyrst pre_tasks, þá roles, þá post_tasks.

En við höfum enn ekki svarað spurningunni: hvar er einingakallið? foo skrifa? Þurfum við að skrifa heilt hlutverk fyrir hverja einingu? Eða er betra að hafa þykkt hlutverk fyrir allt? Og ef ekki hlutverk, hvar ætti ég þá að skrifa - í for- eða færslu?

Ef það er ekkert rökstutt svar við þessum spurningum, þá er þetta merki um skort á innsæi, það er að segja sömu „skjálfta undirstöður“. Við skulum reikna það út. Í fyrsta lagi öryggisspurning: Ef leikur hefur pre_tasks и post_tasks (og það eru engin verkefni eða hlutverk), þá getur eitthvað brotnað ef ég framkvæmi fyrsta verkefnið frá post_tasks Ég flyt það til enda pre_tasks?

Orðalag spurningarinnar gefur auðvitað til kynna að hún muni brotna. En hvað nákvæmlega?

... Handhafar. Að lesa grunnatriðin leiðir í ljós mikilvæga staðreynd: allir meðhöndlarar eru skolaðir sjálfkrafa eftir hvern hluta. Þeir. öll verkefni frá pre_tasks, þá allir meðhöndlarar sem voru látnir vita. Þá eru öll hlutverkin og allir meðhöndlararnir sem voru tilkynntir í hlutverkunum framkvæmdir. Eftir post_tasks og stjórnendur þeirra.

Svona, ef þú dregur verkefni frá post_tasks в pre_tasks, þá muntu hugsanlega keyra það áður en meðhöndlarinn er keyrður. til dæmis ef í pre_tasks vefþjónninn er settur upp og stilltur, og post_tasks eitthvað er sent til þess, flyttu síðan þetta verkefni yfir á hlutann pre_tasks mun leiða til þess að á þeim tíma sem „sending“ er send mun þjónninn ekki enn vera í gangi og allt mun bila.

Nú skulum við hugsa aftur, hvers vegna þurfum við pre_tasks и post_tasks? Til dæmis, til að klára allt sem þarf (þar á meðal umsjónarmenn) áður en hlutverkinu er sinnt. A post_tasks gerir okkur kleift að vinna með niðurstöður framkvæmdahlutverka (þar á meðal umsjónarmenn).

Glöggur Ansible sérfræðingur mun segja okkur hvað það er. meta: flush_handlers, en hvers vegna þurfum við flush_handlers ef við getum treyst á framkvæmdarröð hluta í leik? Þar að auki getur notkun meta: flush_handlers gefið okkur óvænta hluti með tvíteknum meðhöndlum, sem gefur okkur undarlegar viðvaranir þegar þeir eru notaðir when у block o.s.frv. Því betur sem þú þekkir hið sanna, því fleiri blæbrigði geturðu nefnt fyrir „erfiða“ lausn. Og einföld lausn - að nota náttúrulega skiptingu á milli for/hlutverka/pósts - veldur ekki blæbrigðum.

Og aftur að „foo“ okkar. Hvar ætti ég að setja það? Í for-, innleggi eða hlutverkum? Augljóslega fer þetta eftir því hvort við þurfum niðurstöður stjórnandans fyrir foo. Ef þeir eru ekki til staðar, þá þarf ekki að setja foo í pre eða post - þessir hlutar hafa sérstaka merkingu - framkvæma verkefni fyrir og eftir meginhluta kóðans.

Nú kemur svarið við spurningunni „hlutverk eða verkefni“ niður á því sem er þegar í leik - ef það eru verkefni þar, þá þarftu að bæta þeim við verkefni. Ef það eru hlutverk þarf að búa til hlutverk (jafnvel úr einu verkefni). Ég minni á að verkefni og hlutverk eru ekki notuð á sama tíma.

Að skilja grunnatriði Ansible veitir sanngjörn svör við spurningum um smekk.

Verkefni og hlutverk (hluti tvö)

Nú skulum við ræða stöðuna þegar þú ert að byrja að skrifa leikbók. Þú þarft að búa til foo, bar og baz. Eru þetta þrjú verkefni, eitt hlutverk eða þrjú hlutverk? Til að draga saman spurninguna: á hvaða tímapunkti ættir þú að byrja að skrifa hlutverk? Hver er tilgangurinn með því að skrifa hlutverk þegar þú getur skrifað verkefni?... Hvað er hlutverk?

Ein af stærstu mistökunum (ég talaði þegar um þetta) er að halda að hlutverk sé eins og aðgerð í bókasafni forrits. Hvernig lítur almenn falllýsing út? Það samþykkir inntaksrök, hefur samskipti við hliðarorsakir, gerir aukaverkanir og skilar gildi.

Nú, athygli. Hvað er hægt að gera úr þessu í hlutverkinu? Þér er alltaf velkomið að hringja í aukaverkanir, þetta er kjarninn í heildinni Ansible - til að búa til aukaverkanir. Áttu hliðarástæður? Grunnskólastig. En með „passaðu gildi og skilaðu því“ - það er þar sem það virkar ekki. Í fyrsta lagi geturðu ekki sent gildi yfir í hlutverk. Þú getur stillt alþjóðlega breytu með ævistærð leiks í vars hlutanum fyrir hlutverkið. Þú getur stillt alþjóðlega breytu með ævi í leik í hlutverkinu. Eða jafnvel með líftíma leikbóka (set_fact/register). En þú getur ekki haft "staðbundnar breytur". Þú getur ekki „tekið verðmæti“ og „skilað því“.

Aðalatriðið leiðir af þessu: þú getur ekki skrifað eitthvað í Ansible án þess að valda aukaverkunum. Breyting á hnattrænum breytum er alltaf aukaverkun fyrir fall. Í Rust, til dæmis, er að breyta alþjóðlegri breytu unsafe. Og í Ansible er það eina aðferðin til að hafa áhrif á gildin fyrir hlutverk. Athugaðu orðin sem notuð eru: ekki "senda gildi til hlutverksins", heldur "breyttu gildunum sem hlutverkið notar". Það er engin einangrun á milli hlutverka. Það er engin einangrun á milli verkefna og hlutverka.

Samtals: hlutverk er ekki fall.

Hvað er gott við hlutverkið? Í fyrsta lagi hefur hlutverkið sjálfgefna gildi (/default/main.yaml), í öðru lagi hefur hlutverkið viðbótarskrár til að geyma skrár.

Hver er ávinningurinn af vanskilagildum? Vegna þess að í pýramída Maslow, frekar bjagaðri töflu Ansible um breytilegar forgangsröðun, eru sjálfgefin hlutverk í lágmarki (að frádregnum Ansible skipanalínubreytum). Þetta þýðir að ef þú þarft að gefa upp sjálfgefin gildi og ekki hafa áhyggjur af því að þau hnekki gildunum úr birgða- eða hópbreytum, þá eru sjálfgefin hlutverk eini rétti staðurinn fyrir þig. (Ég er að ljúga smá - það eru fleiri |d(your_default_here), en ef við tölum um kyrrstæða staði, þá er aðeins hlutverk sjálfgefið).

Hvað er annars frábært við hlutverkin? Vegna þess að þeir hafa sína eigin vörulista. Þetta eru möppur fyrir breytur, bæði fastar (þ.e. reiknaðar fyrir hlutverkið) og dynamic (það er annað hvort mynstur eða andmynstur - include_vars ásamt {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Þetta eru möppur fyrir files/, templates/. Einnig gerir það þér kleift að hafa þínar eigin einingar og viðbætur (library/). En í samanburði við verkefni í leikbók (sem getur líka haft þetta allt), þá er eini ávinningurinn hér að skrárnar eru ekki settar í einn bunka, heldur nokkra aðskilda hauga.

Eitt smáatriði í viðbót: þú getur reynt að búa til hlutverk sem verða tiltæk til endurnotkunar (í gegnum Galaxy). Með tilkomu safna getur hlutverkaskipting talist nánast gleymd.

Þannig hafa hlutverk tvo mikilvæga eiginleika: þau eru með sjálfgefna stillingu (einstaka eiginleika) og þau gera þér kleift að skipuleggja kóðann þinn.

Farið aftur að upprunalegu spurningunni: hvenær á að gera verkefni og hvenær á að gera hlutverk? Verkefni í leikbók eru oftast notuð annað hvort sem „lím“ fyrir/eftir hlutverk, eða sem sjálfstæður byggingarþáttur (þá ættu engin hlutverk að vera í kóðanum). Hrúgur af venjulegum verkefnum í bland við hlutverk er ótvírætt slúður. Þú ættir að fylgja ákveðnum stíl - annað hvort verkefni eða hlutverk. Hlutverk veita aðskilnað eininga og sjálfgefna, verkefni leyfa þér að lesa kóða hraðar. Venjulega er „kyrrstæðari“ (mikilvægari og flóknari) kóði settur í hlutverk og hjálparforskriftir eru skrifaðar í verkstíl.

Það er hægt að gera import_role sem verkefni, en ef þú skrifar þetta, vertu þá tilbúinn að útskýra fyrir eigin fegurðarskyni hvers vegna þú vilt gera þetta.

Glöggur lesandi gæti sagt að hlutverk geti flutt inn hlutverk, hlutverk geta verið háð í gegnum galaxy.yml, og það er líka til hræðilegt og hræðilegt include_role - Ég minni þig á að við erum að bæta færni í undirstöðu Ansible, en ekki í myndfimleikum.

Umsjónarmenn og verkefni

Við skulum ræða annað augljóst: umsjónarmenn. Að vita hvernig á að nota þau rétt er nánast list. Hver er munurinn á stjórnanda og dragi?

Þar sem við erum að muna grunnatriðin er hér dæmi:

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

Umsjónarmenn hlutverksins eru staðsettir í rolename/handlers/main.yaml. Handlarar grúska á milli allra þátttakenda leiksins: Pre/post_tasks geta dregið hlutverkastjórnendur og hlutverk getur dregið meðhöndlara úr leikritinu. Hins vegar valda "cross-role" köll til handlers miklu meira wtf en að endurtaka trivial handler. (Annar þáttur í bestu starfsvenjum er að reyna að endurtaka ekki nöfn stjórnenda).

Aðalmunurinn er sá að verkefnið er alltaf framkvæmt (afmagnað) (plús/mínus merki og when), og stjórnandinn - eftir ástandsbreytingu (tilkynnið eldsvoða aðeins ef henni hefur verið breytt). Hvað þýðir þetta? Til dæmis sú staðreynd að þegar þú endurræsir, ef það var ekkert breytt, þá verður enginn meðhöndlari. Af hverju gæti verið að við þurfum að framkvæma meðhöndlun þegar engin breyting varð á framleiðsluverkefninu? Til dæmis vegna þess að eitthvað brotnaði og breyttist, en framkvæmd barst ekki til stjórnandans. Til dæmis vegna þess að netið var tímabundið niðri. Stillingin hefur breyst, þjónustan hefur ekki verið endurræst. Næst þegar þú ræsir hana breytist stillingin ekki lengur og þjónustan er áfram með gömlu útgáfuna af stillingunni.

Ekki er hægt að leysa ástandið með stillingarnar (nánar tiltekið, þú getur fundið upp sérstaka endurræsingarreglur fyrir sjálfan þig með skráarflöggum osfrv., en þetta er ekki lengur 'basic ansible' í hvaða formi sem er). En það er önnur algeng saga: við settum upp forritið, tókum það upp .service-skrá, og nú viljum við hana daemon_reload и state=started. Og náttúrulega staðurinn fyrir þetta virðist vera stjórnandinn. En ef þú gerir það ekki að stjórnanda heldur verkefni í lok verkefnalista eða hlutverks, þá verður það framkvæmt af sjálfsdáðum í hvert skipti. Jafnvel þótt leikbókin brotnaði á miðjunni. Þetta leysir alls ekki endurræst vandamálið (þú getur ekki gert verkefni með endurræst eigindinni, vegna þess að sjálfvirkni er glataður), en það er örugglega þess virði að gera state=start, heildarstöðugleiki leikbóka eykst, vegna þess að fjöldi tenginga og kraftmikið ástand minnkar.

Annar jákvæður eiginleiki stjórnandans er að hann stíflar ekki úttakið. Það voru engar breytingar - ekkert aukalega sleppt eða í lagi í úttakinu - auðveldara að lesa. Það er líka neikvæður eiginleiki - ef þú finnur innsláttarvillu í línulega keyrðu verkefni í fyrstu keyrslu, þá verða meðhöndlarnir aðeins keyrðir þegar þeim er breytt, þ.e. við sumar aðstæður - mjög sjaldan. Til dæmis í fyrsta skipti á ævinni fimm árum síðar. Og auðvitað verður prentvilla í nafninu og allt brotnar. Og ef þú keyrir þá ekki í annað skiptið, þá er engin breyting.

Sérstaklega þurfum við að tala um framboð breytna. Til dæmis, ef þú tilkynnir verkefni með lykkju, hvað verður þá í breytunum? Þú getur giskað á greiningar, en það er ekki alltaf léttvægt, sérstaklega ef breyturnar koma frá mismunandi stöðum.

... Þannig að meðhöndlarar eru miklu minna gagnlegir og miklu erfiðari en þeir virðast. Ef þú getur skrifað eitthvað fallega (án díla) án meðhöndla, þá er betra að gera það án þeirra. Ef það virkar ekki fallega, þá er það betra hjá þeim.

Ætandi lesandi bendir réttilega á að við höfum ekki rætt listenað meðhöndlari getur hringt í notify fyrir annan meðhöndlun, að meðhöndlari getur innihaldið import_tasks (sem getur gert include_role með with_items), að meðhöndlunarkerfið í Ansible sé Turing-complete, að meðhöndlarar frá include_role skerast á forvitnilegan hátt með meðhöndlum úr leik, o.s.frv. .d. - allt þetta er greinilega ekki „grunnatriði“).

Þó að það sé einn sérstakur WTF sem er í raun eiginleiki sem þú þarft að hafa í huga. Ef verkefni þitt er framkvæmt með delegate_to og það hefur tilkynnt, þá er samsvarandi meðferðaraðili keyrður án delegate_to, þ.e. á gestgjafanum þar sem leik er úthlutað. (Þó að stjórnandinn gæti auðvitað haft það delegate_to Sama).

Sérstaklega vil ég segja nokkur orð um margnota hlutverk. Áður en söfn birtust var hugmynd um að hægt væri að búa til alhliða hlutverk sem gætu verið ansible-galaxy install og fór. Virkar á öllum stýrikerfum af öllum afbrigðum við allar aðstæður. Svo mín skoðun: það virkar ekki. Hvaða hlutverk sem er með massa include_vars, sem styður 100500 mál, er dæmt til hyldýpis hornhylkja. Hægt er að hylja þær með gríðarlegum prófunum, en eins og með allar prófanir, annað hvort ertu með kartesíska vöru af inntaksgildum og heildarvirkni, eða þú ert með „einstök atburðarás“. Mín skoðun er sú að það sé miklu betra ef hlutverkið er línulegt (cyclomatic complexity 1).

Því færri ef (skýr eða yfirlýsing - í formi when eða form include_vars eftir mengi breyta), því betra hlutverk. Stundum þarf að búa til útibú, en ég endurtek, því færri sem eru, því betra. Svo það virðist vera gott hlutverk með Galaxy (það virkar!) með fullt af when getur verið minna æskilegt en „eigið“ hlutverk úr fimm verkefnum. Augnablikið þegar hlutverkið með Galaxy er betra er þegar þú byrjar að skrifa eitthvað. Augnablikið þegar það versnar er þegar eitthvað brotnar og þú hefur grun um að það sé vegna "hlutverksins með vetrarbrautinni". Þú opnar það og það eru fimm innfellingar, átta verkefnablöð og stafli when'ov... Og við þurfum að komast að þessu. Í stað 5 verkefna, línulegur listi þar sem ekkert er að brjóta.

Í eftirfarandi hlutum

• Smá um birgðahald, hópbreytur, host_group_vars viðbót, hostvars. Hvernig á að binda Gordian hnút með spaghetti. Umfang og forgangsbreytur, Ansible minnislíkan. "Svo hvar geymum við notandanafnið fyrir gagnagrunninn?"
• jinja: {{ jinja }} — nosql notype nosense mjúk plasticine. Það er alls staðar, jafnvel þar sem þú átt ekki von á því. Smá um !!unsafe og ljúffengt yaml.

Heimild: www.habr.com