 |
| Bellacosa Mainframe e o docker sem misterios |
☕ Um Café no Bellacosa Mainframe
🐳 Docker sem Mistérios
Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing
"A lógica é o começo da sabedoria, não o fim."
— Sr. Spock
Introdução — Bem-vindo à Sala de Teletransporte
Imagine que você acaba de embarcar na USS Enterprise.
Você é um jovem oficial recém-saído da Academia da Frota Estelar.
Seu trabalho é manter os computadores da nave funcionando.
No entanto...
A Enterprise não possui apenas um computador.
Ela possui centenas.
Existem computadores para:
Controle de navegação
Motores de Dobra
Sensores
Transporte
Comunicações
Holodeck
Engenharia
Laboratórios científicos
Todos precisam funcionar simultaneamente.
Mas imagine se, para executar um simples software de navegação, fosse necessário construir uma Enterprise inteira.
Foi exatamente assim que a computação funcionou durante décadas.
Cada aplicação precisava praticamente de um servidor inteiro.
Era desperdício.
Foi então que surgiu uma ideia revolucionária.
"E se pudéssemos empacotar apenas a aplicação e tudo aquilo que ela realmente precisa?"
Nasciam os containers.
E alguns anos depois...
O mundo conheceria uma pequena baleia azul chamada Docker.
Hoje, Docker é um dos pilares de DevOps, Cloud Computing, CI/CD, Kubernetes e da computação moderna.
Neste Café no Bellacosa Mainframe vamos entender absolutamente tudo, especialmente para quem vem do universo COBOL, JCL, CICS, Db2 e IBM Z.
Prepare seu café.
O computador da Enterprise já iniciou o boot.
Capítulo 1 — Antes do Docker
Durante muitos anos instalar software era um verdadeiro ritual.
Imagine um servidor Linux.
Você precisava instalar:
Java
Python
NodeJS
Apache
Bibliotecas
Drivers
Dependências
Depois disso...
Rezava para tudo funcionar.
Se alguém atualizasse uma biblioteca...
Seu programa quebrava.
Era comum ouvir:
"Na minha máquina funciona."
Essa frase virou praticamente uma piada mundial.
O problema não era o código.
Era o ambiente.
Capítulo 2 — O Grande Problema
Imagine três aplicações.
Sistema A
Java 8
Sistema B
Java 17
Sistema C
Java 21
Todos no mesmo servidor.
Cada uma exige versões diferentes.
Resultado?
Conflitos.
Muito parecidos com programas COBOL compilados com runtimes incompatíveis.
No IBM Z isso sempre foi tratado com enorme cuidado.
No mundo distribuído...
Era um caos.
Capítulo 3 — A Solução Chamada Container
Container significa isolamento.
Cada aplicação leva consigo:
bibliotecas
dependências
configuração
runtime
Tudo empacotado.
Sem interferir nas demais.
É como colocar cada programa em sua própria cabine da Enterprise.
Todos dividem a nave.
Mas ninguém invade o espaço do outro.
Capítulo 4 — Máquina Virtual x Container
Durante anos usamos máquinas virtuais.
Servidor
↓
Hypervisor
↓
Windows
↓
Aplicação
Docker mudou completamente.
Servidor
↓
Linux
↓
Docker Engine
↓
Containers
Não existe outro sistema operacional inteiro.
Existe apenas:
processo
isolamento
filesystem
Resultado?
Inicialização em segundos.
Pouca memória.
Baixíssimo consumo.
Curiosidade
O kernel Linux enxerga um container apenas como um processo.
Nada mais.
Esse é um dos maiores segredos do Docker.
Capítulo 5 — O Docker Engine
O Docker Engine é o capitão da nave.
Ele administra:
containers
imagens
volumes
redes
armazenamento
execução
Sem ele...
Nada acontece.
Capítulo 6 — Dockerfile
O Dockerfile é uma receita culinária.
Exemplo:
FROM ubuntu
RUN apt update
RUN apt install python3
COPY app.py .
CMD ["python3","app.py"]
Ele diz exatamente como montar a aplicação.
No mundo Mainframe ele lembra bastante:
PROC JCL
CLIST
REXX
Script SMP/E
Job de instalação
Capítulo 7 — O Processo Completo
Tudo segue uma sequência lógica.
Dockerfile
↓
docker build
↓
Imagem
↓
docker run
↓
Container
Jamais confunda.
Dockerfile não executa.
Imagem não executa.
Quem executa é o container.
Capítulo 8 — O Mistério das Imagens
Imagem é um template.
Ela é imutável.
Pense em:
ISO
Backup
Snapshot
Golden Image
Você cria uma única imagem.
Depois gera cem containers.
Todos iguais.
Essa repetibilidade é um dos grandes segredos do DevOps.
Capítulo 9 — docker build
docker build -t web .
Significa:
Construa uma imagem usando o Dockerfile localizado no diretório atual.
"-t"
significa Tag.
Exemplo:
bellacosa/site:v1
Capítulo 10 — docker images
Lista todas as imagens.
docker images
Saída típica:
REPOSITORY
TAG
IMAGE ID
SIZE
Pense nisso como um catálogo de módulos carregáveis.
Capítulo 11 — docker pull
O Docker Hub funciona como uma biblioteca mundial.
docker pull nginx
Baixa uma imagem pronta.
Sem instalar manualmente.
Sem configurar dependências.
Sem sofrimento.
Curiosidade
O Docker Hub possui milhões de imagens.
Mas...
Nem todas são oficiais.
Sempre prefira imagens verificadas.
Capítulo 12 — docker run
Provavelmente o comando mais famoso.
docker run nginx
Ele cria:
Imagem
↓
Container
Nunca altera a imagem.
Principais parâmetros
-d
Modo background.
docker run -d nginx
Muito parecido com iniciar um Started Task no z/OS.
-p
Mapeamento de portas.
-p 8080:80
Host
↓
8080
Container
↓
80
--name
docker run --name web nginx
Muito melhor que decorar IDs enormes.
-e
Variáveis de ambiente.
-e DB_USER=admin
-v
Volumes.
-v dados:/var/lib/mysql
Sem volumes...
Os dados desaparecem ao remover o container.
Capítulo 13 — docker ps
docker ps
Lista apenas containers ativos.
Muito parecido com observar tarefas em execução no ambiente operacional.
docker ps -a
Mostra também:
encerrados
falhados
pausados
É excelente para troubleshooting.
Capítulo 14 — docker logs
Todo administrador aprende isso rapidamente.
Quando algo falha...
Primeiro comando:
docker logs
É equivalente ao programador COBOL abrir imediatamente:
JESMSGLG
JESJCL
SYSOUT
CEEDUMP
SDSF
Os logs contam a história do que aconteceu.
Capítulo 15 — docker exec
docker exec -it web bash
Agora você entra literalmente dentro do container.
Como abrir um terminal remoto exclusivo daquele ambiente.
Muito útil para:
investigar arquivos
executar comandos
validar configurações
Capítulo 16 — docker stop
Encerra um container.
Primeiro envia um SIGTERM.
Dá tempo para o programa finalizar corretamente.
Caso ignore...
Recebe SIGKILL.
Muito semelhante a uma finalização controlada antes de um cancelamento forçado.
Capítulo 17 — docker rm
Remove containers.
Mas apenas se estiverem parados.
Fluxo típico:
docker stop web
docker rm web
Capítulo 18 — docker rmi
Remove imagens.
docker rmi nginx
Só funciona se ninguém estiver usando aquela imagem.
Capítulo 19 — docker system prune
O famoso botão vermelho.
docker system prune -a
Remove:
cache
containers
imagens
redes não utilizadas
artefatos temporários
Libera dezenas de gigabytes.
Mas...
Muito cuidado.
Capítulo 20 — Comandos que Todo Profissional Usa
docker inspect
Mostra praticamente tudo.
IPs.
Volumes.
Redes.
JSON completo.
docker stats
Monitoramento em tempo real.
CPU
RAM
Rede
Disco
É semelhante a consultar métricas de desempenho em ferramentas de monitoramento corporativas.
docker top
Lista processos internos.
docker cp
Copia arquivos.
Host
↓
Container
Container
↓
Host
docker restart
Reinicia.
docker start
Liga novamente um container parado.
docker pause
Congela processos.
docker unpause
Retoma execução.
docker network ls
Lista redes.
docker volume ls
Lista volumes persistentes.
docker history
Mostra todas as camadas da imagem.
Excelente para otimização.
Capítulo 21 — Como Docker Funciona Internamente
Pouca gente sabe...
Mas um container não é uma máquina virtual.
Ele utiliza recursos do próprio kernel Linux, como:
Namespaces
Control Groups (cgroups)
OverlayFS
Union File Systems
Essas tecnologias isolam processos, redes, usuários e sistemas de arquivos sem a necessidade de um sistema operacional completo por container.
É por isso que containers iniciam em poucos segundos e consomem muito menos memória que VMs tradicionais.
Capítulo 22 — Docker e DevOps
Docker revolucionou o DevOps porque eliminou um dos maiores problemas da engenharia de software: ambientes inconsistentes.
Hoje é possível:
Desenvolver localmente.
Testar em homologação.
Implantar em produção.
Tudo usando exatamente a mesma imagem.
Isso torna pipelines de CI/CD previsíveis e reproduzíveis.
Capítulo 23 — Docker no Mundo Mainframe
Você pode pensar:
"Mas eu trabalho com COBOL no IBM Z. O que Docker tem a ver comigo?"
A resposta é: muito.
Mesmo que aplicações COBOL rodem diretamente no z/OS, Docker é amplamente utilizado para hospedar ferramentas que fazem parte do ecossistema de desenvolvimento moderno:
Jenkins para automação de builds e deploys.
SonarQube para análise estática de código.
GitLab e Gitea para repositórios Git.
Nexus e Artifactory para gerenciamento de artefatos.
Bancos PostgreSQL, MariaDB e MongoDB para aplicações satélite.
Ambientes de testes para APIs REST que consomem serviços do z/OS Connect EE.
Ferramentas como Zowe CLI, Ansible e utilitários DevOps.
Assim, Docker não substitui o mainframe: ele o complementa, oferecendo um ecossistema ágil ao redor do IBM Z.
Boas Práticas
Use imagens oficiais sempre que possível.
Evite executar containers como usuário root.
Versione seus Dockerfiles junto com o código-fonte.
Utilize tags específicas (
nginx:1.28) em vez delatestpara garantir previsibilidade.Mantenha imagens pequenas, removendo dependências temporárias.
Faça limpeza periódica de recursos não utilizados com cautela.
Curiosidades
O mascote do Docker chama-se Moby Dock, uma baleia carregando contêineres.
Docker foi lançado em 2013 pela empresa dotCloud.
O formato de imagens e containers inspirou o padrão aberto OCI (Open Container Initiative).
Embora muita gente diga que "Kubernetes usa Docker", atualmente o Kubernetes conversa com runtimes compatíveis com OCI, como containerd e CRI-O, mantendo compatibilidade com imagens Docker.
Muitas distribuições Linux modernas já trazem ferramentas de containers integradas, mostrando como esse modelo se tornou um padrão da indústria.
Easter Egg Bellacosa Mainframe
No universo de Star Trek, o computador da USS Enterprise isola centenas de subsistemas críticos — navegação, comunicações, sensores, suporte de vida e controle dos motores de dobra — para que uma falha em um deles não comprometa toda a nave.
Os containers seguem exatamente essa filosofia: cada aplicação roda em um ambiente isolado, compartilhando apenas os recursos essenciais do sistema operacional. Se um serviço apresentar problemas, os demais continuam operando normalmente.
Essa ideia também ecoa no IBM Z. Assim como LPARs, z/VM e mecanismos de isolamento permitem executar múltiplas cargas de trabalho com segurança e eficiência, os containers oferecem isolamento leve e portabilidade para aplicações modernas.
Missão do Padawan COBOL: quando você entender que Docker não é apenas um conjunto de comandos, mas uma forma diferente de pensar a infraestrutura, terá dado um importante salto rumo ao universo de DevOps. Afinal, tecnologias mudam, ferramentas evoluem, mas os princípios de isolamento, automação, repetibilidade e confiabilidade permanecem — exatamente como ensinaria o Sr. Spock na ponte da Enterprise. 🚀
Sem comentários:
Enviar um comentário