Jag gör många recensioner av andras kod på Ansible och skriver mycket själv. Vid analysen av fel (både andras och mina egna), samt genom vissa intervjuer, förstod jag det huvudfel som Ansible-användare gör — de ger sig in i det komplexa innan de bemästrar grunderna.

För att rätta till denna universella orättvisa har jag beslutat att skriva en introduktion till Ansible för dem som redan känner till det. Jag varnar, det är ingen sammanfattning av manualer, det är en lång text med mycket text och inga bilder.

Den förväntade nivån på läsaren är att ni redan har skrivit flera tusen rader YAML, har något i produktion, men "det verkar bara snett".

Titlar

Det största misstaget hos Ansible-användare är att inte veta vad saker heter. Om du inte vet namnen kan du inte förstå vad som står i dokumentationen. Ett levande exempel: vid en intervju, en person som påstod sig ha skrivit mycket i Ansible, kunde inte svara på frågan "av vilka element består en playbook?". När jag påpekade att "det förväntades ett svar att playbook består av play", följde en förödande kommentar "vi använder inte det". Människor skriver på Ansible för pengar och använder inte play. De använder det i själva verket, men vet inte vad det är.

Så vi börjar med det enkla: hur saker heter. Kanske vet du detta, eller kanske inte, för att du inte har varit uppmärksam när du läste dokumentationen.

ansible-playbook kör playbooken. Playbook är en fil med ändelsen yml/yaml, inuti finns något sådant:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Vi har redan förstått att hela den här filen är en playbook. Vi kan visa var roller (roles) och uppgifter (tasks) finns. Men var är play? Och vad skiljer play från role eller playbook?

Detta finns allt i dokumentationen. Och detta missar man. Nybörjare – för att det är för mycket och man kan inte minnas allt samtidigt. Erfaren – för att "triviala saker". Om du är erfaren – läs om dessa sidor åtminstone en gång var sjätte månad, och din kod kommer att bli betydligt bättre.

Så kom ihåg: Playbook är en lista som består av play och import_playbook.
Detta är en play:

- hosts: group1
  roles:
    - role1

och detta är också en annan play:

- hosts: group2,group3
  tasks:
    - debug:

Vad är då en play? Vad behövs den till?

Play är en nyckelkomponent för playbook, eftersom en play och endast en play kopplar ihop en lista av roller och/eller uppgifter med en lista av värdar där de ska utföras. I djupet av dokumentationen kan man hitta omnämnandet om delegate_to, lokala lookup-plugins, nätverks-cli-specifika inställningar, hopphostar osv. De tillåter en lätt förändring av var uppgifter utförs. Men glöm det. Varje en av dessa smarta alternativ har mycket specifika tillämpningar och de är definitivt inte universella. Och vi pratar om grundläggande saker som alla bör veta och använda.

Om du vill "göra något" "någonstans" — skriver du en play. Inte en roll. Inte en roll med moduler och delegater. Du tar och skriver en play. I vilken, i fältet hosts, listar du var den ska köras, och i roles/tasks — vad som ska köras.

Enkel, eller hur? Och hur skulle det kunna vara på något annat sätt?

En av de typiska situationerna när folk vill göra detta utan play, är "rollen som konfigurerar allt". Man vill ha en roll som konfigurerar och servern den första typen och servrar av den andra typen.

Ett arketypiskt exempel är övervakning. Man vill ha en roll för övervakning som konfigurerar övervakningen. Rollen för övervakning tilldelas övervakningshosts (i motsvarande play). Men det visar sig att för att övervaka måste vi installera paket på de hosts vi övervakar. Varför inte använda delegate? Och vi måste också konfigurera iptables. delegate? Och vi måste också skriva/korrigera konfigurationen för databashanteraren så att övervakningen tillåts. delegate! Och om kreativiteten flödar, kan man göra delegation include_role i en inre loop med en smart filtrering av grupplistan, och inuti include_role kan man även göra delegate_to igen. Och så fortsätter det…

En god önskan — att ha en enda roll för övervakning som "gör allt" — leder oss till en förödande situation där den vanligaste utvägen är: skriva om allt från början.

