Ik zal het hebben over de aanpak voor het organiseren van lokale geïsoleerde ontwikkelomgevingen op mijn werkstation. Deze aanpak is ontwikkeld onder invloed van de volgende factoren:

voor verschillende talen zijn verschillende IDE's en toolchains nodig;
in verschillende projecten kunnen verschillende versies van toolchains en bibliotheken worden gebruikt.

De aanpak bestaat eruit om ontwikkeling te doen binnen LXD-containers die lokaal op de laptop of het werkstation worden uitgevoerd met doorsturing van grafische uitvoer naar de host.

Configuratie aan de hand van een voorbeeld Ubuntu 20.04.

Overpeinzingen over opties en redenen worden aan het einde van het artikel besproken.

1. Installatie van LXD

In Ubuntu 20.04 LXD is niet langer beschikbaar voor installatie als deb-pakket, alleen via snap:

$ snap install lxd

Na installatie moet je initialisatie uitvoeren:

$ lxd init

De enige parameter die ik wijzig, is storage backend — ik gebruik dir als de eenvoudigste. Aangezien ik geen snapshots en kopieën gebruik, ben ik niet bang voor de waarschuwingen in de documentatie mij:

Evenzo moet de directory backend als een laatste redmiddel worden beschouwd.
Het ondersteunt alle belangrijke LXD-functies, maar is vreselijk traag en inefficiënt omdat het geen
directe kopieën of snapshots kan maken en daarom bij elke keer de volledige opslag van de instantie moet kopiëren.

2. Configuratie van het LXD-profiel

Profielen in LXD zijn sets van parameters die op verschillende containers worden toegepast. Voor mijn behoeften is één enkele standaardprofiel default met de volgende wijzigingen voldoende:

$ lxc profile device add default X0 disk source=\/tmp\/.X11-unix\/X0 path=\/tmp\/.X11-unix\/X0 — zodat applicaties in de containers kunnen communiceren met de host X11-server;
$ lxc profile set default environment.DISPLAY :0 — zodat de omgevingsvariabele DISPLAY in de containers correct is ingesteld;
$ lxc profile set default raw.idmap "both 1000 1000" — voor de juiste mapping van identificaties.

3. Het creëren en configureren van een container

Het creëren van een container op basis van het image images:ubuntu\/20.04:

$ lxc launch images:ubuntu\/20.04 dev1

Ik geef de voorkeur aan images uit de repository https://images.linuxcontainers.org, omdat ze minder vooraf geïnstalleerde software bevatten. Om deze reden heb ik een prefix toegevoegd beelden: aan de naam van het image. Het creëren van een container op basis van een image uit de Ubuntu-repository kan als volgt worden uitgevoerd: $ lxc launch ubuntu\/20.04 dev1.

Toegang tot de root-shell van de container:

$ lxc exec dev1 -- bash

Ik installeer Firefox en VS Code (uit de repository volgens instructies):

$ 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

Ik zal de container inschakelen voor duidelijkheid

poweroff

Bonus! Het is vrij eenvoudig om een GPU door te geven aan de container, zodat de applicaties die erin worden uitgevoerd gebruik kunnen maken van de grafische kaart. Hiervoor moet je:

een apparaat toevoegen $ lxc config device add dev1 mygpu gpu;
de videokaartdrivers installeren in de container — dezelfde als die op de host zijn geïnstalleerd.

4. Gebruik van de container

Als de container nog niet draait, moet je deze starten:

lxc start dev1

VS Code uitvoeren als een niet-bevoorrechte gebruiker ubuntu:

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

Firefox uitvoeren:

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

De vensters van de applicaties worden op de host weergegeven, maar ze worden uitgevoerd binnen de container — vergelijkbaar met grafische doorvoer via ssh.

Ik schakel niet handmatig draaiende containers uit, omdat ik er geen zin in zie — ik beperk me tot het sluiten van vensters van draaiende applicaties.

5. Conclusie

Ik geef de voorkeur aan het niet gebruiken van het host-OS voor ontwikkeling, omdat dit zou vereisen dat ontwikkeltools, debugversies van bibliotheken, systeemcomponenten op een specifieke manier worden ingesteld en andere handelingen moeten worden verricht. Dit kan leiden tot onverwacht gedrag van andere software die niets met ontwikkeling te maken heeft, en zelfs van het hele OS. Bijvoorbeeld, wijzigingen in de OpenSSL-configuratie kunnen ertoe leiden dat het OS niet correct opstart.

Ik heb verschillende middelen geprobeerd voor het isoleren van ontwikkelingsomgevingen:

virtuele machines (KVM, VirtualBox, enz.) — de meest voor de hand liggende optie, maar verbruikt aanzienlijk meer middelen, hoewel er voor ontwikkeling onder Windows (wanneer de host Linux is) geen andere opties zijn;
cloud ontwikkeltools die op de lokale machine draaien (Cloud9 in een container of virtuele machine, Eclipse Che, enz.) — deze zijn niet ontwikkeld voor deze werkwijze, ze hebben extra configuratie en onderhoud nodig, je kunt ze het beste gebruiken voor hun oorspronkelijke doel — in de cloud;
Docker-containers zijn eigenlijk voor iets anders bedoeld; naar mijn mening is het niet erg handig om snel prototypes te maken met software die nog niet in afzonderlijke containers is verpakt.

De gekozen benadering spreekt me aan vanwege de eenvoud en de lage drempel. Binnen de containers kun je project-specifieke methoden toepassen: alles handmatig installeren en configureren, of automatisering gebruiken (zoals Puppet, Ansible, enz.), en zelfs implementeren. infrastructuur op basis van Docker.Ik gebruik LXD-containers ook voor het draaien van specifieke software die een groot aantal afhankelijkheden vereist, of een andere versie van het besturingssysteem — in dat geval kun je een container aanmaken met de benodigde versie van het besturingssysteem, bijvoorbeeld $ lxc launch images:ubuntu/16.04 dev16..

Het is belangrijk om te onthouden dat containerisatie in termen van isolatie een grotere aanvalsvector heeft in vergelijking met virtualisatie — de host en container delen dezelfde kernel, en een kwetsbaarheid daarin kan kwaadaardige software de kans geven om uit de container te ontsnappen. Voor experimenten met twijfelachtige software zijn er betere isolatiemechanismen.

Nuttige links

Een uitgebreide artikel op Habré. Basisfunctionaliteiten van LXD - container systemen in Linux
Portal van het LXD-project,het is belangrijk om LXD niet met LXC te verwarren — dit zijn verschillende, maar met elkaar verbonden dingen.
Blog van Simos Xenitellis, in deze blog staan veel nuttige praktische informatie over LXD.
Kant-en-klare Windows 10 virtuele machine images voor ontwikkelaars, Microsoft verzamelt regelmatig nieuwe builds en distribueert deze met een speciale licentie.

Bron: habr.com