block<\/code> Och s\u00e5 vidare. Ju b\u00e4ttre du k\u00e4nner Ansible, desto fler nyanser kan du n\u00e4mna f\u00f6r en \"skicklig\" l\u00f6sning. Ett enkelt beslut \u00e4r att anv\u00e4nda den naturliga uppdelningen mellan pre\/roles\/post \u2013 det v\u00e4cker inga nyanser.<\/p>\n<\/p>\n
Och vi \u00e5terv\u00e4nder till v\u00e5rt 'foo'. Var ska den placeras? I pre, post eller i roles? Sj\u00e4lvklart beror det p\u00e5 om vi beh\u00f6ver resultaten fr\u00e5n handlarens arbete f\u00f6r foo. Om de inte beh\u00f6vs, s\u00e5 ska foo inte placeras varken i pre eller post \u2013 dessa sektioner har en speciell betydelse \u2013 att utf\u00f6ra uppgifter f\u00f6re och efter den huvudsakliga kodm\u00e4ngden.<\/p>\n
<\/p>\n
Nu blir svaret p\u00e5 fr\u00e5gan \"roll eller uppgift\" baserat p\u00e5 vad som redan finns i play \u2013 om det finns uppgifter, b\u00f6r de l\u00e4ggas till i tasks. Om det finns roller \u2013 b\u00f6r en roll skapas (\u00e4ven om det bara \u00e4r en uppgift). Jag p\u00e5minner om att tasks och roles inte anv\u00e4nds samtidigt.<\/p>\n
<\/p>\n
Att f\u00f6rst\u00e5 grunderna i Ansible ger v\u00e4lgrundade svar p\u00e5 fr\u00e5gor som verkar handla om smak.<\/p>\n
<\/p>\n
Uppgifter och roller (del tv\u00e5)<\/h1>\n <\/p>\n
L\u00e5t oss nu diskutera situationen n\u00e4r du just b\u00f6rjar skriva en playbook. Du beh\u00f6ver g\u00f6ra foo, bar och baz. \u00c4r det tre uppgifter, en roll eller tre roller? F\u00f6r att sammanfatta fr\u00e5gan: n\u00e4r b\u00f6r man b\u00f6rja skriva roller? Vad \u00e4r po\u00e4ngen med att skriva roller n\u00e4r man kan skriva uppgifter?\u2026 Och vad \u00e4r en roll?<\/p>\n
<\/p>\n
Ett av de st\u00f6rsta misstagen (jag har redan pratat om detta) \u00e4r att tro att en roll \u00e4r som en funktion i ett programbibliotek. Hur ser en allm\u00e4n beskrivning av en funktion ut? Den tar in argument, interagerar med sidorelaterade orsaker, skapar bieffekter och returnerar ett v\u00e4rde.<\/p>\n
<\/p>\n
Nu, uppm\u00e4rksamhet. Vad av detta kan g\u00f6ras i en roll? Att \u00e5kalla bieffekter \u2013 alltid v\u00e4lkommet, det \u00e4r sj\u00e4lva syftet med Ansible \u2013 att skapa bieffekter. Att ha side causes? Enkelt. Men n\u00e4r det g\u00e4ller att \"skicka ett v\u00e4rde och f\u00e5 tillbaka det\" \u2013 h\u00e4r \u00e4r det stopp. F\u00f6r det f\u00f6rsta kan du inte skicka ett v\u00e4rde till en roll. Du kan skapa en global variabel med livsl\u00e4ngd under play i vars-sektionen f\u00f6r rollen. Du kan skapa en global variabel med livsl\u00e4ngd under play inne i rollen. Eller till och med med livsl\u00e4ngd f\u00f6r spelboken (set_fact<\/code>\/register<\/code>). Men du kan inte ha \"lokala variabler\". Du kan inte \"ta emot ett v\u00e4rde\" och \"\u00e5terv\u00e4nda det\".<\/p>\n<\/p>\n
Detta leder till den viktigaste punkten: man kan inte skriva n\u00e5got i Ansible utan att skapa bieffekter. Att \u00e4ndra globala variabler \u00e4r alltid en bieffekt f\u00f6r funktionen. I Rust, till exempel, \u00e4r f\u00f6r\u00e4ndring av en global variabel - unsafe<\/code>. I Ansible finns det ingen annan metod att p\u00e5verka v\u00e4rdena f\u00f6r en roll. Observera de anv\u00e4nda orden: inte \"skicka v\u00e4rde till rollen\", utan \"\u00e4ndra de v\u00e4rden som rollen anv\u00e4nder\". Det finns ingen isolering mellan roller. Det finns ingen isolering mellan uppgifter och roller.<\/p>\n<\/p>\n
Totalt: en roll \u00e4r inte en funktion<\/strong>.<\/p>\n<\/p>\n
Vad \u00e4r bra med en roll? F\u00f6r det f\u00f6rsta har en roll standardv\u00e4rden (\/default\/main.yaml<\/code>), f\u00f6r det andra har en roll ytterligare kataloger f\u00f6r att lagra filer.<\/p>\n<\/p>\n
Vad \u00e4r bra med standardv\u00e4rden? De \u00e4r att i Maslows ganska snedvridna hierarki av variabler prioriterade hos Ansible, \u00e4r rollstandarder de minst prioriterade (f\u00f6rutom parameterarna fr\u00e5n Ansible kommandoraden). Det inneb\u00e4r att om du beh\u00f6ver tillhandah\u00e5lla standardv\u00e4rden och inte oroa dig f\u00f6r att de ska \u00f6verskrida v\u00e4rden fr\u00e5n inventariet eller gruppvariabler, s\u00e5 \u00e4r rollernas standarder det enda r\u00e4tta st\u00e4llet f\u00f6r dig. (Jag ljuger lite \u2014 det finns ocks\u00e5 |d(your_default_here)<\/code>, men om vi pratar om station\u00e4ra platser \u2014 s\u00e5 \u00e4r det endast rollernas standarder).<\/p>\n<\/p>\n
Vad mer \u00e4r bra med roller? Det \u00e4r att de har sina egna kataloger. Dessa \u00e4r kataloger f\u00f6r variabler, b\u00e5de permanenta (dvs. de som ber\u00e4knas f\u00f6r rollen) och dynamiska (det finns ett slags antingen m\u00f6nster eller anti-m\u00f6nster \u2014 include_vars<\/code> tillsammans med {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Dessa \u00e4r kataloger f\u00f6r files\/<\/code>, templates\/<\/code>. Dessutom till\u00e5ter det roller att ha sina egna moduler och plugins (library\/<\/code>). Men, j\u00e4mf\u00f6rt med uppgifter i en playbook (d\u00e4r ocks\u00e5 allt detta kan vara), \u00e4r f\u00f6rdelen h\u00e4r endast att filerna inte \u00e4r samlade i en enda h\u00f6g, utan flera separata h\u00f6gar.<\/p>\n<\/p>\n
En annan detalj: man kan f\u00f6rs\u00f6ka skapa roller som kommer att vara tillg\u00e4ngliga f\u00f6r \u00e5teranv\u00e4ndning (via galaxy). Efter att samlingar har lanserats kan spridningen av roller n\u00e4stan betraktas som gl\u00f6md.<\/p>\n
<\/p>\n
S\u00e5ledes har roller tv\u00e5 viktiga egenskaper: de har standarder (en unik egenskap) och de till\u00e5ter att strukturera koden.<\/p>\n
<\/p>\n
\u00c5ter till den ursprungliga fr\u00e5gan: n\u00e4r ska man anv\u00e4nda uppgifter och n\u00e4r roller? Uppgifter i playbook anv\u00e4nds oftast antingen som \"lim\" f\u00f6re\/efter roller eller som sj\u00e4lvst\u00e4ndiga byggstenar (d\u00e5 b\u00f6r det inte finnas n\u00e5gra roller i koden). En h\u00f6g med normala uppgifter blandat med roller \u00e4r utan tvekan slarvigt. Man b\u00f6r f\u00f6lja en specifik stil - antingen uppgifter eller roller. Roller ger separation av entiteter och standardv\u00e4rden, medan uppgifter g\u00f6r det m\u00f6jligt att l\u00e4sa koden snabbare. Vanligtvis flyttas mer \"station\u00e4r\" (viktig och komplex) kod till rollen, medan stil med uppgifter inneh\u00e5ller hj\u00e4lpskript.<\/p>\n
<\/p>\n
Det finns m\u00f6jlighet att g\u00f6ra import_role som en uppgift, men om du skriver n\u00e5got s\u00e5dant, var beredd att f\u00f6rklara varf\u00f6r du vill g\u00f6ra detta f\u00f6r ditt eget estetiska sinne.<\/p>\n
<\/p>\n
En p\u00e5tr\u00e4ngande l\u00e4sare kan s\u00e4ga att roller kan importera roller, att roller kan ha beroenden genom galaxy.yml, och att det finns n\u00e5got l\u00e4skigt och hemskt. include_role<\/code> \u2014 jag p\u00e5minner om att vi f\u00f6rb\u00e4ttrar v\u00e5ra f\u00e4rdigheter i grundl\u00e4ggande Ansible, inte i rytmisk gymnastik.<\/p>\n<\/p>\n
Handlers och uppgifter<\/h1>\n <\/p>\n
L\u00e5t oss diskutera en till uppenbar sak: handlers. Att anv\u00e4nda dem korrekt \u00e4r n\u00e4stan en konst. Vad \u00e4r skillnaden mellan en handler och en uppgift?<\/p>\n
<\/p>\n
Eftersom vi g\u00e5r igenom grunderna, h\u00e4r \u00e4r ett exempel:<\/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
Rollens handlers ligger i rolename\/handlers\/main.yaml. Handlers delas mellan alla deltagare i play: pre\/post_tasks kan anropa rollen's handlers, och rollen kan anropa handlers fr\u00e5n play. Men, \"cross-role\" anrop av handlers orsakar betydligt st\u00f6rre f\u00f6rvirring \u00e4n upprepning av triviala handlers. (En annan del av b\u00e4sta praxis - f\u00f6rs\u00f6k att inte namnge handlers flera g\u00e5nger).<\/p>\n
<\/p>\n
Huvudskillnaden \u00e4r att en uppgift alltid utf\u00f6rs (idempotent) (plus\/minus taggar och when<\/code>), medan en handler utf\u00f6rs beroende p\u00e5 tillst\u00e5ndet (notify aktiveras endast om det har skett en f\u00f6r\u00e4ndring). Vad kan det leda till? Till exempel, vid en omk\u00f6rning, om det inte har skett n\u00e5gon f\u00f6r\u00e4ndring, kommer inget handler att k\u00f6ras. Men varf\u00f6r kan det vara s\u00e5 att vi beh\u00f6ver utf\u00f6ra en handler n\u00e4r det inte har skett n\u00e5gon f\u00f6r\u00e4ndring i den genererande uppgiften? Till exempel, f\u00f6r att n\u00e5got gick s\u00f6nder och det skedde en f\u00f6r\u00e4ndring, men exekveringen kom inte fram till handler. Till exempel, f\u00f6r att n\u00e4tverket var nere en kort stund. Konfigurationen \u00e4ndrades, tj\u00e4nsten startades inte om. Vid n\u00e4sta k\u00f6rning \u00e4ndras konfigurationen inte l\u00e4ngre, och tj\u00e4nsten f\u00f6rblir med den gamla versionen av konfigurationen.<\/p>\n<\/p>\n
Situationen med konfigurationen \u00e4r inte l\u00f6sbar (snarare kan man sj\u00e4lv uppfinna ett speciellt omstartsprotokoll med filflaggor osv., men det \u00e4r redan inte 'grundl\u00e4ggande ansible' i n\u00e5got fall). D\u00e4remot finns det en annan vanlig historia: vi har installerat en applikation, skrivit ner den .service<\/code>-fil, och nu vill vi daemon_reload<\/code> och state=started<\/code>. Och den naturliga platsen f\u00f6r detta verkar vara en handler. Men om man g\u00f6r det till en task i slutet av tasklistan eller en roll, s\u00e5 kommer den att utf\u00f6ras idempotent varje g\u00e5ng. \u00c4ven om playbooken skulle g\u00e5 s\u00f6nder p\u00e5 mitten. Detta l\u00f6ser inte problemet med restarted (man kan inte g\u00f6ra en task med attributet restarted, eftersom idempotensen skulle g\u00e5 f\u00f6rlorad), men det \u00e4r absolut v\u00e4rt att s\u00e4tta state=started, den \u00f6vergripande stabiliteten i playbooks \u00f6kar, eftersom antalet kopplingar och dynamiskt tillst\u00e5nd minskar.<\/p>\n<\/p>\n
\u00c4nnu en positiv egenskap hos en handler \u00e4r att den inte skr\u00e4par ner utdata. Inga \u00e4ndringar - inga \u00f6verfl\u00f6diga skipped eller ok i utdata - l\u00e4ttare att l\u00e4sa. Det \u00e4r ocks\u00e5 en negativ egenskap - om du hittar ett skrivfel i en linj\u00e4rt utf\u00f6rd uppgift vid f\u00f6rsta k\u00f6rningen, kommer handlers endast k\u00f6ras vid f\u00f6r\u00e4ndringar, dvs vid vissa villkor - v\u00e4ldigt s\u00e4llan. Till exempel, f\u00f6rsta g\u00e5ngen i livet efter fem \u00e5r. Och, sj\u00e4lvklart, d\u00e4r kommer det att finnas ett skrivfel i namnet och allt kommer att g\u00e5 s\u00f6nder. Vid andra k\u00f6rningen kan de inte startas - det finns ju inga f\u00f6r\u00e4ndringar.<\/p>\n
<\/p>\n
Man m\u00e5ste s\u00e4rskilt n\u00e4mna tillg\u00e5ngen till variabler. Till exempel, om du notifierar f\u00f6r en task med en loop, vad kommer att h\u00e4nda med variablerna? Man kan gissa analytiskt, men det \u00e4r inte alltid trivialt, s\u00e4rskilt om variablerna kommer fr\u00e5n olika k\u00e4llor.<\/p>\n
<\/p>\n
S\u00e5 handler \u00e4r betydligt mindre anv\u00e4ndbara och mycket mer problematiska \u00e4n de verkar. Om du kan skriva n\u00e5got snyggt (utan n\u00e5gra konstigheter) utan handlers, \u00e4r det b\u00e4ttre att g\u00f6ra det utan dem. Om det inte blir snyggt \u2013 d\u00e5 \u00e4r det b\u00e4ttre att anv\u00e4nda dem.<\/p>\n
<\/p>\n
Den insiktsfulle l\u00e4saren p\u00e5pekar med r\u00e4tta att vi inte har diskuterat lyssna<\/code>, som handler kan anropa notify f\u00f6r en annan handler, att en handler kan inkludera import_tasks (som kan g\u00f6ra include_role med with_items), att systemet med handlers i Ansible \u00e4r Turing-komplett, att handlers fr\u00e5n include_role p\u00e5 intressant s\u00e4tt \u00f6verlappar med handlers fr\u00e5n play, och s\u00e5 vidare \u2013 allt detta \u00e4r uppenbarligen inte \"grundl\u00e4ggande\").<\/p>\n<\/p>\n
\u00c4ven om det finns ett visst WTF, som faktiskt \u00e4r en funktion, och som man m\u00e5ste komma ih\u00e5g. Om du har en task som k\u00f6rs med delegate_to<\/code> och den har notify, s\u00e5 k\u00f6rs den motsvarande handlern utan delegate_to<\/code>, det vill s\u00e4ga p\u00e5 den v\u00e4rd d\u00e4r play \u00e4r tilldelad. (\u00c4ven om handlern, naturligtvis, kan ha delegate_to<\/code> ocks\u00e5).<\/p>\n<\/p>\n
Separat vill jag n\u00e4mna n\u00e5gra ord om \u00e5teranv\u00e4ndbara roller. Innan kollektionerna kom fanns det en id\u00e9 om att man skulle kunna skapa universella roller som kan ansible-galaxy install<\/code> och s\u00e5 \u00e5kte jag. Fungerar p\u00e5 alla operativsystem i alla varianter i alla situationer. S\u00e5, min \u00e5sikt: det fungerar inte. Varje roll med st\u00f6d f\u00f6r 100500 fall \u00e4r d\u00f6md till avgrunder av corner case-buggar. include_vars<\/code>, st\u00f6der 100500 fall \u00e4r d\u00f6mt att hamna i avgrunder av corner case-buggar. De kan t\u00e4ppas till med massiv testning, men som med all testning, antingen har du det kartesiska produkten av ing\u00e5ngsv\u00e4rden och en total funktion, eller s\u00e5 har du \"t\u00e4ckt enskilda scenarier\". Min \u00e5sikt \u00e4r att det \u00e4r mycket b\u00e4ttre om rollen \u00e4r linj\u00e4r (cyclomatic complexity 1).<\/p>\n<\/p>\n
Ju f\u00e4rre if-satser (uppenbara eller deklarativa \u2013 i form av when<\/code> eller form include_vars<\/code> baserat p\u00e5 upps\u00e4ttningen av variabler), desto b\u00e4ttre \u00e4r rollen. Ibland m\u00e5ste man g\u00f6ra f\u00f6rgreningar, men, jag upprepar, ju f\u00e4rre desto b\u00e4ttre. S\u00e5 en till synes bra roll med galaxy (den fungerar ju!) med en massa when<\/code> kan vara mindre \u00f6nskv\u00e4rd \u00e4n en \"egen\" roll med fem uppgifter. Stunden n\u00e4r en roll med galaxy \u00e4r b\u00e4ttre \u2013 \u00e4r n\u00e4r du b\u00f6rjar skriva n\u00e5got. Stunden n\u00e4r den blir s\u00e4mre \u2013 \u00e4r n\u00e4r n\u00e5got g\u00e5r s\u00f6nder och du misst\u00e4nker att det beror p\u00e5 \"rollen med galaxy\". Du \u00f6ppnar den och d\u00e4r finns fem includes, \u00e5tta tasklistor och en h\u00f6g when<\/code>\u2026 och d\u00e4r m\u00e5ste du reda ut det. Ist\u00e4llet f\u00f6r 5 uppgifter i en linj\u00e4r lista d\u00e4r det dessutom egentligen inte finns n\u00e5got att g\u00e5 s\u00f6nder.<\/p>\n<\/p>\n
I de f\u00f6ljande delarna<\/h1>\n <\/p>\n
\nLite om inventarier, grupperade variabler, host_group_vars plugin, hostvars. Hur man binder ihop spaghetti till en Gordisk knut. Scope och prioritetsordning f\u00f6r variabler, Ansible's minnesmodell. \"S\u00e5 var ska man egentligen lagra anv\u00e4ndarnamnet f\u00f6r databasen?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nonsens mjukt lera. Det finns \u00f6verallt, \u00e4ven d\u00e4r du minst anar det. Lite om !!unsafe<\/code> och l\u00e4cker yaml.<\/li>\n<\/ul>\nK\u00e4lla: 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