Docker ou Podman: rootless e compatibilidade do fluxo

Podman é uma opção para quem quer executar contêineres sem um daemon permanente, mas a troca pelo Docker depende das integrações usadas pelo projeto. A documentação do Podman descreve comandos comparáveis aos do Docker e informa que a maioria pode ser executada por um usuário comum. Essa semelhança ajuda na linha de comando; ela não faz Compose, IDE e CI encontrarem automaticamente o serviço e o socket esperados.

Para reduzir privilégios com menos mudanças nas ferramentas, Docker rootless costuma ser o primeiro caminho a avaliar. No modo rootless do Docker, daemon e contêineres rodam em um namespace de usuário, mediante configuração de UID e GID subordinados. O daemon continua fazendo parte da arquitetura. A escolha é preservar esse modelo com menos privilégios ou aceitar a adaptação das integrações ao Podman.

Arquitetura e permissões: o que muda de fato

O cliente Docker envia operações ao daemon, que administra imagens e contêineres. Com o Podman local, um comando pode administrar contêineres sem manter um daemon central em execução. Quando outra ferramenta precisa falar com uma API, porém, entra em cena um serviço do Podman acessível por socket. É por isso que executar um contêiner pelo terminal e conectá-lo a uma IDE são verificações diferentes.

Executar como usuário comum também requer preparar a conta no host. O Podman cria um namespace de usuário no modo rootless e usa os intervalos definidos em /etc/subuid e /etc/subgid. Contêineres criados por essa conta não aparecem para outro usuário nem para uma sessão do Podman iniciada como root. Se um serviço for migrado para uma conta diferente, a equipe precisa saber qual conta poderá consultar os contêineres, reiniciá-los e acessar seus dados.

O Docker rootless também depende dos mapeamentos subordinados e das ferramentas de UID e GID exigidas para criá-los. Reduzir privilégios do daemon não dispensa conferir as permissões dos diretórios montados. Da mesma forma, oferecer uma API do Podman a uma ferramenta externa exige decidir qual usuário terá acesso ao socket: esse acesso permite administrar os contêineres daquela conta.

Matriz de compatibilidade: onde o alias deixa de bastar

O Podman Compose depende de um provedor externo e do socket do Podman para administrar serviços em conjunto.

Um alias pode cobrir comandos simples, mas não altera arquivos Compose, caminhos de socket nem a conta usada pelo pipeline. A migração precisa passar pelos componentes que realmente sustentam a aplicação:

CLI: build, run, ps e logs têm comandos próximos. Scripts que dependem de opções específicas ou interpretam a saída devem ser executados com o novo mecanismo; nomes semelhantes não garantem resultados idênticos para cada automação.
Compose: podman compose chama um provedor externo, como docker-compose ou podman-compose, e encaminha a ele comandos e opções por meio do socket local do Podman. O provedor instalado passa a fazer parte do resultado. Teste o arquivo real, sobretudo dependências entre serviços, redes, volumes e verificações de saúde.
Socket e API: um script que chama podman diretamente não precisa da mesma conexão que um cliente da API do Docker. Ferramentas configuradas para /var/run/docker.sock precisam receber o endereço do socket do Podman e ter permissão para acessá-lo. Trocar o executável no PATH não muda uma conexão gravada na configuração da ferramenta.
Volumes: confirme leitura, escrita e propriedade dos arquivos no diretório montado. O mapeamento de identidades no modo rootless pode alterar a relação entre o usuário visto no contêiner e o proprietário visto no host. Um serviço que grava dados persistentes revela problemas que um contêiner iniciado sem volume não mostraria.
Rede: verifique portas publicadas, resolução de nomes entre serviços e acesso a partir dos clientes previstos. Uma aplicação composta pode iniciar todos os contêineres e ainda falhar na comunicação entre eles; o sucesso de podman run isolado não encerra essa verificação.
IDE e CI: a orientação do IntelliJ IDEA para Podman distingue encontrar o executável de conseguir conectar-se ao socket. No CI, procure caminhos de socket, DOCKER_HOST, etapas que iniciam um daemon e tarefas de build ou publicação de imagens. Cada etapa usada pelo projeto precisa funcionar com a conta escolhida.

Desempenho depende da carga medida

No teste em Fedora 41, o contêiner ocioso usou 8,2 MB com Podman e 11,4 MB com Docker.

Em um ensaio relatado pela Leaper, Docker Engine 27.x e Podman 5.4 foram comparados em Fedora 41; a publicação informa dez execuções por teste e apresenta as medianas. Nessa configuração, a memória atribuída a um contêiner ocioso foi de 11,4 MB com Docker e 8,2 MB com Podman. O build da imagem de teste levou 38,2 segundos no Docker e 40,7 no Podman; na medição de vazão entre contêiner e host, os valores foram 42,1 Gbps e 38,7 Gbps, respectivamente.

Esses resultados têm alcance limitado à máquina, às versões e às cargas descritas pela publicação. Também medem coisas diferentes: memória em repouso, construção de uma imagem e tráfego de rede. Para um fluxo que reconstrói imagens continuamente, o tempo de build pode pesar mais; para outro com muitos contêineres ociosos, a memória pode ganhar importância. O benchmark ajuda a formular a comparação, mas não prevê o desempenho dos volumes ou da aplicação de uma equipe.

Validação antes da troca em produção

O teste mais útil reproduz o fluxo com a mesma conta, o mesmo arquivo Compose e diretórios de teste com permissões equivalentes às previstas. Assim, uma falha de acesso não fica escondida pelo uso acidental de root. A sequência deve incluir as ferramentas que operam os contêineres, não apenas o comando que os inicia.

Execute id -u e id -un para identificar a conta. Confira as entradas dela em /etc/subuid e /etc/subgid antes de atribuir uma falha de build ou de volume à aplicação.
Registre a conexão atual com docker context show e docker info. Ao avaliar Docker rootless, use docker info para confirmar que o cliente alcança o daemon pretendido; a existência de um contexto, por si só, não demonstra que ele está ativo.
Com a conta escolhida, execute podman info, construa a imagem do projeto com podman build e inicie um serviço de teste com podman run. Monte um diretório de teste e confirme a leitura, a escrita e a propriedade dos arquivos criados.
Confira as opções do provedor instalado com podman compose --help. Se ele oferecer o comando config, use-o para validar o arquivo; depois execute podman compose up -d, consulte ps e logs e verifique a comunicação entre serviços e pela porta publicada.
Configure a IDE para a conexão do Podman e repita uma operação completa de build, início, inspeção e remoção. Execute também as etapas correspondentes do CI, inclusive a publicação de uma imagem em um destino de teste quando essa tarefa fizer parte do pipeline.

Se podman run funciona e a IDE falha ao conectar-se, a investigação deve começar pelo serviço, pelo caminho e pelas permissões do socket. Se os contêineres iniciam, mas o serviço não grava no volume, o foco passa ao usuário e ao mapeamento de IDs. Separar essas falhas evita tratar uma integração incompleta como defeito da imagem.

Quando cada escolha compensa

Docker rootless tende a exigir menos adaptação quando a equipe já usa ferramentas configuradas para o daemon e sua API, desde que elas consigam alcançar o daemon rootless correto. Ainda é preciso preparar a conta e conferir rede e volumes. Podman atende melhor a quem valoriza dispensar um daemon permanente e pode ajustar o provedor Compose, as conexões por socket e os scripts existentes.

A decisão fica mais clara pelo componente mais difícil de migrar. Se Compose, persistência de dados, rede, IDE e CI funcionam com a mesma conta sem privilégios, a troca para Podman tem uma base operacional. Se uma integração essencial continua dependente do comportamento do Docker, manter o mecanismo e adotar seu modo rootless pode reduzir privilégios com menos mudanças no fluxo.