Por que eu troquei o Docker pelo Podman

 (codesmash.dev)
14 pontos por GN⁺ 2025-09-06 | 8 comentários | Compartilhar no WhatsApp
  • O Docker vem sendo criticado de forma recorrente por problemas de segurança e consumo de recursos devido à sua arquitetura com daemon em segundo plano (dockerd)
  • O Podman adota uma arquitetura sem daemon, fazendo com que os contêineres sejam executados diretamente com as permissões do usuário, reduzindo a superfície de ataque e reforçando a estabilidade
  • Com suporte a integração com systemd, design amigável ao Kubernetes e ferramentas separadas baseadas na filosofia Unix, como Buildah e Skopeo, a eficiência operacional aumenta
  • Mantendo alta compatibilidade com a CLI do Docker, na maioria dos casos o fluxo de trabalho existente continua funcionando apenas com alias docker=podman
  • Mesmo em ambientes reais de produção, a segurança e o gerenciamento de recursos ficam mais simples, e em novos projetos o Podman está se tornando uma opção mais racional e orientada para o futuro

Limitações do Docker e problemas de segurança

  • O Docker tem uma estrutura em que o daemon dockerd está sempre em execução com privilégios de root
    • Se uma vulnerabilidade for encontrada no daemon, todo o host pode ficar exposto a riscos
  • Exemplos de incidentes importantes de segurança
    • 2019: escape de contêiner no runC (CVE-2019-5736)
    • 2022: vulnerabilidade Dirty Pipe no Linux, escape via cgroups v1
    • 2024: runC “Leaky Vessels”, vulnerabilidade no BuildKit
    • 2024: campanha de cryptojacking por exposição da API do Docker
  • A repetição desses incidentes evidencia o risco estrutural da arquitetura baseada em daemon

A arquitetura sem daemon do Podman

  • O Podman não usa daemon em segundo plano
    • Ao executar podman run, o contêiner funciona como processo filho direto de quem executou o comando
    • Como roda em modo rootless, mesmo privilégios de root dentro do contêiner equivalem apenas a permissões de usuário comum no host
  • Vantagens
    • Segurança reforçada: em caso de escape de contêiner, o impacto é reduzido
    • Mais estabilidade: se um contêiner cair, os demais não são afetados
    • Eficiência de recursos: como não há daemon residente desnecessário, o uso de memória diminui

Recursos diferenciados do Podman

  • Integração com systemd
    • podman generate systemd cria automaticamente arquivos de unidade do systemd
    • Os serviços podem ser gerenciados com os comandos padrão do systemctl
  • Compatibilidade com Kubernetes
    • O conceito de Pod já vem embutido por padrão, facilitando o desenvolvimento de apps com múltiplos contêineres
    • podman generate kube permite gerar YAML do Kubernetes diretamente
  • Filosofia Unix
    • O Podman foca na execução de contêineres; para build de imagens usa-se o Buildah, e para gerenciamento de registries o Skopeo
    • Isso permite usar ferramentas otimizadas para cada finalidade

Processo de migração e compatibilidade

  • A migração do Docker para o Podman é praticamente sem interrupções
    • Como a CLI é compatível, dá para usar podman no lugar de docker sem grandes mudanças
    • Dockerfiles existentes continuam funcionando normalmente
  • Diferenças
    • No modo rootless, não é possível fazer bind em portas abaixo de 1024 → recomenda-se usar reverse proxy
    • É necessário cuidar das permissões de volumes
    • Ferramentas que dependem do socket do Docker podem usar o modo de compatibilidade com a API Docker do Podman

Aplicação prática e benefícios

  • Após usar o Podman em ambiente de produção
    • Redução da carga de auditorias de segurança, com segurança rootless aplicada por padrão
    • O padrão de uso de recursos fica mais simples e previsível
  • O Docker continua popular, mas em novos projetos ou quando há liberdade para escolher a stack, o Podman tende a ser mais adequado
    • Integração natural com o ecossistema de administração Linux
    • Arquitetura orientada ao Kubernetes
    • Ambiente de execução de contêineres mais seguro e racional

Resumo do guia de migração para FastAPI

  • É possível usar o Dockerfile existente sem alterações
  • Basta substituir por podman build e podman run
  • Use podman generate systemd para registrar o serviço no systemd
  • Pods permitem dar suporte a ambientes com múltiplos serviços, como banco de dados
  • Fluxos de trabalho com Docker Compose podem ser atendidos com podman-compose ou conversão via kompose

Leituras relacionadas

8 comentários

 
shortstories 2025-09-09

Aqui dizem que é possível fazer a migração sem downtime, mas no ambiente real de operação havia várias coisas estranhas. Por exemplo, no mac, como a configuração padrão usa compressão zstd, a imagem gerada acaba ocupando bastante espaço no registro...
 
