APRENDER. PRATICAR. EVOLUIR.Uma vez em cada lote
O inventário sintético contém cinco aliases com ligação local, usando estratégia linear e serial=2. A tarefa run_once produz três artefactos: batch-alpha para alpha e beta, batch-gamma para gamma e delta, e batch-epsilon para epsilon. A evidência confirma uma execução por lote neste play. Não demonstra execução única entre pipelines nem em toda a vida de uma aplicação. Antes de colocar uma migração numa tarefa dessas, identifica se o requisito é por host, por lote, por execução ou persistente. Cada requisito exige um desenho e uma evidência diferentes.
Seleção de host não é histórico persistente
Uma condição baseada em inventory_hostname == ansible_play_hosts_all[0] produz apenas single-alpha no ensaio. A documentação apresenta esta distinção relativamente ao comportamento de run_once com serial. Ainda assim, outra execução ou outro --limit pode selecionar um primeiro host diferente e repetir a operação. Para uma migração que não admite duplicação, considera o histórico e os controlos próprios da operação, incluindo concorrência e recuperação de resultado incerto. A ordem compilada do inventário também não deve ser reduzida à primeira linha de um ficheiro. Regista a seleção efetiva da execução.
Delegar execução e atribuir dados
No laboratório, alpha executa set_fact com delegate_to: beta. Sem delegate_facts, o marcador pertence a alpha. Com delegate_facts: true, o segundo marcador pertence a beta. A posição da tarefa no output não basta para concluir a quem pertence o dado. Para uma verificação delegada, distingue o host original, o destino da operação e a identidade observada. Consulta hostvars do dono correto e revê quais variáveis alimentam os parâmetros. O ensaio usa atribuições locais, não recolha de facts através de SSH nem verificações de saúde em servidores remotos.
Clear_facts e a variável que permanece
A tarefa set_fact com cacheable=true cria representações com precedências diferentes. Antes de clear_facts, o laboratório observa lab_marker também em ansible_facts. Depois, essa representação desaparece, mas a variável de host continua a resolver para retained-host-variable. Não foi configurado um backend externo ou persistente de cache. O resultado não exige esse mecanismo e não prova persistência entre processos. Se um gate depende de readiness guardada anteriormente, ler a variável não volta a executar a verificação original. Obtém uma observação atual quando o critério de progressão exige atualidade.
Paralelismo e âmbito da progressão
Delegar várias tarefas para o mesmo destino não serializa automaticamente escritas concorrentes nesse destino. Revê concorrência, nomes de artefactos e a operação efetiva antes de presumir segurança. Da mesma forma, serial limita o conjunto de hosts tratado por lote, mas não drena tráfego nem confirma capacidade remanescente. O laboratório tem cinco aliases na mesma máquina; não são cinco servidores independentes. Uma mudança real precisa dos controlos específicos de tráfego, capacidade, saúde e recuperação. O valor de serial participa no plano, mas não demonstra sozinho disponibilidade durante a mudança.
Oficina de gate com identidade e tempo
No caso fictício, um valor destinado a representar beta fica atribuído a alpha e é usado como prontidão atual deste último. Suspende a progressão e reconstrói origem, dono, instante e critério da observação. Corrige a estrutura para que cada resultado preserve a identidade correspondente. Copiar true para ambos os hosts apenas espalha a afirmação sem obter evidência. Na passagem de turno, regista também a seleção de hosts e os lotes concluídos. Em inglês: “The stored value does not establish current readiness for this target.” Define quem recolhe a observação em falta.
Com cinco aliases e serial=2, run_once gerou três marcadores de lote. Após clear_facts, ansible_facts perdeu lab_marker, mas a variável de host continuou disponível na mesma execução.
Armadilhas comuns
Interpretar run_once como lock global; assumir que delegate_to serializa tarefas; confundir alias com máquina; usar um fact retido como observação atual; esperar persistência apenas por cacheable=true.
Tópicos relacionados: Tarefas e estado pretendido · Orquestração por lotes · Falhas e recuperação
Associa cada execução e cada dado ao seu âmbito. Lote, host, processo e histórico persistente são dimensões diferentes que precisam de evidência própria.
Referência: Controlling playbook execution: strategies and more · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation