Loops e evidência por item | Ansible: automatizar alterações e recuperar serviços

Começar pelo contrato de entrada

Uma lista de nomes não define, por si só, uma alteração segura. Especifica os campos de cada serviço, os tipos aceites e o significado de enabled antes de construir o loop. Uma string com vírgulas não equivale necessariamente a uma lista de ficheiros; query ou lookup com wantlist=True permite obter listas quando o plugin oferece esse resultado. Valida também duplicados e valores inesperados. Num exemplo fictício de fundos, duas entradas para o mesmo serviço podem repetir uma ação com efeitos persistentes. O objetivo desta validação é explicar o conjunto que será processado e as condições que excluem cada elemento.

Ler o agregado e depois cada resultado

Register num loop produz uma estrutura com results para as iterações. O changed agregado pode ser verdadeiro porque apenas um item declarou alteração. Um failed agregado pode indicar falha em algum item; skipped agregado representa todos os itens ignorados. Não uses estes resumos para atribuir o mesmo estado a todos os serviços. Percorre os resultados preservando o nome ou identificador e verifica quais os campos realmente presentes. Um comando executado pode ter rc, enquanto um item ignorado pode não ter esse campo. A aceitação deve distinguir alteração, ausência de alteração, falha e ausência de execução, segundo o contrato do serviço.

Condições e identidade em loops internos

When é avaliado para cada item do loop. Se enabled chegar como texto, confirma o contrato e converte explicitamente quando adequado, em vez de depender de coerções implícitas. Não acrescentes delimitadores Jinja a uma condição que já é uma expressão. Um include_tasks que percorre serviços pode executar um segundo loop sobre portas; usa loop_var diferentes, por exemplo service e port, para conservar as duas identidades. Sem essa distinção, uma condição ou mensagem pode referir a porta quando o operador pensa estar a observar o serviço. Revê o contexto das expressões antes de atribuir o problema à concorrência entre hosts.

Resultados ignorados e tentativas

Uma tarefa ignorada devido a when ainda cria o resultado registado. Para saber se executou, consulta o estado de skip em vez de procurar apenas uma variável indefinida. Quando combinas loop com until, as tentativas aplicam-se a cada item; não equivalem a uma transação que repete o conjunto inteiro. Se a ação tiver efeitos, documenta o que uma nova tentativa pode repetir. Para módulos que aceitam diretamente uma lista de pacotes, avalia essa interface antes de criar uma chamada por pacote. A escolha depende da semântica do módulo, da necessidade de resultados por elemento e das restrições do recurso partilhado.

Oficina: três serviços sem infraestrutura externa

O laboratório deste percurso usa três serviços fictícios em localhost: alpha elegível, beta excluído e gamma elegível. Uma tarefa debug declara alteração apenas para alpha, para tornar o agregado observável sem alterar serviços reais. As asserções verificam três resultados, a identidade de cada item, beta ignorado e changed agregado verdadeiro. Outra tarefa ignorada confirma que o resultado registado continua definido. Executa este laboratório num ambiente temporário com a versão documentada e compara as observações. A declaração de changed é deliberadamente artificial neste exercício: demonstra o mecanismo de resultados, sem provar uma alteração funcional em qualquer aplicação.

Resumo e passagem de evidência

Prepara uma matriz com serviço esperado, condição aplicada, ação observada e decisão de aceitação. Identifica os elementos que ficaram fora da execução e se essa exclusão foi autorizada. Usa loop_control.label para melhorar a leitura, mas não o apresentes como proteção de tokens ou passwords; dados sensíveis precisam de tratamento adequado, incluindo no_log onde aplicável e controlo de saídas posteriores. Entrega uma síntese sanitizada ao colega seguinte, com os identificadores que permitem investigar diferenças. Relaciona este trabalho com inventário, proteção de segredos e recuperação: antes de repetir a execução, distingue um serviço inalterado de um serviço nunca processado.

# Local fixture: inspect per-item results, not real service health.
loop: "{{ services }}"
loop_control:
  loop_var: service
  label: "{{ service.name }}"
when: service.enabled
register: service_results
# service_results.results retains each item and its own state.

NA PRÁTICA

Três serviços produzem um resultado alterado, um inalterado e um ignorado. changed=true no resumo identifica uma alteração em pelo menos um item, sem provar cobertura de todos.

Armadilhas comuns

Tratar changed agregado como sucesso global; ler rc no nível errado; reutilizar item em loops internos; usar label como proteção de segredos.

Tópicos relacionados: Inventário e contexto de execução · Orquestração por lotes · Falhas e recuperação

Leva esta ideia contigo

A unidade de aceitação é o serviço esperado. Conserva a sua identidade, distingue os estados e explica qualquer diferença entre âmbito previsto e observado.

Criar conta

Referência: Loops · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation