APRENDER. PRATICAR. EVOLUIR.Notificação, flush e nova execução
O ensaio força changed em duas tarefas debug para produzir notificações controladas. O handler corre uma vez no flush explícito. Uma terceira notificação posterior permite outra execução no final do play. Os eventos mostram duas execuções do handler, com changed=true e depois changed=false, porque lineinfile conserva uma única linha activated. Este resultado distingue execução de efeito adicional. Não houve reload de um serviço real. Num playbook de produção, revê quando as notificações surgem e em que pontos são consumidas, em vez de contar mensagens changed como ativações independentes.
Uma falha pode deixar um candidato no disco
O segundo ensaio copia um candidato, notifica um handler e falha deliberadamente numa tarefa seguinte. Sem force_handlers, o candidato existe e o marcador de ativação não é criado. O processo termina com código dois. Isto representa estado parcial: houve uma escrita antes da falha. O recap ajuda a localizar tarefas, mas a decisão de recuperação precisa do estado por alvo. Em middleware, um ficheiro novo e um processo ainda na geração anterior podem coexistir. Regista essa diferença antes de repetir, limpar ou declarar a mudança concluída.
Force_handlers não valida o candidato
Com force_handlers=true, o mesmo ensaio cria o marcador de ativação apesar da falha posterior à notificação; o processo continua a terminar com código dois. O controlo altera o tratamento dos handlers notificados, não corrige o candidato nem transforma a execução em sucesso. A documentação também alerta que condições como um host inacessível podem impedir a execução. Para uma configuração real, posiciona validação, publicação e notificação na ordem adequada. Um gate colocado depois de uma notificação pode ser insuficiente se a ativação continuar elegível após essa falha.
Rescue trata o fluxo, não desfaz efeitos
O bloco original escreve candidate.cfg e falha deliberadamente. O rescue guarda apenas o nome da tarefa falhada, enquanto always escreve observações. A execução termina com zero, o recap indica uma falha resgatada e o candidato permanece. O exemplo demonstra tratamento de fluxo, sem tarefas de reposição. Não atribuas significado de rollback ao nome rescue. Se a recuperação exige restaurar configuração, dados ou tráfego, essas ações e a sua validação precisam de existir. Preserva a falha original e distingue-a de erros que possam surgir durante a própria recuperação.
Definir o que significa aceitar a mudança
Aceitação precisa de ligar a intenção ao resultado observável: candidato validado, publicação no alvo, geração ativa e percurso do consumidor. Não basta um código zero, um ficheiro presente ou um handler executado. Define também o resultado quando a observação falta, em vez de o converter em sucesso. No laboratório, os hashes identificam os artefactos usados e o executor está fixado em ansible-core 2.21.4. Essa rastreabilidade permite repetir a experiência delimitada; não representa certificação do fornecedor nem validação independente de um ambiente de produção.
Oficina de passagem de estado parcial
No caso final, dois hosts ativaram B, um recebeu apenas o ficheiro B e dois continuam em A. O consumidor não foi validado e a janela está a terminar. Entrega uma tabela por host com geração em disco, geração ativa, tarefa falhada, evidência e ação pendente. Define responsáveis e a próxima decisão autorizada, incluindo recuperação ou nova janela quando necessário. Em inglês: “The rollout is partial; consumer acceptance remains outstanding.” A contagem de handlers não substitui essa passagem. O objetivo é permitir continuidade sem obrigar o turno seguinte a reconstruir o estado a partir de um resumo ambíguo.
Duas notificações antes do flush: uma execução. Nova notificação depois: segunda execução. Rescue bem-sucedido: saída zero com candidate.cfg ainda alterado. São observações locais, sem reload real.
Armadilhas comuns
Contar changed como ativações; assumir execução incondicional de handlers forçados; chamar rollback a qualquer rescue; encerrar com código zero sem observar estado; omitir a falha original.
Tópicos relacionados: Tarefas e estado pretendido · Orquestração por lotes · Falhas e recuperação
Controla a ordem de validação e ativação. Reconstrói efeitos por alvo e só afirma recuperação ou aceitação quando a evidência corresponde ao resultado pretendido.
Referência: Blocks · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation