Containerd vs Docker: Entendendo os tempos de execução dos contêineres

No mundo dos contêineres, uma fonte comum de confusão surge quando os desenvolvedores comparam o Docker (uma plataforma completa) com o containerd, que na verdade é um componente de tempo de execução específico. Essa comparação é como comparar um carro completo com o seu motor: os dois são essenciais, mas têm funções diferentes em níveis diferentes de abstração. 

Neste guia, vou explicar a relação entre essas duas tecnologias, falando sobre suas arquiteturas, integração com o Kubernetes e os cenários específicos em que cada ferramenta se destaca. Se você está criando contêineres localmente ou gerenciando clusters Kubernetes de produção, saber quando usar o Docker ou o containerd pode fazer uma grande diferença nas suas decisões de infraestrutura.

Ao final deste artigo, você vai entender direitinho como o Docker e o containerd se complementam e como escolher a ferramenta certa para suas necessidades específicas, seja para desenvolvimento local rápido ou implantações de produção em grande escala.

Se você é novo no mundo da conteinerização, recomendo muito fazer nosso curso Conceitos de conteinerização e virtualização.

O que é o Docker?

O Docker mudou o jeito de desenvolver software, tornando a conteinerização acessível e prática para os desenvolvedores no dia a dia. Como uma plataforma completa, o Docker oferece tudo o que você precisa para criar, enviar e rodar aplicativos em contêineres.

Pra quem tá começando, esse Guia Prático de Contêineresé uma ótima introdução ao Docker e aos contêineres.

Uma plataforma de contêineres completa

O Docker funciona como uma plataforma de contêineres tudo-em-um, oferecendo um conjunto de ferramentas integradas que cobre a maior parte do ciclo de vida dos contêineres. Basicamente, o Docker empacota aplicativos com todas as suas dependências em imagens portáteis e independentes que podem ser executadas de forma consistente em qualquer ambiente, desde o laptop de um desenvolvedor até servidores de produção.

Essa abordagem abrangente fez do Docker o padrão da indústria para desenvolvimento local e experiência do desenvolvedor. Algumas das principais vantagens são:

• Ecossistema extenso: O Docker Hub tem milhões de imagens pré-construídas, desde bancos de dados até servidores web, eliminando procedimentos de instalação complicados.
• Portabilidade universal: Um contêiner criado no macOS funciona igual no Linux ou no Windows, desde que o Docker esteja instalado.
• Foco do desenvolvedor: Resume as diferenças de infraestrutura para que os desenvolvedores possam se concentrar em suas aplicações, em vez de se preocuparem com as complexidades da implantação.
• Integração rápida: Os novos membros da equipe podem criar ambientes de desenvolvimento em minutos, em vez de horas.

Componentes principais e fluxo de trabalho

A arquitetura do Docker é composta por vários componentes interligados que funcionam juntos de forma integrada. 

A CLI do Docker oferece uma interface para o usuário, onde os desenvolvedores podem dar comandos. Quando você executa um comando como ` docker run`, a CLI se comunica com o daemon do Docker (`dockerd`), que funciona como o serviço principal que gerencia contêineres, imagens, redes e volumes.

Para quem usa Windows e macOS, o Docker Desktop traz uma camada extra de praticidade com uma interface gráfica, tornando o gerenciamento de contêineres acessível até mesmo para quem não tem muita familiaridade com ferramentas de linha de comando. Esse ambiente integrado tem tudo que você precisa para desenvolvimento local, desde suporte ao Kubernetes até gerenciamento de volume.

O fluxo de trabalho típico segue um padrão bem claro: 

1. Os desenvolvedores criam imagens usando Dockerfiles.
2. Eles enviam para registros como o Docker Hub.
3. Por fim, as imagens são executadas como contêineres em qualquer host habilitado para Docker. 

O que muitos desenvolvedores não percebem é que o Docker não executa contêineres diretamente. Em vez disso, o dockerd deixa o containerd cuidar da execução do contêiner, que rola em segundo plano como um processo separado.

Esse design modular, em que o Docker usa o containerd para operações de baixo nível, permite que cada componente se concentre no que faz de melhor: O Docker oferece uma interface e um ecossistema fáceis de usar para desenvolvedores, enquanto o containerd cuida dos detalhes da execução dos contêineres.

Se você está começando a usar o Docker ou quer dar o próximo passo, confira nossas 10 ideias de projetos Docker para todos os níveis.

O que é o Containerd?

Depois de ver a abordagem abrangente da plataforma do Docker, vamos agora dar uma olhada no containerd, o runtime especializado que faz os contêineres funcionarem tanto dentro do Docker quanto em todo o ecossistema.

Um tempo de execução de contêiner padrão do setor

O Containerd é um runtime de contêiner leve e padrão da indústria que se formou na Cloud Native Computing Foundation (CNCF), o que mostra sua maturidade, confiabilidade e ampla adoção. Originalmente parte do Docker, o containerd foi extraído em 2017 e doado à CNCF para permitir uma adoção mais ampla do ecossistema.

Diferente do conjunto completo de recursos do Docker, o escopo do containerd é bem limitado de propósito: ele cuida das operações principais do ciclo de vida do contêiner, como iniciar, parar, pausar e excluir, além de lidar com a transferência e o armazenamento de imagens. Essa abordagem focada torna o containerd super estável e eficiente, qualidades essenciais para ambientes de produção.

Pense no containerd como uma “tubulação”: uma infraestrutura feita pra ser incorporada em sistemas maiores, em vez de ser usada diretamente por pessoas. Grandes plataformas como Kubernetes, AWS Fargate e Google Kubernetes Engine dependem do containerd para rodar contêineres, mesmo que os usuários interajam com essas plataformas por meio de suas próprias interfaces.

Arquitetura e design

Pra entender por que o containerd é tão usado em sistemas de produção, a gente precisa dar uma olhada nos princípios da sua arquitetura.

A arquitetura do Containerd mostra bem os princípios do design modular. Feito com os padrões da Open Container Initiative (OCI) no centro, o containerd garante compatibilidade em todo o ecossistema de contêineres. Isso quer dizer que qualquer imagem compatível com OCI vai funcionar com o containerd, não importa qual ferramenta a criou.

A arquitetura tem algumas camadas principais:

• Camada da API gRPC: Oferece um modelo cliente-servidor onde vários clientes (Docker, Kubernetes, ferramentas personalizadas) se comunicam com uma única instância do containerd.
• Daemon Containerd: Mantém o estado dos contêineres em execução, gerencia o armazenamento de imagens por meio de snapshotters e coordena a rede por meio de plug-ins.
• runtime runc: Um runtime leve e compatível com OCI que se conecta direto com os recursos do kernel Linux, criando namespaces, configurando cgroups e iniciando processos de contêineres.
• Plugins modulares: Snapshotters personalizados para armazenamento especializado, tempos de execução alternativos (gVisor, Kata Containers) e plug-ins de rede podem ser integrados sem modificar o containerd.

Quando o containerd precisa iniciar um contêiner, ele gera o runc, que faz o trabalho de criar namespaces isolados, configurar cgroups para limites de recursos e iniciar o processo do contêiner. 

Essa separação de responsabilidades torna o containerd super flexível. As organizações podem personalizar quase tudo sem mexer no código principal do containerd.

Principais diferenças entre o Containerd e o Docker

Com uma boa noção do que cada ferramenta faz, vamos ver como elas são diferentes na prática, desde a arquitetura até os padrões de integração.

Tempo de execução do contêiner vs plataforma

A diferença principal está no escopo e no objetivo. 

O Docker usa uma arquitetura de daemon centralizada, na qual um dockerd e coordena vários aspectos diferentes, como:

• Construção de imagem
• Execução do contêiner
• Rede de contatos
• Gerenciamento de volume

