Conceito e mecanismo
Um resumo de execução precisa de ser lido por host e tarefa. Failed e unreachable representam problemas diferentes: uma tarefa pode ter executado e devolvido falha, ou o executor pode não ter conseguido contactar o destino. ignore_errors não cobre indiscriminadamente erros de ligação, variáveis indefinidas ou sintaxe inválida. Define failed_when com atenção à lógica: uma lista de condições usa AND implícito; quando basta uma condição, exprime OR. Um erro pode ocorrer depois de outras tarefas terem alterado ficheiros. A falha global não demonstra ausência de efeitos e a execução seguinte deve partir do estado real observado.
Aplicação guiada
Blocks permitem organizar rescue e always, mas não são uma transação que desfaz automaticamente alterações. Hosts unreachable e definições inválidas não acionam essas secções como uma tarefa com estado failed. Um rescue bem-sucedido altera a continuação e o tratamento de limiares; valida que recuperou a função, não apenas que terminou. Num caso fictício, um template notificou reinício, mas outra tarefa falhou antes do handler. O ficheiro novo pode coexistir com o processo antigo. force_handlers permite tratar algumas falhas, mas não torna um host inacessível contactável. Decide recuperação com o estado do ficheiro, serviço, conectividade e dados, e entrega ao RUN a evidência de funcionamento e as limitações restantes.
Ficheiro alterado e handler não executado exigem conciliar configuração em disco com o processo ativo.
Armadilhas comuns
Rescue como rollback automático; always sem exceções; ignorar unreachable; sucesso do comando como recuperação funcional.
Tópicos relacionados: Inventário e contexto de execução · Tarefas e estado pretendido · Validação e handlers
Recupera a função com evidência do estado parcial e do âmbito afetado.
Referência: Error handling in playbooks · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation