🥇Zrychlujeme Ansible

Není to žádné tajemství, že s výchozími nastaveními Ansible nemusí být jeho výkon příliš rychlý. V tomto článku upozorním na několik důvodů a navrhnu užitečné minimální úpravy, které mohou skutečně zvýšit rychlost vašeho projektu.

Zde a dále diskutujeme Ansible 2.9.x, který byl nainstalován do čerstvě vytvořeného virtualenv oblíbeným způsobem.

Po instalaci vytvořte vedle vašeho playbooku soubor «ansible.cfg» — toto umístění umožní přenášet nastavení spolu s projektem a budou se automaticky načítat.

Pipeline

To, že je třeba používat pipelining, tedy nikoli kopírování modulů do souborového systému cílového systému, ale předávání zip archivu obaleného v Base64 přímo na stdin interpretátoru Python, už někteří slyšeli, jiní ne, ale faktem zůstává, že: toto nastavení se stále podceňuje. Bohužel, některé populární distribuce Linuxu nastavovaly sudo výchozí špatně — a to tak, že tento příkaz vyžadoval přítomnost tty (terminálu), takže v Ansible tuto velmi užitečnou funkci ponechali výchozí nastavení vypnutou.

pipelining = True

Shromažďování faktů

Víte, že s výchozími nastaveními Ansible pro každý play iniciuje shromažďování faktů ze všech zapojených hostitelů? Pokud jste to nevěděli, nyní víte. Aby se tomu zabránilo, je třeba povolit buď explicitní režim shromažďování faktů, nebo inteligentní režim. V něm se fakta shromažďují pouze z hostitelů, kteří se v předchozích plays nevyskytovali.
UPD. Při kopírování budete muset vybrat jedno z těchto nastavení.

gathering = smart|explicit

Opětovné používání ssh spojení

Pokud jste někdy spouštěli Ansible v režimu výstupu ladících informací (volba «v» opakovaně od jednou do devíti krát), možná jste si všimli, že ssh spojení se neustále navazuje a přerušuje. I zde existuje pár nuancí.

Zamezení opětovné instalace ssh spojení lze dosáhnout na dvou úrovních současně: jak v klientu ssh, tak při přenosu souborů na řízený hostitel z řídícího zařízení.
Pro opětovné použití otevřeného ssh připojení stačí jednoduše předat požadované klíče ssh klientovi. Poté začne dělat následující: při prvním navázání ssh připojení navíc vytvoří takzvaný control socket, při následných pak zkontroluje existenci tohoto socketu, a pokud je úspěšný, znovu použije existující ssh připojení. Aby to mělo smysl, nastavíme čas pro uchování připojení při neaktivitě. Více si můžete přečíst v dokumentaci k ssh, a v kontextu Ansible jednoduše používáme "prohození" potřebných voleb ssh klientovi.

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

Pro opětovné použití již otevřeného ssh připojení při přenosu souborů na spravovaný host stačí uvést ještě jednu neznámou nastavení ssh_transfer_method. Dokumentace k tomuto je extrémně nejasná a zavádějící, neboť tato volba je plně funkční! Zato čtení zdrojového kódu umožňuje pochopit, co se přesně bude dít: na spravovaném hostu bude spuštěn příkaz dd, který přímo pracuje s požadovaným souborem.

transfer_method = piped

Mimochodem, v větvi "develop" toto nastavení také existuje a nikam nezmizelo.

Neboj se nože, boj se vidlici

Další užitečné nastavení — forks. To určuje počet pracovních procesů, které se budou současně připojovat k hostům a vykonávat úkoly. Vzhledem k vlastnostem Pythonu jako programovacího jazyka se používají právě procesy, nikoli vlákna, protože Ansible stále podporuje Python 2.7 — žádný asyncio, tady není potřeba rozvářet asynchronní zpracování! Výchozí počet prostředníků v Ansible je pět pracovníků, ale pokud požádáte správně, může spustit více:

forks = 20

Jen hned varuji, že tady mohou nastat určité komplikace spojené s dostupným objemem paměti na správním stroji. Jinými slovy, nastavit forks=100500 je samozřejmě možné, ale kdo říkal, že to bude fungovat?

Shrneme to dohromady

Konečně, pro ansible.cfg (ini formát) potřebná nastavení by mohla vypadat takto:

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

A pokud chceš všechno schovat do normálního YaML inventáře zdravého člověka, může to vypadat asi takto:

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

Bohužel, s nastavením „gathering = smart/explicit“ a „forks = 20“ to neprojde: jejich YaML ekvivalenty neexistují. Buď je nastavíme v ansible.cfg, nebo je předáme prostřednictvím proměnných prostředí ANSIBLE_GATHERING a ANSIBLE_FORKS.

O Mitogenu
— A kde je zde o Mitogenu? — můžeš se ptát, vážený čtenáři. V tomto článku — nikde. Ale pokud jsi skutečně připraven číst jeho kód a zkoumat, proč tvůj playbook selhává s Mitogenem, zatímco s vanilkovým Ansible funguje v pořádku, nebo proč tento stejný playbook doteď bezchybně fungoval a po aktualizaci začal fungovat zvláštně — co, Mitogen by mohl být tvým nástrojem. Používej ho, zkoumej, piš články — rád si je přečtu.

Proč osobně já nepoužívám Mitogen? Protože to funguje pouze, když jsou úkoly skutečně jednoduché a všechno je v pořádku. Ale jakmile se trochu odchýlíš doleva nebo doprava — to je konec: na tebe letí hromada nejasných výjimek a k dokreslení obrazu chybí jen okřídlená fráze „děkujeme všem, všichni jsou svobodní“. Stručně řečeno, nechci trávit čas zkoumáním příčin dalšího „podzemního úderu“.

Některá z těchto nastavení byla objevena při čtení zdrojového kódu pluginu connection s výmluvným názvem „ssh.py“. Výsledky čtení sdílím v naději, že to inspiruje někoho, aby se podíval na zdrojové kódy, četl je, ověřoval realizaci a porovnával s dokumentací — vždyť to přinese pozitivní výsledky. Hodně štěstí!

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.