Definindo handlers e padrões de reinicialização

Os manipuladores ficam em sua própria seção handlers de um play, separada das tarefas comuns. Isso mantém as ações reativas claramente agrupadas.

Um manipulador usa exatamente a mesma sintaxe que uma tarefa: um name e uma chamada de módulo. A única diferença é que ele espera ser notificado.

O name do manipulador é a sequência que outras tarefas referenciam em seu notify. Trate-o como um rótulo estável e exato que será reutilizado.

Um manipulador clássico de reinício usa o módulo service com o estado definido como restarted. Ele para e inicia a unidade em uma única etapa.

Prefira reloaded quando um serviço oferecer suporte a esse estado. O recarregamento lê a configuração novamente sem interromper as conexões, ao contrário de um reinício completo.

O módulo systemd oferece um controle mais preciso em hosts systemd, incluindo daemon_reload depois que você altera um arquivo de unidade.

Escreva um manipulador reutilizável Reiniciar nginx e notifique-o a partir de várias tarefas. Evite copiar a mesma lógica de reinício por toda parte.

Quando vários manipuladores entram na fila, eles são executados na ordem em que são definidos, não na ordem em que foram notificados. Planeje essa sequência.

Se um recarregamento precisar ocorrer antes de um reinício, defina-os nessa ordem na lista de manipuladores para que a fila seja processada corretamente.

Em uma função, os manipuladores ficam em handlers/main.yml. As tarefas da função os notificam pelo nome, exatamente como em um playbook comum.

Use nomes no formato de ações, como Reiniciar nginx ou Recarregar sshd. Nomes claros tornam a saída legível e deixam evidentes as linhas de notify.

Você alterou uma configuração e quer que o serviço em execução a recarregue sem interromper as conexões. Qual estado é melhor?

Agora você sabe definir manipuladores na seção handlers, escolher entre reiniciar e recarregar e contar com a execução na ordem de definição. 🎯