 |
| Bellacosa Mainframe do cobol ao container |
☕ Um café no Bellacosa Mainframe
Do COBOL ao Container sem cair do Sysplex
zCX, Kubernetes/OpenShift e Ansible para IBM Z e LinuxONE — fundamentos para quem conhece muito bem o mainframe, mas resolveu atravessar a fronteira do mundo cloud-native
Imagine a cena.
Você passou décadas aprendendo que produção não é playground.
Conhece JOB, STEP, DD, PROC, catalogação, RACF, CICS, Db2, JES2, SDSF, WLM, Sysplex, datasets, USS e provavelmente consegue desconfiar de um S0C7 antes mesmo de alguém terminar de explicar o incidente.
Então chega alguém e diz:
“Agora vamos colocar a aplicação num container, subir num pod, criar um deployment, colocar num cluster Kubernetes, rodar no OpenShift e automatizar tudo com Ansible.”
O COBOLzeiro olha.
Olha novamente.
E pergunta:
“Mas onde está o JCL?”
É justamente aí que começa esta viagem.
CAPÍTULO 1 — IBM z/OS Container Extensions — zCX
Quando colocaram Linux dentro do z/OS e ninguém precisou pedir desculpas ao JES
1. O que diabos é zCX?
IBM z/OS Container Extensions, normalmente chamado simplesmente de zCX, é uma tecnologia que permite executar aplicações Linux empacotadas em containers dentro de um ambiente hospedado pelo próprio z/OS.
A IBM introduziu zCX como recurso do z/OS 2.4, lançado em 2019. A ideia era permitir que software originalmente construído para Linux on Z pudesse trabalhar muito próximo das aplicações tradicionais do z/OS sem obrigatoriamente exigir o provisionamento de uma LPAR Linux separada.
Isso merece ser repetido porque é justamente onde muitos mainframers erram:
zCX não transforma z/OS em Linux.
E:
um container Linux executado em zCX continua sendo um container Linux.
O que acontece é mais interessante.
O z/OS fornece uma infraestrutura especializada dentro da qual existe um ambiente Linux preparado para executar containers.
A IBM descreve cada instância zCX como uma instância executada em um address space do z/OS, representando um servidor virtual capaz de hospedar aplicações containerizadas.
Para um COBOLzeiro, podemos começar com esta representação mental:
IBM Z
│
├── LPAR z/OS
│ │
│ ├── JES2
│ ├── CICS
│ ├── Db2
│ ├── IMS
│ ├── USS
│ │
│ └── zCX
│ │
│ └── Linux
│ │
│ ├── Container A
│ ├── Container B
│ └── Container C
│
└── outras LPARs
Não é tecnicamente uma descrição completa da implementação, mas é uma excelente primeira fotografia mental.
2. Antes de zCX: por que alguém precisaria disso?
Suponha que uma aplicação COBOL execute no CICS e precise chamar um componente escrito em Java, Go, Python ou Node.js.
Tradicionalmente você poderia ter:
CICS
|
TCP/IP
|
Firewall / switch / network
|
Servidor Linux
|
Aplicação
Nada errado.
Milhares de arquiteturas funcionam assim.
Mas existe um problema interessante chamado distância computacional.
Quanto mais longe você coloca um componente dos dados e das transações:
mais rede;
mais latência;
mais infraestrutura;
mais administração;
mais pontos de falha;
mais segurança;
mais troubleshooting.
O zCX apresenta outra possibilidade:
COBOL / CICS / Db2
|
|
z/OS
|
zCX
|
Container Linux
Você aproxima determinado software Linux do universo z/OS.
Essa é uma das ideias fundamentais da modernização do mainframe:
modernizar não significa necessariamente retirar o processamento do mainframe.
Às vezes modernizar significa trazer o componente moderno até onde os dados já estão.
3. A analogia para quem conhece CICS
Imagine um programador COBOL perguntando:
“Container é um address space?”
Não.
Mas existe uma analogia útil.
Um programa COBOL executando sob CICS não precisa carregar consigo:
sistema operacional;
scheduler;
TCP/IP;
dispositivos;
gerenciamento de memória completo;
infraestrutura de segurança do sistema.
O ambiente fornece tudo isso.
Containers seguem parcialmente essa filosofia:
Aplicação
+
bibliotecas
+
dependências
+
configuração
são empacotadas como uma unidade reproduzível.
O container utiliza serviços fornecidos pelo sistema onde é executado.
A grande diferença é que containerização foi construída para tornar aplicações portáveis e reproduzíveis.
O mantra é:
“Funcionou neste ambiente? O mesmo artefato deverá funcionar naquele.”
Não significa que toda aplicação seja magicamente portátil entre arquiteturas de processador.
Aqui aparece uma palavra fundamental para IBM Z:
s390x
Containers executados no IBM Z normalmente precisam possuir imagens compatíveis com arquitetura s390x.
Um container compilado exclusivamente para x86_64 não ganha poderes mágicos ao atravessar a porta do mainframe.
4. Easter egg nº 1 — container não é máquina virtual
Essa confusão é tão comum que vale tatuar no monitor.
Uma VM normalmente possui:
Hardware
└─ Hypervisor
├─ VM
│ ├─ Kernel
│ └─ Aplicações
└─ VM
├─ Kernel
└─ Aplicações
Containers normalmente compartilham recursos do sistema operacional subjacente:
Sistema operacional
└─ Runtime de containers
├─ Container
├─ Container
└─ Container
zCX adiciona uma camada interessante porque oferece o ambiente Linux necessário para esses containers dentro do universo operacional do z/OS.
Portanto:
container ≠ VM
zCX ≠ uma simples VM Linux comum
zCX ≠ Docker instalado diretamente no kernel do z/OS
Esta última distinção é importantíssima.
5. O z/OS virou Docker?
Não.
Historicamente zCX forneceu um ambiente Linux voltado à execução de aplicações gerenciadas como containers Docker. A própria documentação IBM descreve zCX dessa forma.
Mas o ecossistema atual ficou mais interessante.
Hoje a IBM documenta separadamente:
z/OS Container Extensions — zCX
zCX for OpenShift
IBM z/OS Container Platform
E isso pode confundir até profissional experiente.
A IBM inclusive diferencia explicitamente as opções modernas de containerização:
Red Hat OpenShift em Linux x86 ou Linux s390x;
zCX com Linux s390x sobre z/OS;
IBM z/OS Container Platform com containers nativos do z/OS.
Portanto nunca use “container no mainframe” como se fosse uma arquitetura única.
Pergunte:
Container onde?
6. As quatro fronteiras que o COBOLzeiro precisa enxergar
Fronteira A — z/OS
Aqui vivem:
COBOL
PL/I
Assembler
CICS
IMS
Db2
VSAM
JES2
RACF
USS
MQ
z/OS Connect
É o mundo transacional tradicional.
Fronteira B — zCX
Está associado ao z/OS, mas fornece execução Linux/containerizada.
Visualize:
z/OS
|
+---- traditional workloads
|
+---- zCX
|
Linux container workload
Fronteira C — Linux on IBM Z
Agora temos Linux executando como sistema operacional sobre IBM Z.
Por exemplo:
IBM Z
|
LPAR
|
Linux
|
OpenShift
Aqui não estamos dentro do z/OS.
Estamos usando a arquitetura IBM Z para executar Linux.
Essa distinção parece óbvia depois que você entende.
Antes disso ela destrói metade dos diagramas PowerPoint corporativos.
Fronteira D — LinuxONE
LinuxONE é uma família IBM criada especificamente para workloads Linux.
A IBM introduziu LinuxONE em agosto de 2015.
Conceitualmente:
IBM Z
→ z/OS + Linux
LinuxONE
→ Linux
É uma simplificação proposital, mas excelente para começar.
LinuxONE utiliza tecnologia derivada da plataforma IBM Z, porém é posicionado para ambientes Linux e cloud.
Em 2026, a família atual inclui IBM LinuxONE 5, baseada no Telum II.
7. Para que zCX serve?
Pense principalmente em aplicações que precisam:
executar software Linux próximo do z/OS
Um serviço auxiliar pode ficar muito próximo das aplicações e dados tradicionais.
modernizar sem mover os sistemas de registro
Você mantém:
CICS
Db2
IMS
COBOL
e adiciona:
API
microservice
middleware
agent
software Linux
reduzir infraestrutura separada em certos casos
Nem todo componente precisa necessariamente de outra LPAR Linux.
construir pontes entre gerações
Exemplo conceitual:
Aplicativo Web
|
v
API
|
z/OS Connect
|
COBOL/CICS
|
Db2
Alguns componentes auxiliares podem executar próximos ao backend, inclusive utilizando tecnologias Linux.
8. O que NÃO colocar automaticamente no zCX?
Aqui começa a arquitetura de verdade.
Não olhe para zCX e pense:
“Excelente, vamos meter tudo dentro.”
Não.
Pergunte:
A imagem existe para s390x?
O fornecedor certifica essa plataforma?
Qual o consumo de CPU?
Qual o consumo de memória?
Qual a latência necessária?
Há dependência com hardware específico?
A aplicação precisa de Kubernetes?
Existe necessidade de autoscaling?
O workload é stateful?
Quem operará o ambiente?
Containerização não elimina decisões arquiteturais.
Ela apenas muda o lugar onde você cometerá os erros.
9. zCX versus OpenShift
Talvez essa seja a pergunta mais importante deste capítulo.
zCX
Pense:
“Preciso executar containers Linux próximos ao z/OS.”
OpenShift
Pense:
“Preciso administrar aplicações containerizadas distribuídas como uma plataforma.”
OpenShift resolve um problema muito maior.
Ele pensa em:
clusters
nodes
pods
services
deployments
replicas
operators
storage
networking
security
upgrades
observability
lifecycle
A IBM também oferece e documenta arquitetura de referência para Red Hat OpenShift Container Platform sobre IBM Z e LinuxONE.
Além disso, existe zCX Foundation for Red Hat OpenShift, portanto a fronteira não deve ser reduzida à ideia “zCX jamais tem OpenShift”. A própria instrumentação moderna do z/OS diferencia instâncias zCX for Containers, zCX for OpenShift e a appliance relacionada ao z/OS Container Platform.
Isso demonstra como o ecossistema evoluiu desde o zCX original de 2019.
10. Passo a passo mental do zCX
Para começar os estudos, não tente instalar nada ainda.
Primeiro memorize esta sequência:
Passo 1 — existe IBM Z
Hardware.
Passo 2 — existe uma LPAR z/OS
Sistema operacional.
Passo 3 — zCX é provisionado dentro desse universo
O z/OS administra sua existência operacional.
Passo 4 — surge um ambiente Linux
Ele fornece o ambiente necessário para software Linux.
Passo 5 — containers executam ali
As imagens precisam ser adequadas à arquitetura.
Passo 6 — networking conecta os mundos
Container precisa conversar com:
CICS
Db2
IMS
MQ
APIs
Internet
outros servidores
É justamente por isso que networking se torna disciplina central.
A documentação IBM dedica uma seção específica à arquitetura de rede do zCX.
11. Easter egg nº 2 — USS não é zCX
Outro erro maravilhoso.
“Mas z/OS já tinha Unix System Services. Para que Linux?”
Porque:
USS ≠ Linux
USS fornece ambiente POSIX dentro do z/OS.
Linux é outro sistema operacional.
Você pode ter:
z/OS
├─ MVS
├─ USS
└─ zCX
└─ Linux
Um shell parece um shell.
ls parece ls.
Isso não transforma os ambientes na mesma coisa.
É como encontrar duas pessoas usando boina e concluir que ambas são francesas.
12. Onde o COBOL entra nessa história?
Em todo lugar.
O erro de marketing é mostrar containers como substitutos para COBOL.
Na prática muitas arquiteturas modernas são:
Mobile
|
API Gateway
|
Microservices
|
Kafka / MQ
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
O container frequentemente não substitui o sistema transacional.
Ele amplia o ecossistema em volta dele.
Esta é uma das ideias mais importantes para o mainframer moderno:
mainframe modernization não significa obrigatoriamente mainframe migration.
13. Checklist do Padawan zCX
Antes de avançar, você deveria conseguir responder:
O que é zCX?
Em qual release do z/OS apareceu?
Por que zCX possui Linux?
Qual a diferença entre USS e Linux?
O que significa s390x?
Container é VM?
Qual a diferença entre Linux on Z e z/OS?
LinuxONE executa z/OS?
Onde OpenShift entra?
Por que latência e proximidade de dados importam?
Se essas respostas estiverem claras, você ganhou seu primeiro sabre de luz containerizado.
CAPÍTULO 2 — Kubernetes e Red Hat OpenShift Container Platform
Quando alguém percebeu que administrar 3 containers era divertido e 30.000 era um pesadelo
Imagine que você tenha um container.
Tudo lindo.
docker run minha-app
Ele funciona.
Agora o gerente pergunta:
“E se cair?”
Você reinicia.
“E se precisarmos de dez?”
Você inicia dez.
“E se uma máquina morrer?”
Você transfere.
“E se precisarmos atualizar sem parar?”
Você começa a suar.
“E se tivermos 6.000 containers em 400 máquinas?”
Nesse momento nasceu a necessidade conceitual do Kubernetes.
14. Kubernetes: o JES2 dos containers?
A comparação não é perfeita.
Mas para um mainframer ela é deliciosa.
Você não entrega cada batch diretamente ao processador.
Você submete trabalho e deixa toda uma infraestrutura decidir como executá-lo.
Kubernetes faz algo filosoficamente semelhante para aplicações containerizadas.
Você declara:
“Quero três instâncias desta aplicação funcionando.”
Kubernetes tenta manter esse estado.
Isso é chamado de:
Desired State
Você não descreve cada pequena operação.
Você declara o estado esperado.
Por exemplo:
replicas: 3
Quer dizer conceitualmente:
“Kubernetes, mantenha três cópias funcionando.”
Se uma morrer:
Esperado: 3
Real: 2
O sistema tenta reconciliar:
Real → 3
Isso é reconciliation.
Um mainframer pode pensar:
“Então existe uma espécie de automação permanentemente verificando se o estado real corresponde ao planejado?”
Exatamente.
15. Quando Kubernetes apareceu?
O projeto Kubernetes nasceu no Google e foi aberto publicamente em 2014.
A versão Kubernetes 1.0 foi lançada em 21 de julho de 2015, quando o projeto também passou para a recém-formada Cloud Native Computing Foundation.
O DNA veio de experiências anteriores do Google administrando enormes quantidades de workloads containerizados.
E aqui temos uma curiosidade histórica maravilhosa:
“kubernetes” vem do grego e significa aproximadamente:
timoneiro / piloto.
Por isso o símbolo do Kubernetes é um timão.
K8s?
São oito letras entre:
K
ubernete
s
K + 8 letras + S.
Assim nasceu K8s.
Um legítimo Easter egg nerd.
16. O que Kubernetes administra?
Pense nesta hierarquia simplificada:
Cluster
|
+--- Node
| |
| +--- Pod
| |
| +--- Container
|
+--- Node
|
+--- Pod
|
+--- Container
Agora traduziremos.
Cluster
O conjunto total administrado.
Node
Uma máquina participante.
Pode ser física ou virtual dependendo da arquitetura.
Pod
A menor unidade normalmente programada pelo Kubernetes.
Um pod pode conter um ou mais containers que precisam compartilhar contexto de execução.
Container
Sua aplicação empacotada.
17. Easter egg nº 3 — Kubernetes não agenda containers diretamente
Muita apresentação diz:
“Kubernetes agenda containers.”
Tecnicamente, a unidade fundamental de scheduling é o:
Pod.
Por isso o modelo mental correto é:
Kubernetes
↓
Pod
↓
Container
Parece preciosismo.
Até você precisar diagnosticar produção.
18. Deployment
Agora aparece algo que qualquer mainframer reconhecerá filosoficamente.
Você não quer dizer:
“Execute exatamente este processo.”
Você quer declarar:
“Esta aplicação deve existir desta maneira.”
Deployment especifica coisas como:
imagem
número de réplicas
estratégia de atualização
configuração
Por exemplo:
replicas: 3
O Kubernetes criará recursos para atingir esse estado.
19. Service
Pods podem morrer e renascer.
Endereços podem mudar.
Se outro sistema dependesse diretamente de cada pod, seria caos.
Service cria uma abstração de acesso.
Mentalmente:
Cliente
|
Service
|
+--+--+
| | |
Pod Pod Pod
O Service oferece um ponto lógico estável.
Mainframer lendo isso provavelmente pensa:
“VIPA?”
Não é a mesma implementação, mas a analogia ajuda.
Uma identidade lógica desacopla o cliente da instância física específica.
20. ConfigMap e Secret
Você não quer colocar dentro da imagem:
hostname
URL
configuração ambiental
senha
token
certificado
ConfigMaps guardam configuração não secreta.
Secrets representam informações sensíveis.
A filosofia é separar:
APPLICATION
+
CONFIGURATION
Isso lembra práticas antigas do mainframe.
COBOL experiente sempre soube que hardcode de ambiente é receita para desastre.
O cloud-native apenas redescobriu a pólvora usando YAML.
21. O que é OpenShift?
Agora chegamos ao ponto crucial.
OpenShift não é simplesmente outro Kubernetes concorrente.
O Red Hat OpenShift Container Platform é uma plataforma empresarial construída sobre Kubernetes e Red Hat Enterprise Linux, adicionando componentes, processos de instalação, lifecycle management, segurança, ferramentas para desenvolvedores e recursos operacionais.
Uma simplificação:
Kubernetes
+
RHEL / CoreOS
+
security
+
registry/integration
+
operators
+
developer tooling
+
networking
+
observability
+
enterprise lifecycle
=
OpenShift
Não é uma fórmula literal.
É um mapa mental.
22. Quando OpenShift nasceu?
Aqui existe um pequeno detalhe histórico interessante.
OpenShift apareceu originalmente em 2011 como plataforma PaaS da Red Hat.
O OpenShift 1.0 foi lançado em 2012.
Então Kubernetes apareceu.
A Red Hat decidiu padronizar OpenShift sobre Kubernetes em 2014, culminando no OpenShift 3.0 em junho de 2015, já baseado em Kubernetes.
Isso explica algo que confunde iniciantes:
OpenShift é mais antigo que Kubernetes, mas o OpenShift moderno utiliza Kubernetes como fundação.
23. Kubernetes versus OpenShift para o COBOLzeiro
Imagine:
Kubernetes
Motor.
OpenShift
Carro completo.
O motor é fundamental.
Mas você também precisa:
painel
freio
cinto
direção
controle
instrumentação
manutenção
documentação
Outra analogia:
Kubernetes ≈ kernel + mecanismos de orquestração
OpenShift ≈ plataforma operacional Kubernetes empresarial
Também é simplificada, mas útil.
24. IBM Z entra onde?
OpenShift pode executar sobre Linux na arquitetura IBM Z.
A IBM e a Red Hat mantêm documentação específica para OpenShift Container Platform sobre IBM Z e IBM LinuxONE, incluindo arquiteturas de referência, sizing e performance.
Arquitetura conceitual:
IBM Z
|
+--- LPAR Linux
| |
| +--- OpenShift Node
|
+--- LPAR Linux
| |
| +--- OpenShift Node
|
+--- LPAR z/OS
|
+--- CICS
+--- IMS
+--- Db2
+--- COBOL
Observe a beleza disso.
Você pode ter OpenShift e z/OS extremamente próximos fisicamente.
25. E LinuxONE?
LinuxONE foi construído especificamente para Linux.
Portanto:
LinuxONE
|
Linux
|
OpenShift
|
Kubernetes
|
Pods
|
Containers
é uma combinação natural.
A IBM documenta explicitamente OpenShift sobre ambos, IBM Z e LinuxONE.
Agora surge uma arquitetura interessante:
ENTERPRISE
|
Red Hat OpenShift
|
+-------------+-------------+
| |
LinuxONE IBM Z
| |
Linux workloads z/OS
|
+-------+-------+
| | |
CICS IMS Db2
|
COBOL
Isso é hybrid cloud sem precisar imaginar que “cloud” obrigatoriamente significa AWS.
26. O grande conceito: Hybrid Cloud
Cloud não é simplesmente:
“computador de outra pessoa.”
Essa piada é boa, mas incompleta.
O conceito moderno envolve:
automação
elasticidade
APIs
self-service
orquestração
padronização
infraestrutura declarativa
Você pode aplicar vários desses princípios on-premises.
Por isso OpenShift é tão importante para IBM Z.
Ele cria uma camada operacional padronizada que pode existir:
datacenter
IBM Z
LinuxONE
x86
public cloud
edge
O objetivo é diminuir diferenças operacionais para aplicações.
27. Mas meu COBOL vai rodar dentro do Kubernetes?
Talvez.
Mas essa não é a pergunta certa.
A pergunta correta é:
qual componente deveria executar onde?
Talvez:
COBOL → CICS
Db2 → z/OS
API → z/OS Connect
Kafka connector → OpenShift
Frontend → OpenShift
AI service → OpenShift
Batch → z/OS
Arquitetura híbrida madura não é religião.
É engenharia.
28. OpenShift não substitui z/OS
Isso merece um letreiro luminoso.
OpenShift resolve problemas diferentes.
z/OS oferece qualidades extraordinárias para:
transaction processing
workload management
security
availability
data integrity
batch processing
high-volume I/O
OpenShift oferece uma plataforma fantástica para:
cloud-native apps
microservices
containers
CI/CD
declarative deployments
horizontal scaling
operators
DevSecOps
Junte as duas coisas.
Não transforme arquitetura em Fla-Flu.
29. Easter egg nº 4 — COBOL já conhecia “orquestração”
Quando alguém disser:
“Orquestração é um conceito totalmente novo da cloud.”
O mainframer pode sorrir silenciosamente.
Porque há décadas você possui:
JES
WLM
Schedulers
Automation
Sysplex
GDG
catalogação
resource management
Claro que não são Kubernetes.
Mas o problema fundamental:
“Como coordenar enormes quantidades de trabalho em infraestrutura compartilhada?”
é muito mais antigo que Kubernetes.
Cloud-native não inventou gerenciamento de workloads.
Criou novas abstrações para um novo modelo de aplicações.
30. O primeiro laboratório mental
Pegue uma aplicação:
bellacosa-api
Imagem:
bellacosa-api:v1
Crie um deployment:
Deployment
replicas = 3
Kubernetes cria:
Pod 1 → bellacosa-api:v1
Pod 2 → bellacosa-api:v1
Pod 3 → bellacosa-api:v1
Um pod morre:
Pod 1
Pod 2
X
Kubernetes observa:
Desejado = 3
Atual = 2
Cria outro:
Pod 1
Pod 2
Pod 4
Agora você entendeu talvez 30% da filosofia Kubernetes.
E esses 30% valem mais que decorar cinquenta comandos kubectl.
31. Próximo passo: Service
Service
|
+--------+--------+
| | |
Pod Pod Pod
Usuário não precisa saber qual pod respondeu.
Isso permite escalabilidade e substituição dinâmica.
32. Próximo passo: atualização
Versão atual:
v1
v1
v1
Queremos:
v2
v2
v2
Um deployment pode realizar atualização gradual:
v1 v1 v1
v1 v1 v2
v1 v2 v2
v2 v2 v2
Esse é o famoso:
rolling update.
Mainframer imediatamente enxerga o valor:
reduzir indisponibilidade durante deploy.
33. Operators — quando Kubernetes aprende procedimentos
Operator é um conceito extremamente interessante para sysprogs.
Imagine transformar conhecimento operacional em software.
Algo como:
se condição A:
faça B
se B falhar:
execute C
para upgrade:
valide D
migre E
reinicie F
Operators codificam conhecimento operacional especializado usando os mecanismos de controle do Kubernetes.
Para quem passou anos carregando procedimentos em runbooks ou na cabeça do sysprog João que “não pode tirar férias porque só ele sabe reiniciar aquilo”, Operators são quase poesia.
34. O que aprender primeiro?
Não comece por OpenShift inteiro.
Comece nesta ordem:
1. container
2. image
3. registry
4. pod
5. node
6. cluster
7. deployment
8. replica
9. service
10. configmap
11. secret
12. persistent volume
13. namespace
14. ingress/route
15. operator
Depois:
security
network
storage
monitoring
autoscaling
CI/CD
GitOps
Se tentar aprender tudo simultaneamente, Kubernetes parece manual de SMP/E traduzido para klingon.
CAPÍTULO 3 — Ansible for IBM Z and LinuxONE Foundations
Finalmente alguém resolveu automatizar o mainframe sem obrigar o COBOLzeiro a escrever 14 mil linhas de shell
Imagine a rotina:
segunda-feira:
crie dataset
copie membro
altere configuração
reinicie started task
verifique resultado
terça-feira:
mesma coisa.
quarta-feira:
mesma coisa em outro sistema.
quinta-feira:
alguém esqueceu o passo quatro.
sexta-feira:
War Room.
Ansible existe para transformar procedimentos repetíveis em automação declarativa.
35. O que é Ansible?
Ansible é uma tecnologia de automação de TI capaz de executar:
provisionamento;
gerenciamento de configuração;
deployment;
orquestração;
tarefas administrativas;
automação de infraestrutura.
A própria Red Hat resume Ansible como um motor open source para automação de provisionamento, configuração, deployment e outros processos de TI.
Historicamente a Red Hat descrevia Ansible como uma ferramenta lançada no começo de 2013; a Red Hat anunciou sua aquisição em outubro de 2015.
O projeto possui raízes anteriores em desenvolvimento comunitário, mas 2013 é uma referência histórica segura para o lançamento da ferramenta conforme a própria Red Hat.
36. Por que Ansible ficou popular?
Uma palavra:
simplicidade.
Ou pelo menos simplicidade relativa.
Você escreve automações normalmente em YAML.
Exemplo conceitual:
- name: Criar dataset
...
Em vez de escrever uma solução enorme baseada em agentes proprietários distribuídos.
Outro princípio famoso do Ansible:
agentless
Na arquitetura tradicional, o sistema gerenciado não precisa de um daemon Ansible permanentemente instalado esperando comandos.
Normalmente o controlador conecta-se aos alvos através de mecanismos existentes como SSH.
No universo z/OS isso é particularmente interessante porque você evita introduzir mais um agente residente simplesmente para automatizar tarefas.
37. COBOLzeiro pergunta: Ansible substitui JCL?
Não.
Ansible pode:
submeter JCL
copiar JCL
alterar membro
criar dataset
executar comandos
consultar resultados
Mas JCL continua sendo a linguagem de controle de jobs do z/OS.
Pense assim:
Ansible
|
+---- preparar ambiente
|
+---- copiar artefatos
|
+---- submeter JCL
|
+---- verificar resultado
Ou seja:
Ansible pode orquestrar o JCL.
Não precisa substituí-lo.
38. A arquitetura fundamental
CONTROL NODE
Ansible
|
|
SSH
|
+--------+--------+
| |
Linux z/OS
| |
server USS / services
O controlador Ansible normalmente executa em ambiente Linux.
A partir dele você administra nós.
No ecossistema IBM existem conteúdos certificados específicos para z/OS.
A IBM disponibiliza o Red Hat Ansible Certified Content for IBM Z, justamente para integrar IBM Z à estratégia corporativa de automação.
39. O grande personagem: ibm_zos_core
Guarde este nome:
ibm.ibm_zos_core
É a collection fundamental para automação z/OS com Ansible.
A própria documentação IBM usa a instalação:
ansible-galaxy collection install ibm.ibm_zos_core
e demonstra conexão a z/OS por SSH.
Uma collection é basicamente uma coleção organizada de conteúdo Ansible:
modules
plugins
roles
documentação
Então você ganha operações projetadas especificamente para z/OS.
40. Module
Module é uma unidade funcional Ansible.
Pense:
zos_data_set
zos_copy
zos_job_submit
zos_job_query
zos_operator
...
Cada módulo resolve uma classe de tarefa.
Isso muda completamente a forma de automação.
Em vez de:
ssh
executa shell
parse output
espera string
faz sed
reza
você usa uma abstração que conhece o recurso z/OS.
41. Playbook
Playbook é onde você descreve o workflow.
Algo conceitualmente assim:
- name: Deploy Bellacosa
hosts: zos
tasks:
- criar dataset
- copiar programa
- submeter compile
- verificar RC
- copiar load module
- atualizar ambiente
Para o mainframer:
Playbook é quase um PROC de automação corporativa turbinado.
Não tecnicamente.
Mas mentalmente funciona.
42. Inventory
Ansible precisa saber quem administra.
Inventory pode representar:
DEV
TEST
QA
PROD
ou:
LPAR1
LPAR2
LPAR3
Exemplo conceitual:
[development]
zosdev01
[production]
zosprd01
zosprd02
A automação pode ser a mesma.
As variáveis mudam.
Isso reduz aquele câncer operacional conhecido como:
deploy_dev_final_v2_corrigido.sh
deploy_hml_final_agora_vai.sh
deploy_prod_NAO_MEXER.sh
43. Idempotência — uma palavra estranha que o mainframe entende há décadas
Esse é um dos conceitos mais importantes de Ansible.
Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indesejados quando o estado desejado já foi alcançado.
Você declara:
“Este recurso deve existir.”
Ansible verifica.
Se existe corretamente:
OK
Se não:
CHANGE
Isso é muito diferente de scripts burros:
crie
crie novamente
erro
continua
quebra
Exemplo mental:
state: present
Você não está dizendo:
“Execute CREATE.”
Está dizendo:
“Garanta que exista.”
Percebe a proximidade filosófica com Kubernetes?
Ansible:
estado desejado
Kubernetes:
estado desejado
Essa filosofia declarativa é uma das pontes fundamentais entre infraestrutura tradicional e cloud-native.
44. Easter egg nº 5 — YAML não é linguagem de programação tradicional
YAML é um formato de representação de dados.
Ele parece amigável:
name: Bellacosa
language: COBOL
platform: zOS
Até você errar dois espaços.
Então ele vira:
Yet Another Mainframe Lament.
O nome oficial originalmente brincava com “Yet Another Markup Language”, mas hoje YAML é recursivamente apresentado como:
YAML Ain't Markup Language.
Sim.
Programadores também fazem piadas ruins.
45. O z/OS precisa de Python?
Para várias automações da collection IBM, existe infraestrutura Python no lado z/OS.
A documentação atual da IBM especifica versões compatíveis do IBM Open Enterprise SDK for Python de acordo com as versões da collection ibm_zos_core.
Isso é outra mudança cultural fascinante.
O mainframe moderno não é:
COBOL + JCL
Hoje o ecossistema contém também:
Python
Java
Node.js
Go
Ansible
REST
Git
VS Code
containers
sem remover COBOL, CICS, IMS e Db2.
É expansão, não apagamento.
46. Ansible e datasets
Agora começamos a falar a língua do mainframer.
Uma automação pode lidar com recursos como:
PS
PDS
PDSE
members
USS files
jobs
operator commands
Imagine automatizar:
1. criar HLQ.BELLACOSA.LOAD
2. criar HLQ.BELLACOSA.JCL
3. copiar membros
4. compilar
5. conferir MAXCC
6. promover
Tudo registrado em Git.
Agora você começa a compreender por que Ansible interessa ao mundo DevOps mainframe.
47. Infrastructure as Code
Aqui temos outra expressão da moda que na verdade contém uma ideia poderosa.
Em vez de infraestrutura existir apenas porque alguém executou comandos manualmente em 2017 e ninguém lembra quais:
você descreve configuração em arquivos versionados.
Git
|
+-- inventories
+-- playbooks
+-- roles
+-- variables
Você ganha:
histórico
diff
peer review
rollback lógico
auditoria
repetibilidade
Mainframer que conhece ChangeMan, Endevor, ISPW ou Librarian deve sentir imediatamente o cheiro do conceito.
Nós sempre soubemos que:
mudança sem histórico é pedir para conhecer o plantão das três da manhã.
48. Ansible no LinuxONE
Agora trocamos o alvo.
LinuxONE executa Linux.
Ansible é extremamente natural nesse ambiente.
Você pode automatizar:
RHEL
pacotes
services
networking
storage
users
OpenShift
middleware
bancos
security
Inclusive a própria plataforma Ansible Automation Platform pode ser implementada sobre IBM Z e LinuxONE com RHEL; a IBM possui orientação específica para esse cenário.
Portanto:
Ansible
|
+--- z/OS
|
+--- Linux on Z
|
+--- LinuxONE
|
+--- x86
|
+--- cloud
|
+--- network
Esse é o verdadeiro poder.
Uma linguagem operacional comum atravessando silos.
49. E OpenShift?
Aqui a coisa fica muito interessante.
Ansible pode automatizar infraestrutura.
OpenShift orquestra containers.
Você pode ter:
Ansible Automation Platform
|
+---- Linux
|
+---- IBM Z
|
+---- z/OS
|
+---- OpenShift
Isso cria uma camada corporativa de automação.
Imagine um workflow:
1. preparar z/OS
2. criar recursos
3. instalar configuração
4. atualizar aplicação OpenShift
5. testar API
6. validar CICS
7. conferir Db2
Uma mudança pode atravessar tecnologias anteriormente administradas por equipes completamente distintas.
50. O cenário Bellacosa Bank
Vamos juntar os três capítulos.
Temos:
INTERNET
|
API GATEWAY
|
OPENSHIFT
|
+--------------+--------------+
| |
Microservice A Microservice B
| |
+--------------+--------------+
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
Em outro canto:
z/OS
|
zCX
|
Linux container
|
serviço auxiliar
E comandando operações:
ANSIBLE
|
+----------+----------+
| | |
z/OS Linux OpenShift
Agora finalmente conseguimos enxergar os três tópicos da imagem como uma única arquitetura.
51. A fronteira definitiva
Este mapa deveria ficar na parede:
IBM Z HARDWARE
|
+-------------------+-------------------+
| |
z/OS Linux
| |
+--------+--------+ OpenShift
| | | |
CICS IMS Db2 Kubernetes
| |
COBOL Pods
| |
+-- zCX Containers
|
Linux
|
Containers
E separadamente:
IBM LinuxONE
|
Linux
|
OpenShift
|
Kubernetes
|
Pods
|
Containers
Finalmente:
Ansible
|
+--------------+--------------+
| | |
z/OS Linux OpenShift
Pronto.
Agora acabou a sopa de letrinhas.
52. As diferenças que você NÃO pode confundir
z/OS
Sistema operacional principal da plataforma IBM Z.
USS
Ambiente UNIX/POSIX do z/OS.
Linux on Z
Linux executando na arquitetura IBM Z.
zCX
Tecnologia do z/OS para hospedar workloads Linux containerizados próximos do ambiente z/OS.
LinuxONE
Plataforma IBM voltada a Linux.
Kubernetes
Orquestrador de aplicações containerizadas.
OpenShift
Plataforma empresarial Kubernetes da Red Hat.
Ansible
Automação de infraestrutura e aplicações.
Essas oito definições resolvem talvez 70% das confusões iniciais.
53. O que um programador COBOL deveria estudar primeiro?
Minha trilha seria:
Fase 1 — Linux básico
Aprenda:
filesystem
process
permissions
SSH
environment variables
TCP/IP
packages
systemd
shell
Não precisa virar sysadmin Linux.
Precisa deixar de considerar /etc território inimigo.
Fase 2 — containers
Aprenda:
image
container
registry
Dockerfile/Containerfile
volume
port
environment variable
Faça manualmente.
Suba uma aplicação.
Mate.
Suba novamente.
Fase 3 — Kubernetes
Aprenda:
Pod
Deployment
ReplicaSet
Service
Namespace
ConfigMap
Secret
PersistentVolume
Não comece por Operators.
Não comece por service mesh.
Não comece por Istio.
Não comece por 73 certificações.
Fase 4 — OpenShift
Só depois.
Entenda:
oc
projects
routes
operators
builds
security
cluster administration
Fase 5 — IBM Z integration
Volte para casa:
z/OS Connect
MQ
CICS
Db2
IMS
zCX
Linux on Z
Agora você perceberá que não abandonou o mainframe.
Você apenas aumentou o mapa.
Fase 6 — Ansible
Automatize coisas que você já sabe fazer manualmente.
Regra fundamental:
nunca automatize aquilo que você ainda não entende.
Primeiro:
criar dataset manualmente
Depois:
automatizar dataset
Primeiro:
submeter job
Depois:
automatizar job
Primeiro:
deploy manual
Depois:
playbook
Essa sequência transforma Ansible em ferramenta.
Fazer o contrário transforma Ansible em gerador industrial de incidentes.
54. O primeiro exercício Ansible mental
Desejo:
“Quero que o dataset
USER.BELLACOSA.TESTexista.”
Estado atual:
não existe
Playbook:
desired state = present
Resultado:
dataset criado
Execute novamente.
Estado atual:
já existe
Resultado:
nenhuma alteração necessária
Isso é idempotência.
Entendeu isso?
Você entendeu uma parte essencial do Ansible.
55. Segundo exercício: deployment
Agora:
SOURCE
|
Git
|
Ansible
|
+---- copy
|
+---- compile
|
+---- link-edit
|
+---- deploy
|
+---- validate
O COBOL continua COBOL.
O load module continua load module.
O que mudou?
O processo ao redor dele.
Isso é modernização.
56. Terceiro exercício: automação híbrida
Imagine:
Playbook
|
+--- valida CICS
|
+--- atualiza recurso z/OS
|
+--- atualiza microservice OpenShift
|
+--- executa teste
|
+--- verifica retorno
Agora um único processo de mudança conhece os dois lados:
SYSTEM OF RECORD
+
SYSTEM OF ENGAGEMENT
Essa é uma das fronteiras mais interessantes para profissionais de mainframe nos próximos anos.
57. Onde está o verdadeiro valor para um COBOLzeiro?
Não é decorar:
kubectl get pods
Isso qualquer tutorial ensina.
Seu valor aparece quando você consegue olhar:
OpenShift
|
microservice
|
REST
|
z/OS Connect
|
CICS
|
COBOL
|
Db2
e compreender a transação inteira.
O desenvolvedor cloud talvez conheça os primeiros quatro blocos.
O sysprog talvez conheça os últimos quatro.
Quem entende os dois lados se torna extremamente útil.
58. O profissional em formato T
Essa trilha cria exatamente isso.
Profundidade:
COBOL
CICS
Db2
z/OS
Amplitude:
Linux
containers
Kubernetes
OpenShift
Ansible
APIs
DevOps
Git
Não tente competir com um administrador Kubernetes que trabalha dez horas por dia com Kubernetes.
Não precisa.
Seu diferencial é:
“Eu consigo explicar o que acontece desde o pod até o COMMAREA.”
Esse profissional é raro.
59. Easter egg final — o mainframe nunca saiu da moda; apenas mudaram os nomes
Compare:
WLM
scheduler
workload
resource management
automation
virtualization
security
high availability
com:
Kubernetes scheduler
resource limits
orchestration
virtualization/containerization
RBAC
self-healing
Não são equivalentes.
Mas respondem a famílias semelhantes de problemas.
Por isso o mainframer veterano possui uma vantagem inesperada.
Você não começa do zero.
Você já conhece problemas de computação empresarial que o restante da indústria redescobriu em novas camadas.
O segredo é parar de perguntar:
“Qual comando Kubernetes corresponde a este comando z/OS?”
e começar a perguntar:
“Qual problema arquitetural cada tecnologia está resolvendo?”
Aí a ficha cai.
60. Mapa mental definitivo
MODERN ENTERPRISE
|
+------------------+------------------+
| |
IBM Z IBM LinuxONE
| |
+------+-------+ Linux
| | |
z/OS Linux OpenShift
| | |
| OpenShift Kubernetes
| | |
| Kubernetes Pods
| | |
| Pods Containers
| |
| Containers
|
+--- CICS
+--- IMS
+--- Db2
+--- COBOL
+--- MQ
+--- z/OS Connect
|
+--- zCX
|
Linux
|
Containers
AUTOMATION LAYER
|
Ansible
|
+----------------+----------------+
| | |
z/OS Linux OpenShift
Esse desenho é provavelmente a coisa mais importante de todo o material.
61. As dez perguntas que você deve conseguir responder
Quando terminar o estudo inicial, responda sem consultar Google:
Um container é uma VM?
zCX significa que Linux virou parte do kernel z/OS?
USS é Linux?
Qual a diferença entre IBM Z e LinuxONE?
Onde OpenShift executa?
Qual a relação entre Kubernetes e OpenShift?
O que é um Pod?
O que significa desired state?
O que Ansible automatiza no z/OS?
Por que um programa COBOL continua relevante numa arquitetura cloud-native?
Se responder corretamente, você deixou de ser turista.
Agora já tem mapa.
62. Cheat sheet Bellacosa Mainframe
CONTAINER
Aplicação + dependências empacotadas.
IMAGE
Modelo imutável usado para criar containers.
REGISTRY
Repositório de imagens.
KUBERNETES
Orquestra workloads containerizados.
POD
Unidade básica de execução do Kubernetes.
NODE
Máquina participante do cluster.
CLUSTER
Conjunto administrado pelo Kubernetes.
DEPLOYMENT
Declara como uma aplicação deve existir.
SERVICE
Oferece acesso lógico aos pods.
OPENSHIFT
Plataforma Kubernetes empresarial da Red Hat.
IBM Z
Plataforma enterprise que pode executar z/OS e Linux.
LINUXONE
Plataforma IBM orientada a Linux.
USS
Ambiente UNIX do z/OS.
zCX
Ambiente de containers Linux integrado ao universo z/OS.
ANSIBLE
Automação declarativa de TI.
PLAYBOOK
Workflow Ansible escrito normalmente em YAML.
MODULE
Unidade funcional que executa uma tarefa.
COLLECTION
Pacote organizado de módulos/plugins/roles.
INVENTORY
Lista e agrupamento dos sistemas administrados.
IDEMPOTÊNCIA
Reexecutar procurando o mesmo estado sem provocar mudanças desnecessárias.
ibm_zos_core
Collection fundamental para automação z/OS com Ansible.
63. O conselho do velho COBOLzeiro
Não estude essas tecnologias como três disciplinas independentes.
A sequência lógica é:
z/OS
|
zCX
|
container
|
Kubernetes
|
OpenShift
|
Ansible
Mas arquiteturalmente a visão correta é uma rede:
Ansible
|
+----------------+----------------+
| | |
z/OS Linux OpenShift
| |
zCX Kubernetes
| |
Containers Containers
E no centro de tudo continuam os dados.
DATA
|
TRANSACTION
|
COBOL
|
APIs / Events
|
OpenShift
|
Digital World
☕ Conclusão — Não é só container. É estratégia.
O jovem desenvolvedor olha para IBM Z e enxerga algo antigo.
O COBOLzeiro olha para Kubernetes e enxerga algo estranho.
Os dois estão olhando errado.
O IBM Z moderno pode conversar com Linux, containers, APIs, OpenShift, Kubernetes, Ansible, Git e pipelines DevOps sem deixar de fazer aquilo que aprendeu a fazer excepcionalmente bem: processar transações críticas e manter sistemas de registro funcionando.
zCX representa uma ponte.
Kubernetes representa orquestração.
OpenShift transforma essa orquestração em uma plataforma empresarial.
Ansible amarra automação entre mundos.
E LinuxONE demonstra que a arquitetura IBM Z não precisa obrigatoriamente significar z/OS.
O objetivo não é transformar o COBOLzeiro em administrador Kubernetes em uma semana.
É muito mais valioso.
É permitir que ele olhe para um diagrama moderno e diga:
“Ahhh... agora entendi onde cada coisa mora.”
E depois faça a pergunta que realmente assusta o arquiteto:
“Muito bonito. Agora me mostra por onde passa a transação.”
Nesse momento o Padawan deixou de decorar buzzwords.
Começou a fazer arquitetura.
Para ir mais longe
https://eljefemidnightlunch.blogspot.com/2026/07/capitulo-1-o-funeral-que-nunca-aconteceu.html
