ProHoster > Blogs > Administrācija > Iespējamie pamati, bez kuriem jūsu rokasgrāmatas būs lipīgu makaronu gabals

Iespējamie pamati, bez kuriem jūsu rokasgrāmatas būs lipīgu makaronu gabals

Es daudz pārskatu citu cilvēku Ansible kodu un daudz rakstu pats. Analizējot kļūdas (gan citu, gan manas), kā arī vairākās intervijās, es sapratu galveno kļūdu, ko pieļauj Ansible lietotāji - viņi iekļūst sarežģītās lietās, neapgūstot pamata.

Lai labotu Å”o universālo netaisnÄ«bu, es nolēmu uzrakstÄ«t ievadu Ansible tiem, kas to jau zina. BrÄ«dinu, tas nav pārstāsts par cilvēkiem, tas ir sens lasāms raksts ar daudz burtiem un bez bildēm.

Sagaidāmais lasītāja līmenis ir tāds, ka jau ir uzrakstīti vairāki tūkstoŔi jamlas rindu, kaut kas jau tiek ražots, bet "kaut kā viss ir greizs".

Vārdi

Galvenā Ansible lietotāja kļūda ir neziņa, kā kaut ko sauc. Ja jÅ«s nezināt nosaukumus, jÅ«s nevarat saprast, kas teikts dokumentācijā. DzÄ«vs piemērs: intervijas laikā cilvēks, kurÅ”, Ŕķiet, teica, ka daudz rakstÄ«jis Anible, nevarēja atbildēt uz jautājumu ā€œno kādiem elementiem sastāv rotaļu grāmata?ā€ Un, kad es ierosināju, ka ā€œtika gaidÄ«ta atbilde, ka rokasgrāmata sastāv no spēlesā€, sekoja nosodoÅ”s komentārs ā€œmēs to neizmantojamā€. Cilvēki raksta Ansible naudas dēļ un neizmanto spēli. Viņi to faktiski izmanto, bet nezina, kas tas ir.

Tātad, sāksim ar kaut ko vienkārÅ”u: kā to sauc. VarbÅ«t jÅ«s to zināt vai varbÅ«t nezināt, jo jÅ«s, lasot dokumentāciju, nepievērsāt uzmanÄ«bu.

ansible-playbook izpilda rokasgrāmatu. Rokasgrāmata ir fails ar yml/yaml paplaÅ”inājumu, kura iekÅ”pusē ir kaut kas lÄ«dzÄ«gs Å”im:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Mēs jau sapratām, ka viss Å”is fails ir rokasgrāmata. Mēs varam parādÄ«t, kur ir lomas un kur ir uzdevumi. Bet kur ir spēle? Un kāda ir atŔķirÄ«ba starp spēli un lomu vai rotaļu grāmatu?

Tas viss ir dokumentācijā. Un viņiem tas pietrÅ«kst. Iesācēji - jo to ir pārāk daudz un jÅ«s neatcerēsities visu uzreiz. Pieredzējis - jo ā€œtriviālas lietasā€. Ja esat pieredzējis, atkārtoti izlasiet Ŕīs lapas vismaz reizi seÅ”os mēneÅ”os, un jÅ«su kods kļūs par klases vadoÅ”o.

Tātad, atcerieties: Playbook ir saraksts, kas sastāv no spēles un import_playbook.
Å Ä« ir viena luga:

- hosts: group1
  roles:
    - role1

un Ŕī ir arī cita luga:

- hosts: group2,group3
  tasks:
    - debug:

Kas ir spēlÄ“Å”ana? Kāpēc viņa ir?

Spēle ir spēles grāmatas galvenais elements, jo spēle un tikai spēle saista lomu un/vai uzdevumu sarakstu ar resursdatoru sarakstu, kuros tie jāizpilda. Dokumentācijas dziļumos jÅ«s varat atrast pieminējumu par delegate_to, lokālie uzmeklÄ“Å”anas spraudņi, tÄ«klam raksturÄ«gi iestatÄ«jumi, pārejas saimniekdatori utt. Tie ļauj nedaudz mainÄ«t vietu, kur tiek veikti uzdevumi. Bet aizmirsti par to. Katrai no Ŕīm gudrajām iespējām ir ļoti specifisks lietojums, un tās noteikti nav universālas. Un mēs runājam par pamata lietām, kas bÅ«tu jāzina un jāizmanto ikvienam.

