Tutorial: Docker, Podman e Containerd: diferenças e quando usar

16 min de leitura  ·  Guia técnico

Docker, Podman e Containerd são as três principais tecnologias de containers Linux, cada uma com arquitetura e propósito distintos: o Docker oferece uma experiência completa com daemon centralizado, o Podman executa containers sem daemon e com suporte nativo a modo rootless, e o Containerd é o runtime de baixo nível usado internamente por ambos e pelo Kubernetes. Para escolher a ferramenta certa, entenda as diferenças práticas entre elas:

1. Identifique o contexto de uso: desenvolvimento local, produção em VPS ou cluster Kubernetes.
2. Avalie o modelo de segurança necessário: rootless (Podman) ou daemon privilegiado (Docker).
3. Verifique compatibilidade com seu orquestrador: Kubernetes usa Containerd diretamente.
4. Teste a compatibilidade de comandos e arquivos Compose com a ferramenta escolhida.
5. Configure o ambiente no servidor e valide com um container de teste.

Pré-requisitos para usar Docker, Podman ou Containerd

• Servidor Linux com kernel 5.4 ou superior (Ubuntu 24.04 LTS, Debian 12 ou Rocky Linux 9 são recomendados).
• Acesso root ou sudo ao servidor via SSH.
• Mínimo de 1 GB de RAM disponível; 2 GB ou mais para ambientes com múltiplos containers.
• Conexão com a internet para baixar imagens dos registries (Docker Hub, Quay.io, ghcr.io).
• Conhecimento básico de linha de comando Linux.
• Para Podman em modo rootless: usuário não-root com UID/GID mapeados em /etc/subuid e /etc/subgid.
• Para Containerd com Kubernetes: kubeadm ou distribuição Kubernetes já configurada.

Docker: arquitetura, instalação e quando usar

O Docker é a plataforma de containers mais conhecida do mercado e funciona com base em um daemon centralizado chamado dockerd, que roda como processo privilegiado no sistema. Toda comunicação entre o cliente Docker (CLI) e o daemon ocorre via socket Unix (/var/run/docker.sock), o que simplifica a experiência do desenvolvedor, mas introduz um ponto único de falha e um vetor de segurança relevante.

O Docker é ideal para desenvolvimento local, pipelines de CI/CD e ambientes onde a facilidade de uso é prioridade. Ferramentas como Docker Compose, Docker Desktop e uma vasta documentação comunitária tornam a curva de aprendizado mais suave. Se você já usa um servidor VPS Linux e quer subir aplicações rapidamente, o Docker ainda é a escolha mais direta.

Instalando o Docker no Ubuntu 24.04 LTS

Execute os comandos abaixo como root ou com sudo:

apt-get update
apt-get install -y ca-certificates curl gnupg
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | tee /etc/apt/sources.list.d/docker.list
apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifique a instalação:

docker version

Client: Docker Engine - Community
 Version:           26.x.x
 ...
Server: Docker Engine - Community
 Engine:
  Version:          26.x.x
  ...

Rode um container de teste:

docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Quando usar o Docker

• Desenvolvimento local: Docker Desktop e Compose simplificam ambientes multi-serviço.
• CI/CD: integração nativa com GitHub Actions, GitLab CI e Jenkins.
• Equipes iniciantes em containers: documentação extensa e comunidade ativa.
• Quando NÃO usar: ambientes Kubernetes em produção (prefira Containerd) ou quando segurança rootless é mandatória (prefira Podman).

Podman: containers sem daemon e modo rootless

O Podman (Pod Manager) é uma alternativa ao Docker desenvolvida pela Red Hat que elimina o daemon centralizado. Cada container é executado como um processo filho direto do usuário que o iniciou, sem nenhum processo privilegiado em segundo plano. Isso torna o Podman a escolha preferida em ambientes com requisitos de segurança elevados, como servidores de produção em Rocky Linux 9 ou AlmaLinux 9.

