ProHoster > блог > адміністраванне > Ізаляцыя асяроддзяў распрацоўкі з дапамогай кантэйнераў LXD

Ізаляцыя асяроддзяў распрацоўкі з дапамогай кантэйнераў LXD

Я раскажу аб падыходзе да арганізацыі лакальных ізаляваных асяроддзяў распрацоўкі на сваёй працоўнай станцыі. Падыход быў выпрацаваны пад уздзеяннем наступных фактараў:

  • для розных моў патрэбны розныя IDE і тулчайны;
  • у розных праектах могуць выкарыстоўвацца розныя версіі тулчайнаў і бібліятэк.

Падыход заключаецца ў тым, каб весці распрацоўку ўнутры LXD кантэйнераў запушчаных лакальна на ноўтбуку або працоўнай станцыі з перанакіраваннем вываду графікі ў хост.

Канфігурацыя на прыкладзе Ubuntu 20.04.

Разважанні аб варыянтах і прычынах прыведзены ў канцы артыкула.

1. Устаноўка LXD

В Ubuntu 20.04 LXD больш не даступны для ўстаноўкі як deb пакет, толькі праз snap:

$ snap install lxd

Пасля ўстаноўкі трэба выканаць ініцыялізацыю:

$ lxd init

Адзіны параметр які я мяняю, гэта storage bakend - я выкарыстоўваю dir як самы просты. Так як здымкі і копіі я не выкарыстоўваю, то папярэджання ў дакументацыі мяне не палохаюць:

Падобна, directory backend з'яўляецца вынікам апошніх рэсурсаў option.
Гэта спрыяе ўсім галоўным LXD нюансы, але з'яўляецца вельмі нізкім і неэфектыўным, як ён можа быць
instant copies or snapshots and so needs to copy the entirety of instance's storage every time.

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 ад імя не прывілеяванага карыстальніка 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.

Важна памятаць аб тым, што ў разрэзе ізаляцыі кантэйнерызацыя мае вялікую паверхню атакі ў параўнанні з віртуалізацыяй - хост і кантэйнер дзеляць адно ядро, уразлівасць у якім можа дазволіць шкоднаснаму праграмнаму забеспячэнню збегчы з кантэйнера. Для эксперыментаў з сумнеўным ПЗ лепш выкарыстоўваць больш прыдатныя механізмы ізаляцыі.

Карысныя спасылкі

Крыніца: habr.com

Дадаць каментар