LXD — to menedżer kontenerów nowej generacji, tak mówi ClickHouse-Ninja/Proton. Oferuje interfejs użytkownika przypominający maszyny wirtualne, ale zamiast tego wykorzystuje kontenery Linux.

Jądro LXD — to uprzywilejowany demon (usługa uruchomiona z prawami root), który udostępnia REST API przez lokalny gniazdo unixowe, a także przez sieć, jeśli została zainstalowana odpowiednia konfiguracja. Klienci, tacy jak narzędzie wiersza poleceń dostarczane z LXD, wysyłają żądania przez to REST API. Oznacza to, że niezależnie od tego, czy zwracasz się do lokalnego hosta, czy do zdalnego, wszystko działa w ten sam sposób.

W tym artykule nie będziemy szczegółowo omawiać koncepcji LXD, nie będziemy rozważać wszystkich dostępnych możliwości przedstawionych w dokumentacji, w tym ostatniej realizacji w najnowszych wersjach LXD wsparcia dla maszyn wirtualnych QEMU równolegle z kontenerami. Zamiast tego poznamy tylko podstawowe możliwości zarządzania kontenerami — skonfigurujemy pule przechowywania, sieć, uruchomimy kontener, zastosujemy limity na zasoby, a także omówimy, jak korzystać z migawków, abyś mógł uzyskać podstawowe pojęcie o LXD i korzystać z kontenerów w Linuxie.

Aby uzyskać pełne informacje, należy odwołać się do oficjalnego źródła:

• Strona dewelopera
• Dokumentacja
• Forum

Nawigacja

• Instalacja LXD
  • Instalacja LXD w dystrybucjach Ubuntu
  • Instalacja LXD w dystrybucjach Arch Linux
• Przechowywanie LXD (Storage)
• Inicjalizacja LXD
  • Wybór systemu plików dla Storage Pool
  • Inicjalizacja sieci i Storage Pool za pomocą kreatora
  • Tworzenie dodatkowego Storage Pool
    • Zwiększenie rozmiaru Storage Pool
    • Automatyczne wstawianie pliku loopback do slotu urządzenia loopback
  • Bezpieczeństwo. Uprawnienia kontenerów
  • Tworzenie wirtualnego przełącznika sieciowego
  • Profil konfiguracji
    • Edycja profilu
    • Tworzenie nowych profili
  • Repozytorium obrazów
    • Zdalne repozytoria obrazów
    • Lokalne repozytorium obrazów
  • Konfiguracja LXD
• Tworzenie i zarządzanie kontenerem
  • Ustawienie statycznego adresu IP
  • Usunięcie kontenera
  • Dostęp do kontenera
  • Zarządzanie zasobami kontenera
    • Ograniczenie zasobów RAM (Pamięć operacyjna)
    • Ograniczenie zasobów CPU (Procesor)
    • Ograniczenie przestrzeni dyskowej
    • Statystyki zużycia zasobów
  • Praca z migawkami

Instalacja LXD ^

Instalacja LXD w dystrybucjach Ubuntu ^

W dystrybucji Ubuntu 19.10 pakiet lxd ma translację na pakiet snap:

apt search lxd

lxd/eoan 1:0.7 all
  Pakiet przejściowy - lxd -> snap (lxd)

Oznacza to, że zostaną zainstalowane jednocześnie dwa pakiety, jeden systemowy, a drugi jako pakiet snap. Instalacja dwóch pakietów w systemie może stworzyć pewien problem, w którym pakiet systemowy może stać się osierocony, jeśli usuniemy pakiet snap menedżera pakietów snap.

Znajdź pakiet lxd w repozytorium snap można za pomocą następującego polecenia:

snap find lxd

Nazwa              Wersja         Podsumowanie
lxd               3.21           Menedżer kontenerów systemowych i API
lxd-demo-server   0+git.6d54658  Sesje demonstracyjne oprogramowania online za pomocą LXD
nova              ocata          Usługa obliczeniowa OpenStack (nova)
nova-hypervisor   ocata          Usługa obliczeniowa OpenStack - hipernadzorca KVM (nova)
distrobuilder     1.0            Budowniczy obrazów dla LXC i LXD
fabrica           0.1            Twórz snapy, po prostu wskazując formularz internetowy na...
satellite         0.1.2          Zaawansowana skalowalna platforma inteligencji open source

Uruchamiając polecenie list można upewnić się, że pakiet lxd jeszcze nie jest zainstalowany:

snap list

Nazwa  Wersja    Rev   Śledzenie  Wydawca   Notatki
core  16-2.43.3  8689  stabilna   canonical✓  core

Mimo że LXD jest pakietem snap, należy go zainstalować przez pakiet systemowy lxd, który utworzy w systemie odpowiednią grupę, niezbędne narzędzia w /usr/bin itd.

sudo apt update
sudo apt install lxd

Upewnijmy się, że pakiet jest zainstalowany jako pakiet snap:

snap list

Nazwa  Wersja    Rev    Śledzenie  Wydawca   Notatki
core  16-2.43.3  8689   stabilna   canonical✓  core
lxd   3.21       13474  stabilna/...   canonical✓  -

Instalacja LXD w dystrybucjach Arch Linux ^

Aby zainstalować pakiet LXD w systemie, należy uruchomić następujące polecenia, pierwsze — aktualizuje listę pakietów w systemie dostępnych w repozytorium, drugie — bezpośrednio zainstaluje pakiet:

sudo pacman -Syyu && sudo pacman -S lxd

Po zainstalowaniu pakietu, aby zarządzać LXD jako zwykły użytkownik, należy go dodać do grupy systemowej lxd:

sudo usermod -a -G lxd user1

Upewnijmy się, że użytkownik user1 został dodany do grupy lxd:

id -Gn user1

user1 adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd

Jeśli grupa lxd nie jest widoczna na liście, należy ponownie aktywować sesję użytkownika. W tym celu należy wylogować się i zalogować ponownie jako ten sam użytkownik.

Aktywujemy systemd uruchamianie usługi LXD przy starcie systemu:

sudo systemctl enable lxd

Uruchamiamy usługę:

sudo systemctl start lxd

Sprawdzamy status usługi:

