 |
| Bellacosa Mainframe e o ansible sem misterios no Windows |
☕ Um Café no Bellacosa Mainframe
Ansible sem Mistérios no Windows
O guia do Programador COBOL Padawan para automatizar Linux, Apache, Java, WebSphere e IBM Z sem abandonar o legado
Existe um momento na carreira de todo Programador COBOL em que ele percebe uma verdade desconfortável:
o programa pode estar perfeito, mas existe um universo inteiro entre o código-fonte e a produção.
É preciso compilar.
Fazer o link-edit.
Copiar módulos de carga.
Executar testes.
Atualizar bibliotecas.
Submeter JCL.
Configurar servidores.
Alterar arquivos.
Reiniciar serviços.
Verificar logs.
Validar portas.
Confirmar se a aplicação voltou a responder.
E, muitas vezes, repetir tudo isso em desenvolvimento, homologação, contingência e produção.
Durante décadas, essas tarefas foram realizadas por meio de procedimentos escritos em documentos, planilhas, scripts isolados e valiosos conhecimentos armazenados na memória de profissionais veteranos.
Funcionava?
Sim.
Mas também criava uma perigosa dependência de operações manuais.
Um comando digitado incorretamente, um membro copiado para a biblioteca errada ou uma configuração esquecida poderia transformar uma implantação aparentemente simples em um incidente digno de um alerta vermelho na ponte da USS Enterprise.
É justamente nesse espaço que entra o Ansible.
Ele não veio para substituir COBOL, JCL, CICS, Db2, IMS, Linux, Java ou WebSphere.
Ele veio para orquestrar essas tecnologias, transformando procedimentos manuais em automações documentadas, repetíveis, versionáveis e auditáveis.
Portanto, sente-se na cadeira de comando, Padawan. Neste artigo construiremos um laboratório gratuito no Windows, instalaremos o Ansible, criaremos nossos primeiros Playbooks, configuraremos Apache e Java e entenderemos como essa ferramenta se conecta ao universo do IBM Z.
1. Afinal, o que é o Ansible?
O Ansible é uma tecnologia de automação de TI capaz de executar tarefas como:
configuração de servidores;
instalação de programas;
implantação de aplicações;
provisionamento de infraestrutura;
execução de comandos;
administração de serviços;
automação de redes;
integração de ambientes híbridos;
orquestração de processos com várias etapas.
Em vez de um administrador acessar manualmente cada máquina, o Ansible recebe uma descrição do que deve ser feito e executa essas ações nos equipamentos selecionados.
A documentação oficial define o Ansible como uma tecnologia aberta capaz de descrever e automatizar ambientes de TI, desde pequenos laboratórios domésticos até infraestruturas corporativas de grande escala. (Ansible Docs)
Imagine que uma empresa tenha:
Sem automação, alguém precisaria entrar máquina por máquina para realizar as alterações.
Com Ansible, podemos escrever uma instrução como:
- name: Garantir que o Apache esteja instalado
ansible.builtin.apt:
name: apache2
state: present
Essa pequena tarefa declara um estado desejado:
“O pacote Apache deve estar instalado.”
O Ansible analisa o ambiente e tenta conduzi-lo até esse estado.
Essa diferença é fundamental.
Em um Shell Script tradicional, normalmente escrevemos uma sequência de comandos:
apt update
apt install apache2
systemctl start apache2
No Ansible, descrevemos principalmente o resultado que queremos alcançar.
Essa abordagem aproxima a infraestrutura do desenvolvimento de software.
2. Infraestrutura como código
Durante muito tempo, a infraestrutura foi tratada como algo quase artesanal.
Um especialista configurava um servidor.
Outro alterava uma propriedade.
Um terceiro modificava o firewall.
Cada mudança poderia ser registrada em um chamado, mas nem sempre era possível reconstruir exatamente o ambiente apenas lendo a documentação.
A Infraestrutura como Código, conhecida pela sigla IaC — Infrastructure as Code, muda essa lógica.
Configurações passam a ser armazenadas em arquivos.
Esses arquivos podem ser:
Para um Programador COBOL, a analogia é simples.
Imagine que a configuração de um servidor seja como um programa executável sem código-fonte.
Ele funciona, mas ninguém sabe exatamente como foi construído.
O Ansible devolve o “fonte” da infraestrutura.
O Playbook passa a representar a sequência lógica usada para construir ou configurar aquele ambiente.
3. Como o Ansible funciona?
O Ansible trabalha, de maneira simplificada, com dois lados:
┌──────────────────────────────┐
│ CONTROL NODE │
│ │
│ Ansible │
│ Inventários │
│ Playbooks │
│ Variáveis │
│ Credenciais │
└──────────────┬───────────────┘
│
SSH, APIs ou
protocolos específicos
│
┌─────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Linux IBM Z Windows
Apache z/OS Servidores
Java USS corporativos
O Control Node é a máquina onde o Ansible é executado.
Os Managed Nodes são os sistemas administrados.
Em ambientes Linux e Unix, a comunicação costuma ocorrer por SSH.
Para administrar Windows como destino, o Ansible pode utilizar mecanismos como WinRM. A documentação também oferece módulos específicos para instalar programas, administrar atualizações, usuários, grupos, serviços e outros componentes do Windows. (Ansible Docs)
No IBM Z, a comunicação depende da coleção utilizada e dos pré-requisitos configurados. A coleção IBM z/OS Core, por exemplo, permite que o Ansible execute módulos no z/OS e devolva os resultados ao controlador. (IBM GitHub)
4. O que significa dizer que o Ansible é “agentless”?
Muitas plataformas de administração precisam instalar permanentemente um agente em cada servidor.
Esse agente fica ativo, recebe comandos e informa o estado da máquina.
O Ansible adota uma abordagem diferente em muitos de seus cenários: ele normalmente utiliza mecanismos já existentes no sistema, como SSH, bibliotecas Python ou APIs.
Isso reduz a necessidade de manter um programa específico do Ansible permanentemente executando em cada Linux administrado.
Mas “agentless” não significa “sem requisitos”.
A máquina de destino ainda pode precisar de:
No z/OS, por exemplo, diferentes versões da coleção podem exigir combinações específicas de ansible-core, IBM Open Enterprise SDK for Python e Z Open Automation Utilities, o ZOAU. Por isso, sempre é necessário conferir a matriz de requisitos da versão utilizada. (IBM GitHub)
Esse é um erro comum do Padawan:
“Se não tem agente, então não precisa preparar nada.”
Precisa, sim.
A ausência de um agente próprio apenas simplifica parte da arquitetura.
5. Posso instalar Ansible no Windows?
A resposta correta é:
podemos estudar e executar Ansible em uma máquina Windows usando WSL, mas o Ansible não é executado nativamente no Windows como Control Node tradicional.
A documentação oficial informa que o Windows não é suportado como Control Node nativo, mas que é possível executar Ansible no Windows por meio do Windows Subsystem for Linux — WSL ou de um contêiner. A mesma documentação alerta que o uso de WSL como controlador não é suportado para sistemas de produção. Para aprendizado, testes locais e desenvolvimento, entretanto, ele é uma excelente estação de treinamento. (Ansible Docs)
Nossa arquitetura de laboratório será esta:
Windows 11
│
├── PowerShell
├── Navegador
├── Visual Studio Code
│
└── WSL 2
└── Ubuntu
├── Bash
├── Python
├── Git
├── Ansible
├── Apache
├── Java
└── Playbooks YAML
O Windows continuará sendo sua nave principal.
O Ubuntu no WSL será a sala de máquinas onde o Ansible será executado.
6. O que é WSL?
WSL significa Windows Subsystem for Linux.
Ele permite executar uma distribuição GNU/Linux diretamente no Windows, incluindo ferramentas de linha de comando, Bash, gerenciadores de pacotes e aplicações Linux, sem exigir uma instalação dual boot. A Microsoft apresenta o WSL justamente como uma maneira de utilizar ambientes Linux e Windows na mesma estação. (Microsoft Learn)
Para o nosso laboratório, usaremos o WSL 2.
Ele oferece um ambiente Linux muito mais próximo de uma instalação real, sendo adequado para estudar:
Bash;
SSH;
Git;
Python;
Ansible;
Apache;
Java;
Docker;
ferramentas DevOps.
Easter egg da Frota Estelar
O WSL é como o Holodeck da Enterprise.
Você continua fisicamente dentro do Windows, mas entra em um ambiente Linux suficientemente convincente para executar ferramentas, criar arquivos, instalar serviços e praticar comandos como se estivesse em outra nave.
A diferença é que, se o laboratório der errado, você não precisará chamar o Chefe O’Brien.
Na maioria das vezes.
7. Passo a passo: instalando o WSL 2
Abra o PowerShell como administrador.
Execute:
wsl --install
Esse é o método simplificado recomendado atualmente pela Microsoft. Ele habilita os componentes necessários e normalmente instala o Ubuntu como distribuição padrão. Depois da instalação, o computador poderá solicitar uma reinicialização. (Microsoft Learn)
Após reiniciar, abra novamente o PowerShell e execute:
wsl --list --verbose
Ou a forma abreviada:
wsl -l -v
Você deverá encontrar algo semelhante a:
NAME STATE VERSION
* Ubuntu Stopped 2
Caso o Ubuntu apareça como WSL 1, execute:
wsl --set-version Ubuntu 2
Para determinar que novas distribuições utilizem WSL 2 por padrão:
wsl --set-default-version 2
Novas instalações feitas por wsl --install normalmente já utilizam o WSL 2 por padrão. (Microsoft Learn)
Quando abrir o Ubuntu pela primeira vez, será necessário criar:
Você pode escolher:
bellacosa
ou:
cobolpadawan
Ao digitar a senha no terminal Linux, nenhum asterisco aparecerá.
Não é erro.
Não é travamento.
Não é interferência dos Borg.
O Linux simplesmente não exibe os caracteres da senha.
8. Preparando o Ubuntu
Abra o Ubuntu e execute:
sudo apt update
sudo apt upgrade -y
O primeiro comando atualiza a lista de pacotes disponíveis.
O segundo instala as atualizações.
Depois, instale algumas ferramentas úteis:
sudo apt install git python3 python3-pip openssh-client nano curl -y
Essas ferramentas terão funções importantes:
git: versionamento;
python3: execução de módulos;
pip: instalação de pacotes Python;
openssh-client: conexões SSH;
nano: editor simples;
curl: testes de páginas e APIs.
9. Instalando o Ansible
Para um laboratório inicial no Ubuntu, podemos utilizar:
sudo apt install ansible -y
Depois, confirme:
ansible --version
A saída deve apresentar informações como:
ansible [core ...]
config file = ...
python version = ...
jinja version = ...
A documentação oficial também descreve métodos de instalação por pacotes das distribuições e por ferramentas do ecossistema Python. A melhor escolha depende do objetivo: simplicidade para estudo, controle rigoroso de versões, desenvolvimento de coleções ou uso corporativo. (Ansible Docs)
Para nosso primeiro Holodeck, o pacote do Ubuntu é suficiente.
10. Criando a estrutura do laboratório
No Ubuntu, execute:
mkdir -p ~/ansible-lab
cd ~/ansible-lab
Verifique:
pwd
O resultado deverá ser semelhante a:
/home/bellacosa/ansible-lab
Crie algumas pastas:
mkdir -p playbooks inventory files templates roles
Nossa estrutura ficará assim:
ansible-lab/
├── inventory/
├── playbooks/
├── files/
├── templates/
└── roles/
Não precisamos usar todas imediatamente.
Mas estamos preparando o laboratório para crescer de maneira organizada.
11. Inventário: o mapa estelar do Ansible
O inventário informa ao Ansible quais máquinas podem ser administradas.
Crie o arquivo:
nano inventory/hosts.ini
Digite:
[local]
localhost ansible_connection=local
Salve pressionando:
Ctrl + O
Enter
Ctrl + X
Esse inventário cria um grupo chamado local.
Dentro dele existe uma máquina:
localhost
A variável:
ansible_connection=local
informa que a execução será feita diretamente no Ubuntu do WSL, sem abrir uma conexão SSH.
A documentação do Ansible considera inventários, Playbooks, plays, tasks, roles e collections entre seus conceitos fundamentais. (Ansible Docs)
Pense no inventário como um mapa estelar:
[web]
web01
web02
[database]
db01
[mainframe]
zos01
[producao]
web01
web02
db01
zos01
Você pode agrupar os alvos por:
tecnologia;
ambiente;
localização;
aplicação;
função;
criticidade.
12. O primeiro contato: o módulo ping
Execute:
ansible all -i inventory/hosts.ini -m ping
Resultado esperado:
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}
Esse ping não é exatamente o mesmo comando de rede usado para testar ICMP.
O módulo do Ansible verifica se ele consegue executar corretamente no destino e obter uma resposta.
Podemos decompor o comando:
ansible
Programa usado para executar uma ação rápida.
all
Todos os hosts do inventário.
-i inventory/hosts.ini
Arquivo de inventário utilizado.
-m ping
Módulo que será executado.
Esse tipo de comando é chamado de ad hoc command.
São ordens rápidas, úteis para consultas, diagnósticos e pequenas operações.
13. Coletando informações do Linux
Execute:
ansible all -i inventory/hosts.ini -m setup
O Ansible retornará uma grande quantidade de informações:
distribuição Linux;
versão do sistema;
processadores;
memória;
interfaces de rede;
endereços IP;
arquitetura;
variáveis do ambiente;
discos;
hostname.
Essas informações são chamadas de facts.
Podemos filtrar a resposta:
ansible all -i inventory/hosts.ini -m setup \
-a "filter=ansible_distribution*"
Ou consultar a memória:
ansible all -i inventory/hosts.ini -m setup \
-a "filter=ansible_memtotal_mb"
Os facts podem ser usados nos Playbooks para tomar decisões.
Exemplo conceitual:
- name: Instalar pacote no Ubuntu
ansible.builtin.apt:
name: apache2
state: present
when: ansible_distribution == "Ubuntu"
Assim, a automação pode adaptar-se ao sistema encontrado.
14. O que é um Playbook?
Um Playbook é um arquivo YAML que descreve uma ou mais automações.
A documentação oficial explica que Playbooks reúnem tarefas e módulos para executar mudanças de maneira organizada nos sistemas selecionados. (Ansible Docs)
Crie:
nano playbooks/primeiro-playbook.yml
Conteúdo:
---
- name: Primeiro treinamento Bellacosa Mainframe
hosts: local
connection: local
gather_facts: true
tasks:
- name: Criar diretório do laboratório
ansible.builtin.file:
path: /tmp/bellacosa-lab
state: directory
mode: "0755"
- name: Criar mensagem para o Padawan
ansible.builtin.copy:
dest: /tmp/bellacosa-lab/mensagem.txt
content: |
Laboratório Ansible em funcionamento.
Automação autorizada pela Frota Estelar.
O COBOL continua vivo.
mode: "0644"
- name: Mostrar a distribuição Linux
ansible.builtin.debug:
msg: "Sistema detectado: {{ ansible_distribution }} {{ ansible_distribution_version }}"
Execute:
ansible-playbook \
-i inventory/hosts.ini \
playbooks/primeiro-playbook.yml
Confira o arquivo:
cat /tmp/bellacosa-lab/mensagem.txt
15. Entendendo o YAML sem entrar em um buraco negro
YAML é um formato de serialização muito utilizado em configurações.
Sua estrutura depende fortemente de indentação.
Exemplo:
tripulante:
nome: Bellacosa
funcao: Programador COBOL
nivel: Padawan
tecnologias:
- COBOL
- JCL
- Ansible
O YAML possui:
pares de chave e valor;
listas;
objetos aninhados;
valores booleanos;
números;
textos.
No Ansible:
- name: Criar arquivo
ansible.builtin.file:
path: /tmp/teste.txt
state: touch
Temos:
Regra de ouro
Use espaços.
Não utilize tabulação.
Uma indentação incorreta pode impedir a leitura do arquivo ou, pior, alterar sua estrutura lógica.
Para verificar a sintaxe:
ansible-playbook \
-i inventory/hosts.ini \
playbooks/primeiro-playbook.yml \
--syntax-check
16. Idempotência: a disciplina vulcana
Execute novamente o primeiro Playbook.
Na primeira execução, algumas tarefas podem aparecer como:
changed
Na segunda, provavelmente aparecerão como:
ok
Por quê?
Porque o diretório e o arquivo já estão no estado desejado.
Esse comportamento é chamado de idempotência.
A documentação observa que módulos idempotentes procuram produzir o mesmo resultado independentemente de o Playbook ser executado uma ou várias vezes, embora nem todo Playbook seja automaticamente idempotente. (Ansible Docs)
Matematicamente, a ideia lembra:
f(f(x)) = f(x)
Depois que o estado desejado é alcançado, repetir a operação não deveria criar uma situação diferente.
Para um veterano do batch, podemos comparar com um processo restartable bem projetado.
Um job confiável deve saber:
A idempotência é uma das bases da automação segura.
17. Instalando Apache com Ansible
Agora teremos nossa primeira missão real.
Crie:
nano playbooks/apache.yml
Conteúdo:
---
- name: Configurar Apache no Holodeck
hosts: local
connection: local
become: true
tasks:
- name: Atualizar cache de pacotes
ansible.builtin.apt:
update_cache: true
cache_valid_time: 3600
- name: Instalar Apache
ansible.builtin.apt:
name: apache2
state: present
- name: Publicar página Bellacosa
ansible.builtin.copy:
dest: /var/www/html/index.html
content: |
<!DOCTYPE html>
<html lang="pt-BR">
<head>
<meta charset="UTF-8">
<title>Bellacosa Ansible Lab</title>
</head>
<body>
<h1>Ansible sem Mistérios</h1>
<p>Servidor Apache configurado automaticamente.</p>
<p>Mensagem da ponte: o COBOL está integrado ao futuro.</p>
</body>
</html>
mode: "0644"
notify: Reiniciar Apache
- name: Garantir que o Apache esteja iniciado
ansible.builtin.service:
name: apache2
state: started
enabled: true
handlers:
- name: Reiniciar Apache
ansible.builtin.service:
name: apache2
state: restarted
Execute:
ansible-playbook \
-i inventory/hosts.ini \
playbooks/apache.yml \
--ask-become-pass
Digite a senha do usuário Ubuntu.
Depois, teste:
curl http://localhost
Abra também no navegador do Windows:
http://localhost
Se tudo funcionar, você verá a página criada pelo Ansible.
O que é become?
A instrução:
become: true
indica que determinadas tarefas precisam de privilégios elevados, normalmente usando sudo.
O que é um handler?
O handler é uma tarefa acionada por uma notificação.
Observe:
notify: Reiniciar Apache
O Apache será reiniciado apenas quando a tarefa que publica a página realmente provocar uma mudança.
Isso evita reinicializações desnecessárias.
É como dizer:
“Não acorde o Capitão apenas para informar que nada mudou.”
18. Instalando Java
Crie:
nano playbooks/java.yml
Conteúdo:
---
- name: Preparar ambiente Java
hosts: local
connection: local
become: true
tasks:
- name: Instalar OpenJDK
ansible.builtin.apt:
name: openjdk-17-jdk
state: present
update_cache: true
- name: Consultar versão do Java
ansible.builtin.command:
cmd: java -version
register: resultado_java
changed_when: false
- name: Exibir versão instalada
ansible.builtin.debug:
var: resultado_java.stderr_lines
Execute:
ansible-playbook \
-i inventory/hosts.ini \
playbooks/java.yml \
--ask-become-pass
O parâmetro:
register: resultado_java
guarda a resposta de uma tarefa em uma variável.
Depois, usamos:
ansible.builtin.debug:
var: resultado_java.stderr_lines
para mostrar parte dessa resposta.
A instrução:
changed_when: false
informa que a consulta à versão do Java não modifica o sistema.
Sem isso, determinados comandos podem ser marcados como mudança mesmo quando apenas realizam uma leitura.
19. Como o Ansible se relaciona com Java?
O Ansible não substitui a JVM nem escreve automaticamente a lógica da aplicação.
Ele automatiza o ambiente no qual a aplicação Java será executada.
Pode, por exemplo:
instalar o Java;
criar usuários de serviço;
criar diretórios;
copiar arquivos JAR;
distribuir arquivos WAR e EAR;
configurar variáveis de ambiente;
alterar parâmetros da JVM;
criar certificados;
instalar serviços;
configurar logs;
iniciar e parar aplicações;
validar portas;
testar URLs de saúde;
executar scripts de implantação.
Uma aplicação Java pode ser construída em um pipeline e depois entregue por Ansible:
Git
↓
Compilação Maven ou Gradle
↓
Testes
↓
Artefato JAR, WAR ou EAR
↓
Ansible
↓
Tomcat, Liberty ou WebSphere
O Ansible representa o oficial de transporte.
Ele recebe o artefato e garante que chegue ao destino correto, com a configuração correta.
20. E o WebSphere?
WebSphere é uma plataforma corporativa complexa.
Uma automação pode envolver:
No WebSphere tradicional, o Ansible pode ser usado para coordenar comandos e scripts administrativos existentes.
Um fluxo conceitual seria:
1. Retirar servidor do balanceamento
2. Parar aplicação
3. Copiar novo EAR
4. Executar script wsadmin
5. Sincronizar nós
6. Iniciar aplicação
7. Testar URL
8. Recolocar servidor no balanceamento
O valor do Ansible não está apenas em executar um comando.
Está em organizar toda a sequência, aplicar condições, capturar erros e impedir que a próxima etapa seja executada quando a anterior falhar.
Cuidado de Engenharia
Não trate WebSphere como se fosse apenas um diretório onde você copia um EAR.
Uma implantação corporativa pode exigir:
O Ansible automatiza o procedimento, mas não elimina a necessidade de compreendê-lo.
21. Conectando Ansible ao IBM Z
Agora chegamos ao setor onde pulsa o coração do Bellacosa Mainframe.
A IBM disponibiliza conteúdo Ansible voltado ao IBM Z. O objetivo é integrar o IBM Z à estratégia mais ampla de automação corporativa, unificando configuração, provisionamento, implantação e orquestração de fluxos. (Ansible Collections)
A coleção IBM z/OS Core oferece módulos para atividades como:
A documentação oficial destaca explicitamente operações como criação de data sets, submissão e consulta de jobs, recuperação de output e codificação de dados. (IBM GitHub)
Para instalar a coleção no laboratório:
ansible-galaxy collection install ibm.ibm_zos_core
Confira:
ansible-galaxy collection list
A documentação IBM informa que coleções podem ser obtidas por meios como Ansible Galaxy, Ansible Automation Hub ou construção local, dependendo da distribuição e do modelo de suporte adotado. (IBM GitHub)
22. Criando um Playbook conceitual para z/OS
Mesmo sem acesso imediato a um mainframe, você pode começar a estudar a estrutura.
Crie:
nano playbooks/zos-exemplo.yml
Conteúdo conceitual:
---
- name: Laboratório conceitual IBM Z
hosts: zos
gather_facts: false
tasks:
- name: Criar data set sequencial
ibm.ibm_zos_core.zos_data_set:
name: BELLACOS.TRAINING.DATA
type: seq
state: present
record_format: fb
record_length: 80
- name: Submeter JCL de treinamento
ibm.ibm_zos_core.zos_job_submit:
src: BELLACOS.TRAINING.JCL(HELLO)
location: data_set
wait_time_s: 30
A documentação do módulo zos_job_submit informa que ele pode submeter JCL armazenado em data set, arquivo no USS ou arquivo localizado no controlador, além de acompanhar a conclusão do job. (IBM GitHub)
Para executar de verdade, será necessário preparar:
host z/OS;
acesso de rede;
SSH;
usuário e permissões;
USS;
Python suportado;
ZOAU;
variáveis de ambiente;
inventário;
versões compatíveis.
Instalar a coleção no WSL não cria um mainframe mágico dentro do notebook.
Ela apenas prepara o controlador para conversar com um ambiente IBM Z que atenda aos requisitos.
23. Exemplo de inventário para IBM Z
Um inventário conceitual poderia ser:
[zos]
zos01 ansible_host=mainframe.empresa.local
[zos:vars]
ansible_connection=ssh
ansible_user=USUARIO
ansible_python_interpreter=/usr/lpp/IBM/cyp/v3r*/pyz/bin/python3
Os caminhos e parâmetros reais dependem da instalação da empresa.
Nunca copie cegamente configurações de um artigo para produção.
Consulte:
versão da coleção;
versão do z/OS;
versão do Python;
versão do ZOAU;
política de segurança;
configuração de SSH;
padrões internos.
Essa é uma lição essencial:
Um bom Playbook é reutilizável. Uma boa implantação, porém, respeita as particularidades do ambiente.
24. Ansible e JCL: inimigos ou aliados?
Eles são aliados.
O Ansible não substitui JCL.
JCL continua sendo a linguagem de controle dos jobs no z/OS.
O que o Ansible pode fazer é:
Imagine:
Ansible
↓
Submete JCL de compilação
↓
Espera conclusão
↓
Verifica RC
├── RC 0: continua
├── RC 4: aplica regra definida
└── RC 8+: interrompe implantação
Essa combinação preserva a força do JCL e adiciona uma camada moderna de orquestração.
É como instalar um painel LCARS na frente de uma sala de máquinas histórica.
O motor continua sendo poderoso.
A interface e a integração tornam-se mais modernas.
25. Ansible, COBOL e DevOps
Um pipeline híbrido poderia funcionar assim:
1. Desenvolvedor envia código COBOL ao Git
2. Pipeline inicia
3. Build é executado
4. Testes automatizados são realizados
5. Ansible transfere componentes
6. JCL de implantação é submetido
7. Módulos de carga são atualizados
8. BIND de Db2 é executado
9. Aplicação é validada
10. Relatório é produzido
Em uma solução distribuída:
1. COBOL processa regras de negócio no IBM Z
2. Java fornece uma camada de serviços
3. WebSphere ou Liberty hospeda aplicações
4. Apache atua como servidor ou proxy
5. Ansible coordena a configuração
6. Jenkins ou outra ferramenta inicia o pipeline
7. Git guarda código e Playbooks
O Programador COBOL que aprende Ansible deixa de enxergar apenas o programa e passa a compreender o fluxo operacional completo.
Esse profissional consegue conversar com:
desenvolvimento;
infraestrutura;
middleware;
segurança;
produção;
DevOps;
arquitetura;
cloud;
equipes Linux;
equipes IBM Z.
26. Segurança: nunca coloque senhas no Playbook
Nunca faça isto:
senha: MinhaSenha123
E muito menos envie esse arquivo para o Git.
Credenciais podem ser tratadas com mecanismos como:
Para criar um arquivo protegido com Ansible Vault:
ansible-vault create secrets.yml
Para editar:
ansible-vault edit secrets.yml
Para visualizar:
ansible-vault view secrets.yml
O objetivo não é esconder uma senha de maneira improvisada.
É impedir que segredos sejam armazenados em texto aberto ou espalhados por scripts.
Regra de segurança da Frota
Um Playbook pode ser compartilhado.
Uma senha não.
27. Modos seguros de teste
Antes de executar uma automação em ambiente importante, use ferramentas de validação.
Verificar a sintaxe
ansible-playbook playbooks/apache.yml --syntax-check
Simular alterações
ansible-playbook \
-i inventory/hosts.ini \
playbooks/apache.yml \
--check
O modo --check tenta indicar o que seria modificado sem aplicar todas as mudanças.
Entretanto, nem todo módulo consegue simular perfeitamente suas ações.
Portanto, --check ajuda, mas não substitui um ambiente de teste.
Mostrar diferenças
ansible-playbook \
-i inventory/hosts.ini \
playbooks/apache.yml \
--check \
--diff
Limitar a execução
ansible-playbook \
-i inventory/hosts.ini \
playbooks/apache.yml \
--limit localhost
Em ambientes reais, --limit é valioso para realizar um teste controlado em uma única máquina antes de alcançar todo o grupo.
28. Use nomes que expliquem a operação
Evite:
- name: Executar comando
Prefira:
- name: Reiniciar Apache após alteração do arquivo de configuração
Evite:
- name: Copiar arquivo
Prefira:
- name: Publicar página inicial do portal de treinamento
O Playbook deve funcionar como documentação executável.
Um operador deve conseguir lê-lo e compreender:
o que acontecerá;
em quais máquinas;
em que sequência;
sob quais condições.
Código misterioso pertence aos arquivos secretos da Seção 31, não à automação corporativa.
29. Não abuse dos módulos command e shell
É possível executar:
ansible.builtin.command:
cmd: touch /tmp/arquivo.txt
Mas existe um módulo específico para arquivos:
ansible.builtin.file:
path: /tmp/arquivo.txt
state: touch
O módulo especializado geralmente conhece melhor o recurso.
Ele pode:
Use command ou shell quando necessário, mas pesquise antes se existe um módulo apropriado.
A documentação do Ansible mantém um índice de módulos disponíveis nas diversas coleções. (Ansible Docs)
30. Evoluindo para templates
Imagine um arquivo de configuração do Apache diferente para cada ambiente.
Em desenvolvimento:
ServerName dev.bellacosa.local
Em produção:
ServerName www.bellacosa.com
Em vez de manter dois arquivos quase iguais, podemos utilizar um template Jinja2.
Crie:
nano templates/site.conf.j2
Conteúdo:
ServerName {{ nome_servidor }}
DocumentRoot {{ diretorio_site }}
No Playbook:
- name: Gerar configuração do site
ansible.builtin.template:
src: ../templates/site.conf.j2
dest: /etc/apache2/sites-available/bellacosa.conf
mode: "0644"
Com variáveis:
vars:
nome_servidor: localhost
diretorio_site: /var/www/html
Os templates permitem criar configurações dinâmicas sem duplicar arquivos.
Para o Programador COBOL, pense em um template como um esqueleto parametrizado, semelhante a uma PROC de JCL que recebe símbolos.
31. Roles: transformando Playbooks em componentes reutilizáveis
Quando o laboratório crescer, um único arquivo poderá ficar enorme.
As roles organizam a automação em componentes.
Exemplo:
roles/
└── apache/
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
├── templates/
├── files/
├── defaults/
│ └── main.yml
└── vars/
└── main.yml
Uma role poderia representar:
O Playbook principal passa a ser simples:
---
- name: Preparar servidor web
hosts: web
become: true
roles:
- apache
- java
Esse modelo melhora:
manutenção;
reutilização;
padronização;
testes;
documentação.
32. Ansible Community e Ansible Automation Platform
No laboratório, estamos usando a tecnologia aberta pela linha de comando.
Em empresas, também existe a Red Hat Ansible Automation Platform, voltada à execução, governança e escala corporativa da automação. (redhat.com)
Uma plataforma corporativa pode adicionar recursos como:
Mas não espere conhecer a plataforma corporativa para aprender.
Comece por:
YAML
Inventário
Módulos
Playbooks
Variáveis
Handlers
Templates
Roles
Git
A plataforma será muito mais fácil quando os fundamentos estiverem sólidos.
33. Visual Studio Code como painel LCARS
Instale no Windows:
No Ubuntu:
cd ~/ansible-lab
code .
O VS Code abrirá a pasta dentro do ambiente WSL.
Essa combinação oferece:
destaque de sintaxe;
terminal integrado;
validação;
navegação de arquivos;
integração com Git;
sugestões;
pesquisa;
comparação de versões.
O terminal continuará sendo importante, mas você terá uma ponte de comando mais confortável.
34. Um laboratório com vários servidores
Depois de dominar o localhost, avance para múltiplos destinos.
Você pode usar:
máquinas virtuais;
servidores Linux antigos;
instâncias em nuvem;
contêineres de laboratório;
Raspberry Pi;
outro computador da rede.
Arquitetura:
WSL Ubuntu — Control Node
│
├── linux-web-01
├── linux-web-02
├── linux-java-01
└── zos-treinamento
Um inventário poderia ser:
[web]
linux-web-01
linux-web-02
[java]
linux-java-01
[linux:children]
web
java
Teste apenas o grupo web:
ansible web -i inventory/hosts.ini -m ping
Execute apenas em um host:
ansible linux-web-01 -i inventory/hosts.ini -m ping
Esse é o momento em que o laboratório deixa de parecer uma ferramenta local e começa a revelar sua capacidade de orquestração.
35. Plano de ação de 12 semanas
Semanas 1 e 2 — Academia da Frota
Objetivos:
instalar WSL 2;
conhecer comandos Linux;
instalar Ansible;
criar inventário local;
executar ping e setup.
Missão prática:
Criar um Playbook que gere três arquivos em /tmp.
Semanas 3 e 4 — YAML e módulos
Estudar:
listas;
dicionários;
variáveis;
file;
copy;
package;
service;
debug.
Missão prática:
Criar usuários, diretórios e arquivos de configuração em um Linux de laboratório.
Semanas 5 e 6 — Apache e Java
Estudar:
instalação de pacotes;
handlers;
templates;
serviços;
validação por URL;
variáveis registradas.
Missão prática:
Instalar Apache e Java e publicar uma página que mostre informações do servidor.
Semanas 7 e 8 — Git e organização
Estudar:
repositórios;
commits;
branches;
revisão;
roles;
estrutura de projetos;
Ansible Vault.
Missão prática:
Transformar a automação do Apache em uma role versionada no Git.
Semanas 9 e 10 — IBM Z
Estudar:
USS;
SSH no z/OS;
Python;
ZOAU;
coleções IBM;
zos_data_set;
zos_copy;
zos_job_submit;
consulta de jobs.
Missão prática:
Escrever Playbooks conceituais e, quando houver acesso, testá-los em um ambiente educacional autorizado.
Semanas 11 e 12 — Projeto final
Construir um fluxo que:
prepare Linux;
instale Java;
configure Apache;
publique uma aplicação;
execute health check;
gere relatório;
inclua uma etapa conceitual para IBM Z.
Ao final, publique a documentação do projeto em seu repositório.
36. Dez erros clássicos do Padawan
1. Aprender somente copiando Playbooks
Copiar ajuda, mas você precisa entender cada tarefa.
2. Testar primeiro em produção
Produção não é Holodeck.
3. Armazenar senha no Git
Uma credencial vazada pode comprometer todo o ambiente.
4. Usar shell para tudo
Prefira módulos especializados.
5. Ignorar o inventário
Executar no grupo errado pode causar um desastre.
6. Não usar nomes descritivos
Uma tarefa sem descrição é um enigma para o operador.
7. Não verificar resultados
Instalação concluída não significa aplicação saudável.
8. Confundir automação com ausência de controle
Quanto maior o poder, maior deve ser a governança.
9. Ignorar versões
Coleções, Python, Ansible e sistemas precisam ser compatíveis.
10. Querer automatizar sem conhecer o processo
Se você não consegue executar o procedimento manualmente, provavelmente ainda não está pronto para automatizá-lo.
37. Curiosidades da sala de máquinas
O nome “Ansible” foi inspirado no conceito de um dispositivo fictício de comunicação instantânea encontrado na ficção científica.
É uma escolha perfeita.
O Ansible conecta sistemas distantes e transmite instruções de maneira coordenada, quase como se uma única ponte comandasse diferentes naves de uma frota.
Outra curiosidade importante é que o Ansible não está limitado à instalação de pacotes. Ele pode atuar na administração de redes, nuvens, sistemas operacionais, middleware, contêineres e mainframes.
Seu verdadeiro poder não está no comando individual.
Está na orquestração.
Instalar Apache é fácil.
Difícil é:
retirar o servidor do balanceador;
fazer backup;
atualizar a aplicação;
alterar configurações;
reiniciar serviços;
validar a página;
restaurar o tráfego;
interromper tudo e executar rollback se a validação falhar.
Esse fluxo completo é onde a automação se transforma em engenharia.
38. Por que um Programador COBOL deveria aprender Ansible?
Porque o mainframe não vive isolado.
Uma transação pode começar em:
aplicativo móvel;
navegador;
API;
microsserviço;
servidor Java;
mensageria;
z/OS Connect;
CICS;
programa COBOL;
Db2.
O COBOL pode continuar sendo o coração da regra de negócio, mas sua operação está conectada a um ecossistema híbrido.
O profissional que conhece apenas o programa vê uma sala.
O profissional que conhece automação vê a nave inteira.
Aprender Ansible ajuda o Programador COBOL a:
compreender DevOps;
participar de pipelines;
automatizar tarefas repetitivas;
reduzir erros;
dialogar com equipes Linux;
integrar IBM Z a ambientes distribuídos;
transformar procedimentos em código;
documentar operações;
colaborar com arquitetos;
modernizar sem destruir o legado.
Não se trata de abandonar COBOL.
Trata-se de colocar o COBOL dentro de uma estratégia de engenharia contemporânea.
39. A mensagem escondida no console
Existe um easter egg nesta jornada.
O verdadeiro tema deste artigo nunca foi apenas Ansible.
Foi repetibilidade.
Um programa confiável produz resultados previsíveis.
Um job confiável pode ser reiniciado.
Uma transação confiável preserva consistência.
Uma automação confiável conduz o ambiente até um estado conhecido.
COBOL e Ansible nasceram em épocas diferentes, mas compartilham um valor fundamental:
sistemas empresariais precisam ser compreensíveis, controláveis e previsíveis.
O COBOL organiza regras de negócio.
O JCL organiza processamento batch.
O Ansible organiza operações e infraestrutura.
Eles não são inimigos de gerações diferentes.
São oficiais de departamentos diferentes servindo na mesma nave.
Conclusão — O Padawan assume o console
Você não precisa comprar uma licença especial nem construir um data center para começar.
Com um computador Windows 11, WSL 2, Ubuntu e algumas horas de prática, já é possível montar um excelente laboratório de Ansible.
Comece pequeno:
localhost
Depois instale:
Apache
Em seguida:
Java
Aprenda:
Inventários
Playbooks
Módulos
Variáveis
Handlers
Templates
Roles
Vault
Git
Só então avance para:
WebSphere
Linux remoto
Pipelines
IBM Z
z/OS
Ambientes híbridos
Não tente automatizar toda a galáxia no primeiro Playbook.
Automatize uma tarefa.
Teste.
Execute novamente.
Observe a idempotência.
Documente.
Versione.
Melhore.
Depois automatize a próxima.
O futuro do mainframe não será construído apenas por quem conhece tecnologias novas, nem apenas por quem conhece tecnologias antigas.
Será construído por profissionais capazes de fazer essas tecnologias trabalharem juntas.
E quando alguém perguntar:
“Um Programador COBOL realmente precisa aprender Ansible?”
Você poderá responder:
“Não preciso aprender para abandonar o mainframe. Preciso aprender para comandar tudo o que existe ao redor dele.”
Esse é o caminho do Programador COBOL Padawan.
Do terminal 3270 ao YAML.
Do JCL ao Playbook.
Do batch noturno à automação contínua.
Do porão da sala de máquinas à cadeira de comando.
Vida longa ao COBOL. Vida longa à automação. E que nenhum deployment seja realizado manualmente numa sexta-feira à noite.