Ja vēlaties izpildÄ«t ā€œkaut koā€ ā€œkaut kurā€, tu raksti lugu. Nav loma. Nav loma ar moduļiem un delegātiem. Tu ņem to un raksti lugu. Kurā laukā hosts jÅ«s uzskaitāt, kur izpildÄ«t, un lomās/uzdevumos - ko izpildÄ«t.

VienkārÅ”i, vai ne? Kā gan varētu bÅ«t savādāk?

Viens no raksturÄ«gākajiem brīžiem, kad cilvēkiem rodas vēlme to darÄ«t nevis rotaļājoties, ir ā€œloma, kas visu nosakaā€. Es vēlētos iegÅ«t lomu, kas konfigurē gan pirmā tipa serverus, gan otrā tipa serverus.

Arhetipisks piemērs ir monitorings. Es vēlētos iegÅ«t uzraudzÄ«bas lomu, kas konfigurēs uzraudzÄ«bu. UzraudzÄ«bas loma tiek pieŔķirta uzraudzÄ«bas saimniekiem (saskaņā ar spēli). Bet izrādās, ka uzraudzÄ«bai mums ir jāpiegādā paketes saimniekiem, kurus mēs uzraugām. Kāpēc neizmantot delegātu? Jums arÄ« jākonfigurē iptables. deleģēt? Lai iespējotu uzraudzÄ«bu, jums arÄ« jāraksta/jālabo DBVS konfigurācija. deleģēt! Un, ja trÅ«kst radoÅ”uma, tad varat izveidot delegāciju include_role ligzdotā cilpā, izmantojot sarežģītu filtru grupu sarakstā un iekÅ”pusē include_role jÅ«s varat darÄ«t vairāk delegate_to atkal. Un mēs ejam prom...

Laba vēlme - būt vienai uzraudzības lomai, kas "dara visu" - ieved mūs pilnīgā ellē, no kuras visbiežāk ir tikai viena izeja: pārrakstīt visu no nulles.

Kur Å”eit radās kļūda? BrÄ«dÄ«, kad atklājāt, ka, lai veiktu uzdevumu ā€œxā€ resursdatorā X, ir jādodas uz saimniekdatoru Y un jāveic ā€œyā€ tur, jums bija jāveic vienkārÅ”s uzdevums: jāiet un jāuzraksta atskaņoÅ”ana, ko resursdatorā Y veic y. Nepievienojiet kaut ko "x", bet rakstiet to no nulles. Pat ar cietā kodiem mainÄ«gajiem.

Å Ä·iet, ka viss iepriekÅ” minētajās rindkopās ir pateikts pareizi. Bet tas nav tavs gadÄ«jums! Jo jÅ«s vēlaties rakstÄ«t atkārtoti lietojamu kodu, kas ir DRY un bibliotēkai lÄ«dzÄ«gs, un jums ir jāmeklē metode, kā to izdarÄ«t.

Å eit slēpjas vēl viena nopietna kļūda. Kļūda, kas daudzus projektus no pieļaujami uzrakstÄ«tiem (varētu bÅ«t labāk, bet viss strādā un ir viegli pabeigt) pārvērta par pilnÄ«gām Å”ausmām, kuras pat autors nevar izdomāt. Tas darbojas, bet nedod Dievs kaut ko mainÄ«t.

Kļūda ir Ŕāda: loma ir bibliotēkas funkcija. Å Ä« lÄ«dzÄ«ba ir izpostÄ«jusi tik daudz labu sākumu, ka to ir vienkārÅ”i skumji skatÄ«ties. Loma nav bibliotēkas funkcija. Viņa nevar veikt aprēķinus un nevar pieņemt spēles lÄ«meņa lēmumus. Atgādināt man, kādus lēmumus pieņem spēle?

Paldies, tev taisnība. Play pieņem lēmumu (precīzāk, tajā ir informācija) par to, kādus uzdevumus un lomas veikt uz kuriem saimniekiem.

Ja jÅ«s deleģējat Å”o lēmumu kādai lomai un pat ar aprēķiniem, jÅ«s nolemjat sevi (un to, kurÅ” mēģinās parsēt jÅ«su kodu) nožēlojamai eksistencei. Loma neizlemj, kur tā tiek izpildÄ«ta. Å o lēmumu pieņem spēle. Loma dara to, ko tai saka, kur tā saka.

