Podstawowe cechy LXD - Linuxowe systemy kontenerowe

Podstawowe cechy LXD - Linuxowe systemy kontenerowe

LXD to systemowy menedżer kontenerów nowej generacji, jak twierdzi źródło. Oferuje interfejs użytkownika podobny do maszyn wirtualnych, ale zamiast tego wykorzystuje kontenery Linux.

Rdzeń LXD to uprzywilejowany demon (usługa działająca z uprawnieniami roota), który udostępnia API REST poprzez lokalne gniazdo unixowe, a także poprzez sieć, jeśli zainstalowana jest odpowiednia konfiguracja. Klienci, tacy jak narzędzie wiersza poleceń dostarczane z LXD, wysyłają żądania za pośrednictwem tego interfejsu API REST. Oznacza to, że niezależnie od tego, czy uzyskujesz dostęp do hosta lokalnego, czy zdalnego, wszystko działa tak samo.

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 niedawnej implementacji w najnowszych wersjach LXD obsługi maszyn wirtualnych QEMU równolegle z kontenerami. Zamiast tego nauczymy się tylko podstaw zarządzania kontenerami – konfigurowania pul pamięci, sieci, uruchamiania kontenera, stosowania limitów zasobów i korzystania z migawek, aby uzyskać podstawową wiedzę na temat LXD i używać kontenerów w systemie Linux.

Pełne informacje można znaleźć w oficjalnym źródle:

Nawigacja

Instalacja LXD ^

Instalowanie LXD na dystrybucjach Ubuntu ^

W pakiecie dystrybucyjnym Ubuntu 19.10 lxd ma włączoną transmisję pakiet snapowy:

apt search lxd

lxd/eoan 1:0.7 all
  Transitional package - lxd -> snap (lxd)

Oznacza to, że jednocześnie zostaną zainstalowane dwa pakiety, jeden jako pakiet systemowy, a drugi jako pakiet snap. Zainstalowanie dwóch pakietów w systemie może spowodować problem, w wyniku którego pakiet systemowy może zostać osierocony, jeśli pakiet snap zostanie usunięty przez menedżera pakietów snap.

Znajdź paczkę lxd w repozytorium snapów możesz użyć następującego polecenia:

snap find lxd

Name             Version        Summary
lxd              3.21           System container manager and API
lxd-demo-server  0+git.6d54658  Online software demo sessions using LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Image builder for LXC and LXD
fabrica          0.1            Build snaps by simply pointing a web form to...
satellite        0.1.2          Advanced scalable Open source intelligence platform

Uruchamiając polecenie list możesz mieć pewność, że pakiet lxd jeszcze nie zainstalowany:

snap list

Name  Version    Rev   Tracking  Publisher   Notes
core  16-2.43.3  8689  stable    canonical✓  core

Pomimo tego, że LXD jest pakietem zatrzaskowym, należy go zainstalować poprzez pakiet systemowy lxd, który utworzy odpowiednią grupę w systemie, w której znajdują się niezbędne narzędzia /usr/bin itd.

sudo apt update
sudo apt install lxd

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

snap list

Name  Version    Rev    Tracking  Publisher   Notes
core  16-2.43.3  8689   stable    canonical✓  core
lxd   3.21       13474  stable/…  canonical✓  -

Instalowanie LXD na dystrybucjach Arch Linux ^

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

sudo pacman -Syyu && sudo pacman -S lxd

Po zainstalowaniu pakietu, aby móc zarządzać LXD przez zwykłego użytkownika, należy go dodać do grupy systemowej lxd:

sudo usermod -a -G lxd user1

Upewnijmy się, że użytkownik user1 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 widoczny na liście, należy ponownie aktywować sesję użytkownika. Aby to zrobić, musisz się wylogować i zalogować pod tym samym użytkownikiem.

Aktywuj w systemd ładowanie usługi LXD przy starcie systemu:

sudo systemctl enable lxd

Uruchommy usługę:

sudo systemctl start lxd

Sprawdzanie statusu usługi:

sudo systemctl status lxd

Pamięć masowa LXD (przechowywanie) ^

Zanim rozpocznie się inicjalizacja, musimy zrozumieć, jak logicznie zorganizowana jest pamięć w LXD.

Składowanie (Magazynowanie) składa się z z jednego lub więcej Pula pamięci który wykorzystuje jeden z obsługiwanych systemów plików, taki jak ZFS, BTRFS, LVM lub zwykłe katalogi. Każdy Pula pamięci dzieli się na objętości (Pojemność pamięci), które zawierają obrazy, kontenery lub dane do innych celów.

  • Obrazy - są to specjalnie przygotowane dystrybucje bez jądra Linuksa i dostępne z zewnętrznych źródeł
  • pojemniki - są to dystrybucje wdrożone z obrazów, gotowe do użycia
  • Migawki - są to migawki stanu kontenerów, do których możesz wrócić

Podstawowe cechy LXD - Linuxowe systemy kontenerowe

Aby zarządzać pamięcią w LXD, użyj polecenia lxc storage certyfikat, który można uzyskać podając klucz - lxc storage --help

Poniższe polecenie wyświetla listę wszystkich Pula pamięci w pamięci LXD:

lxc storage list

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

Aby wyświetlić listę wszystkich Pojemność pamięci w wybranym Pula pamięci służy drużynie lxc storage volume list:

lxc storage volume list hddpool

+-------+----------------------------------+-------------+---------+
| TYPE  |          NAME                    | DESCRIPTION | USED BY |
+-------+----------------------------------+-------------+---------+
| image | ebd565585223487526ddb3607f515... |             | 1       |
+-------+----------------------------------+-------------+---------+

lxc storage volume list ssdpool

+-----------+----------------------------------+-------------+---------+
|   TYPE    |            NAME                  | DESCRIPTION | USED BY |
+-----------+----------------------------------+-------------+---------+
| container | alp3                             |             | 1       |
+-----------+----------------------------------+-------------+---------+
| container | jupyter                          |             | 1       |
+-----------+----------------------------------+-------------+---------+
| image     | ebd565585223487526ddb3607f515... |             | 1       |
+-----------+----------------------------------+-------------+---------+

Również, jeśli dla Pula pamięci Podczas tworzenia wybrano system plików BTRFS, a następnie uzyskaj listę Pojemność pamięci lub podwoluminy w interpretacji BTRFS możesz skorzystać z zestawu 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

Inicjowanie LXD ^

Przed utworzeniem i użyciem kontenerów należy przeprowadzić ogólną inicjalizację LXD, która tworzy i konfiguruje sieć i pamięć masową. Można to zrobić ręcznie przy użyciu standardowych poleceń klienta dostępnych na liście, wywołując polecenie lxc --help lub korzystając z kreatora inicjalizacji lxd init odpowiadając na kilka pytań.

Wybieranie systemu plików dla puli pamięci ^

Podczas inicjalizacji LXD zadaje kilka pytań, w tym określa domyślny typ systemu plików Pula pamięci. Domyślnie wybrany jest dla niego system plików BTRFS. Po utworzeniu nie będzie możliwości zmiany na inny FS. Sugeruje się wybranie FS tabela porównawcza funkcji:

Cecha
Informator
Btrfs
LVM
ZFS
CEPH

Zoptymalizowane przechowywanie obrazu
Nie
tak
tak
tak
tak

Zoptymalizowane tworzenie instancji
Nie
tak
tak
tak
tak

Zoptymalizowane tworzenie migawek
Nie
tak
tak
tak
tak

Zoptymalizowany transfer obrazu
Nie
tak
Nie
tak
tak

Zoptymalizowany transfer instancji
Nie
tak
Nie
tak
tak

Kopiuj na zapis
Nie
tak
tak
tak
tak

Oparty na blokach
Nie
Nie
tak
Nie
tak

Natychmiastowe klonowanie
Nie
tak
tak
tak
tak

Sterownik pamięci masowej, którego można używać w kontenerze
tak
tak
Nie
Nie
Nie

Przywróć ze starszych migawek (nie najnowszych)
tak
tak
tak
Nie
tak

Limity przechowywania
Tak(*)
tak
tak
tak
Nie

Inicjowanie sieci i puli pamięci za pomocą kreatora ^

Następne polecenie, któremu się przyjrzymy, sugeruje ustawienie głównych komponentów LXD poprzez udzielenie odpowiedzi na proste pytania za pomocą kreatora inicjalizacji.

Uruchom polecenie lxc init i wpisz odpowiedzi na pytania po dwukropku, jak pokazano w poniższym przykładzie lub zmień je w zależności od swoich warunków:

