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

• Verschillende talen vereisen verschillende IDE’s en toolchains;
• Verschillende projecten kunnen verschillende versies van toolchains en bibliotheken gebruiken.

De aanpak is om te ontwikkelen in LXD-containers die lokaal op een laptop of werkstation draaien, waarbij de grafische uitvoer naar de host wordt doorgestuurd.

Voorbeeldconfiguratie Ubuntu 20.04.

Aan het einde van het artikel worden reflecties op opties en redenen gegeven.

1. LXD-installatie

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

$ snap install lxd

Na de installatie moet u de initialisatie uitvoeren:

$ lxd init

De enige parameter die ik verander is storage bakend - Ik gebruik dir als de eenvoudigste. Aangezien ik geen foto's en kopieën gebruik, zijn de waarschuwingen in documentatie Ze maken me niet bang:

Op dezelfde manier moet de directory-backend worden beschouwd als een laatste redmiddel.
Het ondersteunt alle belangrijke LXD-functies, maar is vreselijk traag en inefficiënt omdat het niet kan presteren
directe kopieën of snapshots en moet dus elke keer de volledige opslag van de instantie kopiëren.

2. LXD-profielconfiguratie

Profielen in LXD — dit zijn sets parameters die op verschillende containers worden toegepast. Voor mijn behoeften is het enige standaard aangemaakte profiel voldoende voor mij default met de volgende wijzigingen:

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

3. Een container aanmaken en inrichten

Een container maken op basis van een afbeelding images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Ik geef de voorkeur aan afbeeldingen uit de repository https://images.linuxcontainers.org, omdat ze minder vooraf geïnstalleerde software hebben. Om deze reden heb ik het voorvoegsel toegevoegd images: naar de afbeeldingsnaam. Een container maken op basis van een afbeelding uit de Ubuntu-repository kan als volgt worden gedaan: $ lxc launch ubuntu/20.04 dev1.

Toegang tot de rootshell van de container:

$ lxc exec dev1 -- bash

Ik zal Firefox en VS Code installeren (vanuit 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

Voor de duidelijkheid voeg ik een container toe.

poweroff

Bonus! Het is vrij eenvoudig om een ​​GPU in een container te plaatsen, zodat toepassingen die daarin draaien de grafische kaart kunnen gebruiken. Om dit te doen heb je nodig:

• Voeg toestel toe $ lxc config device add dev1 mygpu gpu;
• installeer videokaartstuurprogramma's in de container - dezelfde die op de host zijn geïnstalleerd.

4. Een container gebruiken

Als de container nog niet actief is, moet u deze starten:

lxc start dev1

VS Code uitvoeren als niet-rootgebruiker ubuntu:

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

Firefox starten:

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

Applicatievensters worden op de host weergegeven, maar worden binnen de container uitgevoerd - vergelijkbaar met het doorsturen van afbeeldingen met behulp van ssh.

Ik sluit actieve containers niet handmatig af, omdat ik er niet veel zin in zie - ik beperk mezelf tot het sluiten van de vensters van actieve applicaties.

5. conclusie

Ik geef er de voorkeur aan om geen host-besturingssysteem te gebruiken voor ontwikkeling, omdat hiervoor ontwikkelingstools moeten worden geïnstalleerd, versies van bibliotheken moeten worden opgespoord, systeemcomponenten op een specifieke manier moeten worden geconfigureerd en andere manipulaties. Dit alles kan leiden tot onverwacht gedrag in andere niet-ontwikkelsoftware, of zelfs in het hele besturingssysteem. Wijzigingen in de OpenSSL-configuratie kunnen er bijvoorbeeld voor zorgen dat het besturingssysteem niet meer correct opstart.

Ik heb verschillende tools geprobeerd om ontwikkelomgevingen te isoleren:

• virtuele machines (KVM, VirtualBox, enz.) zijn de meest voor de hand liggende optie, maar ze verbruiken aanzienlijk meer bronnen, hoewel er geen andere ontwikkelingsopties onder Windows zijn (als de host Linux is);
• cloudontwikkelingstools die op een lokale machine draaien (Cloud9 in een container of virtuele machine, Eclipse Che, enz.) - ze zijn niet ontwikkeld voor deze werkingsmodus, ze vereisen aanvullende configuratie en onderhoud, het is het beste om ze te gebruiken waarvoor ze bedoeld zijn doel - in de cloud;
• Docker-containers zijn weer voor iets anders bedoeld; ze zijn naar mijn mening niet erg handig om snel prototyping te maken met software die nog niet in aparte containers is verpakt.

De gekozen aanpak maakt indruk op mij door zijn eenvoud en lage toetredingsdrempel. In de containers zelf kunt u projectspecifieke benaderingen gebruiken: alles handmatig installeren en configureren, of automatisering gebruiken (Puppet, Ansible, enz.), zelfs implementeren Docker-gebaseerde infrastructuur. Ik gebruik ook LXD-containers om specifieke software uit te voeren waarvoor ofwel een groot aantal afhankelijkheden of een andere besturingssysteemversie moet worden geïnstalleerd. In dit geval kunt u bijvoorbeeld een container maken met de gewenste besturingssysteemversie $ lxc launch images:ubuntu/16.04 dev16.

Het is belangrijk om te onthouden dat containerisatie in termen van isolatie een groter aanvalsoppervlak heeft vergeleken met virtualisatie: de host en de container delen een enkele kern, een kwetsbaarheid waardoor malware uit de container kan ontsnappen. Bij het experimenteren met dubieuze software is het beter om geschiktere isolatiemechanismen te gebruiken.

Nuttige links

• Uitgebreid artikel over Habré Basisfuncties van LXD - Linux containersystemen
• LXD-projectportaalis het belangrijk om LXD niet te verwarren met LXC - het zijn verschillende, maar onderling verbonden dingen.
• Blog Simos Xenitlis — deze blog bevat veel nuttige toegepaste informatie over LXD.
• Kant-en-klare images van virtuele Windows 10-machines voor ontwikkelaars — Microsoft verzamelt periodiek nieuwe builds en distribueert deze met een speciale licentie.

Bron: www.habr.com