sudo systemctl status lxd

Przechowywanie LXD (Storage) ^

Przed rozpoczęciem inicjalizacji musimy zrozumieć, jak logicznie zorganizowane jest przechowywanie w LXD.

Przechowywanie (Pamięć) składa się z jednego lub kilku Pula pamięci masowej które wykorzystuje jeden z obsługiwanych systemów plików, takich jak ZFS, BTRFS, LVM lub zwykłe katalogi. Każdy Pula pamięci masowej dzieli się na wolumeny (Storage Volume) które zawierają obrazy, kontenery lub dane do innych celów.

• Obrazy — to specjalnie skompilowane dystrybucje bez jądra Linux, dostępne z zewnętrznych źródeł
• Kontenery — to rozwinięte dystrybucje z obrazów, gotowe do eksploatacji
• Migawki — to zrzuty stanu kontenerów, do których można wracać

Do zarządzania magazynem w LXD służy polecenie lxc storage pomoc, którą można uzyskać, podając klucz — lxc storage --help

Następujące polecenie wyświetla na ekranie listę wszystkich Pula pamięci masowej w przechowywaniu LXD:

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAZWA | OPIS        | STEROWNIK |             ŹRÓDŁO             | UŻYWANY PRZEZ |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | /dev/loop1                     | 2       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | /var/lib/lxd/disks/ssdpool.img | 4       |
+---------+-------------+--------+--------------------------------+---------+

Aby wyświetlić listę wszystkich Storage Volume w wybranym Pula pamięci masowej służy polecenie lxc storage volume list:

lxc storage volume list hddpool

+-------+----------------------------------+-------------+---------+
| TYP   |          NAZWA                   | OPIS       | UŻYWANY PRZEZ |
+-------+----------------------------------+-------------+---------+
| obraz | ebd565585223487526ddb3607f515... |             | 1       |
+-------+----------------------------------+-------------+---------+

lxc storage volume list ssdpool

+-----------+----------------------------------+-------------+---------+
|   TYP    |            NAZWA                | OPIS       | UŻYWANY PRZEZ |
+-----------+----------------------------------+-------------+---------+
| kontener | alp3                             |             | 1       |
+-----------+----------------------------------+-------------+---------+
| kontener | jupyter                          |             | 1       |
+-----------+----------------------------------+-------------+---------+
| obraz     | ebd565585223487526ddb3607f515... |             | 1       |
+-----------+----------------------------------+-------------+---------+

Ponadto, jeśli dla Pula pamięci masowej przy tworzeniu została wybrana system plików BTRFS, to można uzyskać listę Storage Volume lub subwolumenów w interpretacji BTRFS za pomocą narzędzi tego systemu plików:

sudo btrfs subvolume list -p /var/lib/lxd/storage-pools/hddpool

ID 257 gen 818 parent 5 top level 5 path images/ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3

sudo btrfs subvolume list -p /var/lib/lxd/storage-pools/ssdpool

ID 257 gen 1820 parent 5 top level 5 path images/ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
ID 260 gen 1819 parent 5 top level 5 path containers/jupyter
ID 263 gen 1820 parent 5 top level 5 path containers/alp3

Inicjalizacja LXD ^

Przed utworzeniem i użyciem kontenerów należy wykonać ogólną inicjalizację LXD, która tworzy i konfiguruje sieć oraz magazyn. Można to zrobić ręcznie za pomocą standardowych poleceń klienta, które są dostępne w liście po wywołaniu polecenia lxc --help lub za pomocą kreatora inicjalizacji lxd init odpowiadając na kilka pytań.

Wybór systemu plików dla Storage Pool ^

Podczas inicjalizacji LXD zadawane jest kilka pytań, w tym określenie typu systemu plików dla domyślnego. Pula pamięci masowejDomyślnie wybierany jest system plików BTRFS. Nie będzie możliwe zmienienie na inny system plików po utworzeniu.Do wyboru systemu plików proponowana jest tabela porównawcza możliwości.:

Funkcja
Katalog
Btrfs
LVM
ZFS
CEPH

Optymalizowane przechowywanie obrazów
no
yes
yes
yes
yes

Optymalizowane tworzenie instancji
no
yes
yes
yes
yes

Optymalizowane tworzenie migawek
no
yes
yes
yes
yes

Optymalizowany transfer obrazów
no
yes
no
yes
yes

Optymalizowany transfer instancji
no
yes
no
yes
yes

Kopiowanie na zapis
no
yes
yes
yes
yes

Zarządzanie blokami
no
no
yes
no
yes

Natychmiastowe klonowanie
no
yes
yes
yes
yes

Sterownik magazynu używany wewnątrz kontenera
yes
yes
no
no
no

Odzyskiwanie z wcześniejszych migawek (nie najnowszych)
yes
yes
yes
no
yes

Limity przechowywania
tak(*)
yes
yes
yes
no

Inicjalizacja sieci i Storage Pool za pomocą kreatora ^

Następna komenda, którą omówimy, umożliwia skonfigurowanie podstawowych komponentów LXD poprzez odpowiedzi na proste pytania za pomocą kreatora inicjalizacji.

Uruchom komendę lxc init i wprowadź odpowiedzi na pytania po dwukropku, jak pokazano w poniższym przykładzie lub zmodyfikuj je zgodnie z własnymi warunkami:

lxd init

Czy chciałbyś użyć klastrowania LXD? (tak/nie) [domyślnie=nie]: 
Czy chcesz skonfigurować nową pulę pamięci masowej? (tak/nie) [domyślnie=tak]: 
Nazwa nowej puli pamięci masowej [domyślnie=domyślnie]: ssdpool         
Nazwa używanego zaplecza pamięci masowej (lvm, btrfs, dir) [domyślnie=btrfs]: 
Czy utworzyć nową pulę BTRFS? (tak/nie) [domyślnie=tak]: 
Czy chciałbyś użyć istniejącego urządzenia blokowego? (tak/nie) [domyślnie=nie]: 
Rozmiar nowego urządzenia loop (minimum 1 GB) [domyślnie=15 GB]: 10 GB
Czy chciałbyś połączyć się z serwerem MAAS? (tak/nie) [domyślnie=nie]: 
Czy chciałbyś utworzyć nowy lokalny mostek sieciowy? (tak/nie) [domyślnie=tak]: 
Jak ma nazywać się nowy mostek? [domyślnie=lxdbr0]: 
Jakie adresy IPv4 powinny być używane? (notacja CIDR, „auto” lub „none”) [domyślnie=auto]: 10.0.5.1/24
Czy chciałbyś, aby LXD NAT-ował ruch IPv4 na twoim mostku? [domyślnie=tak]: 
Jakie adresy IPv6 powinny być używane? (notacja CIDR, „auto” lub „none”) [domyślnie=auto]: none
Czy chciałbyś, aby LXD był dostępny w sieci? (tak/nie) [domyślnie=nie]: 
Czy chciałbyś, aby przestarzałe wersje obrazów były aktualizowane automatycznie? (tak/nie) [domyślnie=tak]: nie
Czy chciałbyś, aby wydrukowano YAML "lxd init" preseed? (tak/nie) [domyślnie=nie]: 

Tworzenie dodatkowego Storage Pool ^

W poprzednim kroku utworzyliśmy Pula pamięci masowej którego nadaliśmy nazwę ssdpool i plik, który znajduje się w moim systemie pod adresem /var/lib/lxd/disks/ssdpool.img. Ten adres systemu plików odpowiada fizycznemu dyskowi SSD w moim PC.

Następne kroki, aby lepiej zrozumieć, jaką rolę odgrywa Pula pamięci masowej w pamięci masowej, stworzymy drugi Pula pamięci masowej który fizycznie znajdować się będzie na innym typie dysku, na HDD. Problem polega na tym, że LXD nie pozwala na tworzenie Pula pamięci masowej poza adresem /var/lib/lxd/disks/ a nawet linki symboliczne nie będą działać, zobacz odpowiedź dewelopera. Obejdziemy to ograniczenie przy inicjalizacji/formacie Pula pamięci masowej podając wartość jako urządzenie blokowe zamiast ścieżki do pliku loopback, określając to w kluczu source.

A więc, przed utworzeniem Pula pamięci masowej Należy określić plik loopback lub istniejący podział w systemie plików, który będzie używany. W tym celu stworzymy i użyjemy pliku o ograniczonym rozmiarze 10 GB:

dd if=\/dev\/zero of=\/mnt\/work\/lxd\/hddpool.img bs=1MB count=10000

10000+0 records in
10000+0 records out
10000000000 bytes (10 GB, 9,3 GiB) copied, 38,4414 s, 260 MB\/s

Podłączymy plik loopback do wolnego urządzenia loopback:

sudo losetup --find --show \/mnt\/work\/lxd\/hddpool.img

\/dev\/loop1

Dzięki kluczowi --show wykonanie polecenia zwraca na ekran nazwę urządzenia, do którego został podłączony nasz plik loopback. W razie potrzeby możemy wyświetlić listę wszystkich zajętych urządzeń tego typu, aby upewnić się o poprawności naszych działań:

losetup -l

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                      DIO LOG-SEC
\/dev\/loop1         0      0         0  0 \/mnt\/work\/lxd\/hddpool.img        0     512
\/dev\/loop0         0      0         1  0 \/var\/lib\/lxd\/disks\/ssdpool.img   0     512

Z listy można zauważyć, że w urządzeniu /dev/loop1 jest podłączony plik loopback /mnt/work/lxd/hddpool.img, a w urządzeniu /dev/loop0 jest podłączony plik loopback /var/lib/lxd/disks/ssdpool.img które odpowiada domyślnemu Pula pamięci masowej.

Następne polecenie tworzy nowy Pula pamięci masowej w LXD na podstawie właśnie przygotowanego pliku loopback. LXD sformatuje plik loopback /mnt/work/lxd/hddpool.img w urządzeniu /dev/loop1 pod system plików BTRFS:

lxc storage create hddpool btrfs size=10GB source=\/dev\/loop1

Wyświetlimy listę wszystkich Pula pamięci masowej na ekranie:

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | \/dev\/loop1                     | 0       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | \/var\/lib\/lxd\/disks\/ssdpool.img | 0       |
+---------+-------------+--------+--------------------------------+---------+

Zwiększenie rozmiaru Storage Pool ^

Po utworzeniu Pula pamięci masowej, w razie potrzeby, można go rozszerzyć. Dla Pula pamięci masowej opartego na systemie plików BTRFS wykonaj następujące polecenia:

sudo truncate -s +5G \/mnt\/work\/lxd\/hddpool.img
sudo losetup -c \/dev\/loop1
sudo btrfs filesystem resize max \/var\/lib\/lxd\/storage-pools\/hddpool

Automatyczne wstawianie pliku loopback do slotu urządzenia loopback ^

Mamy jeden mały problem, po ponownym uruchomieniu systemu hosta, plik /mnt/work/lxd/hddpool.img "wyleci" z urządzenia /dev/loop1 i usługa LXD upadnie podczas uruchamiania, ponieważ nie zobaczy go w tym urządzeniu. Aby rozwiązać ten problem, należy stworzyć systemową usługę, która wstawi ten plik do urządzenia /dev/loop1 podczas uruchamiania systemu hosta.

Utworzymy unit plik typu service do /etc/systemd/system/ dla systemu inicjalizacji SystemD:

cat << EOF | sudo tee -a \/etc\/systemd\/system\/lxd-hddpool.service
[Unit]
Description=Losetup LXD Storage Pool (hddpool)
After=local-fs.target

[Service]
Type=oneshot
ExecStart=\/sbin\/losetup \/dev\/loop1 \/mnt\/work\/lxd\/hddpool.img
RemainAfterExit=true

[Install]
WantedBy=local-fs.target
EOF

Aktywujemy usługę:

sudo systemctl enable lxd-hddpool

Utworzono dowiązanie symboliczne /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

Po restarcie systemu hosta sprawdzamy status usługi:

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Załadowano: załadowano (/etc/systemd/system/lxd-hddpool.service; włączona; ustawienie producenta: wyłączone)
     Aktywny: aktywny (wyszedł) od śr 2020-04-08 03:43:53 MSK; 1min 37s temu
    Proces: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (kod=wyszedł, status=0/SUKCES)
   Główny PID: 711 (kod=wyszedł, status=0/SUKCES)

