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

за различни езици са нужни различни 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 — са набори от параметри, прилагани към няколко контейнера. За моите нужди ми е достатъчен единственият предварително зададен профил по подразбиране с следните промени:

$ 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 от не-привилегирован потребител 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.

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

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