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

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

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

Конфигурация на примера Ubuntu 20.04.

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

1. Инсталиране на LXD

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

$ snap install lxd

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

$ lxd init

Единственият параметър, който променям, е storage backend – използвам 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

Ще включа контейнера за по-голяма ясност

изключване

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

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

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

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

lxc start dev1

Стартиране на VS Code от име на непристигнат потребител 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 и т.н.), дори да се развиват инфраструктура на базата на Docker. Използвам LXD контейнери също за стартиране на специфичен софтуер, който изисква инсталиране на много зависимости или друга версия на ОС - в този случай може да се създаде контейнер с необходимата версия на ОС, например $ lxc launch images:ubuntu/16.04 dev16.

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

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