Introdução
Vários comandos pontuais relacionados ficam mais fáceis de repetir e revisar quando armazenados em um playbook. Um playbook útil descreve um estado desejado estável e produz resultados observáveis em todos os destinos pretendidos.
Você escreverá um pequeno playbook YAML usando os módulos file e copy, o aplicará a dois nós SSH e verificará tanto os arquivos criados quanto uma execução repetida sem alterações. Este laboratório apresenta plays, tarefas e idempotência sem variáveis, loops ou roles.
Escrever um playbook em YAML
Nesta etapa, você combinará os módulos file e copy já praticados em um playbook reutilizável.
Entre no projeto pelo Terminal:
cd /home/labex/project
Um playbook é uma lista YAML de plays. Cada play associa um padrão de hosts a uma lista ordenada de tarefas. Cada tarefa nomeia um módulo e seus argumentos. Os rótulos name ajudam as pessoas a ler a saída; eles não criam configurações por si só.
O YAML usa indentação para aninhar dados. Use espaços, não tabulações. Um - inicial começa um item de lista, e dois-pontos introduzem o valor de uma chave. Aqui, tasks contém duas tarefas de módulos. Modos entre aspas como "0750" permanecem strings de permissão. gather_facts: false pula a coleta automática de fatos porque estas tarefas de estado fixo não usam fatos.
Crie o arquivo com um here-document entre aspas, conforme praticado anteriormente. Copie até a linha EOF final:
cat > workspace.yml <<'EOF'
- name: Prepare managed workspaces
hosts: all
gather_facts: false
tasks:
- name: Create the workspace directory
ansible.builtin.file:
path: /home/automation/workspace
state: directory
mode: "0750"
- name: Write the workspace notice
ansible.builtin.copy:
dest: /home/automation/workspace/README.txt
content: "Workspace managed by Ansible\n"
mode: "0640"
EOF
A primeira tarefa declara um diretório. A segunda usa o argumento content de copy para fornecer texto literal diretamente, em vez de ler um arquivo src no controlador. A string YAML entre aspas duplas interpreta \n como uma quebra de linha final. O conteúdo fixo torna estável uma execução repetida; não acrescente um carimbo de data e hora variável.
O play usa hosts: all, ou seja, os dois nós SSH fornecidos. As tarefas comuns executam como automation, portanto seu diretório pessoal é gravável sem become.
ansible-playbook executa arquivos de playbook. Primeiro use --syntax-check para validar a estrutura sem aplicar tarefas:
ansible-playbook workspace.yml --syntax-check
Espere uma linha de identificação do playbook e nenhum erro de análise. A validação de sintaxe, por si só, não comprova a conectividade remota nem a correção dos arquivos finais.
Visualize previamente a seleção de hosts do play usando --list-hosts:
ansible-playbook workspace.yml --list-hosts
O play deve listar web1 e web2. Uma lista vazia não é um playbook utilizável para dois hosts.
Aplicar o estado desejado
Nesta etapa, você executará o playbook e inspecionará seus resultados remotos reais.
Execute o arquivo a partir do projeto para que sua configuração e seu inventário sejam selecionados:
ansible-playbook workspace.yml
O Ansible imprime cada nome de play e tarefa e, em seguida, um PLAY RECAP. Em um ambiente novo, as duas tarefas devem alterar cada host:
web1 : ok=2 changed=2 unreachable=0 failed=0 ...
web2 : ok=2 changed=2 unreachable=0 failed=0 ...
O espaçamento e a ordem dos hosts podem variar. ok conta as tarefas bem-sucedidas, changed conta as tarefas que precisaram de alterações e unreachable/failed devem ser zero. Um nome de tarefa bem-sucedida, por si só, não comprova os bytes nem as permissões exigidos dos arquivos.
Leia cada aviso remoto usando o módulo command ad hoc:
ansible all -m ansible.builtin.command -a 'cat /home/automation/workspace/README.txt'
Os dois valores de stdout devem mostrar Workspace managed by Ansible. A consulta command somente leitura ainda pode informar CHANGED; os resultados de file/copy do playbook descrevem o estado declarado. O diretório gerenciado tem modo 0750, o aviso tem modo 0640 e ambos pertencem a automation.
Verificar a convergência idempotente
Nesta etapa, você repetirá o playbook e confirmará que o estado correspondente não exige alterações extras.
Idempotência significa que aplicar repetidamente o mesmo estado desejado não produz alterações desnecessárias após a convergência. Execute o mesmo playbook novamente:
ansible-playbook workspace.yml
Espere um resumo para cada destino com ok=2, changed=0, unreachable=0 e failed=0. Os dois arquivos permanecem presentes e corretos. Um carimbo de data e hora variável ou um comando genérico incondicional prejudicaria esse resultado estável.
--check solicita uma previsão: os módulos compatíveis preveem alterações sem aplicá-las. Tanto file quanto copy suportam esse fluxo. Visualize a previsão do playbook convergido:
ansible-playbook workspace.yml --check
Espere novamente zero alterações nos dois hosts. Uma previsão não substitui a primeira execução real nem a inspeção do estado real. Aqui, ela confirma que os espaços de trabalho já criados correspondem às declarações.
Guarde o playbook para reutilização futura. Não suprima alterações com changed_when nem force tarefas a sair do modo check para fabricar um resumo sem alterações; o resultado deve refletir a correspondência real do estado.
Resumo
Você expressou a seleção de hosts e tarefas ordenadas de módulos em YAML, verificou a sintaxe e o escopo dos destinos e aplicou o playbook a dois nós gerenciados reais. O estado real dos arquivos correspondeu aos requisitos, uma segunda execução real não fez alterações extras e o modo check somente leitura não encontrou alterações pendentes.
