Accelerarea lui Ansible

Nu este un secret pentru nimeni că, cu setările implicite, Ansible nu își poate face treaba foarte repede. În articol voi indica mai multe motive pentru aceasta și voi oferi un minim util de setări care, foarte posibil, vor crește efectiv viteza proiectului dumneavoastră.

Aici și mai jos discutăm despre Ansible 2.9.x, care a fost instalat într-un virtualenv proaspăt creat în modul tău preferat.

După instalare, creați un fișier „ansible.cfg” lângă registrul de joc - această locație vă va permite să transferați aceste setări împreună cu proiectul, plus acestea se vor încărca destul de automat.

Conducte

Unii poate că au auzit deja despre necesitatea utilizării pipelining-ului, adică nu copierea modulelor în sistemul de fișiere al sistemului țintă, ci transferul unei arhive zip împachetate în Base64 direct în stdin-ul interpretorului Python, dar alții nu, dar faptul că ramane un fapt: această setare rămâne încă subestimat. Din păcate, unele dintre distribuțiile Linux populare folosite pentru a configura sudo nu prea bine în mod implicit - astfel încât această comandă necesita un tty (terminal), așa că Ansible a lăsat această setare foarte utilă dezactivată în mod implicit.

pipelining = True

Adunarea faptelor

Știați că, cu setările implicite, Ansible pentru fiecare joc inițiază colectarea de fapte pentru toate gazdele care participă la ea? În general, dacă nu știai, acum știi. Pentru a preveni acest lucru, trebuie să activați fie modul de solicitare explicită pentru colectarea faptelor (explicit), fie modul inteligent. În ea, vor fi culese date doar de la acele gazde care nu au fost întâlnite în piesele anterioare.
UPD. Când copiați, va trebui să selectați una dintre aceste setări.

gathering = smart|explicit

Reutilizarea conexiunilor ssh

Dacă ați rulat vreodată Ansible în modul de depanare (opțiunea „v”, repetată de una până la nouă ori), este posibil să fi observat că conexiunile ssh sunt în mod constant realizate și întrerupte. Deci, există și aici câteva subtilități.

Puteți evita pasul restabilirii unei conexiuni ssh la două niveluri simultan: atât direct în clientul ssh, cât și la transferul fișierelor către gazda gestionată de la manager.
Pentru a reutiliza o conexiune ssh deschisă, pur și simplu transmiteți cheile necesare clientului ssh. Apoi va începe să facă următoarele: la stabilirea unei conexiuni ssh pentru prima dată, va crea în plus o așa-numită priză de control, la instalările ulterioare, va verifica chiar existența acestei prize și, dacă are succes, va reutiliza conexiune ssh existentă. Și pentru ca toate acestea să aibă sens, să setăm timpul pentru menținerea conexiunii atunci când este inactiv. Puteți citi mai multe în documentație ssh, iar în contextul Ansible pur și simplu folosim „redirecționarea” opțiunilor necesare către clientul ssh.

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

Pentru a reutiliza o conexiune ssh deja deschisă atunci când transferați fișiere către o gazdă gestionată, trebuie doar să specificați o altă setare necunoscută ssh_transfer_method. Documentația pe acest subiect este extrem de scump și induce în eroare, pentru că această opțiune funcționează destul de bine! Dar citind cod sursa vă permite să înțelegeți ce se va întâmpla exact: comanda dd va fi lansată pe gazda gestionată, lucrând direct cu fișierul dorit.

transfer_method = piped

Apropo, în ramura „dezvoltare” există și această setare nu merg nicăieri.

Nu-ți fie frică de cuțit, fie de furculiță

O altă setare utilă este furcile. Acesta determină numărul de procese de lucru care se vor conecta simultan la gazde și vor îndeplini sarcini. Datorită particularităților Python ca limbaj, sunt folosite procese, nu fire de execuție, deoarece Ansible încă acceptă Python 2.7 - nu există asincronizare pentru tine, nu are rost să introduci un comportament asincron aici! În mod implicit, Ansible rulează cinci lucrătorilor, dar dacă este întrebat corect, va lansa mai multe:

forks = 20

Vă avertizez imediat că aici pot apărea unele dificultăți legate de cantitatea de memorie disponibilă pe mașina de control. Cu alte cuvinte, puteți, desigur, să setați forks=100500, dar cine a spus că va funcționa?

Punând totul împreună

Ca rezultat, pentru ansible.cfg (format ini), setările 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

Și dacă doriți să ascundeți totul într-un inventar YaML normal al unei persoane sănătoase, atunci 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, acest lucru nu va funcționa cu setările „gathering = smart/explicit” și „forks = 20”: echivalentele lor YaML nu există. Fie le setăm în ansible.cfg, fie le trecem prin variabilele de mediu ANSIBLE_GATHERING și ANSIBLE_FORKS.

Despre Mitogen
- Unde este asta despre Mitogen? - ai dreptul să întrebi, dragă cititor. Nicăieri în acest articol. Dar dacă sunteți cu adevărat gata să citiți codul său și să vă dați seama de ce playbook-ul dvs. se blochează cu Mitogen, dar funcționează bine cu vanilla Ansible, sau de ce același playbook funcționa bine înainte, dar după o actualizare a început să facă lucruri ciudate - ei bine, Mitogen ar putea fi instrumentul tău. Aplicați-l, înțelegeți-l, scrieți articole - îl voi citi cu interes.

De ce nu folosesc personal Mitogen? Pentru că gladiole funcționează doar atâta timp cât sarcinile sunt cu adevărat simple și totul este în regulă. Cu toate acestea, dacă vă întoarceți puțin la stânga sau la dreapta - asta este, am ajuns: ca răspuns, o mână de excepții indistincte zboară spre tine și, pentru a completa imaginea, tot ceea ce lipsește este expresia comună „mulțumesc tuturor , toată lumea este liberă.” În general, nu vreau să pierd timpul să aflu motivele următoarei „ciocăniri subterane”.

Unele dintre aceste setări au fost descoperite în timpul procesului de citire cod sursa plugin de conexiune sub numele auto-explicativ „ssh.py”. Împărtășesc rezultatele lecturii în speranța că va inspira pe altcineva să se uite la surse, să le citească, să verifice implementarea, să compare cu documentația - la urma urmei, mai devreme sau mai târziu toate acestea vă vor aduce rezultate pozitive. Noroc!

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Pe care dintre următoarele setări Ansible le folosiți pentru a vă accelera proiectele?

• 69,6%pipelining=true32

• 34,8%adunare = inteligent/explicit16

• 52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24

• 17,4%transfer_method = piped8

• 63,0%furci = XXX29

• 6,5%Nimic din toate acestea, doar Mitogen3

• 8,7%Mitogen + voi nota care dintre aceste setări4

Au votat 46 utilizatori. 21 utilizator s-a abținut.

Vrei mai multe lucruri despre Ansible?

• 78,3%da, desigur54

• 21,7%da, vreau doar mai multe chestii hardcore!15

• 0,0%nu și nu este necesar degeaba0

• 0,0%nu, e complicat!!!0

Au votat 69 utilizatori. 7 utilizatori s-au abținut.

Sursa: www.habr.com