🥇Ansible versnellen

Het is geen geheim dat Ansible met de standaardinstellingen zijn werk niet zo snel kan doen. In het artikel zal ik verschillende redenen hiervoor aanwijzen en een nuttig minimum aan instellingen aanbieden die mogelijk de snelheid van uw project daadwerkelijk zullen verhogen.

Hier en hieronder bespreken we Ansible 2.9.x, dat op jouw favoriete manier in een nieuw gemaakte virtuele omgeving is geïnstalleerd.

Na de installatie maakt u een “ansible.cfg”-bestand aan naast uw playbook - op deze locatie kunt u deze instellingen samen met het project overbrengen, en ze worden geheel automatisch geladen.

Pijpleidingen

Sommigen hebben misschien al gehoord van de noodzaak om pipelining te gebruiken, dat wil zeggen, het niet kopiëren van modules naar het bestandssysteem van het doelsysteem, maar het rechtstreeks overbrengen van een zip-archief verpakt in Base64 naar de stdin van de Python-interpreter, maar anderen misschien niet, maar het feit blijft een feit: deze instelling wordt nog steeds onderschat. Helaas waren sommige van de populaire Linux-distributies die gebruikt werden om sudo standaard niet zo goed te configureren - zodat deze opdracht een tty (terminal) vereiste, dus liet Ansible deze zeer nuttige instelling standaard uitgeschakeld.

pipelining = True

Feiten verzamelen

Wist je dat Ansible bij standaardinstellingen voor elk spel het verzamelen van feiten initieert voor alle hosts die eraan deelnemen? Over het algemeen geldt: als je het nog niet wist, weet je het nu. Om dit te voorkomen, moet u de expliciete verzoekmodus voor het verzamelen van feiten (expliciet) of de slimme modus inschakelen. Daarin worden alleen feiten verzameld van die hosts die niet in eerdere toneelstukken zijn aangetroffen.
UPD. Bij het kopiëren moet u een van deze instellingen selecteren.

gathering = smart|explicit

Ssh-verbindingen hergebruiken

Als je Ansible ooit in de foutopsporingsmodus hebt uitgevoerd (de optie "v", één tot negen keer herhaald), is het je misschien opgevallen dat er voortdurend ssh-verbindingen worden gemaakt en verbroken. Er zijn dus ook hier een paar subtiliteiten.

U kunt de stap vermijden van het opnieuw tot stand brengen van een ssh-verbinding op twee niveaus tegelijk: zowel rechtstreeks in de ssh-client als bij het overbrengen van bestanden naar de beheerde host vanuit de manager.
Om een open ssh-verbinding opnieuw te gebruiken, geeft u eenvoudigweg de benodigde sleutels door aan de ssh-client. Vervolgens zal het het volgende gaan doen: wanneer het voor de eerste keer een ssh-verbinding tot stand brengt, zal het bovendien een zogenaamde control socket creëren, bij volgende installaties zal het het bestaan van deze socket controleren en, indien succesvol, de socket opnieuw gebruiken. bestaande ssh-verbinding. En om dit allemaal logisch te maken, stellen we de tijd in voor het onderhouden van de verbinding wanneer deze inactief is. Je kunt er meer over lezen ssh-documentatie, en in de context van Ansible gebruiken we simpelweg het “doorsturen” van de benodigde opties naar de ssh-client.

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

Om een reeds geopende ssh-verbinding te hergebruiken bij het overbrengen van bestanden naar een beheerde host, geeft u gewoon een andere onbekende instelling ssh_tranfer_method op. De documentatie over dit onderwerp is uiterst gierig en misleidend, want deze optie werkt best goed! Maar lezen broncode Hiermee kunt u begrijpen wat er precies zal gebeuren: de opdracht dd wordt gelanceerd op de beheerde host en werkt rechtstreeks met het gewenste bestand.

transfer_method = piped

Overigens bestaat deze instelling ook in de “develop”-tak nergens heengaan.

