- O Podman não tem daemons, é compatível com OCI e permite operação sem root com segurança aprimorada.
- UBI, Buildah e Skopeo formam uma pilha sólida para criar, assinar e distribuir imagens.
- Pods, Kubernetes YAML e unidades systemd facilitam a migração da implantação local para a estável.
Se o seu objetivo é executar contêineres leves no Linux com máxima segurança e controle, o Podman é uma das melhores opções disponíveis. Ele compartilha o ecossistema OCI, oferece uma interface de linha de comando (CLI) bastante familiar para usuários do Docker e, o mais importante, elimina o daemon principal, reduzindo a superfície de ataque e o consumo de recursos.
Este guia prático e completo reúne as informações mais relevantes da Red Hat, SUSE e ferramentas relacionadas, como Buildah e Skopeo. Você aprenderá a instalar, configurar e operar contêineres e pods, criar imagens eficientes (incluindo UBI), gerar arquivos YAML para unidades Kubernetes ou systemd e, ao longo do processo, navegar com facilidade por logs, políticas de confiança, verificações de integridade e eventos.
O que é Podman e por que ele se destaca em contêineres leves?
O Podman é um mecanismo de contêineres sem daemon que está em conformidade com as especificações OCI e permite executar, criar e gerenciar imagens e contêineres com uma sintaxe praticamente idêntica à do Docker. A principal diferença é arquitetônica: não há um processo mestre raiz em segundo plano para o qual as solicitações são enviadas, o que simplifica a segurança e o modelo operacional.
Outra vantagem fundamental é o suporte a sistemas sem privilégios de root : usuários sem privilégios elevados podem criar e executar contêineres sem a necessidade de privilégios adicionais. Isso não só aumenta a segurança, como também melhora a rastreabilidade, pois as ações ficam associadas ao usuário real do sistema e não a um daemon executado como root.
A compatibilidade do Docker com a linha de comando é excelente. Você pode usar comandos como `podman build` , `podman run` ou `podman images` praticamente da mesma forma. Existe até um pacote `podman-docker` que cria um alias para que a execução do Docker invoque o Podman de forma transparente, o que é útil ao executar scripts legados.
O Podman adota o conceito de pod do Kubernetes : agrupar vários contêineres que compartilham uma rede e determinados namespaces. É ideal para compor serviços que cooperam entre si (por exemplo, um banco de dados e seu cliente) e para gerar descrições portáteis para o Kubernetes usando YAML, por exemplo, para integrar o Docker ao Kubernetes.
No ecossistema empresarial, a Red Hat substituiu o mecanismo Docker no RHEL 8 por uma pilha sem daemon baseada em Podman, Buildah e Skopeo. Além disso, promove imagens UBI redistribuíveis para construção sobre uma base RHEL de qualidade, sem restrições de assinatura de destino.
Instalação e requisitos por distribuição
No RHEL 8 e derivados, a maneira mais fácil é habilitar o módulo container-tools , que inclui Podman, Buildah e Skopeo. Após registrar o sistema, se necessário, instale o módulo disponível e você terá tudo o que precisa para trabalhar com contêineres de forma integrada.
No Fedora, o pacote está disponível nos repositórios e é instalado usando o gerenciador de pacotes padrão. No Ubuntu (20.04 e posterior), ele pode ser instalado com o APT a partir dos repositórios padrão ou adicionando o PPA estável libcontainers para a versão mais recente. No SLE Micro , o Podman está incluído por padrão e, caso esteja faltando, pode ser adicionado seguindo a documentação oficial da SUSE.
Verifique seu ambiente com `podman info` para ver detalhes sobre armazenamento , cgroups, compatibilidade sem privilégios de root e plugins. Uma maneira rápida e leve de verificar a rede e o DNS é executar um contêiner Alpine interativamente com um simples `podman run --rm -it alpine sh`.
Se você planeja compilar ou usar imagens protegidas do Red Hat (por exemplo, em registry.redhat.io ), lembre-se de que é necessário autenticar-se com credenciais válidas do portal, enquanto registry.access.redhat.com oferece acesso não autenticado a parte de seu catálogo.
Trabalhando em modo rootless: configuração e limites práticos
O modo rootless é um dos recursos mais interessantes do Podman. Para habilitá-lo corretamente, você deve ajustar os namespaces de usuário e os mapeamentos de subuid e subgid. Se você estiver migrando de sistemas mais antigos ou usando contas preexistentes, revise os arquivos /etc/subuid e /etc/subgid para atribuir intervalos suficientes a cada usuário.
O comando `podman unshare` permite que você insira o namespace do usuário e verifique os mapeamentos efetivos de UIDs e GIDs. Isso é útil para diagnosticar por que um contêiner sem privilégios de root não consegue acessar determinados arquivos ou por que um volume remoto falha com esse usuário.
Existem restrições importantes: um contêiner em modo rootless não pode abrir portas inferiores a 1024. Em cenários de desenvolvimento, você pode alterar o parâmetro do kernel para habilitar portas não privilegiadas de nível inferior ou usar o encaminhamento de portas no host para acessar as portas 80 ou 443 sem elevar privilégios.
Existem também serviços que exigem privilégios globais, como as configurações de hora do sistema . Se você executar o ntpd dentro de um contêiner sem privilégios de root e conceder a ele permissões inadequadas, poderá acabar afetando o host. É preferível manter esses daemons no sistema ou usar pods/serviços com os limites corretos.
Um detalhe operacional importante: o armazenamento de contêineres sem privilégios de root deve residir em um sistema de arquivos local . Montagens remotas geralmente causam problemas com namespaces de usuário. Além disso, se a autenticação do usuário for proveniente de LDAP ou Active Directory , será necessário manter intervalos estáticos de subuid e subgid localmente para que o mapeamento funcione corretamente.
Política de pesquisa, extração e confiança em logs
Por padrão , o Podman consulta os registros listados em /etc/containers/registries.conf . Como usuário root, você pode modificar a configuração do sistema; como usuário sem privilégios, você pode sobrescrever isso criando seu próprio arquivo em $HOME/.config/containers/registries.conf para ajustar prioridades, espelhos ou marcar registros inseguros em sua sessão.
Para localizar imagens, use o comando `podman search` . Você pode pesquisar em todos os registros definidos ou limitar por domínio e, se precisar de resultados completos, adicione `--no-trunc` . Se um registro exigir credenciais, faça login primeiro para que a listagem mostre os repositórios privados acessíveis.
A política de confiança permite verificar assinaturas de imagens. Ela é definida em `/etc/containers /policy.json` e nos arquivos YAML em `/etc/ containers/registries.d/`. A Red Hat publica assinaturas para suas imagens; você pode adicionar seções específicas para `registry.access.redhat.com` e `registry.redhat.io`, especificando os URLs dos repositórios de assinaturas que o sistema deve consultar ao fazer uma solicitação de pull request.
Se você alterar a política padrão para ` reject` , só poderá fazer pull de escopos assinados ou explicitamente permitidos. Isso é útil para reforçar a segurança de servidores de compilação ou ambientes regulamentados. Você pode verificar a política ativa exibindo o JSON da política e testando com ` ubi8-minimal` para ver como a assinatura é validada durante o pull.
É altamente recomendável usar nomes totalmente qualificados ao extrair imagens, especificando o registro, o namespace, o repositório e o rótulo. Isso evita falsificação com nomes curtos e também documenta melhor a origem de cada imagem em seus scripts.
Imagens de base UBI e construção com Buildah
As Imagens Base Universais (UBIs) do RHEL 8 são imagens base oficiais e de livre distribuição. Elas incluem versões padrão, mínimas e de inicialização, além de imagens de tempo de execução para linguagens específicas (como Python , PHP, Ruby e Node.js). O objetivo é permitir que você crie sua aplicação em uma base RHEL de alta qualidade e a distribua sem ficar vinculado a uma assinatura no destino.
A imagem padrão do ubi8 oferece um conjunto robusto de ferramentas para a maioria dos cenários. Em contraste, a imagem ubi8-minimal minimiza o tamanho e inclui apenas o essencial; você pode adicionar pacotes com o microdnf durante a compilação, caso precise de dependências adicionais.
A variante ubi8-init integra o systemd como PID 1 e define um StopSignal especial , já que o systemd ignora os sinais de saída convencionais. Isso é útil quando você deseja executar serviços gerenciados pelo systemd dentro do contêiner com maior fidelidade a uma máquina tradicional.
Em hosts RHEL inscritos, o contêiner UBI padrão pode acessar tanto os repositórios do host quanto os repositórios UBI, dando acesso a todo o catálogo de pacotes . Se você deseja que a imagem resultante seja redistribuível, desabilite os repositórios não-UBI durante o processo de compilação para garantir que apenas pacotes RPM com licença livre sejam incluídos.
Para construir, o Buildah oferece duas opções: a partir de um Dockerfile usando `buildah bud` , ou de forma mais granular, criando um contêiner funcional, montando seu sistema de arquivos, copiando arquivos e executando configurações com `buildah config` . Com o ubi8-minimal , lembre-se de usar `microdnf` em vez de `yum`.
Operando contêineres e imagens com Podman
Para execuções pontuais, você pode executar comandos curtos com `podman run -rm` . Por exemplo, você pode visualizar o sistema base de uma imagem com `cat /etc/os-release` ou abrir um shell bash interativo para investigar o conteúdo do contêiner e realizar testes sem persistência.
A inspeção é muito abrangente: com o comando `podman inspect`, você pode visualizar metadados de contêineres e imagens, além de formatar a saída para obter campos específicos como `NetworkSettings.IPAddress` , `.Config.ExposedPorts` ou o `State.Pid` do processo.
Se precisar entrar em um contêiner em execução , use `podman exec` com um shell, e você não interromperá o processo principal. Isso é ideal para observar o que um aplicativo está fazendo enquanto atende tráfego ou processa tarefas.
Para persistir e compartilhar dados, o Podman oferece suporte a volumes . Você pode criar um volume, montá-lo em um contêiner e, assim, manter os arquivos mesmo se excluir e recriar o contêiner. É recomendável montar o volume pelo nome, em vez de pelo caminho interno do host, para evitar exclusões acidentais com o comando `prune`.
Imagens e contêineres são gerenciados com `podman images` , `podman rmi` , `podman ps` , `podman rm` e comandos similares. Para mover imagens entre máquinas, salve-as em um arquivo tar com `podman save` e recarregue-as com `podman load` . O par `export`/`import` também está disponível caso você queira capturar o sistema de arquivos de um contêiner específico.
Geração de pods e YAML para Kubernetes
Um pod agrupa contêineres e fornece a eles um contêiner de infraestrutura que mantém seus namespaces. Você pode criá-los com `podman pod create` , listá-los com `podman pod ps` e executar contêineres dentro deles especificando `--pod` . É uma maneira natural de preparar implantações com vários componentes que cooperam entre si.
Depois de configurar um pod conforme sua preferência, você pode gerar seu manifesto do Kubernetes com `podman generate kube` . Isso criará um arquivo YAML portátil que descreve o pod e seus contêineres. Posteriormente, você poderá recriar a configuração no mesmo host com `podman play kube` ou implantá-la em um cluster com `kubectl` ou ` oc`.
Lembre-se de que a geração não reflete os volumes LVM do host nem detalhes avançados de armazenamento ; se você os utilizar, documente esses requisitos separadamente ou crie objetos de armazenamento equivalentes no orquestrador.
No OpenShift, você pode usar `oc create` com as flags `dry run` para construir arquivos YAML de recursos a partir de imagens e publicá-los de forma controlada. No Kubernetes, a operação é muito semelhante com `kubectl create`.
Trabalhar com pods localmente acelera a transição para produção , porque a topologia já está projetada em termos de pods e contêineres, e o arquivo YAML serve como um contrato entre desenvolvimento e operações.
Integração Systemd: Serviços de Contêiner e Pod
O Podman integra-se perfeitamente com o systemd . Com `podman generate systemd` , você pode criar unidades para contêineres ou pods existentes, ou gerar definições portáteis com `--new` que criam e iniciam o contêiner se ele não existir e o destroem quando o serviço for interrompido.
As unidades podem ser baseadas no usuário (em $HOME/.config/systemd/user ) ou no sistema (em /etc/systemd/system ou /usr/lib/systemd/system ). Para serviços de usuário, habilite-os com systemctl --user e lembre-se de ajustar o tempo de inicialização persistente do usuário se desejar que eles continuem ativos após o logout.
Se você estiver gerenciando um pod com vários contêineres, concentre-se no serviço do pod e evite iniciar ou parar contêineres internos separadamente com o systemctl, pois o serviço do pod os coordena juntamente com o contêiner de infraestrutura.
Verifique opções como `--restart-policy` para garantir que seus serviços de contêiner iniciem automaticamente na inicialização do sistema e em caso de falha. É uma forma simples de orquestração local que utiliza a conhecida semântica de unidade de serviço do Linux.
Uma dica: regenere os arquivos de unidade ao atualizar o Podman; os modelos evoluem e o comando `podman generate systemd` fornece a versão mais recente das diretivas recomendadas.
Ferramentas Skopeo, Buildah e a caixa de ferramentas
O Skopeo permite inspecionar imagens em registros remotos sem baixá-las completamente, copiar entre servidores de armazenamento e assiná-las. É ideal para auditar metadados de imagens e sincronizar repositórios, além de compartilhar um arquivo de autenticação com o Podman e o Buildah quando ambos estão em execução no mesmo host.
Se você executar o Skopeo em um contêiner , monte o arquivo de autenticação do host com a opção apropriada ou faça login novamente dentro do contêiner. Para listar ou copiar para o armazenamento local, monte também o caminho de armazenamento do contêiner do usuário ou do sistema, conforme necessário.
O Buildah simplifica a criação de imagens OCI do zero, a partir de Dockerfiles ou de contêineres em execução. Ele compartilha o mesmo armazenamento local, portanto, as imagens baixadas com o Podman ou o Buildah são intercambiáveis. Você pode montar o sistema de arquivos do contêiner em execução, copiar arquivos e confirmar alterações com `buildah commit`.
O utilitário toolbox e a imagem support-tools permitem abrir um contêiner privilegiado para diagnóstico do host. Ele monta o sistema de arquivos do sistema em /host e permite executar ferramentas como sosreport ou gcore em processos do host sem afetar o sistema base.
Algumas imagens do Red Hat incluem rótulos de execução (runlabels) que definem comandos prontos para uso para instalar, executar ou desinstalar. Com o comando `podman container runlabel`, você pode invocar esses rótulos em imagens como `rsyslog` ou `support-tools` para simplificar as implantações com os privilégios e montagens apropriados.
Verificações de integridade, informações do sistema e eventos
As verificações de integridade são usadas para determinar se um processo dentro de um contêiner está íntegro ou pronto. Elas são definidas com um comando a ser executado e parâmetros como intervalo, número de tentativas, tempo limite e período de tolerância na inicialização. Elas operam dentro do contêiner, portanto, projete a verificação levando em consideração o funcionamento da aplicação.
Se você quiser executar manualmente, pode usar o comando `check` para ver o último status e seu código de saída ; zero significa sucesso. Essa é uma maneira útil de depurar quando uma sonda sinaliza o contêiner como não íntegro.
O Podman System fornece informações abrangentes sobre o ambiente: armazenamento, versão, suporte a cgroups, tempo de execução e configuração. Isso é muito útil quando você suspeita de um problema de permissões, cgroups ou compatibilidade com o kernel.
Por fim, o podman events permite monitorar o que está acontecendo: criação, inicialização e parada de contêineres; alterações em pods; operações de imagem; e eventos de sistema e volume. Cada evento inclui um registro de data e hora, tipo, status e nome, perfeito para rastrear comportamentos incomuns.
Com tudo isso, você pode criar contêineres verdadeiramente leves e bem controlados com o Podman no Linux: instale-o em sua distribuição favorita, use o modo rootless com sabedoria, utilize o UBI quando necessário, compile com o Buildah, inspecione e sincronize com o Skopeo, crie serviços em pods, gere YAML para o Kubernetes, integre-se ao systemd e monitore a integridade e os eventos sem perder de vista a segurança.
Escritor apaixonado pelo mundo dos bytes e da tecnologia em geral. Adoro compartilhar meu conhecimento por meio da escrita, e é isso que farei neste blog, mostrar a vocês tudo o que há de mais interessante sobre gadgets, software, hardware, tendências tecnológicas e muito mais. Meu objetivo é ajudá-lo a navegar no mundo digital de uma forma simples e divertida.