08 kwi 03:43:52 manjaro systemd[1]: Rozpoczęcie Losetup LXD Storage Pool (hddpool)...
08 kwi 03:43:53 manjaro systemd[1]: Zakończono Losetup LXD Storage Pool (hddpool).

Z wyników możemy upewnić się, że stan usługi wynosi active, mimo że wykonanie naszego skryptu z jednej komendy zakończyło się, pozwoliło nam to zrobić opcja RemainAfterExit=true.

Bezpieczeństwo. Uprawnienia kontenerów ^

Ponieważ wszystkie procesy kontenera są faktycznie wykonywane w izolacji w systemie gospodarza przy użyciu jego jądra, LXD oferuje dodatkowe zabezpieczenie dostępu procesów kontenera do systemu gospodarza poprzez przywilej procesów, gdzie:

• Przywilejowane kontenery to kontenery, w których procesy z UID i GID odpowiadają temu samemu właścicielowi, co w systemie gospodarza. Na przykład, proces uruchomiony w kontenerze z UID równym 0 ma te same prawa dostępu, co proces systemu gospodarza z UID równym 0. Innymi słowy, użytkownik root w kontenerze ma pełne prawa nie tylko w kontenerze, ale i w systemie gospodarza, jeśli uda mu się wyjść poza izolowaną przestrzeń nazw kontenera.

• Nieprzywilejowane kontenery to kontenery, w których procesy należą do właściciela UID i GID z numerami od 0 do 65535, ale dla systemu gospodarza właściciel jest maskowany przez dodany bit SubUID i SubGID odpowiednio. Na przykład, użytkownik z UID=0 w kontenerze będzie widoczny w systemie gospodarza jako SubUID + UID. To chroni system gospodarza, ponieważ jeśli jakikolwiek proces w kontenerze może wyjść z własnej izolowanej przestrzeni nazw, może wchodzić w interakcje z systemem gospodarza tylko jako proces z nieznanym, bardzo wysokim UID/GID.

Domyślnie nowo tworzone kontenery mają status nieprzywilejowany i dlatego musimy zdefiniować SubUID i SubGID.

Utwórzmy dwa pliki konfiguracyjne, w których ustawimy maskę dla SubUID i SubGID odpowiednio:

sudo touch /etc{/subuid,/subgid}
sudo usermod --add-subuids 1000000-1065535 root 
sudo usermod --add-subgids 1000000-1065535 root

Aby zastosować zmiany, serwis LXD musi zostać ponownie uruchomiony:

sudo systemctl restart lxd

Tworzenie wirtualnego przełącznika sieciowego ^

Ponieważ wcześniej zainicjowaliśmy sieć przy pomocy kreatora inicjalizacji lxd init i utworzyliśmy urządzenie sieciowe lxdbr0, w tej sekcji zapoznamy się jedynie z siecią w LXD oraz tym, jak stworzyć wirtualny przełącznik (mostek sieciowy) używając polecenia klienta.

Następujący schemat pokazuje, jak przełącznik (mostek sieciowy) łączy hosta i kontenery w sieć:

Kontenery mogą komunikować się w sieci z innymi kontenerami lub hostem, na którym te kontenery są uruchamiane. W tym celu należy połączyć wirtualne karty sieciowe kontenerów z wirtualnym przełącznikiem. Na początku utworzymy przełącznik, a interfejsy sieciowe kontenera zostaną połączone w następnych rozdziałach, gdy kontener zostanie utworzony.

Następujące polecenie tworzy przełącznik z podsiecią 10.0.5.0/24 i adresem IPv4 10.0.5.1/24, a także włącza ipv4.nat aby kontenery mogły uzyskiwać dostęp do internetu przez hosta za pomocą serwisu NAT:

lxc network create lxdbr0 ipv4.address=10.0.5.1/24 ipv4.nat=true ipv6.address=none

Sprawdzamy listę dostępnych urządzeń sieciowych LXD:

lxc network list

+--------+----------+---------+-------------+---------+
|  NAME  |   TYPE   | MANAGED | DESCRIPTION | USED BY |
+--------+----------+---------+-------------+---------+
| eno1   | physical | NO      |             | 0       |
+--------+----------+---------+-------------+---------+
| lxdbr0 | bridge   | YES     |             | 0       |
+--------+----------+---------+-------------+---------+

Ponadto, można upewnić się o utworzeniu urządzenia sieciowego za pomocą standardowego narzędzia dystrybucji Linux: ip link lub ip addr:

ip addr

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:ee:7b:5a:6b:44 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet6 fe80::9571:11f3:6e0c:c07b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: lxdbr0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c2:38:90:df:cb:59 brd ff:ff:ff:ff:ff:ff
    inet 10.0.5.1/24 scope global lxdbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::c038:90ff:fedf:cb59/64 scope link 
       valid_lft forever preferred_lft forever
5: veth3ddab174@if4:  mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
    link/ether ca:c3:5c:1d:22:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Profil konfiguracji ^

Każdy kontener w LXD ma swoją własną konfigurację i może ją rozszerzać przy pomocy globalnie zadeklarowanych konfiguracji, które nazywane są profile konfiguracji. Zastosowanie profili konfiguracji do kontenera ma model kaskadowy, co ilustruje poniższy przykład:

W tym przykładzie w systemie LXD utworzono trzy profile: default, hddpool i hostfs. Wszystkie trzy profile są stosowane do kontenera, który ma lokalną konfigurację (szara strefa). Profil default ma urządzenie root które ma parametr pool , więc ta funkcja skonfiguruje gniazdo z opcją ssdpool, ale dzięki kaskadowemu modelowi stosowania konfiguracji możemy zastosować dla kontenera profil hddpool które ma parametr pool nakłada ten sam parametr z profilu default i kontener otrzyma konfigurację urządzenia root z parametrem pool równym hddpool, a profil hostfs po prostu dodaje nowe urządzenie do kontenera.

Aby zobaczyć listę dostępnych profili konfiguracji, służy następujące polecenie:

lxc profile list

+---------+---------+
|  NAME   | USED BY |
+---------+---------+
| default | 1       |
+---------+---------+
| hddroot | 0       |
+---------+---------+
| ssdroot | 1       |
+---------+---------+

Pełną listę dostępnych poleceń do pracy z profilami można uzyskać, dodając klucz --help:

lxc profile --help

Opis:
  Zarządzaj profilami

Użycie:
  lxc profile [polecenie]

Dostępne polecenia:
  add         Dodaj profile do instancji
  assign      Przypisz zestawy profili do instancji
  copy        Skopiuj profile
  create      Utwórz profile
  delete      Usuń profile
  device      Zarządzaj urządzeniami instancji
  edit        Edytuj konfiguracje profili jako YAML
  get         Uzyskaj wartości dla kluczy konfiguracji profilu
  list        Wyświetl profile
  remove      Usuń profile z instancji
  rename      Zmień nazwę profili
  set         Ustaw klucze konfiguracji profilu
  show        Pokaż konfiguracje profili
  unset       Usuń ustawienia kluczy konfiguracji profilu

Edycja profilu ^

Profil konfiguracji domyślnie default nie ma konfiguracji karty sieciowej dla kontenera i wszystkie nowo tworzone kontenery nie mają sieci, dla nich należy tworzyć lokalne (dedykowane) urządzenia sieciowe oddzielnym poleceniem, ale możemy stworzyć w profilu konfiguracji globalne urządzenie sieciowe, które będzie współdzielone między wszystkimi kontenerami wykorzystującymi ten profil. Dzięki temu, zaraz po poleceniu utworzenia nowego kontenera będzie on miał sieć z dostępem do sieci. Przy tym, nie ma ograniczeń, zawsze możemy później stworzyć lokalne urządzenie sieciowe, jeśli zajdzie taka potrzeba.

Następujące polecenie doda do profilu konfiguracji urządzenie eth0 typ nic podłączanego do sieci lxdbr0:

lxc profile device add default eth0 nic network=lxdbr0 name=eth0

Ważne jest, aby zauważyć, że ponieważ faktycznie dodaliśmy urządzenie do profilu konfiguracji, jeśli w urządzeniu wskażemy statyczny adres IP, wszystkie kontenery, które będą stosować ten profil, będą dzieliły ten sam adres IP. Jeśli istnieje potrzeba stworzenia kontenera z dedykowanym statycznym adresem IP, należy stworzyć konfigurację urządzenia sieciowego na poziomie kontenera (lokalna konfiguracja) z parametrem adresu IP, a nie na poziomie profilu.

Sprawdźmy profil:

lxc profile show default

config: {}
description: Domyślny profil LXD
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: \/
    pool: ssdpool
    type: disk
name: default
used_by: []

W tym profilu możemy zobaczyć, że dla wszystkich nowo tworzonych kontenerów zostaną utworzone dwa urządzenia (devices):

• eth0 — Urządzenie typu nic połączone z przełącznikiem (mostem sieciowym) lxdbr0
• root — Urządzenie typu dysk które wykorzystuje pulę pamięci ssdpool

Tworzenie nowych profili ^

Aby skorzystać z wcześniej stworzonych Pula pamięci masowej kontenerów, stworzymy profil konfiguracji ssdroot w którym dodamy urządzenie typu dysk z punktem montażu / (root) wykorzystującym wcześniej stworzony Pula pamięci masowej — ssdpool:

lxc profile create ssdroot
lxc profile device add ssdroot root disk path=\/ pool=ssdpool

Podobnie, tworzymy urządzenie typu dysk, ale w tym przypadku wykorzystujące Pula pamięci masowej — hddpool:

lxc profile create hddroot
lxc profile device add hddroot root disk path=\/ pool=hddpool

Sprawdzamy profile konfiguracji:

lxc profile show ssdroot

config: {}
description: ""
devices:
  root:
    path: \/
    pool: ssdpool
    type: disk
name: ssdroot
used_by: []

lxc profile show hddroot

config: {}
description: ""
devices:
  root:
    path: \/
    pool: hddpool
    type: disk
name: hddroot
used_by: []

Repozytorium obrazów ^

Kontenery są tworzone z obrazów, które są specjalnie zbudowanymi dystrybucjami nieposiadającymi jądra Linux. Dlatego przed uruchomieniem kontenera muszą być one rozwinięte z tego obrazu. Źródłem obrazów jest lokalne repozytorium, do którego obrazy są ładowane z zewnętrznych repozytoriów.

Zdalne repozytoria obrazów ^

Domyślnie LXD jest skonfigurowany do pobierania obrazów z trzech zdalnych źródeł:

• ubuntu: (dla stabilnych obrazów Ubuntu)
• ubuntu-daily: (dla codziennych obrazów Ubuntu)
• do nazwy obrazu. Utworzenie kontenera na podstawie obrazu z repozytorium Ubuntu można wykonać w następujący sposób: (dla szeregu innych dystrybucji)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NAZWA     |                   URL                    | PUBLIC | STATIC |
+-----------------+------------------------------------------+--------+--------+
| images          | https://images.linuxcontainers.org       | TAK    | NIE     |
+-----------------+------------------------------------------+--------+--------+
| local (domyślny)| unix://                                  | NIE    | TAK     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | TAK    | TAK     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | TAK    | TAK     |
+-----------------+------------------------------------------+--------+--------+

Na przykład, repozytorium ubuntu: ma następujące obrazy:

lxc image -c dasut list ubuntu: | head -n 11

+----------------------------------------------+--------------+----------+------------+
|                   OPIS                      | ARCHITEKTURA |   ROZMIAR|   TYP     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | KONTENER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | KONTENER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | KONTENER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | KONTENER  |
+----------------------------------------------+--------------+----------+------------+

Aby wyświetlić ograniczoną liczbę kolumn, użyliśmy opcji -c z parametrami dasut, a także ograniczyliśmy długość listy komendą head.

Dostępna jest filtracja dla wyświetlenia listy obrazów. Następująca komenda wyświetli listę wszystkich dostępnych architektur dystrybucji AlpineLinux:

lxc image -c ldast list images:alpine/3.11

