Temos acompanhado o projeto de contenção desde o
início . Portanto, não podemos ignorar um evento significativo: ontem à noite, a organização CNCF por trás do Kubernetes e outras excelentes soluções de código aberto para o mundo nativo da nuvem
anunciaram que continham seu "graduado". Este projeto já era o quinto com esse status, juntando-se às fileiras dos K8s, Prometheus, Envoy e CoreDNS.
Critérios do CNCF
O CNCF, que atualmente apoia dezenas de projetos de código aberto,
adotou três categorias para sua classificação:
- Sandbox ("sandbox") - para os primeiros desenvolvimentos experimentais, mas promissores, que (no futuro) "agregam o valor da missão da CNCF", ou seja, contribuirá para o desenvolvimento do ecossistema e da comunidade de código aberto formados em torno da infraestrutura para aplicativos nativos da nuvem modernos. Existem 12 projetos desse tipo.
- Incubação (“incubadora”) - para projetos que tenham pelo menos três usuários (documentados e independentes) em produção, dentro dos quais são fornecidos níveis e escalas de qualidade suficientes (de acordo com o comitê técnico), além de ter um número adequado de colaboradores com bit de confirmação e desenvolvimento estável da base de código. Existem 15 deles.
- Graduação - para projetos com committers de pelo menos duas organizações, um selo de conformidade com as melhores práticas da CII (Core Infrastructure Initiative), adotado pelo Código de Conduta da CNCF , um esquema de gerenciamento e aceitação claramente definido, uma lista pública de usuários e, é claro, um resultado positivo o resultado da votação correspondente pelo comitê técnico da CNCF. Agora existem 5 deles.
Em suma, a prontidão do projeto para “liberação” na CNCF é formulada como sua “rápida adaptação, originalidade, processo formal de gestão e um forte compromisso com uma comunidade sustentável e inclusiva”. O
container , que foi transferido pela Docker para a CNCF há quase 2 anos, agora é reconhecido como atendendo a esses critérios.
Containerd: origens e presentes
O projeto de contenção remonta ao tempo em que as
árvores do Docker eram grandes. Em 2015, seus desenvolvedores anunciaram que era hora de tornar o Docker Engine mais compacto (rápido, confiável, portátil ...) e, portanto, começaram
a levar seus componentes para projetos separados .
Tudo
começou com o anúncio da ferramenta de lançamento de contêiner runc (2015), depois o tempo de execução de contêiner para contêineres (2016) apareceu e, um ano depois, essa iniciativa se tornou ainda mais global e
trouxe a Moby .
Ilustração para o lançamento do Docker 1.11 (abril de 2016): Docker Engine e componentes removidos deleVoltar ao conteúdo. Em resumo, sua função funcional foi reduzida
(e isso não mudou até hoje) ao fato de que, como um daemon no sistema host, ele gerenciava todo o ciclo de vida do contêiner: do recebimento e armazenamento da imagem ao lançamento do contêiner (por meio da runc já mencionada) e controlando seu trabalho. Em março de 2017, um ano após a separação do contêiner, a
Docker o transferiu para o CNCF , o que aconteceu
simultaneamente com uma iniciativa semelhante do CoreOS chamada
rkt (retornaremos a ele) .
Outros desenvolvimentos incluem o
surgimento e desenvolvimento (liderado pela Red Hat) de um concorrente orientado ao Kubernetes chamado CRI-O * ... e a "resposta" espelhada da Docker Inc na forma de
cri-container .
Um daemon (auto-intitulado) especial foi usado para interagir com os K8s no cri-container, e na versão 1.1 a solução se
transformou em um plug-in para o novo ambiente de tempo de execução do contêiner do Kubernetes - Container Runtime Interface (CRI) - e aqui o plug-in foi comunicado diretamente com o container ( chamando as funções necessárias).
Em junho de 2018,
foi anunciado que o plug-in CRI container estava pronto para produção. O repositório de projeto atual é
container / cri .
* É interessante notar que o pedido apresentado em novembro de 2018 para a inclusão do concorrente containerd e rkt - CRI-O - em projetos CNCF ainda não foi aprovado pela organização.Hoje, o containererd se autodiscutivelmente se chama "um ambiente de contêiner executável que é um padrão do setor e se concentra na simplicidade, confiabilidade e portabilidade":
A arquitetura real das soluções de contêineres usando o container
(na maioria das vezes, elas estão focadas no Kubernetes, mas formalmente não estão limitadas a essa plataforma) , é a seguinte:
A solução em si
vem na forma de um daemon para Linux (versões do kernel 4.x são
recomendadas , embora sejam possíveis opções com versões anteriores) e Windows. O código fonte está escrito em Go (versão 1.9.x +
necessária ).
A versão mais recente do containerd é a
1.2.4 (14 de fevereiro de 2019) , onde a
vulnerabilidade CVE-2019-5736 na runc foi corrigida. O próximo marco é a
versão 1.3 , onde são esperadas inovações, como
grupos de contêineres ,
otimização de desempenho para operação de extração de imagens, várias melhorias no trabalho com o snapshotter e
outras .
O projeto tem mais de 3500 estrelas no GitHub, 14 colaboradores e 166 colaboradores de empresas (exceto Docker, é claro) como
Alibaba , Facebook, Google,
Huawei , IBM, Microsoft, NTT e Tesla. Mais estatísticas da base de código podem ser vistas no
DevStats .
Entre os
usuários notáveis de contêineres
, basta mencionar o próprio Moby e projetos relacionados (LinuxKit, BuildKit), serviços em nuvem do Google (GKE), Microsoft (mecanismo acs no Azure e no futuro AKS), IBM (IKS, ICP) e Alibaba, soluções / motores para contêineres (Rio de Rancher, Kata Containers, Balena), bem como até o recente
Firecracker .
Sobre concorrentes
Finalmente, vale dizer que o ritmo de desenvolvimento do rkt - um análogo do container, incluído no CNCF quase ao mesmo tempo - é significativamente menor. Basta indicar que seu último lançamento - v1.30.0 - ocorreu quase um ano atrás (em abril de 2018).
Existem conclusões lógicas do ponto de vista comercial: há cerca de um ano, o desenvolvedor rkt original, CoreOS,
foi adquirido pela Red Hat. E o último
(ou é mais correto dizer que agora a IBM já tem ...) , como mencionado no material, tem sua própria ideia - cri-o - cujas atividades são
muito mais ativas .
No entanto, embora a gigante do Linux não tenha conseguido "inserir" seu projeto no CNCF, talvez as palavras sobre o container como padrão da indústria pareçam bastante críveis.
PS
Leia também em nosso blog: