🥇Acelerant Ansible

No és cap secret que amb la configuració predeterminada Ansible no pot fer la seva feina molt ràpidament. A l'article assenyalaré diverses raons per això i oferiré un mínim útil de configuracions que, molt possiblement, augmentaran la velocitat del vostre projecte.

Aquí i a continuació parlem d'Ansible 2.9.x, que es va instal·lar en un virtualenv acabat de crear de la vostra manera preferida.

Després de la instal·lació, creeu un fitxer "ansible.cfg" al costat del vostre llibre de jocs; aquesta ubicació us permetrà transferir aquests paràmetres juntament amb el projecte i, a més, es carregaran de manera força automàtica.

Canalització

És possible que alguns ja hagin sentit a parlar de la necessitat d'utilitzar pipelining, és a dir, no copiar mòduls al sistema de fitxers del sistema de destinació, sinó transferir un arxiu zip embolicat en Base64 directament a l'stdin de l'intèrpret de Python, però altres potser no, però el fet segueix sent un fet: aquesta configuració segueix sent subestimada. Malauradament, algunes de les distribucions populars de Linux que s'utilitzen per configurar sudo no són gaire bé per defecte, de manera que aquesta ordre requeria un tty (terminal), de manera que Ansible va deixar aquesta configuració molt útil desactivada per defecte.

pipelining = True

Recull de fets

Sabíeu que amb la configuració predeterminada, Ansible per a cada jugada inicia la recopilació de dades per a tots els amfitrions que hi participen? En general, si no ho sabies, ara ja ho saps. Per evitar que això passi, heu d'activar el mode de sol·licitud explícita per recopilar fets (explícit) o el mode intel·ligent. En ell, només es recolliran dades d'aquells amfitrions que no s'haguessin trobat en jugades anteriors.
UPD. Quan copieu, haureu de seleccionar una d'aquestes configuracions.

gathering = smart|explicit

Reutilització de connexions ssh

Si alguna vegada heu executat Ansible en mode de depuració (l'opció "v", repetida d'una a nou vegades), potser us heu adonat que les connexions ssh es fan i es trenquen constantment. Per tant, aquí també hi ha un parell de subtileses.

Podeu evitar el pas de restablir una connexió ssh a dos nivells alhora: tant directament al client ssh com quan transferiu fitxers a l'amfitrió gestionat des del gestor.
Per reutilitzar una connexió ssh oberta, només cal que passeu les claus necessàries al client ssh. Llavors començarà a fer el següent: quan s'estableixi una connexió ssh per primera vegada, també crearà l'anomenat sòcol de control, en instal·lacions posteriors, comprovarà l'existència d'aquest mateix sòcol i, si té èxit, reutilitzarà el connexió ssh existent. I perquè tot això tingui sentit, establim l'hora per mantenir la connexió quan estigui inactiu. Podeu llegir més a documentació ssh, i en el context d'Ansible simplement fem servir "reenviament" de les opcions necessàries al client ssh.

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

Per reutilitzar una connexió ssh ja oberta en transferir fitxers a un amfitrió gestionat, només cal que especifiqueu una altra configuració desconeguda ssh_transfer_method. La documentació sobre aquest tema és extremadament avaro i enganyosa, perquè aquesta opció funciona força bé! Però la lectura codi font us permet entendre què passarà exactament: l'ordre dd es llançarà a l'amfitrió gestionat, treballant directament amb el fitxer desitjat.

transfer_method = piped

Per cert, a la branca "desenvolupament" també existeix aquesta configuració no anar enlloc.

No tingueu por del ganivet, tingueu por de la forquilla

Una altra configuració útil són les forquilles. Determina el nombre de processos de treball que es connectaran simultàniament als amfitrions i realitzaran tasques. A causa de les peculiaritats de Python com a llenguatge, s'utilitzen processos, no fils, perquè Ansible encara és compatible amb Python 2.7: no hi ha sincronització, no té sentit introduir un comportament asíncron aquí! Per defecte, Ansible s'executa 05:00 treballadors, però si es demana correctament, en llançarà més:

forks = 20

Només us adverteixo de seguida que hi pot haver algunes dificultats relacionades amb la quantitat de memòria disponible a la màquina de control. En altres paraules, podeu, per descomptat, establir forks=100500, però qui va dir que funcionaria?

Ajuntant-ho tot

Com a resultat, per a ansible.cfg (format ini), la configuració necessària pot ser així:

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

I si voleu amagar-ho tot en un inventari normal de YaML d'una persona sana, pot semblar una cosa així:

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

Malauradament, això no funcionarà amb la configuració "gathering = smart/explicit" i "forks = 20": els seus equivalents de YaML no existeixen. O els establim a ansible.cfg, o els passem per les variables d'entorn ANSIBLE_GATHERING i ANSIBLE_FORKS.

Sobre Mitogen
- On és això de Mitogen? - tens dret a preguntar, estimat lector. Enlloc d'aquest article. Però si realment esteu preparat per llegir el seu codi i esbrinar per què el vostre llibre de jugades es bloqueja amb Mitogen, però funciona bé amb Vanilla Ansible, o per què el mateix llibre de jocs funcionava bé abans, però després d'una actualització va començar a fer coses estranyes, bé, Mitogen podria ser la teva eina. Aplicar-lo, entendre-lo, escriure articles: el llegiré amb interès.

Per què no faig servir personalment Mitogen? Perquè Gladiolus només funciona sempre que les tasques siguin realment senzilles i tot estigui bé. Tanmateix, si gireu una mica cap a l'esquerra o la dreta, això és tot, hem arribat: com a resposta, un grapat d'excepcions indistintes us volen cap amunt, i per completar la imatge, només falta la frase comuna "gràcies a tots". , tothom és lliure". En general, no vull perdre el temps esbrinant els motius del proper "coc subterrani".

Algunes d'aquestes configuracions es van descobrir durant el procés de lectura codi font connector de connexió amb el nom autoexplicatiu "ssh.py". Comparteixo els resultats de la lectura amb l'esperança que inspiri algú a mirar les fonts, llegir-les, comprovar la implementació, comparar amb la documentació; després de tot, tard o d'hora, tot això us donarà resultats positius. Bona sort!

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.

Quina de les opcions següents d'Ansible feu servir per accelerar els vostres projectes?

69,6%pipelining=true32
34,8%reunió = intel·ligent/explícit16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%transfer_method = piped8
63,0%forquilles = XXX29
6,5%Res d'això, només Mitogen3
8,7%Mitogen + notaré quina d'aquestes configuracions4

Han votat 46 usuaris. 21 usuari es va abstenir.

Vols més coses sobre Ansible?

78,3%sí, és clar54
21,7%sí, només vull més coses hardcore!15
0,0%no, i no és necessari per a res0
0,0%no, és complicat!!!0

Han votat 69 usuaris. 7 usuaris es van abstenir.

Font: www.habr.com

Accelerant Ansible