+------------------------------+--------------------------------------+--------------+
|            ALIAS             |             OPIS                    | ARCHITEKTURA |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11 (3 inne)         | Alpine 3.11 amd64 (20200220_13:00)   | x86_64       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/arm64 (1 inne)   | Alpine 3.11 arm64 (20200220_13:00)   | aarch64      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/armhf (1 inne)   | Alpine 3.11 armhf (20200220_13:00)   | armv7l       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/i386 (1 inne)    | Alpine 3.11 i386 (20200220_13:01)    | i686         |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/ppc64el (1 inne) | Alpine 3.11 ppc64el (20200220_13:00) | ppc64le      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/s390x (1 inne)   | Alpine 3.11 s390x (20200220_13:00)   | s390x        |
+------------------------------+--------------------------------------+--------------+

Lokalne repozytorium obrazów ^

Aby rozpocząć korzystanie z kontenera, należy dodać obraz z globalnego repozytorium do lokalnego local:. Obecnie lokalne repozytorium jest puste, co potwierdzi nam polecenie lxc image list. Jeśli nie wskazano repozytorium, domyślnie używane będzie lokalne repozytorium — list lxc image list local:+-------+-------------+--------+-------------+--------------+------+------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | +-------+-------------+--------+-------------+--------------+------+------+ local:

Zarządzanie obrazami w repozytorium odbywa się za pomocą następujących metod:

lxc image

Zespół
Opis

Zarządzaj aliasami obrazów alias
Kopiowanie obrazów między serwerami

Zarządzaj aliasami obrazów copy
Usuwanie obrazów

Zarządzaj aliasami obrazów usuń
Edycja właściwości obrazu

Zarządzaj aliasami obrazów edit
Eksportowanie i pobieranie obrazów

Zarządzaj aliasami obrazów export
Importowanie obrazów do magazynu obrazów

Zarządzaj aliasami obrazów importować
Wyświetlanie przydatnych informacji o obrazach

Zarządzaj aliasami obrazów info
Wyświetlanie obrazów

Zarządzaj aliasami obrazów list
odśwież

Zarządzaj aliasami obrazów Odśwież obrazy
pokaż

Zarządzaj aliasami obrazów Pokaż właściwości obrazu
Kopiujemy obraz do lokalnego repozytorium z globalnego

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3Obraz skopiowany pomyślnie! do nazwy obrazu. Utworzenie kontenera na podstawie obrazu z repozytorium Ubuntu można wykonać w następujący sposób::

Wyświetlimy listę wszystkich obrazów dostępnych obecnie w lokalnym repozytorium

lxc image -c lfdatsu list local:+---------+--------------+------------------------------------+--------------+ | ALIAS | FINGERPRINT | DESCRIPTION | ARCHITECTURE | +---------+--------------+------------------------------------+--------------+ | alpine3 | 73a3093d4a5c | Alpine 3.11 amd64 (20200220_13:00) | x86_64 | +---------+--------------+------------------------------------+--------------+ local::

Oprócz trybu interaktywnego, LXD obsługuje również tryb nieinteraktywny instalacji konfiguracji, polegający na tym, że konfiguracja jest określana w postaci pliku YAML, specjalnego formatu, który pozwala na ustawienie całej konfiguracji za jednym razem, omijając wykonanie wielu interaktywnych poleceń, które zostały omówione powyżej w tym artykule, w tym konfigurację sieci, tworzenie profili konfiguracji itd. Nie będziemy tu omawiać tej dziedziny, możesz zapoznać się z tym samodzielnie.

Konfiguracja LXD ^

Następne interaktywne polecenie w dokumentacji..

lxc config które omówimy, pozwala na ustawienie konfiguracji. Na przykład, aby pobrane obrazy z lokalnego repozytorium nie były automatycznie aktualizowane z globalnych repozytoriów, możemy włączyć to zachowanie następującym poleceniem: lxc config set images.auto_update_cached=false

Aby utworzyć kontener, używane jest polecenie

Tworzenie i zarządzanie kontenerem ^

w którym podawane są wartości lxc init repozytorium:obraz a następnie żądany identyfikator kontenera. Repozytorium może być określone jako lokalne. as local local: i każdy globalny. Jeśli repozytorium nie jest określone, domyślnie do wyszukiwania obrazu używane jest lokalne repozytorium. Jeśli obraz jest wskazany z globalnego repozytorium, najpierw obraz zostanie załadowany do lokalnego repozytorium, a następnie wykorzystany do utworzenia kontenera.

Wykonajmy następującą komendę, aby utworzyć nasz pierwszy kontener:

lxc init alpine3 alp --storage=hddpool --profile=domyślny --profile=hddroot

Rozłożymy na części klucze komendy, które tutaj używamy:

• alpine3 — Określa alias (pseudonim) dla obrazu, który wcześniej został załadowany do lokalnego repozytorium. Gdyby alias nie został utworzony dla tego obrazu, zawsze można odwołać się do obrazu po jego Odcisk który jest wyświetlany w tabeli.
• alp — Przydziela identyfikator dla kontenera
• --storage — Ten klucz wskazuje, w jakim Pula pamięci masowej zostanie utworzony kontener
• --profile — Te klucze stosują kaskadowo do kontenera konfigurację z wcześniej utworzonych profili konfiguracji

Uruchamiamy kontener, który zaczyna uruchamiać system init dystrybucji:

lxc start alp

Można również skorzystać z komendy lxc launch która umożliwia połączenie komend lxc init i lxc start w jedną operację.

Sprawdzamy stan kontenera:

lxc list -c ns46tb
+------+---------+------------------+------+-----------+--------------+
| NAME |  STATE  |       IPV4       | IPV6 |   TYPE    | STORAGE POOL |
+------+---------+------------------+------+-----------+--------------+
| alp  | RUNNING | 10.0.5.46 (eth0) |      | KONTENER | hddpool      |
+------+---------+------------------+------+-----------+--------------+

Sprawdzamy konfigurację kontenera:

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: vethb1fe71d8
  volatile.eth0.hwaddr: 00:16:3e:5f:73:3e
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: \/
    pool: hddpool
    type: disk
ephemeral: false
profiles:
- domyślny
- hddroot
stateful: false
description: ""