O modo rootless do Podman permite que usuários comuns executem containers sem nenhum privilégio de root, usando namespaces de usuário do kernel Linux. Isso reduz drasticamente a superfície de ataque em comparação com o Docker tradicional.

Instalando o Podman no Debian 12

apt-get update
apt-get install -y podman

Verifique a versão instalada:

podman version

Client:       Podman Engine
Version:      4.x.x
API Version:  4.x.x
Go Version:   go1.21.x
...

Executando containers em modo rootless

Como usuário não-root (por exemplo, deploy), execute:

podman run --rm -it alpine sh

Verifique que o processo não tem privilégios de root no host:

podman info | grep rootless

rootless: true

Compatibilidade com comandos Docker

O Podman é compatível com a maioria dos comandos Docker. Para facilitar a transição, crie um alias no seu shell:

echo "alias docker=podman" >> ~/.bashrc
source ~/.bashrc

A partir daí, comandos como docker run, docker build, docker pull e docker ps funcionarão via Podman. A exceção principal é o Docker Swarm, que o Podman não suporta.

Quando usar o Podman

• Servidores de produção com política de segurança restrita: modo rootless elimina riscos do daemon privilegiado.
• Ambientes Red Hat/CentOS Stream/Rocky Linux/AlmaLinux: Podman é o padrão nessas distribuições.
• Pods nativos: o Podman suporta o conceito de pods (grupos de containers compartilhando namespace de rede) sem Kubernetes.
• Quando NÃO usar: se sua equipe depende fortemente do Docker Desktop ou de funcionalidades exclusivas do Docker Swarm.

Containerd: o runtime de baixo nível para Kubernetes

O Containerd é um runtime de containers de nível industrial que gerencia o ciclo de vida completo dos containers: pull de imagens, armazenamento, execução e supervisão. Ele implementa a Container Runtime Interface (CRI) do Kubernetes e é o componente que o Docker usa internamente para executar containers — ou seja, quando você roda docker run, o Docker delega a execução real ao Containerd.

Você raramente interage com o Containerd diretamente em desenvolvimento. Ele se torna relevante quando você configura um cluster Kubernetes, pois a partir da versão 1.24 o Kubernetes removeu o suporte direto ao Docker como runtime, passando a exigir um runtime compatível com CRI — e o Containerd é o mais adotado nesse cenário. Para saber mais sobre infraestrutura de servidores Linux, consulte o guia de Configurando um Servidor Linux para Hospedagem de Sites.

Instalando o Containerd no Rocky Linux 9

dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
dnf install -y containerd.io
systemctl enable --now containerd

Verifique o status:

systemctl status containerd

● containerd.service - containerd container runtime
     Loaded: loaded (/usr/lib/systemd/system/containerd.service; enabled)
     Active: active (running) since ...

Interagindo com o Containerd via ctr

A CLI nativa do Containerd é o ctr. Para uso mais amigável, prefira o nerdctl, que replica a sintaxe do Docker:

nerdctl run --rm hello-world

Para configurar o Containerd como runtime do Kubernetes, edite o arquivo de configuração:

containerd config default | tee /etc/containerd/config.toml
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
systemctl restart containerd

Quando usar o Containerd diretamente

• Clusters Kubernetes: é o runtime padrão e recomendado para k8s 1.24+.
• Ambientes de produção mínimos: sem overhead de ferramentas de alto nível.
• Quando NÃO usar: para desenvolvimento local ou quando você precisa de uma CLI rica — use Docker ou Podman nesses casos.

Comparativo direto: Docker vs Podman vs Containerd

A escolha entre as três ferramentas depende do contexto de uso. Veja as diferenças práticas organizadas por critério:

