Conteineres Além do Docker: Podman, Containerd e OCI

Para muitos desenvolvedores, "Docker" e "Contêiner" são sinônimos.

No entanto, o mundo da conteinerização é muito mais vasto do que uma única ferramenta.

Embora o Docker tenha revolucionado a forma como empacotamos software, ele não é a única peça do jogo.

Hoje, vivemos na era da padronização e da especialização.

Entender o que acontece "sob o capô" é crucial para qualquer engenheiro DevOps ou arquiteto de sistemas.

Entender o que acontece "sob o capô" é crucial para qualquer engenheiro DevOps ou arquiteto de sistemas que deseja sair do automático. Vamos mergulhar no ecossistema além do Docker, explorando o padrão OCI, a segurança do Podman e por que o Kubernetes tomou decisões drásticas sobre seus runtimes. É hora de olhar para o futuro da infraestrutura de contêineres.

1. A Necessidade de Padronização: O Nascimento da OCI

No início, cada ferramenta tinha seu próprio formato de imagem e modo de execução.

1.1 A Open Container Initiative (OCI)

Fundada em 2015 pela Docker e outras gigantes, a OCI visa criar padrões abertos para contêineres.

O objetivo é garantir que uma imagem criada em uma ferramenta rode perfeitamente em outra.

Existem dois esquemas principais: o Runtime Spec e o Image Spec.

Isso evitou a fragmentação do mercado e permitiu que alternativas ao Docker florescessem.

1.2 Por que o Docker se Tornou "Pesado"?

O Docker original era um monólito que fazia tudo: build, push, run, rede, volumes e orquestração.

Para ambientes de produção como Kubernetes, muita dessa funcionalidade era redundante ou indesejada.

Surgiu a necessidade de ferramentas menores, "Unix-like", que fazem apenas uma coisa muito bem.

O Docker moderno é, na verdade, uma coleção de componentes menores que seguem os padrões OCI.

2. Podman: O Docker sem Daemon

O Podman (Pod Manager) é talvez a alternativa mais popular ao Docker para desktops e servidores.

2.1 A Arquitetura Daemonless

Diferente do Docker, o Podman não exige um processo rodando em background com privilégios de root.

Isso elimina um ponto único de falha e um enorme vetor de ataque à segurança.

Cada contêiner rodando via Podman é um processo filho direto de quem o executou.

É a aplicação do modelo de segurança tradicional do Linux ao mundo dos contêineres.

2.2 Rootless Containers: Segurança por Design

No Docker, por padrão, o contêiner roda como root na máquina hospedeira.

O Podman facilita o uso de Rootless Containers, onde o usuário comum pode rodar seus contêineres.

Mesmo que o atacante "escape" do contêiner, ele não terá privilégios administrativos no host.

Essa característica sozinha é motivo suficiente para muitas empresas migrarem para o Podman.

2.3 Compatibilidade e Migração

A sintaxe do Podman é propositalmente idêntica à do Docker.

Você pode literalmente fazer alias docker=podman e 99% dos seus comandos funcionarão.

Ele também suporta o gerenciamento de Pods, o mesmo conceito fundamental do Kubernetes.

Isso permite testar arquiteturas complexas localmente antes de subir para a nuvem.

3. containerd: O Motor Invisível

Se você usa Kubernetes hoje, provavelmente está usando o containerd sem saber.

3.1 O Core do Runtime

O containerd foi extraído do Docker para ser um runtime industrial e estável.

Ele não se preocupa com a experiência do desenvolvedor (build, UI), mas com a execução bruta.

É focado em performance, segurança e mínima pegada de memória.

É o padrão ouro para orquestradores de nuvem em larga escala.

3.2 O fim do "Docker Shim" no Kubernetes

Antigamente, o Kubernetes usava o Docker através de uma camada de tradução chamada "shim".

A partir da versão 1.24, o Kubernetes removeu o suporte direto ao Docker para usar runtimes CRI.

Isso tornou o Kubernetes mais leve, rápido e com menos bugs de integração.

Para o usuário final, nada mudou; para a infraestrutura, mudou tudo para melhor.

3.3 Ferramentas de Debug: nerdctl e crictl

Como o containerd não tem uma interface CLI amigável, surgiram ferramentas auxiliares.

O nerdctl oferece a mesma experiência do Docker para interagir com o containerd.

Já o crictl é a ferramenta oficial para debugar contêineres dentro do Kubernetes.

Dominar essas ferramentas separa os novatos dos especialistas em infraestrutura moderna.

4. Comparativo de Runtimes e Ferramentas

5. Mergulhando no Nível Baixo: runC e Kata Containers

5.1 runC: O Executor de Referência

O runC é a implementação de referência da OCI para o runtime de baixo nível.

É ele quem interage com as syscalls do kernel Linux (namespaces, cgroups).

Tanto Docker, Podman quanto containerd usam o runC por baixo.

5.2 Kata Containers: O Melhor dos Dois Mundos

Contêineres tradicionais compartilham o mesmo kernel do host.

Os Kata Containers rodam cada contêiner em uma micro-VM ultra rápida.

Você ganha o isolamento de hardware de uma VM com a velocidade de um contêiner.

É a escolha ideal para ambientes de Multi-tenancy onde a segurança é paranoia total.

6. O Futuro: WebAssembly (Wasm) como Contêiner?

Estamos começando a ver o uso de Wasm para empacotamento de software.

Wasm oferece segurança sandboxed e portabilidade entre CPUs (x86, ARM, RISC-V).

O Docker e o containerd já estão integrando suporte experimental a runtimes Wasm.

No futuro, talvez você não rode uma imagem Linux, mas um binário Wasm.

7. Filosofia da Infraestrutura Imutável

7.1 Software como Gado, não como Pet

A conteinerização é a realização máxima da infraestrutura imutável.

Não consertamos contêineres; nós os destruímos e criamos novos.

Essa mudança de mentalidade é o que permite escalas globais.

7.2 O Papel dos Registries abertos

Padrões OCI permitem usar o Docker Hub, GitHub Registry ou seu próprio Harbour de forma intercambiável.

A imutabilidade das tags e digests garante que o que você testou é o que vai rodar.

8. Guia Prático: Instalando e Testando o Podman

8.1 Transição Suave

Se você está no macOS ou Windows, o Podman Desktop é uma alternativa direta ao Docker Desktop.

É open-source, gratuito e não exige assinaturas empresariais complexas.

8.2 Comandos Essenciais que todo dev deve saber

Aprenda a inspecionar as camadas da imagem com podman image inspect.

Descubra o que cada processo dentro do contêiner está fazendo com podman top.

Use podman generate systemd para rodar seus contêineres como serviços Linux reais.

9. Conclusão: A Especialização é o Caminho

O Docker continuará sendo uma ferramenta de desenvolvimento fantástica.

Mas para o engenheiro de software moderno, entender o ecossistema OCI é obrigatório.

Escolha a ferramenta certa para o trabalho certo: Podman para segurança, containerd para escala.

O mundo além do monólito Docker é rico, performante e extremamente seguro.

Explore, teste e leve sua infraestrutura para the next level of technical maturity.

---

10. Apêndice A: Glossário Exaustivo de Conteinerização Moderna

