Opowiem o podejściu do organizacji lokalnych, izolowanych środowisk deweloperskich na mojej stacji roboczej. Podejście zostało opracowane pod wpływem następujących czynników:

• dla różnych języków potrzebne są różne IDE i zestawy narzędzi;
• w różnych projektach mogą być używane różne wersje zestawów narzędzi i bibliotek.

Podejście polega na prowadzeniu rozwój wewnątrz kontenerów LXD uruchomionych lokalnie na laptopie lub stacji roboczej z przekierowaniem wyjścia graficznego do hosta.

Konfiguracja na przykładzie Ubuntu 20.04.

Rozważania na temat wariantów i powodów zostały przedstawione na końcu artykułu.

1. Instalacja LXD

W Ubuntu 20.04 LXD nie jest już dostępny do instalacji jako pakiet deb, tylko przez snap:

$ snap install lxd

Po instalacji należy wykonać inicjalizację:

$ lxd init

Jedynym parametrem, który zmieniam, jest storage backend — używam dir jako najprostszej opcji. Ponieważ nie używam migawek ani kopii, ostrzeżenia w dokumentacji mnie nie przerażają:

Podobnie, backend katalogu należy traktować jako ostateczną opcję.
Obsługuje wszystkie główne funkcje LXD, ale jest strasznie wolny i nieskuteczny, ponieważ nie może wykonywać
natychmiastowych kopii ani migawek, w związku z czym musi kopiować całą przestrzeń dyskową instancji za każdym razem.

2. Ustawianie profilu LXD

Profile w LXD to zestawy parametrów stosowanych do kilku kontenerów. Dla moich potrzeb wystarczy mi jeden stworzony domyślnie profil default z następującymi zmianami:

• $ lxc profile device add default X0 disk source=\/tmp\/.X11-unix\/X0 path=\/tmp\/.X11-unix\/X0 — aby aplikacje w kontenerach mogły współpracować z hostowym serwerem X11;
• $ lxc profile set default environment.DISPLAY :0 — aby zmienna środowiskowa DISPLAY w kontenerach była ustawiona poprawnie;
• $ lxc profile set default raw.idmap "both 1000 1000" — dla prawidłowego mapowania identyfikatorów.

3. Tworzenie i konfiguracja kontenera

Tworzenie kontenera na podstawie obrazu images:ubuntu\/20.04:

$ lxc launch images:ubuntu\/20.04 dev1

Preferuję obrazy z repozytorium, ponieważ mają mniej wstępnie zainstalowanego oprogramowania. Z tego powodu dodałem prefiks https://images.linuxcontainers.orgimages: do nazwy obrazu. Utworzenie kontenera na podstawie obrazu z repozytorium Ubuntu można wykonać w następujący sposób: $ lxc launch ubuntu\/20.04 dev1 Dostęp do powłoki roota kontenera:.

$ lxc exec dev1 -- bash

Zainstaluję Firefox i VS Code (z repozytorium

zgodnie z instrukcją zgodnie z instrukcją):

$ 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

Włączę kontener dla przejrzystości

poweroff

Bonus! Zaskakująco łatwo jest przekazać GPU do kontenera, aby aplikacje uruchomione wewnątrz mogły korzystać z karty graficznej. Wymaga to:

• dodać urządzenie $ lxc config device add dev1 mygpu gpu;
• zainstalować w kontenerze sterowniki karty graficznej — te same, które są zainstalowane na hoście.

4. Użycie kontenera

Jeśli kontener jeszcze nie działa, należy go uruchomić:

lxc start dev1

Uruchamianie VS Code jako nieuprzywilejowany użytkownik ubuntu:

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

Uruchamianie Firefox:

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

Okna aplikacji wyświetlą się na hoście, ale będą wykonywane wewnątrz kontenera — podobnie jak przekazywanie grafiki za pomocą ssh.

Nie wyłączam ręcznie uruchomionych kontenerów, ponieważ nie widzę w tym sensu — ograniczam się do zamykania okien uruchomionych aplikacji.

5. Podsumowanie

Preferuję nie używać systemu operacyjnego hosta do programowania, ponieważ wymagałoby to instalacji narzędzi deweloperskich, wersji debugujących bibliotek, konfigurowania komponentów systemu w specyficzny sposób oraz innych manipulacji. Wszystko to może prowadzić do niespodziewanego zachowania pozostałego, niezwiązanego z programowaniem oprogramowania, a nawet całego systemu operacyjnego. Na przykład zmiany w konfiguracji OpenSSL mogą spowodować, że system operacyjny przestanie poprawnie się uruchamiać.

Wypróbowałem różne narzędzia do izolacji środowisk deweloperskich:

• maszyny wirtualne (KVM, VirtualBox itd.) — najbardziej oczywisty wybór, ale zużywają znacznie więcej zasobów, chociaż dla programowania pod Windows (jeśli host to Linux) nie ma innych opcji;
• narzędzia do programowania w chmurze uruchamiane na lokalnej maszynie (Cloud9 w kontenerze lub maszynie wirtualnej, Eclipse Che itd.) — nie są one projektowane do takiego trybu pracy, wymagają dodatkowej konfiguracji i obsługi, najlepiej używać ich zgodnie z przeznaczeniem — w chmurze;
• Kontenery Docker znowu są przeznaczone do innych celów; moim zdaniem nie są one zbyt wygodne do szybkiego prototypowania z użyciem oprogramowania, które nie zostało jeszcze spakowane w osobne kontenery.

Wybrana metoda podoba mi się ze względu na swoją prostotę i niski próg wejścia. W samych kontenerach można stosować specyficzne dla projektów podejścia: instalować i konfigurować wszystko ręcznie lub stosować automatyzację (Puppet, Ansible itp.), a nawet rozwijać infrastrukturę opartą na Dockerze.Używam kontenerów LXD również do uruchamiania specyficznego oprogramowania, które wymaga zainstalowania dużej liczby zależności lub innej wersji systemu operacyjnego — w takim przypadku można stworzyć kontener z wymaganą wersją systemu operacyjnego, na przykład $ lxc launch images:ubuntu/16.04 dev16.

Ważne jest, aby pamiętać, że pod względem izolacji konteneryzacja ma większą powierzchnię ataku w porównaniu do wirtualizacji — host i kontener dzielą jedno jądro, a jego podatność może pozwolić złośliwemu oprogramowaniu na ucieczkę z kontenera. Do eksperymentów z wątpliwym oprogramowaniem lepiej używać bardziej odpowiednich mechanizmów izolacji.

Przydatne linki

• Zwięzły artykuł na Habrze Podstawowe możliwości LXD — systemu kontenerów w Linuxie
• Portal projektu LXD, ważne jest, aby nie mylić LXD z LXC — to różne, ale powiązane rzeczy.
• Blog Simos Xenitellis — ten blog zawiera mnóstwo przydatnych informacji praktycznych na temat LXD.
• Gotowe obrazy maszyn wirtualnych Windows 10 dla deweloperów — Microsoft okresowo przygotowuje nowe wydania i udostępnia je z specjalną licencją.

Źródło: habr.com