Räägin lähenemisest isoleeritud arenduskeskkondade korraldamiseks oma tööjaamas. See lähenemine on välja töötatud järgmiste tegurite mõjul:
- erinevad keeled nõuavad erinevaid IDE-sid ja tööriistakomplekte;
- erinevates projektides võivad olla kasutusel erinevad tööriistakomplektide ja raamatukogude versioonid.
Lähenemine seisneb arenduses LXD konteinerites, mis on käivitatud kohapeal sülearvutis või tööjaamas, kus graafika väljund suunatakse hostisse.
Konfiguratsioon näite põhjal Ubuntu 20.04.
Mõtisklused võimaluste ja põhjuste üle on toodud artikli lõpus.
1. LXD paigaldamine
V Ubuntu 20.04 LXD ei ole enam saadaval deb-paketi kujul, ainult snap'i kaudu:
$ snap install lxdPärast installimist tuleb teha initsialiseerimine:
$ lxd initAinus parameeter, mida ma muudan, on storage backend — kasutan dir kui kõige lihtsamat. Kuna ma ei kasuta hetkepilte ega koopiaid, ei ehmata mind hoiatused :
Sarnaselt on ka kaustal põhinev lahendus viimane võimalus.
See toetab kõiki peamisi LXD funktsioone, kuid on äärmiselt aeglane ja ebaefektiivne, kuna ei saa teha
hetke koopiaid ega hetktõmmiseid, mistõttu peab iga kord kopeerima kogu instantsi salvestusruumi.
2. LXD profiili seadistamine
— see on parameetrite komplekt, mida rakendatakse mitmele konteinerile. Minu vajaduste jaoks piisab täiesti ühe vaikeprofiili loomisest. default koos järgmiste muudatustega:
$ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0— et rakendused konteinerites saaksid suhelda hosti X11 serveriga;$ lxc profile set default environment.DISPLAY :0— et keskkonnamuutujaDISPLAYkonteinerites oleks õigesti seadistatud;$ lxc profile set default raw.idmap "both 1000 1000"— õige .
3. konteineri loomine ja seadistamine
Konteineri loomine pildi põhjal images:ubuntu/20.04:
$ lxc launch images:ubuntu/20.04 dev1Eelistangi pilte asjaarhiivist, sest seal on vähem eelinstallitud tarkvara. Sel põhjusel lisasin ma eelneva images: pildi nimele. Ubuntu arhiivis oleva pildi põhjal konteineri loomine käib järgmiselt: $ lxc launch ubuntu/20.04 dev1.
Juurde pääsemine konteineri shell'i:
$ lxc exec dev1 -- bashInstalleerin Firefoxi ja VS Code'i (arhiivist ):
$ 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 codeKasutades konteinerit selgemaks muutmiseks
välja lülitaBoonus! GPU edastamine konteinerisse on piisavalt lihtne, et rakendused, mis seal töötavad, saaksid kasutada graafikakaarti. Selleks tuleb:
- seade lisada
$ lxc config device add dev1 mygpu gpu; - paigaldada konteinerisse graafikakaardi draiverid — samad, mis on paigaldatud hostis.
4. Koti kasutamine
Kui konteiner ei ole veel käivitatud, tuleb see käivitada:
lxc start dev1VS Code'i käivitamine mitteprivileegitud kasutajana ubuntu:
lxc exec dev1 -- sudo --login --user ubuntu codeFirefoxi käivitamine:
lxc exec dev1 -- sudo --login --user ubuntu firefoxRakenduste aknad kuvatakse hostis, kuid need töötavad konteineris — sarnanedes graafika edastamisele ssh kaudu.
Ma ei lülita jooksvaid konteinerite käsitsi välja, kuna ei näe selles erilist mõtet — piirdun avatud rakenduste akende sulgemisega.
5. Kokkuvõte
Ma eelistan mitte kasutada hosti operatsioonisüsteemi arendamiseks, kuna see tähendaks arendustööriistade, teekide silumiste versioonide installimist, süsteemi komponentide spetsiifilist seadistamist ja muid manipulatsioone. Kõik see võib põhjustada ootamatut käitumist muus, mitte arendusega seotud tarkvaras, või isegi kogu operatsioonisüsteemis. Näiteks võivad OpenSSL-i konfiguratsiooni muutmised põhjustada, et operatsioonisüsteem lõpetab nõuetekohase käivitamise.
Olen proovinud erinevaid meetodeid arenduskeskkondade isoleerimiseks:
- virtuaalmasinad (KVM, VirtualBox jne) — kõige ilmselisem variant, kuid see tarbib märgatavalt rohkem ressursse, kuigi Windowsi arendamiseks (kui host on Linux) pole muid valikuid;
- kohalikul masinal töötavad pilvearendustööriistad (Cloud9 konteineris või virtuaalses masinas, Eclipse Che jne) — neid ei arendata selliseks töörežiimiks, need vajavad täiendavat seadistamist ja hooldust, neid on kõige parem kasutada nende otstarbel — pilves;
- Dockeri konteinerid on - minu arvates - mõeldud millekski muuks, nendes ei ole väga mugav kiiresti prototüüpe koostada tarkvara jaoks, mis ei ole veel eraldi konteineritesse pakendatud.
Valitud lähenemine mulle meeldib selle lihtsuse ja madala sissejuhatusetõkke tõttu. Igas konteineris saab rakendada projektipõhiseid lähenemisi: kõike saab installida ja seadistada käsitsi või kasutada automatiseerimist (Puppet, Ansible jne), isegi arendada. Kasutangi LXD konteinerit, et käivitada spetsiifilist tarkvara, mis nõuab kas palju sõltuvusi või teistsugust operatsioonisüsteemi — sellisel juhul saab luua konteineri soovitud operatsioonisüsteemi versiooniga, näiteks. $ lxc launch images:ubuntu/16.04 dev16.
Oluline on meeles pidada, et konteinerimise osas on isolatsioonil võrreldes virtualiseerimisega suurem rünnaku pind — host ja konteiner jagavad ühte tuuma, mille haavatavus võib võimaldada pahavaralise tarkvara escape'ida konteinerist. Eksperimentide tegemiseks kaheldava tarkvaraga on parem kasutada sobivamaid isolatsioonimehanisme.
Kasulikud lingid
- Mahukas artikkel Habras.
- , oluline on mitte segamini ajada LXD ja LXC — need on erinevad, kuid omavahel seotud asjad.
- — selles blogis on palju kasulikku praktilist teavet LXD kohta.
- — Microsoft kogub perioodiliselt uusi versioone ja jagab neid spetsiaalse litsentsi alusel.
Allikas: habr.com
