É claro que, atualmente, as paixões em torno da Red Hat têm um
foco completamente diferente e muito global, mas ainda estamos falando sobre o nosso próprio local e aplicado a partir do mundo dos contêineres. Desde o início deste ano, a Red Hat vem trabalhando ativamente em um substituto para o Docker chamado
Podman (ou
libpod ). Por alguma razão, eles ainda não escreveram sobre esse projeto e agora é um bom momento para conhecê-lo, aprender sobre suas origens e pensar em perspectivas. Vamos lá!
CRI-O como uma história de fundo
Se você observar o mundo moderno dos contêineres Linux, é fácil ver que o tópico do artigo de hoje é apenas um dos estágios de uma estratégia de longo prazo da Red Hat. Uma confirmação vívida disso é
o projeto CRI-O , que
escrevemos cerca de um ano atrás. Em resumo, o CRI-O é uma implementação do Kubernetes CRI (Container Runtime Interface) para iniciar os tempos de execução do contêiner compatíveis com o padrão OCI (Open Container Initiative). Ainda mais curto, este é um substituto para o Docker como um tempo de execução do Kubernetes.
(Uma iniciativa tecnicamente semelhante para K8s da Docker Inc é a cri-container , sobre a qual também escrevemos ; no mesmo artigo, há uma comparação do desempenho dessas duas soluções.)A história do CRI-O é tal que, enquanto a OCI preparava padrões para contêineres (
especificação de tempo de execução e
especificação de imagem )
[que, no entanto, também aconteceu com a participação da Red Hat] , um novo projeto chamado OCID foi criado e colocado na incubadora Kubernetes em RH ( Open Container Initiative Daemon), que mais tarde foi [solicitado pela OCI] renomeado como CRI-O. Seu objetivo era “a implementação de uma interface padrão para o ambiente de tempo de execução de contêineres no Kubernetes”, e a promoção nas “massas técnicas” foi realizada como parte de um projeto maior da Red Hat para criar um sistema operacional para contêineres -
Projeto Atomic .
Bonés com o logotipo CRI-O no KubeCon + CloudNativeCon North America 2017Nos últimos tempos, o CRI-O amadureceu para a
versão 1.0 ,
recebeu suporte no Minikube e sua última conquista pode ser considerada a
adoção da interface de contêiner padrão no
projeto Kubic , que, principalmente, é desenvolvido pela comunidade competitiva (para Red Hat) Distribuição Linux - openSUSE.
Voltando ao tópico do artigo: Podman fazia parte originalmente do CRI-O.
A aparência e a essência de Podman
O anúncio oficial do projeto Podman (nome abreviado para "pod manager")
ocorreu em fevereiro deste ano:
“Podman (anteriormente conhecido como kpod) existe desde o verão passado. Inicialmente, fazia parte do projeto CRI-O . Alocamos o podman para um projeto separado - libpod . Queríamos que Podman e CRI-O crescessem no seu próprio ritmo. Ambos funcionam muito bem individualmente (como utilitários independentes) e juntos. ”
Por esse motivo, o anúncio em si foi intitulado como "
reintrodução" . E o primeiro lançamento público do Podman -
v0.2 - ocorreu duas semanas antes deste anúncio. Então, qual é a essência do Podman?
O objetivo de Podman é fornecer uma interface de console para o lançamento de contêineres fora do sistema de orquestração. Vale ressaltar que os contêineres lançados podem ser combinados em grupos especiais com namespaces comuns, ou seja, pods - esse conceito já se tornou conhecido graças ao Kubernetes. O projeto segue a ideologia dos comandos UNIX, onde cada utilitário faz apenas uma coisa, mas é boa. Outro detalhe importante, que os desenvolvedores enfatizam incansavelmente, já foi citado acima no anúncio: Podman pode ser usado tanto com o CRI-O quanto de forma independente.
Em geral, a idéia principal do Podman é fornecer aos usuários do Kubernetes que escolhem o CRI-O como o tempo de execução do contêiner um análogo da interface do console da CLI do Docker (para interagir com contêineres e imagens em execução em clusters):
“O Podman implementa 38 dos 40 comandos da CLI do Docker definidos no Docker 1.13 (na época do anúncio em fevereiro - aprox. Transl. ), Mas alguns deles não foram repetidos especificamente. Por exemplo, relacionado ao Docker Swarm - em vez disso, para pods / containers que requerem orquestração, sugerimos o uso do Kubernetes. Além disso, alguns comandos para plug-ins do Docker, como plug-ins de volume e para a rede, não foram implementados. Uma lista completa dos comandos do Podman e seus equivalentes no Docker pode ser encontrada na página Transferência do uso do Podman . ”
Um fragmento da tabela de comparação para os comandos Docker e Podman: a maioria deles é a mesma, mas também há diferençasNo entanto, por trás dessa identidade visível na interface existe uma diferença fundamental na arquitetura: se a CLI do Docker se comunica com o daemon do Docker para executar comandos, o Podman é um utilitário independente que não requer daemons para seu trabalho.
Pelo menos por causa dessa diferença de arquitetura, será mais correto comparar o Podman não com o Docker como tal, mas com o crictl, um utilitário de console da
cri-tools (é usado, em particular, para a
integração do container com o Kubernetes). E existem diferenças funcionais: o Podman pode reiniciar contêineres parados e também fornece gerenciamento de imagens de contêineres. (Para uma comparação mais detalhada, consulte o
blog do
OpenShift .)
Com o
lançamento do Fedora 28 Atomic Host (em maio), o Podman se tornou a ferramenta de gerenciamento de contêiner padrão para esta distribuição Linux. E apenas recentemente, em setembro, na conferência Linux All Systems Go! em Berlim, Dan Walsh, chefe da equipe de engenharia de contêineres da Red Hat, apresentou Podman a um público ainda mais amplo - uma gravação da performance pode ser vista
aqui (mas apenas a apresentação
aqui ).
Apresentação Podman na All Systems Go! 2018Notas técnicas
A versão mais recente do Podman é a
v0.10.1.3 (datada de 18 de outubro) e a mais recente com novos recursos é a
v0.10.1 (12 de outubro), que incorporou várias novas equipes e sinalizadores adicionais.
O código Podman é escrito em Go e é distribuído sob a Apache License 2.0 gratuita. Pacotes prontos para instalação estão disponíveis para o Fedora versão 27 e posterior (também há
um guia de instalação para o Ubuntu). Entre os componentes dependentes para o Podman funcionar, estão utilitários para contêineres Linux, como
runc e
conmon , além de
plug-ins de rede CNI .
Tanto o início do contêiner com o Podman quanto o trabalho com ele são semelhantes ao cenário usual de uso da
docker :
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Para uma introdução prática ao Podman, você também pode usar o script on-line Katacoda apropriado: "
Contêineres sem Docker - iniciando contêineres usando Podman e Libpod ".
Por fim, o projeto
pypodman , que está em desenvolvimento ativo e oferece uma interface Python para execução remota de comandos do Podman, merece menção especial.
Não apenas Podman: libpod e o ecossistema
Juntamente com Podman, o artigo mencionou repetidamente o projeto libpod. Qual a diferença?
Se falamos sobre o projeto "completo" do Red Hat, ele é chamado libpod e
está hospedado no GitHub com esse nome. Hoje, a libpod está posicionada como "uma biblioteca para aplicativos que precisam trabalhar com o conceito de lareiras de contêineres, popularizado pelo Kubernetes". E o próprio Podman é um utilitário que faz parte da biblioteca libpod.
Se retornarmos a uma visão mais ampla dos contêineres, a Red Hat terá sua própria visão, que ganha vida com todo um conjunto de utilitários para todas as ocasiões. A maioria deles está concentrada em repositórios com o nome falado
github.com/containers , e isso já mostra as ambições óbvias da empresa
(a propósito, alguns desses projetos costumavam estar localizados em github.com/projectatomic ) .
As visões da Red Hat sobre a padronização e desenvolvimento do ecossistema de contêineres são
articuladas diretamente no README do projeto libpod:
Já escrevemos sobre quase todos esses projetos (runc, containers / imagem, containers / armazenamento, CNI, conmon) na
revisão do CRI-O , no entanto, uma adição importante desde então foi um utilitário para a construção de imagens de container chamado
buildah . Além disso, a Red Hat já possui respostas prontas para outras necessidades do mundo moderno de contêineres, como o
udica para gerar perfis de segurança SELinux e
skopeo para trabalhar com registros remotos de imagens.
Resumindo
Assim como a Red Hat não está apenas por trás de sua plataforma corporativa para contêineres OpenShift, mas também participa ativamente da vida do projeto Open Source Kubernetes, a empresa americana está percebendo sua visão sobre a moderna infraestrutura de TI em um nível mais fundamental - os próprios contêineres, os engenheiros do DevOps e do SRE estão tão preocupados com a orquestração. Podman e libpod são componentes importantes de todo o ecossistema que a Red Hat está construindo no mundo dos contêineres de padrões abertos. Se você observar o que está acontecendo, o acordo com a IBM mencionado no início do artigo,
apresentado como uma iniciativa para formar um fornecedor líder de soluções no campo de nuvens híbridas, parece ainda mais interessante em todo o setor ...
Por fim, proponho uma pequena pesquisa sobre o conhecimento dos leitores do Habra sobre o projeto Podman antes do surgimento deste artigo. Obrigado por participar!
PS
Leia também em nosso blog: