ProHoster > Blog > administration > Isolering af udviklingsmiljøer med LXD-containere

Isolering af udviklingsmiljøer med LXD-containere

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

  • Forskellige sprog kræver forskellige IDE'er og værktøjskæder;
  • Forskellige projekter kan bruge forskellige versioner af værktøjskæder og biblioteker.

Fremgangsmåden er at udvikle inde i LXD-containere, der kører lokalt på en bærbar eller arbejdsstation med grafikoutput omdirigeret til værten.

Eksempel konfiguration Ubuntu 20.04.

Refleksioner over muligheder og begrundelser er givet i slutningen af ​​artiklen.

1. LXD installation

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

$ snap install lxd

Efter installationen skal du udføre initialisering:

$ lxd init

Den eneste parameter jeg ændrer er storage bakend - Jeg bruger dir som den enkleste. Da jeg ikke bruger billeder og kopier, er advarslerne i dokumentation De skræmmer mig ikke:

Tilsvarende skal mappens backend betragtes som en sidste udvej.
Den understøtter alle de vigtigste LXD-funktioner, men er frygtelig langsom og ineffektiv, da den ikke kan udføre
øjeblikkelige kopier eller snapshots og skal derfor kopiere hele instansens lager hver gang.

2. LXD profil opsætning

Profiler i LXD — disse er sæt af parametre, der anvendes på flere containere. Til mine behov er den eneste profil oprettet som standard nok for mig default med følgende ændringer:

  • $ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0 — så applikationer i containere kan interagere med værts X11-serveren;
  • $ lxc profile set default environment.DISPLAY :0 - således at miljøvariablen DISPLAY var installeret korrekt i containere;
  • $ lxc profile set default raw.idmap "both 1000 1000" - for det rigtige identifikatorkortlægning.

3. Oprettelse og opsætning af en container

Oprettelse af en container baseret på et billede images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Jeg foretrækker billeder fra depotet https://images.linuxcontainers.org, da de har mindre forudinstalleret software. 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 beholderens rodskal:

$ lxc exec dev1 -- bash

Jeg vil installere Firefox og VS Code (fra lageret 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 inkludere en beholder for klarhedens skyld.

poweroff

Bonus! Det er ret nemt at smide en GPU i en beholder, så programmer, der kører i den, kan bruge grafikkortet. For at gøre dette skal du bruge:

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

4. Brug af en beholder

Hvis beholderen endnu ikke kører, skal du starte den:

lxc start dev1

Kører VS-kode som en ikke-rootbruger ubuntu:

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

Start Firefox:

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

Programvinduer vil blive vist på værten, men de vil blive udført inde i containeren - svarende til at videresende grafik ved hjælp af ssh.

Jeg lukker ikke kørende containere ned manuelt, fordi jeg ikke kan se meget mening i det - jeg begrænser mig til at lukke vinduerne for kørende applikationer.

5. Konklusion

Jeg foretrækker ikke at bruge et værts-OS til udvikling, da dette ville kræve installation af udviklingsværktøjer, fejlfinding af versioner af biblioteker, konfiguration af systemkomponenter på en specifik måde og andre manipulationer. Alt dette kan føre til uventet adfærd i anden ikke-udviklingssoftware eller endda hele OS. For eksempel kan ændringer i OpenSSL-konfigurationen få OS til at stoppe med at starte korrekt.

Jeg har prøvet forskellige værktøjer til at isolere udviklingsmiljøer:

  • virtuelle maskiner (KVM, VirtualBox osv.) er den mest oplagte mulighed, men de bruger betydeligt flere ressourcer, selvom der ikke er andre muligheder for udvikling under Windows (hvis værten er Linux);
  • cloud-udviklingsværktøjer, der kører på en lokal maskine (Cloud9 i en container eller virtuel maskine, Eclipse Che osv.) - de er ikke udviklet til denne driftsform, de kræver yderligere konfiguration og vedligeholdelse, det er bedst at bruge dem til deres tilsigtede formål - i skyen;
  • Docker-containere - igen, er beregnet til noget andet; efter min mening er de ikke særlig praktiske til hurtig prototyping ved hjælp af software, der endnu ikke er pakket i separate containere.

Den valgte tilgang imponerer mig med sin enkelhed og lave adgangsbarriere. I selve containerne kan du bruge projektspecifikke tilgange: Installer og konfigurer alt manuelt, eller brug automatisering (Puppet, Ansible osv.), selv implementer Docker-baseret infrastruktur. Jeg bruger også LXD-containere til at køre specifik software, der enten kræver installation af et stort antal afhængigheder eller en anden OS-version - i dette tilfælde kan du oprette en container med den ønskede OS-version, f.eks. $ lxc launch images:ubuntu/16.04 dev16.

Det er vigtigt at huske, at isolationsmæssigt har containerisering en større angrebsflade sammenlignet med virtualisering – værten og containeren deler en enkelt kerne, en sårbarhed, hvori kan tillade malware at undslippe containeren. Når du eksperimenterer med tvivlsom software, er det bedre at bruge mere passende isolationsmekanismer.

Nyttige links

Kilde: www.habr.com

Tilføj en kommentar