Programação · DevOps · Contentores

Docker vs Podman: que motor de contentores, e quando?

Resposta rápida: O Docker e o Podman fazem o mesmo trabalho de base — construir e executar contentores — e usam o mesmo formato de imagem, pelo que uma imagem construída com um corre no outro. A principal diferença é a arquitetura: o Docker executa os contentores através de um daemon central de longa duração (dockerd) que normalmente corre como root, enquanto o Podman é sem daemon e rootless por conceção, lançando cada contentor como um simples processo filho. As suas linhas de comandos são suficientemente próximas para que alias docker=podman cubra grande parte do uso diário. Escolhe o Podman quando queres dispensar o daemon root e ter uma integração estreita com o systemd; fica com o Docker quando dependes do Docker Desktop, de um fluxo Compose maduro ou de um ecossistema mais amplo.

Se estás a começar com qualquer um deles, ajuda perceber primeiro o que são o Docker e os contentores. Este guia parte daí e foca-se no que distingue os dois motores.

Arquitetura: com daemon vs sem daemon

O Docker assenta num modelo cliente-servidor. O comando docker que escreves é um cliente que fala com um serviço em segundo plano, o daemon do Docker (dockerd), que na verdade cria e executa os teus contentores. Esse daemon corre continuamente e, na configuração predefinida, como root. É cómodo — um único serviço gere tudo — mas também é um único processo privilegiado que possui todos os contentores do host.

O Podman segue outro caminho. Sem daemon central: quando executas um contentor, o Podman faz fork e depois exec dele diretamente como processo filho da tua shell, usando as mesmas primitivas do Linux (namespaces, cgroups). Cada contentor é apenas uma árvore de processos normal. Esse modelo sem daemon significa que não há um serviço root sempre ativo a comprometer, e que uma falha num contentor não passa por um daemon partilhado.

Contentores rootless e segurança

Essa diferença de arquitetura leva à diferença de segurança que mais importa. O Podman foi construído para correr em rootless: um utilizador sem privilégios pode construir e executar contentores sem root, usando user namespaces para mapear os UID do contentor para o host. O Docker também pode correr em rootless, e suporta-o há anos, mas a sua instalação predefinida continua centrada no daemon root, pelo que o rootless é um modo opcional e não a base.

Não ter um daemon root reduz a superfície de ataque: não há um serviço privilegiado em segundo plano que uma fuga de contentor pudesse visar para tomar conta do host. Para servidores multiutilizador e runners de CI, essa propriedade de «sem daemon root» é uma razão concreta e real para passar para o Podman. Não é magia — os contentores continuam a precisar de configuração cuidadosa — mas a postura predefinida é mais conservadora.

As mesmas imagens, CLI quase idêntica

Esta é a parte que torna a mudança indolor: ambas as ferramentas seguem os padrões OCI (Open Container Initiative) para imagens e execução. Uma imagem construída com o Docker corre sob o Podman e vice-versa, e ambos descarregam dos mesmos registos (Docker Hub, GitHub Container Registry, Quay e outros). Não existe um formato de imagem exclusivo do Docker ou do Podman.

As linhas de comandos são deliberadamente próximas. podman run, podman build, podman ps e podman pull espelham os seus equivalentes do Docker, com as mesmas opções comuns. Muita gente simplesmente define um alias:

alias docker=podman

e mantém os seus hábitos. Os Dockerfiles também funcionam tal como estão sob o Podman. A CLI não é idêntica a 100 % em todos os casos limite, mas para construir e executar no dia a dia é próxima o suficiente para a memória muscular se transferir.

Pods: o agrupamento ao estilo Kubernetes do Podman

O Podman tira o nome do pod — um conceito que pede emprestado ao Kubernetes. Um pod é um grupo de contentores que partilham recursos como um namespace de rede, de modo a comunicarem entre si por localhost como se estivessem na mesma máquina. O Podman pode criar e gerir esses pods diretamente, o que aproxima o desenvolvimento local da forma como as coisas correm num cluster Kubernetes. O Docker não tem uma primitiva «pod» nativa no mesmo sentido; as montagens multicontentor compõem-se com as redes do Compose.

Integração com o systemd

Como os contentores do Podman são processos filhos normais em vez de filhos de um daemon, encaixam naturalmente no systemd, o gestor de serviços do Linux. Historicamente podias executar podman generate systemd para produzir um ficheiro de unit por contentor; a abordagem atual recomendada é o Quadlet, que permite descrever os contentores em ficheiros declarativos ao estilo de unit que o systemd gere diretamente — arrancando-os no boot, reiniciando-os em caso de falha e seguindo-os como qualquer outro serviço. Para servidores que já usam o systemd para tudo o resto, é uma forma limpa de manter os contentores sob o mesmo supervisor sem um daemon adicional.

Compose: docker compose vs podman

Muitos projetos apoiam-se no Compose para subir vários contentores a partir de um único ficheiro YAML. O Docker inclui docker compose (o plugin Compose v2) como ferramenta de primeira classe e bem mantida. O Podman também suporta fluxos Compose: pode trabalhar com a ferramenta separada podman-compose, e o Podman disponibiliza ainda um socket com o qual o tooling Compose padrão consegue falar, pelo que ficheiros compose.yaml existentes correm muitas vezes com pouca ou nenhuma alteração. Na prática, a experiência de Compose do Docker é a mais madura e polida das duas, o que explica porque equipas com uso intensivo de Compose às vezes ficam no Docker.

Licença do Docker Desktop vs modelo open source do Podman

No Windows e no macOS, o Docker usa-se normalmente através do Docker Desktop. O Docker Desktop é gratuito para uso pessoal, educação e pequenas empresas, mas exige uma subscrição paga para organizações maiores (acima do limiar de dimensão publicado pela Docker). Essa mudança de licença é uma verdadeira questão de orçamento e conformidade para as empresas maiores.

O Podman é totalmente open source e gratuito, sem licença por posto. O seu companheiro de ambiente de trabalho, o Podman Desktop, é também open source. Para as organizações que querem evitar uma licença de desktop comercial — ou simplesmente preferir uma stack open source de ponta a ponta — essa diferença conta tanto como qualquer diferença técnica.

Então, qual usar?

Critério	Docker	Podman
Arquitetura	Daemon central (dockerd)	Sem daemon (fork/exec por contentor)
Rootless	Suportado, opcional	Rootless por conceção (predefinido)
Formato de imagem	OCI	OCI — intercambiável com o Docker
CLI	CLI de referência	Quase idêntica (alias docker=podman)
Pods	Sem primitiva pod nativa	Pods nativos (estilo Kubernetes)
systemd	Corre sob o daemon	Units nativas via Quadlet
Compose	docker compose (maduro)	podman-compose / Compose via socket
Licença de desktop	Docker Desktop pago para orgs grandes	Open source, gratuito (Podman Desktop)

Não há um vencedor universal. Escolhe o Podman quando queres dispensar o daemon root, ter contentores rootless por omissão, uma gestão systemd/Quadlet nativa, ou evitar a licença do Docker Desktop. Fica com o Docker quando dependes do Docker Desktop, de um fluxo Compose maduro, ou da amplitude do seu ecossistema e documentação. Como ambos falam OCI, também os podes misturar — construir com um, executar com o outro — ou experimentar o Podman sem deitar fora as tuas imagens e Dockerfiles existentes. E se mais tarde precisares de orquestrar muitos contentores em várias máquinas, isso é tarefa do Kubernetes, que se situa acima de ambos.