🥇 Snabba upp Ansible

Det är ingen hemlighet att med standardinställningarna kan Ansible inte göra sitt jobb särskilt snabbt. I artikeln kommer jag att peka på flera anledningar till detta och erbjuda ett användbart minimum av inställningar som, mycket möjligt, faktiskt kommer att öka hastigheten på ditt projekt.

Här och nedan diskuterar vi Ansible 2.9.x, som installerades i en nyskapad virtualenv på ditt favoritsätt.

Efter installationen, skapa en "ansible.cfg" fil bredvid din spelbok - den här platsen låter dig överföra dessa inställningar tillsammans med projektet, plus att de laddas ganska automatiskt.

Pipelining

Vissa kanske redan har hört talas om behovet av att använda pipelining, det vill säga att inte kopiera moduler till målsystemets filsystem, utan att överföra ett zip-arkiv inslaget i Base64 direkt till stdin för Python-tolken, men andra kanske inte, men faktum förblir ett faktum: denna inställning är fortfarande underskattad. Tyvärr är några av de populära Linux-distributionerna som används för att konfigurera sudo inte särskilt bra som standard - så att detta kommando krävde en tty (terminal), så Ansible lämnade denna mycket användbara inställning inaktiverad som standard.

pipelining = True

Samla fakta

Visste du att med standardinställningar initierar Ansible för varje pjäs insamlingen av fakta för alla värdar som deltar i det? I allmänhet, om du inte visste, nu vet du det. För att förhindra att detta händer måste du aktivera antingen det explicita begäran-läget för att samla in fakta (explicit) eller det smarta läget. I den kommer fakta endast att samlas in från de värdar som inte har stött på i tidigare pjäser.
UPD. När du kopierar måste du välja en av dessa inställningar.

gathering = smart|explicit

Återanvända ssh-anslutningar

Om du någonsin har kört Ansible i felsökningsläge (alternativet "v", upprepat en till nio gånger), kanske du har märkt att ssh-anslutningar ständigt skapas och bryts. Så, det finns ett par finesser här också.

Du kan undvika steget att återupprätta en ssh-anslutning på två nivåer samtidigt: både direkt i ssh-klienten och när du överför filer till den hanterade värden från chefen.
För att återanvända en öppen ssh-anslutning skickar du helt enkelt de nödvändiga nycklarna till ssh-klienten. Sedan kommer den att börja göra följande: när den upprättar en ssh-anslutning för första gången, kommer den dessutom att skapa en så kallad kontrollsocket, vid efterföljande installationer kommer den att kontrollera existensen av just denna socket, och om den lyckas, återanvänd befintlig ssh-anslutning. Och för att göra allt detta vettigt, låt oss ställa in tiden för att upprätthålla anslutningen när den är inaktiv. Du kan läsa mer i ssh dokumentation, och i samband med Ansible använder vi helt enkelt "vidarebefordra" 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 när du överför filer till en hanterad värd, specificera bara en annan okänd inställning ssh_tranfer_method. Dokumentationen i detta ämne är extremt snål och missvisande, eftersom det här alternativet fungerar ganska bra! Men läsning källkod låter dig förstå exakt vad som kommer att hända: kommandot dd kommer att startas på den hanterade värden och arbetar direkt med den önskade filen.

transfer_method = piped

Förresten, i grenen "utveckla" finns denna inställning också går ingenstans.

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

En annan användbar inställning är gafflar. Den bestämmer antalet arbetsprocesser som samtidigt kommer att ansluta till värdar och utföra uppgifter. På grund av särdragen hos Python som språk används processer, inte trådar, eftersom Ansible fortfarande stöder Python 2.7 - ingen asyncio för dig, det är ingen idé att introducera asynkront beteende här! Som standard körs Ansible fem arbetare, men om den tillfrågas på rätt sätt kommer den att starta fler:

forks = 20

Jag varnar dig bara direkt att det kan finnas vissa svårigheter här relaterade till den tillgängliga mängden minne på kontrollmaskinen. Med andra ord, du kan givetvis ställa gafflar=100500, men vem har sagt att det skulle fungera?

Få alltid att falla på plats

Som ett resultat, 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 normal YaML-inventering av en frisk person, 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 kommer detta inte att fungera med inställningarna "gathering = smart/explicit" och "forks = 20": deras YaML-motsvarigheter finns inte. Antingen ställer vi in dem i ansible.cfg, eller så skickar vi dem genom miljövariablerna ANSIBLE_GATHERING och ANSIBLE_FORKS.

Om Mitogen
- Var är det här med Mitogen? - du har rätt att fråga, kära läsare. Ingenstans i denna artikel. Men om du verkligen är redo att läsa dess kod och ta reda på varför din spelbok kraschar med Mitogen, men fungerar bra med vanilj Ansible, eller varför samma spelbok fungerade bra innan, men efter en uppdatering började göra konstiga saker - ja, Mitogen kan potentiellt vara ditt verktyg. Använd det, förstå det, skriv artiklar - jag kommer att läsa det med intresse.

Varför använder jag inte Mitogen personligen? Eftersom gladiolus fungerar det bara så länge som uppgifterna är riktigt enkla och allt är bra. Men om du svänger lite åt vänster eller höger - det är det, vi har kommit fram: som svar flyger en handfull otydliga undantag mot dig, och för att göra bilden komplett är allt som saknas den vanliga frasen "tack alla , alla är fria." I allmänhet vill jag bara inte slösa tid på att ta reda på orsakerna till nästa "underjordiska knackning".

Några av dessa inställningar upptäcktes under läsningsprocessen källkod anslutningsplugin under det självförklarande namnet "ssh.py". Jag delar resultaten av läsningen i hopp om att det ska inspirera någon annan att titta på källorna, läsa dem, kontrollera implementeringen, jämföra med dokumentationen - trots allt kommer allt detta förr eller senare att ge dig positiva resultat. Lycka till!

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vilka av följande Ansible-inställningar använder du för att påskynda dina projekt?

69,6%pipelining=true32
34,8%insamling = smart/explicit16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%transfer_method = piped8
63,0%gafflar = XXX29
6,5%Inget av detta, bara Mitogen3
8,7%Mitogen + Jag kommer att notera vilka av dessa inställningar4

46 användare röstade. 21 användare avstod från att rösta.

Vill du ha mer saker om Ansible?

78,3%ja, självklart 54
21,7%ja, jag vill bara ha mer hardcore grejer!15
0,0%nej, och det är inte nödvändigt för ingenting0
0,0%nej, det är komplicerat!!!0

69 användare röstade. 7 användare avstod från att rösta.

Källa: will.com

Påskynda Ansible