APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O inventário liga nomes lógicos aos sistemas que a automação pode gerir. Um host pode pertencer a vários grupos, por função, ambiente ou localização, sem se tornar várias máquinas independentes. O padrão do play escolhe um conjunto desse inventário; uma interseção difere de uma união. Para atuar apenas nos servidores da aplicação que pertencem a staging, usa uma seleção que expresse ambas as condições. Confirma o inventário fornecido, aliases e limites antes de alterar sistemas. Um endereço configurado em ansible_host não substitui necessariamente o alias usado na seleção. A lista efetiva de hosts é evidência mais útil do que a intenção escrita no nome do job.
Aplicação guiada
Num cenário fictício de APS, a pipeline tem o nome staging mas recebe também o inventário de produção. A equipa deve inspecionar a seleção antes de executar e corrigir a origem do âmbito. Faz o mesmo para variáveis: uma opção -u não vence automaticamente ansible_user vindo de uma fonte com precedência superior; extra vars podem sobrepor outras variáveis. Regista a origem do valor, sem divulgar segredos. Distingue Ansible community, ansible-core e collections, porque as versões não são intercambiáveis. A documentação consultada identifica community 14 e core 2.21; isso não prova a versão do executor. Confirma também plugins, Python e módulos necessários ao destino.
app:&staging seleciona a interseção; app:staging inclui membros de qualquer um dos grupos.
Armadilhas comuns
Nome do job como prova de âmbito; IP como alias universal; versão da collection como versão do core.
Tópicos relacionados: Tarefas e estado pretendido · Validação e handlers · Orquestração por lotes
Antes da alteração, confirma seleção, origem das variáveis e compatibilidade do executor.
Referência: How to build your inventory · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation