🥇Accelerare Ansible

Non è un segreto che con le impostazioni "predefinite" Ansible possa non essere molto veloce. In questo articolo evidenzierò alcune ragioni e offrirò un insieme utile di impostazioni che potrebbero realmente aumentare la velocità del vostro progetto.

Discutiamo qui e oltre di Ansible 2.9.x, che è stato installato in un nuovo virtualenv nel modo che preferite.

Dopo l'installazione, creiamo un file "ansible.cfg" accanto al vostro playbook: questa posizione consentirà di trasferire queste impostazioni insieme al progetto, e verranno caricate automaticamente.

Pipelining

Chiunque potrebbe aver già sentito parlare dell'importanza del pipelining, cioè non copiare i moduli nel filesystem del sistema target, ma trasferire un archivio zip incapsulato in Base64 direttamente su stdin dell'interprete Python; alcuni potrebbero non saperne nulla, ma il fatto rimane: questa impostazione rimane ancora sottovalutata. Purtroppo, alcune delle distribuzioni Linux più popolari configuravano in precedenza sudo in modo non molto efficace, richiedendo un tty (terminal) per questa comando; per questo motivo, Ansible ha mantenuto questa impostazione molto utile disattivata di default.

pipelining = True

Raccolta dei fatti

Sapevate che con le impostazioni predefinite Ansible avvia la raccolta dei fatti su tutti gli host coinvolti in ogni play? In generale, se non lo sapevate, ora lo sapete. Per evitare che ciò accada, è necessario attivare o la modalità di richiesta esplicita per la raccolta dei fatti (explicit) o la modalità smart. In questa modalità, i fatti verranno raccolti solo da quegli host che non sono stati incontrati nei play precedenti.
UPD. Durante la copia dovrete scegliere una di queste impostazioni.

gathering = smart|explicit

Riutilizzo delle connessioni ssh

Se mai avete eseguito Ansible in modalità di output di debug (opzione «v», ripetuta da una a nove volte), allora potreste aver notato che le connessioni ssh vengono continuamente stabilite e interrotte. Ebbene, anche in questo caso ci sono un paio di sottigliezze.

Evitare la fase di reinstallazione della connessione ssh è possibile su due livelli contemporaneamente: sia nel client ssh sia durante il trasferimento di file all'host gestito dal gestore.
Per riutilizzare una connessione ssh aperta, è sufficiente trasmettere le chiavi necessarie al client ssh. Da quel momento, il client inizierà a fare quanto segue: alla prima connessione ssh, creerà un cosiddetto control socket, e nelle connessioni successive verificherà l'esistenza di questo socket e, in caso di successo, riutilizzerà la connessione ssh esistente. Affinché questo abbia senso, dobbiamo impostare il tempo di mantenimento della connessione in caso di inattività. Ulteriori dettagli possono essere letti nella documentazione ssh, mentre nel contesto di Ansible utilizziamo semplicemente il 'passaggio' delle opzioni desiderate al client ssh.

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

Per riutilizzare una connessione ssh già aperta durante il trasferimento di file su un host gestito, è sufficiente specificare un'altra impostazione sconosciuta, ssh_tranfer_method. La documentazione al riguardo è estremamente scarna e fuorviante, poiché questa opzione è perfettamente funzionante! Tuttavia, leggere del codice sorgente permette di capire esattamente cosa accadrà: sul host gestito verrà eseguito un comando dd, che opererà direttamente con il file desiderato.

transfer_method = piped

Tra l'altro, nel ramo 'develop' questa impostazione esiste ancora e non è sparita.

Non temere il coltello, teme la forchetta

Un'altra configurazione utile è rappresentata dai forks. Questa definisce il numero di processi che si connetteranno simultaneamente agli host ed eseguiranno i compiti. A causa delle peculiarità di Python come linguaggio di programmazione, vengono utilizzati processi anziché thread, poiché Ansible supporta ancora Python 2.7 — niente asyncio, non c'è niente da fare qui con l'assincronia! Per impostazione predefinita, Ansible avvia cinque lavoratori, ma se lo si richiede correttamente, può avviarne di più:

forks = 20

Solo ti avverto subito che ci possono essere alcune difficoltà legate alla memoria disponibile sulla macchina di gestione. In altre parole, impostare forks=100500 è possibile, ma chi ha detto che funzionerà?

Riepiloghiamo tutto

Di conseguenza, per il file ansible.cfg (formato ini), le impostazioni necessarie possono apparire così:

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

E se desideri nascondere tutto in un normale inventario YaML di una persona sana, potrebbe apparire più o meno così:

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

Sfortunatamente, con le impostazioni "gathering = smart/explicit" e "forks = 20" questo non passerà: non esistono i loro equivalenti YaML. Dobbiamo impostarli in ansible.cfg o passarli tramite le variabili d'ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

Su Mitogen
— Dove si parla di Mitogen? — potresti chiederti, gentile lettore. In questo articolo — da nessuna parte. Ma se sei realmente pronto a leggere il suo codice e capire perché il tuo playbook fallisce con Mitogen mentre funziona normalmente con Ansible vanilla, oppure perché lo stesso playbook ha funzionato finora e dopo l'aggiornamento ha iniziato a comportarsi in modo strano — beh, Mitogen potrebbe potenzialmente essere il tuo strumento. Usalo, analizzalo, scrivi articoli — li leggerò con interesse.

Perché io personalmente non uso Mitogen? Perché funziona solo finché i task sono realmente semplici e tutto va bene. Ma appena si deviano leggermente a sinistra o a destra — è finita: riceverai una serie di eccezioni poco chiare, e per completare il quadro manca solo la frase comune "grazie a tutti, siete liberi". In generale, non voglio perdere tempo a scoprire le cause di un altro "colpo sotterraneo".

Parte di queste impostazioni sono state scoperte durante la lettura del codice sorgente plugin di connessione con un nome accattivante "ssh.py". Condivido i risultati della lettura nella speranza che questo possa ispirare qualcun altro a esaminare il codice sorgente, leggerlo, verificarne l'implementazione e confrontarlo con la documentazione: tutto ciò porterà, prima o poi, a risultati positivi. Buona fortuna!

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.