🥇Acceleriamo Ansible

Non è un segreto che con le impostazioni "di default" Ansible possa non funzionare troppo velocemente. In questo articolo evidenzierò alcune ragioni e fornirò un utile minimo di impostazioni che, plausibilmente, possono aumentare la velocità di esecuzione del tuo progetto.

Discutiamo qui e in seguito di Ansible 2.9.x, che è stato installato nel nuovo virtualenv nel modo che preferisci.

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

Pipeline

Chiunque abbia sentito dire che è necessario utilizzare il pipelining, cioè non copiare i moduli nel filesystem del sistema target, ma trasferire un archivio zip avvolto in Base64 direttamente su stdin dell'interprete Python, sa che il fatto resta: questa impostazione rimane ancora sottovalutata. Sfortunatamente, qualche distribuzione popolare di Linux in passato configurava male sudo per impostazione predefinita, in modo tale che questo comando richiedesse un tty (terminal), quindi in Ansible questa utile impostazione è stata lasciata disabilitata per impostazione predefinita.

pipelining = True

Raccolta dei fatti

Sapevi che con le impostazioni di default Ansible avvia la raccolta dei fatti per ogni play a tutti gli host coinvolti? In generale, se non lo sapevi, ora lo sai. Per evitare che ciò accada, è necessario attivare o la modalità di richiesta esplicita per la raccolta dei fatti (explicit) o la modalità smart. In quest'ultima, i fatti verranno raccolti solo dagli host che non sono stati incontrati nei play precedenti.
UPD. Durante la copia, dovrai scegliere una di queste impostazioni.

gathering = smart|explicit

Riutilizzo delle connessioni ssh

Se hai mai eseguito Ansible in modalità di output di debug (opzione "v", ripetuta da una a nove volte), probabilmente hai notato che le connessioni ssh vengono continuamente stabilite e interrotte. Ecco, qui ci sono anche un paio di dettagli.

Evitare la fase di reinizializzazione delle connessioni ssh è possibile a 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 trasferire le chiavi necessarie al client ssh. In questo modo inizierà a fare quanto segue: alla prima installazione della connessione ssh crea un cosiddetto socket di controllo, e alle successive – verifica l'esistenza di questo socket e, se ha successo, riutilizza la connessione ssh esistente. E affinché tutto ciò abbia senso, impostiamo il tempo di mantenimento della connessione in caso di inattività. Puoi trovare maggiori dettagli nella documentazione su ssh, mentre nel contesto di Ansible utilizziamo semplicemente il «forwarding» delle opzioni necessarie 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'ulteriore impostazione sconosciuta chiamata ssh_transfer_method. La documentazione a riguardo è estremamente scarso e fuorviante, poiché quest'opzione funziona perfettamente! Invece, la lettura del codice sorgente consente di capire cosa accadrà: sul host gestito verrà eseguito il comando dd, che lavora direttamente con il file desiderato.

transfer_method = piped

A proposito, nel ramo «develop» questa impostazione esiste anche e non è scomparsa.

Non temere il coltello, temi la forchetta

Un'altra impostazione utile è forks. Questa determina il numero di processi di lavoro che si connetteranno contemporaneamente agli host e eseguiranno i task. A causa delle peculiarità di Python come linguaggio di programmazione, vengono utilizzati proprio i processi e non i thread, perché Ansible supporta ancora Python 2.7 – non c'è nulla di asyncio qui, non è il caso di creare asynchrony! Per impostazione predefinita, Ansible avvia cinque worker, ma se si richiede correttamente, può avviarne di più:

forks = 20

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

Raccogliamo tutto insieme

In definitiva, per ansible.cfg (formato ini) le impostazioni necessarie potrebbero 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 funzionerà: i loro equivalenti YaML non esistono. Dobbiamo definirli in ansible.cfg o passarli tramite le variabili d'ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

Su Mitogen
— E dove si parla di Mitogen qui? — potresti chiedere, caro lettore. In questo articolo — da nessuna parte. Ma se sei davvero disposto a leggere il suo codice e capire perché il tuo playbook fallisce con Mitogen, mentre funziona correttamente con Ansible vanilla, o perché lo stesso playbook ha funzionato bene fino all'aggiornamento e ora fa cose strane — beh, Mitogen potrebbe essere il tuo strumento. Usalo, studialo, scrivi articoli — li leggerò con interesse.

Perché personalmente non uso Mitogen? Perché funziona solo quando i task sono realmente semplici e tutto va bene. Tuttavia, basta deviare leggermente a sinistra o a destra — ed è finita: ricevi una manciata di eccezioni confuse in risposta, e per completare il quadro manca solo la frase comune «grazie a tutti, siete liberi». Insomma, non voglio semplicemente perdere tempo a scoprire le ragioni di un ennesimo «rumore sotterraneo».

Parte di queste impostazioni sono state scoperte durante la lettura del codice sorgente del plugin di connessione dal nome eloquente «ssh.py». Condivido i risultati della lettura nella speranza che questo possa ispirare qualcun altro a guardare nel codice sorgente, leggerlo, verificare l'implementazione, confrontare con la documentazione — poiché tutto ciò alla fine porterà risultati positivi. Buona fortuna!

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