🥇Pospešitev Ansible

Ni skrivnost, da lahko Ansible z nastavitvami „privzeto“ ne deluje pretirano hitro. V članku bom izpostavil nekaj vzrokov za to in predlagal koristno minimalno nastavitev, ki lahko dejansko poveča hitrost delovanja vašega projekta.

Tukaj in naprej razpravljamo o Ansible 2.9.x, ki je bil nameščen v sveže ustvarjen virtualenv na vaš priljubljen način.

Po namestitvi ustvarite datoteko „ansible.cfg“ poleg vašega playbooka — taka postavitev omogoča prenos teh nastavitev skupaj s projektom, poleg tega pa se bodo naložile avto-magično.

Cevna obdelava

O tem, da je treba uporabljati pipelining, torej ne kopirati modulov v datotečni sistem ciljne naprave, ampak posredovati zavit Base64 zip arhiv neposredno na stdin Pythonovega interpreterja, je morda že slišal nekdo, nekdo drug pa ne. Kakor koli že, dejstvo ostaja: ta nastavitev pa ostaja še vedno podcenjena. Na žalost je nekaterih priljubljenih distribucij Linuxa privzeto nastavilo sudo precej slabo — tako, da je ta ukaz zahteval prisotnost tty (terminala), zato so v Ansible to zelo koristno nastavitev pustili izključeno privzeto.

pipelining = True

Zbiranje dejstev

Ali ste vedeli, da Ansible z privzetimi nastavitvami za vsak play sproži zbiranje dejstev za vse gostitelje, ki v njem sodelujejo? Na splošno, če niste vedeli, zdaj veste. Da se to ne bi dogajalo, je treba vključiti ali način eksplicitnega zahtevka za zbiranje dejstev (explicit) ali način smart. V tem načinu se bodo dejstva zbirala le s tistih gostiteljev, ki se v prejšnjih playih niso pojavili.
UPD. Pri kopiranju boste morali iz teh nastavitev izbrati eno samo.

gathering = smart|explicit

Ponovna uporaba ssh povezav

Če ste kdaj zagnali Ansible v načinu nalaganja podrobnih informacij (možnost „v“, ponovljena od enega do devetkrat), ste morda opazili, da se ssh povezave nenehno vzpostavljajo in prekinjajo. No, tukaj obstajata tudi dve tanki plati.

Izogniti se fazi ponovne namestitve ssh povezave je mogoče na dveh ravneh hkrati: tako neposredno v odjemalcu ssh, kot tudi pri prenosu datotek na upravljani gostitelj iz upravljavca.
Za ponovno uporabo odprtega ssh-povezave je dovolj, da preprosto predamo ustrezne ključe ssh-odjemalcu. Tako bo začel početi naslednje: pri prvem vzpostavljanju ssh-povezave dodatno ustvari tako imenovani kontrolni soket, pri naslednjih pa preveri obstoj tega soketa in ob uspehu ponovno uporabi obstoječo ssh-povezavo. Da bi to imelo smisel, določimo čas ohranjanja povezave pri neaktivnosti. Več lahko preberete v dokumentaciji o ssh, v kontekstu Ansible pa preprosto uporabimo „posredovanje“ potrebnih možnosti ssh-odjemalcu.

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

Za ponovno uporabo že odprte ssh-povezave pri prenosu datotek na upravljani računalnik je dovolj, da navedete še en neznani parameter ssh_transfer_method. Dokumentacija o tem je zelo revna in zavaja, saj je ta možnost povsem delujoča! A branje izvorne kode omogoča razumeti, kaj se bo zgodilo: na upravljanem računalniku bo zagnana ukaz dd, ki neposredno deluje s potrebno datoteko.

transfer_method = piped

Mimogrede, v veji „develop“ ta parameter prav tako obstaja in ni izginil.

Ne boj se noža, boj se vilic

Še en uporabni parameter je forks. Ta določa število delovnih procesov, ki se bodo hkrati povezali z računalniki in izvajali naloge. Zaradi značilnosti Pythona kot programski jezik se uporabljajo prav procesi, ne niti, saj Ansible še vedno podpira Python 2.7 – brez asyncio, tukaj ni potrebe po asinkronosti! Privzeto Ansible zažene pet delavcev, vendar jih lahko po pravilnem povpraševanju zažene več:

forks = 20

Takole takoj opozarjam, da lahko pride do nekaterih težav v zvezi s količino pomnilnika na upravljalnem računalniku. Drugimi besedami, nastavitev forks=100500 je seveda možna, a kdo je rekel, da bo delovalo?

Zberemo vse skupaj

Tako so potrebne nastavitve za ansible.cfg (ini-format) lahko videti takole:

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

In če želiš vse skriti v normalen YaML-inventar zdravega človeka, lahko izgleda nekako tako:

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

Žal, z nastavitvami „gathering = smart/explicit“ in „forks = 20“ to ne bo delovalo: njihov YaML ekvivalent ne obstaja. Bodisi jih določimo v ansible.cfg, bodisi jih predamo preko okoljevarnih spremenljivk ANSIBLE_GATHERING in ANSIBLE_FORKS.

O Mitogenu
— A kjer tukaj piše o Mitogenu? — se lahko vprašaš, spoštovani bralec. V tem članku — nikjer. Ampak, če si resnično pripravljen prebrati njegovo kodo in se poglobiti, zakaj tvoj playbook pade z Mitogenom, medtem ko z vanilijevim Ansible deluje normalno, ali zakaj je ta isti playbook do sedaj deloval brez težav, po posodobitvi pa se obnaša nenavadno — no, Mitogen ti potencialno lahko služi kot orodje. Uporabi ga, razišči, napiši članke — z zanimanjem jih bom prebral.

Zakaj osebno ne uporabljam Mitogena? Ker deluje le, dokler so naloge res preproste in vse teče kot po maslu. Ko pa se malce odmakneš levo ali desno — to je to: vate letijo kupi nerazumljivih izjem, za popolno sliko pa primanjkuje le še fraze „vsem hvala, vsi so svobodni“. Na splošno, enostavno ne želim trošiti časa na ugotavljanje razlogov za ponovno „podzemsko pokanje“.

Nekatere od teh nastavitev so bile odkrite med branjem izvorne kode vtičnika za povezavo z zgovornim imenom „ssh.py“. Rezultati branja delim v upanju, da bo to navdihnilo še koga, da pogleda v izvorno kodo, jo prebere, preveri implementacijo in primerja z dokumentacijo — saj vam bo to prej ali slej prineslo pozitivne rezultate. Veliko sreče!

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite se, molim vas.