Pular para o conteúdo

LXD Linux Container como alternativa ao Docker

Postado em por Gustavo Henrique 5 minutos de leitura

História

A história do uso de containers começa com o conceito de virtualização, que acredita-se que surgiu em meados dos anos 1960. Virtualização é a capacidade de rodar um sistema dentro de outro. Essa tecnologia ganhou popularidade em 1999 quando uma empresa chamada VMWare criou o primeiro software de virtualização compatível com processadores Intel de 32 bits, que eram os mais utilizados nos computadores pessoais da época.

A virtualização se tornou uma necessidade corporativa após o crescimento inicial da internet. Muitas máquinas ficavam ociosas a maior parte do tempo e custo de manter um datacenter era alto. Expandir a capacidade dos servidores se tornou mais rápido e barato com a virtualização.

Sem falar nos problemas relacionados à segurança. A jovem internet era um ambiente muito inseguro e isso inspirou a busca por uma nova solução chamada de container. A proposta dos containers é isolar processos e limitar o consumo de recursos como CPU e Memória. Isso é, rodar aplicações diferentes na mesma máquina sem que elas interfiram uma na outra.

A primeira solução robusta de container foi o Jails, lançado no FreeBSD, em 2001. Foi a partir daí que esse termo ganhou mais atenção. Porém, só em 2008, que o Linux passou a incluir essa tecnologia por padrão no Kernel, que ficou conhecida como LXC (Linux Container).

Em 2013 foi criado o Docker como uma camada sobre o LXC. Docker se popularizou por simplificar a utilização de containers LXC ao oferecer uma API Rest para desenvolvedores. O foco do Docker é a arquitetura de micro-serviços. Por isso um container Docker executa apenas um processo por padrão (é possível contornar isso utilizando scripts).

Inspirado pelo Docker, a Canonical, empresa responsável pelo Ubuntu Linux, lançou sua própria solução de container, também como uma camada sobre o LXC. Essa solução foi chamada de LXD.

Docker vs. LXD

Tanto Docker como LXD possuem uma API Rest para desenvolvedores. A maior diferença entre eles é que o Docker é focado em rodar um processo por container e o LXD em rodar um Linux completo como um container. Um container LXD permite que você rode vários processos. Exemplo: servidor web, banco de dados e servidor SSH. É parecido com a virtualização mas extremamente rápido como um container.

As gigantes da tecnologia se uniram em 2015 para criar o consórcio Open Containers, uma iniciativa para padronizar e direcionar o futuro dessa tecnologia. A empresa Docker Inc. contribuiu liberando partes do código do projeto Docker como open source. Essa ação facilitou a utilização do Docker em outros sistemas operacionais. O que não é o caso do LXD que roda apenas no Linux.

Assim como o Docker, LXD trabalha com o esquema de imagens. Porém, as imagens oficiais do LXD são de distros Linux, enquanto o Docker possui imagens de aplicativos. Ou seja, as imagens LXD são Ubuntu, CentOS, Arch Linux, etc. Enquanto as imagens Docker são NodeJS, Go, Nginx, Vim, etc.

Docker e LXD não são exatamente competidores. Ambos podem trabalhar juntos. É possível rodar containers Docker dentro de um container LXD, por exemplo.

Meus casos de uso mais comuns

Tanto Docker como LXD são ferramentas indispensáveis no meu cotidiano como desenvolvedor de software. Eu utilizo Docker para serviços simples, por exemplo, um banco de dados Postgres, e LXD quando eu preciso de algo mais avançado, como por exemplo, um Nginx atuando como proxy reverso. Um dos meus recursos preferidos no LXD é a possibilidade de adicionar e remover volumes sem precisar reiniciar o container.

Pair programming é uma prática comum nos projetos que eu trabalho. A maneira mais eficiente para mim é o acesso remoto via SSH + Tmux + Vim. Eu crio um container LXD e adiciono um volume contendo os fontes do projeto e outro volume contendo as configurações do editor. Então, permito que minha dupla acesse remotamente meu container, e esse ambiente isolado mantém meu sistema principal inacessível ao visitante. Nós dois programamos com o editor aberto e nos comunicamos através de outra ferramenta.

Também faz parte da minha rotina ter que gerenciar infra-estrutura de servidores. Há vários ajustes de performance que precisam ser feitos no kernel do Linux para conseguir desempenho melhor para cada aplicação. Sem contar as tarefas relacionadas a segurança como configuração de firewall, por exemplo. LXD permite que eu consiga testar tudo que precisa ser feito antes de aplicar nos servidores.

Exemplos

LXD é um daemon que fornece uma API Rest para manipulação de containers. A instalação traz um client de linha de comando chamado lxc para interagir com esse daemon. Existem versões do CLI lxc para MacOS e Windows também.

Há três repositórios oficiais:

  • images: contém diversas distros
  • ubuntu: imagens com a versão estável do Ubuntu
  • ubuntu-daily: imagens Ubuntu com pacotes atualizados diariamente

Você pode consultar a lista de imagens disponíveis pelo browser:

Verifique na documentação do LXD como proceder com a instalação. Mas se você usa Ubuntu, pode instalar via Snap:

sudo snap install lxd && lxd init

Para criar um container e entrar dentro dele como usuário root:

# lxc launch ubuntu-daily:20.04 mycontainer
lxc launch images:centos/8/amd64 mycontainer
lxc exec mycontainer bash

Você pode transferir arquivos sem precisar montar volumes, passando o nome do container antes do caminho do arquivo:

lxc file pull mycontainer/etc/passwd .
lxc file push ./index.html mycontainer/tmp/

Eu criei um snippet com os comandos mais utilizados em https://gist.github.com/gustavohenrique/4a7e99696bc85030d88803dc58e86c00.
Outros exemplos podem ser encontrados na documentação oficial do LXD.

Conclusão

Nem só de Docker vive o mundo dos containers. É importante conhecer como funciona outras ferramentas, sua história e seu propósito, e entender quando deve utilizá-las.

LXD trouxe muitos benefícios para o meu fluxo de trabalho. Essa ferramenta é um dos motivos que me fizeram voltar, em 2017, à utilizar Linux como meu sistema operacional principal, depois de cinco anos utilizando MacOS.

Alguns servidores de produção sob minha responsabilidade já estão utilizando LXD também, sem qualquer problema.