lxd init

Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: ssdpool         
Name of the storage backend to use (lvm, btrfs, dir) [default=btrfs]: 
Create a new BTRFS pool? (yes/no) [default=yes]: 
Would you like to use an existing block device? (yes/no) [default=no]: 
Size in GB of the new loop device (1GB minimum) [default=15GB]: 10GB
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 10.0.5.1/24
Would you like LXD to NAT IPv4 traffic on your bridge? [default=yes]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none
Would you like LXD to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] no
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 

Tworzenie dodatkowej puli pamięci ^

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

Poniższe działania, aby poszerzyć zrozumienie roli, jaką odgrywa Pula pamięci w repozytorium utworzymy drugie Pula pamięci który będzie fizycznie zlokalizowany na dysku innego typu, HDD. Problem w tym, że LXD nie pozwala na tworzenie Pula pamięci poza adresem /var/lib/lxd/disks/ i nawet dowiązania symboliczne nie będą działać, zobacz odpowiedź dewelopera. Możemy ominąć to ograniczenie podczas inicjalizacji/formatowania Pula pamięci poprzez określenie wartości jako urządzenia blokowego zamiast ścieżki do pliku pętli zwrotnej poprzez określenie tego w kluczu source.

A więc przed utworzeniem Pula pamięci musisz zdefiniować plik pętli zwrotnej lub istniejącą partycję w systemie plików, z której będzie korzystał. Aby to zrobić, utworzymy i wykorzystamy plik, którego rozmiar ograniczymy do 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łączmy plik pętli zwrotnej do wolnego urządzenia pętli zwrotnej:

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

/dev/loop1

Dzięki kluczowi --show wykonanie polecenia powoduje powrót na ekran nazwy urządzenia, do którego podłączony jest nasz plik pętli zwrotnej. W razie potrzeby możemy wyświetlić listę wszystkich zajętych urządzeń tego typu, aby mieć pewność, że nasze działania są prawidłowe:

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żesz dowiedzieć się, że urządzenie ma /dev/loop1 dołączony plik pętli zwrotnej /mnt/work/lxd/hddpool.imgi w urządzeniu /dev/loop0 dołączony plik pętli zwrotnej /var/lib/lxd/disks/ssdpool.img co odpowiada wartości domyślnej Pula pamięci.

Poniższe polecenie tworzy nowe Pula pamięci w LXD w oparciu o plik pętli zwrotnej, który właśnie przygotowaliśmy. LXD sformatuje plik pętli zwrotnej /mnt/work/lxd/hddpool.img w urządzeniu /dev/loop1 dla systemu plików BTRFS:

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

Wyświetlmy listę wszystkich Pula pamięci na ekran:

lxc storage list

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

Zwiększanie rozmiaru puli pamięci ^

Po stworzeniu Pula pamięciw razie potrzeby można go rozbudować. Dla Pula pamięci w oparciu o system plików BTRFS uruchom 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 pętli zwrotnej do gniazda urządzenia pętli zwrotnej ^

Mamy jeden mały problem, podczas ponownego uruchamiania systemu hosta, plik /mnt/work/lxd/hddpool.img „wyleci” z urządzenia /dev/loop1 a usługa LXD ulegnie awarii podczas ładowania, ponieważ nie zobaczy jej na tym urządzeniu. Aby rozwiązać ten problem należy utworzyć usługę systemową, która wstawi ten plik do urządzenia /dev/loop1 podczas uruchamiania systemu hosta.

stwórzmy jednostka Typ pliku usługa в /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

Aktywuj usługę:

sudo systemctl enable lxd-hddpool

Created symlink /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

Po ponownym uruchomieniu systemu hosta sprawdzamy status usługi:

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Loaded: loaded (/etc/systemd/system/lxd-hddpool.service; enabled; vendor preset: disabled)
     Active: active (exited) since Wed 2020-04-08 03:43:53 MSK; 1min 37s ago
    Process: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (code=exited, status=0/SUCCESS)
   Main PID: 711 (code=exited, status=0/SUCCESS)

апр 08 03:43:52 manjaro systemd[1]: Starting Losetup LXD Storage Pool (hddpool)...
апр 08 03:43:53 manjaro systemd[1]: Finished Losetup LXD Storage Pool (hddpool).

