_____ _   _ _    _    ___      _
 / ____| \ | | |  | |  / / |    (_)
| |  __|  \| | |  | | / /| |     _ _ __  _   ___  __
| | |_ | . ` | |  | |/ / | |    | | '_ \| | | \ \/ /
| |__| | |\  | |__| / /  | |____| | | | | |_| |>  <
 \_____|_| \_|\____/_/   |______|_|_| |_|\__,_/_/\_\

Instalacja kontenerów LXD/LXC

Kontenery LXD/LXC są kompromisem pomiędzy konternerami aplikacji takimi jak Docker oraz maszyna wirtualnymi kvm czy xen. Po ściągnięciu obrazu dostajemy czysty system operacyjny tak jakby to była świeżo zainstalowana maszyna wirtualna, ale to nadal przestrzeń użytkowa (userspace) ze współdzielonym wraz z hostem jądrem - kontener. Kontener będzie posiadać oddzielne wszystko to co kojarzy nam się z system operacyjnym, z tym elementami, których możemy hipotetycznie dotknąć. Do instalacji wybrałem serwer z system Ubuntu Server 18.04, ponieważ akurat taki miałem od ręką.

Pierwszą czynnością jaką wykonamy jest dodanie naszego użytkownika do grupy lxd, uwaga ta grupa może nie być dostępna przed instalacją pakietu LXD, więc jeśli to polecenie się nie powiedzie należy je wykonać zaraz po zainstalowaniu pakietu.

$ sudo usermod --append --groups lxd 

Podczas instalacji tym przypadku wykorzystałem system plików ZFS, jako magazyn danych dla kontenerów. ZFS wybieram głównie, gdy dane kontenerów będą przechowywane w oddzielnym dysku. Kiedy storage kontenerów jest wspódzielony z system operacyjnym to wtenczas wybieram dir - klasyczny katalog. Póki co Ubuntu w tej wersji nie wspiera natywnie ZFS dlatego też trzeba doinstalować jego obsługę z repozytorium. Jeśli będziemy korzystać z istniejącego dysku to należy utworzyć na nim partycję na całej jego wielkości.

$ sudo apt update
$ sudo apt install zfsutils-linux

W wielu systemach dostępny jest manager pakietów snap. Na tej stronie możemy sprawdzić czy dla naszej dystrybucji jest on wspierany: https://snapcraft.io/docs/installing-snapd, kiedy uporamy się z instalacją snapa, możemy przejść do instalacji właściwego pakietu.

$ sudo snap install lxd

Po zainstalowaniu pakietu, środowisko trzeba jescze zaincjować. Wydając poniższe polecenie uruchomimy kreator, który zbierze niezbędne do konfiguracji informacje. Postaram się przetłumaczyć te pytania.

$ sudo lxd init

Zatem:

Would you like to use LXD clustering ? (yes/no) [default=no]:

Czy chcesz użyć klastrowania LXD? - spowoduje uruchomienie LXC w trybie klastrowania, czy umożliwie podłączenia do sieci węzłów, wszystkie węzły posiadają jedną bazę danych i są zarządzane za pomocą pojedyńczych poleceń. Klaster ma za zadanie łatwiejsze zarządzanie dużą ilością serwerów z LXC.

Odpowiedź: domyślna.

Do you want to configure a new storage pool ? (yes/no) [default=yes]:

Czy chcesz skonfigurować nową przestrzeń danych - odpowiedź na to pytanie uruchomi, inicjalizacje przestrzeni danych (storage) dla kontenerów.

Odpowiedź: domyślna.

Name of the new storage pool [default=default]:

Nazwa nowej przestrzeni danych? - tutaj możemy nadać nazwę przestrzeni danych dla naszych kontenerów.

Odpowiedź: domyślna / nazwa własna

Name of the storage backend to use (btrfs, dir, lvm, zfs) [default=zfs]

Rodzaj przestrzeni danych - możemy teraz wybrać jaka technologia zostanie użyta do zarządzania przestrzenią danych naszych kontenerów, dla oddzielnych dysków wybieram zfs, ponieważ daje najkorzystniejsze efekty, kontener ma do dyspozycji tak jakby cały dysk (wykorzystuje obraz przestrzeni ZFS), dla dysku współdzielonego z systemem używam klasyczny dir. Do tego drugiego trzeba mieć odpowiednio duży dysk. Odpowiedź może być zasugerowana w zależności od dostępności danych technologii w systemie.

Odpowiedź: zfs / dir. Patrz wyżej.

Would you like to use an existing block device ? (yes/no) [default=no]:

Czy chcesz użyć istniejącego dysku? - wskazujemy dysk, ale tylko jeśli wybraliśmy zfs lub inny rodzaj storage-u, której jest również system plików w UNIX-ach, wyjątkiem będzie lvm, który jest sposobem zarządzania przestrzenią dyskową nie stricte system plików.

Odpowiedź: yes.

Path to existing block device:

Ścieżka do istniejącego dysku - musi to być partycja, najlepiej zrobić ją jeszcze przed rozpoczęciem inicjacji.

Odpowiedź: np. /dev/sda1

Would you like to connect to a MASS server? (yes/no) [default=no]:

Czy chcesz podłączyć się do serwera MAAS? - MAAS - technologia chmury od Canonical Ltd. https://maas.io

Odpowiedź: domyślna

Would you like to create a new local network bridge? (yes/no) [default=yes]

Czy chcesz utworzyć nowy most sieci lokalnej? - tworzymy sieć lokalną dla kontenerów, to coś jak intnet w VirtualBox. Od poźniejszych ustawień będzie zależeć jak będzie wyglądać ich komunikacja, jednak między sobą oraz systemem je hostującym będzie ona dość swobodna.

Odpowiedź: domyślna

What should the new bridge be called ? [default=lxdbr0]

Jaką nazwę nadać dla nowego mostu? - interfejsu między którym będzie wymieniana komunikacja pomiędzy wirtualnymi interfejsami kontenerów a interfejsem systemu hostującego.

Odpowiedź: domyślna / dowolna

What IPv4 address should be used ? (CIDR subnet notation, "auto", "none") [default=auto]

Jakiego adresu IPv4 należy użyć? [adres z notacją CIDR, "auto", "none"] - podajemy adres dla mostu, jedenocześnie ustalając klasę adresów dla naszych kontererów poprzez podanie maski CIDR.

Odpowiedź: 192.168.56.1/24 / dowolna inna.

Would you like LXD to NAT IPv4 traffic on your bridge? [default=yes]:

Czy chcesz przepuścić przez NAT ruch na twoim moście? - Ustawając tutaj yes lub no, możemy wybrać czy kontenery będą miały dostęp do sieci poza system je hostującym czy też nie.

Odpowiedź: domyślna.

What IPv6 address should be used? (CIDR subnet notation, "auto" or "none") [default=auto]: none

Jakiego adresu IPv6 należy użyć? [adres z notacją CIDR, "auto", "none"] - możemy zefiniować adres IPv6, jeśli z nich korzystamy, ja z nich nie korzystam więc ustawiam none

Odpowiedź: w zależności od potrzeb / none

Would you like LXD to be available over network (yes/no) [default=no]:

(Czy chcesz aby LXD by dostępny przez sieć?) - jeśli mamy wiele serwerów pod kontrolą to możemy to ustawić, następnie zarządzać nimi wszystkimi z jednego, umożliwienie dostępu do LXD przez sieć da nam również możliwość przenoszenia kontenerów między serwerami.

Odpowiedź: w zależności od potrzeb, dla pojedyńczego serwera zostawiamy domyślnie.

Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:

Czy chcesz automatyczne aktualizować pobrane obrazy kontenerów?

Odpowiedź: domyślna

Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:

(Czy chcemy wydrukowac wygenerowaną na podstawie naszych odpowiedzi konfiguracje LXD?)

Odpowiedź: domyślna

Po tym ostatnim pytaniu, środowisko LXC zostanie skonfigurowane do użycia. Kiedy zostanie nam zwrócony znak zachęty możemy przejść do utworzenia naszego pierwszego kontenera. Aby utworzyć kontener należy wydać poniższe polecenie.

$ lxc launch ubuntu:18.04 c1

Gdzie launch jest poleceniem odpowiedzialnym za tworzenie nowych kontenerów, ubuntu:18.04 jest nazwą źródła obrazu systemu operacyjnego, w tym przypadku określnego wyłącznie wersją, który służy do utworzenia kontenera, c1 jest nazwą naszego kontenera. System LXC wspiera wiele systemów operacyjnych, ich lista znajduje się tutaj: https://us.images.linuxcontainers.org/, aby skorzystać z innych systemów niż ubuntu, należy skorzystać z oficjalnego źródła, a nazwę zródła możemy sprawdzić wydając polecenie:

$ lxc remote list

Teraz dla przykładu możemy stworzyć kontener np. z GNU/Linux Debian, wydając poniższe polecenie. Dla Debiana możemy odwoływać zarówno numerem wersji jak i jej nazwą, identycznie dla Ubuntu.

$ lxc launch images:debian/10/amd64 c1

Po utworzeniu kontenera możemy się na niego zalogować aby móc na nim działać jak byśmy siedzieli przed konsolą prawdziwego serwera. Logowania możemy dokonać na dwa sposoby, jako użytkownik root, lub użytkownik nieuprzywilejowany z możliwością użycia polecenia podnoszącego uprawnienia. Niestety ten drugi sposób nie jest standardem i to czy możliwe będzie wykorzystanie go czy też nie, zależy głównie od konstrukcji obrazu kontenera. Druga opcja stosowana jest np. w Ubuntu, z kolei w Debianie już nie. Dlatego zachęcam do skorzystania z pierwszego sposobu.

Zalogowanie się do kontenera uruchomi powłokę interaktywną w środowisku kontenera, a co jeśli chcemy wykonać pojedyńcze polecenie, a nie uruchamiać powłokę? W tym przypadku zamiast /bin/bash wstawiamy polecenie jak ma zostać wykonane. Kiedy jednak wydajemy takie polecenie, to musimy mieć świadomość tego że jest ono wykonywane z uprawnieniami użytkownika root, chociaż jeżeli coś popsujemy na kontenerze zawsze możemy usunąć i uruchomić jeszcze raz, w prosty i szybki sposób, a nie ślęcząc przez instalacją po raz kolejny systemu bo zapomnieliśmy wyeksportować czystej maszyny zaraz po instalacji systemu, o fizycznych serwerach już nie wspominając.

~xf0r3m