Embora existam muitos blogs e tutoriais bons sobre Podman e Buildah, os usuários do Docker claramente não possuem explicações claras e concisas sobre como eles mudam para o Podman, por que o Buildah é necessário em outros problemas desse tipo.
Vamos tentar responder a essas perguntas e explicar como migrar perfeitamente do Docker para o Podman.
Como o Docker funciona
Vamos começar esclarecendo como o Docker funciona para entender por que o Podman e o Buildah surgiram. Como você sabe, os comandos do Docker funcionam apenas quando o processo do daemon do Docker está em execução. A idéia com o demônio, ao que parece, era coletar em um só lugar todas as coisas legais que o Docker faz e, ao mesmo tempo, organizar APIs úteis para trabalhar com ele no futuro. Conforme mostrado na figura abaixo, o daemon do Docker contém toda a funcionalidade necessária para executar as seguintes tarefas:
- Operações de puxar e empurrar ao trabalhar com o registro de imagens;
- Criando cópias de imagens no armazenamento local do contêiner e adicionando camadas a esses contêineres;
- Confirmar alterações em contêineres e remover imagens de contêiner do repositório local no host;
- Solicite ao kernel do SO que inicie o contêiner no espaço de nomes correspondente, cgroup etc.
Em essência, o daemon do Docker cuida de todo o trabalho com registros, imagens, contêineres e kernel. E você apenas diz a ele o que fazer através da interface da linha de comandos (CLI).
Aqui não consideraremos os prós e os contras dessa abordagem, quando tudo estiver reunido em um processo demoníaco. Muitos argumentos podem ser feitos a seu favor e, no momento do surgimento de Docker, fazia todo o sentido. No entanto, com o uso ativo do Docker, começaram a surgir perguntas para ele, por exemplo:
- Um único processo significa um único ponto de falha;
- O processo daemon possui todos os processos filhos (executando contêineres);
- Quando o demônio parte, os processos filhos permanecem órfãos;
- A montagem do contêiner possui falhas de segurança;
- Para executar qualquer operação do Docker, os usuários precisam de privilégios de root completos.
Houve outras queixas. Pode-se não concordar com isso ou dizer que essas deficiências já foram eliminadas, mas não vamos discutir. Os desenvolvedores do Podman acreditam que conseguiram resolver muitos desses problemas e, se você quiser tirar proveito do Podman, este artigo é para você.
A essência do Podman é interagir com o registro de imagens, com contêineres e armazenamento de imagens, bem como com o kernel Linux, não através de um daemon, mas diretamente através do processo runC, responsável pelo lançamento de contêineres.
Agora que descobrimos parcialmente os motivos dos desenvolvedores do Podman, é hora de discutir o que a transição para o Podman significa para o usuário. E aqui precisamos entender e esclarecer (o faremos abaixo) o seguinte:
- Podman substitui o Docker. Ao mesmo tempo, não é mais necessário iniciar algum tipo de processo de daemon, como o daemon do Docker;
- Os comandos familiares do Docker funcionam da mesma maneira em Podman;
- Podman não armazena contêineres e imagens no mesmo local que o Docker;
- As imagens Podman e Docker são compatíveis;
- Nos ambientes Kubernetes, o Podman é capaz de mais do que o Docker;
- E também vamos analisar o que é Buildah e por que é necessário.
Instalação Podman
Se você usa o Docker, pode removê-lo quando decidir fazer uma troca. No entanto, você pode deixar o Docker enquanto tenta o Podman. Existem algumas
lições úteis e ótimas
demonstrações que podem ser úteis para ler e ver para iniciantes, para que você possa entender melhor o processo de transição. Um exemplo na demonstração requer que o Docker mostre compatibilidade.
Para instalar o Podman no
Red Hat Enterprise Linux 7.6 ou posterior, use o seguinte; se você estiver usando o Fedora, substitua o yum pelo dnf:
# yum -y install podman
Podman usa os mesmos comandos que o Docker
O Podman foi projetado para facilitar a troca do Docker. Portanto, todas as equipes que você conhece do Docker trabalham da mesma maneira no Podman. Além disso, argumenta-se que os scripts de chamada do Docker devem funcionar bem se você criar o alias apropriado, como este: alias docker = podman - apenas tente. Obviamente, antes disso, é necessário parar o Docker (systemctl stop docker). Além disso, você pode instalar o pacote podman-docker, que fará todas as conversões necessárias para você. Ele simplesmente coloca um script em / usr / bin / docker que executa o Podman com os mesmos argumentos que o Docker usa.
Os comandos habituais do Docker, como pull, push, build, run, commit, tag, etc., estão todos no Podman. Consulte o manual do Podman para obter mais informações. Uma diferença importante é que no Podman algumas equipes adicionaram sinalizadores de conveniência, por exemplo, os sinalizadores --all (-a) para os comandos podman rm e podman rmi, que muitos acharão muito úteis.
Além disso, o Podman pode ser executado como um usuário comum, sem privilégios de root. É verdade que até agora isso só funciona no Fedora e no Podman 1.0, e no RHEL deve aparecer a partir das versões 7.7 e 8.1. Isso foi possível graças a melhorias na proteção do espaço do usuário. A execução como usuário comum significa que, por padrão, o Podman armazena imagens e contêineres no diretório inicial do usuário, discutiremos isso com mais detalhes na próxima seção. Para saber mais sobre como executar o Podman sem privilégios de root, consulte o artigo de Dan Walsh
Como funciona o Podman sem root? .
Imagens de Podman e contêiner
Quando você insere o comando podman images pela primeira vez, é provável que desanime, pois não verá nenhuma imagem do Docker que já tenha sido baixada no computador antes. O fato é que o repositório local do Podman está localizado na pasta / var / lib / containers, e não no diretório / var / lib / docker. Isso foi feito não apenas assim, mas como parte de uma nova estrutura de armazenamento que atende aos padrões da OCI (Open Containers Initiative).
Em 2015, Docker, Red Hat, CoreOS, SUSE, Google e outros criadores de tendências de contêineres Linux criaram a Open Container Initiative, um órgão independente para gerenciar a especificação de padrões para o formato de imagens de contêineres e seu tempo de execução. Como parte do OCI, projetos de containers / imagem e containers / armazenamento foram criados no GitHub.
Como o Podman pode ser executado sem privilégios de root, ele precisa de um local separado para gravar imagens. Portanto, o repositório Podman está localizado no diretório inicial do usuário ~ / .local / share / containers. Isso ajuda a evitar uma situação em que eles possam escrever tudo em / var / lib / containers e em relação a outras práticas perigosas do ponto de vista da segurança. Além disso, agora cada usuário possui seu próprio conjunto separado de contêineres, para que vários usuários possam trabalhar simultaneamente no host ao mesmo tempo. Após concluir o trabalho, os usuários podem enviar por push ao registro geral para disponibilizar suas imagens para outras pessoas.
Ao alternar do Docker para o Podman, conhecer os novos caminhos de localização do contêiner será útil durante a depuração, bem como quando você deseja limpar o repositório local com o comando rm -rf / var / lib / containers para iniciar tudo de novo. No entanto, ao mudar para Podman, você provavelmente começará a usar a nova opção -all para os comandos podman rm e podman rmi, em vez deste comando.
Compatibilidade de contêiner entre Podman e outros tempos de execução
Apesar dos diferentes locais dos repositórios locais, o Docker e o Podman criam imagens de contêiner compatíveis com o padrão OCI. O Podman pode usar registros populares de contêineres, como o Quay.io ou o Docker Hub, bem como registros particulares nas duas direções (empurrar e puxar). Por exemplo, com o Podman, você pode baixar e executar a imagem mais recente do Fedora no Docker Hub. Se você não especificar um registro, o Podman, por padrão, pesquisará os registros listados no arquivo registries.conf, seguindo a ordem especificada neste arquivo. Inicialmente, o primeiro deste arquivo é o registro do Docker Hub.
$ podman pull fedora:latest $ podman run -it fedora bash
As imagens carregadas no registro usando o Docker podem ser baixadas e executadas usando o Podman. Por exemplo, se criamos uma imagem do myfedora usando o Docker e a carregamos no nosso repositório Quay.io (ipbabble), você pode baixá-la usando o Podman, veja como:
$ podman pull quay.io/ipbabble/myfedora:latest $ podman run -it myfedora bash
O Podman permite mover imagens de maneira fácil e elegante entre os diretórios / var / lib / docker e / var / lib / containers usando os comandos push e pull, por exemplo:
$ podman push myfedora docker-daemon:myfedora:latest
É claro que, se você omitir o docker-daemon neste exemplo, o envio por envio será direcionado ao Docker Hub. Se você especificar quay.io/myquayid/myfedora, a imagem será carregada no registro Quay.io (aqui myquayid é o nome da nossa conta no Quay.io):
$ podman push myfedora quay.io/myquayid/myfedora:latest
Se você decidir que está pronto para abandonar o Docker, para desinstalá-lo, simplesmente desligue o daemon e remova o pacote do Docker usando o gerenciador de pacotes. Porém, antes disso, baixe todas as imagens necessárias usando o Docker para o registro externo (não local), para que você possa baixá-las posteriormente. Ou você pode usar o Podman para baixá-los do repositório local Docker para o repositório local Podman OCI. Por exemplo, no RHEL, a transferência de uma imagem do fedora é feita assim:
# systemctl stop docker # podman pull docker-daemon:fedora:latest # yum -y remove docker # optional
Podman facilita a mudança para o Kubernetes
O Podman oferece vários recursos adicionais - comparados ao Docker - que são úteis para desenvolvedores e operadores de TI ao trabalhar com o Kubernetes, em particular, comandos úteis que o Docker simplesmente não possui. Se você conhece o Docker e pensa em mudar para o Kubernetes / OpenShift como uma plataforma de contêiner, o Podman será útil.
O Podman pode gerar um arquivo YAML do Kubernetes com base em um contêiner em execução usando o comando podman generate kube. E ao depurar pods em execução, além dos comandos padrão para trabalhar com contêineres, você também pode usar o comando podman pod. Para obter mais informações sobre como o Podman ajuda a mudar para o Kubernetes, consulte o artigo de Brent Baude, Podman agora pode facilitar a transição para o Kubernetes e o CRI-O.
Buildah - o que é e por quê
Buildah apareceu antes de Podman. E isso às vezes desencoraja os usuários do Docker: “Por que os apologistas do Podman estão subitamente falando sobre o Buildah? Podman não sabe construir? "
Nós nos apressamos em tranquilizar, Podman pode, e faz exatamente como Docker. Ou seja, a montagem pode ser executada usando o Dockerfile e o comando podman build, ou você pode iniciar o contêiner, fazer as alterações necessárias e depois confirmar (executar confirmação), criando uma nova tag na imagem do contêiner. Em nossa interpretação, o Buildah é um conjunto estendido de comandos para criar e gerenciar imagens de contêiner e, portanto, fornece um controle muito mais preciso ao trabalhar com imagens. O comando de construção do Podman contém parcialmente a funcionalidade Buildah e usa o mesmo código de programa para a construção que o próprio Buildah.
A maneira mais eficiente de usar o Buildah é escrever scripts Bash para criar imagens, da mesma forma que você escreve para um Dockerfile.
Quanto à cronologia do aparecimento de Buildah e Podman, os eventos ocorreram aproximadamente da seguinte maneira. Quando o Kubernetes aprendeu a trabalhar com o CRI-O com base no padrão OCI para tempos de execução de contêiner, o daemon do Docker não era mais necessário. Ou seja, não era mais necessário instalar o Docker em todos os nós do cluster Kubernetes para executar pods e contêineres nele. Agora, o Kubernetes pode chamar o CRI-O e esse pode executar o RunC diretamente, o que, por sua vez, inicia os processos do contêiner. No entanto, se ao mesmo tempo desejarmos usar o mesmo cluster Kubernetes não apenas para o lançamento, mas também para a montagem de contêineres (como, por exemplo, no OpenShift), precisaremos de uma nova ferramenta de construção que não dependa do daemon do Docker e , como resultado, não exigiria a instalação do Docker. Além disso, essa ferramenta, criada com base nos projetos de contêineres / armazenamento e contêineres / imagem, eliminaria os riscos de segurança associados ao soquete aberto do daemon Docker durante a montagem, e muitos usuários do Docker estão preocupados com esses riscos.
E a Buildah se tornou uma ferramenta tão nova (o nome se lê como “build” e imita o sotaque de Boston do gerente de projetos Dan Walsh ao pronunciar a palavra “builder”). Mais informações sobre o Buildah podem ser encontradas em buildah.io, além de blogs e guias de links no final deste artigo.
Há mais alguns detalhes para saber se você deseja usar o Buildah:
- Ele fornece controle mais preciso ao criar camadas de imagem. Em particular, ele permite que você faça o que muitos usuários de contêiner desejam há muito tempo - confirme muitas alterações de uma só vez com apenas uma camada.
- A corrida de Buildah e a corrida de Podman são duas coisas diferentes. Como o Buildah foi projetado para criar imagens, seu comando de execução é essencialmente o mesmo que o comando RUN no Dockerfile. William Henry, um dos desenvolvedores do Buildah, lembra como essa solução surgiu: “De alguma forma, eu estava reclamando que alguma porta ou montagem não funcionava como eu esperava. Dan Walsh (@rhatdan) pesou tudo e disse que a Buildah não deveria trabalhar com contêineres dessa maneira. Tudo, sem mais mapeamentos de portas e sem volumes de montagem. Removemos esses sinalizadores e, em vez disso, usamos buildah run para executar os comandos necessários ao criar imagens de contêiner, por exemplo, buildah run dnf -y install nginx. "
- O Buildah pode criar imagens do zero (imagens do zero). Ou seja, imagens nas quais não há nada, literalmente. De fato, se você observar o armazenamento do contêiner criado como resultado do comando buildah from scratch, haverá um diretório vazio. Isso é muito útil do ponto de vista da criação de imagens super leves, contendo apenas os pacotes necessários para executar o aplicativo.
Por que construir do zero? Vamos comparar a imagem de desenvolvimento de um aplicativo Java com sua imagem para um ambiente de produção ou para um ambiente intermediário. No estágio de desenvolvimento, a imagem pode conter o compilador Java, Maven e outras ferramentas necessárias ao desenvolvedor. Porém, ao traduzir para produção, apenas o Java Runtime e seus pacotes devem permanecer na imagem. A propósito, para remover o supérfluo, você não precisa de um gerenciador de pacotes, como DNF / YUM, nem precisa do Bash - você pode fazer tudo através da interface da Buildah CLI, como mostra a figura abaixo, onde o contêiner tradicional de múltiplas camadas fica à esquerda e a única camada à direita imagem arranhada. Consulte
Criando uma imagem de contêiner Buildah para demonstração de introdução do Kubernetes e
Buildah para obter mais detalhes .
Voltando à cronologia. Então, o Kubernetes aprendeu a trabalhar com o CRI-O e o runC, e para a construção que empilhamos o Buildah - tudo, desde o Docker no host do Kubernetes, você pode recusar? Não, a depuração ainda permanece. Como resolver problemas com contêineres se o host não possui as ferramentas apropriadas? Não coloque Docker nele, caso contrário, voltaremos ao demônio e todos os esforços foram em vão. E então Podman entra em cena.
Ou seja, Podman resolve dois problemas ao mesmo tempo. Primeiro, permite que os operadores de TI inspecionem contêineres e imagens usando comandos familiares. E segundo, ele fornece essas mesmas ferramentas para os desenvolvedores. Como resultado, todos os usuários do Docker - desenvolvedores e operadores - podem mudar para Podman e executar calmamente as tarefas para as quais usavam o Docker anteriormente, além de resolver uma série de novas tarefas.
Recursos necessários:
- Site para os projetos Podman.io e Buildah.io.
- Projetos em github.com/containers (conecte-se, estude a fonte e veja o que está em desenvolvimento:
- libpod (Podman);
- buildah;
- image (código para trabalhar com imagens OCI de contêiner);
- armazenamento (código para armazenamento local de imagens de contêiner).
Links úteis: