As diferenças práticas entre Podman e Docker

1. Docker e Podman fazem a mesma coisa?

Em grande parte, sim. Os dois trabalham com imagens e contêineres compatíveis com os padrões da Open Container Initiative, a OCI.

Uma imagem criada com Docker normalmente pode ser executada com Podman. Da mesma forma, uma imagem criada com Podman pode ser enviada para um registro e utilizada pelo Docker.

Um Dockerfile simples como este pode ser processado pelas duas ferramentas:

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80

Com Docker:

$ docker build -t meu-site .

Com Podman:

$ podman build -t meu-site .

Embora o Podman também aceite o nome Dockerfile, sua documentação costuma usar o termo Containerfile. A sintaxe interna é a mesma. A documentação do Podman confirma a compatibilidade com os dois nomes.

2. A principal diferença: o daemon

O Docker tradicionalmente trabalha com uma arquitetura cliente-servidor. Quando executamos:

$ docker ps

o comando docker envia uma solicitação para um processo chamado dockerd. Esse processo permanece continuamente em execução e administra imagens, redes, volumes e contêineres.

Podemos verificar o daemon do Docker com:

$ systemctl status docker

A arquitetura pode ser representada assim:

O Podman foi projetado como uma ferramenta *daemonless*, ou seja, não depende de um daemon central permanentemente ativo. Quando executamos um comando, o próprio Podman realiza a operação necessária.

Isso não significa que os contêineres do Podman deixam de funcionar quando o comando termina. O Podman utiliza componentes auxiliares para acompanhar os processos, mas não precisa manter um serviço central equivalente ao dockerd.

Na prática, isso produz uma diferença importante. Se o daemon do Docker estiver parado, comandos como este não funcionarão:

$ docker ps

Podemos encontrar uma mensagem semelhante a:

Cannot connect to the Docker daemon

Com Podman, não existe um daemon central que precise estar ativo para que o comando seja executado. A própria documentação define o Podman como um mecanismo de contêineres sem daemon e com uma interface comparável à do Docker. Consulte a descrição oficial do Podman.

3. Execução como usuário comum

Uma das características mais conhecidas do Podman é o suporte ao modo *rootless*. Nesse modo, o usuário cria e executa contêineres sem utilizar sudo e sem conceder privilégios administrativos à ferramenta.

$ podman run --rm alpine id

A saída poderá mostrar algo semelhante a:

uid=0(root) gid=0(root) groups=0(root)

Embora o processo apareça como root dentro do contêiner, ele está associado a um usuário sem privilégios fora dele. Isso é feito por meio de namespaces de usuários e do mapeamento de identificadores UID e GID.

É possível examinar os mapeamentos utilizados pelo usuário:

$ podman unshare cat /proc/self/uid_map

O Docker também oferece um modo rootless. Portanto, seria incorreto afirmar que somente o Podman pode executar contêineres dessa maneira. A diferença prática é que o modo rootless ocupa uma posição central no projeto do Podman, enquanto no Docker ele é uma configuração que precisa ser ativada separadamente. O Docker documenta os requisitos e a instalação do seu modo rootless.

Para conferir o modo utilizado pelo Podman:

$ podman info --format '{{.Host.Security.Rootless}}'

Se o resultado for true, o Podman está operando sem privilégios administrativos.

4. O usuário vê apenas os próprios contêineres

No Podman rootless, os contêineres pertencem ao usuário que os criou.

Se o usuário ana executar:

$ podman run -d --name servidor nginx

e o usuário paulo executar:

$ podman ps

Paulo não verá o contêiner de Ana.

Nem mesmo uma execução com sudo acessa automaticamente os mesmos contêineres:

$ podman ps

e:

$ sudo podman ps

representam ambientes distintos. O primeiro mostra os contêineres rootless do usuário atual. O segundo mostra os contêineres administrados pelo Podman como root.

Essa separação é vantajosa em servidores compartilhados, mas pode confundir quem está começando. Um contêiner aparentemente “desaparecido” talvez tenha sido iniciado por outro usuário ou com um nível diferente de privilégio.

5. Os comandos básicos são quase iguais

Na maior parte das tarefas cotidianas, a migração é simples.

Podemos testar um servidor web com Docker:

$ docker run -d \
    --name servidor-web \
    -p 8080:80 \
    nginx

O equivalente com Podman é:

$ podman run -d \
    --name servidor-web \
    -p 8080:80 \
    nginx

Depois, acesse:

http://localhost:8080

Essa compatibilidade permite até a criação de um alias:

alias docker=podman

O próprio manual do Podman menciona essa possibilidade. Entretanto, o alias deve ser visto como uma conveniência, não como uma garantia de compatibilidade absoluta. Scripts mais complexos, integrações que acessam diretamente o socket do Docker e opções específicas de cada ferramenta podem exigir adaptações.

