Hemos tenido una instancia de Ansible AWX en funcionamiento que se ejecuta en v5.0.0 durante más de un año y, de repente, todos los trabajos dejan de funcionar, no se procesa ningún resultado. Comenzarán a "ejecutarse" pero se colgarán indefinidamente sin imprimir ningún registro.
La instancia de AWX se ejecuta en una configuración de contenedor de composición de docker como se define aquí: https://github.com/ansible/awx/blob/5.0.0/INSTALL.md#docker-compose
La solución de problemas estándar, como el reinicio de contenedores, el sistema operativo host, etc., no ha ayudado. Sin cambios de configuración en ninguno de los entornos.
Al depurar un comando real del libro de jugadas, observamos que el comando para ejecutar un libro de jugadas desde la interfaz de usuario es como el siguiente:
ssh-agent sh -c ssh-add /tmp/awx_11021_0fmwm5uz/artifacts/11021/ssh_key_data && rm -f /tmp/awx_11021_0fmwm5uz/artifacts/11021/ssh_key_data && ansible-playbook -vvvvv -u ubuntu --become --ask-vault-pass -i /tmp/awx_11021_0fmwm5uz/tmppo7rcdqn -e @/tmp/awx_11021_0fmwm5uz/env/extravars playbook.yml
Eso se divide en tres comandos en secuencia:
ssh-agent sh -c ssh-add /tmp/awx_11021_0fmwm5uz/artifacts/11021/ssh_key_datarm -f /tmp/awx_11021_0fmwm5uz/artifacts/11021/ssh_key_dataansible-playbook -vvvvv -u ubuntu --become --ask-vault-pass -i /tmp/awx_11021_0fmwm5uz/tmppo7rcdqn -e @/tmp/awx_11021_0fmwm5uz/env/extravars playbook.yml Puede ver en la parte 3, -vvvvv es el argumento de depuración; sin embargo, el bloqueo se produce en el comando n. ° 1. Lo cual no tiene nada que ver con ansible o AWX específicamente, pero no nos dará mucha información de depuración.
Intenté hacer un strace para ver qué estaba pasando, pero por las razones que se indican a continuación, es bastante difícil seguir lo que realmente está sucediendo. Puedo proporcionar esta salida si puede ayudar.
Entonces, una pregunta natural con el comando n. ° 1: ¿qué es 'ssh_key_data'?
Bueno, es lo que configuramos para que sea la credencial de la máquina en AWX (una clave SSH); no ha cambiado en mucho tiempo y funciona bien cuando se usa en un comando SSH directo. Aparentemente, AWX también lo está configurando como una canalización de archivos:
prw------- 1 root root 0 Dec 10 08:29 ssh_key_data
Lo que comienza a explicar por qué podría estar colgando (si no se lee nada desde el otro lado de la tubería).
Ejecutar un libro de jugadas ansible normal desde la línea de comandos (y proporcionar la clave SSH de una manera más normal) funciona bien, por lo que aún podemos implementar, pero solo a través de CLI en este momento; solo AWX está roto.
Entonces, la pregunta se convierte en "¿por qué ahora?" ¿Y "cómo depurar"? Verifiqué el estado de awx_postgres y verifiqué que, de hecho, la credencial de la máquina está presente en el formato esperado (en la tabla main_credential ). También verifiqué que puedo usar ssh-agent en el contenedor awx_task sin el uso de ese archivo de claves de tubería. Entonces, realmente parece ser este archivo canalizado el problema, pero no he podido deducir de ningún registro dónde se supone que está el otro lado de la tubería (remitente) o por qué no están enviando los datos .
Tuve el mismo problema a partir de este viernes en el mismo período de tiempo que tú. Resultó que el agente Crowdstrike (sensor de halcón) era el culpable. Supongo que impulsaron una actualización de definición que está rompiendo o bloqueando las tuberías fifo. Cuando detuvimos el agente CS, AWX comenzó a funcionar correctamente nuevamente, sin problemas. Vea si está ejecutando un producto de seguridad similar.
Para los usuarios de Crowdstrike, es probable que el problema esté relacionado con un cambio de política implementado por su organización durante el fin de semana:
crowdstrike lanzó la versión 6.32, que fue adoptada por muchas organizaciones para responder a una vulnerabilidad de log4j durante el fin de semana, que introdujo algunos cambios en la inspección de nivel de script.
El monitoreo de ejecución basado en scripts es el culpable de la interrupción. Como han dicho otros usuarios, puede deshabilitar crowdstrike por completo y reiniciar los trabajos de AWX para que funcione, pero por seguridad en la producción, eso puede no ser apropiado.
En su lugar, debe comunicarse con su administrador de crowdstrike, quien habrá actualizado la política de su perfil de instancia para incluir el monitoreo de ejecución basado en scripts. La GUI de administración de políticas tiene una casilla de verificación que puede habilitar/deshabilitar el uso de esta característica (nuevo en 6.32). Pídales que lo deshabiliten y envíen los registros al proveedor.
La actualización de la política de Crowdstrike confirmada fue el problema por el cual Ansible Tower también dejó de funcionar durante 48 horas en nuestra empresa. Deshabilitar la opción de monitor permitió que los trabajos se ejecutaran con éxito casi al instante.