☕ 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âneas

O verdadeiro campo de batalha é composto por:

informações
credenciais
autorizações
documentos
fontes
cadeias de confiança
compartimentalização

Curiosamente, 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
Beggarman

Beggarman é 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
...
server100

Executar 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 C

O 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
prod02

Isso é 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
PROD

Ou:

WEB
APPLICATION
DATABASE
MONITORING

E 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 ping

Isso 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
troubleshooting

Mas 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: true

Observe algo interessante.

Não escrevemos simplesmente:

execute apt
execute systemctl
execute outro comando

Estamos 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
changed

Execute novamente.

TASK Install nginx
ok

TASK Start nginx
ok

Por 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
 |
ABEND

Agora 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
debug

O iniciante frequentemente tenta transformar Ansible em um executor remoto de shell.

Algo como:

shell: apt-get install nginx

Pode funcionar.

Mas um módulo apropriado normalmente expressa melhor a intenção:

ansible.builtin.package:
  name: nginx
  state: present

Observe 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 Z

Tudo escrito diretamente no código.

Funciona até precisarmos de:

DEV
TEST
UAT
PROD

Então começamos a copiar arquivos.

Nasce:

playbook-dev.yml
playbook-test.yml
playbook-uat.yml
playbook-prod.yml

Pouco depois:

playbook-prod-final.yml
playbook-prod-final2.yml
playbook-prod-final-CERTO.yml

E 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: production

Agora 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
arquitetura

Isso permite decisões.

Conceitualmente:

          HOST
           |
        FACTS
           |
      +----+----+
      |         |
    RedHat    Debian
      |         |
   tarefa A   tarefa B

Nossa 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 == true

Repetições:

loop:
  - nginx
  - git
  - vim

E captura de resultados:

register: disk_output

Para o programador COBOL iniciante, podemos traduzir mentalmente:

when       → IF / EVALUATE
loop       → PERFORM
register   → guardar resultado para decisão posterior

Nã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.example

Para PROD:

port = 443
domain = production.example

Um 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 nginx

O handler executará a ação apropriada quando necessário.

Mentalmente:

CONFIGURAÇÃO
      |
    mudou?
    /    \
  NÃO    SIM
   |      |
  fim   HANDLER
          |
       restart

Isso 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: true

Permite 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: supersecret123

e depois:

git push

Parabé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ção

Em 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          ROLE

Isso cria:

modularidade
reutilização
padronização
manutenção
testabilidade
colaboração

E 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ção

Meu 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/recovery

Nã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
vault

Precisamos 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 FAILED

Silêncio.

Agora temos:

039
040
041
...
100

O 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 controllers

Cada 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.