🥇Zrýchľujeme Ansible

Nie je to tajomstvom, že s nastaveniami "predvolené" Ansible môže vykonávať svoju prácu nie príliš rýchlo. V článku poukazujem na niekoľko dôvodov tohto stavu a navrhnem užitočné minimálne nastavenia, ktoré môžu reálne zvýšiť rýchlosť fungovania vášho projektu.

Diskutujeme tu a ďalej o Ansible 2.9.x, ktorý bol nainštalovaný vo freshly created virtualenv vašim obľúbeným spôsobom.

Po inštalácii vytvoríme vedľa vášho playbooku súbor „ansible.cfg“ — také umiestnenie umožní prenášať tieto nastavenia spolu s projektom, navyše sa načítajú úplne automaticky.

Pipeline-ovanie

O tom, že je potrebné používať pipelining, teda nie kopírovanie modulov do FS cieľového systému, ale prenos zabaleného v Base64 zip-archíve priamo na stdin interpretera Python, mohol už niekto počuť, a niekto nie, ale fakt zostáva faktom: toto nastavenie naďalej zostáva nedocenené. Bohužiaľ, niektoré z populárnych distribúcií Linux predvolene predtým nastavovali sudo nie veľmi dobre – tak, že tento príkaz vyžadoval prítomnosť tty (terminálu), preto v Ansible toto veľmi užitočné nastavenie ostalo vypnuté predvolene.

pipelining = True

Zber faktov

Viete, že s predvolenými nastaveniami Ansible pre každý play iniciuje zber faktov zo všetkých hostiteľov, ktorí sa na ňom podieľajú? V skratke, ak ste nevedeli, tak teraz viete. Aby sa tomu zabránilo, je potrebné zapnúť buď explicitný režim žiadosti o zber faktov, alebo režim smart. V ňom sa faktory budú zbierať len z tých hostiteľov, ktorí sa neobjavili v predchádzajúcich plays.
UPD. Pri kopírovaní si budete musieť vybrať z týchto nastavení niektoré.

gathering = smart|explicit

Opätovné používanie ssh pripojení

Ak ste niekedy spustili Ansible v režime zobrazovania ladících informácií (možnosť „v“, opakovaná od jedného do deviatich ráz), možno ste si všimli, že ssh pripojenia sa neustále vytvárajú a rozbíjajú. Takže tu tiež existuje pár nuance.

Vyhnúť sa fáze opätovnej inštalácie ssh pripojenia je možné na dvoch úrovniach naraz: a to priamo v klientovi ssh, a pri prenose súborov na riadený hostiteľ z riadiaceho.
Na opätovné využitie otvoreného ssh spojenia stačí jednoducho preniesť potrebné kľúče ssh klientovi. Ten začne robiť nasledujúce: pri prvom nastavení ssh spojenia navyše vytvorí takzvaný control socket, pri nasledujúcich — overuje existenciu tohto socketu, a ak je úspešne, opätovne použije existujúce ssh spojenie. A aby to malo zmysel, nastavíme čas uchovania spojenia pri neaktívnosti. Viac informácií nájdete v dokumentácii k ssh, a v kontexte Ansible jednoducho používame "prenos" potrebných možností ssh klientovi.

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

Na opätovné využitie už otvoreného ssh spojenia pri prenose súborov na riadený host stačí uviesť ešte jednu neznámu nastavenie ssh_transfer_method. Dokumentácia k tomu je veľmi stručná a uvádza do omylu, pretože táto voľba je skutočne funkčná! Ale čítanie zdrojového kódu umožňuje pochopiť, čo sa presne bude diať: na riadenom hoste sa spustí príkaz dd, ktorý priamo pracuje s potrebným súborom.

transfer_method = piped

Mimochodom, vo vetve „develop“ táto nastavenie tiež existuje a nikam nezmizla.

Noža sa neboj, boj sa vidlice

Ďalšie užitočné nastavenie sú forks. Určuje počet pracovných procesov, ktoré sa spojí s hostiteľmi a vykonajú úlohy. Z dôvodov Pythonu ako programovacieho jazyka sa používajú práve procesy, nie vlákna, pretože Ansible stále podporuje Python 2.7 — žiadne asyncio, nič tu asynchronne nevytváraj! Predvolene Ansible spúšťa päť pracovníkov, ale ak správne požiadate, môže ich spustiť viac:

forks = 20

Iba vás hneď varujem, že tu môžu nastať niektoré komplikácie súvisiace s množstvom pamäte na správcovskom stroji. Inými slovami, nastaviť forks=100500 je síce možné, ale kto povedal, že to bude fungovať?

Zhrňme to všetko dohromady

Nakoniec môžu potrebné nastavenia pre ansible.cfg (ini formát) vyzerať takto:

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

A ak chceš všetko skryť v normálnom YAML inventári zdravého človeka, môže vyzerať približne takto:

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

Žiaľ, pri nastaveniach „gathering = smart/explicit“ a „forks = 20“ to nebude fungovať: neexistujú ich ekvivalenty v YaML. Buď ich nastavíme v ansible.cfg, alebo ich predáme cez environmentálne premenné ANSIBLE_GATHERING a ANSIBLE_FORKS.

O Mitogene
— A kde tu je o Mitogene? — môže sa spýtaťš, vážený čitateľ. V tomto článku — nikde. Ale ak si naozaj pripravený čítať jeho kód a zistiť, prečo sa tvoj playbook zrúti s Mitogenom, zatiaľ čo s vanilkovým Ansible funguje normálne, alebo prečo tento istý playbook doteraz bez problémov fungoval, a po aktualizácii začal robiť čudnosti — čo už, Mitogen potenciálne môže byť tvojim nástrojom. Používaj ho, rozoberaj ho, píš články — prečítam ich s záujmom.

Prečo osobne ja nepoužívam Mitogen? Pretože funguje, len keď sú úlohy skutočne jednoduché a všetko ide hladko. Avšak ak sa trochu odkloníš doľava alebo doprava — všetko, prišli sme: na odpoveď sa na teba hrnie hromada nejasných výnimiek, a aby sa obraz uzavrel, chýba len obvyklá fráza „všetkým ďakujem, všetci sú voľní“. V podstate, jednoducho nechcem strácať čas zistením príčin ďalšieho „podzemného úderu“.

Časť týchto nastavení bola objavená počas čítania zdrojového kódu pripojovacieho pluginu s výstižným názvom „ssh.py“. Zdieľam výsledky čítania v nádeji, že to inšpiruje ďalších, aby sa pozreli do zdrojov, čítali ich, overovali implementáciu, porovnávali s dokumentáciou — veď to všetko prinesie skôr či neskôr pozitívne výsledky. Veľa šťastia!

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.