Kāpēc ir bÄ«stami programmēt Ansible un kāpēc COBOL ir labāks par Ansible, mēs runāsim nodaļā par mainÄ«gajiem un džindzām. Pagaidām teiksim vienu ā€“ katrs jÅ«su aprēķins atstāj aiz sevis neizdzÄ“Å”amas globālo mainÄ«go izmaiņu pēdas, un jÅ«s neko nevarat darÄ«t lietas labā. TiklÄ«dz abas ā€œpēdasā€ krustojās, viss bija pazudis.

PiezÄ«me čīkstētājiem: loma noteikti var ietekmēt kontroles plÅ«smu. Ēst delegate_to un tam ir saprātÄ«gs lietojums. Ēst meta: end host/play. Bet! Atcerieties, ka mēs mācām pamatus? Aizmirsu par delegate_to. Mēs runājam par vienkārŔāko un skaistāko Ansible kodu. Kuru ir viegli lasÄ«t, viegli rakstÄ«t, viegli atkļūdot, viegli pārbaudÄ«t un viegli pabeigt. Tātad, vēlreiz:

spēlēt un tikai spēle izlemj, kurÅ” saimnieks kas tiek izpildÄ«ts.

Šajā sadaļā mēs aplūkojām spēles un lomas pretestību. Tagad parunāsim par uzdevumu un lomu attiecībām.

Uzdevumi un lomas

Apsveriet spēli:

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

Pieņemsim, ka jums ir jādara foo. Un tā izskatās foo: name=foobar state=present. Kur man tas būtu jāraksta? in pre? pastu? Vai izveidot lomu?

...Un kur palika uzdevumi?

Mēs atkal sākam ar pamatlietām - atskaņoÅ”anas ierÄ«ci. Ja jÅ«s peldat par Å”o jautājumu, jÅ«s nevarat izmantot spēli kā pamatu visam pārējam, un jÅ«su rezultāts bÅ«s "trÄ«coÅ”s".

AtskaņoÅ”anas ierÄ«ce: saimniekdatora direktÄ«va, paÅ”as spēles iestatÄ«jumi un pre_tasks, uzdevumi, lomas, post_tasks sadaļas. AtlikuÅ”ie spēles parametri mums Å”obrÄ«d nav svarÄ«gi.

Viņu sadaļu secÄ«ba ar uzdevumiem un lomām: pre_tasks, roles, tasks, post_tasks. Tā kā semantiski izpildes secÄ«ba ir starp tasks Šø roles nav skaidrs, tad paraugprakse saka, ka mēs pievienojam sadaļu tasks, tikai tad, ja nē roles... Ja tur ir roles, tad visi pievienotie uzdevumi tiek ievietoti sadaļās pre_tasks/post_tasks.

Atliek tikai, ka viss ir semantiski skaidrs: pirmkārt pre_taskstad rolestad post_tasks.

Bet mēs joprojām neesam atbildējuÅ”i uz jautājumu: kur ir moduļa izsaukums? foo rakstÄ«t? Vai katram modulim ir jāraksta visa loma? Vai arÄ« labāk ir bieza loma visam? Un ja ne lomu, tad kur lai raksta - pre vai post?

Ja uz Å”iem jautājumiem nav pamatotas atbildes, tad tā liecina par intuÄ«cijas trÅ«kumu, tas ir, to paÅ”u "trÄ«cÄ«go pamatu". Izdomāsim. Pirmkārt, droŔības jautājums: ja spēlē ir pre_tasks Šø post_tasks (un nav uzdevumu vai lomu), tad var kaut kas salÅ«zt, ja izpildu pirmo uzdevumu no post_tasks Es to pārcelÅ”u uz beigām pre_tasks?

Protams, jautājuma formulējums liecina, ka tas salÅ«zÄ«s. Bet ko tieÅ”i?

... Apdarinātāji. Izlasot pamatinformāciju, atklājas svarīgs fakts: visi apstrādātāji tiek automātiski izskaloti pēc katras sadaļas. Tie. visi uzdevumi no pre_tasks, pēc tam visi apstrādātāji, kuriem tika paziņots. Pēc tam tiek izpildītas visas lomas un visi apstrādātāji, par kuriem tika paziņots lomās. Pēc post_tasks un to apstrādātāji.