Esse design tudo-em-um simplifica a experiência do desenvolvedor, mas traz uma sobrecarga por causa das várias camadas de abstração.

Já o Containerd é mais focado na execução de contêineres. Não inclui recursos de criação de imagens, recursos de orquestração ou uma interface gráfica. Para redes, o Docker inclui um Libnetwork e embutida no seu daemon, enquanto o containerd usa plugins externos de Interface de Rede de Contêiner (CNI) que podem ser trocados conforme o que for preciso.

Essa diferença arquitetônica tem implicações no desempenho. Em ambientes com alta rotatividade, onde os contêineres são iniciados e parados com frequência, como clusters Kubernetes com autoescalonamento, o design simplificado do containerd pode resultar em tempos de inicialização mais rápidos e menor consumo de recursos. A redução da sobrecarga significa que o containerd usa menos memória e CPU, o que se torna significativo em grande escala.

Integração com o Kubernetes

Falando do Kubernetes, a relação entre os tempos de execução de contêineres e as plataformas de orquestração mudou bastante, principalmente em relação a como o Kubernetes se conecta ao containerd.

A relação entre o Kubernetes e os tempos de execução de contêineres mudou bastante com o Kubernetes 1.24, lançado em 2022. Essa versão tirou o “Dockershim”, uma camada de compatibilidade que deixava o Kubernetes usar o Docker como seu tempo de execução de contêiner.

A Dockershim sempre foi pensada como uma ponte temporária. Quando o Kubernetes lançou a Interface de Tempo de Execução de Contêiner (CRI) pra padronizar a comunicação com os tempos de execução, o Docker não conseguiu implementar isso direto porque ele já existia antes do design da CRI. O Dockershim fazia a tradução entre o Kubernetes e o Docker, adicionando uma camada de tradução que acabou sendo desnecessária.

As versões modernas do Kubernetes se comunicam diretamente com o containerd por meio do CRI, eliminando totalmente a camada de tradução do Docker. Essa simplificação traz benefícios concretos:

• Latência reduzida: A comunicação direta elimina os custos de tradução nas operações com contêineres.
• Estabilidade melhorada: Menos peças móveis significam menos pontos de falha em potencial.
• Melhor desempenho: A pilha de tempo de execução simplificada é ótima para implantações em grande escala.
• Depuração simplificada: A integração direta do CRI torna o diagnóstico de problemas mais simples.

Para quem usa o Kubernetes, essa mudança é bem transparente. As imagens do Docker continuam totalmente compatíveis porque seguem os padrões OCI. Na prática, isso quer dizer que os clusters Kubernetes de produção agora funcionam melhor usando o containerd direto, enquanto os desenvolvedores podem continuar usando o Docker localmente para construir e testar.

Se você não tem certeza sobre as vantagens e desvantagens de usar o Kubernetes, dê uma olhada nessa comparação entre o Docker Compose e o Kubernetes.

Construção e gestão de imagem

Embora a integração em tempo de execução seja essencial para a orquestração, o fluxo de trabalho do desenvolvedor depende muito de como cada ferramenta lida com a criação e o armazenamento de imagens. A criação de imagens mostra uma diferença grande de capacidade entre o Docker e o containerd. 

O Docker oferece um sistema de compilação integrado por meio de Dockerfiles e BuildKit, permitindo que os desenvolvedores criem compilações complexas em várias etapas com cache, paralelização e recursos avançados, como segredos de compilação e encaminhamento de agente SSH.

O Containerd, por padrão, não inclui nenhum fluxo de trabalho nativo para a criação de imagens. Para criar imagens com o containerd, os desenvolvedores precisam usar ferramentas externas. As opções incluem rodar o BuildKit como um daemon separado e usar o buildctl para compilações de linha de comando, ou adotar o nerdctl, uma CLI compatível com Docker que integra o BuildKit.

