Explorando o ‘Podman’, uma alternativa ao Docker com segurança reforçada

 (betterstack.com)
6 pontos por GN⁺ 2024-01-14 | 1 comentários | Compartilhar no WhatsApp
  • Podman oferece uma experiência de execução de contêineres parecida com a do Docker, mas se diferencia por funcionar sem daemon, o que melhora a segurança e a rastreabilidade para auditoria
  • O Docker usa uma arquitetura cliente-servidor centrada no Docker daemon, enquanto o Podman cria contêineres diretamente na sessão do usuário, deixando o rastreamento do usuário que executou mais claro
  • Como segue o padrão OCI, é possível executar imagens como hello-world, caddy, wordpress e mysql:5.7 do Docker Hub, e em muitos casos basta trocar o comando docker por podman
  • Nomes curtos de imagem não assumem automaticamente o Docker Hub como padrão, então é necessário usar um nome completo de imagem, alias ou a configuração unqualified-search-registries
  • Configurações com múltiplos contêineres podem ser tratadas com Podman Compose, pods ou manifestos do Kubernetes, mas não há orquestração embutida para produção como o Docker Swarm, exigindo um sistema externo como Kubernetes

Onde Podman e Docker se separam

  • Podman é um mecanismo de contêineres open source que busca ser uma alternativa mais segura e mais leve ao Docker
  • Ele executa contêineres sem um daemon residente e adota uma estrutura em que o próprio usuário gerencia diretamente os contêineres
  • Sua orientação de segurança padrão é focada em contêineres rootless, namespaces de usuário e uso mais cuidadoso das capabilities do kernel
  • A compatibilidade com imagens Docker e com a estrutura de comandos do Docker faz dele uma opção prática para desenvolvedores e administradores de sistemas que procuram uma alternativa ao Docker

Arquitetura e rastreabilidade para auditoria

  • O Docker usa um modelo cliente-servidor, em que as solicitações para executar contêineres são enviadas do Docker client para o Docker daemon
    • Os processos dos contêineres tornam-se processos filhos do Docker daemon, e não da sessão do usuário
    • Quando o auditd, sistema de auditoria do Linux, detecta eventos de processos de contêiner, o audit user ID pode aparecer como unset em vez do ID real do usuário
    • Nessa estrutura, fica mais difícil associar uma atividade maliciosa a um usuário específico
  • O Podman usa uma arquitetura sem daemon
    • Cada contêiner é criado diretamente a partir da sessão de login do usuário
    • Os dados de processo do contêiner preservam as informações do usuário
    • O auditd pode detectar e registrar com precisão o ID do usuário que iniciou um processo específico do contêiner
  • Dependendo da imagem, o tempo de inicialização de contêineres no Podman pode ser até 50% mais rápido que no Docker

Gerenciamento do ciclo de vida dos contêineres

  • Como o Podman não tem daemon, a forma de gerenciar o ciclo de vida dos contêineres também difere do Docker
  • No Linux, ele depende bastante do Systemd
    • Para aplicar a política de reinício de contêineres definida com a flag --restart always, ele usa um serviço systemd chamado podman-restart
    • Esse serviço reinicia automaticamente os contêineres configurados após a reinicialização do sistema
  • Ele também oferece um comando para gerar arquivos de serviço do Systemd a partir de contêineres em execução
    • Colocar o contêiner sob gerenciamento do systemd facilita iniciar, parar e verificar seu estado
  • No Docker, esse tipo de tarefa é tratado dentro do próprio daemon

Opções de orquestração

  • No desenvolvimento local, usuários do Docker normalmente definem e gerenciam aplicações com múltiplos contêineres usando o Docker Compose
  • O Podman não oferece suporte nativo a arquivos Compose, mas fornece o Podman Compose como alternativa compatível
    • Em geral, ele funciona com arquivos docker-compose.yml já existentes
    • Quem já está acostumado ao Docker Compose pode continuar usando seus arquivos Compose
  • Como abordagem nativa do Podman, é possível usar pods
    • Trata-se de um conceito trazido do Kubernetes
    • Eles permitem gerenciar vários contêineres como se fossem uma única unidade
  • Em implantações de produção, o Podman não possui uma ferramenta de orquestração embutida como o Docker Swarm
    • Nesse caso, um sistema externo de orquestração, como o Kubernetes, torna-se a alternativa
    • O Kubernetes pode ser integrado ao Podman, mas pode exigir configuração adicional para funcionar corretamente

