Mimi hufanya hakiki nyingi za nambari zinazofaa za watu wengine na ninaandika mengi mwenyewe. Wakati wa kuchambua makosa (ya watu wengine na yangu mwenyewe), pamoja na mahojiano kadhaa, niligundua kosa kuu ambalo watumiaji wa Ansible hufanya - wanaingia kwenye mambo magumu bila kujua yale ya msingi.

Ili kurekebisha udhalimu huu wa ulimwengu wote, niliamua kuandika utangulizi wa Ansible kwa wale ambao tayari wanaijua. Ninakuonya, hii sio kurudia kwa mans, hii ni kusoma kwa muda mrefu na barua nyingi na hakuna picha.

Kiwango kinachotarajiwa cha msomaji ni kwamba mistari elfu kadhaa ya yamla tayari imeandikwa, kitu tayari kinatolewa, lakini "kwa njia fulani kila kitu kimepotoshwa."

Majina

Kosa kuu analofanya mtumiaji Ansible ni kutojua kitu kinaitwaje. Ikiwa hujui majina, huwezi kuelewa nyaraka zinasema nini. Mfano hai: wakati wa mahojiano, mtu ambaye alionekana kusema kwamba aliandika sana katika Ansible hakuweza kujibu swali "kitabu cha kucheza kinajumuisha vipengele gani?" Na nilipopendekeza kwamba "jibu lilitarajiwa kwamba kitabu cha kucheza kina mchezo," maoni ya kulaani "hatutumii hiyo" yalifuata. Watu wanaandika Ansible for money na hawatumii mchezo. Kwa kweli wanaitumia, lakini hawajui ni nini.

Basi hebu tuanze na kitu rahisi: inaitwa nini. Labda unajua hili, au labda hujui, kwa sababu haukuzingatia wakati unasoma nyaraka.

ansible-playbook hutekeleza kitabu cha kucheza. Kitabu cha kucheza ni faili iliyo na kiendelezi cha yml/yaml, ambacho ndani yake kuna kitu kama hiki:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Tayari tuligundua kuwa faili hii yote ni kitabu cha kucheza. Tunaweza kuonyesha mahali ambapo majukumu yapo na kazi ziko wapi. Lakini kucheza ni wapi? Na ni tofauti gani kati ya mchezo na jukumu au kitabu cha kucheza?

Yote yako kwenye nyaraka. Na wanakosa. Kompyuta - kwa sababu kuna mengi sana na hautakumbuka kila kitu mara moja. Uzoefu - kwa sababu "mambo madogo". Ikiwa una uzoefu, soma tena kurasa hizi angalau mara moja kila baada ya miezi sita, na msimbo wako utakuwa unaoongoza darasani.

Kwa hivyo, kumbuka: Playbook ni orodha inayojumuisha kucheza na import_playbook.
Huu ni mchezo mmoja:

- hosts: group1
  roles:
    - role1

na huu pia ni mchezo mwingine:

- hosts: group2,group3
  tasks:
    - debug:

Mchezo ni nini? Kwa nini yeye?

Kucheza ni kipengele muhimu cha kitabu cha kucheza, kwa sababu mchezo na igizo hushirikisha tu orodha ya majukumu na/au majukumu yenye orodha ya wapangishaji ambapo ni lazima yatekelezwe. Katika kina kirefu cha nyaraka unaweza kupata kutajwa delegate_to, programu jalizi za utafutaji wa ndani, mipangilio mahususi ya mtandao, wapangishi wa kuruka, n.k. Wanakuruhusu kubadilisha kidogo mahali ambapo kazi zinafanywa. Lakini, kusahau kuhusu hilo. Kila moja ya chaguzi hizi za busara zina matumizi maalum, na hakika sio ya ulimwengu wote. Na tunazungumzia mambo ya msingi ambayo kila mtu anapaswa kujua na kutumia.

Ikiwa unataka kufanya "kitu" "mahali fulani", unaandika kucheza. Sio jukumu. Sio jukumu la moduli na wajumbe. Unaichukua na kuandika kucheza. Ambayo, katika uwanja wa majeshi unaorodhesha wapi kutekeleza, na katika majukumu / kazi - nini cha kutekeleza.