6. As imagens não aparecem automaticamente nas duas ferramentas

Embora os formatos sejam compatíveis, Docker e Podman mantêm áreas de armazenamento próprias.

Se uma imagem for criada com Docker:

$ docker build -t minha-aplicacao .

ela não aparecerá necessariamente em:

$ podman images

O inverso também é verdadeiro.

Uma forma de transferir a imagem é exportá-la:

$ docker save minha-aplicacao:latest \
    -o minha-aplicacao.tar

Depois, importe-a no Podman:

$ podman load \
    -i minha-aplicacao.tar

Para fazer o caminho inverso:

$ podman save minha-aplicacao:latest \
    -o minha-aplicacao.tar

$ docker load \
    -i minha-aplicacao.tar

Em ambientes profissionais, o método habitual é publicar a imagem em um registro:

$ podman push registry.example.com/minha-aplicacao:1.0

Depois, ela pode ser baixada pelo Docker:

$ docker pull registry.example.com/minha-aplicacao:1.0

7. Docker Compose e Podman Compose

Docker Compose é uma das áreas em que a diferença se torna mais perceptível. Ele permite definir uma aplicação com vários serviços em um arquivo YAML.

Exemplo:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"

  banco:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: senha

Com Docker, a execução normalmente é feita assim:

$ docker compose up -d

O Compose está profundamente integrado ao ecossistema Docker e é descrito oficialmente como uma ferramenta para definir e executar aplicações com vários contêineres. Veja a documentação do Docker Compose.

No Podman, podemos executar:

$ podman compose up -d

Existe, porém, uma diferença importante: podman compose funciona como uma camada intermediária que chama um provedor externo, como podman-compose ou docker-compose. Essa arquitetura está descrita no manual oficial.

Consequentemente, um arquivo Compose simples tende a funcionar nas duas ferramentas, mas arquivos mais sofisticados podem apresentar diferenças relacionadas a:

• redes;
• nomes de contêineres;
• dependências entre serviços;
• opções específicas do Docker;
• permissões de volumes;
• recursos recentes da especificação Compose;
• ferramentas que esperam encontrar o socket do Docker.

Antes de migrar uma aplicação extensa, teste o arquivo completo:

$ podman compose config
$ podman compose up

Não presuma que a semelhança dos comandos significa compatibilidade perfeita.

8. O Podman possui pods

O Podman tem suporte direto ao conceito de *pod*, inspirado na organização utilizada pelo Kubernetes. Um pod reúne um ou mais contêineres que compartilham determinados recursos, especialmente a rede.

Podemos criar um pod:

$ podman pod create \
    --name minha-aplicacao \
    -p 8080:80

Adicionar um servidor web:

$ podman run -d \
    --pod minha-aplicacao \
    --name web \
    nginx

Adicionar outro contêiner ao mesmo pod:

$ podman run -d \
    --pod minha-aplicacao \
    --name auxiliar \
    alpine sleep infinity

Listar os pods:

$ podman pod ps

Examinar o conteúdo do pod:

$ podman ps --pod

Como os contêineres compartilham a rede do pod, o contêiner auxiliar pode acessar serviços do contêiner web por localhost.

O Docker não oferece esse mesmo modelo de pod em sua interface tradicional. Ele organiza aplicações com Compose, redes e, em ambientes distribuídos, Docker Swarm. Isso não torna um modelo universalmente superior ao outro, mas mostra que as ferramentas seguem caminhos diferentes para agrupar contêineres.

9. Integração com systemd

Em servidores Linux, o Podman possui uma integração particularmente natural com o systemd. Atualmente, a abordagem recomendada é o Quadlet.

Um arquivo Quadlet pode ser criado em:

 ~/.config/containers/systemd/meu-site.container 

Com o seguinte conteúdo:

[Unit]
Description=Servidor web executado pelo Podman

[Container]
Image=docker.io/library/nginx:alpine
ContainerName=meu-site
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=default.target

Depois, recarregue as unidades:

$ systemctl --user daemon-reload

Inicie o serviço:

$ systemctl --user start meu-site.service

Habilite a inicialização automática:

$ systemctl --user enable meu-site.service

Consulte seu estado:

$ systemctl --user status meu-site.service

Para permitir que o serviço do usuário seja iniciado mesmo quando ele não estiver conectado:

$ sudo loginctl enable-linger "$USER"

Versões anteriores do Podman popularizaram este comando:

$ podman generate systemd

Ele ainda existe, mas está obsoleto. A documentação atual recomenda o uso de arquivos Quadlet para executar contêineres e pods sob o controle do systemd. Veja o aviso no manual do Podman.

No Docker, normalmente administramos o daemon com systemd:

$ sudo systemctl enable --now docker

Os contêineres podem receber políticas de reinicialização:

$ docker run -d \
    --name meu-site \
    --restart unless-stopped \
    -p 8080:80 \
    nginx

A diferença conceitual é que o Docker mantém seu daemon como serviço, e esse daemon administra os contêineres. Com Quadlet, cada carga do Podman pode ser descrita e acompanhada de maneira mais direta pelo systemd.

10. Compatibilidade com programas que esperam Docker

Muitas ferramentas de desenvolvimento procuram o socket /var/run/docker.sock.

Elas utilizam a API do Docker para criar contêineres, executar testes ou montar ambientes temporários.

O Podman oferece uma API compatível com a API do Docker, mas ela precisa ser disponibilizada. Para um usuário comum, podemos ativar o socket com:

$ systemctl --user enable --now podman.socket

Depois, configure:

$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"

Programas compatíveis poderão então tentar usar o Podman como se estivessem falando com o Docker.

O serviço do Podman oferece uma camada de compatibilidade com a API do Docker e outra API nativa chamada Libpod. Veja a documentação do serviço de API.

Mesmo assim, a compatibilidade não é total. Ferramentas que dependem de comportamentos muito específicos do daemon, de extensões recentes da API ou de componentes exclusivos do Docker podem não funcionar corretamente.

Também é importante proteger o socket. Quem consegue acessá-lo adquire grande controle sobre os contêineres e pode executar código com os privilégios do usuário responsável pelo serviço.

11. Portas baixas no modo rootless

No Linux, portas inferiores a 1024 são tradicionalmente consideradas privilegiadas. Isso pode afetar o uso rootless.

Este comando poderá falhar, dependendo da configuração do sistema:

$ podman run -d \
    --name web \
    -p 80:80 \
    nginx

Uma solução simples é utilizar uma porta mais alta no host:

$ podman run -d \
    --name web \
    -p 8080:80 \
    nginx

Outra possibilidade é alterar a configuração do sistema, mas isso afeta todos os usuários e deve ser avaliado com cuidado:

$ sudo sysctl net.ipv4.ip_unprivileged_port_start=80

Para manter a alteração após a reinicialização, seria necessário registrá-la em um arquivo de configuração do sysctl.

No uso diário, escolher portas como 8080, 8443 ou 3000 costuma ser a opção mais simples.

12. Volumes e permissões podem exigir atenção

Aplicações que gravam arquivos em diretórios do host podem encontrar diferenças de UID e GID no modo rootless.

Considere:

mkdir dados
$ podman run --rm \
    -v "$PWD/dados:/dados" \
    alpine \
    touch /dados/teste.txt

Dependendo da imagem, do sistema de arquivos e da configuração dos namespaces, podem surgir problemas de permissão.

O Podman possui opções que ajudam a ajustar a propriedade do volume. Um exemplo é o sufixo :U:

$ podman run --rm \
    -v "$PWD/dados:/dados:U" \
    alpine \
    touch /dados/teste.txt

Essa opção pode alterar recursivamente a propriedade dos arquivos no diretório do host. Portanto, não deve ser aplicada sem verificar suas consequências.

Em sistemas com SELinux, também podem ser necessários os sufixos :z ou :Z:

$ podman run --rm \
    -v "$PWD/dados:/dados:Z" \
    alpine \
    touch /dados/teste.txt

Problemas com volumes são uma das áreas em que a troca direta de docker por podman pode exigir ajustes.

13. Nomes curtos de imagens

Este comando é comum no Docker:

$ docker run nginx

Em algumas instalações do Podman, o uso de um nome curto pode pedir a escolha de um registro ou gerar um aviso:

$ podman run nginx

Para evitar ambiguidades, indique o registro completo:

$ podman run docker.io/library/nginx:alpine

O mesmo cuidado pode ser aplicado a outras imagens:

$ podman run docker.io/library/alpine:latest
$ podman run quay.io/podman/hello

Usar referências completas torna scripts mais previsíveis e reduz o risco de baixar uma imagem de um registro diferente do esperado.

14. Docker Desktop e Podman Machine

No Linux, Docker Engine e Podman podem trabalhar diretamente com os recursos do kernel. No Windows e no macOS, os contêineres Linux precisam de um ambiente Linux intermediário.

Docker Desktop fornece esse ambiente e também reúne recursos como:

• interface gráfica;
• Docker Engine;
• Docker Compose;
• gerenciamento de volumes e imagens;
• integração com Kubernetes e extensões, conforme a configuração;
• integração com WSL 2 no Windows.

O Podman utiliza podman machine no Windows e no macOS:

$ podman machine init
$ podman machine start
$ podman info

A máquina pode ser parada com:

$ podman machine stop

A documentação informa que o Podman precisa dessa máquina virtual no Windows e no macOS porque os contêineres dependem de recursos do kernel Linux. Consulte o manual de "podman machine".

Para equipes que desejam uma experiência gráfica muito consolidada e uniforme em diferentes sistemas, Docker Desktop costuma oferecer o caminho mais conhecido. Para usuários de Linux interessados em uma abordagem integrada ao sistema, rootless e sem daemon central, Podman pode ser mais natural.

Também convém observar que Docker Engine e Docker Desktop não são exatamente o mesmo produto. As condições comerciais do Docker Desktop devem ser examinadas por organizações que ultrapassem os critérios de uso gratuito definidos pela Docker. Consulte os termos atuais de licenciamento.

15. Segurança: Podman é automaticamente mais seguro?

A resposta curta é: depende da configuração.

A arquitetura sem daemon e o uso rootless reduzem alguns riscos. Um usuário pode executar contêineres sem entregar seus comandos a um daemon central executado como root.

Por outro lado:

• um contêiner mal configurado ainda pode expor dados;
• montar diretórios sensíveis continua sendo perigoso;
• executar com --privileged reduz o isolamento;
• expor o socket da API oferece grande poder a quem o acessa;
• imagens desconhecidas podem conter software malicioso;
• Docker também pode ser configurado para funcionar em modo rootless.

Este comando, por exemplo, é perigoso em qualquer mecanismo:

$ podman run --privileged \
    -v /:/host \
    imagem-desconhecida

A escolha da ferramenta ajuda, mas a segurança depende principalmente de como imagens, volumes, redes, capacidades e privilégios são configurados.

16. Um teste prático de migração

Suponha que uma aplicação seja executada com Docker:

$ docker run -d \
    --name redis-teste \
    -p 6379:6379 \
    -v redis-dados:/data \
    redis:alpine

A primeira tentativa com Podman poderia ser:

$ podman run -d \
    --name redis-teste \
    -p 6379:6379 \
    -v redis-dados:/data \
    docker.io/library/redis:alpine

Depois, verifique:

$ podman ps
$ podman logs redis-teste
$ podman port redis-teste
$ podman volume inspect redis-dados

Teste a comunicação:

$ podman exec redis-teste redis-cli ping

O resultado esperado é:

PONG

Finalmente, remova o ambiente:

$ podman stop redis-teste
$ podman rm redis-teste
$ podman volume rm redis-dados

Esse exemplo mostra que uma carga simples pode ser migrada quase sem alterações. A validação se torna mais importante quando existem arquivos Compose complexos, redes personalizadas, integração com IDEs, acesso ao socket, GPUs ou volumes com permissões específicas.

17. Quando escolher Docker

Docker tende a ser uma escolha conveniente quando:

• a equipe já utiliza intensamente Docker Compose;
• os materiais de treinamento e scripts foram escritos para Docker;
• ferramentas externas exigem compatibilidade exata com o Docker;
• Docker Desktop faz parte do fluxo de desenvolvimento;
• a equipe busca o ecossistema com maior quantidade de exemplos e integrações;
• Docker Swarm já é utilizado na infraestrutura;
• mudar a ferramenta produziria trabalho sem benefício prático relevante.

Para quem está aprendendo contêineres, Docker também possui uma enorme quantidade de documentação, cursos e exemplos disponíveis.

18. Quando escolher Podman

Podman tende a ser especialmente interessante quando:

• o sistema principal é Linux;
• deseja-se executar contêineres como usuário comum;
• a integração com systemd é importante;
• diferentes usuários devem manter ambientes isolados;
• prefere-se uma arquitetura sem daemon central;
• pods são úteis para organizar grupos de contêineres;
• o ambiente utiliza tecnologias da família Red Hat;
• deseja-se reduzir a dependência de componentes específicos do ecossistema Docker.

Em estações Linux e servidores administrados com systemd, Podman e Quadlet formam uma combinação bastante coerente.

19. Quadro-resumo

Conclusão

Para executar um contêiner isolado, a diferença entre Docker e Podman pode se resumir à primeira palavra do comando. Ambos baixam as mesmas imagens, processam Dockerfiles e oferecem operações muito semelhantes.

As diferenças aparecem quando observamos o funcionamento do sistema como um todo. Docker utiliza uma arquitetura cliente-servidor baseada no daemon dockerd. Podman foi construído sem a necessidade de um daemon central e favorece a execução rootless, o isolamento por usuário, os pods e a integração com systemd.

Docker continua sendo muito atraente por seu ecossistema, pelo Compose, pelo Docker Desktop e pelo grande número de ferramentas que esperam encontrar sua API. Podman ganha força em ambientes Linux, especialmente quando segurança, administração com systemd e execução sem privilégios são prioridades.

A melhor escolha depende menos do comando usado para iniciar um contêiner e mais do ambiente em que ele precisará operar. Em muitos casos, as duas ferramentas podem inclusive coexistir, desde que se compreenda que cada uma manterá suas próprias imagens, volumes e contêineres.