Wees niet bang voor het mes, wees bang voor de vork

Een andere handige instelling zijn vorken. Het bepaalt het aantal werkprocessen dat tegelijkertijd verbinding maakt met hosts en taken uitvoert. Vanwege de eigenaardigheden van Python als taal worden er processen gebruikt en geen threads, omdat Ansible nog steeds Python 2.7 ondersteunt - geen asyncio voor jou, het heeft geen zin om hier asynchroon gedrag te introduceren! Standaard wordt Ansible uitgevoerd vijf werknemers, maar als het juist wordt gevraagd, zal het meer lanceren:

forks = 20

Ik waarschuw u meteen dat er hier enkele problemen kunnen zijn die verband houden met de beschikbare hoeveelheid geheugen op de besturingsmachine. Met andere woorden, je kunt natuurlijk forks=100500 instellen, maar wie zei dat dit zou werken?

Alles op een rij zetten

Als gevolg hiervan kunnen de benodigde instellingen voor ansible.cfg (ini-indeling) er als volgt 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 verbergen in een normale YaML-inventaris van een gezond persoon, dan 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 zal dit niet werken met de instellingen “gathering = smart/explicit” en “forks = 20”: hun YaML-equivalenten bestaan niet. Ofwel plaatsen we ze in ansible.cfg, ofwel geven we ze door via de omgevingsvariabelen ANSIBLE_GATHERING en ANSIBLE_FORKS.

Over Mitogen
- Waar gaat dit over Mitogen? - u heeft het recht om dit te vragen, beste lezer. Nergens in dit artikel. Maar als je echt klaar bent om de code te lezen en erachter te komen waarom je playbook crasht met Mitogen, maar prima werkt met vanilla Ansible, of waarom hetzelfde playbook voorheen prima werkte, maar na een update vreemde dingen begon te doen - nou, Mitogen zou mogelijk uw hulpmiddel kunnen zijn. Pas het toe, begrijp het, schrijf artikelen - ik zal het met interesse lezen.

Waarom gebruik ik Mitogen niet persoonlijk? Omdat gladiolen het alleen werkt zolang de taken heel eenvoudig zijn en alles in orde is. Als je echter een beetje naar links of rechts draait - dat is alles, we zijn er: als reactie vliegen een handvol onduidelijke uitzonderingen op je af, en om het plaatje compleet te maken, ontbreekt alleen de algemene zin "bedankt allemaal , iedereen is vrij.” Over het algemeen wil ik gewoon geen tijd verspillen aan het achterhalen van de redenen voor de volgende “ondergrondse klop”.

Sommige van deze instellingen zijn ontdekt tijdens het leesproces broncode verbindingsplug-in onder de voor zichzelf sprekende naam “ssh.py”. Ik deel de resultaten van het lezen in de hoop dat het iemand anders zal inspireren om naar de bronnen te kijken, ze te lezen, de implementatie te controleren, te vergelijken met de documentatie - dit alles zal je vroeg of laat immers positieve resultaten opleveren. Succes!

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Welke van de volgende Ansible-instellingen gebruikt u om uw projecten te versnellen?

69,6%pijplijnen=true32
34,8%verzamelen = slim/expliciet16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%transfer_method = doorgesluisd8
63,0%vorken = XXX29
6,5%Niets van dit alles, alleen Mitogen3
8,7%Mitogen + Ik noteer welke van deze instellingen4

46 gebruikers hebben gestemd. 21 gebruiker onthield zich van stemming.

Wil je meer informatie over Ansible?

78,3%ja, natuurlijk54
21,7%ja, ik wil gewoon meer hardcore dingen!15
0,0%nee, en het is niet voor niets nodig0
0,0%nee, het is ingewikkeld!!!0

69 gebruikers hebben gestemd. 7 gebruikers onthielden zich van stemming.

Bron: www.habr.com

Ansible versnellen