Padrões de segurança

  • Um grande risco na segurança de contêineres é o escape do contêiner, comprometendo o sistema hospedeiro
  • O Podman foi projetado para oferecer configurações de segurança padrão mais fortes que as do Docker
    • contêineres rootless
    • namespaces de usuário
    • perfis seccomp
  • No Docker também é possível usar contêineres rootless, namespaces de usuário e perfis seccomp, mas isso geralmente não vem ativado por padrão e costuma exigir configuração extra
  • A configuração padrão do Podman executa contêineres rootless dentro de namespaces de usuário isolados, limitando o impacto de um possível escape
  • A configuração padrão do Docker executa os processos do contêiner como root, o que aumenta o risco em caso de escape
  • Os valores padrão de capabilities também são diferentes
    • O Podman inicia contêineres com 11 capabilities por padrão
    • O Docker usa 14 capabilities em uma configuração padrão mais permissiva
  • Ambos podem ser configurados com uma postura de segurança forte, mas em geral o Podman exige menos esforço para chegar a esse ponto

Diferenças que se destacam na comparação de recursos

  • O Podman oferece arquitetura sem daemon e integração com o Systemd
  • É possível agrupar contêineres em pods e também lidar com YAML do Kubernetes
  • O Docker oferece suporte ao Docker Swarm, enquanto o Podman não
  • No restante, a maior parte dos recursos pode ser considerada aproximadamente equivalente entre os dois

Instalação e ambiente de execução

  • Assim como o Docker, o Podman pode rodar nos principais sistemas operacionais
    • macOS
    • Windows
    • principais distribuições Linux
  • A diferença importante é que no Linux ele roda nativamente, enquanto no Windows e no macOS precisa de uma máquina virtual
  • Os exemplos assumem distribuições Linux baseadas em Debian, como Ubuntu, Mint e Debian
  • Para instalar uma versão recente do Podman, é necessário usar uma distribuição relativamente nova
    • No momento em que o texto foi escrito, a versão principal mais recente do Podman era a 4.x
    • O Ubuntu 22.04 LTS está preso ao Podman 3.x
    • Os exemplos usam como base o Ubuntu 23.10
  • Após a instalação, a saída de exemplo mostra podman version 4.3.1, confirmando que o comando podman pode ser executado localmente

Execução de imagens Docker e compatibilidade com OCI

  • O Podman consegue executar a imagem hello-world, construída para o ecossistema de ferramentas do Docker
  • Essa compatibilidade existe porque tanto Docker quanto Podman seguem o padrão OCI (Open Container Initiative)
    • O OCI define a especificação de formato de imagem e a especificação de runtime
    • Isso permite interoperabilidade entre diferentes runtimes de contêiner
  • A maioria das imagens e contêineres do Docker Hub pode ser usada no Podman
  • Isso permite migrar workloads existentes para o Podman sem modificações ou aproveitar a biblioteca de imagens do Docker Hub
  • Mesmo que a saída de hello-world mostre “Hello from Docker!”, quem executa de fato é o Podman
    • Nem o Docker client nem o Docker daemon participam do processo de execução