Os mecanismos de armazenamento também têm filosofias diferentes. O gerenciamento de volumes do Docker oferece uma abstração que parece natural para os desenvolvedores, com volumes nomeados que mantêm os dados independentemente do ciclo de vida dos contêineres. O Containerd usa um sistema de snapshot mais básico, onde diferentes drivers de snapshot podem ser conectados para lidar com sistemas de arquivos em camadas de maneiras diferentes, dependendo dos requisitos de armazenamento.

Essa diferença mostra para quem essas ferramentas foram feitas: 

• O Docker otimiza a produtividade dos desenvolvedores com recursos integrados que facilitam a vida.
• O Containerd oferece primitivas flexíveis que os criadores de plataformas podem montar de acordo com suas necessidades específicas.

CLI, experiência do desenvolvedor e nerdctl

Além da arquitetura e dos recursos, a experiência diária do desenvolvedor é moldada mais diretamente pela interface de linha de comando que cada ferramenta oferece. A experiência da linha de comando mostra bem as diferentes filosofias de design. 

A CLI do Docker é famosa por ser super fácil de usar. Comandos como docker run, docker build e docker logs são intuitivos, bem documentados e feitos para pessoas. A CLI tem padrões úteis, mensagens de erro claras e várias opções que cobrem a maioria dos casos de uso.

O containerd vem com o ` ctr`, uma CLI minimalista feita só para depurar e testar as funcionalidades de baixo nível do containerd. A ferramenta ctr é bem complicada para os desenvolvedores. Faltam recursos comuns, como atalhos de mapeamento de portas, políticas de reinício automático e integração com auxiliares de credenciais. Foi feito pra desenvolvedores de contêineres, não pra desenvolvedores de aplicativos.

Preenchendo a lacuna com o nerdctl

Essa lacuna de usabilidade levou à criação do nerdctl, uma CLI compatível com o Docker para o containerd. Usar o nerdctl é igual a usar o Docker, com a mesma sintaxe de comando, os mesmos sinalizadores, o mesmo fluxo de trabalho, mas com o containerd como o tempo de execução por baixo. Isso faz do nerdctl uma excelente ponte para equipes que estão mudando do Docker para o containerd em ambientes de desenvolvimento.

Na prática, os desenvolvedores raramente interagem diretamente com o containerd. Quando precisam, o nerdctl oferece a interface familiar que eles esperam, enquanto os operadores e administradores da plataforma usam as APIs do containerd de forma programática por meio de sistemas de orquestração como o Kubernetes.

Pra mostrar as diferenças na prática, veja como as operações comuns de contêineres se comparam nas três ferramentas CLI:

Observação: o ctr do não tem mapeamento de porta (-p) e precisa de rede de host (--net-host) para mostrar os serviços. Ele também não pega as imagens automaticamente.

Visão geral das principais diferenças

Antes de entrarmos nas recomendações para casos de uso específicos, vamos recapitular as diferenças que abordamos até agora. A tabela a seguir resume as principais diferenças funcionais entre o Docker e o containerd, destacando suas capacidades distintas e públicos-alvo:

Por que escolher o Docker?

Agora que já falamos sobre as diferenças técnicas, vamos ver alguns cenários práticos em que cada ferramenta se destaca. Mesmo com o crescimento do containerd nos ambientes de produção, o Docker continua sendo a melhor escolha para situações específicas em que a experiência do desenvolvedor e ferramentas completas são super importantes.

Para desenvolvimento local e prototipagem

O Docker é ótimo quando você precisa de uma solução “tudo em um” pra escrever e testar código. A cadeia de ferramentas integrada significa que os desenvolvedores podem passar do zero à execução de contêineres em minutos, sem precisar montar vários componentes ou configurar redes complexas.

O ecossistema Docker traz um monte de vantagens de produtividade:

