🥇Kiirendame Ansible

Ei ole kellelegi saladus, et Ansible vaikeseadetega ei pruugi oma tööd liiga kiiresti teha. Artiklis toon välja mõned põhjused ja pakun kasulikke minimaalsete seadistuste soovitusi, mis võivad teie projekti töö kiirusest oluliselt parandada.

Arutame siin ja edaspidi Ansible 2.9.x versiooni, mis on installitud teie lemmikmeetodil värskes virtualenv's.

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

Pipeline'ide kasutamine

Kellelegi pole saladus, et pipeliningut, st mitte moodulite kopeerimist sihtsüsteemi failisüsteemi, vaid Base64 zip-arhiiviga edastamist otse Python'i tõlgendaja stdin'i kaudu, on juba kuulatud, kuid fakt jääb faktiks: see seadistus on endiselt alahinnatud. Kahjuks seadistas üks populaarne Linuxi distributsioon sudo vaikimisi mitte kõige paremini — nõudes, et see käsu täitmiseks peaks olema tty (terminaal), mistõttu jäeti Ansible see väga kasulik seadistus vaikimisi välja.

pipelining = True

Faktide kogumine

Kas teadsite, et Ansible'i vaike seadistustega käivitab iga plaan faktide kogumise kõikidest osalevatest hostidest? Üldiselt, kui te ei teadnud, siis nüüd teate. Et seda ei toimuks, peate kas lubama faktide kogumise selgesõnalise päringu režiimi (explicit) või nutika režiimi. Viimases kogutakse faktid ainult nendelt hostidelt, mis pole eelnevalt plaanides ilmunud.
UPD. Kopeerimisel peate valima nende seadete hulgast ühe.

gathering = smart|explicit

ssh-ühenduste taaskasutamine

Kui olete kunagi käinud Ansible'i režiimis, kus kuvatakse silumisinfo (valik «v», korduv alates ühest kuni üheksani), siis olete ilmselt märganud, et ssh-ühendused pidevalt luuakse ja katkestatakse. Noh, siin on samuti paar nüanssi.

SSH-ühenduse uuesti loomise etappi saab vältida kahel tasemel: nii ssh-klientis kui ka failide edastamisel haldatavale hostile haldussüsteemist.
Avatud ssh-ühenduse taaskasutamiseks piisab lihtsalt vajalike ssh-võtmete edastamisest ssh-klientile. Siis hakkab ta tegema järgmist: ssh-ühenduse esmakordsel seadistamisel loob ta nn control socket'i ja järjestikuste ühenduste puhul kontrollib olemasolu ning õnnestumise korral kasutab ta olemasolevat ssh-ühendust. Et kõigel sel oleks mõte, seadistame sidumise ajaloo salvestamise, kui see ei ole aktiivne. Rohkem informatsiooni leiate ssh dokumentatsioonist, ja Ansible kontekstis kasutame lihtsalt soovitud ssh-valikute "edastust".

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

Juba avatud ssh-ühenduse taaskasutamiseks failide edastamisel hallatavale hostile piisab, kui määrata veel üks teadmata seade ssh_tranfer_method. Dokumentatsioon selle kohta on äärmiselt napakas ja eksitav, kuna see võimalus on täiesti toimiv! Küll aga aitab lugemine lähtekood mõista, mis täpselt toimuma hakkab: hallataval hostil käivitatakse dd käsk, mis töötab otseselt vajaliku failiga.

transfer_method = piped

Muide, "develop" harus see seade samuti eksisteerib ja ei ole kuhugi kadunud.

Ära karda nuga, vaid karda kahvlit

Veel üks kasulik seadistus on forks. See määrab, kui palju tööprotsesse ühendatakse hostidega ja täidavad ülesandeid erinevalt. Python'i keelena kasutatakse siin protsesse, mitte thread'e, kuna Ansible toetab endiselt Python 2.7 — ei mingit asyncio't, siin pole asünkroonsust vaja! Vaikimisi alustab Ansible viit töötajat, kuid kui õigesti paluda, saab rohkem käima panna:

forks = 20

Aga kohe hoiataks, et siinkohal võivad tekkida mõned raskused, mis on seotud hallatava masina mälumahuga. Teisisõnu, forks=100500 seadmine on muidugi võimalik, kuid kes ütles, et see töötab?

Kokkuvõtteks

Lõpuks võivad ansible.cfg (ini-formaat) vajalikud seaded välja näha järgmiselt:

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

Ja kui soovid kogu selle normaalse YaML-inventarisse peita, siis võib see 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 ei sobi „gathering = smart/explicit“ ja „forks = 20“ seaded: nende YaML-i ekvivalente ei eksisteeri. Kas seame need ansible.cfg-failis või edastame keskkonnamuutujate ANSIBLE_GATHERING ja ANSIBLE_FORKS kaudu.

Küsimus Mitogeni kohta
— Kus siin on juttu Mitogenist? — võid küsida, kallis lugeja. Selles artiklis ei ole seda kuskil. Kuid kui sa tõesti oled valmis lugema selle koodi ja aru saama, miks su playbook Mitogeni puhul kukub, samas kui puhta Ansible'i puhul töötab, või miks sama playbook varem hästi töötas, aga pärast värskendust hakkas imelikult käituma — noh, Mitogen võib potentsiaalselt olla sinu tööriist. Kasuta, uuri, kirjuta artikleid — loen huvi pärast.

Miks ma isiklikult Mitogeni ei kasuta? Sest see töötab ainult seni, kuni ülesanded on tõeliselt lihtsad ja kõik on hästi. Kuid kui astuda veidi vasakule või paremale — on kõik, asi läbi: vastuseks lendab su poole hulk ebaselgeid erandeid ning pildi täiendamiseks vajatakse ainult ühte fraasi „kõigile aitäh, kõik on vabastatud”. Ühesõnaga, ma ei soovi lihtsalt aega kulutada järgmise „maa-aluse klõpsu” põhjuste väljaselgitamisele.

Mõned neist seadistustest avastati lugemise käigus lähtekood Ühenduse plugin nimega «ssh.py». Jagades selle lugemise tulemusi, loodan, et see inspireerib kedagi veel allikaid vaatama, neid lugema, rakendust kontrollima, dokumentatsiooniga võrdlema — lõpuks toob see kindlasti positiivseid tulemusi. Edu!

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