Como o Podman lida com nomes curtos de imagem

  • O Docker usa o docker.io como registro padrão quando não se informa um nome completo de imagem
  • O Podman não recomenda o uso de nomes curtos e não assume automaticamente um registro padrão
  • hello-world é resolvido como docker.io/library/hello-world porque existe um alias em shortnames.conf
  • Se você tentar executar uma imagem sem alias, como caddy, com nome curto, ocorrerá o seguinte erro
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Há três formas de resolver isso
    • usar um nome completo de imagem, explicitando algo como docker.io/library/caddy
    • adicionar uma seção [aliases] em registries.conf para definir o alias "caddy"="docker.io/caddy"
    • configurar unqualified-search-registries=["docker.io"] para procurar nomes curtos no Docker Hub
  • Configurações por usuário podem ficar em $HOME/.config/containers/registries.conf
    • Esse arquivo tem prioridade sobre /etc/containers/registries.conf
    • Como pode ser configurado sem privilégios de root, ele combina melhor com a abordagem rootless
  • Para usar o Podman como substituto do Docker, a configuração unqualified-search-registries tende a ser mais conveniente no longo prazo do que aliases

Uso de registro privado

  • O Podman também pode usar registros privados, assim como o Docker
  • O exemplo com uma conta do Docker Hub segue este fluxo
    • criar um access token no Docker Hub
    • definir a descrição como Podman tutorial e as permissões como Read & Write
    • criar um repositório privado
    • fazer login com podman login docker.io
  • Se docker.io for a primeira entrada em unqualified-search-registries dentro de registries.conf, isso pode ser omitido, mas explicitar o registro é uma boa prática
  • Se nenhum registro for informado, podman login falhará com o seguinte erro
    • Error: no registries found in registries.conf, a registry must be provided
  • Após o login, é possível enviar a imagem hello-world para o repositório privado, apagar a imagem pública local e depois executar um contêiner usando a imagem do repositório privado
  • Sem credenciais válidas de login, ao fazer pull de uma imagem privada ocorrerão erros de acesso negado e autenticação obrigatória
  • A diferença mais visível no uso de registros privados é trocar docker por podman; no restante, o Podman funciona com registros privados amplamente utilizados

Executando múltiplos contêineres com Podman Compose

  • Quando é necessário executar vários contêineres como uma unidade, o Podman oferece várias opções
    • Podman Compose
    • pods
    • manifestos do Kubernetes
  • O exemplo usa o Podman Compose para executar WordPress e MySQL
  • O Podman Compose é uma ferramenta conduzida pela comunidade, implementa a Compose specification e se integra ao Podman
  • Ele depende de Python 3 e, no exemplo, é instalado com pipx
    • A saída de instalação de exemplo mostra podman-compose 1.0.6
    • A versão do Podman usada é 4.3.1
  • Se o pipx for instalado em $HOME/.local/bin, esse caminho pode não estar presente em $PATH
    • pipx ensurepath pode ser usado para adicionar o caminho
    • Depois disso, é necessário abrir um novo terminal ou recarregar o arquivo de configuração do shell

Exemplo com WordPress e MySQL

  • O exemplo define usuário, senha e nome do banco de dados em um arquivo .env e configura os serviços WordPress e MySQL em docker-compose.yml
  • Ao executar podman-compose up -d, o Podman Compose analisa o docker-compose.yml
  • Processamento do serviço wordpress
    • procura o volume externo necessário e o cria se não existir
    • procura a rede apropriada e a cria se não existir
    • executa o contêiner wordpress
    • se a imagem local não existir, busca wordpress:latest no registro docker.io configurado
  • Processamento do serviço db
    • cria o volume podman-tutorial_db
    • verifica a rede existente
    • executa o contêiner mysql:5.7
    • se a imagem local não existir, faz o pull a partir do Docker Hub
  • Depois da execução, é possível ver a página de instalação do WordPress em localhost:8080
  • A saída de podman ps mostra os contêineres wordpress e db em execução
    • wordpress tem a porta mapeada como 0.0.0.0:8080->80/tcp
    • db está em execução com a imagem mysql:5.7
  • A lista de imagens mostra docker.io/library/wordpress:latest e docker.io/library/mysql:5.7
  • A lista de redes mostra a rede padrão podman e a rede podman-tutorial_default criada pelo Podman Compose
    • podman-tutorial_default é criada para isolar os contêineres definidos em docker-compose.yml dos demais contêineres no mesmo sistema
  • A lista de volumes mostra podman-tutorial_db e podman-tutorial_wordpress
  • podman-compose down para e remove os contêineres, mas mantém a rede e os volumes
    • para remover volumes, use podman volume rm
    • para remover redes, use podman network rm
  • Os comandos são quase iguais aos do Docker e do Docker Compose; a diferença é usar podman e podman-compose no lugar de docker e docker-compose

Critérios de escolha

  • O Podman é uma alternativa prática ao Docker para executar workloads em contêineres
  • Ele consegue fazer a maior parte do que o Docker faz e tem a vantagem de não precisar de um daemon em segundo plano
  • Também oferece recursos que o Docker não tem
    • trabalhar com arquivos de manifesto do Kubernetes
    • organizar contêineres individuais em pods
  • Se você precisa de uma solução de gerenciamento de contêineres mais leve e mais segura, o Podman pode ser a melhor escolha
  • Se a prioridade for um ecossistema forte e amplo suporte da comunidade, o Docker pode ser mais adequado
  • Para explorar mais, consulte o site oficial do Podman, a documentação e a comunidade

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-14
Opiniões do Hacker News

  • Eu gostava de quando o Podman tinha suporte a arquivos de unidade do systemd. Isso porque era possível iniciar e atualizar automaticamente não só contêineres, mas também pods inteiros via systemd
    Só que removeram esse recurso e começaram a empurrar o Quadlet. Para um contêiner individual dá para usar um arquivo de unidade, mas para um pod é preciso usar uma definição de cluster Kubernetes
    Além disso, ao contrário do Docker, como os contêineres seguem as definições do SELinux, passei aperto várias vezes porque eles não conseguiam acessar diretórios mapeados
    No fim, não entendo o que o Podman quer que eu faça. Usar Kubernetes? Não mapear caminhos lógicos e criar diretórios dedicados para tudo?

    • Eu já definia minha infraestrutura com docker-compose.yml, e descobri que o podman-compose tem um recurso mal documentado para gerar unidades systemd
      Esse recurso não usa a funcionalidade agora obsoleta do Podman; ele escreve os arquivos de unidade diretamente e, pessoalmente, achei muito mais fluido do que o modo antigo do Podman
      Para ativar o recurso, use $ podman-compose systemd -a create-unit; para registrar a unidade systemd, use $ podman-compose systemd -a register e $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"
      As atualizações são feitas com $ podman-compose pull e depois $ systemctl --user restart "podman-compose@$PROJECT_NAME". $PROJECT_NAME normalmente é o nome do diretório
      Se quiser conferir, o código-fonte do recurso está aqui: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Ainda estou usando o podman 4.3.1, mas não vejo motivo para esse método parar de funcionar em versões posteriores
    • Dizer que “ao contrário do Docker, os contêineres seguem as definições do SELinux” na verdade aponta para um bug do Docker. Se o sistema não foi configurado para SELinux, ele deve ser desativado
      E os arquivos systemd que o podman-generate-systemd gerava, no fim, basicamente executavam "podman start containername", então também é fácil escrevê-los à mão. Só que, diferentemente de algo como docker-compose, o contêiner é quase uma caixa-preta
      A vantagem do Quadlet é que a definição do contêiner fica declarada em um arquivo .container. Antes, eu escrevia manualmente a linha de comando do podman run na unidade systemd; nesse sentido, o Quadlet é uma grande melhoria e também pode ser uma alternativa ao docker-compose. Claro, há prós e contras
    • Sou fã de longa data, mas concordo com essa parte
      Toda vez que tento executar podman generate systemd [...], lembro de novo que essa transição aconteceu
      Não passo por isso com frequência porque criei meu próprio papel do Ansible que lida com isso de uma forma decente
      Mesmo assim, a sensação é forte de que o Podman perdeu o rumo. Eles já aceitaram o lado de manutenção de arquivos de unidade e modelagem de relações, então eu só queria que deixassem usar o gerador. Não me importo com o Quadlet nem com a história de que ele é melhor
    • Se você não quer lidar com SELinux, basta adicionar isto ao containers.conf: [containers] label=false
      Se você não gosta do nível de segurança padrão do Podman, geralmente há uma forma de desligá-lo
    • Recentemente migrei para o NixOS, e o NixOS trata o systemd como a referência para tudo, inclusive contêineres
      Achei esse modelo muito intuitivo, mas aplicá-lo ao Docker Compose exigia muita migração manual
      Por isso criei uma ferramenta que converte arquivos Compose em configuração do NixOS, permitindo interpretá-los e gerenciá-los de forma nativa: https://github.com/aksiksi/compose2nix

  • Há uma vantagem que quase nunca é mencionada como motivo decisivo para preferir Podman ao Docker: o Docker bagunça a configuração de rede
    Tentar rodar Docker e máquinas virtuais KVM com bridge ao mesmo tempo é um pesadelo, enquanto o Podman, só com as configurações padrão, convive muito melhor
    VPNs também já quebraram por causa do Docker, ou quebraram o Docker, muitas vezes. Não sei bem como o networking do Podman funciona por dentro, mas pelo menos parece bem projetado para não atrapalhar outras tarefas. Eu jamais diria o mesmo do Docker

    • Para mim, o Buildah é o verdadeiro recurso central. Ele também pode funcionar bem com Docker, mas é mais próximo da mesma família de ferramentas do Podman
      Acho Dockerfile um lixo absoluto. Linguagens prontas já bastam; eu realmente odeio quando um “desenvolvedor entediado” inventa uma nova DSL ou linguagem de programação. Especialmente se for YAML — não é o caso aqui, mas Dockerfile é um ótimo exemplo de por que deveríamos parar de fazer esse tipo de coisa
      Olhando para o Buildah sem bud, o motivo fica evidente. Em vez de uma DSL mal ajambrada que fica irritante assim que o caso de uso sai um pouco do caminho padrão, você pode usar Bash, Fish ou o que quiser
      Esse tipo de decisão ruim se espalha por todo o ecossistema Docker. O DCS e seus substitutos sempre inacabados também são exemplos. Em vez de usar um protocolo de assinatura estabelecido como o Cosign, quiseram criar um sistema complicado, difícil de automatizar e especialmente chato para rotação de chaves
    • Podman é gratuito. Docker também é gratuito, mas é chato instalar Docker sem o Docker Desktop
    • Eu ainda rodo Docker e máquinas virtuais KVM com bridge, e funciona normalmente, sem pesadelo. Meio estranho

  • Fico feliz que o Podman esteja se tornando mais usado. Ferramentas demais são criadas supondo que o usuário vai adicionar o grupo sudo docker, então elas quebram em configurações do Docker com consciência de segurança que não concedem acesso root indiscriminadamente

    • Sempre achei engraçado que o futuro de ponta, tipo serverless e contêineres, acabou sendo construído sobre uma base de executar todo tipo de coisa como root

  • Como engenheiro RHEL certificado, já uso Podman há alguns anos
    Sinceramente, gosto bastante para uso pessoal de contêineres. Mas no trabalho ainda fornecemos Docker aos desenvolvedores. Até agora não havia uma forma de oferecer aos desenvolvedores algo que se igualasse à simplicidade do docker compose
    Ao criar imagens de contêiner, também usamos buildah nos pipelines de CI, mas, do ponto de vista do usuário final desenvolvedor, o docker compose ainda domina

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Quase fui pego por causa desse problema

    • O Docker mexe no iptables mesmo só com a configuração e instalação padrão. Em especial, sempre foi uma dor de cabeça quando eu queria usar o nftables, mais novo
    • Por causa das escolhas padrão inseguras do Docker, um minerador de criptomoedas entrou em um contêiner pessoal self-hosted de um projeto no GitHub que deveria ser usado apenas via VPN. Ainda fico irritado com isso
    • Falando de problemas de rede, houve um problema sério em que, em uma configuração aninhada, faltou memória para dispositivos de rede e foi necessário reiniciar o sistema. Se não fosse isso, teria sido uma ótima alternativa ao lxc, uma pena

  • Ainda não sei bem por que a Red Hat investe em criar uma alternativa ao Docker, mas gosto muito do resultado
    O Podman faz quase tudo que o Docker faz e ainda tem recursos como pod, ou muitas vezes adota uma abordagem melhor, como o processo de criação de contêineres sem daemon
    Para desenvolvedores comuns, o maior problema provavelmente é o Docker compose, mas, se você usa um arquivo compose simples, existe o script podman-compose, que tenta ser compatível com a especificação do Docker compose
    Também há uma forma de usar o Podman como backend do docker-compose [1]. No geral, em 2024 não vejo motivo para usar Docker em uma máquina Linux. Não sei muito bem como o Podman se sai no macOS ou no Windows
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • A Red Hat originalmente tentou colaborar com o Docker para corrigir vários problemas que apareceram no passado, por exemplo problemas de compatibilidade com systemd em certos casos de uso, mas não teve muito resultado
      Some a isso o fato de o Docker ter tido, antes e agora, uma quantidade incomumente grande de problemas de segurança, e o fato de contêineres e imagens no estilo Docker serem muito usados entre desenvolvedores, e acabou sendo inevitável criar uma implementação própria mais alinhada ao valor e à abordagem do RHEL
      Por exemplo, embora o Docker consiga funcionar em modo rootless, ainda não usa isso como padrão. Em ambientes reforçados, tanto o grupo de usuários docker quanto a execução sem grupo são difíceis de aceitar em muitos casos de uso do ponto de vista de segurança
      O Docker inicial foi pouco proativo demais em fazer com que contêineres sem privilégios tivessem ao menos um isolamento mínimo e, mesmo depois que os problemas ficaram conhecidos, demorou para corrigi-los. A forma como ele interage com firewall, regras de rede e SELinux também tem muitos problemas. É por isso que não é raro Docker ser proibido em empresas que têm administradores Linux dedicados e preocupados com segurança
    • Uso Podman no Windows. O Docker no Windows foi uma sequência interminável de irritações e frustrações
      Desde o começo, toda a documentação empurra agressivamente para uma instalação via GUI que não é amigável ao usuário. Ele inicia processos pesados no boot, exige cadastro em uma conta de nuvem por algum motivo e ainda reclama de novo que você não pode usar no trabalho esse tal produto open source
      A alternativa sem suporte de instalar “só o Docker de linha de comando” era desnecessariamente complicada e, da última vez que tentei, a maioria das VMs WSL nem era compatível por padrão
      Já com o Podman basta winget install podman e pronto, ele não incomoda. Só inicio a VM do Podman quando preciso executar contêineres e, quando não preciso, o sistema funciona como antes
      Se preciso executar algo com arquivos compose, existe o podman-compose. Talvez ele não lide com configurações incomuns, mas funcionou bem para meu uso
      O que o Podman não faz direito é mais a integração com o VS Code, mas o trabalho para fazer o Docker se comportar no Windows é muito mais irritante do que perder alguns atalhos do VS Code, então isso não chega a ser problema
      Recomendo o Podman como solução padrão de contêineres no Windows. Os motivos para usar Docker seriam basicamente a empresa pagar por ele ou você ter uma configuração compose complexa; nesse caso, talvez valha a pena migrar para Kubernetes
    • O motivo de a Red Hat investir é que o Docker é distante demais da forma como as coisas são feitas no Linux
      Ele faz coisas que quebram o sistema, penou durante anos com rootless e, claro, há também o vendor lock-in
      O Podman é aberto, segue padrões e se encaixa bem com Kubernetes. A quantidade de esforço que desenvolvedores colocaram no Docker só porque ele chegou primeiro ao mercado de contêineres fáceis foi absurda
    • Espero que a visão de que “não há motivo para usar Docker no Linux” não se torne majoritária. Docker não é RedHat/IBM
      Se o Docker desaparecer, a RedHat poderá empurrar sua agenda corporativa com mão ainda mais pesada
      O Podman tem vantagens, mas também há partes que não foram bem executadas no processo de a RedHat tentar substituir tudo do Docker
      Olhando para o histórico da RedHat na área de contêineres, houve um aspecto de desperdício de tempo e esforço em muitos projetos nos quais ela poderia ter contribuído e melhorado
      A RedHat não é uma empresa com uma agenda de fazer o que é certo para seus clientes, então é preciso pensar no que se quer no panorama mais amplo
    • Uso Podman no macOS. No geral, a experiência foi melhor do que com Docker, especialmente no suporte a versões antigas do macOS
      A única grande desvantagem do Podman para macOS é não poder usar a rede do host a partir do contêiner. Mas é raro alguém querer usar a rede do host dentro de um contêiner
      Ainda assim, se você estiver fazendo experimentos relacionados a rede dentro do contêiner e quiser manter o mesmo nome de host e endereço IP do host, é algo a ter em mente. Mesmo assim, tenho usado contornando essa limitação

  • Gosto da abordagem e das decisões com prioridade em segurança. Parece seguro desde a configuração padrão, e também gosto do fato de funcionar com docker compose
    Mas me pergunto se, quando o Podman ficar popular o suficiente, um dia seguirá um caminho próprio nos comandos e no formato yml. Hoje ele parece uma ferramenta que se apoia nos formatos de arquivos do Docker e do Docker compose
    Seria bom se o Podman tivesse uma alternativa ao Swarm. Hoje, por falta de orquestração, parece que Kubernetes é usado como muleta
    Uma equipe que leva segurança a sério provavelmente conseguiria criar uma forma razoável e simples de executar contêineres em pequena escala sem precisar mergulhar como num doutorado em um Kubernetes inseguro por padrão. E ainda poderia manter a compatibilidade com o formato Docker compose

  • Concordo que contêineres rootless e namespaces isolados são recursos de segurança importantes. Mas isso também é possível com Docker rootless e não é complicado. Basta configurá-lo assim
    Já escrevi um texto sobre como configurar o Mastodon com docker rootless aplicando todas as melhores práticas disponíveis atualmente [1]
    A vantagem de continuar usando Docker é que ele é mais acessível. Há mais comunidade e blogs, configurações de docker compose são amplamente disponíveis, e também há mais pessoas ao redor que sabem usá-lo
    No fim das contas, tanto Podman quanto Docker executam processos em namespaces isolados do host
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Não quero que haja mal-entendidos. O Podman é excelente e hoje em dia eu o uso no lugar do Docker, mas no começo comecei a usá-lo achando que era um substituto simples do Docker e acabei me queimando bastante com mapeamento de UID/GID, políticas do SELinux, configurações de DNS ausentes etc.
    Também estraguei toda a configuração várias vezes ao executar system migrate para tentar corrigir problemas. Há todo um sistema próprio relacionado a ACLs de segurança, mapeamento de IDs e labels
    Se você fizer chmod -R dentro da pasta home, provavelmente todos os contêineres podem morrer
    Estou satisfeito com o resultado, mas ficou longe de ser uma solução que “simplesmente funciona” como o Docker. Provavelmente melhorou bastante desde que comecei a usá-lo

    • Comecei a usar este ano, com o objetivo de isolar vários ambientes de desenvolvimento e impedir que o npm tivesse acesso fácil à máquina de desenvolvimento inteira
      Para mim, foi mais fácil de usar do que o Docker. Parece que melhorou em relação às situações que você enfrentou acima

  • Vendo o panorama geral, o Podman parece tão essencial quanto o Linux de antigamente
    Mesmo que pouquíssimas pessoas o usem, sua simples existência impede que seus irmãos de software proprietário muito maiores façam coisas terríveis
    Quando digo “Linux de antigamente”, não quero dizer que o Linux tenha se tornado menos importante; pelo contrário, hoje ele ficou ainda mais essencial e central

    • Se “irmãos de software proprietário muito maiores” se refere ao Docker, é um pouco irônico. Porque RedHat e IBM também fazem muitas coisas ruins no campo do código aberto