 |
| Bellacosa Mainframe apresenta docker e kubernetes |
☕ Um Café no Bellacosa Mainframe
Docker e Kubernetes Muito Além do docker run e do kubectl apply
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Containers, Orquestração, DevOps, Cloud, IBM Z e Como os Grandes Bancos Executam Milhares de Aplicações Sem Parar um Segundo
"O programador COBOL do século XXI não precisa abandonar o Mainframe. Precisa entender como o Mainframe conversa com o restante do mundo."
Introdução
Durante muitos anos, aprender informática significava instalar programas diretamente no computador.
Você colocava um CD.
Executava o instalador.
Clicava em "Avançar".
Esperava alguns minutos.
Pronto.
O software estava instalado.
O problema era que esse software passava a depender completamente daquele computador.
Se outro computador tivesse uma versão diferente do Windows...
Outra biblioteca...
Outro Java...
Outra configuração regional...
Outro driver...
Era comum ouvir uma frase que se tornou quase uma piada entre programadores.
"Na minha máquina funciona."
Essa frase custou bilhões de dólares para empresas no mundo inteiro.
Ela representa horas perdidas de suporte técnico, atrasos em projetos, ambientes inconsistentes, servidores quebrados e implantações malsucedidas.
Foi justamente para resolver esse problema que nasceu uma das tecnologias mais importantes da computação moderna: Docker.
Poucos anos depois surgiu outro desafio.
Tudo funcionava muito bem com um único container.
Mas e quando uma empresa possui:
500 servidores;
8.000 containers;
centenas de microsserviços;
milhões de clientes conectados simultaneamente?
Quem decide onde cada aplicação será executada?
Quem reinicia automaticamente uma aplicação que falhou?
Quem distribui a carga?
Quem aumenta automaticamente a quantidade de servidores durante a Black Friday?
Quem reduz essa infraestrutura durante a madrugada?
Essa resposta chama-se Kubernetes.
Hoje praticamente todas as grandes empresas utilizam Docker e Kubernetes de alguma forma.
Google.
Netflix.
Spotify.
Amazon.
IBM.
Microsoft.
Nubank.
Itaú.
Bradesco.
Santander.
BB.
Caixa.
E centenas de outras instituições financeiras.
Mas existe uma forma muito mais fácil de compreender tudo isso.
Vamos esquecer a nuvem por alguns minutos.
Vamos olhar para Docker e Kubernetes com os olhos de um Programador COBOL Padawan.
Antes do Docker
Imagine que você acabou de desenvolver um programa COBOL.
Você compilou.
Gerou o Load Module.
Tudo funcionou.
Agora outra equipe precisa executar exatamente o mesmo programa em outro ambiente.
Só que existe um problema.
O compilador é diferente.
As bibliotecas são diferentes.
O sistema operacional possui outra versão.
O banco de dados foi atualizado.
A variável de ambiente mudou.
O timezone é outro.
O locale também.
De repente...
O programa deixa de funcionar.
Não porque o código esteja errado.
Mas porque o ambiente mudou.
Foi exatamente esse problema que Docker resolveu.
O conceito mais importante
Docker não foi criado para substituir máquinas virtuais.
Nem servidores.
Nem sistemas operacionais.
Ele nasceu para encapsular uma aplicação junto com tudo aquilo que ela precisa para funcionar.
Imagine uma caixa.
Dentro dessa caixa existe:
sua aplicação;
bibliotecas;
dependências;
arquivos de configuração;
variáveis de ambiente;
versões corretas das ferramentas;
tudo pronto para execução.
Essa caixa recebe o nome de Container.
Uma analogia com o Mainframe
Imagine um programa COBOL.
Primeiro temos:
Programa Fonte
Depois:
Compilação
Depois:
Link Edit
Depois:
Load Module
Quando executamos:
//STEP01 EXEC PGM=PAGAMENT
O programa entra em execução.
Docker segue exatamente essa filosofia.
Você cria uma Imagem.
Depois executa essa imagem.
A imagem nunca muda.
Quem muda é a instância dela.
Essa instância chama-se Container.
Imagem não é Container
Este talvez seja o primeiro conceito que todo iniciante precisa aprender.
Muitas pessoas confundem.
Uma imagem é apenas um modelo.
Ela não está executando.
É semelhante a um Load Module armazenado em uma Load Library.
Já o container é o programa em execução.
Da mesma forma que um mesmo programa COBOL pode ser executado por vários JOBs simultaneamente, uma única imagem Docker pode originar diversos containers independentes.
O Dockerfile: o "JCL" do Mundo Docker
Se existe algo que lembra um JCL dentro do universo Docker, esse algo é o Dockerfile.
Ele descreve todas as etapas necessárias para construir uma imagem.
Exemplo:
FROM eclipse-temurin:21
WORKDIR /app
COPY . .
RUN mvn clean package
CMD ["java","-jar","app.jar"]
Observe que ele não executa imediatamente.
Ele apenas descreve como construir o ambiente.
É muito parecido com um procedimento documentando todas as etapas para gerar um executável.
Build: construindo a imagem
Quando executamos:
docker build -t banco-api .
Estamos dizendo:
"Leia o Dockerfile e construa uma imagem chamada banco-api."
Nada está rodando ainda.
Estamos apenas fabricando nosso executável.
É como executar uma compilação COBOL.
Run: finalmente executando
Agora sim.
docker run banco-api
A imagem transforma-se em um container.
O programa começa a executar.
Se executarmos novamente:
docker run banco-api
Outro container será criado.
A imagem continua exatamente igual.
Docker Client e Docker Daemon
Muita gente acredita que o comando docker faz todo o trabalho.
Na realidade, ele é apenas o cliente.
Quem realmente administra tudo é o Docker Daemon.
Quando digitamos:
docker ps
O terminal envia uma solicitação ao Daemon.
É o Daemon que lista os containers.
Quando digitamos:
docker stop
Quem encerra o container é o Daemon.
Quando criamos imagens.
Volumes.
Redes.
Quem faz tudo é ele.
O cliente apenas envia comandos.
Docker Hub: a "Load Library" da Internet
Imagine uma gigantesca biblioteca contendo milhões de programas prontos.
Ubuntu.
Debian.
PostgreSQL.
MySQL.
Redis.
MongoDB.
Nginx.
Apache.
Python.
Node.js.
Java.
Tudo disponível.
Esse repositório chama-se Docker Hub.
Ao executar:
docker pull postgres
Você baixa uma imagem pronta.
É semelhante a copiar um Load Module certificado para sua biblioteca de execução.
Volumes: onde moram os dados?
Aqui encontramos um dos erros mais comuns dos iniciantes.
Containers devem ser descartáveis.
Podem morrer.
Podem ser recriados.
Podem desaparecer.
Então onde ficam os dados?
Em um Volume.
Imagine um banco PostgreSQL.
Os dados nunca ficam dentro do container.
Eles ficam em um armazenamento externo.
O container pode ser destruído.
Os dados continuam intactos.
Para um programador COBOL, pense em um programa acessando um VSAM ou um Db2.
O programa pode terminar.
Os dados continuam armazenados.
Redes Docker
Outro conceito interessante.
Cada container recebe um endereço IP interno.
Docker cria uma rede virtual.
Aplicações podem conversar entre si.
Imagine:
Container WEB
↓
Container API
↓
Container Db2
↓
Container Redis
Cada um executando separadamente.
Mas todos conectados pela mesma rede.
Bridge, Host e Overlay
O driver Bridge é o padrão.
Ele cria uma rede privada.
Host elimina esse isolamento e utiliza diretamente a rede do servidor.
Overlay conecta containers distribuídos em vários servidores diferentes.
É justamente esse último que se torna extremamente importante quando entramos no universo Kubernetes.
O problema que Docker não resolve
Agora imagine um banco digital.
Existem:
3.000 APIs;
800 microsserviços;
12.000 containers;
centenas de servidores Linux.
Docker sabe criar containers.
Mas não sabe decidir em qual servidor cada aplicação deverá executar.
Também não sabe reiniciar automaticamente aplicações que falharam.
Não sabe fazer escalabilidade automática.
Não sabe distribuir carga.
Não sabe realizar atualizações sem indisponibilidade.
É aqui que entra Kubernetes.
Kubernetes: o maestro da orquestra
Docker fabrica músicos.
Kubernetes rege a orquestra.
Ele observa milhares de containers simultaneamente.
Decide onde executar cada um.
Monitora falhas.
Redistribui carga.
Executa atualizações.
Realiza rollback.
Mantém sempre o ambiente funcionando.
O Control Plane
O cérebro do Kubernetes recebe esse nome.
Ele não executa aplicações.
Ele apenas toma decisões.
É semelhante a uma central de controle.
Tudo passa por ele.
API Server
Toda comunicação acontece através dele.
Quando executamos:
kubectl apply -f deployment.yaml
Na realidade estamos falando com o API Server.
Ele recebe a solicitação.
Valida.
Armazena.
Distribui.
etcd: a memória do cluster
O Kubernetes precisa lembrar de tudo.
Quantos Pods existem.
Quais aplicações estão instaladas.
Quem possui acesso.
Quais Secrets foram criados.
Tudo isso fica armazenado no etcd.
Ele funciona como um banco de dados extremamente rápido.
Scheduler
Imagine cinco servidores disponíveis.
Qual deles possui CPU suficiente?
Qual possui memória livre?
Qual atende às restrições?
Quem decide?
Scheduler.
Ele analisa dezenas de parâmetros antes de escolher o melhor destino.
Worker Nodes
São os servidores que realmente executam os containers.
Podemos ter:
Node 1
Node 2
Node 3
Node 4
Node 5
Todos trabalhando simultaneamente.
Pods: a menor unidade
Muitos acreditam que Kubernetes executa containers.
Na verdade, ele executa Pods.
Um Pod normalmente contém um container.
Mas pode conter vários.
Eles compartilham rede.
Compartilham armazenamento.
Compartilham ciclo de vida.
Deployments
Suponha que desejamos dez Pods.
Criamos um Deployment.
Ele monitora continuamente.
Se um Pod morrer.
Outro nasce automaticamente.
Sem intervenção humana.
ReplicaSets
O Deployment utiliza ReplicaSets.
Sua missão é simples.
Garantir que o número desejado de Pods permaneça constante.
Services
Pods mudam constantemente.
São criados.
Destruídos.
Reiniciados.
Logo, seus endereços IP mudam.
Não podemos depender deles.
Criamos então um Service.
Ele fornece:
endereço fixo;
DNS;
balanceamento de carga.
As aplicações conversam com o Service.
Jamais diretamente com o Pod.
ConfigMaps
Imagine alterar a URL do banco de dados.
Você precisaria recompilar toda a aplicação?
Não.
Basta modificar um ConfigMap.
Ele armazena configurações externas.
Secrets
Senhas jamais devem ficar escritas no código.
Secrets armazenam:
senhas;
certificados;
tokens;
chaves de API.
Tudo de forma protegida.
Rolling Update
Uma das maiores vantagens do Kubernetes.
Imagine atualizar um sistema bancário.
Antigamente seria necessário interromper o serviço.
Hoje não.
O Kubernetes substitui Pods gradualmente.
Usuários praticamente não percebem.
Rollback
A atualização apresentou defeito?
Em segundos retornamos para a versão anterior.
Tudo automaticamente.
Auto Scaling
Imagine um PIX viralizando durante uma promoção.
O número de acessos dispara.
Kubernetes identifica o aumento.
Cria novos Pods.
Quando a demanda diminui.
Remove os Pods excedentes.
Tudo sem intervenção humana.
Onde entra o IBM Z?
Aqui está um ponto que muitos profissionais desconhecem.
Docker e Kubernetes não vieram substituir o Mainframe.
Vieram complementá-lo.
Hoje é extremamente comum encontrar arquiteturas como:
Aplicativo Mobile
↓
API Gateway
↓
Kubernetes
↓
Microsserviços Java
↓
IBM MQ
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
Observe que o COBOL continua executando exatamente onde sempre esteve.
A diferença é que agora ele conversa com aplicações modernas executando em containers.
O papel do OpenShift
A Red Hat, empresa pertencente à IBM, criou o OpenShift.
Ele utiliza Kubernetes como base.
Mas adiciona recursos corporativos.
Autenticação.
Segurança.
Monitoramento.
Registro de imagens.
Pipelines CI/CD.
Console gráfico.
Integração com IBM Z.
É hoje uma das plataformas mais utilizadas em ambientes financeiros.
O futuro do Programador COBOL
Existe um enorme equívoco no mercado.
Muitos imaginam que aprender Docker significa abandonar COBOL.
Na realidade acontece exatamente o contrário.
Quanto mais modernas ficam as arquiteturas, maior é a necessidade de integrar sistemas novos com sistemas legados.
O conhecimento em COBOL passa a ter ainda mais valor quando combinado com:
Docker;
Kubernetes;
Git;
DevOps;
APIs REST;
OpenShift;
IBM MQ;
z/OS Connect;
observabilidade;
automação.
O profissional deixa de ser apenas um programador.
Passa a ser um engenheiro de software capaz de compreender toda a cadeia de processamento.
Conclusão
Docker e Kubernetes representam uma mudança profunda na maneira como desenvolvemos, distribuímos e operamos aplicações.
Docker resolveu um problema antigo: garantir que uma aplicação funcione da mesma forma em qualquer ambiente, empacotando código, bibliotecas e dependências em containers leves, portáveis e reproduzíveis.
Kubernetes levou essa ideia a um novo patamar, automatizando a implantação, a recuperação de falhas, o balanceamento de carga, as atualizações e a escalabilidade de milhares de containers distribuídos por diversos servidores.
Para o Programador COBOL Padawan, esses conceitos não são estranhos. Eles dialogam diretamente com ideias já conhecidas do universo IBM Mainframe: a disciplina do JCL, a confiabilidade do z/OS, a persistência do Db2 e do VSAM, a automação do IBM Z Workload Scheduler, a integração via IBM MQ e a alta disponibilidade que sempre caracterizou os grandes ambientes corporativos.
O mundo da tecnologia não está abandonando o Mainframe; está construindo uma ponte entre décadas de confiabilidade e as novas arquiteturas baseadas em microsserviços, containers e computação em nuvem. Entender Docker e Kubernetes é aprender a atravessar essa ponte.
O COBOL continua processando bilhões de transações diariamente. A diferença é que, agora, muitas dessas transações começam em um aplicativo móvel, passam por APIs executadas em containers orquestrados pelo Kubernetes e chegam ao IBM Z com a mesma robustez e segurança que sustentam o mercado financeiro há mais de meio século.
E talvez essa seja a maior lição deste café no Bellacosa Mainframe: as tecnologias mudam, as ferramentas evoluem, mas os princípios da boa engenharia de software — padronização, automação, confiabilidade e simplicidade — permanecem os mesmos. Quem domina esses princípios estará preparado para programar tanto no legado quanto no futuro.
