Voy a explicar el enfoque para organizar entornos de desarrollo locales e aislados en mi estación de trabajo. Este enfoque se ha desarrollado bajo la influencia de los siguientes factores:

se necesitan diferentes IDE y herramientas para diferentes lenguajes;
en diferentes proyectos pueden utilizarse diferentes versiones de herramientas y bibliotecas.

El enfoque consiste en desarrollar dentro de contenedores LXD que se ejecutan localmente en el portátil o estación de trabajo, con redirección de salida gráfica al host.

Configuración en el ejemplo Ubuntu 20.04.

Las reflexiones sobre las opciones y razones se presentan al final del artículo.

1. Instalación de LXD

En Ubuntu 20.04 LXD ya no está disponible para instalar como paquete deb, solo a través de snap:

$ snap install lxd

Después de la instalación, se debe ejecutar la inicialización:

$ lxd init

El único parámetro que cambio es storage backend — utilizo dir como el más simple. Dado que no utilizo instantáneas y copias, las advertencias en la documentación no me asustan:

De manera similar, el backend de directorio debe considerarse como una opción de última instancia.
Admite todas las funciones principales de LXD, pero es terriblemente lento e ineficiente, ya que no puede realizar
copias instantáneas o snapshots, por lo que necesita copiar la totalidad del almacenamiento de la instancia cada vez.

2. Configuración del perfil de LXD

Los perfiles en LXD son conjuntos de parámetros aplicados a varios contenedores. Para mis necesidades, me basta con un solo perfil creado por defecto default con los siguientes cambios:

$ lxc profile device add default X0 disk source=\/tmp\/ .X11-unix\/X0 path=\/tmp\/ .X11-unix\/X0 — para que las aplicaciones en los contenedores puedan interactuar con el servidor X11 del host;
$ lxc profile set default environment.DISPLAY :0 — para que la variable de entorno DISPLAY en los contenedores se establezca correctamente;
$ lxc profile set default raw.idmap "both 1000 1000" — para un mapeo correcto de identificadores. 3. Creación y configuración del contenedor.

Creación de un contenedor basado en la imagen

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

Prefiero las imágenes del repositorio

, ya que tienen menos software preinstalado. Por esta razón, añadí un prefijo https://images.linuxcontainers.orgal nombre de la imagen. La creación de un contenedor basado en una imagen del repositorio de Ubuntu se puede hacer de la siguiente manera: images: $ lxc launch ubuntu\/20.04 dev1 Acceso a la shell root del contenedor:.

$ lxc exec dev1 -- bash

Instalaré Firefox y VS Code (desde el repositorio

según las instrucciones по инструкции):

$ 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

Voy a encender el contenedor para mayor claridad

apagar

¡Bono! Es bastante fácil pasar la GPU al contenedor para que las aplicaciones que se ejecutan en él puedan usar la tarjeta gráfica. Para ello, es necesario:

agregar el dispositivo $ lxc config device add dev1 mygpu gpu;
instalar en el contenedor los controladores de la tarjeta gráfica — los mismos que están instalados en el host.

4. Uso del contenedor

En caso de que el contenedor aún no esté en funcionamiento, debes encenderlo:

lxc start dev1

Ejecutar VS Code como un usuario no privilegiado ubuntu:

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

Ejecutar Firefox:

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

Las ventanas de las aplicaciones se mostrarán en el host, pero se ejecutarán dentro del contenedor, similar al redireccionamiento gráfico a través de ssh.

No apago los contenedores en funcionamiento manualmente, ya que no veo el sentido en ello — me limito a cerrar las ventanas de las aplicaciones en ejecución.

5. Conclusión

Prefiero no usar el sistema operativo del host para el desarrollo, ya que eso requeriría la instalación de herramientas de desarrollo, versiones de bibliotecas en modo debug, configuración de componentes del sistema de manera específica y otras manipulaciones. Todo esto puede llevar a comportamientos inesperados de otros softwares no relacionados con el desarrollo, o incluso del sistema operativo completo. Por ejemplo, los cambios en la configuración de OpenSSL pueden hacer que el sistema operativo deje de arrancar correctamente.

He probado diferentes herramientas para aislar los entornos de desarrollo:

máquinas virtuales (KVM, VirtualBox, etc.) — la opción más obvia, pero consume significativamente más recursos; aunque para el desarrollo en Windows (si el host es Linux) no hay otras opciones;
herramientas de desarrollo en la nube ejecutadas en la máquina local (Cloud9 en un contenedor o máquina virtual, Eclipse Che, etc.) — no están diseñadas para ese modo de funcionamiento, requieren una configuración adicional y mantenimiento, es mejor utilizarlas para su propósito: en la nube;
Los contenedores Docker, en mi opinión, están diseñados para otro propósito y no son muy convenientes para prototipar rápidamente con software que aún no está empaquetado en contenedores individuales.

La aproximación elegida me atrae por su simplicidad y bajo umbral de entrada. Dentro de los propios contenedores, se pueden aplicar enfoques específicos de proyectos: instalar y configurar todo manualmente o utilizar automatización (Puppet, Ansible, etc.), incluso desplegar infraestructura basada en Docker.También utilizo contenedores LXD para ejecutar software específico que requiere la instalación de numerosas dependencias o una versión diferente del sistema operativo; en este caso, se puede crear un contenedor con la versión necesaria del sistema operativo, por ejemplo, $ lxc launch images:ubuntu/16.04 dev16.

Es importante recordar que, en términos de aislamiento, la contenedorización tiene una superficie de ataque mayor en comparación con la virtualización: el host y el contenedor comparten un núcleo, y una vulnerabilidad en él puede permitir que software malicioso escape del contenedor. Para experimentos con software cuestionable, es mejor utilizar mecanismos de aislamiento más adecuados.

Enlaces útiles

Un artículo completo en Habr. Las capacidades básicas de LXD: el sistema de contenedores en Linux
Portal del proyecto LXD, es importante no confundir LXD con LXC: son cosas diferentes pero interrelacionadas.
Blog de Simos Xenitellis — en este blog hay una gran cantidad de información práctica útil sobre LXD.
Imágenes listas de máquinas virtuales Windows 10 para desarrolladores — Microsoft recopila periódicamente nuevas compilaciones y las distribuye con una licencia especial.

Fuente: habr.com