Vou falar sobre a abordagem para organização de ambientes de desenvolvimento isolados localmente em minha estação de trabalho. A abordagem foi desenvolvida em resposta a diversos fatores:

são necessárias IDEs e toolchains diferentes para diferentes linguagens;
em diferentes projetos podem ser usadas versões distintas de toolchains e bibliotecas.

A abordagem consiste em desenvolver dentro de contêineres LXD executados localmente no laptop ou na estação de trabalho, com o redirecionamento da saída gráfica para o host.

Configuração com exemplo Ubuntu 20.04.

Reflexões sobre opções e razões estão no final do artigo.

1. Instalação do LXD

Em Ubuntu 20.04 O LXD não está mais disponível para instalação como pacote deb, apenas através do snap:

$ snap install lxd

Após a instalação, é necessário realizar a inicialização:

$ lxd init

O único parâmetro que eu altero é storage backend — eu uso dir como o mais simples. Como não utilizo snapshots e cópias, os avisos em documentação não me assustam:

Da mesma forma, o backend de diretório deve ser considerado como uma opção de último recurso.
Ele suporta todos os principais recursos do LXD, mas é terrivelmente lento e ineficiente, pois não pode realizar
cópias instantâneas ou snapshots e, portanto, precisa copiar toda a parte de armazenamento da instância a cada vez.

2. Configuração do perfil LXD

Perfis no LXD — são conjuntos de parâmetros aplicados a vários contêineres. Para minhas necessidades, é suficiente ter um único perfil criado por padrão padrão com as seguintes alterações:

$ lxc profile device add default X0 disk source=\/tmp\/.X11-unix\/X0 path=\/tmp\/.X11-unix\/X0 — para que os aplicativos nos contêineres possam interagir com o servidor X11 do host;
$ lxc profile set default environment.DISPLAY :0 — para que a variável de ambiente DISPLAY nos contêineres seja definida corretamente;
$ lxc profile set default raw.idmap "both 1000 1000" — para o mapeamento correto de identificadores 3. Criação e configuração do contêiner.

Criação de um contêiner baseado na imagem

images:ubuntu\/20.04 $ lxc launch images:ubuntu\/20.04 dev1:

Prefiro imagens do repositório

, pois têm menos software pré-instalado. Por essa razão, adicionei um prefixo https://images.linuxcontainers.orgao nome da imagem. Criar um contêiner baseado em uma imagem do repositório Ubuntu pode ser feito da seguinte maneira: images: $ lxc launch ubuntu\/20.04 dev1 Acesso ao shell root do contêiner:.

$ lxc exec dev1 -- bash

Vou instalar o Firefox e o VS Code (do repositório

segundo as instruções de acordo com as instruções):

$ apt update
$ apt install curl gpg firefox

$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
$ install -o root -g root -m 644 packages.microsoft.gpg /usr/share/keyrings/
$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list

$ apt update
$ apt install code

Vou ativar o contêiner para visualização

desligar

Bônus! É bastante simples passar a GPU para o contêiner para que os aplicativos executados nele possam utilizar a placa gráfica. Para isso, é necessário:

adicionar o dispositivo $ lxc config device add dev1 mygpu gpu;
instalar os drivers da placa gráfica no contêiner — os mesmos que estão instalados no host.

4. Usando o contêiner

Caso o contêiner ainda não esteja em execução, é necessário iniciá-lo:

lxc start dev1

Executando o VS Code como um usuário não privilegiado ubuntu:

lxc exec dev1 -- sudo --login --user ubuntu code

Executando o Firefox:

lxc exec dev1 -- sudo --login --user ubuntu firefox

As janelas dos aplicativos serão exibidas no host, mas serão executadas dentro do contêiner — semelhante ao redirecionamento gráfico via ssh.

Eu não desligo os contêineres em execução manualmente, pois não vejo sentido nisso — apenas fecho as janelas dos aplicativos em execução.

5. Conclusão

Prefiro não usar o sistema operacional host para desenvolvimento, pois isso exigiria a instalação de ferramentas de desenvolvimento, versões de depuração de bibliotecas, configuração de componentes do sistema de maneira específica e outras manipulações. Tudo isso pode levar a comportamentos inesperados de outros softwares não relacionados ao desenvolvimento, ou até mesmo do sistema operacional inteiro. Por exemplo, alterações na configuração do OpenSSL podem fazer com que o sistema operacional não inicie corretamente.

Eu testei diferentes ferramentas para isolar ambientes de desenvolvimento:

máquinas virtuais (KVM, VirtualBox, etc.) — a opção mais óbvia, mas consome significativamente mais recursos, embora para desenvolvimento em Windows (caso o host seja Linux) não haja outras alternativas;
ferramentas de desenvolvimento em nuvem executadas na máquina local (Cloud9 em contêiner ou máquina virtual, Eclipse Che, etc.) — elas não são desenvolvidas para esse modo de operação, exigem configuração e manutenção adicionais, sendo melhor usá-las como foram concebidas — na nuvem;
Os containers Docker são, mais uma vez, destinados a outros usos; na minha opinião, não são muito práticos para prototipar rapidamente usando softwares que ainda não estão empacotados em containers separados.

A abordagem escolhida me agrada pela simplicidade e pela baixa barreira de entrada. Dentro dos próprios containers, pode-se aplicar abordagens específicas para os projetos: instalar e configurar tudo manualmente ou usar automação (Puppet, Ansible, etc.), até mesmo implantar a infraestrutura baseada em Docker.Eu uso containers LXD também para rodar softwares específicos que ou exigem a instalação de um grande número de dependências ou uma versão diferente do sistema operacional — nesse caso, é possível criar um container com a versão desejada do sistema operacional, por exemplo, $ lxc launch images:ubuntu/16.04 dev16.

É importante lembrar que, em termos de isolamento, a contêinerização tem uma maior superfície de ataque em comparação com a virtualização — o host e o container compartilham um núcleo, e uma vulnerabilidade nesse núcleo pode permitir que malwares escapem do container. Para experimentos com softwares-questionáveis, é melhor usar mecanismos de isolamento mais adequados.

Links Úteis

Um artigo conciso no Habr Funcionalidades básicas do LXD - sistema de containers no Linux
O portal do projeto LXD, é importante não confundir LXD com LXC — são coisas diferentes, mas inter-relacionadas.
Blog Simos Xenitellis — este blog possui uma enorme quantidade de informações úteis sobre LXD.
Imagens prontas de máquinas virtuais Windows 10 para desenvolvedores — a Microsoft periodicamente compila novas builds e distribui com uma licença especial.

Fonte: habr.com