Tādējādi, ja velkat uzdevumu no post_tasks Š² pre_tasks, tad, iespējams, jÅ«s to izpildÄ«sit pirms apdarinātāja izpildes. piemēram, ja iekŔā pre_tasks tÄ«mekļa serveris ir instalēts un konfigurēts, un post_tasks tai kaut kas tiek nosÅ«tÄ«ts, pēc tam pārsÅ«tiet Å”o uzdevumu uz sadaļu pre_tasks novedÄ«s pie tā, ka ā€œsÅ«tÄ«Å”anasā€ laikā serveris vēl nedarbosies un viss sabojāsies.

Tagad padomāsim vēlreiz, kāpēc mums tas ir vajadzÄ«gs pre_tasks Šø post_tasks? Piemēram, lai pabeigtu visu nepiecieÅ”amo (arÄ« hendlerus) pirms lomas izpildes. A post_tasks ļaus mums strādāt ar lomu izpildes rezultātiem (ieskaitot apstrādātājus).

AsprātÄ«gs Ansible eksperts mums pastāstÄ«s, kas tas ir. meta: flush_handlers, bet kāpēc mums ir vajadzÄ«gi flush_handlers, ja mēs varam paļauties uz sekciju izpildes secÄ«bu spēlē? Turklāt meta: flush_handlers izmantoÅ”ana var sniegt mums negaidÄ«tas lietas ar dublētiem apstrādātājiem, sniedzot dÄ«vainus brÄ«dinājumus when у block utt. Jo labāk jÅ«s zināt iespējamos risinājumus, jo vairāk nianses varat nosaukt "kutenÄ«gam" risinājumam. Un vienkārÅ”s risinājums ā€“ izmantojot dabisku sadalÄ«jumu starp pirms/lomām/post ā€“ nianses nerada.

Un atpakaļ pie mÅ«su ā€œfooā€. Kur man to likt? Pirms, amatā vai lomās? AcÄ«mredzot tas ir atkarÄ«gs no tā, vai mums ir nepiecieÅ”ami foo apstrādātāja rezultāti. Ja to nav, tad foo nav jāievieto ne pirms, ne pēc - Ŕīm sadaļām ir Ä«paÅ”a nozÄ«me - uzdevumu izpilde pirms un pēc koda galvenā korpusa.

Tagad atbilde uz jautājumu ā€œloma vai uzdevumsā€ ir saistÄ«ta ar to, kas jau ir spēlē - ja tur ir uzdevumi, tad tie jāpievieno uzdevumiem. Ja ir lomas, jums ir jāizveido loma (kaut vai no viena uzdevuma). AtgādināŔu, ka uzdevumi un lomas netiek izmantoti vienlaikus.

Izpratne par Ansible pamatiem sniedz pamatotas atbildes uz Ŕķietami gaumes jautājumiem.

Uzdevumi un lomas (otrā daļa)

Tagad apspriedÄ«sim situāciju, kad jÅ«s tikko sākat rakstÄ«t rokasgrāmatu. Vajag taisÄ«t foo, bar un baz. Vai Å”ie trÄ«s uzdevumi ir viena loma vai trÄ«s lomas? Rezumējot jautājumu: kurā brÄ«dÄ« jāsāk rakstÄ«t lomas? Kāda jēga rakstÄ«t lomas, ja var rakstÄ«t uzdevumus?... Kas ir loma?

Viena no lielākajām kļūdām (es par to jau runāju) ir domāt, ka loma ir kā funkcija programmas bibliotēkā. Kā izskatās vispārīgs funkcijas apraksts? Tā pieņem ievades argumentus, mijiedarbojas ar blakuscēloņiem, rada blakusparādības un atgriež vērtību.

Tagad uzmanÄ«bu. Ko no tā var izdarÄ«t lomā? JÅ«s vienmēr esat laipni aicināti saukt par blakusefektiem, tā ir visa Ansible bÅ«tÄ«ba - radÄ«t blakusparādÄ«bas. Vai ir blakus cēloņi? Elementāri. Bet ar "nododiet vērtÄ«bu un atdodiet to" - tas ir, kur tas nedarbojas. Pirmkārt, lomai nevar nodot vērtÄ«bu. Lomas sadaļā Vars varat iestatÄ«t globālu mainÄ«go ar spēlÄ“Å”anas ilgumu. Lomā varat iestatÄ«t globālu mainÄ«go, kas darbojas visu mūžu. Vai pat ar rokasgrāmatu kalpoÅ”anas laiku (set_fact/register). Bet jums nevar bÅ«t "vietējie mainÄ«gie". JÅ«s nevarat "paņemt vērtÄ«bu" un "atgriezt to".