Na podstawie danych wyjściowych możemy sprawdzić, czy stan usługi to aktywny, pomimo tego, że wykonanie naszego skryptu z jednego polecenia zostało zakończone, opcja nam to umożliwiła RemainAfterExit=true.

Bezpieczeństwo. Przywileje kontenerowe ^

Ponieważ wszystkie procesy kontenerowe faktycznie działają w izolacji w systemie hosta przy użyciu jądra, aby jeszcze bardziej chronić dostęp procesów kontenerowych do systemu hosta, LXD oferuje przywileje procesów, gdzie:

  • Uprzywilejowane kontenery - są to kontenery, w których procesy z UID i GID odpowiadają temu samemu właścicielowi, co w systemie hosta. Na przykład proces działający w kontenerze z UID równym 0 ma takie same prawa dostępu, jak proces w systemie hosta z UID równym 0. Innymi słowy, użytkownik root w kontenerze ma wszystkie prawa nie tylko do kontenerze, ale także w systemie hosta, jeśli może wyjść poza izolowaną przestrzeń nazw kontenera.

  • Nieuprzywilejowane kontenery - są to kontenery, w których procesy należą do właściciela o UID i GID o numerze od 0 do 65535, ale dla systemu hosta właściciel jest maskowany za pomocą dodanych odpowiednio bitów SubUID i SubGID. Na przykład użytkownik z UID=0 w kontenerze będzie widoczny w systemie hosta jako SubUID + UID. Chroni to system hosta, ponieważ jeśli jakikolwiek proces w kontenerze zdoła uciec ze swojej izolowanej przestrzeni nazw, może komunikować się z systemem hosta jedynie jako proces o nieznanym, bardzo wysokim UID/GID.

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

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

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

Aby zastosować zmiany należy zrestartować usługę LXD:

sudo systemctl restart lxd

Tworzenie przełącznika sieci wirtualnej ^

Ponieważ wcześniej zainicjowaliśmy sieć za pomocą kreatora inicjalizacji lxd init i utworzyłem urządzenie sieciowe lxdbr0, to w tej sekcji po prostu zapoznamy się z siecią w LXD i tym, jak utworzyć wirtualny przełącznik (most) za pomocą polecenia klienta.

Poniższy diagram ilustruje sposób, w jaki przełącznik (most) łączy hosta i kontenery z siecią:

Podstawowe cechy LXD - Linuxowe systemy kontenerowe

Kontenery mogą komunikować się za pośrednictwem sieci z innymi kontenerami lub hostem, na którym te kontenery są obsługiwane. W tym celu należy połączyć wirtualne karty sieciowe kontenerów z wirtualnym przełącznikiem. Najpierw utworzymy przełącznik, a interfejsy sieciowe kontenera zostaną połączone w kolejnych rozdziałach, już po utworzeniu samego kontenera.

Poniższe polecenie tworzy przełącznik z podsiecią 10.0.5.0/24 i adres IPv4 10.0.5.1/24, a także obejmuje ipv4.nat aby kontenery mogły uzyskać dostęp do Internetu za pośrednictwem hosta korzystającego z usługi NAT:

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

Sprawdzanie listy urządzeń sieciowych dostępnych w LXD:

lxc network list

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

Możesz także sprawdzić, czy urządzenie sieciowe zostało utworzone za pomocą standardowego narzędzia dystrybucji Linuksa - ip link lub ip addr:

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 konfiguracyjny ^

Każdy kontener w LXD ma swoją własną konfigurację i może ją rozszerzyć o globalnie zadeklarowane konfiguracje tzw profile konfiguracyjne. Stosowanie profili konfiguracyjnych do kontenera ma model kaskadowy, co ilustruje poniższy przykład:

Podstawowe cechy LXD - Linuxowe systemy kontenerowe

W tym przykładzie zostały utworzone trzy profile w systemie LXD: default, hddpool и hostfs. Wszystkie trzy profile są stosowane do kontenera, który ma konfigurację lokalną (szary obszar). Profil default ma urządzenie root który ma parametr pool równa się ssdpool, ale dzięki modelowi aplikacji konfiguracji kaskadowej możemy zastosować profil do kontenera hddpool który ma parametr pool zastąpi ten sam parametr z profilu default a kontener otrzyma konfigurację urządzenia root z parametrem pool równy hddpooli profil hostfs po prostu dodaje nowe urządzenie do kontenera.

Aby wyświetlić listę dostępnych profili konfiguracyjnych, użyj następującego polecenia:

lxc profile list

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

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

lxc profile --help

Description:
  Manage profiles

Usage:
  lxc profile [command]

Available Commands:
  add         Add profiles to instances
  assign      Assign sets of profiles to instances
  copy        Copy profiles
  create      Create profiles
  delete      Delete profiles
  device      Manage instance devices
  edit        Edit profile configurations as YAML
  get         Get values for profile configuration keys
  list        List profiles
  remove      Remove profiles from instances
  rename      Rename profiles
  set         Set profile configuration keys
  show        Show profile configurations
  unset       Unset profile configuration keys

Edycja profilu ^

Domyślny profil konfiguracyjny default nie ma konfiguracji karty sieciowej dla kontenera i wszystkie nowo utworzone kontenery nie mają sieci, dla nich konieczne jest utworzenie lokalnych (dedykowanych) urządzeń sieciowych osobnym poleceniem, ale możemy w konfiguracji utworzyć globalne urządzenie sieciowe profil, który będzie współdzielony pomiędzy wszystkimi kontenerami korzystającymi z tego profilu. Dzięki temu zaraz po wydaniu polecenia utworzenia nowego kontenera będą mieli sieć z dostępem do sieci. Jednocześnie nie ma żadnych ograniczeń, zawsze, jeśli zajdzie taka potrzeba, zawsze możemy później utworzyć urządzenie sieci lokalnej.

Poniższe polecenie doda urządzenie do profilu konfiguracyjnego eth0 typ nic podłączony do sieci lxdbr0:

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

Warto zauważyć, że skoro faktycznie dodaliśmy urządzenie do profilu konfiguracyjnego, to jeśli w urządzeniu określimy statyczny adres IP, to wszystkie kontenery, które będą korzystać z tego profilu, będą miały ten sam adres IP. Jeżeli istnieje potrzeba utworzenia kontenera z przydzielonym dla kontenera statycznym adresem IP, wówczas konfigurację urządzenia sieciowego należy utworzyć na poziomie kontenera (konfiguracja lokalna) z parametrem adresu IP, a nie na poziomie profilu.

Sprawdźmy profil:

lxc profile show default

config: {}
description: Default LXD profile
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: /
    pool: ssdpool
    type: disk
name: default
used_by: []

W tym profilu widzimy, że dla wszystkich nowo utworzonych kontenerów zostaną utworzone dwa urządzenia:

  • eth0 - Rodzaj urządzenia nic podłączony do przełącznika (mostek sieciowy) lxdbr0
  • root - Rodzaj urządzenia disk który korzysta z puli pamięci ssdpool

Tworzenie nowych profili ^

Aby skorzystać z wcześniej utworzonego Pula pamięci kontenerów, utwórz profil konfiguracyjny ssdroot w którym dodamy urządzenie takie jak disk z punktem mocowania / (root) przy użyciu wcześniej utworzonego pliku Pula pamięci - ssdpool:

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

Podobnie tworzymy urządzenie takie jak disk, ale w tym przypadku używając Pula pamięci - hddpool:

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

Sprawdzanie profili konfiguracyjnych:

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 złożonymi dystrybucjami, które nie mają jądra Linuksa. Dlatego przed uruchomieniem kontenera należy go wdrożyć z tego obrazu. Źródłem obrazów jest lokalne repozytorium, do którego pobierane są obrazy z repozytoriów zewnętrznych.

Zdalne repozytoria obrazów ^

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

  • Ubuntu: (dla stabilnych obrazów Ubuntu)
  • ubuntu-dayly: (dla codziennych obrazów Ubuntu)
  • zdjęcia: (dla wielu innych dystrybucji)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NAME       |                   URL                    | PUBLIC | STATIC |
+-----------------+------------------------------------------+--------+--------+
| images          | https://images.linuxcontainers.org       | YES    | NO     |
+-----------------+------------------------------------------+--------+--------+
| local (default) | unix://                                  | NO     | YES    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | YES    | YES    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | YES    | YES    |
+-----------------+------------------------------------------+--------+--------+

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

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