Rahisi, sawa? Inawezaje kuwa vinginevyo?

Mojawapo ya nyakati za tabia ambapo watu wana hamu ya kufanya hivi sio kwa kucheza ni "jukumu linaloweka kila kitu." Ningependa kuwa na jukumu ambalo linasanidi seva zote za aina ya kwanza na seva za aina ya pili.

Mfano wa archetypal ni ufuatiliaji. Ningependa kuwa na jukumu la ufuatiliaji ambalo litasanidi ufuatiliaji. Jukumu la ufuatiliaji limepewa wasimamizi wa ufuatiliaji (kulingana na uchezaji). Lakini inabadilika kuwa kwa ufuatiliaji tunahitaji kuwasilisha vifurushi kwa waandaji ambao tunafuatilia. Kwa nini usitumie mjumbe? Pia unahitaji kusanidi iptables. mjumbe? Pia unahitaji kuandika/kusahihisha usanidi wa DBMS ili kuwezesha ufuatiliaji. mjumbe! Na ikiwa ubunifu haupo, basi unaweza kufanya ujumbe include_role katika kitanzi kilichowekwa kiota kwa kutumia kichujio cha hila kwenye orodha ya vikundi, na ndani include_role unaweza kufanya zaidi delegate_to tena. Na tunaenda mbali ...

Tamaa nzuri - kuwa na jukumu moja la ufuatiliaji, ambalo "hufanya kila kitu" - hutupeleka kwenye kuzimu kamili ambayo mara nyingi kuna njia moja tu ya kutoka: kuandika tena kila kitu kutoka mwanzo.

Kosa limetokea wapi hapa? Mara tu ulipogundua kuwa ili kufanya kazi "x" kwenye mwenyeji X ilibidi uende kukaribisha Y na kufanya "y" hapo, ilibidi ufanye zoezi rahisi: nenda na uandike mchezo, ambao kwa mwenyeji Y hufanya y. Usiongeze kitu kwa "x", lakini iandike kutoka mwanzo. Hata na vigeu vilivyowekwa ngumu.

Inaonekana kwamba kila kitu katika aya hapo juu kinasemwa kwa usahihi. Lakini hii sio kesi yako! Kwa sababu unataka kuandika msimbo unaoweza kutumika tena ambao ni KAVU na kama maktaba, na unahitaji kutafuta mbinu ya jinsi ya kuifanya.

Hapa ndipo kosa lingine kubwa linapojificha. Hitilafu ambayo iligeuza miradi mingi kutoka kwa maandishi kwa uvumilivu (inaweza kuwa bora, lakini kila kitu kinafanya kazi na ni rahisi kumaliza) kuwa hofu kamili ambayo hata mwandishi hawezi kufikiri. Inafanya kazi, lakini Mungu akuepushe na chochote.

Hitilafu ni: jukumu ni kazi ya maktaba. Ulinganisho huu umeharibu mwanzo mzuri sana hivi kwamba inasikitisha kutazama. Jukumu sio kazi ya maktaba. Hawezi kufanya hesabu na hawezi kufanya maamuzi ya kiwango cha kucheza. Nikumbushe ni maamuzi gani mchezo hufanya?

Asante, uko sahihi. Cheza hufanya uamuzi (kwa usahihi zaidi, ina taarifa) kuhusu kazi na majukumu ya kutekeleza kwa wapangishi gani.

Ukikabidhi uamuzi huu kwa jukumu, na hata kwa mahesabu, unajihukumu mwenyewe (na yule ambaye atajaribu kuchanganua nambari yako) kwa maisha duni. Jukumu haliamui ni wapi lifanyike. Uamuzi huu unafanywa na mchezo. Jukumu hufanya kile inachoambiwa, ambapo inaambiwa.

