LXD vs Docker

Nem tudo o que é novo é bom e nem tudo revolucionário é necessário. Com as tecnologias de contêineres, como em todas as outras "próximas grandes", estamos vendo uma invenção desenfreada de abstrações de nível superior, seguidas pela implantação na produção, com a infraestrutura inteira de CD/CI dependente dele e DevOps sem entender o que realmente faz.

Vamos começar com o que realmente eram os contêineres, historicamente. No início dos anos 2000, o FreeBSD introduziu o conceito de "prisões", que ofereceu um novo ambiente, como uma nova instalação do sistema operacional que oferece toda a biblioteca FreeBSD e infraestrutura do kernel que já está em vigor. Uma lousa limpa para os desenvolvedores testarem um novo software.

Isso contrasta fortemente com VMware, KVM ou VirtualBox, como tecnologias, onde o hardware inteiro é virtualizado, onde, o seu sistema operacional host provisões um conjunto virtual de CPU, RAM e outros recursos. Seu sistema operacional convidado fica no topo desses recursos de hardware virtual. Quase todas as camadas de abstração são repetidas duas vezes e recursos como RAM e CPU, uma vez alocados ao hóspede, não estão mais disponíveis para o host (independentemente de o hóspede ou não os usar ou não).

Docker e Linux-Y recipientes

Com o sistema operacional sendo virtualizado, os contêineres podem ser divididos com cotas definidas para a utilização de recursos. Por exemplo, se configurarmos um limite máximo de 2 GB de uso de RAM para contêiner, não será capaz de excedê -lo. Por outro lado, como existe apenas um kernel no loop, se o contêiner não estiver usando toda.

A primeira desvantagem que as pessoas perceberam com o modelo de contêiner é que, como estamos virtualizando o sistema operacional e não o hardware, você pode ter várias instâncias do mesmo sistema operacional e perder a capacidade de girar um sistema operacional arbitrário.

Não existe contêiner Windows em contêineres Linux ou Linux no Windows. Docker no Windows, por exemplo, usa o Moby Linux, que está realmente sendo executado em uma VM dentro da sua caixa do Windows.

Quando se trata de uma distribuição Linux, no entanto, você pode fazer muitas coisas interessantes. Como o que chamamos de Linux é apenas o kernel e precisa de uma pilha de bibliotecas GNU para fornecer um ambiente completo do sistema operacional, você pode imitar várias distribuições, como Centos, Ubuntu, alpina em diferentes instâncias de contêiner.

Isso é verdade para LXD e Docker.

Docker como mecanismo de embalagem

Docker fará com o APT, o que o APT fez ao alcatrão. Isto é, você ainda estará usando APT, mas com uma camada adicional de abstração em cima. Para entender como, considere o seguinte exemplo.

Você tem uma instância do seu site em execução em um php5.6 e você precisa executar outro serviço da web no mesmo servidor usando Php7.0. Agora, executando duas versões diferentes do próprio PHP é uma idéia assustadora, sem saber quais conflitos surgiriam delas. Atualizar e atualizar em breve se tornará um empreendimento sem esperança.

Mas e se tivéssemos nossa instância original da web executando dentro de um contêiner do Docker? Agora, tudo o que precisamos é de um novo contêiner do Docker dentro do qual podemos instalar o PHP7.0 e nosso segundo serviço da web funcionará a partir deste recipiente recém -fiado. Ainda estaremos usando o APT em segundo plano, assim como o APT usa alcatrão em segundo plano, mas o Docker garantiria que várias aplicações de diferentes contêineres não se confundem entre si.

Docker é especialmente útil para executar aplicativos sem estado e você ouvirá pessoas dizendo frequentemente que não pode correr mais de um processo em um contêiner. Embora isso seja falso, executar vários serviços com estado em um contêiner pode frequentemente fazer com que o Docker forneça resultados inconsistentes. Você em breve você se encontrará reiniciando o mesmo conjunto de contêineres repetidamente.

LXD como hipervisor

Com os contêineres LXD, o que você recebe é muito mais próximo de um sistema operacional independente do que o que você recebe do Docker. Todos os contêineres do Docker compartilham a mesma pilha de rede e pilha de armazenamento.

Isso significa comandos básicos como ping ou ifconfig estão indisponíveis de dentro de um recipiente do Docker. Na verdade, você não pode saber quase nada sobre a rede em que está, de dentro daquele contêiner. Docker Nat em execução na pilha de rede do host oferece a maioria da conectividade e instalações como o encaminhamento de porta.

Os contêineres LXD estão muito à frente da curva, suportando pontes de rede, Macvlan e várias outras opções. Seus contêineres LXD e seu host formam uma rede privada própria e podem se comunicar como se estivessem conversando com diferentes computadores em uma rede.

O mesmo acontece com a pilha de armazenamento. Muitas vezes, é muito mais prático usar o LXD com os pools do ZFS, onde você pode alocar conjuntos de dados com cotas limitando a utilização de armazenamento. O LXD está em concorrência direta com a VMware, KVM e outras tecnologias de hipervisor.

Usando -o, seu provedor de nuvem agora pode provisionar seu recipiente pessoal que cheiraria e pareça um sistema operacional completo e ainda é barato e rápido para girar e matar, juntamente com todas as sutilezas de dados persistentes que você espera.

Da perspectiva do provedor, as coisas também são econômicas. Como nem todo mundo usa todo o RAM que eles pedem, você pode incluir muito mais recipientes no mesmo metal do que você pode.

Para os usuários finais, pode parecer trapaça no começo, mas eles também vencem no final, os contêineres LX são mais rápidos para girar e matar, tornando o processo muito mais suave e "escalável" (como as pessoas gostam de dizer).

Você pode girar recipientes em um nó de computação onde seus dados residem, fazer o cálculo que deseja fazer e depois destruir o contêiner deixando os dados intactos. Isso é muito mais rápido do que buscar dados relevantes até a sua máquina virtual, que está em execução em algum outro data center. Isso funciona especialmente bem com o ZFS no loop.

Tl; Dr

Para resumir tudo o que sabemos, tanto o LXD quanto o Docker são tecnologias de contêinerização. Docker é leve, simplista e é adequado para isolar aplicativos um do outro, tornando-o popular entre DevOps e desenvolvedores. Um aplicativo por contêiner do Docker.

O LXD, por outro lado, está muito melhor equipado e está muito mais próximo de um ambiente completo do sistema operacional com interfaces de rede e armazenamento. Você pode executar vários recipientes do Docker aninhados dentro do LXD, se quiser.