• Docker Hub: Milhões de imagens prontas para usar em bancos de dados, filas de mensagens e servidores web
• Docker Compose: Defina aplicativos com vários contêineres em um único arquivo YAML e crie ambientes de desenvolvimento completos com um único comando.
• GUI do Docker Desktop: Gerenciamento visual de contêineres, navegação por volume, ajustes de limite de recursos e suporte integrado ao Kubernetes
• Menos obstáculos pra entrar no mercado: Ferramentas gráficas e comandos intuitivos tornam os contêineres acessíveis para desenvolvedores que estão começando a usar essa tecnologia.

Para equipes que usam o Docker Desktop, a interface gráfica oferece conveniências adicionais que aceleram significativamente a integração e os fluxos de trabalho diários.

Para pipelines de compilação complexos

Além do desenvolvimento, os recursos de compilação do Docker fazem dele a escolha natural para fluxos de trabalho sofisticados de integração e implantação contínuas.

O BuildKit integrado do Docker oferece recursos avançados essenciais para pipelines modernos de CI/CD. As compilações em várias etapas diminuem o tamanho das imagens e ainda deixam os Dockerfiles fáceis de ler. Os mecanismos de cache do BuildKit reutilizam camadas de forma inteligente entre compilações, reduzindo drasticamente os tempos de compilação em ambientes de integração contínua.

A maioria das plataformas de automação, como GitHub Actions, GitLab CI, Jenkins e outras, têm integrações Docker maduras e testadas em batalha. Essas integrações cuidam da autenticação, do cache e da publicação de imagens sem nenhum problema. 

Embora outras ferramentas possam alcançar resultados parecidos, a popularidade do Docker faz com que as soluções e a ajuda para resolver problemas estejam sempre à mão, o que é outra grande vantagem.

Por que escolher o Containerd?

O Containerd é ótimo em cenários de produção onde o minimalismo, o desempenho e a estabilidade são mais importantes do que a conveniência das ferramentas integradas.

Para clusters Kubernetes de produção

Usar o containerd como tempo de execução para os nós do Kubernetes traz benefícios que a gente pode medir:

• Custos gerais reduzidos: Eliminar o daemon do Docker significa menos consumo de recursos por nó e uma economia significativa em escala.
• Estabilidade melhorada: Menos peças móveis significam menos pontos de falha em potencial na sua infraestrutura.
• Superfície de ataque menor: Menos código para auditar e menos vulnerabilidades potenciais de segurança
• Depuração simplificada: A integração direta do CRI elimina a camada de tradução do dockershim, facilitando o diagnóstico de problemas.
• Melhor desempenho: A pilha de tempo de execução simplificada melhora os tempos de inicialização e a capacidade de resposta dos contêineres.

O status de graduação do Containerd na CNCF mostra que ele está maduro e é confiável. Os principais provedores de nuvem, incluindo AWS, Google Cloud e Azure, padronizaram o containerd para suas ofertas gerenciadas do Kubernetes, mostrando que confiam na sua prontidão para produção em infraestruturas críticas.

Para ambientes especializados e minimalistas

Embora o Kubernetes seja o caso de uso mais comum em produção, a natureza leve do containerd abre as portas para cenários de implantação em que o Docker seria impraticável.

A computação de ponta e os dispositivos IoT geralmente funcionam com recursos bem limitados. O design leve do Containerd torna-o viável nesses ambientes onde a pilha completa do Docker seria proibitiva. Cada megabyte de memória e cada ciclo da CPU são importantes quando se trabalha com hardware incorporado.

Os cenários de segurança avançados se beneficiam da arquitetura de tempo de execução modular do containerd. As organizações podem integrar tempos de execução em sandbox para cargas de trabalho que precisam de limites de segurança extras. Exemplos incluem:

• gVisor: oferece um isolamento robusto do kernel
• Kata Containers: roda contêineres em VMs leves

Essas integrações se conectam ao containerd sem precisar de muitas mudanças.

Migração do Docker para o Containerd

Entender quando usar cada ferramenta é importante, mas saber como alternar entre elas é igualmente crucial. A transição do Docker para o containerd em ambientes existentes precisa de um planejamento cuidadoso, mas o processo é bem documentado e simples.

Migrando nós do Kubernetes

As etapas operacionais para migrar nós do Kubernetes do Docker para o containerd seguem um padrão padrão:

1. Cordão do nó: Evite que novos pods sejam agendados (kubectl cordon )

2. Esvazie os pods existentes: Migrar cargas de trabalho para outros nós (kubectl drain )

3. Atualizar a configuração do Kubelet: Aponte para o soquete CRI do containerd em /run/containerd/containerd.sock

4. Verifique os plugins CNI: Certifique-se de que o containerd tenha os plug-ins de rede necessários instalados.

5. Reinicie o Kubelet: Registre-se com o novo tempo de execução e volte a entrar no cluster.

Testar a migração primeiro em nós que não são de produção ajuda a identificar problemas específicos do ambiente antes de implementar alterações em todo o cluster. Para evitar erros comuns, certifique-se de seguir as seguintes práticas recomendadas:

• Alterações no caminho do log: O Docker e o containerd usam locais de log padrão diferentes, então atualize sua infraestrutura de log de acordo com isso.
• Instale os plugins CNI que estão faltando: O Containerd precisa dos binários do plugin CNI para funcionar com redes; eles nem sempre vêm instalados por padrão.
• Fica de olho nas diferenças de puxada de imagem: As configurações de autenticação e registro podem precisar de ajustes.
• Cuidado com incompatibilidades de drivers de armazenamento: Certifique-se de que seus volumes persistentes sejam compatíveis com o snapshotter do containerd.

Navegando pelas diferenças da CLI

Depois que sua infraestrutura for migrada, os desenvolvedores precisam adaptar seus fluxos de trabalho diários para trabalhar com o novo tempo de execução.

Pra desenvolvedores que já conhecem os comandos do Docker, o nerdctl oferece uma experiência quase igual. Comandos como nerdctl run, nerdctl build e nerdctl compose up funcionam exatamente como seus equivalentes no Docker, tornando a transição perfeita.

Para depurar, é essencial entender como mapear os fluxos de trabalho de depuração do Docker para o containerd. Quando você usa o comando ` docker inspect ` para examinar um contêiner, o comando ` ctr containers info ` fornece informações semelhantes, embora em um formato diferente. Da mesma forma, ctr tasks list mostra os contêineres em execução.

A maioria dos desenvolvedores acha que o nerdctl elimina a necessidade de aprender a sintaxe do ctr para tarefas do dia a dia. O ctr de baixo nível continua sendo útil para resolver problemas específicos de tempo de execução ou quando se trabalha diretamente com as APIs do containerd.

Conclusão

A relação entre o Docker e o containerd é um exemplo perfeito de design modular bem-sucedido em infraestrutura de software. O Docker continua sendo a ferramenta ideal para quem escreve código, já que oferece uma experiência integrada, um ecossistema completo e interfaces fáceis de usar para desenvolvedores, o que torna a criação de aplicativos em contêineres produtiva (e divertida).

Já o Containerd é ótimo como ambiente de execução para máquinas que rodam código,oferecendo a estabilidade, o desempenho e o minimalismo necessários para plataformas de orquestração de produção. O fato de o Docker Engine usar o containerd nos bastidores mostra como as duas ferramentas se complementam, em vez de competirem entre si.

Eu recomendo uma abordagem prática para a maioria das organizações: continuar usando o Docker nos laptops dos desenvolvedores, onde suas ferramentas aceleram os fluxos de trabalho de desenvolvimento, mas pensar em migrar os clusters Kubernetes de produção diretamente para o containerd, por causa das vantagens operacionais de redução de sobrecarga e simplificação das pilhas de tempo de execução.

Se você escolher a plataforma completa do Docker ou o tempo de execução focado do containerd, os dois continuam sendo partes essenciais do ecossistema moderno de contêineres, cada um otimizado para diferentes fases do ciclo de vida da aplicação.

Para continuar aprendendo, inscreva-se no nosso programa de Containerização e Virtualização com Docker e Kubernetes.