Var här inträffade felet? I det ögonblick du upptäckte att för att utföra uppgiften "x" på värden X måste du gå till värden Y och göra "y" där, borde du ha utfört en enkel övning: gå och skriv en play som på värden Y gör y. Inte lägga till något i "x", utan skriva från början. Även om du hårdkodar variabler.

Det verkar som att allt ovanstående är korrekt. Men det är inte ditt fall! Eftersom du vill skriva återanvändbar kod som är DRY och liknar ett bibliotek, och du behöver hitta en metod för att göra det.

Här finns en annan allvarlig bugg. En bugg som har förvandlat många projekt från att vara hyfsat skrivna (det kan bli bättre, men allt fungerar och är lätt att bygga på) till en fullständig mardröm, där till och med författaren har svårt att förstå. Det fungerar, men Gud förbjude att förändra något.

Denna bugg låter så här: en roll är en biblioteksfunktion. Denna analoga jämförelse har dödat så många bra initiativ att det är sorgligt att se. En roll är inte en biblioteksfunktion. Den kan inte göra beräkningar och den kan inte fatta beslut på nivå med play. Påminn mig, vilka beslut fattar play?

Tack, du har rätt. Play fattar ett beslut (mer exakt, innehåller information) om vilka uppgifter och roller som ska utföras på vilka värdar.

Om du delegerar detta beslut till en roll, och dessutom med beräkningar, fördömer du dig själv (och den som kommer att försöka förstå din kod) till ett eländigt liv. En roll avgör inte var den ska utföras. Det beslutet fattar play. En roll gör det som den blivit tillsagd att göra, där den blivit tillsagd att göra det.

Varför det är farligt att programmera med Ansible och varför COBOL är bättre än Ansible kommer vi att diskutera i kapitlet om variabler och jinja. Men just nu kan vi säga en sak - varje beräkning du gör efterlämnar ett bestående spår av förändring av globala variabler, och du kan inte göra något åt det. Så snart två "spår" korsar varandra - allt är förlorat.

En notis för den petiga: en roll kan självfallet påverka kontrollflödet. Det finns delegate_to och det finns rimliga tillämpningar för det. Det finns meta: end host/play. Men! Kom ihåg, vi lär oss grunderna? Glömde du bort delegate_to. Vi pratar om den enklaste och vackraste koden i Ansible. Som är lätt att läsa, skriva, felsöka, testa och bygga på. Så, än en gång:

play och endast play avgör på vilka värdar saker körs.

I detta avsnitt har vi granskat motståndet mellan play och roll. Nu ska vi prata om relationerna mellan tasks vs roll.

Uppgifter och Roller

Låt oss betrakta play:

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

Låt oss säga att du behöver göra foo. Och det ser ut som foo: name=foobar state=present. Vart ska detta skrivas? I pre? Post? Ska jag skapa en roll?

… Och vart tog uppgifterna vägen?

Vi börjar igen från grunden - strukturen för play. Om du har problem med detta ämne kan du inte använda play som grund för allt annat, och ditt resultat blir "skakigt".

Enheten play: direktiv hosts, inställningar för själva play och sektionerna pre_tasks, tasks, roles, post_tasks. Andra parametrar för play är för tillfället ointressanta.

Ordningen av deras sektioner med tasker och roller: pre_tasks, roles, tasks, post_tasks. Eftersom den semantiska ordningen för utförandet är tasks och roles oklar, så säger best practices att vi lägger till en sektion tasks, endast om det inte finns någon roles. Om det finns roles, så placeras alla relaterade tasks i sektionerna pre_tasks/post_tasks.

Det kvarstår bara det som är semantiskt tydligt: först pre_tasks, sedan roles, sedan post_tasks.

Men vi har fortfarande inte besvarat frågan: var ska vi skriva anropet till modulen foo ? Måste vi skriva en hel roll för varje modul? Eller är det bättre att ha en allomfattande roll för allt? Och om det inte är en roll, var skriver vi då — i pre eller i post?

Om det inte finns något välinformerat svar på dessa frågor, så är det ett tecken på bristande intuition, det vill säga de "skakiga grunderna". Låt oss reda ut det. Först en kontrollfråga: Om play har pre_tasks och post_tasks och det inte finns några tasks eller roller, kan något gå sönder om jag flyttar första tasken från post_tasks till slutet? pre_tasks?

Självklart antyder formuleringen av frågan att något kommer att gå fel. Men vad exakt?

… Handlers. Att läsa grunderna avslöjar en viktig fakta: alla handlers flushas automatiskt efter varje sektion. Det vill säga, alla tasks från pre_tasks, körs, därefter alla handlers som har notifierats. Sedan körs alla roller och alla handlers som har notifierats i rollerna. Därefter post_tasks och deras handlers.

Således, om du flyttar en task från post_tasks på pre_tasks, kan du potentiellt köra den före handlern. Till exempel, om i pre_tasks installationen och konfigurationen webbserver, och i post_tasks någonting skickas, kommer flytten av den här tasken till sektionen pre_tasks att leda till att servern inte är igång vid "skickande"-tillfället och allt går fel.

Och nu låt oss tänka en gång till, varför behöver vi pre_tasks och post_tasks? Например, для того, чтобы выполнить всё нужное (включая хэндлеры) до выполнения роли. А post_tasks som gör att vi kan arbeta med resultaten från rollernas (inklusive handlers) utförande.

En nitisk kännare av Ansible kommer att säga oss att det finns meta: flush_handlers, men varför behöver vi flush_handlers, om vi kan lita på sektionernas utförande ordning i play? Dessutom kan användningen av meta: flush_handlers ge oss oväntade resultat med upprepande handlers och ge oss konstiga varningar vid användning av when för block osv. Ju mer du känner till Ansible, desto fler nyanser kan du namnge för den "fiffiga" lösningen. En enkel lösning — användningen av naturlig separation mellan pre/roller/post — ger inga nyanser.

Och vi återvänder till vårt 'foo'. Var ska vi placera det? I pre, post eller i roles? Självklart beror det på om vi behöver resultaten från handläggaren för foo. Om vi inte gör det, så behöver foo inte placeras varken i pre eller post - dessa sektioner har en speciell betydelse - att utföra uppgifter före och efter huvudkoden.

Nu reduceras svaret på frågan "roll eller uppgift" till vad som redan finns i play - om det finns uppgifter där, så bör vi lägga till dem i tasks. Om det finns roller - så bör vi skapa en roll (även om det bara är en uppgift). Jag påminner om att uppgifter och roller inte används samtidigt.

Att förstå grunderna i Ansible ger välgrundade svar på frågor som verkar handla om smak.

Uppgifter och roller (del två)

Låt oss nu diskutera situationen när du just börjar skriva en playbook. Du behöver göra foo, bar och baz. Är det tre uppgifter, en roll eller tre roller? För att sammanfatta frågan: när bör man börja skriva roller? Vad är poängen med att skriva roller när man kan skriva uppgifter?… Och vad är en roll?

Ett av de största misstagen (jag har redan pratat om detta) är att tro att en roll är som en funktion i ett programbibliotek. Hur ser en allmän beskrivning av en funktion ut? Den tar in argument, interagerar med sidorelaterade orsaker, skapar bieffekter och returnerar ett värde.

Nu, uppmärksamhet. Vad av detta kan göras i en roll? Att skapa bieffekter - alltid gärna, det är hela syftet med Ansible - att skapa bieffekter. Att ha sidorelaterade orsaker? Lätt. Men med "skicka ett värde och returnera det" - här är det stopp. För det första kan du inte skicka ett värde till en roll. Du kan sätta en global variabel med livslängd motsvarande play i sektionen vars för rollen. Du kan sätta en global variabel med livslängd i play inom rollen. Eller till och med med livslängd för playbook.set_fact/registerMen du kan inte ha "lokala variabler". Du kan inte "ta emot ett värde" och "returnera det".

Detta leder till den viktigaste punkten: man kan inte skriva något i Ansible utan att skapa bieffekter. Att ändra globala variabler är alltid en bieffekt för funktionen. I Rust, till exempel, är förändring av en global variabel - unsafe. Men i Ansible är det den enda metoden för att påverka värdena för en roll. Observera de använda orden: inte "skicka ett värde till rollen", utan "ändra de värden som rollen använder". Det finns ingen isolering mellan roller. Det finns ingen isolering mellan uppgifter och roller.

Totalt: en roll är inte en funktion.

Vad är bra med en roll? För det första har en roll standardvärden (/default/main.yaml), för det andra har en roll ytterligare kataloger för att lagra filer.

Vad är bra med standardvärden? De är att i Maslows ganska snedvridna hierarki av variabler prioriterade hos Ansible, är rollstandarder de minst prioriterade (förutom parameterarna från Ansible kommandoraden). Det innebär att om du behöver tillhandahålla standardvärden och inte oroa dig för att de ska överskrida värden från inventariet eller gruppvariabler, så är rollernas standarder det enda rätta stället för dig. (Jag ljuger lite — det finns också |d(your_default_here), men om vi pratar om stationära platser — så är det endast rollernas standarder).

Vad mer är bra med roller? Det är att de har sina egna kataloger. Dessa är kataloger för variabler, både permanenta (dvs. de som beräknas för rollen) och dynamiska (det finns ett slags antingen mönster eller anti-mönster — include_vars tillsammans med {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Dessa är kataloger för files/, templates/. Dessutom tillåter det roller att ha sina egna moduler och plugins (library/). Men, i jämförelse med uppgifter i playbooken (som också kan ha allt detta), är fördelen här bara att filerna inte ligger i en enda hög, utan i flera separata högar.

En annan detalj: man kan försöka skapa roller som kommer att vara tillgängliga för återanvändning (via galaxy). Efter att samlingar har lanserats kan spridningen av roller nästan betraktas som glömd.

Således har roller två viktiga egenskaper: de har standarder (en unik egenskap) och de tillåter att strukturera koden.

Återkommande till den ursprungliga frågan: när ska man göra uppgifter och när roller? Uppgifter i playbooken används oftast antingen som "lim" före/efter roller eller som självständiga byggstenar (då bör det inte finnas några roller i koden). En hög av normala uppgifter blandat med roller — det är helt klart slarvigt. Man bör hålla sig till en konkret stil — antingen uppgifter eller roller. Roller ger separation av entiteter och standarder, uppgifter gör att man kan läsa koden snabbare. Vanligtvis förs mer "stationär" (viktig och komplex) kod ut till roller, medan hjälpskript skrivs i stil med uppgifter.

Det finns möjlighet att göra import_role som en uppgift, men om du skriver något sådant, var beredd att förklara varför du vill göra detta för ditt eget estetiska sinne.

En påträngande läsare kan säga att roller kan importera roller, att roller kan ha beroenden genom galaxy.yml, och att det finns något läskigt och hemskt. include_role — jag påminner om att vi förbättrar våra färdigheter i grundläggande Ansible, inte i rytmisk gymnastik.

Handlers och uppgifter

Låt oss diskutera en till uppenbar sak: handlers. Att använda dem korrekt är nästan en konst. Vad är skillnaden mellan en handler och en uppgift?

Eftersom vi går igenom grunderna, här är ett exempel:

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

I en roll ligger handlers i rolename/handlers/main.yaml. Handlers delas mellan alla deltagare i spelet: pre/post_tasks kan aktivera handlers från rollen, och rollen kan anropa handlers från spelet. Men "cross-role" anrop av handlers orsakar en mycket större förvirring än att upprepa en trivial handler. (En annan del av bästa praxis är att försöka undvika att upprepa namn på handlers).

Huvudskillnaden är att en uppgift alltid utförs (idempotent) (plus/minus taggar och when), medan en handler utförs beroende på tillståndet (notify aktiveras endast om det har skett en förändring). Vad kan det leda till? Till exempel, vid en omkörning, om det inte har skett någon förändring, kommer inget handler att köras. Men varför kan det vara så att vi behöver utföra en handler när det inte har skett någon förändring i den genererande uppgiften? Till exempel, för att något gick sönder och det skedde en förändring, men exekveringen kom inte fram till handler. Till exempel, för att nätverket var nere en kort stund. Konfigurationen ändrades, tjänsten startades inte om. Vid nästa körning ändras konfigurationen inte längre, och tjänsten förblir med den gamla versionen av konfigurationen.

Situation med konfigurationen är inte lösbar (eller snarare kan man själva hitta på ett speciellt omstartprotokoll med filflaggor osv., men det är inte längre 'grundläggande ansible' i något avseende). Men det finns en annan vanlig historia: vi installerade en applikation, antecknade dess .service-fil, och nu vill vi daemon_reload och state=started. Och den naturliga platsen för detta verkar vara en handler. Men om man gör det till en task i slutet av tasklistan eller en roll, så kommer den att utföras idempotent varje gång. Även om playbooken skulle gå sönder på mitten. Detta löser inte problemet med restarted (man kan inte göra en task med attributet restarted, eftersom idempotensen skulle gå förlorad), men det är absolut värt att sätta state=started, den övergripande stabiliteten i playbooks ökar, eftersom antalet kopplingar och dynamiskt tillstånd minskar.

En annan positiv egenskap hos handlern är att den inte skräpar ner utskriften. Inga förändringar – inga onödiga skipped eller ok i utskriften – lättare att läsa. Det är också en negativ egenskap – om du hittar ett stavfel i en linjärt exekverad task vid första körningen, kommer handlers endast att köras vid ändringar, det vill säga under vissa förutsättningar – mycket sällan. Till exempel första gången i livet efter fem år. Och naturligtvis kommer det att finnas ett stavfel i namnet och allt kommer att gå sönder. Vid andra körningen kan de inte startas – det finns ju ingen ändring.

Man måste särskilt nämna tillgången till variabler. Till exempel, om du notifierar för en task med en loop, vad kommer att hända med variablerna? Man kan gissa analytiskt, men det är inte alltid trivialt, särskilt om variablerna kommer från olika källor.

… Så handlers är långt mindre användbara och mycket mer problematiska än de verkar. Om man kan skriva något snyggt (utan krusiduller) utan handlers, är det bättre att göra det utan dem. Om det inte går att få det snyggt – är det bättre att använda dem.

Den insiktsfulle läsaren påpekar med rätta att vi inte har diskuterat lyssna, att en handler kan anropa notify för en annan handler, att en handler kan innehålla import_tasks (som kan göra include_role med with_items), att systemet med handlers i Ansible är turing-komplett, att handlers från include_role märkligt nog korsas med handlers från play och så vidare – allt detta är uppenbarligen inte "grunderna").

Även om det finns ett visst WTF, som faktiskt är en funktion, och som man måste komma ihåg. Om du har en task som körs med delegate_to och den har notify, så körs den motsvarande handlern utan delegate_to, det vill säga på den värd där play är tilldelad. (Även om handlern, naturligtvis, kan ha delegate_to också).

Separat vill jag nämna några ord om återanvändbara roller. Innan kollektionerna kom fanns det en idé om att man skulle kunna skapa universella roller som kan ansible-galaxy install och så åkte jag. Fungerar på alla operativsystem i alla varianter i alla situationer. Så, min åsikt: det fungerar inte. Varje roll med stöd för 100500 fall är dömd till avgrunder av corner case-buggar. include_varsDe kan täppas till med massiv testning, men som med all testning, antingen har du ett kartegiskt produkt av ingångsvärden och en total funktion, eller så har du "täcker enskilda scenarier". Min åsikt är - det är mycket bättre om rollen är linjär (cyklomatisk komplexitet 1).

Ju färre if:s (öppna eller deklarativa - i form av when eller form include_vars baserat på uppsättningen av variabler), desto bättre är rollen. Ibland måste man göra förgreningar, men, jag upprepar, ju färre desto bättre. Så en till synes bra roll med galaxy (den fungerar ju!) med en massa when kan vara mindre önskvärd än "sin" roll med fem uppgifter. Momentet när rollen med galaxy är bättre - när du börjar skriva något. Momentet när den blir sämre - när något går sönder, och du har misstankar om att det beror på "rollen med galaxy". Du öppnar den, och där är fem inkluderade, åtta uppgiftslistor och en hög when‘or ... Och detta måste du reda ut. Istället för 5 uppgifter i en linjär lista, där det knappt finns något att gå sönder.

I de följande delarna

• Lite om inventering, gruppvariabler, host_group_vars-plugin, hostvars. Hur man knyter ihop spagettin till en Gordisk knut. Scope och precedens för variabler, Ansible-minnesmodell. "Så var ska man egentligen lagra användarnamnet för databasen?".
• jinja: {{ jinja }} — nosql notype nonsens mjukt lera. Det finns överallt, även där du minst anar det. Lite om !!unsafe och läcker yaml.

Källa: habr.com