+----------------------------------------------+--------------+----------+------------+
|                   DESCRIPTION                | ARCHITECTURE |   SIZE   |   TYPE     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+

Aby wyświetlić ograniczoną liczbę kolumn skorzystaliśmy z opcji -c z parametrami dasut, a także ograniczył długość listy za pomocą polecenia head.

Aby wyświetlić listę obrazów, dostępne jest filtrowanie. Poniższe polecenie wyświetli listę wszystkich dostępnych architektur dystrybucji AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Lokalne repozytorium obrazów ^

Aby rozpocząć korzystanie z kontenera należy dodać obraz z repozytorium globalnego do lokalnego local:. Teraz lokalne repozytorium jest puste, polecenie się o to upewni lxc image list. Jeśli metoda list nie określaj repozytorium, wówczas domyślnie zostanie użyte repozytorium lokalne - local:

lxc image list local:

+-------+-------------+--------+-------------+--------------+------+------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE |
+-------+-------------+--------+-------------+--------------+------+------+

Obrazy w repozytorium zarządzane są przy użyciu następujących metod:

Zespół
Opis

obraz lxc alias
Zarządzaj aliasami obrazów

obraz lxc kopia
Kopiuj obrazy pomiędzy serwerami

obraz lxc usunąć
Usuń obrazy

obraz lxc edit
Edytuj właściwości obrazu

obraz lxc eksport
Eksportuj i pobieraj obrazy

obraz lxc importować
Importuj obrazy do magazynu obrazów

obraz lxc Informacje
Pokaż przydatne informacje o obrazach

obraz lxc podstęp
Lista obrazów

obraz lxc Odśwież
Odśwież obrazy

obraz lxc pokazać
Pokaż właściwości obrazu

Skopiuj obraz do repozytorium lokalnego z repozytorium globalnego images::

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3

Image copied successfully!

Wyświetlmy listę wszystkich obrazów aktualnie dostępnych w lokalnym repozytorium local::

lxc image -c lfdatsu list local:

+---------+--------------+------------------------------------+--------------+
|  ALIAS  | FINGERPRINT  |            DESCRIPTION             | ARCHITECTURE |
+---------+--------------+------------------------------------+--------------+
| alpine3 | 73a3093d4a5c | Alpine 3.11 amd64 (20200220_13:00) | x86_64       |
+---------+--------------+------------------------------------+--------------+

Konfiguracja LXD ^

Oprócz trybu interaktywnego LXD obsługuje także nieinteraktywny tryb instalacji konfiguracji, ma to miejsce wtedy, gdy konfiguracja jest określona w postaci pliku YAML, specjalnego formatu, który pozwala na zainstalowanie całej konfiguracji na raz, z pominięciem wykonywania wielu interaktywnych poleceń omówionych powyżej w tym artykule, w tym konfiguracji sieci, tworzenia profili konfiguracyjnych itp. Nie będziemy tutaj omawiać tego obszaru, możesz to sprawdzić samodzielnie. w dokumentacji.

Następne interaktywne polecenie lxc config którym się przyjrzymy, pozwala ustawić konfigurację. Na przykład, aby mieć pewność, że obrazy pobrane do lokalnego repozytorium nie zostaną automatycznie zaktualizowane z repozytoriów globalnych, możemy włączyć to zachowanie za pomocą następującego polecenia:

lxc config set images.auto_update_cached=false

Tworzenie i zarządzanie kontenerem ^

Aby utworzyć kontener użyj polecenia lxc init do których przekazywane są wartości репозиторий:образ a następnie żądany identyfikator kontenera. Repozytorium można określić jako lokalne local: tak samo jak każdy globalny. Jeśli repozytorium nie zostało określone, domyślnie do wyszukiwania obrazu używane jest repozytorium lokalne. Jeżeli obraz zostanie podany z repozytorium globalnego, to obraz zostanie najpierw pobrany do repozytorium lokalnego, a następnie wykorzystany do utworzenia kontenera.

Uruchommy następujące polecenie, aby utworzyć nasz pierwszy kontener:

lxc init alpine3 alp --storage=hddpool --profile=default --profile=hddroot

