Je vais parler de l'approche pour organiser des environnements de développement locaux et isolés sur ma station de travail. Cette approche a été développée sous l'influence des facteurs suivants :

• Différentes langues nécessitent différents IDE et chaînes d'outils ;
• Différents projets peuvent utiliser différentes versions de chaînes d'outils et de bibliothèques.

L'approche consiste à développer à l'intérieur de conteneurs LXD lancés localement sur le portable ou la station de travail, avec redirection de la sortie graphique vers l'hôte.

Configuration à titre d'exemple Ubuntu 20.04.

Les réflexions sur les options et les raisons sont présentées à la fin de l'article.

1. Installation de LXD

Dans Ubuntu 20.04 LXD n'est plus disponible pour installation en tant que paquet deb, uniquement via snap :

$ snap install lxd

Après l'installation, il faut effectuer l'initialisation :

$ lxd init

Le seul paramètre que je change, c'est le backend de stockage — j'utilise dir comme étant le plus simple. Comme je n'utilise pas de snapshots ni de copies, les avertissements dans documentation ne me font pas peur :

De même, le backend de répertoire doit être considéré comme une option de dernier recours.
Il prend en charge toutes les fonctionnalités principales de LXD, mais est terriblement lent et inefficace car il ne peut pas effectuer
des copies instantanées ou des snapshots et doit donc copier l'intégralité du stockage de l'instance à chaque fois.

2. Configuration du profil LXD

Les profils dans LXD sont des ensembles de paramètres appliqués à plusieurs conteneurs. Pour mes besoins, il me suffit d'un seul profil par défaut créé default avec les modifications suivantes :

• $ lxc profile device add default X0 disk source=\/tmp\/X11-unix\/X0 path=\/tmp\/X11-unix\/X0 — pour que les applications dans les conteneurs puissent interagir avec le serveur X11 de l'hôte ;
• $ lxc profile set default environment.DISPLAY :0 — pour que la variable d'environnement DISPLAY dans les conteneurs soit correctement définie ;
• $ lxc profile set default raw.idmap "both 1000 1000" — pour un bon mappage des identifiants ;.

3. Création et configuration du conteneur

Création d'un conteneur basé sur l'image images:ubuntu\/20.04:

$ lxc launch images:ubuntu\/20.04 dev1

Je préfère les images du dépôt https://images.linuxcontainers.org, car elles contiennent moins de logiciels préinstallés. Pour cette raison, j'ai ajouté le préfixe images : au nom de l'image. La création d'un conteneur basé sur une image du dépôt Ubuntu peut être réalisée comme suit : $ lxc launch ubuntu\/20.04 dev1.

Accès au shell root du conteneur :

$ lxc exec dev1 -- bash

J'installerai Firefox et VS Code (du dépôt selon les instructions):

$ 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

Je vais activer le conteneur pour plus de clarté

poweroff

Bonus ! Il est assez simple de faire passer le GPU dans le conteneur afin que les applications qui y sont exécutées puissent utiliser la carte graphique. Pour cela, il faut :

• ajouter le périphérique $ lxc config device add dev1 mygpu gpu;
• installer dans le conteneur les pilotes de la carte graphique — les mêmes que ceux installés sur l'hôte.

4. Utilisation du conteneur

Dans le cas où le conteneur n'est pas encore démarré, il faut le démarrer :

lxc start dev1

Lancer VS Code en tant qu'utilisateur non privilégié ubuntu:

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

Lancer Firefox :

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

Les fenêtres des applications s'afficheront sur l'hôte, mais elles s'exécuteront à l'intérieur du conteneur — semblable au passage de l'affichage via ssh.

Je ne stoppe pas les conteneurs en cours d'exécution manuellement, car je ne vois pas l'intérêt — je me limite à fermer les fenêtres des applications en cours.

5. Conclusion

Je préfère ne pas utiliser le système d'exploitation hôte pour le développement, car cela nécessiterait l'installation des outils de développement, des versions de debugging des bibliothèques, la configuration des composants système de manière spécifique et d'autres manipulations. Cela peut conduire à un comportement inattendu d'autres logiciels non liés au développement, voire de tout le système d'exploitation. Par exemple, des modifications dans la configuration d'OpenSSL peuvent entraîner un échec de démarrage correct du système d'exploitation.

J'ai essayé différents outils pour isoler les environnements de développement :

• machines virtuelles (KVM, VirtualBox, etc.) — l'option la plus évidente, mais qui consomme beaucoup plus de ressources, même si pour le développement sous Windows (si l'hôte est Linux), il n'y a pas d'autres options ;
• outils de développement en cloud exécutés sur la machine locale (Cloud9 dans un conteneur ou machine virtuelle, Eclipse Che, etc.) — ils ne sont pas conçus pour ce mode de fonctionnement, nécessitent une configuration et un suivi supplémentaires, il vaut mieux les utiliser à leurs fins — dans le cloud ;
• Les conteneurs Docker sont encore une fois destinés à autre chose ; à mon avis, ils ne sont pas très pratiques pour prototyper rapidement avec des logiciels qui ne sont pas encore emballés dans des conteneurs séparés.

L'approche choisie me convient par sa simplicité et son faible seuil d'entrée. Dans les conteneurs eux-mêmes, il est possible d'appliquer des approches spécifiques aux projets : installer et configurer manuellement tout, ou bien utiliser l'automatisation (Puppet, Ansible, etc.), voire déployer une infrastructure basée sur Docker.J'utilise également des conteneurs LXD pour exécuter des logiciels spécifiques qui nécessitent soit l'installation d'un grand nombre de dépendances, soit une autre version du système d'exploitation ; dans ce cas, on peut créer un conteneur avec la version souhaitée du système d'exploitation, par exemple $ lxc launch images:ubuntu/16.04 dev16.

Il est important de garder à l'esprit qu'en termes d'isolation, la conteneurisation a une plus grande surface d'attaque par rapport à la virtualisation : l'hôte et le conteneur partagent un même noyau, une vulnérabilité dans lequel pourrait permettre à des logiciels malveillants de s'échapper du conteneur. Pour expérimenter avec des logiciels douteux, il est préférable d'utiliser des mécanismes d'isolation plus adaptés.

Liens utiles

• Un article complet sur Habré Fonctionnalités de base de LXD — systèmes de conteneurs sous Linux
• Le portail du projet LXD, il ne faut pas confondre LXD avec LXC : ce sont des choses différentes mais interconnectées.
• Le blog de Simos Xenitellis — ce blog regorge d'informations pratiques utiles sur LXD.
• Des images prêtes de machines virtuelles Windows 10 pour les développeurs — Microsoft compile régulièrement de nouvelles versions et les distribue avec une licence spéciale.

Source : habr.com