☕ Um Café no Bellacosa Mainframe
🕵️ Ansible sob a Tutela de Beggarman — Tinker, Tailor, Soldier, Spy e o Segredo de Automatizar sem Confiar em Ninguém
“Na infraestrutura, como na espionagem, o problema raramente é executar uma ordem. O problema é saber quem deu a ordem, com que autoridade, sobre quais máquinas — e o que acontecerá se ela estiver errada.”
Existe uma tentação perigosa quando conhecemos Ansible pela primeira vez.
Ele parece simples.
Um arquivo YAML, alguns servidores, uma conexão, algumas tarefas e pronto: aquilo que antes exigia entrar máquina por máquina começa a acontecer automaticamente.
É sedutor.
É também exatamente o tipo de situação em que George Smiley provavelmente tiraria os óculos, limparia lentamente as lentes e perguntaria:
— Quem mais tem acesso a isso?
Porque automação não elimina risco.
Automação automatiza o risco também.
E é aqui que nosso café entra numa atmosfera muito diferente.
Hoje não teremos laboratórios luminosos, gurus DevOps sorridentes ou nuvens coloridas ligadas por setinhas. Vamos entrar nos corredores cinzentos de Tinker Tailor Soldier Spy, onde ninguém sabe exatamente em quem confiar, informação vale poder e um detalhe aparentemente insignificante pode denunciar toda uma operação.
Sob a tutela de Beggarman, vamos descobrir que aprender Ansible não significa simplesmente aprender YAML.
Significa aprender a controlar uma máquina capaz de executar suas ordens em dezenas, centenas ou milhares de sistemas.
E isso muda tudo.
🕵️ 1. Tinker, Tailor, Soldier, Spy
Tinker Tailor Soldier Spy nasceu como romance de espionagem de John le Carré, publicado em 1974, e acompanha George Smiley na investigação de um agente soviético infiltrado no alto escalão do serviço secreto britânico.
Posteriormente vieram adaptações, incluindo a célebre minissérie da BBC de 1979 com Alec Guinness e o filme de 2011 dirigido por Tomas Alfredson, com Gary Oldman como Smiley.
O universo criado por le Carré está muito distante do glamour de James Bond.
Não espere:
carros esportivos
martínis
gadgets explosivos
vilões em bases subterrâneasO verdadeiro campo de batalha é composto por:
informações
credenciais
autorizações
documentos
fontes
cadeias de confiança
compartimentalizaçãoCuriosamente, essa também é uma excelente lista de preocupações para quem administra infraestrutura.
E os codinomes usados na investigação são perfeitos para nossa missão:
Tinker
Tailor
Soldier
Poorman
BeggarmanBeggarman é a peça que nos interessa.
Porque nossa infraestrutura também precisa descobrir:
quem pode fazer o quê?
🎯 2. A primeira missão: entender o que é Ansible
Imagine uma empresa com cem servidores.
Sem automação, um administrador poderia precisar conectar-se individualmente:
server01
server02
server03
...
server100Executar comandos.
Copiar arquivos.
Alterar configurações.
Instalar software.
Reiniciar serviços.
Agora imagine fazer tudo novamente no mês seguinte.
E novamente.
E novamente.
É assim que pequenas diferenças começam a surgir.
No servidor 17 alguém esqueceu uma configuração.
No servidor 32 existe uma versão diferente.
No 48 um parâmetro foi digitado errado.
No 73 alguém resolveu “melhorar” alguma coisa.
Temos então o inimigo silencioso:
configuration drift.
Os servidores que deveriam ser iguais lentamente deixam de ser iguais.
Ansible entra justamente nesse cenário.
Em sua forma conceitual mais simples:
CONTROL NODE
|
ANSIBLE
|
SSH
|
+------------+------------+
| | |
SERVER A SERVER B SERVER CO operador escreve o que deseja.
Ansible executa essa automação nos sistemas apropriados.
Mas Beggarman imediatamente faria uma pergunta:
Quais são os sistemas apropriados?
Excelente.
Precisamos de um inventário.
📋 3. Inventory — a lista de agentes da operação
Todo serviço de inteligência precisa saber quem está participando da operação.
Ansible também.
Podemos ter:
[webservers]
web01
web02
web03
[databases]
db01
db02
[production]
prod01
prod02Isso é o inventory.
Ele diz ao Ansible quais hosts existem e permite organizá-los em grupos.
Pense nele como nosso dossier operacional.
Podemos separar:
DEV
TEST
UAT
PRODOu:
WEB
APPLICATION
DATABASE
MONITORINGE aqui aparece uma regra Bellacosa Mainframe extremamente importante:
Nunca trate produção como simplesmente “mais um servidor”.
Produção é uma fronteira administrativa.
A existência de grupos permite limitar o alcance de uma operação.
E isso nos apresenta um conceito que Beggarman conhece muito bem:
blast radius.
Se eu errar, quantas máquinas consigo destruir?
Uma?
Dez?
Mil?
Automação multiplica produtividade.
Consequentemente, também pode multiplicar um erro.
📡 4. Ad hoc — uma mensagem rápida do Circus
Ansible permite comandos rápidos.
Por exemplo:
ansible all -m pingIsso testa a capacidade do Ansible de alcançar os hosts e executar o módulo correspondente.
Podemos consultar uptime:
ansible web -m command -a "uptime"São os chamados ad hoc commands.
Fantásticos para:
diagnóstico
verificação
testes
operações pontuais
troubleshootingMas existe um problema.
Imagine um agente recebendo uma ordem verbal:
“Vá até lá e faça isso.”
Funcionou.
Três meses depois alguém pergunta:
Quem mandou?
Qual era exatamente o comando?
Por que foi executado?
Podemos repetir?
Talvez ninguém saiba.
É exatamente por isso que operações repetíveis deveriam evoluir para playbooks.
📖 5. Playbook — o plano da operação
Um playbook descreve a automação.
Exemplo:
- name: Configurar servidores web
hosts: webservers
become: true
tasks:
- name: Instalar nginx
ansible.builtin.package:
name: nginx
state: present
- name: Iniciar nginx
ansible.builtin.service:
name: nginx
state: started
enabled: trueObserve algo interessante.
Não escrevemos simplesmente:
execute apt
execute systemctl
execute outro comandoEstamos descrevendo estados:
nginx deve existir
nginx deve estar iniciado
nginx deve estar habilitadoÉ uma diferença aparentemente pequena.
Conceitualmente, é gigantesca.
♻️ 6. Idempotência — Beggarman executa a mesma ordem duas vezes
Chegamos talvez ao conceito mais importante desta conversa.
Imagine executar o playbook.
Primeira vez:
TASK Install nginx
changed
TASK Start nginx
changedExecute novamente.
TASK Install nginx
ok
TASK Start nginx
okPor quê?
Porque o estado desejado já existe.
Esse é o coração da idempotência.
De forma simplificada:
executar novamente uma automação idempotente não deveria produzir mudanças desnecessárias quando o sistema já está no estado desejado.
Para quem vem de COBOL e batch, isso deveria imediatamente acender uma luz vermelha.
Imagine:
JOB
|
STEP01
|
STEP02
|
STEP03
|
ABENDAgora são 03:17.
Sim, meu caro leitor.
Você encontrou o easter egg.
☎️ O telefone toca.
Alguém pergunta:
“Pode dar rerun?”
E essa pequena frase pode significar quinze minutos ou cinco horas de investigação.
STEP01 pode executar novamente?
Vai duplicar registros?
STEP02 já atualizou alguma tabela?
Há checkpoint?
Existe restart?
O processamento é recuperável?
É por isso que um mainframer consegue compreender intuitivamente por que idempotência é tão importante.
O problema não é apenas:
“funciona?”
É:
“posso executar novamente com segurança?”
Essa é uma pergunta muito mais madura.
🧱 7. Modules — nossos agentes especializados
Ansible possui módulos para operações específicas:
package
service
copy
file
template
user
uri
debugO iniciante frequentemente tenta transformar Ansible em um executor remoto de shell.
Algo como:
shell: apt-get install nginxPode funcionar.
Mas um módulo apropriado normalmente expressa melhor a intenção:
ansible.builtin.package:
name: nginx
state: presentObserve novamente a diferença.
No primeiro:
execute este comando.
No segundo:
garanta este estado.
É a diferença entre procedimento e intenção operacional.
🧠 8. Variables — ninguém deveria esconder valores dentro da missão
Agora imagine que nosso playbook contém:
porta 8080
servidor X
diretório Y
usuário ZTudo escrito diretamente no código.
Funciona até precisarmos de:
DEV
TEST
UAT
PRODEntão começamos a copiar arquivos.
Nasce:
playbook-dev.yml
playbook-test.yml
playbook-uat.yml
playbook-prod.ymlPouco depois:
playbook-prod-final.yml
playbook-prod-final2.yml
playbook-prod-final-CERTO.ymlE finalmente:
playbook-prod-final-CERTO-NAO-APAGAR.yml😂
Beggarman desapareceria voluntariamente antes de investigar isso.
A solução são variáveis.
app_name: nginx
port: 80
environment: productionAgora lógica e dados começam a se separar.
🔎 9. Facts — interrogando o próprio servidor
Mais interessante ainda: nem toda informação precisa ser fornecida manualmente.
Ansible pode coletar facts.
Podemos descobrir características do host:
sistema operacional
hostname
endereços
interfaces
memória
arquiteturaIsso permite decisões.
Conceitualmente:
HOST
|
FACTS
|
+----+----+
| |
RedHat Debian
| |
tarefa A tarefa BNossa automação deixou de ser uma sequência rígida.
Ela começou a observar o ambiente.
🔀 10. when, loop e register — finalmente aparece lógica
Agora entram condições:
when: feature_enabled == trueRepetições:
loop:
- nginx
- git
- vimE captura de resultados:
register: disk_outputPara o programador COBOL iniciante, podemos traduzir mentalmente:
when → IF / EVALUATE
loop → PERFORM
register → guardar resultado para decisão posteriorNão são equivalências formais.
São pontes cognitivas.
E pontes são extremamente úteis quando estamos aprendendo algo novo.
📝 11. Templates — uma identidade, muitos disfarces
Beggarman aprovaria Jinja2.
Temos um template:
server {
listen {{ port }};
server_name {{ domain }};
}Para DEV:
port = 8080
domain = dev.examplePara PROD:
port = 443
domain = production.exampleUm modelo.
Múltiplas configurações.
Isso elimina dezenas de arquivos quase iguais e reduz divergências acidentais.
É uma ideia antiga e poderosa:
separe aquilo que permanece daquilo que varia.
🔔 12. Handlers — não reinicie o serviço sem motivo
Esta é uma das minhas partes favoritas.
Imagine que alteramos uma configuração do nginx.
Então notificamos:
notify: Restart nginxO handler executará a ação apropriada quando necessário.
Mentalmente:
CONFIGURAÇÃO
|
mudou?
/ \
NÃO SIM
| |
fim HANDLER
|
restartIsso parece trivial até lembrarmos que estamos falando de produção.
Reiniciar serviços indiscriminadamente é criar indisponibilidade porque sim.
Um bom operador pergunta:
mudou alguma coisa?
Depois:
reload resolve?
Somente depois:
preciso realmente de restart?
Automação madura tenta produzir a menor perturbação necessária.
George Smiley chamaria isso de discrição.
Nós chamamos de engenharia.
🔐 13. become — quem autorizou este agente?
Chegamos à parte que deveria fazer todo mainframer prestar atenção.
become: truePermite executar tarefas utilizando escalada de privilégio conforme o mecanismo configurado.
Mas o verdadeiro assunto não é a keyword.
É:
autoridade.
Quem executa?
Como autentica?
Qual identidade utiliza?
Que privilégios possui?
Durante quanto tempo?
Sobre quais sistemas?
Para executar quais tarefas?
Quem audita?
De repente, alguém que trabalha com RACF começa a sorrir.
Porque o mundo distribuído descobriu uma velha verdade:
identidade sem controle de autorização é uma bomba esperando um operador distraído.
O princípio correto é least privilege.
Não dê root porque é conveniente.
Dê apenas a autoridade necessária.
🗝️ 14. Ansible Vault — há informações que nem Tinker deve conhecer
Passwords.
API keys.
Tokens.
Credenciais.
Certificados e material sensível.
Nunca deveriam ser alegremente colocados num playbook:
password: supersecret123e depois:
git pushParabéns.
Você acabou de publicar a chave da sala secreta.
Ansible Vault permite proteger conteúdo sensível criptografando dados que precisam permanecer armazenados.
Mas existe uma sutileza fundamental:
criptografado em repouso não significa protegido durante toda a execução.
Em algum momento o segredo precisa ser utilizado.
Portanto, gestão de segredos envolve muito mais:
armazenamento
acesso
rotação
auditoria
exposição em logs
CI/CD
permissões
revogaçãoEm ambientes maiores entram secret managers dedicados.
Porque a pergunta nunca deveria ser apenas:
“Está criptografado?”
Deveria ser:
“Quem consegue descriptografar?”
Beggarman certamente faria essa pergunta.
📦 15. Roles — compartimentalização
E chegamos à página que fecha magistralmente o conjunto.
Um playbook cresce.
E cresce.
E cresce.
Até virar aquele velho programa COBOL de 18 mil linhas que ninguém quer alterar porque:
“Tem uma coisa lá no parágrafo 7420 que ninguém sabe para que serve, mas quando tiraram em 2007 fechou a folha errada.”
😎
Ansible possui Roles.
Podemos organizar:
webserver/
├── tasks/
├── handlers/
├── templates/
├── files/
├── defaults/
├── vars/
└── meta/Então:
PLAYBOOK
|
+------------+------------+
| | |
WEB DB MONITORING
| | |
ROLE ROLE ROLEIsso cria:
modularidade
reutilização
padronização
manutenção
testabilidade
colaboraçãoE aqui Beggarman finalmente fecha o dossier.
Porque serviços de inteligência conhecem muito bem outro princípio:
compartimentalização.
Cada componente deve possuir responsabilidade claramente definida.
🏛️ 16. O mainframe estava esperando por esta conversa
Agora retire as marcas comerciais.
Esqueça por alguns segundos Linux, nginx, YAML e cloud.
Observe apenas:
automação
procedimentos
parâmetros
condições
reutilização
segurança
autoridade
restart
controle
auditoria
recuperação
padronizaçãoMeu amigo...
isso soa familiar.
Muito familiar.
O mainframe vive há décadas cercado por conceitos semelhantes:
JCL
PROC
symbolic parameters
RACF
scheduler
REXX
CLIST
SMP/E
libraries
change management
restart/recoveryNão significa que Ansible seja “JCL moderno”.
Essa comparação seria tecnicamente pobre.
Mas ambos pertencem a uma longa tradição da computação corporativa:
transformar operações complexas em procedimentos controlados, reproduzíveis e auditáveis.
🧬 17. O mapa mental do programador COBOL
Para quem está chegando agora, eu usaria esta ponte:
| Mainframe | Ansible | Ideia |
|---|---|---|
| JOB | Playbook | operação coordenada |
| PROC | Role | reutilização |
| STEP | Task | unidade de trabalho |
| PARM / symbolic | Variable | parametrização |
| condição | when | decisão |
| repetição | loop | processamento repetitivo |
| RC | registered result | resultado utilizado posteriormente |
| RACF | identidade / become | autoridade |
| biblioteca | repository | conteúdo controlado |
| restart/recovery | idempotência + tratamento | execução segura |
Mais uma vez:
mapa mental, não equivalência técnica.
Mas funciona maravilhosamente para quebrar a barreira inicial.
🚨 18. O que as páginas não mostram
Agora Beggarman coloca outra pasta sobre a mesa.
Está escrito:
PRODUCTION.
É aí que a brincadeira muda.
Porque não basta saber:
inventory
playbook
task
module
role
vaultPrecisamos começar a perguntar:
Quem aprovou?
Quem executou?
Qual versão?
Quais hosts?
Quantos simultaneamente?
Existe dry run?
Existe backup?
Existe rollback?
Como monitoramos?
Como interrompemos?
O que acontece se 37 funcionarem e o 38 falhar?
Podemos continuar?
Podemos rerodar?
Qual é o blast radius?Essas são perguntas que transformam um estudante de Ansible em alguém capaz de pensar em produção.
💥 19. A verdadeira missão: failure engineering
Imagine:
100 servidores
001 OK
002 OK
003 OK
...
037 OK
038 FAILEDSilêncio.
Agora temos:
039
040
041
...
100O que fazemos?
Continuamos?
Paramos?
Rollback?
Investigamos?
E o servidor 38?
A operação nele falhou antes ou depois da alteração crítica?
Existe estado intermediário?
Esta é uma verdade importante:
automação não elimina incidentes; muda a velocidade e a escala com que eles podem acontecer.
Um humano talvez configure dez máquinas incorretamente durante uma manhã.
Uma automação pode configurar mil incorretamente antes do café esfriar.
Portanto:
velocidade sem controle não é maturidade.
É apenas velocidade.
🕵️ 20. A lição de Beggarman
No final de Tinker Tailor Soldier Spy, aquilo que importa não é uma perseguição cinematográfica.
É confiança.
Quem possui informação?
Quem controla acesso?
Quem conhece a operação?
Quem pode alterar alguma coisa?
Quem deixou rastros?
Quem está dizendo a verdade?
Curiosamente, são excelentes perguntas para DevSecOps.
Nossa infraestrutura possui seus próprios agentes:
usuários
service accounts
pipelines
APIs
tokens
SSH keys
playbooks
roles
secret managers
automation controllersCada um possui determinada capacidade.
Portanto, segurança de automação começa por uma pergunta profundamente simples:
Em quem estamos confiando?
E continua:
Quanto estamos confiando?
Essa segunda pergunta é ainda melhor.
☕ Epílogo — O espião que entrou no datacenter
Imagine Beggarman caminhando lentamente pelo corredor do datacenter.
Luzes piscando.
Ventiladores.
Milhares de processos trabalhando.
Ele observa um Automation Controller capaz de modificar centenas de servidores.
Pergunta:
— Quem pode executar isto?
O engenheiro responde:
— A equipe de infraestrutura.
Beggarman olha novamente.
— Toda a equipe?
Silêncio.
— Bem... sim.
Ele continua:
— E quem pode alterar os playbooks?
— Os desenvolvedores.
— Todos?
Outro silêncio.
— Onde estão as credenciais?
— No pipeline.
— Quem pode alterar o pipeline?
Agora ninguém mais toca no café.
E é justamente aí que percebemos a grande lição desta história.
Ansible não é simplesmente uma ferramenta para executar comandos mais rapidamente.
É uma plataforma capaz de transformar intenção humana em alteração de infraestrutura em escala.
Isso merece disciplina.
Inventories definem onde.
Playbooks definem o quê.
Variables definem com quais valores.
Conditions definem quando.
Modules definem como.
Handlers controlam as consequências das mudanças.
Roles organizam responsabilidades.
Vault ajuda a proteger segredos.
become participa da definição de autoridade.
Idempotência ajuda a garantir que repetir uma ordem não transforme uma operação rotineira numa investigação às 03:17 da manhã.
E Git, revisão, CI/CD, observabilidade, segregação de funções e auditoria ajudam a responder à pergunta que inevitavelmente aparecerá quando alguma coisa der errado:
“Quem mudou o quê, onde, quando, por quê — e podemos colocar tudo de volta?”
Essa pergunta não nasceu com DevOps.
Não nasceu com cloud.
Muito menos com YAML.
Mainframes já conviviam com versões dela quando muitos dos atuais engenheiros ainda nem haviam nascido.
Talvez seja essa a maior ironia de nossa missão.
Depois de décadas distribuindo processamento, criando milhares de servidores, microsserviços, containers, clouds e APIs, a indústria começou novamente a procurar desesperadamente por:
controle, padronização, segurança, repetibilidade e previsibilidade.
Em algum lugar, dentro de uma sala refrigerada, um velho mainframe continua processando tranquilamente seus JOBs.
Beggarman fecha a pasta.
Olha para nós.
E talvez diga apenas:
“Automatize tudo o que puder. Mas nunca automatize aquilo que você ainda não entende.”
☕ Um Café no Bellacosa Mainframe
Porque em produção, como no Circus, confiança nunca deveria ser implícita.