W sekcji profile możemy upewnić się, że ten kontener korzysta z dwóch profili konfiguracji — default i hddroot. W sekcji urządzenia możemy odkryć tylko jedno urządzenie, ponieważ urządzenie sieciowe zostało utworzone na poziomie profilu default. Aby zobaczyć wszystkie urządzenia używane przez kontener, należy dodać klucz --expanded:

lxc config show alp --expanded

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: vethb1fe71d8
  volatile.eth0.hwaddr: 00:16:3e:5f:73:3e
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: \
    pool: hddpool
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

Ustawienie statycznego adresu IP ^

Jeśli spróbujemy przypisać adres IP do urządzenia sieciowego eth0 poleceniem lxc config device set alp przeznaczonego do konfiguracji kontenera, otrzymamy błąd informujący, że urządzenie nie istnieje, ponieważ urządzenie eth0 używane przez kontener należy do profilu default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Możemy oczywiście ustawić statyczny adres IP dla eth0 urządzenia w profilu, ale będzie on wspólny dla wszystkich kontenerów, które korzystają z tego profilu. Dlatego dodamy dedykowane urządzenie dla kontenera:

lxc config device add alp eth0 nic name=eth0 nictype=bridged parent=lxdbr0 ipv4.address=10.0.5.5

Następnie należy zrestartować kontener:

lxc restart alp

Jeśli teraz spojrzymy na konfigurację kontenera, nie musimy stosować opcji --expanded aby zobaczyć urządzenie sieciowe eth0, ponieważ stworzyliśmy go na poziomie kontenera i przejęło ono to samo urządzenie z profilu default:

lxc config show alp

architektura: x86_64
konfiguracja:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: veth2a1dc59d
  volatile.eth0.hwaddr: 00:16:3e:0e:e2:71
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    ipv4.address: 10.0.5.5
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: \/
    pool: hddpool
    type: disk
ephemeral: false
profile:
- domyślny
- hddroot
stateful: false
description: ""

Usunięcie kontenera ^

Aby usunąć kontener, użyj polecenia lxc delete, ale przed usunięciem kontenera, należy go zatrzymać za pomocą polecenia lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAZWA | STAN    |       IPV4        | IPV6 |   TYP     | ZRZUTY    |
+------+---------+-------------------+------+-----------+-----------+
| alp  | ZATRZYMANE | 10.0.5.10 (eth0)  |      | KONTENER  | 0         |
+------+---------+-------------------+------+-----------+-----------+

Po upewnieniu się, że stan kontenera to STOPPED, można go usunąć z Pula pamięci masowej:

lxc delete alp

Dostęp do kontenera ^

Aby wykonać polecenia w kontenerze bezpośrednio, omijając połączenia sieciowe, użyj polecenia lxc exec które wykonuje polecenia w kontenerze bez uruchamiania powłoki systemowej. Jeśli musisz wykonać polecenie w powłoce, stosując wzorce powłoki, takie jak zmienne, przekierowania plików (pipe) itd., musisz wyraźnie uruchomić powłokę i przekazać polecenie jako argument, na przykład:

lxc exec alp -- \/bin\/sh -c "echo $HOME"

W poleceniu użyto znaku specjalnego do eskapowania dla znaku specjalnego $ aby zmienna $HOME nie była interpretowana na maszynie gospodarza, lecz tylko wewnątrz kontenera.

Możliwe jest także uruchomienie interaktywnego trybu powłoki, a następnie zakończenie sesji za pomocą klawisza skrótu CTRL+D:

lxc exec alp -- \/bin\/sh

Zarządzanie zasobami kontenera ^

W LXD można zarządzać zasobami kontenera za pomocą specjalnego zestawu konfiguracji. Pełną listę parametrów konfiguracyjnych kontenera można znaleźć w dokumentacji..

Ograniczenie zasobów RAM (Pamięć operacyjna) ^

Parametr limits.memory ogranicza objętość RAM dostępną dla kontenera. Jako wartość podaje się liczbę oraz jeden z dostępnych sufiksów.

Ustawmy kontenerowi limit na objętość RAM równy 256 MB:

lxc config set alp limits.memory 256MB

Istnieją także inne parametry do ograniczenia pamięci:

• limits.memory.enforce
• limits.memory.hugepages
• limits.memory.swap
• limits.memory.swap.priority

Zespół lxc config show pozwala na wyświetlenie całej konfiguracji kontenera, w tym zastosowanych ograniczeń zasobów:

lxc config show alp

architektura: x86_64
konfiguracja:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200220_13:00)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200220_13:00"
  image.type: squashfs
  limits.memory: 256MB
  volatile.base_image: 73a3093d4a5ce0148fd84b95369b3fbecd19a537ddfd2e2d20caa2eef0e8fd60
  volatile.eth0.host_name: veth75b6df07
  volatile.eth0.hwaddr: 00:16:3e:a1:e7:46
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

Ograniczenie zasobów CPU (Procesor) ^

Aby ograniczyć zasoby CPU, istnieje kilka typów ograniczeń:

• limit.cpu — przypisanie kontenera do jednego lub kilku rdzeni CPU
• limits.cpu.allowance — zarządza albo kwotami planowania CFS, kiedy upłynął czas, albo uniwersalnym mechanizmem współdzielenia zasobów CPU, kiedy upłynęła procentowa wartość
• limits.cpu.priority — priorytet planowania, gdy dla wielu instancji współdzieli się zestaw procesorów, a przypisano ten sam procent procesorów

lxc config set alp limits.cpu.allowance 40%

lxc config show alp

architektura: x86_64
konfiguracja:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200220_13:00)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200220_13:00"
  image.type: squashfs
  limits.cpu.allowance: 40%
  limits.memory: 256MB
  volatile.base_image: 73a3093d4a5ce0148fd84b95369b3fbecd19a537ddfd2e2d20caa2eef0e8fd60
  volatile.eth0.host_name: veth75b6df07
  volatile.eth0.hwaddr: 00:16:3e:a1:e7:46
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

Ograniczenie przestrzeni dyskowej ^

Oprócz ograniczeń takich jak limits.read, limits.write możemy także ograniczyć ilość miejsca na dysku zajmowanego przez kontener (działa tylko z ZFS lub BTRFS):

lxc config device set alp root size=2GB

