🥇Accelerăm Ansible

Nu este un secret pentru nimeni că, cu setările „default”, Ansible poate să nu își facă treaba foarte rapid. În acest articol, voi evidenția câteva motive pentru aceasta și voi propune un minim util de setări care, cu siguranță, pot crește viteza de lucru a proiectului dumneavoastră.

Discutăm aici și mai departe despre Ansible 2.9.x, care a fost instalat într-un virtualenv proaspăt creat, folosind metoda preferată de dumneavoastră.

După instalare, creați un fișier „ansible.cfg” lângă playbook-ul dumneavoastră — această plasare va permite transferarea acestor setări împreună cu proiectul, iar încărcarea lor se va face simplu și automat.

Pipelining

Despre utilizarea pipelining-ului, adică evitarea copieri modulelor în sistemul de fișiere al sistemului țintă și transmiterea unui arhivă zip comprimată în Base64 direct pe stdin interpretului Python, unii ar fi putut auzi, iar alții nu, dar faptul rămâne: această setare rămâne în continuare subevaluată. Din păcate, unele dintre distribuțiile populare Linux configurau sudo nu foarte bine „per default” — astfel, comanda aceasta necesita un tty (terminal), iar, în cazul Ansible, această setare foarte utilă a rămas dezactivată implicit.

pipelining = True

Colectarea de fapte

Știați că, cu setările „default”, Ansible inițiază colectarea de fapte pentru fiecare play de pe toate gazdele implicate? Ei bine, dacă nu știați, acum știți. Pentru a evita acest lucru, trebuie să activați fie modul de solicitare explicită pentru colectarea de fapte, fie modul smart. În acesta, faptele vor fi colectate doar de la gazdele care nu au fost întâlnite în play-urile anterioare.
UPD. Când copiați, va trebui să alegeți una dintre aceste setări.

gathering = smart|explicit

Reutilizarea conexiunilor ssh

Dacă ați rulat vreodată Ansible în modul de ieșire a informațiilor de depanare (opțiunea „v”, repetată de la una la nouă ori), atunci probabil ați observat că conexiunile ssh sunt constant instalate și întrerupte. Ei bine, aici există și câteva subtilități.

Evitarea fazei de reinstalare a conexiunii ssh se poate face pe două niveluri simultan: atât direct în clientul ssh, cât și la transferul fișierelor pe gazda gestionată din partea de management.
Pentru a reutiliza o conexiune SSH deschisă, este suficient să transmiți cheile necesare clientului SSH. Apoi, acesta va începe să facă următoarele: la prima stabilire a conexiunii SSH, va crea un așa-numit control socket, iar la stabilirile ulterioare va verifica existența acestui socket și, în caz de succes, va reutiliza conexiunea SSH existentă. Iar pentru ca toate acestea să aibă sens, să stabilim un timp de păstrare a conexiunii în absența activității. Poți citi mai multe în documentația SSH, iar în contextul Ansible utilizăm pur și simplu „transmiterea” opțiunilor necesare către clientul SSH.

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

Pentru a reutiliza o conexiune SSH deja deschisă la transferul fișierelor către gazda gestionată, este suficient să specifici o altă configurație necunoscută ssh_transfer_method. Documentația pe această temă este extrem de sărăcăcioasă și induce în eroare, deoarece această opțiune funcționează foarte bine! În schimb, lectura codului sursă permite înțelegerea a ceea ce se va întâmpla: pe gazda gestionată va fi executată comanda dd, care interacționează direct cu fișierul dorit.

transfer_method = piped

Apropo, în ramura „develop” această configurație există de asemenea și nu a dispărut.

Nu te teme de cuțit, teme-te de furcă

O altă configurare utilă este forks. Aceasta definește numărul de procese de lucru care se vor conecta simultan la gazde și vor executa sarcini. Din cauza specificităților Python ca limbaj de programare, se folosesc procese, nu fire, deoarece Ansible încă suportă Python 2.7 — nu avem asyncio, nu e cazul să introducem asincronismul aici! În mod implicit, Ansible lansează cinci lucrători, dar dacă soliciți corect, va lansa mai mulți:

forks = 20

Doar te avertizez din timp că pot apărea unele dificultăți legate de volumul de memorie disponibil pe mașina de control. Cu alte cuvinte, poți seta forks=100500, desigur, dar cine a spus că va funcționa?

Să adunăm totul împreună

În concluzie, pentru ansible.cfg (format ini), configurațiile necesare pot arăta astfel:

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

Dacă dorești să ascunzi totul într-un inventar YaML normal pentru un om sănătos, acesta poate arăta cam așa:

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

Din păcate, cu setările „gathering = smart/explicit” și „forks = 20” acest lucru nu va funcționa: echivalentele lor YaML nu există. Fie le definim în ansible.cfg, fie le transmitem prin variabilele de mediu ANSIBLE_GATHERING și ANSIBLE_FORKS.

Despre Mitogen
— Și unde este vorba despre Mitogen? — ai dreptul să întrebi, cititor respectat. În acest articol — nicăieri. Dar dacă ești cu adevărat pregătit să citești codul său și să înțelegi de ce playbook-ul tău eșuează cu Mitogen, dar funcționează bine cu Ansible vanilla, sau de ce același playbook a funcționat până acum, dar după actualizare începe să se comporte ciudat — ei bine, Mitogen ar putea fi instrumentul tău. Folosește-l, analizează-l, scrie articole — le voi citi cu interes.

De ce personal nu folosesc Mitogen? Pentru că funcționează doar cât timp sarcinile sunt realmente simple și totul este în regulă. Totuși, dacă te abați puțin la stânga sau la dreapta — gata: în răspuns, te bombardează cu o grămadă de excepții neclare, iar pentru a completa tabloul, lipsește doar expresia comună „mulțumesc tuturor, sunteți liberi”. În general, nu vreau să-mi pierd timpul cu descoperirea cauzelor unor „sune subterane” din nou.

O parte din aceste setări au fost descoperite în timpul lecturii codului sursă plugin-ului de conexiune numit „ssh.py”. Împărtășesc rezultatele lecturii în speranța că acesta va inspira și pe alții să privească sursele, să le citească, să verifice implementarea, să compare cu documentația — pentru că, totul acesta, mai devreme sau mai târziu, îți va aduce rezultate pozitive. Multă baftă!

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.