Galvenais no tā izriet: jÅ«s nevarat kaut ko uzrakstÄ«t Ansible, neradot blakusparādÄ«bas. Globālo mainÄ«go maiņa vienmēr ir funkcijas blakusefekts. Piemēram, Rustā globālā mainÄ«gā mainÄ«Å”ana ir unsafe. Un Ansible tā ir vienÄ«gā metode, kā ietekmēt lomas vērtÄ«bas. Ņemiet vērā lietotos vārdus: nevis "nodot lomai vērtÄ«bu", bet "mainÄ«t lomas izmantotās vērtÄ«bas". Starp lomām nav izolācijas. Starp uzdevumiem un lomām nav izolācijas.

Kopā: loma nav funkcija.

Kas Å”ajā lomā ir labs? Pirmkārt, lomai ir noklusējuma vērtÄ«bas (/default/main.yaml), otrkārt, lomai ir papildu direktoriji failu glabāŔanai.

Kādas ir noklusējuma vērtÄ«bu priekÅ”rocÄ«bas? Tā kā Maslova piramÄ«dā, Ansible diezgan izkropļotajā mainÄ«go prioritāŔu tabulā, lomu noklusējumiem ir viszemākā prioritāte (atskaitot Ansible komandrindas parametrus). Tas nozÄ«mē, ka, ja jums ir jānorāda noklusējuma vērtÄ«bas un nav jāuztraucas par to, ka tās ignorēs krājumu vai grupu mainÄ«go vērtÄ«bas, lomu noklusējuma vērtÄ«bas ir jums vienÄ«gā Ä«stā vieta. (Nedaudz meloju - ir vēl |d(your_default_here), bet, ja runājam par stacionārām vietām, tad tikai lomu noklusējuma).

