Jeg vil fortælle om tilgangen til at organisere lokale isolerede udviklingsmiljøer på min arbejdsstation. Tilgangen er blevet udviklet under indflydelse af følgende faktorer:

• for forskellige sprog er der behov for forskellige IDE'er og værktøjer;
• forskellige projekter kan bruge forskellige versioner af værktøjer og biblioteker.

Tilgangen går ud på at foretage udvikling inden for LXD-containere, som kører lokalt på en laptop eller arbejdsstation med videreledning af grafisk output til værten.

Konfiguration som eksempel Ubuntu 20.04.

Refleksioner over muligheder og årsager er præsenteret i slutningen af artiklen.

1. Installation af LXD

I Ubuntu 20.04 LXD er ikke længere tilgængelig til installation som deb-pakke, kun via snap:

$ snap install lxd

Efter installationen skal initializationen udføres:

$ lxd init

Den eneste parameter, som jeg ændrer, er storage backend — jeg bruger dir som den enkleste. Da jeg ikke bruger snapshots og kopier, skræmmer advarslerne i dokumentationen mig ikke:

Tilsvarende bør backend til mapper betragtes som en sidste udvej.
Det understøtter alle hovedfunktioner i LXD, men er frygtelig langsom og ineffektiv, da det ikke kan udføre
øjeblikkelige kopier eller snapshots og derfor skal kopiere hele instansens lager hver gang.

2. Konfiguration af LXD-profil

Profiler i LXD — er mængder af parametre, der anvendes på flere containere. For mine behov er det tilstrækkeligt med den standardprofil, der er oprettet default med følgende ændringer:

• $ lxc profile device add default X0 disk source=\/tmp\/.11-unix\/X0 path=\/tmp\/.11-unix\/X0 — for at applikationer i containerne kan interagere med værtsens X11-server;
• $ lxc profile set default environment.DISPLAY :0 — for at miljøvariablen DISPLAY i containerne er indstillet korrekt;
• $ lxc profile set default raw.idmap "both 1000 1000" — for korrekt mapping af identifikatorer..

3. Oprettelse og konfiguration af container

Oprettelse af en container baseret på billedet images:ubuntu\/20.04:

$ lxc launch images:ubuntu\/20.04 dev1

Jeg foretrækker billeder fra depotet https://images.linuxcontainers.org, da der er mindre forudinstalleret software i dem. Af denne grund tilføjede jeg præfikset images: til billedets navn. Oprettelse af en container baseret på et billede fra Ubuntu-depotet kan gøres som følger: $ lxc launch ubuntu\/20.04 dev1.

Adgang til containerens root-shell:

$ lxc exec dev1 -- bash

Jeg vil installere Firefox og VS Code (fra depotet i henhold til instruktionerne):

$ 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

Jeg vil aktivere containeren for klarhed

poweroff

Bonus! Det er ret enkelt at videresende GPU'en til containeren, så de applikationer, der kører i den, kan bruge grafikkortet. For at gøre dette skal du:

• tilføje en enhed $ lxc config device add dev1 mygpu gpu;
• installere grafikkortdrivere i containeren — de samme som er installeret på værten.

4. Brug af containeren

Hvis containeren ikke allerede er startet, skal den startes:

lxc start dev1

Kørsel af VS Code som en ikke-privilegeret bruger ubuntu:

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

Kørsel af Firefox:

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

Applikationsvinduerne vil blive vist på værten, men de vil køre inde i containeren — ligesom grafikken bliver videresendt via ssh.

Jeg slukker ikke for de kørende containere manuelt, da jeg ikke ser nogen særlig grund til det — jeg begrænser mig til at lukke vinduerne fra de kørende applikationer.

5. Konklusion

Jeg foretrækker ikke at bruge værts-OS til udvikling, da det ville kræve installation af udviklingsværktøjer, debugging-versioner af biblioteker, konfiguration af systemkomponenter på en specifik måde og andre manipulationer. Alt dette kan føre til uventet adfærd fra andet software, der ikke er relateret til udvikling, eller endda hele OS. For eksempel kan ændringer i OpenSSL-konfigurationen føre til, at OS ikke længere starter korrekt.

Jeg har prøvet forskellige midler til at isolere udviklingsmiljøer:

• virtuelle maskiner (KVM, VirtualBox osv.) — den mest oplagte mulighed, men det kræver betydeligt flere ressourcer, selvom der ikke er andre muligheder for udvikling på Windows (hvis værten er Linux);
• værktøjer til cloud-udvikling, der kører på den lokale maskine (Cloud9 i en container eller virtuel maskine, Eclipse Che osv.) — de er ikke designet til denne driftsform, de kræver ekstra opsætning og vedligeholdelse, det er bedst at bruge dem til deres formål — i skyen;
• Docker-containere er igen designet til noget andet; efter min mening er det ikke meget bekvemt at prototypere hurtigt med software, der endnu ikke er pakket i separate containere.

Den valgte tilgang tiltaler mig med sin enkelhed og lave tærskel for indtræden. I selve containerne kan man anvende projektspecifikke metoder: installere og konfigurere alt manuelt eller anvende automatisering (Puppet, Ansible osv.), endda ud deployere infrastruktur baseret på Docker.Jeg bruger også LXD-containere til at køre specifik software, som enten kræver installation af mange afhængigheder eller en anden version af OS - i dette tilfælde kan man oprette en container med den nødvendige version af OS, for eksempel $ lxc launch images:ubuntu/16.04 dev16.

Det er vigtigt at huske, at når det kommer til isolation, har containerisering en større angrebsoverflade sammenlignet med virtualisering - værten og containeren deler et kerne, en sårbarhed her kan give malware mulighed for at slippe ud af containeren. Til eksperimenter med tvivlsom software er det bedre at bruge mere passende isolationsmekanismer.

Nyttige links

• En fyldestgørende artikel på Habré. Grundlæggende funktioner i LXD - container systemet i Linux
• Portalen for LXD-projektet, det er vigtigt ikke at forveksle LXD med LXC - de er forskellige, men relaterede ting.
• Bloggen Simos Xenitellis - denne blog har masser af nyttig praktisk information om LXD.
• Færdige billeder af virtuelle maskiner Windows 10 til udviklere - Microsoft samler regelmæssigt nye builds og distribuerer dem med en særlig licens.

Kilde: habr.com