LXD е следващото поколение системен контейнерен мениджър, така се казва източник. Той предлага потребителски интерфейс, подобен на виртуалните машини, но вместо това използва Linux контейнери.

LXD ядро е привилегирован демон (услуга, работеща с root права), която предоставя REST API чрез локален unix сокет, както и през мрежата, ако е инсталирана подходящата конфигурация. Клиентите, като инструмента за команден ред, предоставен с LXD, правят заявки чрез този REST API. Това означава, че независимо дали имате достъп до локален хост или отдалечен хост, всичко работи по същия начин.

В тази статия няма да се спираме подробно на концепциите на LXD; няма да разглеждаме всички налични възможности, описани в документацията, включително скорошното внедряване в най-новите версии на LXD на поддръжка за виртуални машини QEMU паралелно с контейнери. Вместо това ще научим само основите на управлението на контейнери – настройка на пулове за съхранение, работа в мрежа, работа с контейнер, прилагане на ограничения на ресурсите и как да използвате моментни снимки, за да можете да получите основно разбиране за LXD и да използвате контейнери в Linux.

За пълна информация, моля, вижте официалния източник:

• Уебсайт на разработчика
• Документация
• форум

Навигация

• Монтаж LXD
  • Инсталиране на LXD в дистрибуции на Ubuntu
  • Инсталиране на LXD в дистрибуции на Arch Linux
• Съхранение LXD (съхранение)
• Инициализиране на LXD
  • Избор на файлова система за Storage Pool
  • Инициализиране на мрежата и пула за съхранение с помощта на съветника
  • Създаване на допълнителен пул за съхранение
    • Увеличаване на размера на пула за съхранение
    • Автоматично вмъкване на loopback файл в слот за loopback устройство
  • Безопасност. Привилегии на контейнера
  • Създаване на виртуален мрежов комутатор
  • Конфигурационен профил
    • Редактиране на вашия профил
    • Създаване на нови профили
  • Хранилище за изображения
    • Отдалечени хранилища за изображения
    • Локално хранилище за изображения
  • LXD конфигурация
• Създаване и управление на контейнер
  • Задаване на статичен IP адрес
  • Премахване на контейнер
  • Достъп до контейнер
  • Управление на ресурсите на контейнера
    • Ограничение на RAM ресурса
    • Ограничение на процесорния ресурс
    • Ограничение на дисковото пространство
    • Статистика на потреблението на ресурси
  • Работа с моментни снимки

Монтаж LXD ^

Инсталиране на LXD в дистрибуции на Ubuntu ^

В пакета за разпространение на Ubuntu 19.10 lxd има предаване на модулен пакет:

apt search lxd

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

Това означава, че два пакета ще бъдат инсталирани наведнъж, единият като системен пакет, а другият като модулен пакет. Инсталирането на два пакета в една система може да създаде известен проблем, при който системният пакет може да остане сирак, ако модулът за модулиране на пакети бъде премахнат от мениджъра на пакети за модулиране.

Намерете пакет lxd в snap хранилището можете да използвате следната команда:

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

Чрез изпълнение на командата list можете да се уверите, че пакетът lxd все още не е инсталирано:

snap list

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

Въпреки факта, че LXD е модулен пакет, той трябва да бъде инсталиран чрез системния пакет lxd, което ще създаде съответната група в системата, необходимите помощни програми в /usr/bin и т.н.

sudo apt update
sudo apt install lxd

Нека се уверим, че пакетът е инсталиран като модулен пакет:

snap list

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

Инсталиране на LXD в дистрибуции на Arch Linux ^

За да инсталирате пакета LXD в системата, трябва да изпълните следните команди, първата ще актуализира списъка с пакети в системата, налични в хранилището, втората ще инсталира директно пакета:

sudo pacman -Syyu && sudo pacman -S lxd

След инсталиране на пакета, за да управлявате LXD от обикновен потребител, той трябва да бъде добавен към системната група lxd:

sudo usermod -a -G lxd user1

Нека се уверим, че потребителят user1 добавен към групата lxd:

id -Gn user1

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

Ако групата lxd не се вижда в списъка, тогава трябва отново да активирате потребителската сесия. За да направите това, трябва да излезете и да влезете под същия потребител.

Активирайте в systemd зареждане на услугата LXD при стартиране на системата:

sudo systemctl enable lxd

Да започнем услугата:

sudo systemctl start lxd

Проверка на състоянието на услугата:

sudo systemctl status lxd

Съхранение LXD (съхранение) ^

Преди да започне инициализацията, трябва да разберем как е логически подредено съхранението в LXD.

Съхранение (Съхранение) се състои от от един или повече Басейн за съхранение който използва една от поддържаните файлови системи като ZFS, BTRFS, LVM или обикновени директории. Всеки Басейн за съхранение е разделен на томове (Обем на съхранение), които съдържат изображения, контейнери или данни за други цели.

• образи - това са специално събрани дистрибуции без Linux ядрото и достъпни от външни източници
• Контейнери - това са разгърнати дистрибуции от изображения, готови за употреба
• Моментни снимки - това са моментни снимки на състоянието на контейнерите, към които можете да се върнете

За да управлявате съхранението в LXD, използвайте командата lxc storage сертификат, за който можете да получите, като посочите ключа - lxc storage --help

Следващата команда показва списък с всички Басейн за съхранение в LXD хранилище:

lxc storage list

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

За да видите списък с всички Обем на съхранение в избраното Басейн за съхранение служи на отбора 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       |
+-----------+----------------------------------+-------------+---------+

Освен това, ако за Басейн за съхранение При създаването е избрана файловата система BTRFS, след което вземете списък Обем на съхранение или подкубове в интерпретацията на BTRFS можете да използвате инструментариума на тази файлова система:

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

Инициализиране на LXD ^

Преди да създадете и използвате контейнери, трябва да извършите обща LXD инициализация, която създава и конфигурира мрежата и хранилището. Това може да се направи ръчно с помощта на стандартни клиентски команди, които са налични в списъка чрез извикване на командата lxc --help или с помощта на съветника за инициализация lxd init отговаряйки на няколко въпроса.

Избор на файлова система за Storage Pool ^

По време на инициализацията LXD задава няколко въпроса, включително определяне на типа на файловата система по подразбиране Басейн за съхранение. По подразбиране за него е избрана файловата система BTRFS. Ще бъде невъзможно да се промени на друг FS след създаването. Препоръчва се да изберете FS таблица за сравнение на характеристиките:

Особеност
указател
Btrfs
LVM
ZFS
CEPH

Оптимизирано съхранение на изображения
Не.
да
да
да
да

Оптимизирано създаване на инстанция
Не.
да
да
да
да

Оптимизирано създаване на моментна снимка
Не.
да
да
да
да

Оптимизирано прехвърляне на изображения
Не.
да
Не.
да
да

Оптимизирано прехвърляне на екземпляри
Не.
да
Не.
да
да

копиране при запис
Не.
да
да
да
да

Базиран на блокове
Не.
Не.
да
Не.
да

Незабавно клониране
Не.
да
да
да
да

Драйвер за съхранение, използваем в контейнер
да
да
Не.
Не.
Не.

Възстановяване от по-стари моментни снимки (не най-новите)
да
да
да
Не.
да

Квоти за съхранение
да(*)
да
да
да
Не.

Инициализиране на мрежата и пула за съхранение с помощта на съветника ^

Следващата команда, която ще разгледаме, предлага настройка на основните компоненти на LXD чрез отговаряне на прости въпроси с помощта на съветника за инициализация.

Изпълни команда lxc init и въведете отговорите на въпросите след двоеточието, както е показано в примера по-долу, или ги променете според вашите условия:

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]: 

Създаване на допълнителен пул за съхранение ^

