🥇Accelerer Ansible

Det er ingen hemmelighed, at Ansible med standardindstillingerne ikke altid arbejder særlig hurtigt. I artiklen vil jeg påpege flere årsager til dette og tilbyde et nyttigt minimum af indstillinger, som sandsynligvis kan øge hastigheden af dit projekt.

Vi diskuterer her og videre Ansible 2.9.x, som er installeret i det nyoprettede virtualenv på din foretrukne måde.

Efter installationen opretter vi en fil ved navn «ansible.cfg» ved siden af din playbook – sådan en placering gør det muligt at flytte disse indstillinger sammen med projektet, og de vil blive indlæst på en fuldstændig automatisk måde.

Pipelining

At det er nødvendigt at bruge pipelining, dvs. ikke at kopiere moduler til mål-systemets filsystem, men at sende en Base64-kodet zip-arkiv direkte til stdin på Python-fortolkeren, har nogle måske allerede hørt om, mens andre ikke har, men faktum er, at: denne indstilling fortsat er undervurderet. Desværre har nogle populære Linux-distributioner tidligere konfigureret sudo ikke særligt godt som standard – så det krævede tilstedeværelse af tty (terminal), hvorfor Ansible har efterladt denne meget nyttige indstilling deaktiveret som standard.

pipelining = True

Indsamling af fakta

Vidste du, at Ansible med standardindstillingerne indleder indsamlingen af fakta for hver play fra alle de værter, der er involveret? Generelt, hvis du ikke vidste det, ved du det nu. For at undgå at dette sker, skal du aktivere enten den eksplicitte anmode-mode for indsamling af fakta eller intelligent mode. I denne sidste indsamles fakta kun fra de værter, der ikke tidligere er blevet mødt i de forrige plays.
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 debug-output-tilstand (muligheden «v», gentaget fra en til ni gange), har du muligvis bemærket, at ssh-forbindelser konstant oprettes og brydes. Herudover findes der også et par detaljer.

Du kan undgå geninstallationsstadiet af ssh-forbindelsen på to niveauer samtidig: både direkte i ssh-klienten og ved overførsel af filer til den administrerede vært fra kontrollen.
For reuse of an open SSH connection, it is sufficient to simply pass the necessary keys to the SSH client. Then, it will start doing the following: upon the first establishment of the SSH connection, it will additionally create a so-called control socket. For subsequent connections, it will check the existence of that socket, and if successful, it will reuse the existing SSH connection. To make this all meaningful, let's set the connection retention time during inactivity. More details can be found in the SSH documentation, and in the context of Ansible, we simply use the 'forwarding' of the necessary options to the SSH client.

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

For reusing an already opened SSH connection when transferring files to the managed host, you just need to specify one more unknown setting, ssh_transfer_method. The documentation on this is extremely sparse and misleading, as this option indeed works! Instead, reading it af kildekode allows understanding what will happen: a command dd will be executed on the managed host, directly working with the required file.

transfer_method = piped

By the way, this setting also exists in the 'develop' branch and hasn't gone anywhere.

Don't fear the knife, fear the fork

Another useful setting is forks. It determines the number of worker processes that will connect to hosts and perform tasks simultaneously. Due to the peculiarities of Python as a programming language, processes are used rather than threads because Ansible still supports Python 2.7 — no asyncio here, let's not go for asynchrony! By default, Ansible launches five workers, but if properly requested, it can start more:

forks = 20

Just a heads up, there may be some complications related to the available memory on the controlling machine. In other words, while you can set forks=100500, who said it would work?

Let's sum it all up

In the end, the necessary settings for ansible.cfg (ini format) can look like this:

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

And if you want to hide everything in a proper healthy YaML inventory, it can look something like this:

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

Desværre vil indstillingerne «gathering = smart/explicit» og «forks = 20» ikke fungere: der findes ikke deres YaML-ækvivalenter. Enten angiver vi dem i ansible.cfg, eller vi sender dem gennem miljøvariablerne ANSIBLE_GATHERING og ANSIBLE_FORKS.

Om Mitogen
— Og hvor står der noget om Mitogen her? — kan du, kære læser, spørge. I denne artikel — ingen steder. Men hvis du virkelig er klar til at læse koden og finde ud af, hvorfor dit playbook fejler med Mitogen, mens det fungerer fint med den almindelige Ansible, eller hvorfor det samme playbook hidtil har fungeret, men efter opdateringen gør mærkelige ting — så kan Mitogen potentielt være dit redskab. Brug det, undersøg det, skriv artikler — jeg vil læse med interesse.

Hvorfor bruger jeg personligt ikke Mitogen? Fordi det kun fungerer, så længe opgaverne er virkelig enkle, og alt er i orden. Men så snart man drejer lidt til venstre eller højre — er det slut: i stedet modtager man en håndfuld uforståelige undtagelser, og for at fuldende billedet mangler kun den kendte sætning «tak til alle, alle er frie». Generelt vil jeg bare ikke bruge tid på at finde årsagerne til endnu et «underjordisk bankende».

Nogle af disse indstillinger blev opdaget under læsning af kildekode af forbindelsesplugin'et med det sigende navn «ssh.py». Resultaterne af læsningen deler jeg i håbet om, at det vil inspirere andre til at se på kildekoden, læse dem, tjekke implementeringen, sammenligne med dokumentationen — for alt dette vil før eller siden give dig positive resultater. Held og lykke!

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.