Em todos os âmbitos do mercado de tecnologia existe uma competitividade muito alta, porém existem casos em que determinadas tecnologias ao surgirem dominam o mercado e não existe um concorrente direto disputando espaço de forma igualitária. Esse foi o caso do Git que surgiu e dominou o mercado de versionamento de código-fonte frente às opções da época (CVS, Subversion, Mercurial, entre outros).

E aconteceu algo semelhante ao Docker. Essa incrível ferramenta surgiu em 2013 e ressignificou uma série de atributos no ciclo de desenvolvimento de software desde a forma como um desenvolvedor trabalhar localmente na sua máquina até a forma de disponibilizar um código em produção, tornando-se praticamente um requisito a todo programador.

E ainda quebrou o paradigma do “Na minha máquina funciona”.

Se o Docker é tão bom, por que aprender uma alternativa?

A empresa por trás do Docker, a Docker, Inc. e o próprio Docker estiveram ligadas a fortes decisões que provocaram bastante agitação na comunidade de software no mundo inteiro.

Venda da Docker Enterprise para a Mirantis. Entre os acontecimentos, a Docker, Inc., deixa de ter posse do Docker Swarm, ferramenta de orquestração de containers nativa do Docker (para mais detalhes, clique aqui).
Restrição de solicitações pull no Docker Hub (para mais detalhes, clique aqui).
Kubernetes anuncia que deixará de dar suporte a containers Docker (para mais detalhes, clique aqui).

Todos os acontecimentos (com exceção do terceiro), possuem seu lado positivo e negativo e estão abertos a discussão e pontos de vistos.
E ainda, sobre o anuncio do Kubernetes, não é uma decisão pessoal contra o Docker, e sim uma decisão técnica devido ao Docker não ter se adequado ao CRI (Container Runtime Interface) do Kubernetes.

E de acordo com o próprio Kubernetes, o suporte ao Docker só será removido em uma versão futura (atualmente planejada para a versão 1.22, no final de 2021).

Isso não significa que o Docker está morto. Particularmente, acredito que o Docker se adequará ao CRI do Kubernetes.

O exatamente significa o fim do suporte do Kubernetes ao Docker?

O Kubernetes é o que chamamos de orquestrador de containers extensível. O que significa que o Container Runtime não é dele. É uma interface chamada de CRI – Container Runtime Interface. Isso quer dizer que o Kubernetes não é o responsável pelo build de imagem, pela execução do container em si. Ele orquestra quem o faz.

O Docker, por padrão, não é uma implementação CRI compliant. Com isso, é necessário criar um adapter para usar o runtime de containers do Docker no Kubernetes. Esse adapter chama-se DockerShim.

Logo, não é o Docker que será deprecated, e sim o DockerShim. E você pode entender todos os argumentos no Dockershim Deprecation FAQ, diretamente no blog do Kubernetes.

E assim chegamos ao Podman

Nesse momento de mudanças e definições a respeito do futuro do Docker, concorrentes que não eram tão conhecidos, vão ganhando força como ContainerD, CRI-O e o Podman.

A seguir vamos falar especificamente do Podman.

O Podman (o POD MANager) é uma ferramenta para gerenciar contêineres e imagens, volumes montados nesses contêineres e pods feitos de grupos de contêineres. Totalmente baseada em libpod, uma biblioteca para gerenciamento do ciclo de vida do contêiner que também está contida neste repositório. A biblioteca libpod fornece APIs para gerenciar contêineres, pods, imagens de contêiner e volumes.

Essa incrível ferramenta é um projeto de código aberto que está disponível na maioria das plataformas Linux e reside no GitHub .

Por fim, o Podman fornece um front-end de linha de comando compatível com Docker que pode simplesmente criar um alias para o Docker cli, **alias docker = podman** .

Isso é algo que a sua própria documentação sugere, consulte aqui

Principais diferenças entre Docker e Podman

O Docker possui dois blocos principais: Docker CLI e Docker Daemon.

O Docker Daemon: é um processo constante em segundo plano que ajuda a gerenciar imagens Docker, contêineres, redes e volumes de armazenamento. E ainda existe uma API Docker Engine REST para interagir com o daemon Docker, acessada via protocolo HTTP.

O Docker CLI é o cliente de linha de comando Docker para interagir com o daemon Docker. Naturalmente o usamos quando executamos qualquer comando Docker.

Devido essa arquitetura o Docker possui alguns problemas:

Docker é executado em um único processo (e todos os processos filhos pertencem a este processo), o que pode resultar em um único ponto de falha;
Se o Docker Daemon falhar, todos os processos filhos perderão o controle e entrarão no estado órfão;
Todas as etapas precisam ser executadas pelo root para as operações do Docker.

Enquanto isso o Podman foi criado sem daemon, ainda assim, é possível desenvolver, gerenciar e executar contêineres OCI em seu sistema Linux. Os contêineres podem ser executados como root ou no modo rootless. Com isso, possui alguns benefícios adicionais como:

Interage diretamente com o registro de imagens, contêineres e armazenamento de imagens;
O Docker é construído sobre um runtime container chamado runC e usa Daemon, em vez de usar o daemon, o Podman está usando diretamente o runC;
Não há necessidade de iniciar ou gerenciar um processo de daemon;
Há compatibilidade entre imagens do Podman e do Docker.

Instalando o Podman

O cliente MacOS está disponível por meio do Homebrew:

brew install podman

O cliente Linux/CentOS está disponível por meio do Yum:

sudo yum -y install podman

O cliente remoto mais recente para Windows está disponível nesse link.

Para outras distruições, consulte a documentação do Podman, clicando aqui.

Comandos no Podman

Help

podman -–help

Na versão 2.2.1 do Podman, ao executar o comando acima, obterá a seguinte saída:

Para quem está habituado com os comandos Docker, percebe-se que realmente há bastante semelhança com a CLI do Podman, trazendo praticamente as mesmas opções de comandos, assim podemos simplesmente seguir trabalhando com os comandos que já conhecemos.

Conclusão

Nesse artigo aprendemos sobre o Podman, uma nova opção de container engine.
Entretanto, vale ressaltar que o Docker continua sendo a principal tecnologia quando o assunto é container e possivelmente isso não mudará tão cedo. Mas é válido conhecermos e explorarmos novas opções ao atual favorito do mundo de containers. Afinal, tecnologias podem passar, mas os conceitos são imutáveis.