Ich werde den Ansatz zur Organisation lokaler, isolierter Entwicklungsumgebungen auf meiner Arbeitsstation erläutern. Diese Methode wurde unter dem Einfluss folgender Faktoren entwickelt:

Für verschiedene Sprachen sind unterschiedliche IDEs und Toolchains erforderlich;
In verschiedenen Projekten können unterschiedliche Versionen von Toolchains und Bibliotheken verwendet werden.

Der Ansatz besteht darin, die Entwicklung innerhalb von lokal auf dem Laptop oder der Arbeitsstation laufenden LXD-Containern durchzuführen, wobei die grafische Ausgabe an den Host umgeleitet wird.

Konfiguration am Beispiel Ubuntu 20.04.

Überlegungen zu den Optionen und Gründen sind am Ende des Artikels aufgeführt.

1. Installation von LXD

In Ubuntu 20.04 LXD ist nicht mehr als deb-Paket verfügbar, sondern nur über snap:

$ snap install lxd

Nach der Installation muss die Initialisierung durchgeführt werden:

$ lxd init

Der einzige Parameter, den ich ändere, ist storage backend — ich verwende dir als die einfachste Option. Da ich keine Snapshots und Kopien verwende, schrecken mich die Warnungen in Dokumentation. nicht ab:

Das Verzeichnis-Backend sollte ebenfalls als letzte Option betrachtet werden.
Es unterstützt alle wichtigen LXD-Funktionen, ist jedoch sehr langsam und ineffizient, da es keine
sofortigen Kopien oder Snapshots erstellen kann und daher jedes Mal den gesamten Speicher der Instanz kopieren muss.

2. Einrichtung des LXD-Profils

Profile in LXD — das sind Parametersätze, die auf mehrere Container angewendet werden. Für meine Bedürfnisse reicht mir das standardmäßig erstellte Profil aus. default mit den folgenden Änderungen:

$ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0 — damit Anwendungen in den Containern mit dem Host-X11-Server interagieren können;
$ lxc profile set default environment.DISPLAY :0 — damit die Umgebungsvariable DISPLAY in den Containern korrekt gesetzt wird;
$ lxc profile set default raw.idmap "both 1000 1000" — für die richtige ID-Mapper..

3. Erstellung und Konfiguration des Containers.

Container aus einem Image erstellen: images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Ich bevorzuge Images aus dem Repository, https://images.linuxcontainers.orgda sie weniger vorinstallierte Software enthalten. Aus diesem Grund habe ich ein Präfix images: zum Namen des Images hinzugefügt. Die Erstellung eines Containers aus einem Image des Ubuntu-Repositories kann wie folgt durchgeführt werden: $ lxc launch ubuntu/20.04 dev1.

Zugriff auf die Root-Shell des Containers:

$ lxc exec dev1 -- bash

Ich werde Firefox und VS Code (aus dem Repository entsprechend der Anleitung) installieren.):

$ 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

Ich werde den Container zur Anschauung aktivieren

Herunterfahren

Bonus! Es ist recht einfach, die GPU in den Container weiterzuleiten, damit die darin ausgeführten Anwendungen die Grafikkarte nutzen können. Dazu muss man:

ein Gerät hinzufügen $ lxc config device add dev1 mygpu gpu;
die Treiber der Grafikkarte im Container installieren — dieselben, die auf dem Host installiert sind.

4. Verwendung des Containers

Falls der Container noch nicht läuft, muss er gestartet werden:

lxc start dev1

VS Code unter einem unprivilegierten Benutzer ausführen ubuntu:

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

Firefox starten:

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

Die Anwendungsfenster werden auf dem Host angezeigt, aber sie werden im Container ausgeführt — ähnlich wie bei der Grafikweiterleitung über ssh.

Ich schalte laufende Container nicht manuell aus, da ich darin keinen besonderen Sinn sehe — ich beschränke mich auf das Schließen der Fenster der laufenden Anwendungen.

5. Fazit

Ich ziehe es vor, kein Host-Betriebssystem für die Entwicklung zu verwenden, da dies die Installation von Entwicklungswerkzeugen, Debug-Versionen von Bibliotheken, spezielle Konfigurationen von Systemkomponenten und andere Manipulationen erfordern würde. All das kann zu unerwartetem Verhalten anderer, nicht entwicklungsbezogener Software oder sogar des gesamten Betriebssystems führen. Veränderungen in der OpenSSL-Konfiguration können beispielsweise dazu führen, dass das Betriebssystem nicht mehr korrekt bootet.

Ich habe verschiedene Mittel zur Isolation von Entwicklungsumgebungen ausprobiert:

Virtuelle Maschinen (KVM, VirtualBox usw.) — die offensichtlichste Option, aber sie verbrauchen deutlich mehr Ressourcen. Bei der Entwicklung unter Windows (wenn der Host Linux ist) gibt es jedoch keine Alternativen;
Entwicklungstools, die lokal auf dem Rechner ausgeführt werden (Cloud9 in einem Container oder einer virtuellen Maschine, Eclipse Che usw.) — sie sind nicht für diesen Betriebsmodus entwickelt worden, sie erfordern zusätzliche Konfiguration und Wartung. Am besten verwendet man sie daher wie vorgesehen — in der Cloud.
Docker-Container sind meines Erachtens nicht ideal, um schnell Prototypen mit Software zu erstellen, die noch nicht in separate Container verpackt ist.

Der gewählte Ansatz gefällt mir aufgrund seiner Einfachheit und des niedrigen Einstiegsniveaus. In den Containern können Projekt-spezifische Methoden verwendet werden: alles manuell installieren und konfigurieren oder Automatisierung (Puppet, Ansible usw.) anwenden, sogar Infrastruktur auf Docker-Basis bereitstellen. Ich nutze LXD-Container auch zum Starten spezifischer Software, die entweder viele Abhängigkeiten benötigt oder eine andere OS-Version erfordert — in diesem Fall kann man einen Container mit der benötigten OS-Version erstellen, zum Beispiel$ lxc launch images:ubuntu/16.04 dev16 Es ist wichtig zu beachten, dass die Containerisierung im Hinblick auf Isolation eine größere Angriffsfläche im Vergleich zur Virtualisierung bietet — Host und Container teilen sich einen Kernel, dessen Schwachstelle es schadhafter Software ermöglichen kann, aus dem Container zu entkommen. Für Experimente mit fragwürdiger Software sind besser geeignete Isolationsmechanismen zu verwenden..

Ein umfassender Artikel auf Хабре

Nützliche Links

Ein umfassender Artikel auf Habré Die Grundfunktionen von LXD — dem Container-System in Linux
Portal für das LXD-Projekt, es ist wichtig, LXD nicht mit LXC zu verwechseln – es sind verschiedene, aber miteinander verbundene Konzepte.
Blog von Simos Xenitellis — in diesem Blog gibt es eine Menge nützlicher praktischer Informationen zu LXD.
Fertige Windows 10-VM-Images für Entwickler — Microsoft bündelt regelmäßig neue Builds und verteilt sie mit einer speziellen Lizenz.

Quelle: habr.com