В предишната стъпка, която създадохме Басейн за съхранение на което е дадено името ssdpool и чийто файл се намира в моята система на адрес /var/lib/lxd/disks/ssdpool.img. Този адрес на файловата система съответства на физическото SSD устройство в моя компютър.

Следните действия, за да се разшири разбирането на ролята, която играе Басейн за съхранение в хранилището ще създадем второ Басейн за съхранение който ще бъде физически разположен на различен тип диск, HDD. Проблемът е, че LXD не ви позволява да създавате Басейн за съхранение извън адреса /var/lib/lxd/disks/ и дори символните връзки няма да работят, вижте отговора на разработчика. Можем да заобиколим това ограничение по време на инициализация/форматиране Басейн за съхранение като посочите стойността като блоково устройство вместо пътя към файла за обратна връзка, като посочите това в ключа source.

Така че, преди да създадете Басейн за съхранение трябва да дефинирате loopback файл или съществуващ дял на вашата файлова система, който ще използва. За да направим това, ще създадем и използваме файл, чийто размер ще ограничим до 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

Нека свържем loopback файла към безплатно устройство за loopback:

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

/dev/loop1

Благодарение на ключа --show изпълнението на командата връща на екрана името на устройството, към което е свързан нашият loopback файл. Ако е необходимо, можем да покажем списък с всички заети устройства от този тип, за да сме сигурни, че действията ни са правилни:

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

От списъка можете да разберете, че устройството има /dev/loop1 включен loopback файл /mnt/work/lxd/hddpool.img, и в устройството /dev/loop0 включен loopback файл /var/lib/lxd/disks/ssdpool.img което съответства на по подразбиране Басейн за съхранение.

Следващата команда създава нова Басейн за съхранение в LXD въз основа на loopback файла, който току-що подготвихме. LXD ще форматира loopback файла /mnt/work/lxd/hddpool.img в устройството /dev/loop1 за файловата система BTRFS:

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

Нека покажем списък с всички Басейн за съхранение към екрана:

lxc storage list

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

Увеличаване на размера на пула за съхранение ^

След създаването Басейн за съхранение, при необходимост може да се разшири. За Басейн за съхранение въз основа на файловата система BTRFS, изпълнете следните команди:

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

Автоматично вмъкване на loopback файл в слот за loopback устройство ^

Имаме един малък проблем, при рестартиране на хост системата, файлът /mnt/work/lxd/hddpool.img ще "излети" от устройството /dev/loop1 и услугата LXD ще се срине при зареждане, защото няма да я види в това устройство. За да разрешите този проблем, трябва да създадете системна услуга, която ще вмъкне този файл в устройството /dev/loop1 когато хост системата се стартира.

Да творим единица тип файл обслужване в /etc/systemd/system/ за системата за инициализация на 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

Активирайте услугата:

sudo systemctl enable lxd-hddpool

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

След рестартиране на хост системата проверяваме състоянието на услугата:

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).

От изхода можем да проверим дали състоянието на услугата е активен, въпреки факта, че изпълнението на нашия скрипт от една команда беше завършено, опцията ни позволи да направим това RemainAfterExit=true.

Безопасност. Привилегии на контейнера ^

Тъй като всички контейнерни процеси действително се изпълняват изолирано в хост системата, използвайки нейното ядро, за допълнителна защита на достъпа на контейнерни процеси до хост системата, LXD предлага привилегия на процеса, където:

• Привилегировани контейнери - това са контейнери, в които процеси с UID и GID съответстват на същия собственик като на хост системата. Например, процес, работещ в контейнер с UID 0, има всички същите права за достъп като процес в хост системата с UID 0. С други думи, root потребителят в контейнера има всички права не само в контейнера, но също и на хост системата, ако може да излезе извън изолираното пространство на имената на контейнера.

• Непривилегировани контейнери - това са контейнери, в които процесите принадлежат на собственика на UID и GID с номер от 0 до 65535, но за хост системата собственикът е маскиран с помощта на добавените съответно SubUID и SubGID битове. Например, потребител с UID=0 в контейнер ще бъде видян в хост системата като SubUID + UID. Това защитава хост системата, тъй като ако някой процес в контейнера е в състояние да избегне своето изолирано пространство от имена, той може да комуникира с хост системата само като процес с неизвестен, много висок UID/GID.

По подразбиране новосъздадените контейнери имат непривилегирован статус и затова трябва да дефинираме SubUID и SubGID.

Нека създадем два конфигурационни файла, в които ще зададем маската съответно за SubUID и SubGID:

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

За да приложите промените, услугата LXD трябва да се рестартира:

sudo systemctl restart lxd

Създаване на виртуален мрежов комутатор ^

Тъй като преди това инициализирахме мрежата с помощта на съветника за инициализация lxd init и създаде мрежово устройство lxdbr0, тогава в този раздел просто ще се запознаем с работата в мрежа в LXD и как да създадем виртуален комутатор (мост) с помощта на командата client.

Следващата диаграма демонстрира как комутатор (мост) свързва хоста и контейнерите в мрежа:

Контейнерите могат да комуникират чрез мрежа с други контейнери или хоста, на който се обслужват тези контейнери. За да направите това, трябва да свържете виртуалните мрежови карти на контейнерите с виртуален комутатор. Първо ще създадем превключвател и мрежовите интерфейси на контейнера ще бъдат свързани в следващите глави, след като самият контейнер бъде създаден.

Следната команда създава комутатор с подмрежа 10.0.5.0/24 и IPv4 адрес 10.0.5.1/24, а също така включва ipv4.nat така че контейнерите да имат достъп до интернет през хоста, използвайки услугата NAT:

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

Проверка на списъка с мрежови устройства, налични в LXD:

lxc network list

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

Можете също така да проверите дали е създадено мрежово устройство с помощта на стандартния инструмент на дистрибуцията на Linux - ip link или 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

Конфигурационен профил ^

Всеки контейнер в LXD има своя собствена конфигурация и може да я разшири с глобално декларирани конфигурации, наречени конфигурационни профили. Прилагането на конфигурационни профили към контейнер има каскаден модел, следният пример демонстрира това:

В този пример са създадени три профила в системата LXD: default, hddpool и hostfs. И трите профила се прилагат към контейнер, който има локална конфигурация (сива зона). Профил default има устройство root който има параметър pool е равно на ssdpool, но благодарение на модела на приложение за каскадна конфигурация, можем да приложим профил към контейнера hddpool който има параметър pool ще замени същия параметър от профила default и контейнерът ще получи конфигурацията на устройството root с параметър pool равен hddpool, и профила hostfs просто добавя ново устройство към контейнера.

За да видите списъка с налични профили за конфигурация, използвайте следната команда:

lxc profile list

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

Пълен списък с налични команди за работа с профил можете да получите чрез добавяне на ключа --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

Редактиране на вашия профил ^

Конфигурационен профил по подразбиране default няма конфигурация на мрежова карта за контейнера и всички новосъздадени контейнери нямат мрежа, за тях е необходимо да създадете локални (специализирани) мрежови устройства с отделна команда, но можем да създадем глобално мрежово устройство в конфигурацията профил, който ще бъде споделен между всички контейнери, използващи този профил. По този начин, веднага след командата за създаване на нов контейнер, те ще имат мрежа с достъп до мрежата. В същото време няма ограничения, винаги можем да създадем устройство за локална мрежа по-късно, ако е необходимо.

Следващата команда ще добави устройството към конфигурационния профил eth0 типа nic свързан към мрежата lxdbr0:

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

Важно е да се отбележи, че тъй като всъщност добавихме устройството към конфигурационния профил, ако посочихме статичен IP адрес в устройството, тогава всички контейнери, които ще използват този профил, ще споделят един и същ IP адрес. Ако има нужда да създадете контейнер със статичен IP адрес, разпределен за контейнера, тогава трябва да създадете конфигурация на мрежово устройство на ниво контейнер (локална конфигурация) с параметъра IP адрес, а не на ниво профил.

Да проверим профила:

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: []

В този профил можем да видим, че за всички новосъздадени контейнери ще бъдат създадени две устройства:

• eth0 — Тип на устройството nic свързан към комутатор (мрежов мост) lxdbr0
• root — Тип на устройството disk който използва пул за съхранение ssdpool

Създаване на нови профили ^

За използване на предварително създадени Басейн за съхранение контейнери, създайте конфигурационен профил ssdroot в който ще добавим устройство като disk с точка на монтиране / (root), използвайки предварително създадения Басейн за съхранение - ssdpool:

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

По същия начин създаваме устройство като disk, но в този случай използвайки Басейн за съхранение - hddpool:

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

Проверка на конфигурационните профили:

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: []

Хранилище за изображения ^

Контейнерите се създават от изображения, които са специално сглобени дистрибуции, които нямат Linux ядро. Следователно, преди да стартирате контейнера, той трябва да бъде разгърнат от това изображение. Източникът на изображения е локално хранилище, в което изображенията се изтеглят от външни хранилища.

Отдалечени хранилища за изображения ^

По подразбиране LXD е конфигуриран да получава изображения от три отдалечени източника:

• ubuntu: (за стабилни изображения на Ubuntu)
• ubuntu-ежедневно: (за ежедневни изображения на Ubuntu)
• снимки: (за куп други дистрибуции)

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    |
+-----------------+------------------------------------------+--------+--------+

Например, хранилище ubuntu: има следните изображения:

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  |
+----------------------------------------------+--------------+----------+------------+

За показване на ограничен брой колони използвахме опцията -c с параметри dasut, а също така ограничи дължината на списъка с командата head.

Налично е филтриране за показване на списък с изображения. Следващата команда ще изброи всички налични архитектури за разпространение 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        |
+------------------------------+--------------------------------------+--------------+

Локално хранилище за изображения ^

За да започнете да използвате контейнера, трябва да добавите изображение от глобалното хранилище към локалното local:. Сега локалното хранилище е празно, командата ще се увери в това lxc image list. Ако методът list не посочвайте хранилище, тогава локалното хранилище ще се използва по подразбиране - local:

lxc image list local:

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

Изображенията в хранилището се управляват чрез следните методи:

Отбор
описание

lxc изображение псевдоним
Управление на псевдоними на изображения

lxc изображение копирате
Копирайте изображения между сървъри

lxc изображение изтриване
Изтриване на изображения

lxc изображение редактирам
Редактиране на свойствата на изображението

lxc изображение износ
Експортиране и изтегляне на изображения

lxc изображение внос
Импортирайте изображения в магазина за изображения

lxc изображение инфо
Показване на полезна информация за изображения

lxc изображение списък
Избройте изображения

lxc изображение опресняване
Опресняване на изображения

lxc изображение Покажи
Показване на свойствата на изображението

Копирайте изображението в локалното хранилище от глобалното images::

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

Image copied successfully!

Нека покажем списък с всички изображения, налични в момента в локалното хранилище local::

lxc image -c lfdatsu list local:

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

LXD конфигурация ^

В допълнение към интерактивния режим, LXD поддържа и неинтерактивен режим на инсталиране на конфигурация, това е, когато конфигурацията е посочена под формата на YAML файл, специален формат, който ви позволява да инсталирате цялата конфигурация наведнъж, заобикаляйки изпълнението на много интерактивни команди, които бяха обсъдени по-горе в тази статия, включително мрежова конфигурация, създаване на конфигурационни профили и т.н. Тук няма да покриваме тази област, можете да я проверите сами. в документация.

Следваща интерактивна команда lxc config който ще разгледаме ви позволява да зададете конфигурацията. Например, за да гарантираме, че изтеглените изображения в локалното хранилище не се актуализират автоматично от глобалните хранилища, можем да активираме това поведение със следната команда:

