 |
| Bellacosa Mainframe apresenta docker sem misterios |
☕ Um Café no Bellacosa Mainframe
Docker sem Mistérios
O Guia Definitivo para um Programador COBOL Padawan Entender Containers, DevOps e a Nova Engenharia de Software
"Um programador COBOL experiente não demora muito para perceber que Docker não veio substituir o Mainframe. Veio apenas democratizar conceitos que os grandes ambientes corporativos praticam há décadas."
Existe uma curiosidade interessante sobre a evolução da tecnologia.
A cada dez ou quinze anos surge uma "nova revolução" que promete reinventar completamente a computação. Já aconteceu com orientação a objetos, Java, virtualização, cloud computing, microsserviços, Kubernetes, DevOps e, mais recentemente, Inteligência Artificial.
Mas quando olhamos um pouco mais profundamente, percebemos algo fascinante: quase todas essas revoluções não inventaram novos princípios. Elas apenas encontraram formas diferentes de aplicar conceitos que sempre existiram.
Docker é um excelente exemplo disso.
Para muitos desenvolvedores modernos, containers parecem uma tecnologia revolucionária. Para quem passou anos trabalhando com IBM Z, JES2, CICS, Db2, z/OS e COBOL, porém, Docker soa surpreendentemente familiar.
Este artigo não pretende ensinar apenas comandos. Seu objetivo é mostrar como um programador COBOL pode compreender Docker utilizando aquilo que já domina: engenharia de software, ambientes corporativos e sistemas críticos.
A maior mentira sobre Docker
Se você perguntar para um iniciante:
"O que é Docker?"
Provavelmente ouvirá:
"É uma ferramenta para criar containers."
Essa resposta está tecnicamente correta.
Mas está completamente incompleta.
Docker nunca foi apenas uma ferramenta.
Docker é uma solução para um problema antigo.
Imagine uma aplicação Java.
Ela funciona perfeitamente no computador do desenvolvedor.
Quando chega ao servidor...
Nada funciona.
Falta uma biblioteca.
A versão do Java é diferente.
Existe conflito de dependências.
Uma variável de ambiente está ausente.
Uma DLL não existe.
Um certificado expirou.
A famosa frase aparece:
"Na minha máquina funciona."
Durante décadas essa frase custou milhões de dólares às empresas.
Docker nasceu justamente para eliminar esse problema.
O verdadeiro objetivo dos Containers
Containers não existem para economizar memória.
Nem para facilitar deploy.
Nem para executar microsserviços.
Tudo isso é consequência.
O verdadeiro objetivo é tornar o ambiente reproduzível.
Ou seja...
A aplicação leva consigo tudo aquilo que precisa.
Bibliotecas.
Configurações.
Dependências.
Usuários.
Permissões.
Arquivos.
Versões.
Quando o container é iniciado, o ambiente é exatamente igual em qualquer computador.
Notebook.
Servidor.
Cloud.
Produção.
Homologação.
Tudo funciona da mesma forma.
O primeiro paralelo com o Mainframe
Esse conceito não é novo para quem vive no IBM Z.
Pense em um JOB.
Quando submetemos um JCL ao JES2, ele leva consigo:
o programa que será executado;
os parâmetros necessários;
os datasets de entrada;
os datasets de saída;
bibliotecas de carga;
bibliotecas COBOL;
DD Statements;
região de memória;
configurações específicas.
Perceba a semelhança.
O ambiente de execução já está definido antes mesmo do programa começar.
Docker segue exatamente essa filosofia.
Containers não são Máquinas Virtuais
Esse talvez seja o erro mais comum dos iniciantes.
Virtual Machine.
Container.
Parecem iguais.
Mas internamente são completamente diferentes.
Uma máquina virtual precisa simular praticamente um computador inteiro.
Hardware virtual.
BIOS.
Kernel.
Sistema operacional completo.
Drivers.
Depois disso...
Finalmente a aplicação.
Já um container compartilha o kernel do sistema operacional hospedeiro.
Ele isola apenas processos.
Isso muda completamente o consumo de recursos.
Enquanto uma VM pode levar minutos para iniciar, um container normalmente leva poucos segundos.
Às vezes milissegundos.
Easter Egg nº 1 — O Mainframe já fazia isso de outra forma
Uma curiosidade pouco comentada.
No IBM Z também buscamos compartilhar recursos ao máximo.
Milhares de usuários utilizam o mesmo kernel do z/OS.
Centenas de jobs compartilham CPU.
Diversas aplicações compartilham memória.
CICS executa milhares de transações simultaneamente.
Db2 atende milhares de conexões.
A filosofia sempre foi aproveitar recursos de maneira eficiente.
Docker segue exatamente essa linha.
Docker Images: o "Load Module" do mundo Cloud
Aqui aparece um dos conceitos mais importantes.
Muita gente acredita que:
Imagem = Container.
Não.
Imagem é apenas um molde.
Container é uma instância desse molde.
Para um programador COBOL isso faz muito sentido.
Primeiro escrevemos:
SOURCE.
Depois compilamos.
Geramos o OBJ.
Executamos o Link-Edit.
Criamos o Load Module.
Somente então um JOB executa aquele módulo.
O Load Module continua existindo mesmo após o JOB terminar.
O mesmo acontece com Docker.
A imagem permanece armazenada.
Os containers nascem e morrem quantas vezes forem necessárias.
Dockerfile: o PROC do mundo Linux
O Dockerfile é talvez o arquivo mais importante de toda a plataforma.
Ele descreve passo a passo como construir uma imagem.
Não existe mágica.
Existe automação.
Cada instrução representa uma ação.
FROM.
COPY.
RUN.
ENV.
WORKDIR.
CMD.
É como escrever um PROC extremamente sofisticado.
Em vez de apenas indicar o programa a ser executado, você descreve toda a preparação do ambiente.
Instale Java.
Configure usuários.
Copie arquivos.
Crie diretórios.
Abra portas.
Defina variáveis.
No final, qualquer computador consegue reproduzir exatamente aquele ambiente.
Easter Egg nº 2 — As Layers lembram muito o SMP/E
Pouca gente percebe isso.
Cada comando do Dockerfile cria uma nova camada.
Essas camadas são reutilizadas automaticamente.
Se apenas uma linha mudou...
Docker recompõe somente aquela parte.
Isso reduz drasticamente tempo de build.
No Mainframe existe um conceito parecido durante manutenção do sistema operacional.
O SMP/E também trabalha reutilizando componentes ao invés de reinstalar tudo novamente.
São tecnologias completamente diferentes.
Mas a filosofia é muito semelhante.
O ciclo de vida de um Container
Todo container passa pelos mesmos estados.
Imagem.
Container criado.
Executando.
Parado.
Removido.
Nada disso significa que a aplicação desapareceu.
A imagem continua disponível.
Basta criar outra instância.
Para um profissional COBOL isso lembra imediatamente:
Programa compilado.
JOB submetido.
Executando.
Finalizado.
Novo JOB.
O programa continua existindo.
Quem nasce e morre é a execução.
Docker Networking
Talvez o assunto mais negligenciado pelos iniciantes.
Sem comunicação...
Não existe aplicação corporativa.
Imagine um banco.
O sistema precisa conversar com:
Db2.
Servidor Web.
Fila MQ.
API.
Cache.
Monitoramento.
Autenticação.
Cada componente precisa se comunicar de forma segura.
Docker oferece diferentes estratégias.
Bridge.
Host.
Overlay.
MacVLAN.
None.
Cada uma resolve um problema específico.
Easter Egg nº 3 — Overlay lembra muito Sysplex
Overlay permite que containers distribuídos em diversos servidores conversem como se estivessem na mesma rede.
Agora pense um pouco.
Isso lembra bastante um Parallel Sysplex.
Diversos sistemas físicos trabalhando praticamente como um único ambiente lógico.
Mais uma vez...
A tecnologia mudou.
A ideia continua a mesma.
Volumes: onde mora o maior erro dos iniciantes
Container é descartável.
Dados não.
Esse conceito parece simples.
Mas produz inúmeros problemas.
Imagine gravar arquivos importantes dentro do container.
Depois alguém executa:
docker rm.
Tudo desaparece.
Por isso existem Volumes.
Eles armazenam informações fora do ciclo de vida do container.
No Mainframe isso seria equivalente a gravar dados em um Dataset permanente ao invés de um arquivo temporário.
O programa termina.
O dataset continua.
Compose: descrevendo toda uma arquitetura
Imagine uma aplicação moderna.
Banco PostgreSQL.
Redis.
API Java.
Frontend.
Servidor NGINX.
Fila RabbitMQ.
Sem Docker Compose seria necessário iniciar cada serviço individualmente.
Com Compose tudo fica descrito em um único arquivo YAML.
Uma simples instrução coloca toda a arquitetura em funcionamento.
docker compose up.
Isso lembra muito a filosofia declarativa dos grandes ambientes corporativos.
PROC.
Scheduler.
JCL.
Parâmetros.
Tudo documentado.
Tudo reproduzível.
Logs contam histórias
Existe um conselho que todo especialista em Mainframe aprende cedo.
Nunca altere código antes de entender o problema.
E para entender o problema...
Leia os logs.
Docker possui um comando extremamente simples.
docker logs.
Mas sua importância é enorme.
Ali estão mensagens de erro.
Inicialização.
Dependências.
Falhas.
Exceções.
No Mainframe fazemos exatamente a mesma coisa analisando JESMSGLG, SYSOUT, CEEDUMP, SMF, RMF e dumps do sistema.
Os logs sempre contam a história completa.
Registry: a biblioteca do mundo Cloud
Outra analogia interessante.
Docker Registry é um repositório de imagens.
Pense nele como uma gigantesca biblioteca de Load Modules.
As equipes publicam novas versões.
Outros ambientes apenas fazem download.
Tudo versionado.
Tudo controlado.
Tudo auditável.
Essa preocupação sempre existiu em ferramentas como Endevor, ISPW e ChangeMan.
A filosofia DevOps
Muitos profissionais acreditam que Docker e DevOps são sinônimos.
Não são.
Docker é apenas uma ferramenta.
DevOps é uma cultura.
Seu objetivo é reduzir a distância entre desenvolvimento e operação.
Automatizar.
Versionar.
Testar.
Monitorar.
Implantar continuamente.
Curiosamente...
Grandes ambientes IBM Z já possuíam muitos desses processos muito antes da popularização do termo DevOps.
Existiam mudanças controladas.
Promoções entre ambientes.
Auditoria.
Versionamento.
Controle de acesso.
Separação entre desenvolvimento e produção.
O que mudou foi o grau de automação.
Docker e Kubernetes
Depois que um profissional domina Docker, naturalmente surge outra pergunta.
Quem gerencia centenas ou milhares de containers?
A resposta é Kubernetes.
Mas aqui existe outro paralelo interessante.
Docker executa containers.
Kubernetes coordena containers.
No Mainframe temos algo semelhante.
O sistema operacional executa workloads.
O WLM decide prioridades.
O Sysplex distribui carga.
O SA z/OS automatiza recuperação.
Novamente...
Não são tecnologias iguais.
Mas resolvem problemas parecidos.
Curiosidades que poucos conhecem
Docker surgiu em 2013 como um projeto da empresa dotCloud, que posteriormente passou a se chamar Docker Inc.
Entretanto, a tecnologia de containers é muito mais antiga.
Ela aproveita recursos do kernel Linux chamados namespaces e cgroups, desenvolvidos anos antes do Docker existir.
Outros sistemas operacionais também possuíam conceitos semelhantes, como Solaris Zones e FreeBSD Jails.
Ou seja...
Docker não inventou containers.
Ele tornou containers acessíveis para milhões de desenvolvedores.
O verdadeiro impacto na carreira de um Programador COBOL
Talvez você esteja pensando:
"Mas eu trabalho com Mainframe. Por que deveria aprender Docker?"
A resposta é simples.
Porque praticamente toda arquitetura moderna conversa com containers.
APIs.
Microsserviços.
CI/CD.
Pipelines.
Integração contínua.
OpenShift.
Kubernetes.
Cloud híbrida.
Mesmo que o seu COBOL continue executando no IBM Z, ele provavelmente será integrado a aplicações empacotadas em containers.
Entender Docker deixa de ser um diferencial.
Passa a ser uma competência estratégica.
O maior ensinamento
Existe uma frase que resume tudo o que vimos.
Ferramentas mudam.
Princípios permanecem.
Um bom engenheiro de software não memoriza centenas de comandos.
Ele compreende conceitos.
É justamente por isso que muitos profissionais IBM Z aprendem Docker, Kubernetes e DevOps com relativa facilidade.
Eles já conhecem os fundamentos.
Sabem o valor da padronização.
Da automação.
Da confiabilidade.
Da rastreabilidade.
Da observabilidade.
Da documentação.
Da recuperação de falhas.
Da estabilidade operacional.
Docker apenas apresenta esses princípios com uma nova interface.
E talvez essa seja a maior lição deste artigo.
Quando um Programador COBOL Padawan olha para Docker pela primeira vez, ele pode enxergar apenas uma tecnologia moderna da nuvem. Mas quando começa a compreender sua arquitetura, percebe algo muito mais profundo: grande parte das ideias consideradas "inovadoras" já fazia parte da cultura do Mainframe havia décadas. A verdadeira evolução não está em abandonar o passado, e sim em reconhecer que os melhores fundamentos da engenharia de software atravessam gerações de plataformas. Quem domina esses fundamentos consegue transitar naturalmente entre IBM Z, Linux, Cloud, Kubernetes e Inteligência Artificial, porque entende que linguagens, ferramentas e interfaces mudam continuamente, mas os princípios que sustentam sistemas críticos continuam exatamente os mesmos. Esse é o verdadeiro caminho do Mestre Bellacosa: não decorar tecnologias, mas compreender a engenharia que existe por trás delas.
