🥇Az Ansible felgyorsítása

Nem titok, hogy az alapértelmezett beállításokkal az Ansible nem tudja túl gyorsan elvégezni a feladatát. A cikkben rámutatok ennek több okára, és felajánlok egy hasznos minimális beállítást, amelyek valószínűleg valóban növelik a projekt sebességét.

Itt és az alábbiakban az Ansible 2.9.x-et tárgyaljuk, amelyet egy frissen létrehozott virtualenv-be telepítettek kedvenc módon.

A telepítés után hozzon létre egy „ansible.cfg” fájlt a forgatókönyve mellett – ezen a helyen átviheti ezeket a beállításokat a projekttel együtt, és ezek teljesen automatikusan betöltődnek.

Csővezetékezés

Lehet, hogy néhányan már hallottak arról, hogy pipeline-t kell használni, vagyis nem a modulokat kell másolni a célrendszer fájlrendszerébe, hanem a Base64-be csomagolt zip-archívumot közvetlenül a Python interpreter stdin-jébe kell átvinni, de mások nem, de az tény. tény marad: ezt a beállítást továbbra is alábecsült marad. Sajnos néhány népszerű Linux-disztribúció alapértelmezés szerint nem túl jól konfigurálta a sudo-t – ezért ehhez a parancshoz tty (terminál) kellett, ezért az Ansible ezt a nagyon hasznos beállítást alapértelmezés szerint letiltotta.

pipelining = True

Tények összegyűjtése

Tudtad, hogy az alapértelmezett beállításokkal az Ansible for every play kezdeményezi a tények gyűjtését az abban részt vevő összes házigazda számára? Általában, ha nem tudtad, most már tudod. Ennek elkerülése érdekében engedélyeznie kell az explicit kérési módot a tények gyűjtéséhez (explicit), vagy az intelligens módot. Ebben a tényeket csak azoktól a műsorvezetőktől gyűjtik össze, amelyekkel a korábbi darabokban nem találkoztak.
UPD. Másoláskor ki kell választania az egyik beállítást.

gathering = smart|explicit

Ssh kapcsolatok újrafelhasználása

Ha valaha is futtatta az Ansible-t hibakeresési módban (a „v” opció, XNUMX-XNUMX alkalommal megismételve), akkor észrevehette, hogy az ssh-kapcsolatok folyamatosan jönnek létre és megszakadnak. Tehát itt is van néhány finomság.

Elkerülheti az ssh-kapcsolat újbóli létrehozását egyszerre két szinten: mind közvetlenül az ssh-kliensben, mind pedig akkor, amikor fájlokat visz át a felügyelt gazdagépre a kezelőtől.
Egy nyitott ssh-kapcsolat újrafelhasználásához egyszerűen adja át a szükséges kulcsokat az ssh-kliensnek. Ezután a következőt kezdi el: az ssh kapcsolat első létesítésekor létrehoz egy úgynevezett vezérlőaljzatot, a későbbi telepítéseknél ellenőrzi ennek a socketnek a meglétét, és ha sikeres, újra felhasználja a meglévő ssh kapcsolat. És hogy mindez értelmes legyen, állítsuk be az inaktív kapcsolat fenntartásának idejét. Bővebben olvashatsz benne ssh dokumentáció, és az Ansible kontextusában egyszerűen a szükséges opciók ssh kliensnek való „továbbítását” használjuk.

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

Ha egy már nyitott ssh-kapcsolatot szeretne újra felhasználni, amikor fájlokat visz át egy felügyelt gazdagépre, adjon meg egy másik ismeretlen beállítást: ssh_tranfer_method. A dokumentáció ebben a témában rendkívüli fukar és félrevezető, mert ez a lehetőség elég jól működik! De olvasni forráskód lehetővé teszi, hogy megértse, mi fog pontosan történni: a dd parancs elindul a felügyelt gazdagépen, közvetlenül a kívánt fájllal együttműködve.

transfer_method = piped

Egyébként a „develop” ágban is létezik ez a beállítás nem megy sehova.

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

Egy másik hasznos beállítás a villák. Meghatározza azon dolgozói folyamatok számát, amelyek egyidejűleg csatlakoznak a gazdagépekhez és hajtanak végre feladatokat. A Python mint nyelv sajátosságai miatt folyamatokat használnak, nem szálakat, mert az Ansible továbbra is támogatja a Python 2.7-et – nincs asyncio az Ön számára, nincs értelme az aszinkron viselkedést bevezetni! Alapértelmezés szerint az Ansible fut öt dolgozók, de ha helyesen kérdezik, többet indít:

forks = 20

Azonnal figyelmeztetem, hogy itt nehézségek adódhatnak a vezérlőgépen rendelkezésre álló memória mennyiségével kapcsolatban. Más szóval, természetesen beállíthatja a forks=100500-at, de ki mondta, hogy ez működni fog?

Az egészet összerakva

Ennek eredményeként az ansible.cfg (ini formátum) esetén a szükséges beállítások í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

És ha mindent el akar rejteni egy egészséges ember normál YaML-leltárában, akkor ez valahogy í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 ez nem működik a „Gathering = smart/explicit” és a „forks = 20” beállításokkal: ezek YaML megfelelői nem léteznek. Vagy beállítjuk őket az ansible.cfg fájlban, vagy átadjuk őket az ANSIBLE_GATHERING és ANSIBLE_FORKS környezeti változókon.

Mitogénről
- Hol van ez a Mitogenről? - joga van kérdezni, kedves olvasó. Ebben a cikkben sehol. De ha valóban készen áll arra, hogy elolvassa a kódját, és rájöjjön, miért ütközik össze a játékkönyve a Mitogennel, de működik jól a vanilla Ansible-vel, vagy miért működött jól ugyanaz a játékkönyv korábban, de egy frissítés után furcsa dolgokat kezdett csinálni - hát a Mitogen esetleg az Ön eszköze lehet. Alkalmazza, értse meg, írjon cikkeket - érdeklődéssel olvasom.

Miért nem használok személy szerint a Mitogent? Mert a kardvirág csak addig működik, amíg a feladatok nagyon egyszerűek és minden rendben van. Viszont ha kicsit balra vagy jobbra fordulsz - ez az, megérkeztünk: válaszul egy maroknyi homályos kivétel repül rád, és hogy teljes legyen a kép, már csak a közönséges „köszönöm mindenkinek” mondat hiányzik. , mindenki szabad." Általában nem akarok időt vesztegetni a következő „földalatti kopogtatás” okainak kiderítésére.

Ezen beállítások egy részét az olvasási folyamat során fedezték fel forráskód csatlakozási bővítmény „ssh.py” néven. Megosztom az olvasás eredményeit abban a reményben, hogy másokat is inspirál a források áttekintésére, elolvasására, a megvalósítás ellenőrzésére, a dokumentációval való összehasonlításra - elvégre előbb-utóbb mindez pozitív eredményeket hoz. Sok szerencsét!

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Az alábbi Ansible beállítások közül melyiket használja projektjei felgyorsításához?

69,6%pipelineing=true32
34,8%gyűjtés = okos/explicit16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%átviteli_módszer = vezetékes8
63,0%villa = XXX29
6,5%Ebből semmi, csak a Mitogen3
8,7%Mitogen + Megjegyzem, melyik beállítás4

46 felhasználó szavazott. 21 felhasználó tartózkodott.

Többet szeretne az Ansible-ről?

78,3%igen, természetesen 54
21,7%igen, csak több kemény cuccot szeretnék!15
0,0%nem, és semmire sem szükséges0
0,0%nem, ez bonyolult!!!0

69 felhasználó szavazott. 7 felhasználó tartózkodott.

Forrás: will.com

Az Ansible felgyorsítása