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.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?