Guia Completo de Podman e Alternativas ao Docker: Daemonless Containers na Prática Já leu

Entendendo Containers Tradicionais vs. Daemonless

A história dos containers começa com o Docker, que revolucionou a forma como empacotamos e distribuímos aplicações. No entanto, a arquitetura tradicional do Docker depende de um daemon — um processo sempre rodando com privilégios elevados no servidor. Esse daemon centraliza todas as operações de container, desde sua criação até gerenciamento de redes e volumes. Essa abordagem traz segurança como principal preocupação: se alguém comprometer o daemon, compromete toda a infra de containers daquele host.

O Podman (Pod Manager) apresenta uma filosofia radicalmente diferente. Em vez de usar um daemon central, cada container é gerenciado diretamente pelo usuário ou processos específicos. Isso significa que quando você executa um container no Podman, não há um serviço daemon rodando continuamente. A arquitetura é modular, permitindo que cada componente funcione de forma isolada e independente, reduzindo a superfície de ataque e simplificando a manutenção. Essa mudança fundamental muda não apenas a segurança, mas também como pensamos sobre orquestração e controle de privilégios em ambientes containerizados.

Podman: Arquitetura e Diferenciais Técnicos

Como Funciona o Podman

O Podman utiliza a biblioteca libpod, que abstrai as operações de baixo nível necessárias para gerenciar containers usando tecnologias Linux como cgroups, namespaces e SELinux. Diferentemente do Docker, o Podman não precisa de um daemon externo. Quando você executa podman run, você está invocando diretamente o binário do Podman, que cria um novo processo container sem intermediários. Isso também significa que os containers são propriedade do usuário que os criou, não de um daemon centralizado.

Uma vantagem prática desse design: você pode usar systemd para gerenciar containers como serviços de primeira classe. Containers não desaparecem quando você faz logout ou quando a sessão SSH encerra. O Podman também é totalmente compatível com a OCI (Open Container Initiative), o padrão de imagens Docker, permitindo migração quase direta de scripts e workflows.

Instalação e Configuração Básica

Para instalar o Podman em um sistema baseado em Debian/Ubuntu, execute:

sudo apt-get update
sudo apt-get install -y podman podman-docker

Para Red Hat/Fedora:

sudo dnf install -y podman podman-docker

O pacote podman-docker fornece um alias que mapeia comandos docker para podman, permitindo usar scripts antigos sem modificação. Após a instalação, teste com:

podman --version
podman run --rm hello-world

Se você receber erros de permissão, configure rootless containers. O Podman suporta execução sem privilégios root através de user namespaces. Para habilitar, adicione seu usuário ao grupo de subuid/subgid:

# Verificar se já tem subuids configurados
grep $(whoami) /etc/subuid /etc/subgid

# Se não tiver, configure manualmente
sudo usermod --add-subuids 100000-165535 $USER
sudo usermod --add-subgids 100000-165535 $USER

Executando Containers com Podman

A sintaxe é praticamente idêntica à do Docker, mas com diferenças importantes no comportamento. Aqui, criaremos um container simples com uma aplicação web:

# Container simples
podman run -d --name meu-nginx -p 8080:80 nginx:latest

# Verificar status
podman ps

# Ver logs
podman logs meu-nginx

# Executar comando dentro do container
podman exec -it meu-nginx bash

Agora, um exemplo mais realista com volumes e variáveis de ambiente:

# Container com volume e variáveis
podman run -d \
  --name postgres-db \
  -e POSTGRES_PASSWORD=senhaSegura123 \
  -e POSTGRES_USER=appuser \
  -v dados_postgres:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:15-alpine

O Podman cria automaticamente o volume dados_postgres se não existir. Para inspecionar volumes:

podman volume ls
podman volume inspect dados_postgres

Uma diferença importante: no Podman, você pode parar um container e ele continua existindo. Para removê-lo completamente:

podman rm meu-nginx
podman volume rm dados_postgres

Alternativas e Comparação com Docker

LXC (Linux Containers)

LXC é a tecnologia de containers mais antiga, funcionando em nível de sistema operacional. Ao contrário de containers de aplicação (como Docker), LXC cria máquinas virtuais leves que comportam todo um sistema operacional. O LXC é gerenciado pelo daemon lxd e é ideal quando você precisa de isolamento total ou executar serviços que exigem múltiplos processos por container.

# Instalação do LXD (daemon do LXC)
sudo snap install lxd

# Inicializar
sudo lxd init --auto

# Criar container LXC
lxc launch ubuntu:22.04 meu-container

# Executar comando
lxc exec meu-container -- apt update

A principal diferença: LXC é "system container" (VM leve), enquanto Docker/Podman são "application container" (um processo isolado). Escolha LXC se precisar de múltiplos serviços por container ou ambiente completo; escolha Podman se quer aplicações isoladas e leves.

Containerd

Containerd é um runtime de containers de baixo nível, mantido pela CNCF e baseado em padrões OCI. Diferentemente do Docker (que usa containerd internamente mas adiciona camadas), containerd é mais minimalista. É gerenciado por um daemon, assim como Docker, mas com menos overhead e mais controle fino.

# Instalação (exemplo em Ubuntu)
wget https://github.com/containerd/containerd/releases/download/v1.7.0/containerd-1.7.0-linux-amd64.tar.gz
sudo tar Czxvf containerd-1.7.0-linux-amd64.tar.gz -C /usr/local

# Criar arquivo de serviço systemd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# Iniciar daemon
sudo systemctl start containerd

Usar containerd requer nerdctl como CLI:

# Instalação do nerdctl
wget https://github.com/containerd/nerdctl/releases/download/v1.4.0/nerdctl-1.4.0-linux-amd64.tar.gz
sudo tar Czxvf nerdctl-1.4.0-linux-amd64.tar.gz -C /usr/local/bin/

# Uso (sintaxe similar a Docker)
nerdctl run -d --name app nginx:latest
nerdctl ps

Comparação Rápida

Podman em Produção: Orquestração e Melhores Práticas

Usando Podman Compose

Para orquestrar múltiplos containers, o podman-compose é a alternativa nativa do Podman ao Docker Compose. Ele lê arquivos docker-compose.yml e funciona sem daemon centralizado.

Instale o Podman Compose:

sudo curl -o /usr/local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/main/podman-compose
sudo chmod +x /usr/local/bin/podman-compose

Crie um arquivo docker-compose.yml:

version: '3.9'

services:
  app:
    image: python:3.11-slim
    container_name: minha-app
    command: python -m http.server 8000
    ports:
      - "8000:8000"
    volumes:
      - ./app:/app
    working_dir: /app
    environment:
      - DEBUG=True
    networks:
      - app-network

  banco:
    image: postgres:15-alpine
    container_name: app-postgres
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: senha123
    volumes:
      - pg_data:/var/lib/postgresql/data
    networks:
      - app-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  pg_data:

networks:
  app-network:
    driver: bridge

Execute com:

podman-compose up -d
podman-compose logs -f app
podman-compose ps
podman-compose down

Containers como Serviços Systemd

Uma vantagem única do Podman é integração nativa com systemd. Em vez de orquestração centralizada, crie arquivos de serviço para containers individuais:

# /etc/systemd/system/container-app.service
[Unit]
Description=Minha Aplicação em Container
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=appuser
Restart=always
RestartSec=10
ExecStart=/usr/bin/podman run --rm \
  --name app-container \
  -p 8000:8000 \
  -v /home/appuser/app:/app:z \
  -e APP_ENV=production \
  python:3.11-slim \
  python -m http.server 8000

ExecStop=/usr/bin/podman stop app-container

[Install]
WantedBy=multi-user.target

Ative e inicie:

sudo systemctl daemon-reload
sudo systemctl enable container-app.service
sudo systemctl start container-app.service
sudo systemctl status container-app.service

Agora o container é gerenciado como qualquer outro serviço Linux, com logs centralizados em journald:

journalctl -u container-app.service -f

Segurança no Podman

O Podman rootless é significativamente mais seguro. Containers rodando como usuário normal não conseguem afetar o sistema hospedeiro. Porém, há considerações:

# Rodar container em modo rootless (padrão para usuário normal)
podman run -d --name app-seguro nginx:latest

# Verificar owner do processo
ps aux | grep nginx

# Verificar namespaces isolados
podman inspect app-seguro | grep -A 10 'SecurityOpt'

Para máxima segurança, use SELinux labels (se disponível):

podman run -d \
  --security-opt label=type:svirt_apache_t \
  --name app-hardened \
  nginx:latest

Use sempre imagens de fontes confiáveis e escaneie vulnerabilidades:

# Com ferramentas como Trivy
trivy image nginx:latest

Conclusão

Três pontos fundamentais aprendidos nesta aula: Primeiro, o Podman representa uma evolução arquitetural genuína ao eliminar o daemon centralizado, oferecendo melhor segurança, isolamento de privilégios e gerenciamento direto via systemd. Segundo, a compatibilidade com ferramentas Docker (docker-compose, OCI) torna a migração praticamente transparente, sem reescrever workflows existentes. Terceiro, você não precisa escolher uma única solução — Docker continua dominante em desenvolvimento, Podman em ambientes de segurança elevada, containerd em orquestração cloud-native, e LXC quando você realmente precisa de system containers completos. A decisão deve ser baseada em requisitos específicos: segurança, escalabilidade e modelo de governança.

Referências

1. Documentação Oficial do Podman
2. Podman Compose no GitHub
3. Open Container Initiative (OCI) Spec
4. Red Hat: Introduction to Podman
5. Containerd Documentation