 |
| Bellacosa Mainframe e o docker no mundo cobol mainframe |
☕ Um Café no Bellacosa Mainframe
Docker para Programadores COBOL Mainframe: O "JCL" do Mundo Moderno que Todo Padawan IBM Z Precisa Entender
"Você pode passar trinta anos programando COBOL sem nunca escrever uma linha de Docker. Mas provavelmente trabalhará com pessoas que usam Docker todos os dias para entregar o seu programa em produção."
Existe um mito muito comum entre profissionais de Mainframe.
"Docker é coisa de Linux."
Não.
Docker é uma tecnologia que muda completamente a forma como software é distribuído.
E isso afeta diretamente quem trabalha com COBOL.
Mesmo que seu programa execute dentro de um IBM Z rodando z/OS.
Hoje praticamente toda arquitetura moderna possui alguma camada containerizada.
Seu COBOL conversa com APIs.
As APIs estão em containers.
Os testes automatizados rodam em containers.
O banco PostgreSQL usado para homologação roda em container.
O Redis roda em container.
O RabbitMQ roda em container.
O Kafka roda em container.
Até o VS Code que conversa com seu Zowe pode estar executando dentro de um Dev Container.
Ou seja...
Mesmo que você nunca instale Docker, Docker provavelmente trabalha para você todos os dias.
A analogia que todo coboleiro entende
Imagine um JOB.
Você escreve:
//STEP01 EXEC PGM=MEUPROG
Quando o operador executa o JOB, ele sabe exatamente:
qual programa executar
quais datasets utilizar
quais bibliotecas carregar
qual ambiente existe
Docker segue exatamente essa filosofia.
Em vez de dizer
"Execute o programa."
Ele diz
"Execute exatamente ESTE ambiente."
Essa pequena diferença mudou toda a indústria.
O maior problema do desenvolvimento moderno
Todo desenvolvedor já ouviu a frase:
"Na minha máquina funciona."
Essa frase custa milhões para empresas.
Porque existem diferenças entre computadores.
Imagine três desenvolvedores.
Carlos usa Ubuntu.
João usa Windows.
Maria usa Mac.
Cada um possui:
versões diferentes de Java
versões diferentes de Python
bibliotecas diferentes
PATH diferente
variáveis diferentes
Resultado?
O software funciona em uma máquina.
Quebra na outra.
Docker elimina esse problema.
O container é um ambiente fechado
Pense nele como um mini sistema operacional.
Dentro dele existe tudo.
Aplicação
↓
Bibliotecas
↓
Dependências
↓
Sistema
↓
Configuração
↓
Rede
Tudo viaja junto.
Assim como um LOAD MODULE leva seu código compilado.
O paralelo perfeito com Mainframe
No z/OS nós temos:
STEPLIB
LINKLIST
LPALIB
PROCLIB
PARMLIB
SDFHLOAD
SCEERUN
DBRMLIB
Cada biblioteca influencia a execução.
Docker faz exatamente isso.
Só que empacotado.
O Dockerfile é praticamente um PROC
Olhe este Dockerfile.
FROM ubuntu
RUN apt update
RUN apt install python3
COPY app.py .
CMD python3 app.py
Ele descreve todo ambiente.
Assim como uma PROC descreve um JOB.
Um PROC
//COBPROC PROC
//COB EXEC PGM=IGYCRCTL
//LKED EXEC PGM=IEWL
// PEND
Os dois descrevem como construir um ambiente.
Só muda a linguagem.
O Build
Quando fazemos
docker build
Estamos criando uma imagem.
É semelhante a:
Compilar COBOL
↓
Link-edit
↓
Gerar Load Module
Não executa ainda.
Apenas cria.
A imagem
A imagem é imutável.
Ela funciona como um LOAD MODULE.
Você gera uma vez.
Executa milhares.
O Container
Quando fazemos
docker run
É semelhante ao operador executando
SDSF
COMMAND
S
START JOB
A imagem ganha vida.
O Registry
Docker possui repositórios.
Semelhantes a uma gigantesca LOADLIB.
Docker Hub
GitHub Registry
Azure Registry
IBM Registry
O COBOL moderno conversa com containers
Imagine seu programa.
COBOL
↓
CICS
↓
REST API
↓
Docker
↓
Java
↓
Banco
Você nem percebe.
Mas boa parte da aplicação vive dentro de containers.
O Docker não substitui Mainframe
Esse é outro mito.
Ele complementa.
Mainframe continua fazendo aquilo que faz melhor.
Processamento crítico.
Docker faz aquilo que faz melhor.
Microsserviços.
APIs.
Ferramentas.
Integração.
Um exemplo real
Seu COBOL chama:
CLIENTE
↓
API PIX
↓
Container
↓
Spring Boot
↓
Banco PostgreSQL
O COBOL nunca sabe.
Só vê uma URL.
Onde um coboleiro usa Docker?
Muito mais do que imagina.
Exemplos.
PostgreSQL
docker run postgres
MongoDB
docker run mongo
Redis
docker run redis
Kafka
docker run kafka
RabbitMQ
docker run rabbitmq
Jenkins
docker run jenkins
SonarQube
docker run sonarqube
GitLab Runner
Container.
Zowe
Pode rodar em container.
IBM Explorer
Ambientes de teste podem ser containerizados.
Easter Egg número 1
Docker também possui "camadas".
Assim como o Mainframe possui bibliotecas em cascata.
Quando duas imagens compartilham partes iguais...
Docker reutiliza.
É quase um:
LPA
Shared Library
LINKLIST
Easter Egg número 2
Imagem Docker.
Read Only
Load Module.
Read Only
Curiosa coincidência.
Easter Egg número 3
Containers morrem.
Dados persistem.
Parece familiar?
Datasets.
Você apaga um JOB.
Mas o VSAM continua.
Volumes
Volumes são onde vivem os dados.
Sem volume.
Tudo desaparece.
Assim como arquivos temporários em SYSDA.
Cuidado
Padawans fazem isto:
docker run mysql
Depois:
docker rm
Adeus banco.
Tudo perdido.
O equivalente ao DELETE do catálogo.
Sem backup.
Sem retorno.
Docker Compose
Imagine um sistema inteiro.
Você precisa:
PostgreSQL
Redis
RabbitMQ
API
Front-end
Seria trabalhoso iniciar tudo manualmente.
Então existe:
docker-compose.yml
É praticamente um scheduler.
Você escreve.
Suba tudo.
E ele sobe.
Na ordem correta.
Parece JCL?
Muito.
STEP01
↓
STEP02
↓
STEP03
Docker Desktop
É o ISPF do Docker.
Quem conhece ISPF aprende Docker Desktop rapidamente.
Como um coboleiro evolui?
Nível 1
Aprender comandos.
docker ps
docker images
docker stop
docker rm
docker logs
Nível 2
Dockerfile.
Nível 3
Volumes.
Nível 4
Networks.
Nível 5
Compose.
Nível 6
CI/CD.
Nível 7
Kubernetes.
O comando que todo mundo esquece
docker logs
É praticamente:
SDSF
OUTPUT
SYSOUT
Sem logs.
Não existe diagnóstico.
Outro comando essencial
docker exec -it container bash
É equivalente a:
TSO
LOGON
Você entra dentro da máquina.
Redes Docker
Containers conversam por rede virtual.
Pense em CICS falando com DB2.
Tudo isolado.
Variáveis de ambiente
No Mainframe temos:
PARMLIB.
PARM.
SYSIN.
No Docker temos:
ENV
Environment Variables
Mesmo conceito.
Segurança
Nunca coloque senhas.
Errado.
ENV PASSWORD=123456
Correto.
Secrets.
Vault.
Azure Key Vault.
Hashicorp Vault.
Um perigo enorme
Container não é Máquina Virtual.
Muitos iniciantes confundem.
Container compartilha o Kernel.
Máquina Virtual possui Kernel próprio.
São tecnologias diferentes.
Outro erro comum
Criar imagens gigantes.
Imagem de:
12 GB
Quando poderia ter:
300 MB
Outro erro
Executar como root.
Jamais.
Sempre criar usuário.
Outro erro
Copiar arquivos desnecessários.
Use:
.dockerignore
Assim como usamos:
EXCLUDE
Em utilitários.
Docker e DevOps
Hoje praticamente toda pipeline faz:
Git
↓
Build
↓
Testes
↓
Docker
↓
Deploy
Mesmo sistemas Mainframe participam desse fluxo.
Onde entra o COBOL?
Exemplo.
GitHub
↓
Compila COBOL
↓
Executa testes
↓
Publica API
↓
Container
↓
OpenShift
↓
Consome CICS
O COBOL continua sendo protagonista.
Docker apenas ajuda.
Curiosidade
IBM possui imagens oficiais.
Ferramentas IBM também utilizam containers.
OpenShift é baseado em Kubernetes.
Kubernetes nasceu para gerenciar milhares de containers.
Easter Egg número 4
No Mainframe aprendemos cedo:
Nunca altere produção diretamente.
Docker leva isso ao extremo.
Você nunca altera um container.
Você destrói.
Cria outro.
É uma filosofia muito parecida com a imutabilidade dos artefatos promovida por pipelines modernos.
Easter Egg número 5
O famoso:
docker kill
Lembra muito um operador fazendo:
CANCEL JOB
A diferença é que o impacto pode ser ainda maior.
Se aquele container fazia parte de um cluster, outro poderá assumir automaticamente.
É como um Sysplex distribuindo a carga para outro membro.
Docker e IBM Z: um casamento cada vez mais comum
Muitos padawans imaginam que Docker existe apenas em servidores x86. Na prática, o ecossistema IBM Z também abraçou containers. É comum encontrar ambientes onde aplicações Java, Node.js, Python ou Go executam em Linux on IBM Z ou LinuxONE dentro de containers, enquanto os sistemas críticos permanecem em z/OS.
Um cenário típico é:
Internet
│
API Gateway
│
Container Spring Boot
│
IBM MQ
│
CICS
│
Programa COBOL
│
DB2
Perceba que o COBOL continua onde sempre esteve: no coração da transação. O Docker atua nas camadas de integração, autenticação, observabilidade e exposição de serviços.
Como identificar problemas em Docker com a mentalidade de um operador de Mainframe
Um bom programador COBOL costuma pensar de forma estruturada. Essa habilidade ajuda muito ao trabalhar com containers. Ao investigar um problema, faça perguntas parecidas com as que faria diante de um ABEND:
O container iniciou corretamente?
O processo principal terminou inesperadamente?
Os logs mostram mensagens de erro?
Há portas em conflito?
O volume de dados foi montado?
A variável de ambiente obrigatória foi definida?
A imagem está na versão correta?
Existe comunicação entre os containers?
O serviço externo está disponível?
Essa abordagem sistemática reduz drasticamente o tempo de diagnóstico.
Conclusão: Docker é mais familiar ao coboleiro do que parece
Quando um padawan olha para Docker pela primeira vez, tudo parece novo: imagens, containers, volumes, registries, compose, redes. Porém, um veterano de Mainframe rapidamente percebe padrões conhecidos.
Você já entende de ambientes controlados.
Já entende de bibliotecas.
Já entende de versões.
Já entende de promoção entre desenvolvimento, homologação e produção.
Já entende da importância dos logs.
Já entende que uma alteração aparentemente pequena pode causar um grande incidente.
Docker apenas utiliza outra linguagem para resolver muitos dos mesmos problemas que o Mainframe resolveu décadas atrás.
No fim das contas, um bom programador COBOL não precisa abandonar sua experiência para aprender Docker. Pelo contrário: sua disciplina, seu cuidado com mudanças, sua visão de estabilidade e sua capacidade de diagnosticar problemas são exatamente as qualidades que diferenciam um excelente profissional de containers.
E fica um último pensamento para os Padawans do Bellacosa Mainframe:
"Quem domina JCL entende que infraestrutura também é código. Docker apenas tornou essa ideia popular para o restante da indústria."
A tecnologia muda, as ferramentas evoluem, mas os princípios continuam os mesmos: ambientes reproduzíveis, processos previsíveis, mudanças controladas e software confiável. E nisso, poucos profissionais têm tanto a ensinar quanto um bom coboleiro de Mainframe.
Docker na Stack Mainframe
Não houve um único ano, um release ou um anúncio dizendo "Docker agora suporta COBOL Mainframe". O que aconteceu foi uma convergência gradual de tecnologias.
Esta é uma linha do tempo que ajuda a entender essa evolução:
| Ano | Marco | Impacto para Mainframe |
|---|---|---|
| 2013 | Docker é lançado pela dotCloud | Nasce o conceito moderno de containers Linux. |
| 2014 | Docker 1.0 | Empresas começam a adotar containers em produção. |
| 2015 | Kubernetes ganha força | Orquestração de milhares de containers. |
| 2016-2017 | IBM passa a investir fortemente em containers e microserviços | Integrações com IBM Z tornam-se prioridade. |
| 2017 | IBM adquire a Red Hat? (não, o anúncio foi em 2018 e conclusão em 2019) | Estratégia híbrida começa a se consolidar. |
| 2018 | IBM anuncia a aquisição da Red Hat | OpenShift torna-se a principal plataforma de containers da IBM. |
| 2019 | Conclusão da aquisição da Red Hat | OpenShift passa a ser peça central da estratégia IBM Hybrid Cloud. |
| 2020+ | OpenShift chega amplamente ao IBM Z e LinuxONE | Containers tornam-se parte da arquitetura corporativa junto ao z/OS. |
| 2021-2024 | APIs, z/OS Connect, Ansible, Zowe e OpenShift amadurecem | COBOL passa a conviver naturalmente com aplicações containerizadas. |
O ponto importante
Docker não executa programas COBOL do z/OS.
Quem continua executando o COBOL é:
z/OS
CICS
Batch
IMS
Db2
JCL
O Docker normalmente executa o que está ao redor do COBOL:
APIs REST
Java
Spring Boot
Node.js
Python
NGINX
Redis
PostgreSQL
Kafka
RabbitMQ
Ferramentas DevOps
O cenário típico hoje é:
Internet
│
OpenShift / Docker
│
API REST
│
z/OS Connect
│
CICS
│
Programa COBOL
│
DB2
O programa COBOL continua exatamente onde sempre esteve.
O Docker apenas fornece uma maneira moderna de consumir seus serviços.
Quando o COBOL "abraçou" Docker?
Se tivermos que escolher um período, eu diria que foi entre 2018 e 2022.
Isso ocorreu porque várias tecnologias amadureceram ao mesmo tempo:
IBM OpenShift no IBM Z
Linux on IBM Z
z/OS Connect Enterprise Edition
Zowe
Git e pipelines DevOps para Mainframe
APIs REST consumindo programas COBOL
Arquiteturas híbridas (Hybrid Cloud)
Foi nessa época que deixou de ser incomum ver um sistema como este:
Docker
│
Spring Boot
│
REST
│
z/OS Connect EE
│
CICS
│
COBOL
│
DB2
Hoje essa arquitetura é bastante comum em bancos, seguradoras, telecomunicações e grandes empresas.
Existe Docker rodando diretamente no z/OS?
Não.
O Docker utiliza recursos do kernel Linux (namespaces, cgroups etc.), portanto não roda nativamente sobre o kernel do z/OS.
No ecossistema IBM Z, o mais comum é:
Docker rodando em Linux on IBM Z ou LinuxONE.
OpenShift gerenciando containers nesses ambientes Linux.
z/OS executando COBOL, CICS, IMS, Db2 e batch.
Comunicação entre ambos via REST, IBM MQ, gRPC, eventos ou APIs.
Uma curiosidade para o coboleiro
O Docker nunca substituiu o Mainframe. Na verdade, ele acabou reforçando seu papel.
Quando uma empresa cria dezenas ou centenas de microsserviços em containers, muitos deles precisam consultar dados críticos. Em vez de migrar décadas de regras de negócio, eles chamam as aplicações COBOL existentes por meio de APIs. Assim, o COBOL permanece como o sistema de registro (System of Record), enquanto os containers atuam como camada de apresentação, integração e inovação.
É por isso que, atualmente, um programador COBOL moderno não precisa aprender Docker para "rodar COBOL", mas sim para compreender o ecossistema onde seu código vive e como ele se integra ao restante da arquitetura corporativa. Esse conhecimento facilita a comunicação com equipes de DevOps, SRE, desenvolvimento Java, APIs e nuvem híbrida, tornando o profissional de Mainframe ainda mais valioso.
Sem comentários:
Enviar um comentário