ansible ansible-2.x

¿Cómo puedo mostrar el progreso de una tarea Ansible de larga ejecución?



ansible-2.x (3)

Tengo algunas tareas ansibles que realizan operaciones desafortunadamente largas, como ejecutar una operación de sincronización con una carpeta S3. No siempre está claro si están progresando, o simplemente atascados (o la conexión ssh ha muerto), por lo que sería bueno tener algún tipo de resultado de progreso mostrado. Si el comando stdout / stderr se mostrara directamente, lo vería, pero Ansible captura la salida.

La devolución de la tubería es un problema difícil para Ansible para resolver en su forma actual . Pero, ¿hay algún truco de Ansible que pueda usar para proporcionar algún tipo de indicación de que las cosas todavía se están moviendo?

La entrada actual es https://github.com/ansible/ansible/issues/4870


Encontré este problema hoy en OSX, donde estaba ejecutando un comando shell de docker que tardó mucho tiempo en construirse y no hubo salida mientras se construía. Fue muy frustrante no entender si el comando se había colgado o simplemente estaba progresando lentamente.

Decidí canalizar la salida (y el error) del comando de shell a un puerto, que luego podría escucharse a través de netcat en un terminal separado.

myplaybook.yml - name: run some long-running task and pipe to a port shell: myLongRunningApp > /dev/tcp/localhost/4000 2>&1

Y en una ventana de terminal separada:

$ nc -lk 4000 Output from my long running app will appear here

Tenga en cuenta que canalizo la salida de error al mismo puerto; Podría fácilmente canalizar a un puerto diferente.

Además, terminé configurando una variable llamada nc_port que permitirá cambiar el puerto en caso de que ese puerto esté en uso. La tarea ansible entonces se ve como:

shell: myLongRunningApp > /dev/tcp/localhost/{{nc_port}} 2>&1

Tenga en cuenta que el comando myLongRunningApp se está ejecutando en localhost (es decir, ese es el host configurado en el inventario), por eso escucho a localhost con nc .


Hay un par de cosas que puedes hacer, pero como bien has señalado, Ansible en su forma actual no ofrece realmente una buena solución.

Soluciones oficiales-ish:

Una idea es marcar la tarea como asíncrona y encuestarla. Obviamente, esto solo es adecuado si es capaz de ejecutarse de tal manera sin causar fallas en otras partes de tu libro de jugadas. Los documentos asíncronos están here y he here un ejemplo de ellos:

- hosts: all remote_user: root tasks: - name: simulate long running op (15 sec), wait for up to 45 sec, poll every 5 sec command: /bin/sleep 15 async: 45 poll: 5

Esto puede, al menos, darle un ''ping'' para saber que la tarea no está pendiente.

El único otro método respaldado oficialmente sería Ansible Tower, que tiene barras de progreso para tareas pero no es gratis.

Soluciones Hacky-Ish:

Más allá de lo anterior, vas a tener que rodar el tuyo. Su ejemplo específico de sincronización de un grupo de S3 se puede monitorear con bastante facilidad con una secuencia de comandos que llama periódicamente al CLI de AWS y cuenta la cantidad de elementos en un grupo, pero eso no es una buena solución genérica.

Lo único que podría imaginar siendo algo efectivo sería ver la sesión de ssh entrante desde uno de sus nodos.

Para hacerlo, puede configurar el usuario ansible en esa máquina para conectarse a través de la pantalla y verlo activamente. Alternativamente, tal vez utilice la opción log_output en la entrada sudoers para ese usuario, lo que le permite log_output el archivo. Los detalles de log_output se pueden encontrar en la página del manual de sudoers


Si está en Linux, puede usar systemd-run para crear una unidad transitoria e inspeccionar la salida con journalctl , como:

sudo systemd-run --unit foo / bash -c ''for i in {0..10}; do echo "$((i * 10))%"; sleep 1; done; echo "Complete"''

Y en otra sesion

sudo journalctl -xf --unit foo

Saldría algo como:

Apr 07 02:10:34 localhost.localdomain systemd[1]: Started /bin/bash -c for i in {0..10}; do echo "$((i * 10))%"; sleep 1; done; echo "Complete". -- Subject: Unit foo.service has finished start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit foo.service has finished starting up. -- -- The start-up result is done. Apr 07 02:10:34 localhost.localdomain bash[10083]: 0% Apr 07 02:10:35 localhost.localdomain bash[10083]: 10% Apr 07 02:10:36 localhost.localdomain bash[10083]: 20% Apr 07 02:10:37 localhost.localdomain bash[10083]: 30% Apr 07 02:10:38 localhost.localdomain bash[10083]: 40% Apr 07 02:10:39 localhost.localdomain bash[10083]: 50% Apr 07 02:10:40 localhost.localdomain bash[10083]: 60% Apr 07 02:10:41 localhost.localdomain bash[10083]: 70% Apr 07 02:10:42 localhost.localdomain bash[10083]: 80% Apr 07 02:10:43 localhost.localdomain bash[10083]: 90% Apr 07 02:10:44 localhost.localdomain bash[10083]: 100% Apr 07 02:10:45 localhost.localdomain bash[10083]: Complete