Przyjrzyjmy się klawiszom poleceń, których tutaj używamy w kolejności:

  • alpine3 — Określono alias (alias) dla obrazu, który został wcześniej przesłany do lokalnego repozytorium. Jeśli dla tego obrazu nie utworzono aliasu, zawsze możesz odwołać się do obrazu po jego aliasie Odcisk palca co jest widoczne w tabeli.
  • alp — Ustawia identyfikator kontenera
  • --storage — Ten klawisz wskazuje, w którym Pula pamięci zostanie utworzony kontener
  • --profile — Te klucze kaskadowo stosują konfigurację z wcześniej utworzonych profili konfiguracyjnych do kontenera

Uruchamiamy kontener, który rozpoczyna uruchamianie systemu init dystrybucji:

lxc start alp

Możesz także użyć polecenia lxc launch co pozwala łączyć zespoły lxc init и lxc start w jednej operacji.

Sprawdzanie stanu kontenera:

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

Sprawdzanie konfiguracji 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:
- default
- hddroot
stateful: false
description: ""

W dziale profiles możemy się upewnić, że ten kontener korzysta z dwóch profili konfiguracyjnych − default и hddroot. W sekcji devices możemy wykryć 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: ""

Ustawianie statycznego adresu IP ^

Jeśli spróbujemy ustawić adres IP dla urządzenia sieciowego eth0 według zespołu lxc config device set alp przeznaczonych do konfiguracji kontenera, wówczas otrzymamy błąd, który zgłosi, że urządzenie nie istnieje, ponieważ urządzenie eth0 którego używa 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ądzeń w profilu, ale będzie taki sam dla wszystkich kontenerów, które będą korzystać z tego profilu. Dodajmy zatem urządzenie dedykowane do kontenera:

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

Następnie musisz ponownie uruchomić kontener:

lxc restart alp

Jeśli teraz przyjrzymy się konfiguracji kontenera, nie będziemy musieli korzystać z tej opcji --expanded aby zobaczyć urządzenie sieciowe eth0, ponieważ utworzyliśmy go na poziomie kontenera i został on przeniesiony kaskadowo na to samo urządzenie z profilu default:

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: 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
profiles:
- default
- hddroot
stateful: false
description: ""

Demontaż pojemnika ^

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

+------+---------+-------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4        | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPED | 10.0.5.10 (eth0)  |      | CONTAINER | 0         |
+------+---------+-------------------+------+-----------+-----------+

Po sprawdzeniu, że stan kontenera stał się ZATRZYMANY, można go usunąć Pula pamięci:

lxc delete alp

Dostęp do kontenera ^

Aby wykonać polecenia bezpośrednio w kontenerze, z pominięciem połączeń sieciowych, użyj polecenia lxc exec który wykonuje polecenia w kontenerze bez uruchamiania powłoki systemowej. Jeśli chcesz wykonać polecenie w powłoce przy użyciu wzorców powłoki, takich jak zmienne, przekierowania plików (potok) itp., musisz jawnie uruchomić powłokę i przekazać polecenie jako klucz, na przykład:

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

W poleceniu użyto specjalnego znaku ucieczki dla specjalnego charakteru $ tak, że zmienna $HOME nie został zinterpretowany na komputerze hosta, ale został zinterpretowany tylko wewnątrz kontenera.

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

lxc exec alp -- /bin/sh

Zarządzanie zasobami kontenerowymi ^

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

Ograniczenie zasobów pamięci RAM ^

Parametr limits.memory ogranicza ilość pamięci RAM dostępnej dla kontenera. Wartość jest liczbą i jedną z dostępne przyrostki.

Ustawmy limit pamięci RAM kontenera na 256 MB:

lxc config set alp limits.memory 256MB

Istnieją również inne parametry ograniczające pamięć:

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

Zespół lxc config show pozwala wyświetlić całą konfigurację kontenera, łącznie z zastosowanym limitem zasobów, który został ustawiony:

lxc config show alp

architecture: x86_64
config:
  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: ""

Limit zasobów procesora ^

Istnieje kilka sposobów ograniczenia zasobów procesora. rodzaje ograniczeń:

  • limit.cpu - wiąże kontener z jednym lub większą liczbą rdzeni procesora
  • limits.cpu.allowance - zarządza przydziałami harmonogramu CFS po upływie limitu czasu lub uniwersalnym mechanizmem współdzielenia zasobów procesora po upływie określonego procentu
  • limits.cpu.priority - priorytet programu planującego, gdy wiele instancji współdzielących zestaw procesorów ma przypisany ten sam procent procesorów

