Ще говоря за подход за организиране на локални изолирани среди за разработка на моята работна станция. Подходът е разработен под въздействието на следните фактори:

• Различните езици изискват различни IDE и вериги от инструменти;
• Различните проекти могат да използват различни версии на инструментални вериги и библиотеки.

Подходът е да се разработи в LXD контейнери, работещи локално на лаптоп или работна станция с графичен изход, пренасочен към хоста.

Примерна конфигурация Ubuntu 20.04.

Размисли за варианти и причини са дадени в края на статията.

1. LXD инсталация

В Ubuntu 20.04 LXD вече не е достъпен за инсталиране като deb пакет, само чрез snap:

$ snap install lxd

След инсталирането трябва да извършите инициализация:

$ lxd init

Единственият параметър, който променям, е storage bakend - Използвам dir като най-простият. Тъй като не използвам снимки и копия, предупрежденията са включени документация Не ме плашат:

По подобен начин бекендът на директорията трябва да се разглежда като последна опция.
Той поддържа всички основни функции на LXD, но е ужасно бавен и неефективен, тъй като не може да работи
незабавни копия или моментни снимки и така трябва да копира цялото хранилище на екземпляра всеки път.

2. Настройка на LXD профил

Профили в LXD — това са набори от параметри, приложени към няколко контейнера. За моите нужди ми е достатъчен единственият профил, създаден по подразбиране default със следните промени:

• $ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0 — така че приложенията в контейнери да могат да взаимодействат с хост X11 сървъра;
• $ lxc profile set default environment.DISPLAY :0 - така че променливата на околната среда DISPLAY е инсталиран правилно в контейнери;
• $ lxc profile set default raw.idmap "both 1000 1000" - за правилното съпоставяне на идентификатори.

3. Създаване и настройка на контейнер

Създаване на контейнер въз основа на изображение images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Предпочитам изображения от хранилището https://images.linuxcontainers.org, тъй като имат по-малко предварително инсталиран софтуер. Поради тази причина добавих префикса images: към името на изображението. Създаването на контейнер въз основа на изображение от хранилището на Ubuntu може да се направи по следния начин: $ lxc launch ubuntu/20.04 dev1.

Достъп до основната обвивка на контейнера:

$ lxc exec dev1 -- bash

Ще инсталирам Firefox и VS Code (от хранилището според инструкциите):

$ 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

Ще включа контейнер за яснота.

poweroff

Бонус! Доста лесно е да хвърлите GPU в контейнер, така че приложенията, работещи в него, да могат да използват графичната карта. За да направите това ви трябва:

• добави устройство $ lxc config device add dev1 mygpu gpu;
• инсталирайте драйвери за видеокарти в контейнера - същите, които са инсталирани на хоста.

4. Използване на контейнер

Ако контейнерът все още не работи, трябва да го стартирате:

lxc start dev1

Изпълнение на VS Code като не-root потребител Ubuntu:

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

Стартирайте Firefox:

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

Прозорците на приложенията ще се показват на хоста, но те ще се изпълняват вътре в контейнера - подобно на препращането на графики чрез ssh.

Не изключвам ръчно работещите контейнери, защото не виждам много смисъл в това - ограничавам се до затваряне на прозорците на работещи приложения.

5. заключение

Предпочитам да не използвам хост операционна система за разработка, тъй като това ще изисква инсталиране на инструменти за разработка, отстраняване на грешки във версии на библиотеки, конфигуриране на системни компоненти по специфичен начин и други манипулации. Всичко това може да доведе до неочаквано поведение в друг софтуер, който не е за разработка, или дори в цялата операционна система. Например промените в конфигурацията на OpenSSL могат да доведат до спиране на стартирането на операционната система правилно.

Опитах различни инструменти за изолиране на среди за разработка:

• виртуалните машини (KVM, VirtualBox и т.н.) са най-очевидният вариант, но те консумират значително повече ресурси, въпреки че няма други възможности за разработка под Windows (ако хостът е Linux);
• инструменти за разработка на облак, работещи на локална машина (Cloud9 в контейнер или виртуална машина, Eclipse Che и т.н.) - те не са разработени за този режим на работа, изискват допълнителна конфигурация и поддръжка, най-добре е да ги използвате по предназначение предназначение - в облака;
• Docker контейнерите отново са предназначени за нещо друго; според мен те не са много удобни за бързо създаване на прототипи с помощта на софтуер, който все още не е опакован в отделни контейнери.

Избраният подход ме впечатлява със своята простота и ниска бариера за влизане. В самите контейнери можете да използвате подходи, специфични за проекта: инсталирайте и конфигурирайте всичко ръчно или използвайте автоматизация (Puppet, Ansible и т.н.), дори внедряване Докер базирана инфраструктура. Също така използвам LXD контейнери за стартиране на специфичен софтуер, който или изисква инсталиране на голям брой зависимости, или различна версия на ОС - в този случай можете да създадете контейнер с желаната версия на ОС, например $ lxc launch images:ubuntu/16.04 dev16.

Важно е да запомните, че по отношение на изолацията, контейнеризацията има по-голяма повърхност за атака в сравнение с виртуализацията - хостът и контейнерът споделят едно ядро, уязвимост, в която може да позволи на зловреден софтуер да избяга от контейнера. Когато експериментирате със съмнителен софтуер, по-добре е да използвате по-подходящи механизми за изолация.

Полезни връзки

• Просторна статия на Хабре Основни характеристики на LXD - Linux контейнерни системи
• Портал за проекти LXD, важно е да не бъркате LXD с LXC - те са различни, но взаимосвързани неща.
• Блог Simos Xenitellis — този блог има много полезна приложна информация за LXD.
• Готови изображения на виртуални машини с Windows 10 за разработчици — Microsoft периодично събира нови компилации и ги разпространява със специален лиценз.

Източник: www.habr.com