🥇Acelerando Ansible

Non é ningún segredo que coa configuración predeterminada Ansible non pode facer o seu traballo moi rapidamente. No artigo indicarei varias razóns para iso e ofrecerei un mínimo de configuración útil que, moi posiblemente, aumente a velocidade do teu proxecto.

Aquí e a continuación comentamos Ansible 2.9.x, que se instalou nun virtualenv recén creado ao teu xeito favorito.

Despois da instalación, crea un ficheiro "ansible.cfg" xunto ao teu playbook; esta localización permitirache transferir esta configuración xunto co proxecto, ademais de cargarse de forma bastante automática.

Tuberías

Algúns xa escoitaron falar da necesidade de usar o pipelining, é dicir, non copiar módulos no sistema de ficheiros do sistema de destino, senón transferir un arquivo zip envolto en Base64 directamente ao stdin do intérprete de Python, pero outros poden non, pero o feito segue sendo un feito: esta configuración aínda segue subestimada. Desafortunadamente, algunhas das distribucións populares de Linux usadas para configurar sudo non son moi ben por defecto, polo que este comando requiría un tty (terminal), polo que Ansible deixou esta configuración moi útil desactivada por defecto.

pipelining = True

Recopilación de feitos

Sabías que coa configuración predeterminada, Ansible para cada xogada inicia a recollida de datos para todos os anfitrións que participan nela? En xeral, se non o sabías, agora xa sabes. Para evitar que isto ocorra, cómpre activar o modo de solicitude explícita para recoller feitos (explícito) ou o modo intelixente. Nela recolleranse datos só daqueles anfitrións que non se atopasen en xogadas anteriores.
UPD. Ao copiar, terás que seleccionar unha destas opcións.

gathering = smart|explicit

Reutilizando conexións ssh

Se algunha vez executaches Ansible no modo de depuración (a opción "v", repetida de unha a nove veces), quizais teñas notado que as conexións ssh están a facerse e romperse constantemente. Polo tanto, tamén hai un par de sutilezas aquí.

Pode evitar o paso de restablecer unha conexión ssh en dous niveis á vez: ambos directamente no cliente ssh e ao transferir ficheiros ao host xestionado desde o xestor.
Para reutilizar unha conexión ssh aberta, simplemente pase as chaves necesarias ao cliente ssh. Entón comezará a facer o seguinte: ao establecer unha conexión ssh por primeira vez, creará ademais un chamado socket de control, nas instalacións posteriores comprobará a existencia deste mesmo socket e, se ten éxito, reutilizará o conexión ssh existente. E para que todo isto teña sentido, imos establecer o momento para manter a conexión cando estea inactiva. Podes ler máis en documentación ssh, e no contexto de Ansible simplemente usamos "reenviar" as opcións necesarias ao cliente ssh.

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

Para reutilizar unha conexión ssh xa aberta ao transferir ficheiros a un host xestionado, só tes que especificar outra configuración descoñecida ssh_transfer_method. A documentación sobre este tema é extremadamente tacaño e enganoso, porque esta opción funciona bastante ben! Pero lendo código fonte permítelle comprender o que sucederá exactamente: o comando dd lanzarase no host xestionado, traballando directamente co ficheiro desexado.

transfer_method = piped

Por certo, na rama "desenvolver" tamén existe esta configuración non vai a ningures.

Non teñas medo ao coitelo, ten medo ao garfo

Outra opción útil son os garfos. Determina o número de procesos de traballo que se conectarán simultaneamente aos hosts e realizarán tarefas. Debido ás peculiaridades de Python como linguaxe, utilízanse procesos, non fíos, porque Ansible aínda admite Python 2.7. Non hai asíncrono para ti, non ten sentido introducir aquí un comportamento asíncrono. Por defecto execútase Ansible cinco traballadores, pero se se lle pregunta correctamente, lanzará máis:

forks = 20

Só aviso de inmediato de que aquí pode haber algunhas dificultades relacionadas coa cantidade de memoria dispoñible na máquina de control. Noutras palabras, pode, por suposto, establecer garfos=100500, pero quen dixo que funcionaría?

Xuntando todo

Como resultado, para ansible.cfg (formato ini), a configuración necesaria pode verse así:

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

E se queres ocultar todo nun inventario normal de YaML dunha persoa sa, pode parecer algo así:

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

Desafortunadamente, isto non funcionará coas opcións "gathering = smart/explicit" e "forks = 20": os seus equivalentes de YaML non existen. Ou os establecemos en ansible.cfg ou os pasamos polas variables de ambiente ANSIBLE_GATHERING e ANSIBLE_FORKS.

Sobre Mitogen
- Onde está isto de Mitogen? - tes dereito a preguntar, querido lector. En ningún lugar deste artigo. Pero se estás realmente preparado para ler o seu código e descubrir por que o teu libro de jugadas falla con Mitogen, pero funciona ben con vanilla Ansible, ou por que o mesmo libro de xogos funcionaba ben antes, pero despois dunha actualización comezou a facer cousas estrañas, ben, Mitogen podería ser potencialmente a túa ferramenta. Aplícalo, entendelo, escribe artigos: lereino con interese.

Por que non uso persoalmente Mitogen? Porque o gladiolo só funciona sempre que as tarefas sexan realmente sinxelas e todo estea ben. Non obstante, se xiras un pouco á esquerda ou á dereita, xa está, chegamos: en resposta, un puñado de excepcións indistintas volan cara a ti e, para completar a imaxe, só falta a frase común "grazas a todos". , todos son libres". En xeral, non quero perder o tempo descubrindo os motivos do próximo "golpe subterráneo".

Algunhas destas configuracións foron descubertas durante o proceso de lectura código fonte plugin de conexión baixo o nome autoexplicativo "ssh.py". Comparto os resultados da lectura coa esperanza de que inspire a outra persoa a mirar as fontes, lelas, comprobar a implementación, comparar coa documentación; despois de todo, tarde ou cedo, todo isto traerá resultados positivos. Moita sorte!

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Cal das seguintes opcións de configuración de Ansible utilizas para acelerar os teus proxectos?

69,6%canalización=true32
34,8%reunión = intelixente/explícito16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%método_transferencia = pipe8
63,0%garfos = XXX29
6,5%Nada diso, só Mitogen3
8,7%Mitogen + Notarei cal destas opcións4

Votaron 46 usuarios. 21 usuario abstívose.

Queres máis cousas sobre Ansible?

78,3%si, claro54
21,7%si, só quero máis cousas hardcore!15
0,0%non, e non é necesario para nada0
0,0%non, é complicado!!!0

Votaron 69 usuarios. 7 usuarios abstivéronse.

Fonte: www.habr.com

Acelerando Ansible