🥇 Fremskyndelse af Ansible

Det er ingen hemmelighed, at Ansible med standardindstillingerne ikke kan udføre sit arbejde særlig hurtigt. I artiklen vil jeg påpege flere årsager til dette og tilbyde et brugbart minimum af indstillinger, der med stor sandsynlighed faktisk vil øge hastigheden på dit projekt.

Her og nedenfor diskuterer vi Ansible 2.9.x, som blev installeret i en nyoprettet virtualenv på din foretrukne måde.

Efter installationen skal du oprette en "ansible.cfg" fil ved siden af din playbook - denne placering giver dig mulighed for at overføre disse indstillinger sammen med projektet, plus at de indlæses ret automatisk.

Rørføring

Nogle har måske allerede hørt om behovet for at bruge pipelining, det vil sige ikke at kopiere moduler til målsystemets filsystem, men at overføre et zip-arkiv pakket ind i Base64 direkte til stdin af Python-fortolkeren, men andre kan ikke, men det faktum forbliver et faktum: denne indstilling er stadig undervurderet. Desværre er nogle af de populære Linux-distributioner, der bruges til at konfigurere sudo, ikke særlig godt som standard - så denne kommando krævede en tty (terminal), så Ansible lod denne meget nyttige indstilling være deaktiveret som standard.

pipelining = True

Indsamling af fakta

Vidste du, at Ansible for hvert spil med standardindstillinger starter indsamlingen af fakta for alle værter, der deltager i det? Generelt, hvis du ikke vidste det, ved du det nu. For at forhindre dette i at ske, skal du aktivere enten den eksplicitte anmodningstilstand til indsamling af fakta (eksplicit) eller den smarte tilstand. I den vil fakta kun blive indsamlet fra de værter, der ikke blev stødt på i tidligere spil.
UPD. Når du kopierer, skal du vælge en af disse indstillinger.

gathering = smart|explicit

Genbrug af ssh-forbindelser

Hvis du nogensinde har kørt Ansible i debugging-tilstand (“v”-indstillingen, gentaget en til ni gange), har du måske bemærket, at ssh-forbindelser konstant bliver oprettet og brudt. Så der er også et par finesser her.

Du kan undgå trinnet med at genetablere en ssh-forbindelse på to niveauer på én gang: både direkte i ssh-klienten, og når du overfører filer til den administrerede vært fra manageren.
For at genbruge en åben ssh-forbindelse skal du blot videregive de nødvendige nøgler til ssh-klienten. Derefter vil den begynde at gøre følgende: når den etablerer en ssh-forbindelse for første gang, vil den desuden oprette en såkaldt kontrolsocket, ved efterfølgende installationer vil den kontrollere eksistensen af netop denne socket, og hvis det lykkes, genbrug eksisterende ssh-forbindelse. Og for at få det hele til at give mening, lad os indstille tidspunktet for opretholdelse af forbindelsen, når den er inaktiv. Du kan læse mere i ssh dokumentation, og i forbindelse med Ansible bruger vi blot "videresendelse" af de nødvendige muligheder til ssh-klienten.

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

For at genbruge en allerede åben ssh-forbindelse, når du overfører filer til en administreret vært, skal du blot angive en anden ukendt indstilling ssh_tranfer_method. Dokumentationen om dette emne er ekstrem nærig og vildledende, fordi denne mulighed fungerer ganske godt! Men læsning kildekode giver dig mulighed for at forstå, hvad der præcist vil ske: dd-kommandoen vil blive lanceret på den administrerede vært, der arbejder direkte med den ønskede fil.

transfer_method = piped

Forresten, i "udvikle"-grenen findes denne indstilling også går ingen steder hen.

Vær ikke bange for kniven, vær bange for gaflen

En anden nyttig indstilling er gafler. Det bestemmer antallet af arbejdsprocesser, der samtidigt vil oprette forbindelse til værter og udføre opgaver. På grund af de særlige kendetegn ved Python som sprog, bruges processer, ikke tråde, fordi Ansible stadig understøtter Python 2.7 - ingen asyncio for dig, der er ingen mening i at introducere asynkron adfærd her! Som standard kører Ansible fem arbejdere, men hvis de bliver spurgt rigtigt, vil den starte flere:

forks = 20

Jeg advarer dig lige med det samme om, at der kan være nogle vanskeligheder her relateret til den tilgængelige mængde hukommelse på styremaskinen. Med andre ord kan du selvfølgelig sætte gafler=100500, men hvem sagde det ville virke?

Samler det hele

Som følge heraf kan de nødvendige indstillinger for ansible.cfg (ini-format) se sådan ud:

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

Og hvis du vil skjule alt i en normal YaML-beholdning af en sund person, så kan det se sådan ud:

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

Desværre vil dette ikke fungere med indstillingerne "gathering = smart/explicit" og "forks = 20": deres YaML-ækvivalenter eksisterer ikke. Enten sætter vi dem i ansible.cfg, eller også sender vi dem gennem miljøvariablerne ANSIBLE_GATHERING og ANSIBLE_FORKS.

Om Mitogen
- Hvor er det her med Mitogen? - du har ret til at spørge, kære læser. Ingen steder i denne artikel. Men hvis du virkelig er klar til at læse dens kode og finde ud af, hvorfor din playbook går ned med Mitogen, men fungerer fint med vanilla Ansible, eller hvorfor den samme playbook fungerede fint før, men efter en opdatering begyndte at gøre mærkelige ting - ja, Mitogen kunne potentielt være dit værktøj. Anvend det, forstå det, skriv artikler - jeg vil læse det med interesse.

Hvorfor bruger jeg ikke personligt Mitogen? Fordi gladiolus virker det kun, så længe opgaverne er virkelig enkle og alt er i orden. Men hvis du drejer lidt til venstre eller højre - det er det, vi er nået: som svar flyver en håndfuld utydelige undtagelser mod dig, og for at fuldende billedet mangler der kun den almindelige sætning "tak allesammen , alle er frie." Generelt vil jeg bare ikke spilde tid på at finde ud af årsagerne til den næste "underjordiske bank".

Nogle af disse indstillinger blev opdaget under læseprocessen kildekode forbindelsesplugin under det selvforklarende navn "ssh.py". Jeg deler resultaterne af læsningen i håb om, at det vil inspirere en anden til at se på kilderne, læse dem, tjekke implementeringen, sammenligne med dokumentationen - før eller siden vil alt dette trods alt give dig positive resultater. Held og lykke!

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvilke af følgende Ansible-indstillinger bruger du til at fremskynde dine projekter?

69,6 %pipelining=true32
34,8 %indsamling = smart/eksplicit16
52,2 %ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4 %transfer_method = piped8
63,0 %gafler = XXX29
6,5 %Intet af dette, kun Mitogen3
8,7 %Mitogen + Jeg vil notere hvilke af disse indstillinger4

46 brugere stemte. 21 bruger undlod at stemme.

Vil du have flere ting om Ansible?

78,3 %ja, selvfølgelig 54
21,7 %ja, jeg vil bare have mere hardcore ting!15
0,0 %nej, og det er ikke nødvendigt for ingenting0
0,0 %nej, det er kompliceret!!!0

69 brugere stemte. 7 brugere undlod at stemme.

Kilde: www.habr.com

Fremskynder Ansible