codemasterkimc 2025-09-08

Tanto Docker quanto Podman....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

Na prática, a compatibilidade com Docker não funciona tão bem, então a usabilidade não é lá essas coisas...
Fui para o Podman pensando no modo rootless, mas acabei voltando para o Docker.
Como outra pessoa disse, se for para usar com Kubernetes, aí é melhor simplesmente usar containerd.
 
click 2025-09-08

Fico me perguntando se, já que o Docker Compose não funciona bem e a vantagem seria a boa compatibilidade com Kubernetes, não seria melhor simplesmente usar Kubernetes direto.
Eu também tentei usar, mas como não funcionou de primeira e também não dava para mapear portas abaixo de 1024 diretamente, acabei usando uma combinação de k3s com nerdctl para build de imagens.
 
ndrgrd 2025-09-07

Embora eu queira trocar algum dia, quando tentei antes, ao contrário do que os desenvolvedores diziam, muitos projetos com Docker Compose simplesmente não funcionavam direito...
 
afewgoodman 2025-09-07

Nem tem suporte a rede do Docker, né.
 
devsepnine 2025-09-07

Pelo que sei, ele também oferece suporte a recursos de rede, de forma semelhante ao Docker.
Ainda existe algo que não funciona direito?
 
GN⁺ 2025-09-06
Comentários no Hacker News
  • Em 2001/2002 eu precisava montar uma caixa de hotspot WiFi. Na época eu era fã de OpenBSD e queria deixar a distribuição em Python o mais enxuta possível. Para evitar cópia desnecessária de arquivos e problemas de dependência, escolhi os conceitos de chroot e jail. Meu código de distribuição executava o software fora do ambiente de jail e monitorava com ptrace quais arquivos o processo abria. A partir dessa saída, eu gerava uma lista de dependências e empacotava tudo. No fim, a distribuição ficou pequena, imutável e mais segura. Quando o Docker apareceu, isso me lembrou aquele método antigo, e fiquei curioso para saber se existia alguma ferramenta parecida que monitorasse o uso de arquivos de contêineres Docker para reduzir a distribuição
    • O melhor pipeline de CI/CD que já usei foi para deploy freelancer de Django. Um hook de post-receive do git automatizava o build dos arquivos estáticos e o reinício do httpd a cada git push. Era só fazer git push live master e o deploy acontecia. Já usei muito Docker, mas esse foi o deploy mais fácil de todos. Eu entendo as vantagens do Docker, mas configurar HTTP no Ubuntu ou no OpenBSD não é tão difícil assim. Fico me perguntando se a reprodutibilidade exclusiva do Docker realmente vale toda essa sobrecarga de manutenção
    • O primeiro resultado no Google é o slimtoolkit/slim, com 22k estrelas
    • No ambiente OpenWrt existe uma ferramenta chamada ujail: você passa um executável ELF, ela analisa as dependências de bibliotecas necessárias e monta em tmpfs, como somente leitura, apenas os arquivos essenciais
      Link para o código relacionado
  • O Podman tem sido uma experiência realmente excelente para mim. Eu achava o uso do Docker difícil e cheio de armadilhas, mas o Podman não fica devendo em nada. Acima de tudo, na empresa onde trabalho não precisamos nos preocupar com licença. É ganho dos dois lados
    • Fico curioso se licença realmente era uma preocupação na empresa. A política de licença paga do Docker Desktop é razoável. É gratuito para empresas com menos de 250 funcionários ou menos de US$ 10 milhões em faturamento. Mesmo que a licença custe US$ 90 por ano, isso mal dá o preço de um almoço considerando o salário de um desenvolvedor nos EUA. Além disso, dá para usar uma ferramenta com suporte oficial em todos os sistemas operacionais
    • Na verdade, a empresa nem precisa se preocupar tanto com licença. O Docker Engine é totalmente open source e gratuito. Só o Docker Desktop exige uma licença separada para uso corporativo. Mas a maioria dos recursos já está disponível no Docker Engine
    • O Podman é muito melhor que o Docker. Você não precisa se preocupar com tratamento de permissões de usuário/grupo nem com os problemas de segurança de processos root. Também não precisa mandar dados para um daemon
    • Em alguns PCs, o desinstalador do Podman no Windows não remove todos os componentes corretamente, então aparecem erros ao executar de novo. Mesmo apagando o serviço manualmente, o problema continua. É uma fonte de irritação bem frequente
  • Eu gosto muito do Podman, mas ele não funciona sempre bem com todos os contêineres. Por exemplo, contêineres grandes como o GitLab frequentemente falham no Podman porque dependem da história complexa e das peculiaridades do Docker. Já as imagens que eu mesmo crio costumam rodar bem no Podman. Para contêineres problemáticos, eu contorno subindo uma VM com incus e rodando lá dentro. Tanto o Podman quanto o Docker têm formas inconsistentes de lidar com acesso à GPU, o que é inconveniente. Ainda assim, acho o Podman um pouco melhor. Principalmente por causa do rootless
    • Imagino que a maioria dos problemas venha de imagens que iniciam o PID 1 como root. O Podman é rootless por padrão, então isso acaba causando esse tipo de problema. Se você quiser usar imagens baseadas em root sem Docker, pode manter o Podman em modos rootful e rootless separadamente e usar a flag --connection para apontar para o ambiente desejado. Se necessário, o Podman também pode criar uma VM automática para isso (usando lima). O Podman Desktop também tem uma camada de compatibilidade com Docker para aliviar esses problemas
    • O fato de alguns contêineres não funcionarem no Podman provavelmente foi a própria motivação do post do blog. Se a base de usuários crescer o suficiente, deve surgir o hábito de testar também em ambiente Podman antes de publicar
    • Nós rodamos tanto o servidor quanto os runners do GitLab em Podman. Pessoalmente eu gostaria de migrar os runners para k8s, mas no momento usamos Traefik e tudo funciona bem
    • Eu uso bastante recursos relacionados ao buildx e, embora pareça que o Podman suporte isso, na prática não funciona direito
  • O maior problema é o suporte ao Podman no Ubuntu. A versão padrão do Podman no Ubuntu é velha demais para uso imediato. Eu uso Podman v5, o GitHub Actions usa v3, e meus colegas usam Docker. No fim, surge a complexidade de fazer meus scripts rodarem em Podman antigo, Podman novo e Docker ao mesmo tempo
    • Não existe um repositório confiável de builds .deb. Não há .deb oficial, e os que encontrei estão desatualizados ou já avisam que não serão mais mantidos. Então fica a pergunta: por que o Podman não facilita mais a instalação? Minha impressão é que a RedHat não quer gastar recursos de desenvolvimento dando suporte a software de concorrentes. Faz sentido, mas fora do ecossistema RedHat a sensação é de ser tratado como cidadão de segunda classe
    • Acho que esse é o maior problema. A menor popularidade em comparação ao Docker pesa, mas o desencontro de versões é uma causa muito maior para o Podman continuar sendo nichado. Distribuições como Ubuntu frequentemente entregam software antigo, e isso precisa ser resolvido por quem mantém o pacote, mas o lado do Podman não parece muito ativo nisso. Por causa disso, até meu home server acabou sendo trocado para algo da linha Red Hat só para usar Podman atualizado
    • O fato de não haver .deb oficial upstream fornecido de forma consistente impede o uso interno do Podman. Dá até inveja do Docker, que mantém muito bem seu repositório oficial .deb
    • Esse é um dos motivos pelos quais eu não uso Ubuntu/Debian: as atualizações são lentas demais. Até daria para usar via flatpak, mas esse tipo de software deveria ser oferecido por padrão
    • Como o Podman é open source, lugares como o Ubuntu podem empacotar e atualizar por conta própria. Também dá para entender por que a RedHat hesita em dar suporte direto ao empacotamento de software concorrente
  • Recentemente tive que lidar com um setup de Podman no trabalho e foi uma das piores experiências que já tive. A combinação rootless Podman + SELinux + usuário comum dentro do contêiner é um inferno de verdade
    • Na prática, se você quiser sofrer, consegue fazer qualquer coisa sofrer, mas no geral a maior parte funciona bem. Eu rodo vários serviços (Forgejo, runner, uptime-kuma etc.) como contêineres rootless atrás de um reverse proxy nginx em máquinas RHEL10 com SELinux ativado, e funciona bem
    • Eu nunca senti qualquer vantagem no rootless. Se a máquina estiver em um único domínio de segurança, dá para rodar como root sem problemas; se não estiver, então o certo é usar isolamento de verdade, como uma VM Firecracker/Kata. Rootless parece trazer muito sofrimento para um benefício questionável
    • Eu também passei pela mesma situação na empresa, mas dá para usar se você resolver do jeito específico do Podman (consulte a documentação). O ponto principal é olhar a documentação das versões mais recentes
    • Eu uso só Podman no Fedora há mais de 7 anos
    • Nossa organização fez a migração completa de Docker para Podman e, embora tenha havido alguns ruídos no caminho, a equipe de SysDev resolveu tudo sem grandes problemas
  • Já ouvi dizer que, se o workflow com Docker Compose ficar complexo demais, é melhor converter logo para YAML de Kubernetes, mas pela minha experiência o YAML do K8s é muito mais complexo que docker compose. E nem todo mundo usa Kubernetes
    • Eu discordo. Na minha opinião, o YAML do K8s tem complexidade parecida com a do docker compose, ou às vezes até menor. Só é absurdamente verboso. Um compose de 100 linhas pode acabar dividido em 20 YAMLs de 50 linhas cada. Seria ótimo se o kubectl tivesse algum recurso mais prático para converter entre YAML simples e complexo
    • Usar um LLM como camada para converter docker compose em k8s yaml funciona absurdamente bem. E, por sinal, o Podman também tem geração de k8s yaml, então a migração pode ser natural
    • Eu não sei criar arquivos compose, mas sei fazer k8s yaml. Então, para mim, o compose acaba parecendo mais “complexo”
  • O comando podman generate systemd mencionado no artigo agora está deprecated. A alternativa são os Podman Quadlets, que funcionam de forma parecida com um docker-compose.yaml definido dentro de arquivos unit do systemd
    • Faz sentido passar composição/orquestração para o systemd. Como não é uma arquitetura cliente-servidor como no Docker, e sim um processo real do usuário, essa escolha se encaixa claramente
    • O problema é que quase não existe documentação
  • Mapear contêineres com múltiplos UIDs para um único usuário do host é difícil. Por padrão, o root dentro do contêiner é mapeado para o usuário do host que executa o processo, mas recentemente muitos apps passaram a usar usuários não-root dentro do contêiner (por exemplo, www-data, usuário 1000 etc.). Eles acabam mapeados para IDs secundários no host, e isso faz com que, ao mapear volumes, os donos dos arquivos fiquem “órfãos”, gerando bastante confusão. Faz falta uma opção simples para mapear todos os UIDs para um único usuário, e as opções existentes (uidmap do crun, userns) não funcionam bem. Fico em dúvida sobre a utilidade prática desse mapeamento por IDs secundários
    • Se entendi corretamente, isso é uma limitação dos namespaces do Linux. Para ferramentas como Docker e Podman oferecerem esse tipo de mapeamento, seria necessário suporte do Linux. O motivo de o mapeamento 1:1 de UID ser importante é que, se os usuários 1000 e 0 dentro do contêiner forem mapeados para o mesmo usuário do host, as informações de dono dos arquivos ficam inconsistentes
    • Talvez valha a pena analisar idmapped mounts. Eles resolvem apenas o remapeamento no sistema de arquivos, não nas chamadas ao kernel
    • Seria bom se dentro do contêiner fosse possível simplesmente operar como “você mesmo”, de um jeito em que isso também aparecesse corretamente nos logs de propriedade
    • Dá para usar a opção ignore_chown_errors para mapear o root para o ID do usuário de forma simples, sem precisar de mapeamentos extras
  • Tentei migrar para Podman várias vezes, mas falhei em vários pontos. Primeiro, o desempenho do Podman no meu VPS pequeno era muito pior que o do Docker (vou poupar os detalhes). Segundo, o ecossistema de desenvolvimento ainda não acompanhou totalmente. Muitas ferramentas dependem do socket do Docker, e o Podman não funciona bem com elas por causa de problemas de permissão ou diferenças de compatibilidade da API. O Podman não é um substituto drop-in perfeito
    • Se você usa Podman rootless, a rede lenta pode ser culpa do slirp4netns. O pasta é uma alternativa mais rápida. No Docker, por padrão, um daemon privilegiado configura a rede; então, se você usar o Podman como root, não deveria haver diferença de desempenho
    • Os erros de permissão do SELinux com Podman e Quadlet continuam sendo um incômodo recorrente. Sempre que possível, é mais fácil criar um pod com privilégios no host inteiro, montar apenas os /dev necessários e expor um programa bem restrito em uma rede isolada
    • Curiosamente, nos meus sistemas com poucos recursos, o Podman teve desempenho e uso de recursos muito melhores que o Docker. Parece ser por causa da diferença entre crun e runc. Além disso, como o Podman não tem daemon, ele é mais leve
  • Abandonei tanto Docker quanto Podman e fui para FreeBSD Jails
    • Mais informações e ferramentas de gerenciamento estão aqui,
      aqui,
      aqui,
      e aqui
    • Dá para rodar instantaneamente MS SQL Server ou milhares de contêineres Docker dentro de uma jail do FreeBSD? Escolher FreeBSD cobra um preço alto, como limitações de compatibilidade. Esse é o motivo de jails não terem se popularizado
    • A configuração parece enorme; fico curioso se existe algo como containerd também no FreeBSD
    • FreeBSD jails são um recurso específico da plataforma
    • Fico curioso sobre qual é a diferença entre rodar uma VM em um host Linux e usar uma jail do FreeBSD