🥇Ansible felgyorsítása

Nem titok, hogy az alapértelmezett beállításokkal az Ansible nem mindig végzi a dolgát túl gyorsan. A cikkemben néhány okot fel fogok sorolni, és javaslok egy hasznos minimum beállítást, amelyek valószínűleg növelni fogják a projekted sebességét.

Itt és a továbbiakban az Ansible 2.9.x-ről beszélünk, amelyet a kedvenc módszereddel telepítettél egy frissen létrehozott virtualenv-be.

A telepítés után létrehozunk egy "ansible.cfg" fájlt a playbook-od mellett – ez a helyzet lehetővé teszi, hogy az adatokkal együtt mozgasd a beállításokat a projekttel, ráadásul automatikusan be fogják őket tölteni.

Csövesítés

Valaki már hallhatott róla, hogy pipelining-et kell használni, vagyis nem a modulok másolása a célrendszer fájlrendszerébe, hanem egy Base64-be csomagolt zip-archívum átvitele közvetlenül a Python interpreter stdin-jére, mások talán nem, de a tény az tény marad: ez a beállítás még mindig alulértékelt. Sajnos, egyes népszerű Linux-disztribúciók alapértelmezés szerint nem konfigurálták jól a sudot — így ez a parancs tty (terminál) meglétét követelte meg, ezért az Ansible ezt a nagyon hasznos beállítást alapértelmezés szerint ki is hagyta.

pipelining = True

Faktumok gyűjtése

Tudtad-e, hogy az Ansible alapértelmezett beállításai szerint a play minden egyes ütemezésénél faktumokat gyűjt minden résztvevő hoszton? Ha eddig nem tudtad, most már tudod. Annak érdekében, hogy ez ne történjen meg, vagy a faktumgyűjtés explicit kérésének módját, vagy a smart módot kell bekapcsolni. Ebben a módban a faktumok csak azokból a hosztokból fognak összegyűlni, amelyek korábban még nem voltak találkoztak.
UPD. A másolás során ki kell választanod ezekből a beállításokból egyet.

gathering = smart|explicit

ssh-kapcsolatok újrahasználata

Ha valaha Ansible-t futtattál a hibakeresési mód melletti kimenettel (a "v" opciót egy-től kilencszer ismételve), akkor valószínűleg észrevetted, hogy az ssh-kapcsolatok folyamatosan létrejönnek és megszakadnak. Nos, itt is létezik néhány apróság.

Az ssh-kapcsolat újbóli létrehozásának lépését két szinten is elkerülheted: és közvetlenül az ssh kliensben, és a fájlok átvitele során az irányítószámhoz.
A nyitott SSH kapcsolat újrahasználatához elegendő, ha a szükséges SSH kulcsokat átadjuk az SSH kliensnek. Így a következő történik: az SSH kapcsolat első létesítésekor létrejön egy úgynevezett vezérlő socket, a későbbi kapcsolatfelvételeknél pedig ellenőrzi ennek a socketnek a meglétét, és ha sikeres, újrahasználja a meglévő SSH kapcsolatot. Ahhoz, hogy mindez értelmet nyerjen, állítsuk be az inaktivitás miatti kapcsolattartási időt. Bővebben erről olvashatunk a SSH dokumentációban, az Ansible kontextusában pedig egyszerűen használjuk a szükséges SSH opciók átadását a kliensnek.

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

A már megnyitott SSH kapcsolat újrahasználatához a fájlok átvitele során a kezelt hoszton elegendő megadni egy további ismeretlen beállítást, az ssh_transfer_method-ot. Erről a dokumentáció rendkívül szűkszavú és félrevezető, hiszen ez az opció teljesen működőképes! De az olvasás forráskódból segít megérteni, hogy pontosan mi fog történni: a kezelt hoszton egy dd parancs fog futni, amely közvetlen kapcsolatban áll a szükséges fájllal.

transfer_method = piped

Egyébként a "develop" ágon ez a beállítás szintén létezik és nem tűnt el.

Ne félj a késtől, félj a villától

Egy másik hasznos beállítás a forks. Ez meghatározza azt a munkafolyamatok számát, amelyek egyszerre csatlakoznak a hosztokhoz és végrehajtják a feladatokat. A Python nyelv sajátosságai miatt pontosan folyamatok, nem szálak kerülnek felhasználásra, mivel az Ansible még mindig támogatja a Python 2.7-et — itt semmiféle asyncio nem jöhet szóba, felesleges az aszinkronizálás! Alapértelmezés szerint az Ansible öt munkást indít el, de ha helyesen kérjük, akkor többet is indít:

forks = 20

Csak előre figyelmeztetlek, hogy itt lehetségesek bizonyos nehézségek a vezérlő gépen rendelkezésre álló memória mennyisége miatt. Más szóval, a forks=100500 természetesen beállítható, de ki mondta, hogy működni fog?

Összefoglalva

Végül az ansible.cfg (ini formátum) szükséges beállításai így nézhetnek ki:

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

Ha szeretnéd mindezt egy normális YaML-inventory-ba rejteni egy normális ember számára, akkor ez körülbelül így nézhet ki:

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

Sajnos a „gathering = smart/explicit” és a „forks = 20” beállításokkal ez nem fog működni: ezeknek nincs YaML megfelelője. Vagy meg kell adni őket az ansible.cfg fájlban, vagy át kell adni környezeti változókként az ANSIBLE_GATHERING és ANSIBLE_FORKS értékeket.

A Mitogenről
— De hol van itt a Mitogen? — kérdezheted, kedves olvasó. Ebben a cikkben — sehol. De ha tényleg készen állsz, hogy olvasd a kódját és felfedezd, miért omlik össze a playbookod a Mitogen-nel, míg a sima Ansible-lel rendben működik, vagy miért működött eddig jól ez a playbook, de frissítés után furcsán viselkedik — hát, a Mitogen potenciálisan a te eszközöd lehet. Használj, elemezz, írj cikkeket — érdeklődéssel fogom olvasni.

Miért nem használom a Mitogen-t? Mert működik, amíg a feladatok valóban egyszerűek, és minden rendben van. De ha kicsit balra vagy jobbra fordulsz — akkor vége: egy rakás zavaros kivétel zúdul rád, és a kép végső simításához csak annyira van szükség, hogy elhangozzon a „köszönöm mindenkinek, mindenki szabad” frázis. Összességében nem akarom az időmet az újabb „földalatti zörej” okainak a tisztázásával tölteni.

Ezek közül néhány beállítást az olvasás során fedeztem fel forráskódból a "ssh.py" nevű kapcsolat pluginban. Az olvasás eredményeit megosztom azzal a reménnyel, hogy ez inspirálni fog másokat is, hogy nézzenek a forráskódba, olvassák el azt, ellenőrizzék a megvalósítást, hasonlítsák össze a dokumentációval — hiszen mindez előbb vagy utóbb pozitív eredményeket hoz számotokra. Sok sikert!

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.