APRENDER. PRATICAR. EVOLUIR.Quatro estados que não se substituem
Uma ação longa tem pelo menos quatro perguntas diferentes: foi lançada, terminou, terminou com o resultado esperado e deixou a aplicação pronta? Com async e poll: 0, o controlador pode avançar depois do lançamento sem responder às restantes perguntas. Conserva ansible_job_id e o contexto de execução para acompanhar essa operação. Um changed no lançamento não mede sucesso final. Para um comando cujo contrato exige rc=0, examina o resultado terminal e o código de saída. Depois verifica a função relevante da aplicação. Estes critérios devem constar da alteração antes da janela operacional, para evitar inventar aceitação enquanto o serviço está indisponível.
Escolher espera e proteger dependências
Com poll positivo, a execução acompanha a tarefa até obter um resultado ou atingir o limite assíncrono. O intervalo de poll não é a duração garantida do trabalho; async define o limite permitido para essa ação. Com poll zero, podes lançar trabalho e acompanhar explicitamente mais tarde, mas tens de desenhar as dependências. Dois passos que usam um gestor de pacotes com lock exclusivo não devem sobrepor-se apenas porque o controlador recebeu um identificador. Aumentar forks ou mudar labels não liberta o lock. Coloca uma barreira de conclusão antes do passo dependente e define o que acontece se o acompanhamento falhar.
Perda de observação e limpeza
Se perderes ligação ou não encontrares a cache, não concluas que a operação nunca executou. O processo pode ter produzido efeitos que sobrevivem ao controlador. Recolhe o identificador original, o utilizador e o contexto corretos, e reconcilia o estado persistente antes de relançar. Async_status mode: cleanup remove a cache de acompanhamento; não é um pedido de cancelamento nem uma reversão de efeitos. Na implementação de ansible-core 2.21.4 inspecionada, a limpeza elimina o ficheiro sem esperar pelo processo. Depois de uma conclusão validada, a limpeza limitada a esse identificador pode ser apropriada. Conserva primeiro a evidência necessária para diagnóstico e auditoria.
HTTP aceite e contrato de prontidão
Uma verificação com ansible.builtin.uri tem de distinguir status HTTP aceite do significado do documento recebido. Se o endpoint documenta ready, uma resposta 200 com ready=false ainda não confirma prontidão. Com Content-Type application/json, o resultado json é disponibilizado independentemente de return_content; esse parâmetro controla outro aspeto da devolução do corpo. Define condições para a estrutura esperada e um limite de espera coerente com a janela. Confirma também a identidade e geração da aplicação quando isso fizer parte do contrato local. Não transformes exemplos fictícios em requisitos universais: cada aplicação define os sinais que demonstram capacidade para servir pedidos.
Oficina isolada e limites de simulação
O laboratório lança apenas um processo Python local que espera um segundo e escreve fixture-complete. Consulta o mesmo identificador até à conclusão, verifica rc=0 e a saída e limpa a cache concluída. Uma segunda parte inicia um servidor HTTP temporário em 127.0.0.1 que devolve JSON com ready=false. A asserção confirma HTTP 200 e a falta de prontidão, sem contactar serviços externos. Estes quatro factos são observações de laboratório, não garantias de produção. URI não suporta check mode na documentação consultada; uma tarefa ignorada num ensaio não testou o endpoint. Verificações reais precisam de âmbito explícito e efeitos compreendidos.
Resumo para a janela de alteração
Escreve o fluxo de decisão antes da execução: lançar, acompanhar, validar o comando, observar a função e só depois aceitar ou avançar. Para cada transição, indica a evidência, o prazo e o responsável. Se houver falha parcial, conserva o estado conhecido e a incerteza, em vez de repetir automaticamente uma ação com efeitos persistentes. Define cancelamento e reversão através de mecanismos próprios da operação; não uses limpeza de cache como substituto. Na passagem de turno, transmite o identificador original e os critérios ainda não satisfeitos. Relaciona esta aula com serial, recuperação e observabilidade, porque uma execução tecnicamente concluída pode continuar a exigir investigação funcional.
# Conceptual sequence; the runnable fixture is in content/labs/ansible-execution.
# launch: async: 20, poll: 0, register: launched
# observe: async_status jid=launched.ansible_job_id
# wait until finished, then inspect failure and rc
# validate application readiness separately
# retain evidence, then clean this completed job's cacheUm job pode devolver um identificador imediatamente e continuar ativo. Um endpoint pode devolver 200 com ready=false. Nenhuma destas respostas, isoladamente, aceita a alteração.
Armadilhas comuns
Confundir poll zero com conclusão; repetir uma migração sem reconciliar efeitos; limpar cache como cancelamento; tratar HTTP 200 como prontidão.
Tópicos relacionados: Inventário e contexto de execução · Orquestração por lotes · Falhas e recuperação
Um identificador inicia o acompanhamento. A aceitação exige resultado terminal correto e uma observação funcional adequada ao serviço.
Referência: Asynchronous actions and polling · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation