🥇Acelerando Ansible

No es un secreto que con la configuración 'por defecto', Ansible puede no desempeñarse de manera muy rápida. En este artículo, señalaré algunas de las razones de esto y ofreceré un conjunto mínimo útil de configuraciones que, posiblemente, realmente aumenten la velocidad de trabajo de su proyecto.

Discutimos aquí y en adelante Ansible 2.9.x, que fue instalado en un virtualenv recién creado de la forma que más le gusta.

Después de la instalación, creamos un archivo 'ansible.cfg' junto a su playbook: esta ubicación permitirá transferir estas configuraciones junto con el proyecto, además se cargarán automáticamente.

Canalización

Alguien pudo haber escuchado que es necesario usar la canalización, es decir, no copiar módulos en el sistema de archivos del sistema objetivo, sino transmitir un archivo zip envuelto en Base64 directamente a stdin del intérprete de Python; algunos ya lo sabían y otros no, pero el hecho es que: esta configuración sigue siendo subestimada. Desafortunadamente, alguna de las distribuciones populares de Linux configuraba anteriormente sudo de manera no óptima por defecto - de tal modo que este comando requería un tty (terminal), por lo que Ansible dejó esta configuración tan útil desactivada por defecto.

pipelining = True

Recolección de hechos

¿Sabía que con la configuración por defecto, Ansible inicia la recolección de hechos para cada play desde todos los hosts que participan en él? En general, si no lo sabía, ahora lo sabe. Para evitar que esto ocurra, debe habilitar el modo de solicitud explícita de recolección de hechos (explicit) o el modo inteligente (smart). En éste, los hechos solo se recogerán de aquellos hosts que no hayan aparecido en plays anteriores.
UPD. Al copiar, deberá elegir alguna de estas configuraciones.

gathering = smart|explicit

Reutilización de conexiones ssh

Si alguna vez ha ejecutado Ansible en modo de salida de depuración (opción 'v', repetida de una a nueve veces), es posible que haya notado que las conexiones ssh se establecen y se rompen constantemente. Pues bien, aquí también existen un par de matices.

Se puede evitar la etapa de reinstalación de la conexión ssh en dos niveles a la vez: tanto en el cliente ssh como durante la transferencia de archivos al host administrado desde el controlador.
Para reutilizar una conexión SSH abierta, simplemente es necesario pasar las claves necesarias al cliente SSH. Así, comenzará a hacer lo siguiente: al establecer la primera conexión SSH, creará un control socket adicional y, en las posteriores, verificará la existencia de dicho socket y, si tiene éxito, reutilizará la conexión SSH existente. Para que todo esto tenga sentido, definamos el tiempo de conservación de la conexión en caso de inactividad. Se puede leer más en la documentación de SSH, y en el contexto de Ansible, simplemente utilizamos el "forwarding" de las opciones necesarias al cliente SSH.

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

Para reutilizar ya una conexión SSH abierta al transferir archivos al host gestionado, es suficiente con indicar otra configuración desconocida, ssh_transfer_method. La documentación al respecto es extremadamente escasa y puede resultar confusa, ya que esta opción realmente funciona. Pero la lectura del código fuente permite entender qué es lo que sucederá: se ejecutará un comando dd en el host gestionado, trabajando directamente con el archivo necesario.

transfer_method = piped

Por cierto, en la rama "develop" esta configuración también existe y no ha desaparecido.

No temas al cuchillo, teme al tenedor

Otra configuración útil es forks. Esta define la cantidad de procesos de trabajo que se conectarán simultáneamente a los hosts y ejecutarán tareas. Debido a las características de Python como lenguaje de programación, se usan procesos y no hilos, porque Ansible aún soporta Python 2.7 — ¡nada de asyncio, aquí no hay que complicarse con asincronía! Por defecto, Ansible inicia cinco trabajadores, pero si se pide correctamente, puede iniciar más:

forks = 20

Sólo aviso que aquí pueden surgir algunas complicaciones relacionadas con la cantidad de memoria en la máquina de gestión. En otras palabras, se puede establecer forks=100500, por supuesto, pero ¿quién ha dicho que funcionará?

Resumiendo todo

Al final, para ansible.cfg (formato ini) las configuraciones necesarias pueden verse así:

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

Y si deseas ocultar todo en un inventario YaML saludable, puede verse aproximadamente así:

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

Desafortunadamente, con la configuración «gathering = smart/explicit» y «forks = 20», eso no funcionará: no existen sus equivalentes en YAML. Debemos configurarlos en ansible.cfg o pasarlos a través de las variables de entorno ANSIBLE_GATHERING y ANSIBLE_FORKS.

Sobre Mitogen
— ¿Y dónde se menciona a Mitogen? — podrías preguntarte, estimado lector. En este artículo — en ninguna parte. Pero si realmente estás dispuesto a leer su código y entender por qué tu playbook falla con Mitogen, pero funciona bien con Ansible estándar, o por qué este mismo playbook funcionó correctamente hasta que se actualizó y ahora hace cosas extrañas — pues bien, Mitogen puede ser tu herramienta. Utilízalo, investiga, escribe artículos — los leeré con interés.

¿Por qué personalmene no utilizo Mitogen? Porque funciona, pero solo mientras las tareas son realmente simples y todo va bien. Sin embargo, si te desvías un poco a la izquierda o a la derecha — eso es todo: lo que recibes es un montón de excepciones confusas, y para completar el cuadro solo falta la frase común «gracias a todos, están libres». En resumen, simplemente no quiero perder tiempo tratando de averiguar las razones de otro «golpe subterráneo».

Parte de estas configuraciones se descubrieron al leer del código fuente el plugin de conexión con el ingenioso nombre «ssh.py». Comparto los resultados de la lectura con la esperanza de que esto inspire a otros a mirar el código fuente, leerlo, verificar su implementación, compararla con la documentación — porque todo esto, tarde o temprano, te brindará resultados positivos. ¡Buena suerte!

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.