O Projeto Moby Pós-Kubernetes: 3 novos lançamentos em 2023

O último grande lançamento do Moby Project de código aberto foi em 2020, mas este ano veremos três grandes lançamentos, de acordo com dois colaboradores do Moby.

O Projeto Moby é uma coleção de componentes que podem ser usados ​​para construir sistemas baseados em contêineres, incluindo um tempo de execução de contêineres, um registro de contêineres, ferramentas de construção de contêineres, ferramentas de orquestração e ferramentas de rede, registro e monitoramento. Esses componentes podem ser usados ​​para construir sistemas baseados em contêineres, como aplicativos nativos da nuvem, arquiteturas de microsserviços, pipelines de CI/CD e plataformas de contêineres locais.

O mantenedor do Moby, Bjorn Neergaard, é engenheiro de software sênior na Docker. Ele foi acompanhado pelo membro do comitê de direção técnica, Sebastiaan van Stijn, também engenheiro de software da Docker, na apresentação sobre o Projeto Moby na DockerCon no início deste mês. Eles ofereceram detalhes dos principais lançamentos de 2023, bem como planos para o futuro.

Pré-Moby: uma breve história

Neergaard e van Stijn iniciaram sua palestra na DockerCon com uma breve história do Moby como um projeto de código aberto. Isso remonta aos dias em que os desenvolvedores usaram contêineres pela primeira vez como máquinas virtuais leves, difíceis de usar e muito específicas, disse van Stijn.

“Não foi amplamente utilizado porque era muito complicado”, disse van Stijn. “Foi difícil manter a sincronia; não houve distribuição de imagens nem nada.”

Então o dotCloud, uma pequena plataforma como serviço que se tornaria o Docker, começou a oferecer serviços. Descobriu-se, porém, que o que realmente interessava aos tecnólogos era o que o dotCloud estava fazendo nos bastidores: eles estavam implantando contêineres de tecnologia, em sua maioria escritos em Python e exigindo muitos scripts para fazer os contêineres funcionarem, explicou van Stijn. dotCloud decidiu abrir o código-fonte do que eles usavam internamente.

Então, em 2013, Solomon Hykes, fundador do Docker, apresentou contêineres Linux durante uma palestra relâmpago na PyCon.

“Foram cinco minutos, mas causou uma grande repercussão na indústria porque, nesses cinco minutos, ele mostrou uma execução do docker pela primeira vez”, disse van Stijn. “Aquela execução do Docker fez muito do trabalho que precisava ser feito com o LXC, mas apenas em um único comando.”

O Docker ainda era um invólucro do LXC naquela época, com o LXC fazendo todo o trabalho pesado. Ele forneceu uma maneira fácil de usar UX, mas também um formato de imagem – o que fez uma grande diferença porque agora os desenvolvedores podiam usar uma imagem em vez de criar seu próprio sistema de arquivos para um contêiner. Não houve construção neste momento. Também forneceu uma API, que permitiu aos desenvolvedores fazer “coisas legais”, acrescentou.

“Isso causou um grande impacto no mercado porque, pela primeira vez, os contêineres Linux se tornaram realidade e chegaram às mãos dos desenvolvedores”, disse ele.

O LXC estava funcionando, mas o Docker decidiu reescrever o tempo de execução para criar um tempo de execução nativo integrado ao Docker Engine, disse van Stijn, o que mais tarde provou ser importante à medida que mais coisas foram adicionadas, como redes. Os contêineres se popularizaram, mas cada um tinha uma única tarefa, o que significava que os programadores precisavam de mais de um contêiner na maioria das pilhas. Isso levou às primeiras tentativas de orquestração, que mais tarde se tornou composta e permitiu definir um arquivo YAML.

Docker adquiriu Fig, que se tornou Docker Compose. Então o Docker iniciou o Swarm, que na versão um permitia aos desenvolvedores executar seus contêineres em um cluster de máquinas. Então o Kubernetes entrou online e decidiu usar o Docker como tempo de execução porque era o padrão de fato para executar contêineres, disse van Stijn. Isso gerou alguns problemas, pois mais pessoas solicitaram recursos que estavam claramente fora do escopo do projeto, acrescentou.

“O Kubernetes não precisava da pilha de rede do Docker, não precisava de outras coisas que fornecíamos, mas ainda usava o tempo de execução e às vezes as coisas eram desafiadoras”, disse ele. “O motor como um monólito tornou-se cada vez mais um problema.”

Além disso, embora Docker fosse o de fato padrão, não havia especificação formal de imagens para contêineres ou como o tempo de execução deveria se comportar, disse ele.

“A implementação foi a especificação e isso nem sempre é ideal”, disse ele.

Docker decidiu dividir o tempo de execução real. Na mesma época, começou a OCI, uma organização de padronização. Docker doou as especificações que estava usando para distribuir a imagem, bem como as especificações de tempo de execução e imagens.

“Agora outras pessoas poderiam implementar os tempos de execução, imagens e registros, não apenas o Docker.”

O Docker também começou a reescrever o tempo de execução do zero com algumas empresas parceiras, o que levou ao containerd (pronuncia-se “container D”), uma reescrita completa das partes do tempo de execução do Docker.

O Nascimento do Projeto Moby

O Projeto Moby começou quando Docker decidiu dividir o projeto ainda mais em componentes menores, porque as pessoas queriam usar contêineres e outras partes do motor Docker, disse van Stijn ao público na apresentação. Isso levou ao Build Kits para construção, ao Swarm Kit para orquestração e ao mecanismo Docker. A CLI passou a fazer parte dos produtos Docker, como um projeto separado, acrescentou. O próprio tempo de execução tornou-se o projeto Moby.

“Isso poderia ser usado para que outros construíssem e participassem, mas também tornou mais fácil aceitar mudanças que podem não beneficiar diretamente o Docker como produto, mas que poderiam ser usadas por outros – e vice-versa”, disse ele.

O próprio Docker também mudou com os produtos corporativos indo para Mirantis, enquanto o Docker voltou para seus produtos voltados para desenvolvedores. O Docker concentrou-se no desktop Docker e o trabalho no projeto Moby desacelerou até os últimos 18 a 24 meses, quando os mantenedores da Mirantis e da Microsoft se juntaram ao esforço, acrescentou.

“Uma das coisas que confunde as pessoas é o que aconteceu com o código-fonte aberto conhecido como Docker”, explicou Neergaard. “Mas talvez também ajude a explicar um pouco que há mais participantes – e não apenas participantes, mas pessoas que são partes interessadas no projeto – do que apenas Docker, Inc.”

Além da Mirantis e da Microsoft, a Nvidia contribuiu recentemente com suporte para interface de dispositivo contêiner, acrescentou Neergaard.

O que está acontecendo agora

“Nos caminhos relativamente recentes, mas também temos visto muito mais atividade no projeto”, disse Neergaard. “Isso é visível de várias formas, (mas) talvez não seja comunicado da melhor maneira.”

Atividade recente no Projeto Moby

O lançamento mais recente do motor Docker foi em 2020. Entre então e agora, houve muitos códigos e melhorias que nunca encontraram um veículo de lançamento, acrescentou.

Este ano já houve dois lançamentos principais – versão 23.0 e 24.0, sendo os principais recursos:

• BuildKit, ativado por padrão (não mais DOCKER_BUILDKIT=1). BuildKit é uma reescrita do construtor, disse Neergaard. “Parte do mandato e do plano original do BuildKits era substituir o construtor legado clássico no mecanismo Docker e fornecer uma plataforma de construção muito mais rica e flexível, que ainda é tão simples quanto a construção do Docker”, disse ele. “Então o BuildKit está ativado por padrão agora.”
• CSI (Interface de armazenamento de contêiner) no Swarm
• Calços de contêiner alternativos:
  • gVisor
  • Recipientes Kata
  • WebAssembly
• Containers

Os calços alternativos são “talvez enfadonhos”, disse Neergaard, mas abrem muitas possibilidades, “especialmente para pessoas que inventam novas maneiras de executar um contêiner ou executar algo que se parece com um contêiner, como o WebAssembly”.

A equipe esperava oferecer uma terceira versão, 25.0, antes da DockerCon, mas isso não aconteceu. O lançamento está previsto para qualquer dia, de acordo com a apresentação. Esse lançamento incluirá:

• CDI (Interface de Dispositivo de Contêiner)
• OTEL (OpenTelemetry) integrado ao motor
• Verificações de saúde “elegantes” com intervalo de início de saúde, o que há muito tempo é um problema, disse Neergaard.

“Penso que terminaremos com três lançamentos do motor este ano, mas ainda é um desafio significativo; estamos melhorando a cada vez”, disse Neergaard.

“Outra coisa interessante, que surpreende as pessoas, é que ainda existem novos recursos no Docker Swarm”, disse ele. Swarm é a resposta do Docker ao Kubernetes, explicou ele.

“Neste ponto, eu diria que o Kubernetes é a plataforma de fato para orquestração, e você provavelmente não deveria escolher algo diferente do Kubernetes, a menos que tenha um bom motivo”, disse Neergaard. “Há um grupo pequeno, mas ainda muito expressivo, de usuários que gostam de usar o Swarm e desejam que o Swarm faça mais coisas – ou até mesmo seja compatível com muitos complementos e extensões existentes para Kubernetes.”

Os planos futuros para o Projeto Moby incluem a adição de vários snapshooters e multiarquitetura nativa em contêineres, bem como uma CLI redesenhada, correções de bugs e novos recursos para rede e movimentação da lógica do reconciliador do Compose para o daemon do Docker Declarativo, acrescentou a dupla.

A postagem O Projeto Moby Pós-Kubernetes: 3 novos lançamentos em 2023 apareceu pela primeira vez em The New Stack.