Introdução
A automação só é segura quando alcança os hosts pretendidos. Dois aliases para uma mesma máquina, um host ausente ou uma seleção ampla demais podem tornar enganoso um comando bem-sucedido.
Neste laboratório, você organizará dois destinos SSH distintos em grupos canary e stable, inspecionará um grupo pai, visualizará previamente padrões de hosts e criará um marcador apenas no canary. O Ansible e as conexões de treinamento já estão preparados; você trabalhará com o inventário e o escopo dos comandos.
Organizar hosts em grupos
Nesta etapa, você agrupará os dois hosts SSH existentes sem duplicar suas identidades nem seus endereços.
Abra o Terminal e entre no projeto:
cd /home/labex/project
Leia o inventário fornecido antes de editá-lo:
cat inventory.ini
Ele define web1 e web2 com valores diferentes de ansible_host. Mantenha essas linhas e as configurações de conexão em [all:vars]. Os nomes do inventário identificam os hosts; colocar o mesmo nome em vários grupos não cria outro servidor.
Um grupo descreve um conjunto de hosts. Usaremos canary para o primeiro host, stable para o segundo e webservers como um grupo pai contendo os dois grupos. Acrescente estas seções. >> preserva o arquivo existente, e o marcador de here-document entre aspas mantém literal o texto colado:
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] e [stable] contêm nomes de hosts. Uma seção que termina em :children contém nomes de grupos, portanto webservers herda os hosts pertencentes a canary e stable. Não coloque novos endereços de destino nesses grupos.
ansible-inventory --graph desenha a composição resolvida:
ansible-inventory --graph
Espere ver web1 em canary e web2 em stable, com os dois grupos sob webservers. As entradas especiais all e ungrouped também podem aparecer. Um host pode aparecer em mais de um ramo do gráfico e continuar sendo um único host no inventário.
Um padrão de hosts seleciona os destinos de um comando. Visualize previamente o grupo pai sem executar um módulo:
ansible webservers --list-hosts
Espere ver exatamente web1 e web2. Em um padrão, :& significa interseção: escolher hosts pertencentes às duas partes. Use aspas para que o shell não interprete &:
ansible 'webservers:&canary' --list-hosts
Espere ver apenas web1. Essa visualização permite detectar um erro de seleção antes de alterar qualquer host.
Limitar uma alteração ao canary
Nesta etapa, você fará uma pequena alteração no canary, preservando o host stable e o controlador.
O primeiro padrão de um comando seleciona um conjunto inicial. --limit o restringe ainda mais; não acrescenta hosts fora desse conjunto. Visualize previamente uma seleção limitada antes de usá-la:
ansible webservers --limit canary --list-hosts
Espere ver um host, web1. Um limite que não corresponda a nenhum host não demonstraria uma alteração bem-sucedida, mesmo que o comando terminasse sem falha de módulo.
Use o módulo command do laboratório anterior para executar touch. Esse comando Linux cria um arquivo vazio quando ele não existe e atualiza seu carimbo de data e hora quando existe. O marcador deve ficar no diretório pessoal do usuário automation gerenciado. O valor de -a entre aspas mantém o executável e o caminho juntos:
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
Espere um resultado de comando bem-sucedido apenas para web1. Essa ação é deliberadamente um exercício simples de escopo; touch pode atualizar carimbos de data e hora em execuções repetidas, portanto seu status CHANGED não é uma demonstração de idempotência.
Inspecione os arquivos visíveis no diretório pessoal de cada usuário gerenciado. ls lista o diretório em cada destino porque é executado pelo módulo command do Ansible:
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
O resultado de web1 deve conter canary-ready. O resultado de web2 não deve conter esse nome; seu stdout pode estar vazio. Esses são diretórios remotos, separados do espaço de trabalho do controlador.
Por fim, inspecione o diretório atual do controlador:
ls
Ele deve mostrar a configuração e o inventário do projeto, sem um marcador canary-ready local. Você selecionou um host gerenciado real em vez de fazer uma alteração no controlador. Laboratórios futuros usarão módulos que declaram diretamente o estado de arquivos e depois verificarão a idempotência.
Resumo
Você preservou duas identidades distintas no inventário, organizou hosts e grupos filhos, visualizou previamente um padrão de interseção entre aspas e restringiu um comando com --limit. O estado real dos destinos mostrou o marcador apenas no canary, enquanto o host stable e o controlador ficaram fora da alteração.
