🥇Accelerare Ansible

Non è un segreto che con le impostazioni predefinite Ansible non possa svolgere il suo lavoro molto rapidamente. Nell'articolo indicherò diversi motivi per ciò e offrirò un minimo utile di impostazioni che, molto probabilmente, aumenteranno effettivamente la velocità del tuo progetto.

Qui e di seguito discutiamo di Ansible 2.9.x, che è stato installato in un virtualenv appena creato nel modo che preferisci.

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

Pipeline

Alcuni potrebbero aver già sentito parlare della necessità di utilizzare il pipelining, cioè non copiare i moduli nel file system del sistema di destinazione, ma trasferire un archivio zip avvolto in Base64 direttamente nello stdin dell'interprete Python, ma altri no, ma il fatto resta un dato di fatto: questa impostazione resta ancora sottovalutato. Sfortunatamente, alcune delle popolari distribuzioni Linux utilizzate per configurare sudo non molto bene per impostazione predefinita, quindi questo comando richiedeva un tty (terminale), quindi Ansible ha lasciato questa impostazione molto utile disabilitata per impostazione predefinita.

pipelining = True

Raccolta di fatti

Sapevi che con le impostazioni predefinite, Ansible per ogni riproduzione avvia la raccolta dei fatti per tutti gli host che vi partecipano? In generale, se non lo sapevi, ora lo sai. Per evitare che ciò accada, è necessario abilitare la modalità di richiesta esplicita per la raccolta dei fatti (esplicita) o la modalità intelligente. In esso verranno raccolti fatti solo da quegli host che non sono stati incontrati nelle commedie precedenti.
AGGIORNAMENTO. Durante la copia, dovrai selezionare una di queste impostazioni.

gathering = smart|explicit

Riutilizzo delle connessioni ssh

Se hai mai eseguito Ansible in modalità debug (l'opzione "v", ripetuta da una a nove volte), potresti aver notato che le connessioni ssh vengono costantemente stabilite e interrotte. Quindi, anche qui ci sono un paio di sottigliezze.

Puoi evitare il passaggio di ristabilire una connessione ssh a due livelli contemporaneamente: sia direttamente nel client ssh, sia durante il trasferimento di file all'host gestito dal gestore.
Per riutilizzare una connessione ssh aperta, passa semplicemente le chiavi necessarie al client ssh. Quindi inizierà a fare quanto segue: quando stabilisce una connessione ssh per la prima volta, creerà inoltre un cosiddetto socket di controllo, nelle installazioni successive controllerà l'esistenza di questo stesso socket e, in caso di successo, riutilizzerà il connessione ssh esistente. E per dare un senso a tutto ciò, impostiamo il tempo per il mantenimento della connessione quando inattivo. Puoi leggere di più in documentazione ssh, e nel contesto di Ansible usiamo semplicemente "inoltrare" le 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, basta specificare un'altra impostazione sconosciuta ssh_tranfer_method. La documentazione su questo argomento è estremamente avaro e fuorviante, perché questa opzione funziona abbastanza bene! Ma leggere codice sorgente permette di capire cosa accadrà esattamente: il comando dd verrà lanciato sull'host gestito, lavorando direttamente con il file desiderato.

transfer_method = piped

A proposito, nel ramo "sviluppo" esiste anche questa impostazione non andato da nessuna parte.

Non aver paura del coltello, abbi paura della forchetta

Un'altra impostazione utile è fork. Determina il numero di processi di lavoro che si connetteranno simultaneamente agli host ed eseguiranno attività. A causa delle peculiarità di Python come linguaggio, vengono utilizzati i processi, non i thread, perché Ansible supporta ancora Python 2.7: niente asincio per te, non ha senso introdurre qui un comportamento asincrono! Per impostazione predefinita, Ansible viene eseguito cinque lavoratori, ma se richiesto correttamente, ne avvierà altri:

forks = 20

Ti avverto subito che qui potrebbero esserci delle difficoltà legate alla quantità di memoria disponibile sulla macchina di controllo. In altre parole, puoi ovviamente impostare forks=100500, ma chi ha detto che avrebbe funzionato?

Mettere tutto insieme

Di conseguenza, per ansible.cfg (formato ini), le impostazioni necessarie potrebbero assomigliare a queste:

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

E se vuoi nascondere tutto in un normale inventario YaML di una persona sana, allora può assomigliare a questo:

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

Sfortunatamente, questo non funzionerà con le impostazioni “gathering = smart/explicit” e “forks = 20”: i loro equivalenti YaML non esistono. O li impostiamo in ansible.cfg o li passiamo attraverso le variabili di ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

A proposito di Mitogen
- Dov'è questa storia di Mitogen? - hai il diritto di chiedere, caro lettore. Da nessuna parte in questo articolo. Ma se sei davvero pronto a leggere il suo codice e capire perché il tuo playbook si blocca con Mitogen, ma funziona bene con Ansible vaniglia, o perché lo stesso playbook funzionava bene prima, ma dopo un aggiornamento ha iniziato a fare cose strane - beh, Mitogen potrebbe potenzialmente essere il tuo strumento. Applicalo, capiscilo, scrivi articoli: lo leggerò con interesse.

Perché non uso personalmente Mitogen? Perché gladiolo funziona solo finché i compiti sono veramente semplici e tutto va bene. Ma se giri un po' a sinistra o a destra ecco, siamo arrivati: in risposta ti volano addosso una manciata di eccezioni indistinte, e per completare il quadro manca solo la frase comune “grazie a tutti”. , tutti sono liberi”. In generale, non voglio perdere tempo a scoprire le ragioni del prossimo "colpo sotterraneo".

Alcune di queste impostazioni sono state scoperte durante il processo di lettura codice sorgente plugin di connessione con il nome autoesplicativo “ssh.py”. Condivido i risultati della lettura nella speranza che ispiri qualcun altro a guardare le fonti, leggerle, controllare l'implementazione, confrontarsi con la documentazione - dopo tutto, prima o poi tutto ciò ti porterà risultati positivi. Buona fortuna!

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Quale delle seguenti impostazioni Ansible utilizzi per velocizzare i tuoi progetti?

69,6%pipeline=true32
34,8%raccolta = intelligente/esplicito16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%metodo_trasferimento = piped8
63,0%forchette = XXX29
6,5%Niente di tutto questo, solo Mitogen3
8,7%Mitogen + prenderò nota di quale di queste impostazioni4

46 utenti hanno votato. 21 utente si è astenuto.

Vuoi altre informazioni su Ansible?

78,3%sì, certo54
21,7%sì, voglio solo cose più hardcore!15
0,0%no, e non è necessario per niente0
0,0%no, è complicato!!!0

69 utenti hanno votato. 7 utenti si sono astenuti.

Fonte: habr.com

Accelerare Ansible