• Arquitetura: Docker usa daemon (dockerd); Podman é daemonless; Containerd é um runtime de baixo nível sem CLI de alto nível nativa.
• Segurança: Podman suporta rootless nativamente; Docker requer configuração adicional para rootless; Containerd depende de como é invocado.
• Compatibilidade com Kubernetes: Containerd é o runtime padrão; Docker foi removido como runtime direto no k8s 1.24+; Podman não é usado como runtime k8s.
• Facilidade de uso: Docker tem a melhor experiência para iniciantes; Podman é quase idêntico ao Docker na CLI; Containerd exige ferramentas adicionais como nerdctl.
• Docker Compose: Docker tem suporte nativo via plugin; Podman suporta via podman-compose ou podman compose (v4.x+); Containerd não tem suporte nativo.
• Distribuições padrão: Docker é universal; Podman é padrão no RHEL, Rocky Linux, AlmaLinux e Fedora; Containerd é padrão em clusters Kubernetes gerenciados.
• Overhead de recursos: Docker tem overhead do daemon; Podman tem overhead mínimo; Containerd é o mais leve dos três.

Exemplo prático: subindo uma aplicação Node.js com cada ferramenta

Para ilustrar as diferenças na prática, veja como subir um container Node.js simples com cada runtime. O comportamento do container é idêntico — o que muda é a ferramenta de orquestração.

Com Docker

docker run -d --name app-node -p 3000:3000 node:20-alpine node -e "require('http').createServer((req,res)=>{res.end('OK Docker')}).listen(3000)"

curl http://localhost:3000
OK Docker

Com Podman (modo rootless)

podman run -d --name app-node -p 3000:3000 node:20-alpine node -e "require('http').createServer((req,res)=>{res.end('OK Podman')}).listen(3000)"

curl http://localhost:3000
OK Podman

Com Containerd via nerdctl

nerdctl run -d --name app-node -p 3000:3000 node:20-alpine node -e "require('http').createServer((req,res)=>{res.end('OK Containerd')}).listen(3000)"

curl http://localhost:3000
OK Containerd

Perceba que os três comandos são praticamente idênticos. A diferença real está no que acontece por baixo: o Docker delega ao Containerd via dockerd, o Podman executa diretamente via conmon e runc, e o nerdctl chama o Containerd diretamente.

Problemas comuns e como resolver

Sintoma: permissão negada ao rodar Docker sem sudo

Causa: o usuário não pertence ao grupo docker, que é necessário para acessar o socket /var/run/docker.sock.
Solução: adicione o usuário ao grupo e reinicie a sessão:

usermod -aG docker $USER
newgrp docker

Atenção: adicionar um usuário ao grupo docker equivale a conceder acesso root indireto ao sistema. Avalie se o modo rootless do Podman não é mais adequado para o seu caso.

Sintoma: Podman rootless não consegue mapear portas abaixo de 1024

Causa: no Linux, portas privilegiadas (abaixo de 1024) exigem capacidades de root por padrão.
Solução: ajuste o parâmetro do kernel para permitir que usuários não-root usem portas baixas, ou mapeie para uma porta alta e use um proxy reverso na frente:

sysctl -w net.ipv4.ip_unprivileged_port_start=80

Para tornar permanente, adicione ao /etc/sysctl.conf:

net.ipv4.ip_unprivileged_port_start=80

Sintoma: Containerd não inicia no Kubernetes — erro "failed to load plugin"

Causa: a configuração padrão do Containerd não habilita o SystemdCgroup, causando conflito com o cgroup driver do kubelet.
Solução: regenere a configuração e habilite o SystemdCgroup:

containerd config default > /etc/containerd/config.toml
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
systemctl restart containerd

Sintoma: imagens Docker não aparecem no Podman (e vice-versa)

Causa: Docker e Podman usam stores de imagens separados por padrão. O Docker armazena em /var/lib/docker e o Podman em ~/.local/share/containers (rootless) ou /var/lib/containers (root).
Solução: exporte a imagem do Docker e importe no Podman:

docker save minha-imagem:latest | podman load

Sintoma: docker-compose.yml não funciona com podman-compose

Causa: algumas diretivas específicas do Docker Swarm (deploy.replicas, configs de Swarm) não são suportadas pelo Podman.
Solução: remova ou adapte as diretivas incompatíveis. Para a maioria dos arquivos Compose padrão, o podman compose funciona sem alterações:

podman compose up -d

Perguntas frequentes sobre Docker, Podman e Containerd

Qual a diferença entre Docker e Podman na prática?

Docker usa um daemon centralizado (dockerd) que roda como root, enquanto o Podman executa containers sem daemon e suporta modo rootless nativamente. Na prática, os comandos são quase idênticos, mas o Podman oferece isolamento de segurança superior por não depender de um processo privilegiado em segundo plano. Para equipes que já usam Docker, a migração para Podman é geralmente transparente no nível da CLI.

Posso usar os mesmos comandos do Docker no Podman?

Sim, o Podman é compatível com a maioria dos comandos Docker. Você pode criar um alias alias docker=podman e usar praticamente todos os subcomandos como run, build, pull, push e compose. Exceções existem em funcionalidades específicas do Docker Swarm, que o Podman não suporta. Para a maioria dos fluxos de trabalho de desenvolvimento e produção, a compatibilidade é suficiente para uma migração sem atrito.

O que é Containerd e quando devo usá-lo diretamente?

Containerd é um runtime de baixo nível que gerencia o ciclo de vida dos containers — pull de imagens, execução e armazenamento. Ele é usado internamente pelo Docker e pelo Kubernetes. Você interage diretamente com o Containerd apenas em ambientes Kubernetes ou quando precisa de um runtime mínimo sem overhead de ferramentas de alto nível. Para uso cotidiano em desenvolvimento, prefira Docker ou Podman, que oferecem uma CLI mais rica e amigável.

Docker Compose funciona com Podman?

Sim, o Podman oferece o subcomando podman-compose e também suporta o plugin podman compose a partir da versão 4.x. A compatibilidade com arquivos docker-compose.yml é alta, mas algumas diretivas específicas do Docker Swarm ou funcionalidades de rede avançadas podem exigir ajustes. Para a maioria das aplicações web padrão com múltiplos serviços, o arquivo Compose funciona sem modificações.

Qual runtime de container é recomendado para Kubernetes?

Para Kubernetes, o Containerd é o runtime recomendado e mais amplamente adotado, pois implementa a Container Runtime Interface (CRI) diretamente. O Docker foi removido como runtime padrão do Kubernetes a partir da versão 1.24, embora imagens Docker continuem funcionando normalmente via Containerd. Se você está configurando um novo cluster Kubernetes, instale e configure o Containerd com SystemdCgroup = true para garantir compatibilidade total com o kubelet.

Conclusão

• Use Docker para desenvolvimento local, pipelines de CI/CD e quando a facilidade de uso e o ecossistema de ferramentas são prioridade.
• Use Podman em servidores de produção onde segurança é crítica, especialmente em distribuições Red Hat (Rocky Linux 9, AlmaLinux 9), aproveitando o modo rootless sem configuração extra.
• Use Containerd como runtime de Kubernetes em clusters de produção, configurando-o com SystemdCgroup habilitado e interagindo via nerdctl ou crictl para operações de diagnóstico.

Leia também

• Comparativo: Docker vs Podman para servidores Linux em 2026
• Manual do Docker: imagem, container e volume — diferenças práticas
• Entenda o Checklist de Segurança do Docker antes de ir ao ar

Precisa de ajuda com containers no seu servidor?

Configurar Docker, Podman ou Containerd em um ambiente de produção exige um servidor Linux estável, com recursos adequados e boa conectividade de rede. Um VPS bem dimensionado faz toda a diferença para rodar containers com performance e segurança.

Conheça os planos de VPS da AviraHost e comece a usar containers hoje