lxc config set alp limits.cpu.allowance 40%

lxc config show alp

architecture: x86_64
config:
  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 miejsca na dysku ^

Oprócz ograniczeń takich 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 instalacji w parametrze devices.root.size Możemy zweryfikować ustawiony limit:

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

Aby wyświetlić wykorzystane przydziały dysku, możemy uzyskać z polecenia lxc info:

lxc info alp
...
Resources:
  Processes: 5
  Disk usage:
    root: 1.05GB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 5.46MB
  Network usage:
    eth0:
      Bytes received: 802B
      Bytes sent: 1.59kB
      Packets received: 4
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

Pomimo tego, że ustawiliśmy limit urządzenia root kontenera na 2 GB, narzędzia systemowe takie jak df nie zobaczy tego ograniczenia. Aby to zrobić, przeprowadzimy mały test i dowiemy się, jak to działa.

Stwórzmy 2 nowe identyczne pojemniki w tym samym Pula pamięci (dysk twardy):

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

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | RUNNING | 10.0.5.46 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | RUNNING | 10.0.5.30 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+

Utwórzmy plik o wielkości 1 GB w jednym z kontenerów:

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

Upewnijmy się, że plik został utworzony:

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

Jeśli zajrzymy do drugiego kontenera, sprawdzimy, czy w tej samej lokalizacji znajduje się plik, to tego pliku tam nie będzie, czego można się spodziewać, ponieważ kontenery są tworzone we własnym zakresie Pojemność pamięci w tym samym Pula pamięci:

lxc exec alp2 -- ls -lh
total 0

Ale porównajmy wartości, które wytwarza df na jednym i drugim pojemniku:

lxc exec alp1 -- df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
/dev/loop1           btrfs           9.3G   1016.4M      7.8G  11% /
...

lxc exec alp2 -- df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
/dev/loop1           btrfs           9.3G   1016.4M      7.8G  11% /
...

Urządzenie /dev/loop1 zamontowany tak samo, jak partycja główna Pula pamięci z którego korzystają te pojemniki, dlatego dzielą swoją objętość pomiędzy dwa.

Statystyki zużycia zasobów ^

Możesz wyświetlić statystyki zużycia zasobów dla kontenera za pomocą polecenia:

lxc info alp

Name: alp
Location: none
Remote: unix://
Architecture: x86_64
Created: 2020/04/08 18:05 UTC
Status: Running
Type: container
Profiles: 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
Resources:
  Processes: 5
  Disk usage:
    root: 495.62kB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 4.79MB
  Network usage:
    eth0:
      Bytes received: 730B
      Bytes sent: 1.59kB
      Packets received: 3
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

Praca z migawkami ^

LXD ma możliwość tworzenia migawek i przywracania z nich stanu kontenera.

Aby utworzyć migawkę, uruchom następujące polecenie:

lxc snapshot alp snapshot1

Drużyna lxc snapshot brak dostępnego klucza listdlatego też, aby wyświetlić listę snapshotów należy skorzystać z polecenia wyświetlającego ogólne informacje o kontenerze:

lxc info alp
...
...
Snapshots:
  snapshot1 (taken at 2020/04/08 18:18 UTC) (stateless)

Możesz przywrócić kontener z migawki za pomocą polecenia lxc restore określenie kontenera, dla którego zostanie wykonane przywrócenie oraz aliasu migawki:

lxc restore alp snapshot1

Poniższe polecenie służy do usuwania migawki. Należy pamiętać, że składnia poleceń nie jest podobna do wszystkich pozostałych; tutaj należy podać ukośnik po nazwie kontenera. Jeśli pominięto ukośnik, polecenie usunięcia migawki zostanie zinterpretowane jako polecenie usunięcia kontenera!

lxc delete alp/snapshot1

W powyższym przykładzie przyjrzeliśmy się tak zwanym migawkom bezstanowym. LXD posiada inny rodzaj snapshotów – stanowy, który zapisuje aktualny stan wszystkich procesów w kontenerze. Istnieje wiele interesujących i przydatnych funkcji związanych ze stanowymi migawkami.

Co jeszcze? ^

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

AKTUALIZACJA 10.04.2020 15:00: Dodano nawigację

Źródło: www.habr.com

Dodaj komentarz