lxc config set images.auto_update_cached=false

Създаване и управление на контейнер ^

За да създадете контейнер, използвайте командата lxc init към които се предават стойности репозиторий:образ и след това желания ID за контейнера. Хранилището може да бъде посочено като локално local: така е и всеки глобален. Ако хранилището не е посочено, тогава по подразбиране локалното хранилище се използва за търсене на изображението. Ако изображението е указано от глобалното хранилище, тогава изображението първо ще бъде изтеглено в локалното хранилище и след това ще се използва за създаване на контейнера.

Нека изпълним следната команда, за да създадем нашия първи контейнер:

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

Нека да разгледаме командните клавиши, които използваме тук по ред:

• alpine3 — Посочен е псевдоним (alias) за изображението, което е било качено преди това в локалното хранилище. Ако псевдонимът не е създаден за това изображение, винаги можете да се обърнете към изображението чрез него Fingerprint който се показва в таблицата.
• alp — Задава идентификатора за контейнера
• --storage — Този ключ показва в коя Басейн за съхранение ще бъде създаден контейнер
• --profile — Тези ключове каскадно прилагат конфигурация от предварително създадени конфигурационни профили към контейнера

Стартираме контейнера, който започва да стартира системата за стартиране на дистрибуцията:

lxc start alp

Можете също да използвате командата lxc launch което ви позволява да комбинирате екипи lxc init и lxc start в една операция.

Проверка на състоянието на контейнера:

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

Проверка на конфигурацията на контейнера:

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: ""

В раздела profiles можем да се уверим, че този контейнер използва два конфигурационни профила − default и hddroot. В раздел devices можем да открием само едно устройство, тъй като мрежовото устройство е създадено на ниво профил default. За да видите всички устройства, използвани от контейнера, трябва да добавите ключ --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: ""

Задаване на статичен IP адрес ^

Ако се опитаме да зададем IP адрес за мрежово устройство eth0 екип lxc config device set alp предназначен за конфигурацията на контейнера, тогава ще получим грешка, която ще съобщи, че устройството не съществува, тъй като устройството eth0 който се използва от контейнера принадлежи към профила default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Разбира се, можем да зададем статичен IP адрес за eth0 устройства в профила, но ще бъде същото за всички контейнери, които ще използват този профил. Затова нека добавим устройство, посветено на контейнера:

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

След това трябва да рестартирате контейнера:

lxc restart alp

Ако погледнем конфигурацията на контейнера сега, не е необходимо да използваме опцията --expanded за да видите мрежовото устройство eth0, тъй като го създадохме на ниво контейнер и той се каскадира върху същото устройство от профила 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: ""

Премахване на контейнер ^

За да премахнете контейнер, използвайте командата lxc delete, но преди да премахнете контейнера, той трябва да бъде спрян с помощта на командата lxc stop:

lxc stop alp

lxc list

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

След като проверим, че състоянието на контейнера е станало СПРЯНА, може да се премахне от Басейн за съхранение:

lxc delete alp

Достъп до контейнер ^

За да изпълните директно команди в контейнер, заобикаляйки мрежовите връзки, използвайте командата lxc exec който изпълнява команди в контейнера, без да стартира системната обвивка. Ако трябва да изпълните команда в обвивка, използвайки шаблони на обвивка като променливи, пренасочвания на файлове (тръба) и т.н., тогава трябва изрично да стартирате обвивката и да предадете командата като ключ, например:

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

Командата използва специален символ за изход за специален характер $ така че променливата $HOME не се интерпретира на хост машината, а се интерпретира само вътре в контейнера.

Възможно е също така да стартирате интерактивния режим на обвивка и след това да прекратите сесията чрез изпълнение на клавишна комбинация CTRL+D:

lxc exec alp -- /bin/sh

Управление на ресурсите на контейнера ^

В LXD можете да управлявате ресурсите на контейнера, като използвате специален набор от конфигурации. Можете да намерите пълен списък с параметри за конфигурация на контейнера в документация.

Ограничение на RAM ресурса ^

Параметър limits.memory ограничава количеството RAM, достъпно за контейнера. Стойността е число и едно от налични суфикси.

Нека зададем ограничението на RAM на контейнера до 256 MB:

lxc config set alp limits.memory 256MB

Освен това има и други параметри за ограничаване на паметта:

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

Отбор lxc config show ви позволява да покажете цялата конфигурация на контейнера, включително приложеното ограничение на ресурсите, което е зададено:

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.cpu - свързва контейнер към едно или повече процесорни ядра
• limits.cpu.allowance - управлява или квотите на планировчика на CFS, когато срокът е изтекъл, или универсалния механизъм за споделяне на ресурси на процесора, когато процентът е изтекъл
• limits.cpu.priority - приоритет на планировчика, когато на множество екземпляри, споделящи набор от процесори, е присвоен същия процент процесори

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: ""

Ограничение на дисковото пространство ^

В допълнение към ограниченията като limits.read, limits.write можем също така да ограничим количеството дисково пространство, консумирано от контейнера (работи само с ZFS или BTRFS):

lxc config device set alp root size=2GB

След инсталирането, в параметъра devices.root.size Можем да проверим зададения лимит:

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

За да видите използваните дискови квоти, можем да получим от командата 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

Въпреки факта, че сме задали ограничение за основното устройство на контейнера до 2GB, системните помощни програми като df няма да видите това ограничение. За да направим това, ще проведем малък тест и ще разберем как работи.

Нека създадем 2 нови идентични контейнера в същия Басейн за съхранение (hddpool):

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         |
+------+---------+------------------+------+-----------+-----------+

Нека създадем файл от 1 GB в един от контейнерите:

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

Нека се уверим, че файлът е създаден:

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

Ако погледнем във втория контейнер, проверим за съществуването на файл на същото място, тогава този файл няма да бъде там, което се очаква, тъй като контейнерите се създават в собствените си Обем на съхранение в същото Басейн за съхранение:

lxc exec alp2 -- ls -lh
total 0

Но нека сравним стойностите, които произвежда df на единия и на другия контейнер:

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% /
...

приспособление /dev/loop1 монтиран като root дял Басейн за съхранение които тези контейнери използват, така че споделят обема му между двама.

Статистика на потреблението на ресурси ^

Можете да видите статистическите данни за потреблението на ресурси за контейнер, като използвате командата:

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

Работа с моментни снимки ^

LXD има способността да създава моментни снимки и да възстановява състоянието на контейнера от тях.

За да създадете моментна снимка, изпълнете следната команда:

lxc snapshot alp snapshot1

Екипът lxc snapshot няма наличен ключ list, следователно, за да видите списъка със снимки, трябва да използвате командата, която показва обща информация за контейнера:

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

Можете да възстановите контейнер от моментна снимка с помощта на командата lxc restore указвайки контейнера, за който ще се извърши възстановяването, и псевдонима на моментната снимка:

lxc restore alp snapshot1

Следната команда се използва за изтриване на моментна снимка. Моля, обърнете внимание, че синтаксисът на командата не е подобен на всички останали; тук трябва да посочите наклонена черта след името на контейнера. Ако наклонената черта е пропусната, тогава командата за изтриване на моментна снимка се интерпретира като команда за изтриване на контейнер!

lxc delete alp/snapshot1

В примера по-горе разгледахме така наречените моментни снимки без състояние. LXD има и друг тип моментни снимки – stateful, които запазват текущото състояние на всички процеси в контейнера. Има редица интересни и полезни функции, свързани с моментните снимки на състоянието.

Какво друго? ^

• Наличен е модул за разработчици на Python PyLXD който предоставя API за LXD

АКТУАЛИЗАЦИЯ 10.04.2020/15/00 XNUMX:XNUMX: Добавена навигация

Източник: www.habr.com