🥇Kiirendame Ansible'i

Kellelegi ei ole saladus, et vaikeseadetega Ansible ei suuda oma tööd alati kiiresti teha. Artiklis toon välja mitu selle põhjuseid ja pakun välja kasulikud seadistused, mis võivad teie projekti töö kiirus tõenäoliselt oluliselt suurendada.

Räägime siin ja edaspidi Ansible 2.9.x versioonist, mis on paigaldatud värskelt loodud virtualenvi teie lemmikviisil.

Pärast paigaldamist looge oma playbook'i kõrval fail „ansible.cfg“ — see asukoht võimaldab edastada neid seadistusi koos projektiga ning need laaditakse automaatselt.

Torujoonestamine

Kas olete kuulnud, et pipelining'i kasutamine, see tähendab moodulite mitte kopeerimist sihtruumi failisüsteemi, vaid Base64 zip-arhiivi edastamist otse Python'i tõlgendi stdin'isse, on tõhus? Fakt jääb faktiks: see seadistus et püsib endiselt alahinnatud. Kahjuks mõnes populaarsetes Linuxi distributsioonides ei olnud sudo vaikimisi hästi seadistatud — nii, et see käsk küsis tty (terminaali) olemasolu, seega jäeti Ansible's see väga kasulik seadistus vaikimisi välja.

pipelining = True

Faktide kogumine

Kas te teate, et vaikeseadetega Ansible käivitab iga play puhul faktide kogumise kõikide hostide osas, mis selles osalevad? Kui te ei teadnud, siis nüüd teate. Selle vältimiseks tuleb sisse lülitada kas faktide kogumise eksplitsiitne režiim või nutikas režiim. Viimases kogutakse fakti andmed ainult nendelt hostidelt, mida ei ole eelnevates play'des kohatud.
UPD. Kopeerimisel peate nendest seadistustest valima ainult ühe.

gathering = smart|explicit

SSH-ühenduste uuesti kasutamine

Kui olete kunagi käivitanud Ansible'i tõrkeotsingu režiimis (valik „v”, korduv alates ühest kuni deviteeni), siis olete võib-olla märganud, et SSH-ühendused pidevalt luuakse ja katkestatakse. Siingi on mõned nüansid.

SSH-ühenduse uuesti loomise etappi saab vältida kahel tasandil: nii SSH-klientis kui ka failide edastamisel hallatavale hostile haldurist.
Ava SSH-ühenduse taaskasutamiseks on piisav, kui edastada vajalikud võtmed SSH-klientile. Siis hakkab ta järgmist tegema: esimese SSH-ühenduse loomise ajal loob ta täiendavalt nii-öelda juhtimise pesase, järgmistel kordadel kontrollib ta olemasoleva pesase olemasolu ning eduka juhul kasutab ta olemasolevat SSH-ühendust uuesti. Et see kõik oleks mõistlik, määrame ühenduse säilitamise aja inaktiivsuse ajal. Täiendaval teabel saab lugeda SSH dokumentatsioonist, ja Ansible'i kontekstis kasutame me lihtsalt "vajalike valikute edastamist" SSH-klientile.

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

Töötava SSH-ühenduse taaskasutamiseks failide edastamisel hallatavale hostile tuleb lihtsalt määrata veel üks tundmatu seadistus ssh_transfer_method. Dokumentatsioon selle kohta on äärmiselt napakas ja eksitav, sest see valik töötab kenasti! Samuti lugemine allikakoodist aitab mõista, mis täpselt toimuma hakkab: hallataval hostil käivitatakse dd käsk, mis töötab otse vajaliku failiga.

transfer_method = piped

Muide, haru "develop" sees see seadistus samuti eksisteerib ja ei ole kuhugi kadunud.

Ära karda noa, vaid karda kahvlit

Veel üks kasulik seadistus on forks. See määrab töötavate protsesside arvu, mis samal ajal ühenduvad hostidega ja täidavad ülesandeid. Python'i kui programmeerimiskeele eripärade tõttu kasutatakse protsesse, mitte thread'e, sest Ansible toetab endiselt Python 2.7 — ei mingit asyncio, ei tasu asünkroonsust proovida! Vaikimisi käivitab Ansible viis töötajat, kuid kui õigesti paluda, siis saab rohkem käivitada:

forks = 20

Aga kohe hoiatuseks, et siin võivad esineda mõned probleemid, mis on seotud haldusmasina olemasoleva mälu mahutavusega. Teisisõnu, forks=100500 seadmine on muidugi võimalik, kuid kes ütles, et see töötab?

Kogume kõik kokku

Lõppkokkuvõttes võivad vajalikud seaded ansible.cfg (ini-formaat) välja näha nii:

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

Ja kui soovid kõike normaalsesse YaML-inventari peita, siis see võib välja näha umbes selline:

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

Kahjuks seadetega «gathering = smart/explicit» ja «forks = 20» nii ei toimi: nende YaML-i ekvivalente ei eksisteeri. Kas määrame need ansible.cfg failis või edastame keskkonnamuutujate ANSIBLE_GATHERING ja ANSIBLE_FORKS kaudu.

Mitogenist
— Aga kus siin on juttu Mitogenist? — võid sa küsida, austatud lugeja. Selles artiklis — mitte kusagil. Kuid kui sa oled tõeliselt valmis lugema selle kood ja aru saama, miks su playbook Mitogeniga ei tööta, samas kui puhas Ansible töötab hästi, või miks sama playbook töötas varem normaalselt, aga pärast uuendamist hakkas imelikult käituma — noh, Mitogen võib olla potentsiaalselt sinu tööriist. Kasuta, uurige, kirjuta artikleid — loen huviga.

Miks ma isiklikult Mitogenit ei kasuta? Sest see töötab ainult siis, kui ülesanded on tõeliselt lihtsad ja kõik on hästi. Kui aga veidi väänata vasakule või paremale — kõik, see on lõpp: vastuseks lendab su suunas hulk segaseid erandeid, ja täiendavaks pildiks jääb puudu vaid fraas «kõigile tänud, kõik on vabaks». Kokkuvõttes, ma ei soovi lihtsalt aega raisata järgmise «maapinna koputamise» põhjuste väljaselgitamiseks.

Mõned neist seadistustest leidsin lugemise käigus allikakoodist connection plugini alt nimega «ssh.py». Jagatavad tulemused loodetavasti innustavad kedagi veelgi vaatama lähtekoodi, seda lugema, kontrollima rakendust, võrreldama dokumentatsiooniga — lõpuks toob see varem või hiljem teie jaoks positiivseid tulemusi. Edu!

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.