Kwa nini ni hatari kupanga katika Ansible na kwa nini COBOL ni bora kuliko Ansible tutazungumza katika sura kuhusu vigezo na jinja. Kwa sasa, hebu tuseme jambo moja - kila hesabu yako inaacha nyuma alama isiyofutika ya mabadiliko katika vigeu vya kimataifa, na huwezi kufanya lolote kulihusu. Mara tu "athari" hizo mbili zilipoingiliana, kila kitu kilikuwa kimekwenda.

Kumbuka kwa squeamish: jukumu linaweza kuathiri mtiririko wa udhibiti. Kula delegate_to na ina matumizi ya kuridhisha. Kula meta: end host/play. Lakini! Unakumbuka tunafundisha mambo ya msingi? Umesahau kuhusu delegate_to. Tunazungumza juu ya nambari rahisi na nzuri zaidi ya Ansible. Ambayo ni rahisi kusoma, rahisi kuandika, rahisi kutatua, rahisi kujaribu na rahisi kukamilisha. Kwa hivyo, kwa mara nyingine tena:

cheza na uchezaji pekee ndio unaoamua ni wapangishaji gani ni nini kitatekelezwa.

Katika sehemu hii, tulishughulikia upinzani kati ya mchezo na jukumu. Sasa hebu tuzungumze juu ya kazi dhidi ya uhusiano wa jukumu.

Kazi na Majukumu

Fikiria kucheza:

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

Wacha tuseme unahitaji kufanya foo. Na inaonekana kama foo: name=foobar state=present. Niandike wapi hii? kabla? chapisho? Je, ungependa kuunda jukumu?

...Na kazi zilienda wapi?

Tunaanza na mambo ya msingi tena - kifaa cha kucheza. Ikiwa utaelea juu ya suala hili, huwezi kutumia mchezo kama msingi wa kila kitu kingine, na matokeo yako yatakuwa "ya kutikisika".

Cheza kifaa: maagizo ya wapangishaji, mipangilio ya kucheza yenyewe na kazi_za awali, kazi, majukumu, sehemu za_majukumu. Vigezo vilivyobaki vya kucheza sio muhimu kwetu sasa.

Mpangilio wa sehemu zao na kazi na majukumu: pre_tasks, roles, tasks, post_tasks. Kwa kuwa kimantiki utaratibu wa utekelezaji ni kati tasks и roles haiko wazi, basi mbinu bora zinasema kwamba tunaongeza sehemu tasks, ikiwa sivyo roles... Kama ipo roles, basi kazi zote zilizounganishwa zimewekwa katika sehemu pre_tasks/post_tasks.

Kinachobaki ni kwamba kila kitu kiko wazi: kwanza pre_tasksbasi rolesbasi post_tasks.

Lakini bado hatujajibu swali: simu ya moduli iko wapi? foo andika? Je, tunahitaji kuandika jukumu zima kwa kila moduli? Au ni bora kuwa na jukumu nene kwa kila kitu? Na ikiwa sio jukumu, basi napaswa kuandika wapi - kabla au chapisho?

Ikiwa hakuna jibu la busara kwa maswali haya, basi hii ni ishara ya ukosefu wa angavu, ambayo ni, "misingi sawa" sawa. Hebu tufikirie. Kwanza, swali la usalama: Ikiwa mchezo una pre_tasks и post_tasks (na hakuna kazi au majukumu), basi kitu kinaweza kuvunjika ikiwa nitafanya kazi ya kwanza kutoka post_tasks Nitaisogeza hadi mwisho pre_tasks?

Bila shaka, maneno ya swali yanaonyesha kwamba itavunjika. Lakini nini hasa?

... Washikaji. Kusoma misingi kunaonyesha ukweli muhimu: vidhibiti vyote husafishwa kiotomatiki baada ya kila sehemu. Wale. kazi zote kutoka pre_tasks, kisha washikaji wote walioarifiwa. Kisha majukumu yote na wasimamizi wote ambao waliarifiwa katika majukumu wanatekelezwa. Baada ya post_tasks na washikaji wao.

