🥇Ubrzavamo Ansible

Nije nikakva tajna da Ansible s 'zadanim' postavkama ne radi previše brzo. U ovom članku ću navesti nekoliko razloga za to i ponuditi osnovne postavke koje bi mogle značajno povećati brzinu rada vašeg projekta.

Ovdje raspravljamo o Ansible 2.9.x, koji je instaliran u svježe kreiranom virtualenv-u na vaš način.

Nakon instalacije, uz vaš playbook crean je datoteka 'ansible.cfg' — takva lokacija omogućuje prenošenje tih postavki zajedno s projektom, a one će se učitavati automatski.

Cijevna obrada

Netko je možda čuo da treba koristiti cijevnu obradu, tj. da se moduli ne kopiraju u datotečni sustav ciljnog sustava, već se šalju obavijeni u Base64 zip-archivu direktno na stdin Python interpretatora, ali činjenica ostaje činjenica: ova postavka i dalje ostaje nedovoljno cijenjena. Nažalost, neki od popularnih Linux distribucija ranije su configurirali sudo loše prema zadanim postavkama — tako da je ta naredba zahtijevala prisustvo tty (terminala), zbog čega je Ansible ovu vrlo korisnu postavku ostavio isključenom.

pipelining = True

Prikupiti činjenice

Znate li da Ansible s zadanim postavkama za svaki play pokreće prikupljanje činjenica sa svih hostova koji sudjeluju? Ako niste znali, sada znate. Da se to ne bi događalo, potrebno je uključiti ili eksplicitni način zahtjeva za prikupljanjem činjenica ili pametni način. U njemu će se činjenice prikupljati samo s onih hostova koji se nisu pojavili u prethodnim play-evima.
UPD. Kada kopirate, morat ćete odabrati jednu od ovih postavki.

gathering = smart|explicit

Ponovno korištenje ssh veza

Ako ste ikada pokretali Ansible u načinu prikaza dijagnostičkih informacija (opcija 'v', ponovljena od jednom do devet puta), možda ste primijetili da se ssh veze neprekidno uspostavljaju i prekinu. I ovdje postoje neke finese.

Izbjegavanje ponovnog uspostavljanja ssh veze može se postići na dva nivoa: i u samom ssh klijentu i prilikom prijenosa datoteka na upravljani host s kontrolera.
Za ponovnu uporabu otvorene ssh veze, samo je potrebno poslati potrebne ključeve ssh klijentu. Tada će početi raditi sljedeće: pri prvoj uspostavi ssh veze dodatno će se kreirati takozvani kontrolni socket, a pri sljedećim će provjeriti postoji li taj socket, te ukoliko jest, ponovo iskoristiti postojeću ssh vezu. Kako bi ovo imalo smisla, postavit ćemo vrijeme zadržavanja veze u slučaju neaktvnosti. Više informacija možete pročitati u dokumentaciji za ssh, a u kontekstu Ansibla jednostavno koristimo „prosljeđivanje“ potrebnih opcija ssh klijentu.

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

Za ponovnu uporabu već otvorene ssh veze prilikom prijenosa datoteka na upravljani host, dovoljno je navesti još jednu nepoznatu postavku ssh_transfer_method. Dokumentacija o tome je vrlo oskudna i zbunjujuća, jer ova opcija sasvim dobro funkcionira! Međutim, čitanje izvornog koda omogućuje razumijevanje što će se točno događati: na upravljanom hostu bit će pokrenuta naredba dd, koja izravno radi s potrebnom datotekom.

transfer_method = piped

Usput, u grani „develop“ ova postavka također postoji i nije nestala.

Ne boj se noža, boj se vilice

Još jedna korisna postavka su forks. Ona definira broj radnih procesa koji će se istovremeno povezivati na hostove i izvršavati zadatke. Zbog osobitosti Pythona kao jezika, koriste se procesi, a ne niti, jer Ansible još uvijek podržava Python 2.7 — ovdje nema asyncio, ne radi se ovdje o asinkronim operacijama! Prema zadanim postavkama, Ansible pokreće pet radnika, no ako pravilno zatražite, može pokrenuti i više:

forks = 20

Samo odmah upozoravam da ovdje mogu nastati neki problemi povezani s dostupnom količinom memorije na upravljačkom računalu. Drugim riječima, postaviti forks=100500, naravno, moguće je, ali tko je rekao da će raditi?

Sve zajedno

Na kraju, potrebne postavke za ansible.cfg (ini-format) mogu izgledati ovako:

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

A ako želiš sve to sakriti u normalan YaML inventory zdravog čovjeka, može izgledati otprilike ovako:

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

Nažalost, s postavkama „gathering = smart/explicit“ i „forks = 20“ ovo neće proći: njihovi YaML ekvivalenti ne postoje. Ili ih postavljamo u ansible.cfg, ili ih proslijedimo putem varijabli okruženja ANSIBLE_GATHERING i ANSIBLE_FORKS.

O Mitogenu
— A gdje ovdje piše o Mitogenu? — možeš pitati, cijenjeni čitatelju. U ovom članku — nigdje. No ako si stvarno spreman pročitati njegov kod i razumjeti zašto tvoj playbook ne radi s Mitogenom, a s običnim Ansible-om normalno radi, ili zašto je ovaj isti playbook do sada ispravno radio, a nakon ažuriranja počeo činiti čudno — pa, Mitogen potencijalno može biti tvoj alat. Koristi ga, prouči, piši članke — rado ću ih pročitati.

Zašto ja osobno ne koristim Mitogen? Zato što on radi samo dok su zadaci stvarno jednostavni i sve ide dobro. Međutim, čim se malo odmakneš lijevo ili desno — to je to: u tvoju stranu leti hrpa nejasnih iznimaka, i za završetak slike nedostaje ti samo fraza „svima hvala, svi slobodni“. Uglavnom, jednostavno ne želim trošiti vrijeme na razjašnjavanje uzroka još jednog „podzemnog udarca“.

Neke od ovih postavki otkrivene su tijekom čitanja izvornog koda connection plugina pod govorećim imenom „ssh.py“. Podijeljem rezultate čitanja u nadi da će to inspirirati još nekoga da pogleda u izvorne kodove, pročita ih, provjeri implementaciju, usporedi s dokumentacijom — jer sve to prije ili kasnije donosi pozitivne rezultate. Sretno!

Samo registrirani korisnici mogu sudjelovati u anketi. Prijavite se, molimo.