Definir handlers y patrones de reinicio

Los handlers se colocan en su propia sección handlers del play, separada de las tareas normales. Así las acciones reactivas quedan agrupadas con claridad.

Un handler utiliza exactamente la misma sintaxis que una tarea: un name y una llamada a un módulo. La única diferencia es que espera a recibir una notificación.

El name del handler es la cadena a la que hacen referencia otras tareas en su notify. Trátelo como una etiqueta estable y exacta que reutilizará.

Un handler de reinicio clásico utiliza el módulo service con el estado establecido en restarted. Detiene e inicia la unidad en un solo paso.

Prefiera reloaded cuando un servicio lo admita. Una recarga vuelve a leer la configuración sin interrumpir las conexiones, a diferencia de un reinicio completo.

El módulo systemd ofrece un control más preciso en hosts systemd, incluido daemon_reload después de cambiar un archivo de unidad.

Escriba un único handler reutilizable Reiniciar nginx y notifíquelo desde muchas tareas. Evite copiar la misma lógica de reinicio por todas partes.

Cuando hay varios handlers en cola, se ejecutan en el orden en que se definieron, no en el orden en que recibieron la notificación. Planifique esa secuencia.

Si una recarga debe ocurrir antes que un reinicio, defínalos en ese orden en la lista de handlers para que la cola se procese correctamente.

En un role, los handlers se encuentran en handlers/main.yml. Las tareas del role los notifican por nombre, exactamente igual que en un playbook normal.

Use nombres con formato de acción, como Reiniciar nginx o Recargar sshd. Los nombres claros hacen que la salida sea legible y que las líneas notify sean evidentes.

Ha cambiado una configuración y quiere que el servicio en ejecución la adopte sin interrumpir las conexiones. ¿Qué estado es el más adecuado?

Ahora puede definir handlers en la sección handlers, elegir entre reiniciar y recargar, y confiar en que se ejecuten en el orden de definición. 🎯