osv. Jo bedre du kender Ansible, desto flere nuancer kan du n\u00e6vne for \"smart\" l\u00f8sning. Og den enkle l\u00f8sning \u2014 brugen af naturlig adskillelse mellem pre\/roles\/post \u2014 medf\u00f8rer ikke nuancer.<\/code> osv. Jo mere du kender Ansible, jo flere nuancer vil du kunne n\u00e6vne for \"det smarte\" l\u00f8sning. Og en simpel l\u00f8sning - brugen af naturlig opdeling mellem pre\/roles\/post - skaber ikke nogen nuancer.<\/p>\n<\/p>\n
Og, lad os vende tilbage til vores 'foo'. Hvor skal vi placere det? I pre, post eller i roles? Det afh\u00e6nger tydeligvis af, om vi har brug for resultaterne fra handlerens arbejde for foo. Hvis ikke, er det ikke n\u00f8dvendigt at placere foo hverken i pre eller post - disse sektioner har en specifik betydning - at udf\u00f8re opgaver f\u00f8r og efter det prim\u00e6re kodearrangement.<\/p>\n
<\/p>\n
Nu er svaret p\u00e5 sp\u00f8rgsm\u00e5let \"rolle eller opgave\" baseret p\u00e5, hvad der allerede findes i play - hvis der er tasks, s\u00e5 skal du tilf\u00f8je dem til tasks. Hvis der er roles, skal du lave en rolle (selv om det kun er en opgave). Jeg minder om, at tasks og roles ikke bruges samtidig.<\/p>\n
<\/p>\n
Forst\u00e5elsen af Ansible's grundl\u00e6ggende aspekter giver velbegrundede svar p\u00e5 tilsyneladende smagsspecifikke sp\u00f8rgsm\u00e5l.<\/p>\n
<\/p>\n
Opgaver og roller (del to)<\/h1>\n <\/p>\n
Lad os nu diskutere situationen, hvor du lige er begyndt at skrive et playbook. Du skal lave foo, bar og baz. Er det tre opgaver, \u00e9n rolle eller tre roller? For at generalisere sp\u00f8rgsm\u00e5let: hvorn\u00e5r skal man begynde at skrive roller? Hvad er meningen med at skrive roller, n\u00e5r man kan skrive opgaver?\u2026 Hvad er en rolle?<\/p>\n
<\/p>\n
En af de st\u00f8rste fejl (jeg har talt om det tidligere) er at antage, at en rolle er som en funktion i et bibliotek til et program. Hvordan ser en generel beskrivelse af en funktion ud? Den tager argumenter som input, interagerer med side\u00e5rsager, skaber sideeffekter og returnerer en v\u00e6rdi.<\/p>\n
<\/p>\n
Nu, v\u00e6r opm\u00e6rksom. Hvad kan g\u00f8res i en rolle? At p\u00e5kalde sideeffekter - altid gerne, det er hele essensen af Ansible - at skabe sideeffekter. At have side\u00e5rsager? Simpelt. Men med \"at overf\u00f8re en v\u00e6rdi og returnere den\" - her er der ikke muligt. For det f\u00f8rste kan du ikke overf\u00f8re en v\u00e6rdi til en rolle. Du kan oprette en global variabel med en levetid svarende til play i vars sektionen for rollen. Du kan oprette en global variabel med en levetid i play inden for rollen. Eller endda med en levetid p\u00e5 playbooks (set_fact<\/code>\/register<\/code>). Men du kan ikke have \"lokale variabler\". Du kan ikke \"modtage en v\u00e6rdi\" og \"returnere den\".<\/p>\n<\/p>\n
Derfor f\u00f8lger det vigtigste: Du kan ikke skrive noget i Ansible og undg\u00e5 at skabe sideeffekter. \u00c6ndring af globale variabler er altid en sideeffekt for funktionen. I Rust, for eksempel, er \u00e6ndring af en global variabel \u2014 unsafe<\/code>. I Ansible er den eneste metode at p\u00e5virke v\u00e6rdier for en rolle. Bem\u00e6rk de anvendte ord: ikke \"overf\u00f8re v\u00e6rdi til rolle\", men \"\u00e6ndre v\u00e6rdierne, som rollen bruger\". Der er ingen isolation mellem roller. Der er ingen isolation mellem opgaver og roller.<\/p>\n<\/p>\n
I alt: en rolle er ikke en funktion<\/strong>.<\/p>\n<\/p>\n
Hvad er der godt ved roller? For det f\u00f8rste har roller standardv\u00e6rdier (\/default\/main.yaml<\/code>), for det andet har roller ekstra kataloger til opbevaring af filer.<\/p>\n<\/p>\n
Hvad er s\u00e5 godt ved standardv\u00e6rdier? Det er, at i Maslows ret forvr\u00e6ngede tabel over variabelprioriteter i Ansible er rolle-standarder de mindst prioriterede (minus kommandolinjeparametre fra Ansible). Det betyder, at hvis du \u00f8nsker at give standardv\u00e6rdier og ikke bekymre dig om, at de overskriver v\u00e6rdier fra inventar eller gruppevariabler, s\u00e5 er rolle-standarder det eneste rigtige sted for dig. (Jeg lyver lidt \u2013 der er ogs\u00e5 |d(your_default_here)<\/code>, men hvis vi taler om station\u00e6re steder \u2013 s\u00e5 kun rolle-standarder).<\/p>\n<\/p>\n
Hvad er der ellers godt ved roller? Det er, at de har deres egne kataloger. Disse kataloger er til variabler, b\u00e5de permanente (dvs. beregnede for rollen) og dynamiske (der er en slags m\u00f8nster eller anti-m\u00f8nster \u2013 include_vars<\/code> sammen med {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Dette er kataloger til files\/<\/code>, templates\/<\/code>. Derudover g\u00f8r det det muligt at have sine egne moduler og plugins i roller (library\/<\/code>). Men i forhold til opgaverne i playbooken (som ogs\u00e5 kan have alt dette), er fordelen her kun, at filerne ikke er i \u00e9n bunke, men i flere separate bunker.<\/p>\n<\/p>\n
Endnu en detalje: man kan pr\u00f8ve at lave roller, der vil v\u00e6re tilg\u00e6ngelige for genbrug (gennem galaxy). Efter introduktionen af samlinger kan distributionen af roller betragtes som n\u00e6sten glemt.<\/p>\n
<\/p>\n
Dermed har roller to vigtige egenskaber: de har standarder (en unik egenskab), og de tillader at strukturere koden.<\/p>\n
<\/p>\n
Tilbage til det oprindelige sp\u00f8rgsm\u00e5l: hvorn\u00e5r skal man lave opgaver og hvorn\u00e5r roller? Opgaver i playbooken bruges oftest enten som \"lim\" f\u00f8r\/efter roller, eller som en selvst\u00e6ndig byggeklods (s\u00e5 b\u00f8r der ikke v\u00e6re roller i koden). En bunke normale opgaver blandet med roller er klart klodset. Man b\u00f8r holde sig til en bestemt stil \u2013 enten opgaver eller roller. Roller giver opdeling af entiteter og standardv\u00e6rdier, mens opgaver tillader hurtigere l\u00e6sning af koden. Normalt placeres mere \"station\u00e6r\" (vigtig og kompleks) kode i roller, mens stilopgaver skrives som hj\u00e6lpe scripts.<\/p>\n
<\/p>\n
Der er mulighed for at lave import_role som en opgave, men hvis du skriver det, s\u00e5 v\u00e6r forberedt p\u00e5 at skulle forklare, hvorfor du \u00f8nsker at g\u00f8re det.<\/p>\n
<\/p>\n
Den nysgerrige l\u00e6ser kan sige, at roller kan importere roller, at roller kan have afh\u00e6ngigheder via galaxy.yml, og der er ogs\u00e5 den skr\u00e6mmende og forf\u00e6rdelige include_role<\/code> \u2014 jeg minder om, at vi forbedrer vores f\u00e6rdigheder i grundl\u00e6ggende Ansible, ikke i rytmisk gymnastik.<\/p>\n<\/p>\n
Handlere og opgaver<\/h1>\n <\/p>\n
Lad os diskutere en anden indlysende ting: handlere. At kunne bruge dem korrekt er n\u00e6sten en kunst. Hvad er forskellen mellem en handler og en opgave?<\/p>\n
<\/p>\n
Da vi minder om grundprincipperne, s\u00e5 her er et eksempel:<\/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
I rollen ligger handlerne i rolename\/handlers\/main.yaml. Handlerne deles mellem alle deltagere i spillet: pre\/post_tasks kan kalde handlerne fra rollen, og rollen kan kalde handlerne fra play. Men \"krydsrolle\" kald af handlere medf\u00f8rer meget st\u00f8rre forvirring end at gentage en triviel handler. (Endnu et element for bedste praksis \u2013 pr\u00f8v at undg\u00e5 gentagelser af navnene p\u00e5 handlerne).<\/p>\n
<\/p>\n
Den grundl\u00e6ggende forskel er, at en opgave altid udf\u00f8res (idempotent) (plus\/minus tags og block<\/code>), mens en handler \u2014 ved \u00e6ndring af tilstand (notify aktiveres kun, hvis der er sket \u00e6ndringer). Hvad kan det f\u00f8re til? For eksempel, at ved genstart, hvis der ikke var sket \u00e6ndringer, s\u00e5 bliver handleren ikke aktiveret. Og hvorfor kan det v\u00e6re, at vi har brug for at udf\u00f8re en handler, n\u00e5r der ikke var sket \u00e6ndringer i den genererende opgave? For eksempel, fordi noget gik i stykker, og der var sket \u00e6ndringer, men handleren blev ikke n\u00e5et. Fordi netv\u00e6rket var midlertidigt nede. Konfigurationen blev \u00e6ndret, tjenesten blev ikke genstartet. Ved n\u00e6ste k\u00f8rsel \u00e6ndres konfigurationen ikke, og tjenesten forbliver med den gamle version af konfigurationen.<\/p>\n<\/p>\n
Situationen med konfigurationen er ikke l\u00f8selig (mere pr\u00e6cist, man kan selv finde p\u00e5 en speciel genstartprotokol med filflag osv., men det er ikke l\u00e6ngere 'basic ansible' i nogen form). Derimod er der en anden hyppig historie: vi installerede en applikation, vi skrev dens .service<\/code>-fil, og nu vil vi gerne have den daemon_reload<\/code> og state=started<\/code>. Og det naturlige sted for dette ser ud til at v\u00e6re handleren. Men hvis du g\u00f8r det til en opgave i slutningen af opgavelisten eller rollen, vil det blive idempotent udf\u00f8rt hver gang. Selv hvis playbooken fejler midtvejs. Dette l\u00f8ser bestemt ikke problemerne med restarted (det er ikke muligt at have en opgave med attributten restarted, da idempotens g\u00e5r tabt), men det er helt sikkert v\u00e6rd at angive state=started, den samlede stabilitet af playbooks \u00f8ges, da antallet af forbindelser og dynamisk tilstand reduceres.<\/p>\n<\/p>\n
Endnu en positiv egenskab ved handleren er, at den ikke sviner output. Der var ingen \u00e6ndringer \u2013 ingen un\u00f8dvendige skipped eller ok i output \u2013 lettere at l\u00e6se. Det er ogs\u00e5 en negativ egenskab \u2013 hvis du finder en trykfejl i en line\u00e6rt udf\u00f8rt task ved f\u00f8rste fors\u00f8g, vil handlerne kun blive udf\u00f8rt ved \u00e6ndring, dvs. under visse betingelser - meget sj\u00e6ldent. For eksempel, f\u00f8rste gang i dit liv fem \u00e5r senere. Og selvf\u00f8lgelig vil der v\u00e6re en trykfejl i navnet og alt vil g\u00e5 i stykker. Og anden gang kan de ikke startes \u2013 der er jo ingen \u00e6ndring.<\/p>\n
<\/p>\n
Der skal tales s\u00e6rskilt om tilg\u00e6ngeligheden af variabler. For eksempel, hvis du notifierer for en opgave med en l\u00f8kke, hvad vil der s\u00e5 v\u00e6re i variablerne? Man kan g\u00e6tte det analytisk, men det er ikke altid trivielt, is\u00e6r hvis variablerne kommer fra forskellige steder.<\/p>\n
<\/p>\n
S\u00e5 handlerne er langt mindre nyttige og langt mere problematiske, end det ser ud til. Hvis man kan skrive noget p\u00e6nt (uden krumspring) uden handlerne, er det bedst at g\u00f8re det uden dem. Hvis det ikke kan g\u00f8res p\u00e6nt \u2014 s\u00e5 er det bedre at bruge dem.<\/p>\n
<\/p>\n
Den nysgerrige l\u00e6ser bem\u00e6rker med rette, at vi ikke har diskuteret lytt<\/code>, at en handler kan kalde notify for en anden handler, at en handler kan inkludere import_tasks (som kan g\u00f8re include_role med with_items), at systemet med handlers i Ansible er Turing-komplet, at handlers fra include_role p\u00e5 en fascinerende m\u00e5de krydser med handlers fra play osv. \u2014 alt dette er \u00e5benlyst ikke \"grundl\u00e6ggende\").<\/p>\n<\/p>\n
Selvom der er en bestemt WTF, som faktisk er en funktion, og som man skal huske. Hvis du har en opgave, der udf\u00f8res med delegate_to<\/code> og den har en notifikation, s\u00e5 udf\u00f8res den tilsvarende handler uden delegate_to<\/code>, dvs. p\u00e5 den v\u00e6rt, hvortil play er tildelt. (Selvom handleren selvf\u00f8lgelig ogs\u00e5 kan have delegate_to<\/code> det samme).<\/p>\n<\/p>\n
Separat vil jeg gerne sige et par ord om genanvendelige roller. Inden samlingerne kom, var ideen, at man kunne lave universelle roller, som man kunne ansible-galaxy install<\/code> Og s\u00e5 k\u00f8rte det. Det fungerer p\u00e5 alle OS i alle varianter under alle forhold. S\u00e5dan er min mening: det virker ikke. Enhver rolle med massiv include_vars<\/code>, med st\u00f8tte for 100500 tilf\u00e6lde er d\u00f8mt til at blive fyldt med corner case fejl. De kan d\u00e6kkes med massiv testning, men som med al testning, har du enten et cartesiansk produkt af inputv\u00e6rdier og en total funktion, eller du har \"d\u00e6kkede enkelte scenarier\". Min mening \u2014 det er langt bedre, hvis rollen er line\u00e6r (cyklomatisk kompleksitet 1).<\/p>\n<\/p>\n
Jo f\u00e6rre if'er (expr\u00e6sse eller deklarative \u2014 i form af block<\/code> eller formen include_vars<\/code> ud fra et s\u00e6t variabler), jo bedre er rollen. Nogle gange er det n\u00f8dvendigt at lave forgreninger, men jeg gentager, jo f\u00e6rre de er, jo bedre. S\u00e5 en tilsyneladende god rolle med galaxy (for det virker!), med en masse block<\/code> kan v\u00e6re mindre foretrukket end en \"egen\" rolle best\u00e5ende af fem opgaver. \u00d8jeblikket, hvor en rolle med galaxy er bedre \u2014 er n\u00e5r du begynder at skrive noget. \u00d8jeblikket, hvor den bliver d\u00e5rligere \u2014 er n\u00e5r noget g\u00e5r i stykker, og du har mistanke om, at det er p\u00e5 grund af \"rollen med galaxy\". Du \u00e5bner den, og s\u00e5 er der fem inkluderede, otte task-lister og en bunke block<\/code>\u2019er\u2026 Og det skal man finde ud af. I stedet for 5 opgaver som en line\u00e6r liste, hvor der ikke engang er noget at g\u00e5 i stykker.<\/p>\n<\/p>\n
I de kommende dele<\/h1>\n <\/p>\n
\nLidt om inventar, gruppevariabler, host_group_vars plugin, hostvars. Hvordan man fra spagetti binder den gordiske knude. Scope og precedence for variabler, Ansible's hukommelsesmodel. \"Hvor skal man s\u00e5 egentlig opbevare brugernavnet til databasen?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nosense bl\u00f8d plastelin. Det er overalt, selv der hvor du ikke forventer det. Lidt om !!unsafe<\/code> og l\u00e6kker yaml.<\/li>\n<\/ul>\nKilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f \u0434\u0435\u043b\u0430\u044e \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0432\u044c\u044e \u0434\u043b\u044f \u0447\u0443\u0436\u043e\u0433\u043e \u043a\u043e\u0434\u0430 \u043d\u0430 \u0410\u043d\u0441\u0438\u0431\u043b \u0438 \u043c\u043d\u043e\u0433\u043e \u043f\u0438\u0448\u0443 \u0441\u0430\u043c. \u0412 \u0445\u043e\u0434\u0435 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u043e\u0448\u0438\u0431\u043e\u043a (\u043a\u0430\u043a \u0447\u0443\u0436\u0438\u0445, \u0442\u0430\u043a \u0438 \u0441\u0432\u043e\u0438\u0445), \u0430 \u0442\u0430\u043a \u0436\u0435 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0439, \u044f \u043f\u043e\u043d\u044f\u043b \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u043e\u0448\u0438\u0431\u043a\u0443, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0410\u043d\u0441\u0438\u0431\u043b\u0430 \u2014 \u043e\u043d\u0438 \u043b\u0435\u0437\u0443\u0442 \u0432 \u0441\u043b\u043e\u0436\u043d\u043e\u0435, \u043d\u0435 \u043e\u0441\u0432\u043e\u0438\u0432 \u0431\u0430\u0437\u043e\u0432\u043e\u0433\u043e. \u0414\u043b\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439 \u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u043e\u0439 \u043d\u0435\u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u043e\u0441\u0442\u0438 \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0410\u043d\u0441\u0438\u0431\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87084","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t