Por baixo do capô do Ansible: do inventário estático aos desafios de SSH, syscalls e escalonamento

Gerenciar infraestrutura como código parece algo simples nos exemplos básicos de tutoriais: você lista alguns endereços IP em um arquivo de texto, roda um comando e a automação acontece.

No entanto, no momento em que você precisa adicionar servidores reais em escala ou operar em redes heterogêneas, os detalhes de baixo nível do sistema operacional e da camada de rede cobram seu preço.

Recentemente, revisei a arquitetura de conexão e inventário do Ansible para entender exatamente onde os gargalos e as falhas operacionais acontecem.

Abaixo, compartilho o fluxo interno do engine, o comportamento do OpenSSH no kernel, armadilhas clássicas de escalonamento de privilégios (become) e o roteiro prático para debugar conexões problemáticas.

1. Estruturando o inventário: além de um arquivo de texto#

A porta de entrada do Ansible é o Inventory. No dia a dia, tanto o formato INI quanto o YAML são amplamente utilizados. O formato INI continua sendo muito prático pela concisão:

[webservers]
web01.seusite.com.br ansible_host=192.168.10.11 ansible_user=deploy
web02.seusite.com.br

[dbservers]
db01.seusite.com.br

[production:children]
webservers
dbservers

O que o engine do Ansible faz na inicialização?#

Ao disparar o comando ansible-playbook, o engine executa três etapas antes de transmitir qualquer payload:

1. Parsing: Lê o arquivo de inventário e resolve a árvore de dependências entre grupos e nós (children).
2. Host Pattern Matching: Cruza os padrões definidos no playbook com os hosts ativos na memória.
3. Variable Merging: Consolida as variáveis declaradas inline com aquelas definidas nos diretórios group_vars/ e host_vars/.

Em infraestruturas dinâmicas em nuvem, o inventário estático se torna obsoleto rapidamente. Nesses cenários, a abordagem recomendada é o Dynamic Inventory (scripts ou plugins executáveis). O Ansible invoca o script passando o parâmetro --list, faz o parse do JSON emitido no STDOUT diretamente para a memória e popula os alvos sob demanda.

2. O mecanismo de conexão: multiplexação SSH e syscalls#

Por ser agentless (sem agentes instalados nos alvos), toda a sobrecarga de comunicação do Ansible recai sobre o plugin de conexão SSH.

Se o recurso de ControlPersist / ControlMaster não estiver ativo no nó de controle, cada tarefa do seu playbook abrirá uma nova conexão TCP, refazendo o handshake de três vias (3-way handshake) e renegociando chaves criptográficas (Diffie-Hellman). No nível do kernel, isso gera centenas de chamadas de sistema (syscalls) repetidas de socket() e connect().

[Control Node] ──(Socket Persistente em ~/.ansible/cp/)──► [Servidor Alvo]
       │
       ├─► 1. Envia módulo Python compactado via SFTP para /tmp/ansible_remote_tmp
       ├─► 2. Aplica permissão chmod +x no arquivo temporário
       └─► 3. Dispara chamada execve() chamando /usr/bin/python3

Com o multiplexing habilitado:

• O Ansible reaproveita sockets persistentes no nó de controle (em ~/.ansible/cp/).
• O payload (o módulo empacotado em Python) é comprimido e enviado via SFTP direto para o diretório configurado em ansible_remote_tmp.
• No servidor remoto, o sistema executa um chmod +x e faz a chamada execve() invocando o interpretador Python para executar a tarefa.

3. Diagnóstico cirúrgico de conexões#

Quando um nó novo é adicionado e não responde aos comandos, evite tentativas às cegas e siga este roteiro de depuração:

# 1. Testar o handshake SSH e a execucao do Python com verbosidade maxima
ansible webservers -m ping -vvv

# 2. Inspecionar exatamente quais variaveis e hosts foram carregados pelo parser
ansible-inventory --host web01.seusite.com.br

Erros recorrentes e causas raiz:#

• Permission Denied (Publickey): Não basta a chave pública estar cadastrada no servidor. O daemon SSH recusa a autenticação silenciosamente se as permissões estiverem muito abertas. O padrão exigido é permissão 700 no diretório ~/.ssh e 600 no arquivo authorized_keys.
• Interpretador Python Não Encontrado: Em distribuições Linux recentes, o binário /usr/bin/python não existe por padrão, estando presente apenas o /usr/bin/python3. Para garantir compatibilidade, defina no inventário:

ansible_python_interpreter=/usr/bin/python3

• Fragmentação de Pacotes em Túneis (MTU/MSS): Ao acessar servidores remotos via VPNs ou túneis GRE, pacotes volumosos contendo o código serializado do módulo Python podem sofrer descarte silencioso de fragmentos. Verifique as interfaces com ip link para diagnosticar incompatibilidades de MTU.

4. Casos de borda: host key checking e escalonamento (become)#

Dois obstáculos operacionais são muito comuns em ambientes corporativos:

A. Travamento no fingerprint SSH em lote#

Ao disparar playbooks pela primeira vez contra dezenas de instâncias recém-criadas, o processo pode travar aguardando confirmação interativa do fingerprint da chave pública.

• Workaround no ansible.cfg: Configurar host_key_checking = False.
• Boa prática de segurança: Em vez de desabilitar a checagem globalmente (o que abre margem para ataques de Man-in-the-Middle), pré-popule o arquivo known_hosts do nó de controle antes do deploy:

ssh-keyscan -H 192.168.10.11 >> ~/.ssh/known_hosts

B. Falhas de escalonamento com sudo (requiretty)#

Ao conectar como um usuário sem privilégios e utilizar become: yes, o Ansible executa no alvo uma instrução equivalente a:

sudo -H -S -p "[sudo password prompt] " -u root /bin/sh -c '...'

Se a diretiva Defaults requiretty estiver ativada no arquivo /etc/sudoers do servidor de destino, a execução falhará imediatamente. Isso acontece porque, por padrão, o Ansible não aloca um pseudoterminal (TTY) para economizar I/O e evitar problemas de buffer. A solução é ajustar o /etc/sudoers para liberar comandos sem TTY para o usuário de automação.

Boas práticas para conexões confiáveis no Ansible#

Garantir uma execução sólida no Ansible vai além de listar nós em um arquivo: depende de alinhar a cadeia de confiança do SSH, a integridade do MTU de rede, a declaração explícita do interpretador Python e as permissões de escalonamento no sudoers.

Entender esses mecanismos no nível do sistema operacional é o que transforma automações instáveis em uma infraestrutura verdadeiramente previsível.

Veja também

DevOps Refatorando playbooks Ansible: da execução imperativa ao padrão declarativo e idempotente

DevOps Automatizando gestão de acessos em escala: do Bash com cPanel/WHM à orquestração com Ansible

DevOps Do SSH em lote à automação com UI: gerenciando múltiplas VPS com Ansible Semaphore

Este post está licenciado sob CC BY-NC.