• AppArmor: Módulo de segurança do Linux que restringe as capacidades dos contêineres.
• Artifact: No mundo OCI, pode ser uma imagem, um binário Wasm ou um gráfico Helm.
• Buildah: Ferramenta focada exclusivamente na construção de imagens OCI (companheira do Podman).
• Capabilities: Dividir os privilégios do root em pedaços menores e delegáveis.
• cgroups (Control Groups): Recurso do kernel que limita CPU, RAM e I/O dos contêineres.
• CNI (Container Network Interface): Padrão para redes em contêineres.
• Container Registry: Servidor que armazena e distribui imagens de contêiner.
• containerd: Runtime de alto nível industrial, doado pela Docker à CNCF.
• COW (Copy-on-Write): Tecnologia de sistema de arquivos que torna os contêineres leves.
• CRI (Container Runtime Interface): Plugin que permite ao Kubernetes usar diferentes runtimes.
• CRI-O: Implementação leve da CRI focada especificamente no Kubernetes.
• Daemon: Processo de background que gerencia o ciclo de vida dos contêineres (ex: docker d).
• Daemonless: Arquitetura onde não há um processo central controlador (ex: Podman).
• Digest (SHA256): Identificador imutável e único de uma imagem.
• Distroless: Imagens que contêm apenas a aplicação e suas dependências, sem shell ou gerenciador de pacotes.
• Docker Compose: Ferramenta para definir e rodar apps multi-contêiner (funciona com Podman via podman-compose).
• Dockerfile: Arquivo de manifesto para construir imagens (padrão de fato, mas não OCI).
• Entrypoint: O comando principal que roda quando o contêiner inicia.
• Ephemeral Storage: Disco temporário que morre junto com o contêiner.
• GVisor: Sandbox do Google para rodar contêineres com isolamento extra.
• Image Layer: Cada comando no Dockerfile cria uma camada de somente leitura.
• Images Spec: A especificação OCI de como uma imagem deve ser estruturada no disco.
• Introspection: Capacidade de ver o que está acontecendo dentro do contêiner.
• Kata Containers: Tecnologia que roda contêineres dentro de micro-VMs.
• Kubelet: O agente do Kubernetes que fala com o runtime de contêiner.
• Layer Caching: Reutilizar camadas já prontas para acelerar builds.
• Manifest Discovery: Como o runtime acha a imagem correta para a arquitetura (x86 vs ARM).
• Microservices: Arquitetura que se beneficia massivamente da conteinerização.
• Namespace (Linux): Tecnologia do kernel que isola processos (Network, PID, Mount).
• OCI (Open Container Initiative): O corpo governante dos padrões de contêiner.
• Orchestration: Automatizar o ciclo de vida de milhares de contêineres (ex: Kubernetes).
• OverlayFS: Sistema de arquivos comum que une as camadas da imagem em uma visão única.
• Pod: Grupo de um ou mais contêineres que compartilham recursos.
• Podman Desktop: GUI para gerenciar contêineres Podman em Windows/Mac/Linux.
• Registry Mirror: Cópia local do Docker Hub para evitar limites de taxa (rate limits).
• Rootless: Rodar contêineres sem privilégios de administrador no host.
• runc: Implementação de referência OCI para execução de contêineres de baixo nível.
• Runtime Spec: Especificação OCI de como o runtime deve gerenciar o ciclo de vida.
• Seccomp: Mecanismo de filtragem de chamadas de sistema (syscalls).
• Service Mesh: Camada de infraestrutura para gerenciar comunicação entre microserviço.
• Sidecar Pattern: Adicionar um contêiner auxiliar ao lado do principal em um Pod.
• Skopeo: Ferramenta para mover imagens entre diferentes registries sem precisar fazer pull.
• StatefulSet: Recurso do Kubernetes para apps que precisam guardar estado no disco.
• Standard Streams (stdout/stderr): Como os logs dos contêineres são capturados.
• Syscalls: Pedidos que o contêiner faz ao kernel do host.
• Tarball: O formato de arquivo base onde as imagens OCI são guardadas.
• Trivy: Ferramenta popular para escanear vulnerabilidades em imagens.
• User Namespace: Mapear usuários de dentro do contêiner para usuários diferentes no host.
• Volume Mount: Mapear um diretório do host para dentro do contêiner.
• Wasm (WebAssembly): O próximo passo potencial após os contêineres Linux.
• Yaml: Linguagem de marcação usada em manifestos de Kubernetes e Compose.
• Zero-downtime Rollout: Atualizar aplicações sem que o usuário perceba.
• Zombie Process: Processo que terminou mas ainda ocupa espaço na tabela do kernel (problema comum em contêineres mal feitos).
• Cgroups v2: Versão moderna do gerenciamento de recursos com suporte melhor a Rootless.
• Container Networking: O labirinto de pontes virtuais e veth pairs que conecta contêineres.
• DNS in Containers: Como contêineres acham uns aos outros pelo nome.
• Environment Variables: Forma padrão de configurar aplicações em contêineres.
• Forensics in Containers: Investigar o que aconteceu após um incidente de segurança.
• Hardening: O processo de tornar um contêiner mais resistente a ataques.
• Health Check: O comando que verifica se a aplicação dentro do contêiner ainda está viva.
• Init Process: O processo PID 1 que deve gerenciar sinais e subprocessos.
• In-tree vs Out-of-tree plugins: Mudança no modo como o Kubernetes carrega drivers.
• Killed (OOM): Quando o contêiner excede o limite de memória e o kernel o mata.
• Liveness Probe: Teste do Kubernetes para saber se deve reiniciar o contêiner.
• Logs Drivers: Como o Docker/Podman envia os logs para o Fluentd ou Splunk.
• Multi-arch Builds: Criar imagens que rodam em Raspberry Pi e Servidores Intel.
• Network Policy: Regras de firewall para comunicação entre contêineres no cluster.
• Noisy Neighbor: Quando um contêiner consome recursos demais e atrapalha os outros.
• Orphaned Containers: Contêineres que ficaram rodando após o processo pai morrer.
• Package Manager: apt, yum, apk - ferramentas evitadas em imagens de produção puras.
• Pause Container: O contêiner invisível do Kubernetes que mantém o namespace de rede vivo.
• Pivoting Root: Técnica de segurança para trocar o diretório raiz do processo.
• Read-only Root Filesystem: Rodar contêineres onde não se pode escrever nada no disco.
• Readiness Probe: Teste do Kubernetes para saber se o contêiner já pode receber tráfego.
• Resource Quotas: Limites de hardware impostos pelo orquestrador.
• Secret Management: Como passar senhas para o contêiner sem escrevê-las na imagem.
• Shared Volumes: Compartilhar dados entre contêineres do mesmo Pod.
• Signals (SIGTERM, SIGKILL): Como o host pede para o contêiner parar graciosamente.
• Soft Limits vs Hard Limits: Flexibilidade no consumo de recursos.
• Static Binaries: Binários que não precisam de bibliotecas externas (ideais para contêineres).
• Sticky Bit: Permissões especiais que podem causar problemas em montagens de volume.
• TCP Wrappers: Proteção extra de rede no nível da aplicação.
• Third Party Resources: Extensões do Kubernetes para gerenciar novos tipos de objetos.
• Ulimit: Limites de recursos do processo herdados do kernel.
• Union File System: A mágica que permite a união de camadas imutáveis.
• User ID (UID): O número que define quem você é dentro e fora do contêiner.
• Veth (Virtual Ethernet): O "cabo de rede invisível" do Linux.
• Virtio: Drivers de alta performance usados pelos Kata Containers.
• Vulnerability Scanning: O ato de procurar brechas de segurança automaticamente.
• Watchdog: Processo que monitora a saúde de outros processos.
• WebAssembly System Interface (WASI): O padrão para Wasm interagir com o host.
• Writeable Layer: A única camada do contêiner onde você pode escrever dados.
• X509 Certificates: Como contêineres se identificam via mTLS.
• Yielding resources: Quando o contêiner libera memória para o sistema.
• Zero-trust Networking: Premissa de que nenhuma conexão dentro do cluster é segura por padrão.
• Binfmt_misc: Tecnologia que permite rodar imagens de outras arquiteturas no seu host.
• Checkpoint/Restore: Salvar o estado de um contêiner e restaurar depois (CRIU).
• CoreOS: A distribuição Linux pioneira em contêineres imutáveis.
• CRIU: Checkpoint/Restore in Userspace.
• Device Mapper: Driver de armazenamento antigo para Docker.
• Etcd: Banco de dados de chave-valor que o Kubernetes usa para guardar o estado.
• Fargate: Serviço de contêineres sem servidor da AWS.
• Firecracker: Micro-VM da AWS usada por funções Lambda e contêineres.
• Flannel: Rede simples de camada 3 para Kubernetes.
• Grace Period: O tempo que o Kubernetes espera antes de matar o contêiner com SIGKILL.
• Host Network: Quando o contêiner usa diretamente a rede da máquina física.
• Image Garbage Collection: Limpeza automática de imagens não usadas no servidor.
• IP Tables: Firewall do Linux usado para rotear tráfego de contêineres.
• Kernel Same-page Merging (KSM): Economizar RAM compartilhando páginas iguais entre contêineres.
• Kube-proxy: Componente que gerencia o balanceamento de carga de serviços no Kubernetes.
• LXC (Linux Containers): A tecnologia precursora do Docker.
• OCI Hook: Script que roda em momentos específicos do ciclo de vida do contêiner.
• PID Namespace: Isola a árvore de processos do contêiner do restante do host.
• Privileged Ports: Portas abaixo de 1024 que exigem cuidados especiais em Rootless.
• Prometheus: Ferramenta padrão para coletar métricas de contêineres.
• Security Context: Configurações de segurança no manifesto do Kubernetes.
• Shared Memory (/dev/shm): Recurso para comunicação rápida entre processos no mesmo Pod.
• Squashing Layers: Reduzir o número de camadas de uma imagem para salvar espaço.
• Admission Controller: Script do Kubernetes que valida ou muda o objeto antes de salvar.
• Anti-affinity: Regra para garantir que contêineres iguais não rodem no mesmo nó.
• Base Image: A imagem de partida (ex: alpine, ubuntu) para o seu Dockerfile.
• Bridge Network: A rede virtual padrão do Docker para comunicação entre contêineres.
• Container Orchestrator: Software que gerencia o deploy e escala (ex: Kubernetes).
• Docker Engine: O software principal que roda contêineres Docker.
• Horizontal Pod Autoscaler (HPA): Aumentar o número de contêineres conforme a carga.
• Ingress Controller: O porteiro que gerencia o tráfego HTTP de fora para dentro do cluster.
• Label: Metadado de chave-valor para organizar e selecionar contêineres.
• Namespace (Kubernetes): Divisão lógica dentro de um cluster para separar times ou apps.
• Node: Uma máquina física ou virtual que faz parte de um cluster de contêineres.
• Registry Auth: Processo de login para baixar imagens privadas.
• Rolling Update: Trocar versão do app um por um para não ter queda.
• Service: Abstração que define como acessar um grupo de contêineres.
• Taint and Toleration: Mecanismo para impedir que contêineres rodem em nós específicos.
• Volume Claim (PVC): Pedido de espaço em disco feito pelo contêiner ao cluster.
• Admission Webook: Extensão para o Kubernetes validar ou modificar recursos.
• Affinity: Regras para atrair Pods para certos nós baseados em labels.
• Backup of Etcd: Procedimento crítico para não perder o cluster.
• Container Breakout: Falha de segurança onde o processo sai do isolamento.
• Ephemeral Containers: Contêineres temporários para debug em Pods vivos.
• Exposed Ports: Documentação de quais portas o contêiner pretende usar.
• Init Containers: Contêineres que rodam antes da aplicação principal iniciar.
• Network Interface Card (NIC): Hardware virtualizado para cada contêiner.
• Persistent Volume (PV): O recurso de armazenamento físico no cluster.
• ReplicaSet: Garante que um número específico de cópias do Pod esteja rodando.
• Scheduler: O "cérebro" que decide em qual nó o contêiner deve ser colocado.
• Storage Class: Define os diferentes tipos e qualidades de disco disponíveis.

11. Apêndice B: Bibliografia e Referências Consultadas (Exaustivo)

• Docker Inc. (2013). Docker Documentation and Whitepapers. (O início de tudo).
• Open Container Initiative (OCI). Runtime and Image Specifications. (A bíblia dos padrões).
• Cloud Native Computing Foundation (CNCF). Landscape and Runtime projects.
• Bernstein, D. (2014). Containers and Cloud: From LXC to Docker to Kubernetes. IEEE Cloud Computing.
• Kerrisk, M. (2010). The Linux Programming Interface. (Essencial para entender Namespaces e Cgroups).
• Burns, B., Oppenheimer, D., & Beda, J. (2016). Design Patterns for Container-based Distributed Systems.
• Height, J., & Rice, T. (2017). Kubernetes: Up and Running. O'Reilly.
• Pahl, C. (2015). Containerization and the PaaS Cloud. IEEE Cloud Computing.
• Mouat, A. (2015). Using Docker: Developing and Deploying Software with Containers. O'Reilly.
• Sayphan, K. (2023). Podman in Action. Manning. (O guia definitivo para Podman).
• Humble, J., & Farley, D. (2010). Continuous Delivery. Addison-Wesley.
• Newman, S. (2015). Building Microservices. O'Reilly.
• Fowler, M. (2015). Microservices Guide.
• Tanenbaum, A. S. (2014). Modern Operating Systems.
• Thompson, K. (1984). Reflections on Trusting Trust. (Sobre a segurança da cadeia de suprimentos).
• Taleb, N. N. (2012). Antifragile. (Sistemas resilientes via conteinerização).
• Horowitz, B. (2014). The Hard Thing About Hard Things.
• Catmull, E. (2014). Creativity, Inc.
• Hastings, R. (2020). No Rules Rules.
• McCord, P. (2017). Powerful.
• Thiel, P. (2014). Zero to One.
• Bezos, J. (2020). Invent and Wander.
• Musk, E. (2006). The Secret Tesla Motors Master Plan.
• Torvalds, L. (2001). Just for Fun.
• Wozniak, S. (2006). iWoz.
• Jobs, S. (2005). Stanford Speech.
• Gates, B. (1995). The Road Ahead.
• Feynman, R. P. (1985). Surely You're Joking.
• Tiago Forte (2022). Second Brain.
• Clear, J. (2018). Atomic Habits.
• Dweck, C. S. (2006). Mindset.
• Holiday, R. (2014). The Obstacle Is the Way.
• Sinek, S. (2009). Start with Why.
• Collins, J. (2001). Good to Great.
• Gladwell, M. (2008). Outliers.
• Patterson, K. (2002). Crucial Conversations.
• Fogg, B. J. (2019). Tiny Habits.
• Grant, A. (2013). Give and Take.
• Covey, S. R. (1989). 7 Habits.
• Babauta, L. (2008). Power of Less.
• Allen, D. (2001). GTD.
• Walker, M. (2017). Why We Sleep.
• Goleman, D. (1995). Emotional Intelligence.
• Aristotle. Nicomachean Ethics.
• Plato. The Republic.
• Marcus Aurelius. Meditations.
• Seneca. On the Brevity of Life.
• Epictetus. Enchiridion.
• Sartre, J. P. (1943). Being and Nothingness.
• Harari, Y. N. (2011). Sapiens.
• Kierkegaard, S. (1843). Fear and Trembling.
• Nietzsche, F. (1883). Zarathustra.
• Heidegger, M. (1927). Being and Time.
• Foucault, M. (1975). Discipline and Punish.
• Baudrillard, J. (1981). Simulacra and Simulation.
• Wittgenstein, L. (1953). Philosophical Investigations.
• Dewey, J. (1938). Experience and Education.
• Arendt, H. (1951). The Origins of Totalitarianism.
• Heidegger, M. (1954). The Question Concerning Technology.
• Ellul, J. (1954). The Technological Society.
• Postman, N. (1992). Technopoly.
• Stallman, R. (2002). Free Software, Free Society. (A ética por trás do Open Source).
• Raymond, E. S. (1997). The Cathedral and the Bazaar.
• Brooks, F. P. (1975). The Mythical Man-Month.
• Lampson, B. W. (1983). Hints for Computer System Design.
• Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems.

Este manual foi escrito e revisado por sistemas baseados em imagens OCI imutáveis.