Kwa hivyo, ikiwa utaburuta kazi kutoka post_tasks в pre_tasks, basi uwezekano utaitekeleza kabla ya kidhibiti kutekelezwa. kwa mfano, ikiwa ndani pre_tasks seva ya wavuti imewekwa na kusanidiwa, na post_tasks kitu kinatumwa kwake, kisha uhamishe kazi hii kwenye sehemu pre_tasks itasababisha ukweli kwamba wakati wa "kutuma" seva bado haifanyi kazi na kila kitu kitavunjika.

Sasa hebu tufikirie tena, kwa nini tunahitaji pre_tasks и post_tasks? Kwa mfano, ili kukamilisha kila kitu muhimu (ikiwa ni pamoja na washughulikiaji) kabla ya kutekeleza jukumu. A post_tasks itaturuhusu kufanya kazi na matokeo ya utekelezaji wa majukumu (pamoja na washughulikiaji).

Mtaalam mwenye akili timamu atatuambia ni nini. meta: flush_handlers, lakini kwa nini tunahitaji flush_handlers ikiwa tunaweza kutegemea utaratibu wa utekelezaji wa sehemu zinazochezwa? Zaidi ya hayo, matumizi ya meta: flush_handlers yanaweza kutupa vitu visivyotarajiwa na vishikilizi nakala, kutupa maonyo ya kushangaza inapotumiwa. when у block na kadhalika. Kadiri unavyojua vyema, ndivyo nuances zaidi unaweza kutaja kwa suluhisho la "gumu". Na suluhisho rahisi - kwa kutumia mgawanyiko wa asili kati ya kabla / majukumu / post - haina kusababisha nuances.

Na, kurudi kwa 'foo' wetu. Niweke wapi? Katika kabla, chapisho au majukumu? Ni wazi, hii inategemea ikiwa tunahitaji matokeo ya kidhibiti kwa foo. Ikiwa hazipo, basi foo haihitaji kuwekwa kabla au baada - sehemu hizi zina maana maalum - kutekeleza majukumu kabla na baada ya kikundi kikuu cha msimbo.

Sasa jibu la swali "jukumu au kazi" linakuja kwa kile ambacho tayari kinachezwa - ikiwa kuna kazi hapo, basi unahitaji kuziongeza kwenye kazi. Ikiwa kuna majukumu, unahitaji kuunda jukumu (hata kutoka kwa kazi moja). Acha nikukumbushe kwamba kazi na majukumu hayatumiwi kwa wakati mmoja.

Kuelewa misingi ya Ansible hutoa majibu ya busara kwa maswali yanayoonekana kuwa ya ladha.

Kazi na majukumu (sehemu ya pili)

Sasa hebu tujadili hali hiyo unapoanza kuandika kitabu cha kucheza. Unahitaji kutengeneza foo, bar na baz. Je, hizi ni kazi tatu, jukumu moja au majukumu matatu? Kwa muhtasari wa swali: ni wakati gani unapaswa kuanza kuandika majukumu? Kuna umuhimu gani wa kuandika majukumu wakati unaweza kuandika kazi?... Jukumu ni nini?

Mojawapo ya makosa makubwa (tayari nilizungumza juu ya hili) ni kufikiria kuwa jukumu ni kama kazi katika maktaba ya programu. Je, maelezo ya kazi ya jumla yanaonekanaje? Inakubali hoja za ingizo, inaingiliana na visababishi kando, haina athari, na inarudisha thamani.

Sasa, tahadhari. Nini kinaweza kufanywa kutoka kwa hii katika jukumu? Unakaribishwa kila wakati kuwaita madhara, hii ndiyo kiini cha Ansible nzima - kuunda madhara. Una sababu za upande? Msingi. Lakini kwa "pitisha thamani na uirudishe" - hapo haifanyi kazi. Kwanza, huwezi kupitisha thamani kwa jukumu. Unaweza kuweka kigezo cha kimataifa na ukubwa wa uchezaji wa maisha yote katika sehemu ya vars kwa jukumu. Unaweza kuweka kigezo cha kimataifa kwa kucheza maisha yote ndani ya jukumu. Au hata na maisha ya vitabu vya kucheza (set_fact/register) Lakini huwezi kuwa na "vigeu vya ndani". Huwezi "kuchukua thamani" na "kuirudisha".

Jambo kuu linafuata kutoka kwa hili: huwezi kuandika kitu katika Ansible bila kusababisha madhara. Kubadilisha vigeu vya kimataifa daima ni athari ya upande wa chaguo za kukokotoa. Katika kutu, kwa mfano, kubadilisha variable kimataifa ni unsafe. Na katika Ansible ndio njia pekee ya kushawishi maadili ya jukumu. Kumbuka maneno yaliyotumiwa: sio "kupitisha thamani kwa jukumu", lakini "badilisha maadili ambayo jukumu linatumia". Hakuna kutengwa kati ya majukumu. Hakuna kutengwa kati ya kazi na majukumu.

Jumla: jukumu si kazi.

Nini nzuri kuhusu jukumu? Kwanza, jukumu lina maadili chaguo-msingi (/default/main.yaml), pili, jukumu lina saraka za ziada za kuhifadhi faili.

Je, ni faida gani za maadili chaguo-msingi? Kwa sababu katika piramidi ya Maslow, jedwali potofu la Ansible la vipaumbele tofauti, chaguo-msingi za jukumu ndizo zilizopewa kipaumbele cha chini zaidi (ondoa vigezo vya mstari wa amri Ansible). Hii ina maana kwamba ikiwa unahitaji kutoa thamani chaguo-msingi na usiwe na wasiwasi kuzihusu zikipuuza thamani kutoka kwa hesabu au vigeu vya kikundi, basi chaguo-msingi za majukumu ndio mahali pekee panapokufaa. (Ninadanganya kidogo - kuna zaidi |d(your_default_here), lakini ikiwa tunazungumza juu ya maeneo ya stationary, basi chaguo-msingi za jukumu tu).

Nini kingine ni nzuri kuhusu majukumu? Kwa sababu wana katalogi zao. Hizi ni saraka za vigeu, vyote vya mara kwa mara (yaani vilivyohesabiwa kwa jukumu) na vinavyobadilika (kuna muundo au muundo wa kipingamizi - include_vars na {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Hizi ndizo saraka za files/, templates/. Pia, hukuruhusu kuwa na moduli zako na programu-jalizi (library/) Lakini, kwa kulinganisha na kazi katika kitabu cha kucheza (ambacho kinaweza pia kuwa na haya yote), faida pekee hapa ni kwamba faili hazitupwa kwenye rundo moja, lakini piles kadhaa tofauti.

Maelezo moja zaidi: unaweza kujaribu kuunda majukumu ambayo yatapatikana kwa matumizi tena (kupitia galaksi). Pamoja na ujio wa makusanyo, usambazaji wa jukumu unaweza kuchukuliwa kuwa karibu kusahau.

Kwa hivyo, majukumu yana vipengele viwili muhimu: yana chaguo-msingi (kipengele cha kipekee) na hukuruhusu kupanga msimbo wako.

Kurudi kwa swali la asili: wakati wa kufanya kazi na wakati wa kufanya majukumu? Majukumu katika kitabu cha kucheza mara nyingi hutumika kama "gundi" kabla/baada ya majukumu, au kama kipengele cha ujenzi huru (basi kusiwe na majukumu katika msimbo). Rundo la kazi za kawaida zilizochanganywa na majukumu ni uzembe usio na utata. Unapaswa kuambatana na mtindo maalum - ama kazi au jukumu. Majukumu hutoa mgawanyo wa huluki na chaguo-msingi, kazi hukuruhusu kusoma msimbo haraka zaidi. Kawaida, msimbo zaidi wa "stationary" (muhimu na ngumu) huwekwa katika majukumu, na maandishi ya msaidizi yameandikwa kwa mtindo wa kazi.

Inawezekana kufanya import_role kama kazi, lakini ukiandika hii, basi uwe tayari kuelezea hisia zako za uzuri kwa nini unataka kufanya hivi.

Msomaji mahiri anaweza kusema kuwa majukumu yanaweza kuagiza majukumu, majukumu yanaweza kuwa na utegemezi kupitia galaxy.yml, na pia kuna hali mbaya na ya kutisha. include_role - Ninakukumbusha kwamba tunaboresha ujuzi katika Ansible ya msingi, na sio katika gymnastics ya takwimu.

Washughulikiaji na kazi

Wacha tujadili jambo lingine dhahiri: washughulikiaji. Kujua jinsi ya kuzitumia kwa usahihi ni karibu sanaa. Kuna tofauti gani kati ya mshikaji na buruta?

Kwa kuwa tunakumbuka mambo ya msingi, hapa kuna mfano:

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

Wasimamizi wa jukumu wanapatikana katika rolename/handlers/main.yaml. Vishikilizi hupekua kati ya washiriki wote wa igizo: kazi za kabla/baada zinaweza kuvuta vidhibiti, na jukumu linaweza kuwavuta vidhibiti kutoka kwenye igizo. Walakini, simu za "jukumu-jukumu" kwa washughulikiaji husababisha wtf zaidi kuliko kurudia kidhibiti kidogo. (Kipengele kingine cha mazoea bora ni kujaribu kutorudia majina ya washughulikiaji).

Tofauti kuu ni kwamba kazi hiyo inatekelezwa kila wakati (bila kujali) (plus/minus tags na when), na mshughulikiaji - kwa mabadiliko ya hali (arifu moto tu ikiwa imebadilishwa). Hii ina maana gani? Kwa mfano, ukweli kwamba unapoanza upya, ikiwa hapakuwa na mabadiliko, basi hakutakuwa na mtoaji. Kwa nini inaweza kuwa kwamba tunahitaji kutekeleza kidhibiti wakati hakukuwa na mabadiliko katika kazi ya kutengeneza? Kwa mfano, kwa sababu kitu kilivunjika na kubadilika, lakini utekelezaji haukufika kwa mtunzi. Kwa mfano, kwa sababu mtandao ulikuwa chini kwa muda. Usanidi umebadilika, huduma haijaanzishwa tena. Wakati mwingine unapoianzisha, usanidi haubadilika tena, na huduma inabaki na toleo la zamani la usanidi.

Hali na usanidi haiwezi kutatuliwa (kwa usahihi zaidi, unaweza kuvumbua itifaki maalum ya kuanzisha upya mwenyewe na bendera za faili, nk, lakini hii "haifai tena" kwa njia yoyote). Lakini kuna hadithi nyingine ya kawaida: tuliweka programu, tukairekodi .service-file, na sasa tunaitaka daemon_reload и state=started. Na mahali pa asili kwa hii inaonekana kuwa mtoaji. Lakini ikiwa hutaifanya kuwa kidhibiti lakini kazi mwishoni mwa orodha ya kazi au jukumu, basi itatekelezwa bila mpangilio kila wakati. Hata kama kitabu cha kucheza kilivunjika katikati. Hii haisuluhishi shida iliyoanzishwa tena (huwezi kufanya kazi na sifa iliyoanzishwa tena, kwa sababu ufahamu umepotea), lakini inafaa kufanya hali = ilianza, utulivu wa jumla wa vitabu vya kucheza huongezeka, kwa sababu. idadi ya viunganisho na hali ya nguvu hupungua.

Sifa nyingine nzuri ya kidhibiti ni kwamba haizibi pato. Hakukuwa na mabadiliko - hakuna ziada iliyorukwa au sawa katika matokeo - rahisi kusoma. Pia ni mali hasi - ikiwa utapata typo katika kazi iliyotekelezwa kwa mstari kwenye kukimbia kwa kwanza, basi washughulikiaji watatekelezwa tu wakati wa kubadilishwa, i.e. chini ya hali fulani - mara chache sana. Kwa mfano, kwa mara ya kwanza katika maisha yangu miaka mitano baadaye. Na, bila shaka, kutakuwa na typo kwa jina na kila kitu kitavunjika. Na ikiwa hautaziendesha mara ya pili, hakuna mabadiliko.

Tofauti, tunahitaji kuzungumza juu ya upatikanaji wa vigezo. Kwa mfano, ikiwa utaarifu kazi na kitanzi, ni nini kitakuwa katika vigezo? Unaweza kukisia kwa uchanganuzi, lakini sio jambo la maana kila wakati, haswa ikiwa vigezo vinatoka sehemu tofauti.

... Kwa hivyo washikaji sio muhimu sana na wana shida zaidi kuliko wanavyoonekana. Ikiwa unaweza kuandika kitu kwa uzuri (bila frills) bila washughulikiaji, ni bora kuifanya bila wao. Ikiwa haifanyi kazi kwa uzuri, ni bora pamoja nao.

Msomaji babuzi anaonyesha sawa kwamba hatujajadili listenkwamba kidhibiti kinaweza kupiga simu arifu kwa kidhibiti kingine, kwamba kidhibiti kinaweza kujumuisha import_tasks (ambazo zinaweza kujumuisha_jukumu na with_items), kwamba mfumo wa kidhibiti katika Ansible ni Turing-complete, ambao vidhibiti kutoka kujumuisha_role hupishana kwa njia ya kudadisi na vidhibiti kutoka kwa kucheza, nk. .d. - yote haya ni wazi sio "misingi").

Ingawa kuna WTF moja mahususi ambayo kwa kweli ni kipengele ambacho unahitaji kukumbuka. Ikiwa kazi yako inatekelezwa na delegate_to na imearifu, basi kidhibiti kinacholingana kinatekelezwa bila delegate_to, i.e. kwa mwenyeji ambapo mchezo umetolewa. (Ingawa mshughulikiaji, kwa kweli, anaweza kuwa nayo delegate_to Sawa).

Kando, nataka kusema maneno machache kuhusu majukumu yanayoweza kutumika tena. Kabla ya makusanyo kuonekana, kulikuwa na wazo kwamba unaweza kufanya majukumu ya ulimwengu ambayo inaweza kuwa ansible-galaxy install akaenda. Inafanya kazi kwenye OS zote za anuwai zote katika hali zote. Kwa hiyo, maoni yangu: haifanyi kazi. Jukumu lolote na wingi include_vars, inayoauni kesi 100500, itakabiliwa na matatizo mengi. Zinaweza kufunikwa na majaribio makubwa, lakini kama ilivyo kwa jaribio lolote, ama una bidhaa ya Cartesian ya thamani za ingizo na utendaji kamili, au una "matukio ya mtu binafsi." Maoni yangu ni kwamba ni bora zaidi ikiwa jukumu ni la mstari (ugumu wa cyclomatic 1).

Ikiwa chache (za wazi au za kutangaza - katika fomu when au fomu include_vars kwa seti ya anuwai), jukumu bora. Wakati mwingine unapaswa kufanya matawi, lakini, narudia, wachache kuna, ni bora zaidi. Kwa hivyo inaonekana kama jukumu zuri na gala (inafanya kazi!) Na rundo la when inaweza kuwa ya chini zaidi kuliko jukumu la "mtu" kutoka kwa kazi tano. Wakati ambapo jukumu na gala ni bora ni wakati unapoanza kuandika kitu. Wakati unapozidi kuwa mbaya zaidi ni wakati kitu kinapovunjika na una shaka kuwa ni kwa sababu ya "jukumu na gala". Unaifungua, na kuna majumuisho matano, karatasi nane za kazi na stack when'ov... Na tunahitaji kufikiri hili. Badala ya kazi 5, orodha ya mstari ambayo hakuna kitu cha kuvunja.

Katika sehemu zifuatazo

• Kidogo kuhusu hesabu, vigezo vya kikundi, programu-jalizi ya host_group_vars, hostvars. Jinsi ya kufunga fundo la Gordian na tambi. Vigezo vya upeo na utangulizi, Mfano wa kumbukumbu unaofaa. "Kwa hivyo tunahifadhi wapi jina la mtumiaji la hifadhidata?"
• jinja: {{ jinja }} - nosql nosense nosense laini ya plastiki. Iko kila mahali, hata mahali ambapo hautarajii. kidogo kuhusu !!unsafe na yaml ladha.

Chanzo: mapenzi.com