Po ustawieniu, w parametrze devices.root.size możemy upewnić się, że ograniczenie zostało ustawione:

lxc config show alp
...
devices:
  root:
    path: \/
    pool: hddpool
    size: 2GB
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

Aby zobaczyć wykorzystanie przydziału na dysk, możemy uzyskać z polecenia lxc info:

lxc info alp
...
Zasoby:
  Procesy: 5
  Użycie dysku:
    root: 1.05GB
  Użycie CPU:
    Użycie CPU (w sekundach): 1
  Użycie pamięci:
    Pamięć (aktualna): 5.46MB
  Użycie sieci:
    eth0:
      Odebrane bajty: 802B
      Wysłane bajty: 1.59kB
      Odebrane pakiety: 4
      Wysłane pakiety: 14
    lo:
      Odebrane bajty: 0B
      Wysłane bajty: 0B
      Odebrane pakiety: 0
      Wysłane pakiety: 0

Mimo że ustawiliśmy ograniczenie dla głównego urządzenia kontenera na 2 GB, narzędzia systemowe takie jak df nie będą widziały tego ograniczenia. Przeprowadzimy mały test, aby zobaczyć, jak to działa.

Stwórzmy 2 nowe identyczne kontenery w tym samym Pula pamięci masowej (hddpool):

lxc init alpine3 alp1 --storage=hddpool --profile=default --profile=hddroot
lxc init alpine3 alp2 --storage=hddpool --profile=default --profile=hddroot

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAZWA | STAN | IPV4 | IPV6 | TYP | ZDJĘCIA |
+------+---------+------------------+------+-----------+-----------+
| alp1 | DZIAŁA | 10.0.5.46 (eth0) | | KONTENER | 0 |
+------+---------+------------------+------+-----------+-----------+
| alp2 | DZIAŁA | 10.0.5.30 (eth0) | | KONTENER | 0 |
+------+---------+------------------+------+-----------+-----------+

W jednym z kontenerów stwórzmy plik o rozmiarze 1 GB:

lxc exec alp1 -- dd if=\/dev\/urandom of=file.img bs=1M count=1000

Upewnimy się, że plik został stworzony:

lxc exec alp1 -- ls -lh
total 1000M  
-rw-r--r--    1 root     root     1000.0M Mar 27 10:16 file.img

Jeśli sprawdzimy drugi kontener, aby zweryfikować istnienie pliku w tym samym miejscu, plik ten nie będzie obecny, co jest zgodne z oczekiwaniami, ponieważ kontenery są tworzone w swoich własnych Storage Volume w tym samym Pula pamięci masowej:

lxc exec alp2 -- ls -lh
total 0

Ale porównajmy wartości, które daje df w jednym i drugim kontenerze:

lxc exec alp1 -- df -hT
System plików           Typ            Rozmiar      Używane Dostępne Użycie% Zamontowane na
\/dev\/loop1           btrfs           9.3G   1016.4M      7.8G  11% \/
...

lxc exec alp2 -- df -hT
System plików           Typ            Rozmiar      Używane Dostępne Użycie% Zamontowane na
\/dev\/loop1           btrfs           9.3G   1016.4M      7.8G  11% \/
...

Urządzenie /dev/loop1 zamontowany jako główny system plików jest Pula pamięci masowej który te kontenery używają, więc dzielą jego objętość po połowie.

Statystyki zużycia zasobów ^

Aby zobaczyć statystyki zużycia zasobów kontenera, można użyć polecenia:

lxc info alp

Nazwa: alp
Lokalizacja: none
Zdalny: unix:\/\/
Architektura: x86_64
Utworzono: 2020\/04\/08 18:05 UTC
Status: Działa
Typ: kontener
Profile: default, hddroot
Pid: 19219
Ips:
  eth0: inet    10.0.5.5        veth2a1dc59d
  eth0: inet6   fe80::216:3eff:fe0e:e271        veth2a1dc59d
  lo:   inet    127.0.0.1
  lo:   inet6   ::1
Zasoby:
  Procesy: 5
  Użycie dysku:
    root: 495.62kB
  Użycie CPU:
    Użycie CPU (w sekundach): 1
  Użycie pamięci:
    Pamięć (aktualnie): 4.79MB
  Użycie sieci:
    eth0:
      Bajty odebrane: 730B
      Bajty wysłane: 1.59kB
      Pakiety odebrane: 3
      Pakiety wysłane: 14
    lo:
      Bajty odebrane: 0B
      Bajty wysłane: 0B
      Pakiety odebrane: 0
      Pakiety wysłane: 0

Praca z migawkami ^

W LXD istnieje możliwość tworzenia migawków oraz przywracania stanu kontenera z tych migawek.

Aby stworzyć migawkę, wykonaj następujące polecenie:

lxc snapshot alp snapshot1

Polecenie lxc snapshot nie ma opcji list, dlatego, aby zobaczyć listę migawków, należy użyć polecenia, które wyświetla ogólne informacje o kontenerze:

lxc info alp
...
...
Zrzuty:
  snapshot1 (utworzony 2020/04/08 18:18 UTC) (bezustawny)

Można przywrócić kontener ze zrzutu poleceniem lxc restore podając kontener, dla którego ma być wykonane przywrócenie oraz alias zrzutu:

lxc restore alp snapshot1

Następne polecenie służy do usunięcia zrzutu. Zwróć uwagę, że składnia tego polecenia różni się od pozostałych, tutaj należy podać ukośnik po nazwie kontenera. Jeśli pominiesz ukośnik, polecenie usuwania zrzutu zostanie zinterpretowane jako polecenie usunięcia kontenera!

lxc delete alp/snapshot1

W powyższym przykładzie omówiliśmy tzw. zrzuty bezstanowe. W LXD istnieje również inny typ zrzutów — zrzuty stanowe, które zachowują aktualny stan wszystkich procesów w kontenerze. Z zrzutami stanowymi związanych jest wiele interesujących i przydatnych funkcji.

Co jeszcze? ^

• Dla programistów Pythona dostępny jest moduł PyLXD który zapewnia API dla LXD

AKTUALIZACJA 10.04.2020 15:00: Dodałem nawigację

Źródło: habr.com