🥇Versnelling voor Ansible

Het is geen geheim dat Ansible met de standaardinstellingen zijn werk niet altijd even snel doet. In dit artikel zal ik wijzen op enkele redenen hiervoor en een nuttig minimum aan instellingen voorstellen die de snelheid van uw project mogelijk aanzienlijk kunnen verhogen.

We bespreken hier en verder Ansible 2.9.x, dat is geïnstalleerd in een vers aangemaakt virtualenv op de door u favoriete manier.

Na installatie creëren we naast uw playbook het bestand "ansible.cfg" - die locatie maakt het mogelijk om deze instellingen samen met het project te verplaatsen, en bovendien zullen ze vrij automatisch worden geladen.

Pipeline-ing

Misschien heeft iemand al gehoord dat we pipelining moeten gebruiken, d.w.z. niet het kopiëren van modules naar het bestandssysteem van het doel-systeem, maar het direct doorgeven van een in Base64 verpakte zip-archief naar stdin van de Python-interpreter. Dit is een feit, ongeacht of iedereen het eerder gezien heeft. deze instelling blijft nog steeds ondergewaardeerd. Helaas configureert een aantal populaire Linux-distributies sudo standaard niet al te goed, waardoor deze opdracht een tty (terminal) vereiste, en daarom is deze zeer nuttige instelling in Ansible standaard uitgeschakeld gelaten.

pipelining = True

Feiten verzamelen

Wist u dat Ansible met de standaardinstellingen voor elke play feiten verzamelt van alle betrokken hosts? Als u dat nog niet wist, weet u het nu. Om dit te voorkomen, moet u ofwel de expliciete verzamelmodus inschakelen, of de slimme modus. In de slimme modus worden feiten alleen verzameld van die hosts die niet in eerdere plays voorkwamen.
UPD. Bij het kopiëren moet u een van deze instellingen kiezen.

gathering = smart|explicit

Herbruikbaarheid van ssh-verbindingen

Als u ooit Ansible heeft uitgevoerd in de modus voor debug-informatie (optie "v", die één tot negen keer herhaald kan worden), hebt u misschien opgemerkt dat ssh-verbindingen voortdurend worden opgezet en verbroken. Ook hier zijn enkele nuances.

Het vermijden van de stap om ssh-verbindingen opnieuw op te zetten kan op twee niveaus tegelijk: zowel in de ssh-client als bij het overdragen van bestanden naar de beheerde host vanaf de beheerder.
Voor het hergebruiken van een open ssh-verbinding is het voldoende om de benodigde sleutels gewoon door te geven aan de ssh-client. Dan zal deze het volgende doen: bij de eerste installatie van de ssh-verbinding een zogenaamde control socket aanmaken, en bij volgende verbindingen de aanwezigheid van deze socket controleren, en bij succes de bestaande ssh-verbinding hergebruiken. En om dit alles zinvol te maken, stellen we een tijdsduur in voor het bewaren van de verbinding bij inactiviteit. Meer hierover kan worden gelezen in de documentatie over ssh, en in de context van Ansible gebruiken we simpelweg de "doorvoer" van de benodigde opties aan de ssh-client.

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

Voor het hergebruiken van een al geopende ssh-verbinding bij het overdragen van bestanden naar de beheerde host, hoeft u slechts één onbekende instelling door te geven: ssh_transfer_method. De documentatie hierover is uiterst schraal en leidt tot verwarring, want deze optie werkt prima! Maar door te lezen broncode begrijp je wat er precies zal gebeuren: op de beheerde host wordt het dd-commando uitgevoerd dat rechtstreeks met het gewenste bestand werkt.

transfer_method = piped

Overigens, in de "develop"-tak bestaat deze instelling ook en is nergens heen gegaan.

Vrees de mes niet, vrees de vork

Een andere nuttige instelling is forks. Dit bepaalt het aantal werkprocessen dat tegelijk verbinding kan maken met hosts en taken kan uitvoeren. Vanwege de kenmerken van Python als programmeertaal worden hier processen en geen threads gebruikt, omdat Ansible nog steeds Python 2.7 ondersteunt — geen asyncio voor jou, hier hoeft geen asynchroniciteit te zijn! Standaard start Ansible vijf werkers, maar als je het goed vraagt, kan het er meer starten:

forks = 20

Ik waarschuw je echter alvast dat hier enkele complicaties kunnen optreden, afhankelijk van het beschikbare geheugen op de beheermachine. Met andere woorden, je kunt forks=100500 zetten, maar wie zegt dat het zal werken?

Laten we alles samenvatten

Uiteindelijk kunnen de benodigde instellingen voor ansible.cfg (ini-formaat) er zo uitzien:

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

En als je alles wilt verstoppen in een normaal YaML-inventaris voor een gezond persoon, kan het er ongeveer zo uitzien:

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

Helaas, met de instellingen 'gathering = smart/explicit' en 'forks = 20' gaat dit niet door: hun YaML-equivalenten bestaan niet. Of we definiëren ze in ansible.cfg, of we geven ze door via omgevingsvariabelen ANSIBLE_GATHERING en ANSIBLE_FORKS.

Over Mitogen
— Waar staat hier iets over Mitogen? — mag je je afvragen, beste lezer. In dit artikel — nergens. Maar als je daadwerkelijk bereid bent om zijn code te lezen en te begrijpen waarom jouw playbook faalt met Mitogen, terwijl het normaal werkt met de standaard Ansible, of waarom hetzelfde playbook tot nu toe goed functioneerde, maar na de update vreemd gedrag vertoont — dan is Mitogen mogelijk jouw tool. Pas het toe, onderzoek, schrijf artikelen — ik zal ze met interesse lezen.

Waarom ik persoonlijk Mitogen niet gebruik? Omdat het alleen werkt als de taken echt eenvoudig zijn en alles goed gaat. Maar zodra je iets naar links of rechts afwijkt — is het afgelopen: je krijgt een handvol onduidelijke uitzonderingen, en voor de voltooiing van het plaatje ontbreekt alleen de afgezaagde zin 'iedereen bedankt, iedereen is vrijgegeven'. Kortom, ik wil gewoon geen tijd verspillen aan het achterhalen van de oorzaak van weer een 'ondergronds geklop'.

Een deel van deze instellingen werd ontdekt tijdens het lezen van broncode de connection plugin met de sprekende naam 'ssh.py'. De resultaten van het lezen deel ik in de hoop dat dit anderen inspireert om in de source code te kijken, deze te lezen, de implementatie te controleren, deze te vergelijken met de documentatie — want dit zal vroeg of laat positieve resultaten opleveren. Veel succes!

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.