APRENDER. PRATICAR. EVOLUIR.Estrutura e momento de expansão
Uma equipa fictícia de middleware separa um playbook em ficheiros para reutilizar preparação, configuração e validação. Um ficheiro de tarefas contém tarefas; um playbook contém plays com seleção de hosts e outros atributos. import_tasks e include_tasks não recebem automaticamente qualquer documento YAML válido. import_tasks expande a lista estaticamente durante a análise do playbook; include_tasks carrega a lista quando a execução chega à inclusão. A escolha afeta a disponibilidade de variáveis, a inspeção e o momento de encontrar erros. Se o nome do ficheiro depende de um resultado registado por uma tarefa anterior, esse resultado existe em runtime e não deve ser tratado como uma entrada já conhecida na expansão estática. Uma divisão em mais ficheiros não fornece, por si só, isolamento ou transações.
Uma condição copiada pode mudar entre tarefas
No laboratório, rollout_enabled começa como true. O ficheiro reutilizado contém duas tarefas: a primeira define rollout_enabled=false; a segunda escreve um marcador sintético. Com when: rollout_enabled no import_tasks, a condição é aplicada às tarefas importadas e avaliada separadamente. A primeira corre, altera a variável e faz com que a segunda seja saltada. Com a mesma condição no include_tasks, a decisão permite carregar o ficheiro uma vez; não é copiada automaticamente para cada tarefa filha, pelo que o marcador é escrito. Nenhuma variante é universalmente melhor. Decide se a intenção é autorizar o conjunto com base no estado de entrada ou reavaliar um requisito antes de cada ação. Se a segurança de uma tarefa depende de uma condição atual, coloca essa condição no âmbito que a deve verificar.
Repetir uma lista sem perder a identidade
Para configurar dois componentes com duas portas cada, o ensaio usa um loop em include_tasks. A variável exterior chama-se component e a interior service_port. São produzidos quatro ficheiros distintos: alpha-8080, alpha-9090, beta-8080 e beta-9090. Os nomes conservam a associação entre componente e porta; usar item indistintamente nos dois níveis pode ocultar ou substituir o valor que a tarefa pretendia usar. import_tasks não suporta o mesmo loop diretamente e o ensaio confirma a rejeição. Repetir uma inclusão também não significa repetir até ficar saudável: include_tasks não suporta do-until. Para uma sonda, coloca a repetição suportada na tarefa que observa o estado e define uma condição de conclusão, limite e resultado de falha.
O que a análise consegue ver
O laboratório compara --list-tasks nas duas formas. O import mostra a tarefa filha de escrita; o include mostra a inclusão sem expandir a mesma lista de filhos. Assim, uma listagem curta pode representar trabalho ainda por carregar e não uma execução pequena. O caso do ficheiro ausente reforça esta diferença: syntax-check passa numa inclusão dinâmica que referencia not-present.yml, e a execução com a condição false salta a inclusão. Quando a condição passa a true, a execução falha ao tentar abrir o ficheiro. Um import do ficheiro ausente falha durante a análise mesmo com when:false. Uma condição de execução não corrige um artefacto estático inexistente. Conserva o resultado destes controlos, mas não descrevas syntax-check como prova de todos os ramos.
Aceitar a biblioteca de tarefas
Antes de promover o conjunto para RUN, regista a revisão dos ficheiros, a versão de Ansible, as variáveis exigidas e os ramos que foram executados. Pede previsões antes do ensaio: qual tarefa deve correr, qual deve ser saltada e que estado deve permanecer? Depois compara previsões, recap e artefactos. O ensaio desta aula correu duas vezes em core 2.16.14 numa máquina macOS, com um alias local e ficheiros temporários sintéticos. Não configura RHEL, não executa AAP e não testa serviços ou persistência após reboot. O curso AU294 publica uma base core 2.16, mas isso não fixa todas as variantes de inscrição EX294. Para transferir o exercício, repete os ramos relevantes no ambiente e nas versões autorizadas, acrescentando observação funcional do serviço real.
# Local fixture only; see the complete task files in the lab.
- hosts: lab
gather_facts: false
vars:
rollout_enabled: true
tasks:
- ansible.builtin.import_tasks: change-gate.yml
when: rollout_enabled
# The first child sets rollout_enabled=false.
# Predict whether the second child runs, then compare include_tasks.
Uma tarefa de preparação altera a flag usada na condição do import. A ativação seguinte é saltada; trocar para include muda a semântica e exige confirmar a intenção.
Armadilhas comuns
Import como include equivalente; condição false como proteção contra qualquer erro de parsing; item partilhado em loops aninhados; syntax-check como teste de todos os ramos.
Tópicos relacionados: Variáveis e facts · Tags e execução parcial
Escolhe conscientemente quando expandir o trabalho e quando voltar a avaliar a condição.
Referência: Reusing Ansible artifacts · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned