Cinco alternativas ao Docker que você deve considerar

Docker liderou o caminho para o mundo dos contêineres, mas agora há uma variedade de outras opções. O especialista Mark Betz descreve cinco alternativas sólidas para Docker, com conselhos práticos.

O SQL foi mais ou menos inventado pela IBM no início da década de 1970, mas três garotos, Bob Miner, Ed Oates e Larry Ellison, fizeram parte de um negócio com o lançamento do sistema de gerenciamento de banco de dados relacional do Relational Software em 1979. Os bancos de dados relacionais eram um avanço fundamental e, pelo menos em retrospectiva, parece óbvio que um mercado grande e competitivo se desenvolveria ao seu redor.

É divertido e um pouco humilde notar que 38 anos depois, a IBM voltou a participar, junto com o Google e outros, no desenvolvimento de outro avanço computacional fundamental: o contentor Linux LXC. Mais uma vez, tomou um tipo empresarial, Solomon Hykes do dotCloud, para tornar as idéias e as ferramentas em uma plataforma comercialmente viável. O resultado de seus esforços e de outros foi Docker, o que provavelmente não requer mais nenhuma introdução aqui. Embora o Docker não funcione mais em LXC, a herança genética sempre estará lá.

A história é a nossa melhor ferramenta para a previsão – a visão real é impossível – e se for um guia neste caso, continuaremos a ver um mercado grande e vibrante construído em torno de contêineres de desenvolvimento e as plataformas nas quais eles correm. É provável que seja um em que Docker estará desempenhando um papel central, mas talvez não mais dominante. Haverá concorrência para as peças principais que possuem agora e para o ecossistema de ferramentas que crescem em torno desse núcleo. Aqui está uma lista de cinco nomes que valem a pena manter um olho, nenhum dos quais é Docker.

1. Open Container Initiative (OCI)

 

A evolução da infra-estrutura fundamental é muito importante para ser deixada nas mãos de qualquer entidade comercial única e, portanto, a Iniciativa Open Container foi lançada há cerca de um ano para promover padrões abertos para formatos de contêiner de desenvolvimento e tempos de execução. Docker é um suporte principal e doou recentemente seu mecanismo de contêiner runC para o OCI. Outros apoiadores inclusos são Google, Amazon, Facebook, IBM e Red Hat.

Talvez o melhor modelo histórico para o OCI seja a iniciativa Open Systems Interconnection que resultou no famoso modelo em camadas OSI de comunicação e integração de rede. O OCI define seu escopo de maneira similar e estreita e, mais recentemente, lançou uma proposta de especificação para formatos de imagem de contêiner. Se o consórcio for tão efetivo e bem-sucedido como o OSI foi então, dentro de alguns anos, teremos um quadro muito mais estável e comumente compreendido de conceitos e ferramentas para trabalhar.

2. Kubernetes

 

Ao trabalhar primeiro com contêineres de desenvolvimento individuais, seu modelo de implantação parece uma maravilha de simplicidade. À medida que o número de contêineres implantados cresce rapidamente, torna-se evidente que, como sempre, existem novas complexidades para lidar – desde a construção de imagens até o gerenciamento do ciclo de vida do recipiente, descoberta de serviços, redes e dados persistentes. O Google, um dos contribuidores originais para a LXC, provavelmente executa mais aplicativos contatados do que qualquer outra organização. A sua plataforma de orquestração Kubernetes de código aberto baseia-se em anos de experiência interna com a Omega e anteriormente com a Borg, que provavelmente ainda são o maior sistema de gerenciamento de contêineres do mundo.

A Kubernetes tornou-se rapidamente um candidato principal para um cluster padrão e plataforma de gerenciamento de contêineres. Uma das principais vantagens do sistema é que ele fornece um modelo de objeto consistente e uma API para muitos recursos subjacentes que variam entre provedores da nuvem e tem módulos que permitem que ele seja executado na maioria dos principais serviços, incluindo Amazon Web Services e, claro, Google Cloud.

3. CoreOS e rkt

 

Como Docker e muitos outros, a CoreOS é uma empresa que cresceu a partir de projetos de código aberto bem-sucedidos. Sua distribuição CoreOS Linux é um sistema operacional minimalista adaptado para a execução de contêineres de desenvolvimento. A sua loja de valores de chave distribuída etcd fornece a loja centralizada de cluster para os clusters Kubernetes. Eles também executam o quay.io, um pacote hospedado de repositórios de imagens e ferramentas de automação de compilação de contêineres.

 

Mais recentemente, a empresa vem fazendo novidades com o rkt, um formato de contêiner e uma alternativa de tempo de execução para o Docker, que incorpora uma filosofia arquitetônica bem diferente. Onde as funções do Docker foram historicamente atendidas por um daemon monolítico de tempo de execução, o rkt prefere seguir a filosofia do Unix de ferramentas de linha de comando simples e composáveis. Além disso, o rkt suporta múltiplos formatos de contêineres, incluindo o Docker, e níveis de “encaixe” de isolamento de contêiner de tempo de execução, o que é útil para certos tipos de aplicativos de sistema e servidor. CoreOS rkt ainda está em seus estágios iniciais de desenvolvimento, mas promete ser uma alternativa de interesse particular para os desenvolvedores de ferramentas de orquestração de contêineres que podem ser instáveis pela incursão de Docker em seu território com swarm e compose.

4. Apache Mesos and Mesosphere

 

O Mesos é um sistema de gerenciamento de cluster e um plano de controle para alocação eficiente de recursos de computação entre plataformas de entrega de aplicativos, chamados frameworks, que estão em camadas acima. Suas origens estavam em um projeto de pesquisa no UC Berkeley RAD Lab em torno de 2008, e em 2013, tornou-se um projeto de alto nível da Apache Software Foundation. Entre os frameworks construídos para serem executados no Mesos estão o Apache Aurora, uma estrutura distribuída para serviços de longa duração e o Chronos, um framework compartilhado com cron. No momento da sua adoção pelo Apache, Chris Fry, um consultor independente da empresa de tecnologia, descreveu a Mesos como a “pedra angular da nossa infraestrutura de computação elástica”.

 

A Mesosphere é um OEM de software empresarial que vende um “sistema operacional de data center” também construído no Mesos e fornece gerenciamento de cluster, orquestração de contêineres, descoberta de serviços e automação de compilação para computação elástica. As ofertas da Mesosphere estão em grande escala em Yelp, Verizon e Bloomberg, para citar alguns adotantes. Apache Mesos e Mesosphere formam o núcleo de uma alternativa de orquestração credível para o Kubernetes ou o Elastic Container Service da Amazon.

5. Canonical e LXD

 

A LXC não foi o fim da trilha para o desenvolvimento básico do Linux de contêineres e conceitos relacionados. Recentemente, a Canonical, o mantenedor da distribuição Ubuntu Linux, anunciou o LXD, um “hypervisor de contêiner” para o Linux. O LXD constrói os recursos do LXC, adicionando-lhe um daemon do sistema com uma API para gerenciamento de contêineres LXC e um plug-in OpenStack Nova para gerenciar hosts LXD virtuais na nuvem. É um hipervisor real? Não, mas pretende ter muitas das mesmas características para executar imagens de contêineres estáveis, seguras e imutáveis.

Como os contêineres de desenvolvimento, ele conta com cgroups, espaços de nome de kernel e um montável sistema de arquivos portável. Ao contrário da LXC, tem um forte foco na segurança e confiança da imagem e aproveita ao máximo os subsistemas de segurança subjacentes no Linux como seccomp e AppArmor.

O objetivo declarado da Canonical é que o LXD seja tão seguro e isolado como um hardware de máquina virtual, com bare-metal desempenho tempos de início semelhantes a contêineres. Pense nisso como um tempo de execução de contêiner ultra-fino e endurecido com capacidades de gerenciamento remoto. O que a LXD faz para sistemas como Docker ou Kubernetes continua a ser visto, mas, pelo menos, o LXD é um bom reflexo da nova prioridade no desenvolvimento do sistema operacional, que é fornecer um local seguro e de alto desempenho para que os recipientes funcionem.

O texto é uma livre tradução do original escrito por Mark Betz no TechTarget.

Leia Mais

 

 

 

Obrigado por enviar o seu comentário minha jóia!