🥇Snabbare Ansible

Det är ingen hemlighet att Ansible med standardinställningar kanske inte gör sitt jobb särskilt snabbt. I artikeln kommer jag att påpeka några orsaker till detta och föreslå ett nyttigt minimum av inställningar som möjligtvis kan öka hastigheten på ditt projekt.

Vi diskuterar här och framöver Ansible 2.9.x, som installerades i en ny skapad virtualenv på ditt favorit sätt.

Efter installationen skapar vi en fil "ansible.cfg" bredvid din playbook — en sådan placering gör det möjligt att flytta dessa inställningar med projektet, plus de kommer att laddas automatiskt.

Pipelinehantering

Att man bör använda pipelining, det vill säga att inte kopiera moduler till filsystemet i målmaskinen utan att överföra dem som en Base64-zipfil direkt till stdin för Python-tolkaren, har vissa kanske redan hört talas om, men faktum kvarstår: denna inställning är fortfarande undervärderad. Tyvärr har några populära Linux-distributioner tidigare konfigurerat sudo ganska dåligt som standard — så att detta kommando krävde en tty (terminal), så i Ansible lämnades denna mycket användbara inställning avstängd som standard.

pipelining = True

Insamling av fakta

Visste du att Ansible med standardinställningar initierar insamling av fakta för varje play på alla värdar som ingår? Om du inte visste det, så vet du det nu. För att förhindra detta kan man antingen aktivera det explicita läget för faktainsamling eller smartläge. I smartläget kommer fakta att samlas in endast från de värdar som inte har förekommit i tidigare plays.
UPD. Vid kopiering måste du välja en av dessa inställningar.

gathering = smart|explicit

Återanvändning av ssh-anslutningar

Om du någonsin har kört Ansible i debug-utdata-läge (med alternativet "v", upprepat mellan en och nio gånger), har du kanske märkt att ssh-anslutningar hela tiden upprättas och kopplas ner. Så här finns det också ett par nyanser.

Att undvika steget med att återinstallera ssh-anslutningen kan göras på två nivåer: både direkt i ssh-klienten och när filer överförs till den hanterade värden från styrenheten.
För att återanvända en öppen ssh-anslutning räcker det med att bara överföra de nödvändiga nycklarna till ssh-klienten. Då kommer den att göra följande: vid första installationen av ssh-anslutningen skapa en så kallad control socket, vid efterföljande anslutningar kontrollera existensen av just den socketen, och vid framgång återanvända den existerande ssh-anslutningen. För att detta ska ha mening ställer vi in tiden för att behålla anslutningen vid inaktivitet. Mer information kan läsas i dokumentationen för ssh, och i kontexten av Ansible använder vi helt enkelt "passera" de nödvändiga alternativen till ssh-klienten.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

För att återanvända en redan öppen ssh-anslutning vid överföring av filer till den hanterade värden är det tillräckligt att ange en ytterligare okänd inställning ssh_tranfer_method. Dokumentationen om detta är oerhört snåly och förvirrande, eftersom det här alternativet faktiskt fungerar! Men att läsa källkoden ger insikt i vad som faktiskt kommer att hända: på den hanterade värden kommer ett dd-kommando att köras som direkt arbetar med den nödvändiga filen.

transfer_method = piped

För övrigt finns den här inställningen också i "develop"-grenen och har inte försvunnit.

Var inte rädd för kniven, var rädd för gaffeln

En annan användbar inställning är forks. Den definierar antalet arbetsprocesser som kommer att ansluta till värdar och utföra uppgifter samtidigt. På grund av Python som programmeringsspråk används faktiskt processer, inte trådar, eftersom Ansible fortfarande stödjer Python 2.7 — ingen asyncio här, ingen anledning att sprida asynkronitet! Som standard startar Ansible fem arbetare, men om man ber om det på rätt sätt kan det starta fler:

forks = 20

Men jag varnar direkt för att det kan uppstå vissa problem kopplade till det befintliga minnesutrymmet på den styrande maskinen. Med andra ord, att sätta forks=100500 är förstås möjligt, men vem har sagt att det kommer att fungera?

Låt oss sammanfatta allt

Så för ansible.cfg (ini-format) kan de nödvändiga inställningarna se ut så här:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

Och om du vill gömma allt i en snygg YaML-inventering för en sund människa kan det se ut ungefär så här:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Tyvärr, med inställningarna «gathering = smart/explicit» och «forks = 20» kommer detta inte att fungera: deras YaML-ekvivalenter finns inte. Antingen definierar vi dem i ansible.cfg, eller så överför vi dem via miljövariabler ANSIBLE_GATHERING och ANSIBLE_FORKS.

Om Mitogen
— Men var är informationen om Mitogen här? — kan du fråga, kära läsare. I denna artikel finns den inte. Men om du verkligen är redo att läsa dess kod och förstå varför din playbook misslyckas med Mitogen, medan den fungerar normalt med det vanliga Ansible, eller varför samma playbook tidigare fungerade felfritt men efter en uppdatering nu beter sig märkligt — ja då kan Mitogen potentiellt vara ditt verktyg. Använd det, undersök det, skriv artiklar — jag kommer läsa med intresse.

Varför använder jag personligen inte Mitogen? För att det bara fungerar bra så länge uppgifterna är riktigt enkla och allt är i ordning. Men så fort man svänger lite åt vänster eller höger — då kommer en mängd otydliga undantag, och för att fullända bilden saknas bara den typiska frasen «tack alla, ni är fria». Så, jag vill helt enkelt inte spendera tid på att ta reda på orsakerna till ännu ett «underjordiskt ljud».

En del av dessa inställningar upptäcktes under läsningen källkoden av anslutningspluginen med det talande namnet «ssh.py». Resultaten från läsningen delar jag i hopp om att detta inspirerar flera att titta i källkoden, läsa den, verifiera implementationen, jämföra med dokumentationen — för allt detta kommer förr eller senare att ge positiva resultat. Lycka till!

Endast registrerade användare kan delta i omröstningen. Logga in, tack.