Kas vēl ir lielisks lomās? Jo viņiem ir savi katalogi. Tie ir direktoriji mainÄ«gajiem lielumiem, gan nemainÄ«giem (t.i., aprēķinātiem lomai), gan dinamiskiem (ir vai nu modelis, vai pretmodelis - include_vars ar {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Å ie ir katalogi files/, templates/. Tas arÄ« ļauj jums izveidot savus moduļus un spraudņus (library/). Bet, salÄ«dzinot ar uzdevumiem rokasgrāmatā (kurā var bÅ«t arÄ« tas viss), vienÄ«gais labums Å”eit ir tas, ka faili netiek sabērti vienā kaudzē, bet gan vairākās atseviŔķās kaudzÄ«tēs.

Vēl viena detaļa: varat mēģināt izveidot lomas, kas bÅ«s pieejamas atkārtotai izmantoÅ”anai (izmantojot galaktiku). LÄ«dz ar kolekciju parādÄ«Å”anos lomu sadalÄ«jumu var uzskatÄ«t par gandrÄ«z aizmirstu.

Tādējādi lomām ir divas svarīgas funkcijas: tām ir noklusējuma iestatījumi (unikāla funkcija), un tās ļauj strukturēt kodu.

Atgriežoties pie sākotnējā jautājuma: kad veikt uzdevumus un kad pildÄ«t lomas? Uzdevumi rotaļu grāmatā visbiežāk tiek izmantoti vai nu kā ā€œlÄ«meā€ pirms/pēc lomām, vai arÄ« kā neatkarÄ«gs bÅ«ves elements (tad kodā lomām nevajadzētu bÅ«t). Normālu uzdevumu kaudze, kas sajaukta ar lomām, ir nepārprotama pavirŔība. Jums vajadzētu pieturēties pie noteikta stila - vai nu uzdevuma, vai lomas. Lomas nodroÅ”ina entÄ«tiju un noklusējuma atdalÄ«Å”anu, uzdevumi ļauj ātrāk lasÄ«t kodu. Parasti lomās tiek ievietots ā€œstacionārāksā€ (svarÄ«gāks un sarežģītāks) kods, un palÄ«gskripti tiek rakstÄ«ti uzdevuma stilā.

Ir iespējams veikt import_role kā uzdevumu, bet, ja rakstāt Å”o, tad esiet gatavs izskaidrot savai skaistuma izjÅ«tai, kāpēc vēlaties to darÄ«t.

AsprātÄ«gs lasÄ«tājs var teikt, ka lomas var importēt lomas, lomām var bÅ«t atkarÄ«bas, izmantojot galaxy.yml, un ir arÄ« Å”ausmÄ«gs un briesmÄ«gs include_role ā€” Atgādinu, ka pilnveidojam iemaņas pamata Ansible, nevis daiļvingroÅ”anā.

Vadītāji un uzdevumi

ApspriedÄ«sim vēl vienu acÄ«mredzamu lietu: hendleri. Zināt, kā tos pareizi lietot, ir gandrÄ«z māksla. Kāda ir atŔķirÄ«ba starp hendleri un vilkÅ”anu?

Tā kā mēs atceramies pamatus, Å”eit ir piemērs:

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

Lomas apstrādātāji atrodas failā rolename/handlers/main.yaml. Apdarinātāji rakņājas starp visiem spēles dalÄ«bniekiem: pirms/pēc_uzdevumi var izvilkt lomu apdarinātājus, un loma var izvilkt apdarinātājus no spēles. Tomēr "savstarpēju lomu" zvani apstrādātājiem rada daudz vairāk wtf nekā triviāla apdarinātāja atkārtoÅ”ana. (Vēl viens paraugprakses elements ir mēģināt neatkārtot apstrādātāju vārdus).

Galvenā atŔķirÄ«ba ir tā, ka uzdevums vienmēr tiek izpildÄ«ts (idempotenciāli) (plus/mÄ«nus atzÄ«mes un when), un apstrādātājs - pēc stāvokļa maiņas (ziņot par ugunsgrēkiem tikai tad, ja tas ir mainÄ«ts). Ko tas nozÄ«mē? Piemēram, to, ka, restartējot, ja nekas nav mainÄ«ts, tad arÄ« apstrādātāja nebÅ«s. Kāpēc mums ir jāizpilda apdarinātājs, ja Ä£enerējoÅ”ais uzdevums nav mainÄ«jies? Piemēram, tāpēc, ka kaut kas salÅ«za un mainÄ«jās, bet izpilde nesasniedza apstrādātāju. Piemēram, tāpēc, ka tÄ«kls Ä«slaicÄ«gi nedarbojās. Konfigurācija ir mainÄ«ta, pakalpojums nav restartēts. Nākamajā reizē, kad to startējat, konfigurācija vairs nemainās, un pakalpojums paliek vecajā konfigurācijas versijā.

Situāciju ar konfigurāciju nevar atrisināt (precÄ«zāk, var pats izdomāt speciālu restartÄ“Å”anas protokolu ar failu karodziņiem utt., bet tas vairs nav 'pamata iespēja' nekādā veidā). Bet ir vēl viens izplatÄ«ts stāsts: mēs instalējām lietojumprogrammu, ierakstÄ«jām to .service-failu, un tagad mēs to vēlamies daemon_reload Šø state=started. Un Ŕķiet, ka dabiskā vieta tam ir apstrādātājs. Bet, ja jÅ«s padarāt to nevis par apdarinātāju, bet gan par uzdevumu uzdevumu saraksta vai lomas beigās, tas katru reizi tiks izpildÄ«ts idempotenciāli. Pat ja rokasgrāmata salÅ«za vidÅ«. Tas nemaz neatrisina restartÄ“Å”anas problēmu (ar restartētu atribÅ«tu nevar veikt uzdevumu, jo idempotence zÅ«d), taču noteikti ir vērts izdarÄ«t status=started, palielinās kopējā playbook stabilitāte, jo samazinās savienojumu skaits un dinamiskais stāvoklis.

Vēl viena apdarinātāja pozitÄ«va Ä«paŔība ir tāda, ka tas neaizsprosto izvadi. Nekādu izmaiņu nebija - izlaidē nav izlaista vai ok - vieglāk lasÄ«t. Tā ir arÄ« negatÄ«va Ä«paŔība ā€“ ja jau pirmajā palaiÅ”anas reizē atrodat drukas kļūdu lineāri izpildÄ«tā uzdevumā, tad apdarinātāji tiks izpildÄ«ti tikai tad, kad tie tiks mainÄ«ti, t.i. dažos apstākļos - ļoti reti. Piemēram, pirmo reizi mūžā pēc pieciem gadiem. Un, protams, nosaukumā bÅ«s drukas kļūda un viss salÅ«zÄ«s. Un, ja jÅ«s tos nepalaižat otro reizi, nekas nemainās.

AtseviŔķi mums jārunā par mainÄ«go lielumu pieejamÄ«bu. Piemēram, ja par uzdevumu paziņosit ar cilpu, kas bÅ«s mainÄ«gajos? JÅ«s varat uzminēt analÄ«tiski, taču tas ne vienmēr ir triviāls, it Ä«paÅ”i, ja mainÄ«gie nāk no dažādām vietām.

... Tātad apstrādātāji ir daudz mazāk noderÄ«gi un daudz problemātiskāki, nekā Ŕķiet. Ja varat kaut ko skaisti uzrakstÄ«t (bez volāniem) bez apdarinātājiem, labāk to darÄ«t bez tiem. Ja tas neizdodas skaisti, labāk ar viņiem.

KodÄ«gais lasÄ«tājs pareizi norāda, ka mēs neesam apsprieduÅ”i listenka apdarinātājs var izsaukt paziņojumu citam apdarinātājam, ka apdarinātājs var ietvert import_tasks (kas var veikt include_role ar with_items), ka apdarinātāja sistēma Ansible ir TjÅ«ringa pilnÄ«ga, ka apdarinātāji no include_role ziņkārÄ«gā veidā krustojas ar apdarinātājiem no spēles, utt. .d. - tas viss acÄ«mredzami nav ā€œpamatsā€).

Lai gan ir viena konkrēta WTF, kas patiesÄ«bā ir funkcija, kas jums jāpatur prātā. Ja jÅ«su uzdevums tiek izpildÄ«ts ar delegate_to un tam ir paziņots, tad atbilstoÅ”ais apdarinātājs tiek izpildÄ«ts bez delegate_to, t.i. resursdatorā, kuram ir pieŔķirta atskaņoÅ”ana. (Lai gan apdarinātājam, protams, var bÅ«t delegate_to Tas pats).

AtseviŔķi es vēlos teikt dažus vārdus par atkārtoti lietojamām lomām. Pirms kolekciju parādÄ«Å”anās bija doma, ka varētu izveidot universālas lomas, kas varētu bÅ«t ansible-galaxy install un aizgāja. Strādā uz visām OS un visu variantu visās situācijās. Tātad, mans viedoklis: tas nedarbojas. Jebkura loma ar masu include_vars, kas atbalsta 100500 1 gadÄ«jumu, ir lemts stÅ«ra korpusa kļūdu bezdibenim. Tos var veikt ar masveida testÄ“Å”anu, taču, tāpat kā ar jebkuru testÄ“Å”anu, jums ir ievades vērtÄ«bu un kopējās funkcijas Dekarta reizinājums, vai arÄ« jums ir ā€œaptverti atseviŔķi scenārijiā€. Mans viedoklis ir tāds, ka ir daudz labāk, ja loma ir lineāra (ciklomātiskā sarežģītÄ«ba XNUMX).

Jo mazāk if (skaidri vai deklaratÄ«vi - formā when vai forma include_vars pēc mainÄ«go kopas), jo labāka loma. Reizēm jātaisa zari, bet, atkārtoju, jo mazāk, jo labāk. Tāpēc Ŕķiet, ka tā ir laba loma ar galaktiku (tas darbojas!) ar daudzām lietām when var bÅ«t mazāk vēlama nekā ā€œsavāā€ loma no pieciem uzdevumiem. BrÄ«dis, kad loma ar galaktiku ir labāka, ir tad, kad sāc kaut ko rakstÄ«t. BrÄ«dis, kad kļūst sliktāk, ir tad, kad kaut kas saplÄ«st un rodas aizdomas, ka tas ir ā€œlomas ar galaktikuā€ dēļ. JÅ«s to atverat, un ir pieci ieslēgumi, astoņas uzdevumu lapas un kaudze when'ov... Un mums tas ir jāizdomā. 5 uzdevumu vietā lineārs saraksts, kurā nav ko lauzt.

Turpmākajās daļās

  • Mazliet par krājumiem, grupu mainÄ«gajiem, spraudni host_group_vars, hostvars. Kā piesiet Gordija mezglu ar spageti. DarbÄ«bas jomas un prioritātes mainÄ«gie, Iespējamās atmiņas modelis. "Tātad, kur mēs glabājam datu bāzes lietotājvārdu?"
  • jinja: {{ jinja }} ā€” nosql notype nosense mÄ«kstais plastilÄ«ns. Tas ir visur, pat tur, kur jÅ«s to negaidāt. Mazliet par !!unsafe un garŔīgs jamss.

Avots: www.habr.com

Pievieno komentāru