Comandos ad-hoc do Ansible e modo de verificação para uma primeira execução segura em uma frota de hosts

Objetivo

Confirmar que o Ansible consegue alcançar um conjunto de hosts gerenciados e, em seguida, visualizar uma mudança nesses hosts antes de aplicá-la de fato, usando apenas comandos ad-hoc e o modo de verificação (check mode), sem precisar de playbook para a pré-visualização.

Pré-requisitos

Ansible instalado no nó de controle; um arquivo de inventário com os hosts e grupos de destino; acesso funcional por SSH (ou WinRM, no caso de alvos Windows) e, para mudanças que exigem privilégios, um método de become como sudo configurado para o usuário de conexão.

Passos

1. Confirme a conectividade e a presença do Python em todos os nós gerenciados: ansible all -m ping. all é o grupo interno do Ansible que abrange todos os hosts do inventário; um host saudável responde com um resultado pong (hosts Windows usam ansible.windows.win_ping). A sintaxe dos comandos ad-hoc está documentada, de forma geral, como ansible [pattern] -m [module] -a "[module options]", em que o padrão (pattern) seleciona os hosts e -m seleciona o módulo a executar.
2. Restrinja a um subconjunto antes de tentar algo mais arriscado: ansible webservers --limit "*.example.com" -m ping, ou use o nome de um único host. --limit restringe ainda mais um padrão já correspondido, o que é mais seguro do que editar o inventário para testar com menos hosts.
3. Visualize uma mudança real sem aplicá-la: ansible webservers -b -m ansible.builtin.service -a "name=cron state=started" --check. Sem -b, a pré-visualização roda sem privilégios e pode diferir da execução real. A documentação do Ansible afirma que "In check mode, Ansible runs without making any changes on remote systems" (no modo de verificação, o Ansible roda sem fazer nenhuma alteração nos sistemas remotos); os módulos que suportam esse modo informam as mudanças que fariam, em vez de realizá-las, e os módulos sem suporte a check mode "report nothing and do nothing" (não informam nada e não fazem nada).
4. Adicione --diff junto com --check para ver o conteúdo antes e depois nos módulos que o suportam (principalmente os que manipulam arquivos). A documentação avisa que o modo diff "produces a large amount of output" (gera uma grande quantidade de saída) e sugere processar um host por vez (--limit host1); além disso, os diffs podem exibir segredos presentes em arquivos.
5. Em qualquer comando que exija privilégios elevados no alvo, adicione --become (-b): a própria documentação do Ansible descreve o become como o uso de "existing privilege escalation systems to execute tasks with root privileges or with another user's permissions" (sistemas de elevação de privilégio existentes para executar tarefas com privilégios de root ou com as permissões de outro usuário), apoiado em ferramentas como sudo, su ou doas, conforme o que estiver configurado para aquele host.
6. Somente depois que a pré-visualização em check mode parecer correta, execute o mesmo comando novamente sem --check para aplicá-lo, de preferência ainda restrito com --limit, primeiro a um pequeno grupo canário.

Resultado esperado

ansible all -m ping retorna um pong de cada host alcançável; a execução com --check --diff mostra a mudança exata que um módulo faria, sem que nenhuma modificação ocorra; e a execução real posterior corresponde ao que a pré-visualização mostrou.

Limites e base de verificação

O modo de verificação "is just a simulation" (é apenas uma simulação): em playbooks, tarefas com condicionais baseadas em resultados registrados de tarefas anteriores não produzem uma saída significativa. O módulo ad-hoc padrão, command, não consegue prever um comando arbitrário e é ignorado sob --check. Um módulo sem suporte a check mode não faz nada sob --check, o que pode parecer "nada precisava mudar"; antes de confiar em uma pré-visualização limpa, verifique o atributo de suporte check_mode na documentação do módulo. Os próprios comandos ad-hoc não são artefatos idempotentes de rastreamento: nada registra que determinado comando ad-hoc foi executado, exceto o histórico do shell e qualquer log que o nó de controle esteja configurado para manter.