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

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

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

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

Инсталация на LXD
- Инсталация на LXD в дистрибуции на Ubuntu
- Инсталация на LXD в дистрибуции на Arch Linux
Хранилище на LXD (Storage)
Инициализация на LXD
Създаване и управление на контейнер

Инсталация на LXD ^

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

В дистрибуцията на Ubuntu 19.10 пакетът lxd има транслация на snap пакет:

apt search lxd

lxd/eoan 1:0.7 all
  Преходен пакет - lxd -> snap (lxd)

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

Намерете пакета lxd в snap репозитория може да се извърши с командата:

snap find lxd

Име            Версия        Резюме
lxd             3.21           Управител на системни контейнери и API
lxd-demo-server  0+git.6d54658  Онлайн демо сесии на софтуер с LXD
nova            ocata          Услуга за компютърна обработка OpenStack (nova)
nova-hypervisor  ocata          Услуга за компютърна обработка - KVM хипервизор (nova)
distrobuilder    1.0            Конструктор на образи за LXC и LXD
fabrica          0.1            Създаване на snap пакети, просто като насочите уеб форма към...
satellite        0.1.2          Развита мащабируемa платформа за интелигентност с отворен код

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

snap list

Име  Версия    Рев   Проследяване  Издател   Бележки
core  16-2.43.3  8689  стабилен    canonical✓  core

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

sudo apt update
sudo apt install lxd

Убедим се, че пакетът е инсталиран като snap пакет:

snap list

Име  Версия    Рев    Проследяване  Издател   Бележки
core  16-2.43.3  8689   стабилен   canonical✓  core
lxd   3.21       13474  стабилен/...  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 (Storage) ^

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

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

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

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

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

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  ИМЕ   | ОПИСАНИЕ   | ДРАЙВЕР |             ИЗТОЧНИК             | ИЗПОЛЗВАНО ОТ |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | /dev/loop1                     | 2       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | /var/lib/lxd/disks/ssdpool.img | 4       |
+---------+-------------+--------+--------------------------------+---------+

За преглед на списъка на всички Storage Volume в избраното Storage Pool служи командата lxc storage volume list:

lxc storage volume list hddpool

+-------+----------------------------------+-------------+---------+
| ТИП  |          ИМЕ                    | ОПИСАНИЕ   | ИЗПОЛЗВАНО ОТ |
+-------+----------------------------------+-------------+---------+
| изображение | ebd565585223487526ddb3607f515... |             | 1       |
+-------+----------------------------------+-------------+---------+

lxc storage volume list ssdpool

+-----------+----------------------------------+-------------+---------+
|   ТИП    |            ИМЕ                  | ОПИСАНИЕ   | ИЗПОЛЗВАНО ОТ |
+-----------+----------------------------------+-------------+---------+
| контейнер | alp3                             |             | 1       |
+-----------+----------------------------------+-------------+---------+
| контейнер | jupyter                          |             | 1       |
+-----------+----------------------------------+-------------+---------+
| изображение     | ebd565585223487526ddb3607f515... |             | 1       |
+-----------+----------------------------------+-------------+---------+

Също така, ако за Storage Pool при създаването е избрана файлова система BTRFS, можете да получите списък Storage Volume или subvolumes в интерпретацията на 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 се задават няколко въпроса, сред които е определянето на типа файлова система за по подразбиране Storage Pool. По подразбиране се избира файлова система BTRFS. Няма да е възможно да се смени на друга файлова система след създаването й. За избор на файлова система се предлага таблица за сравнение на възможностите:

Функция
Directory
Btrfs
LVM
ZFS
CEPH

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

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

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

Оптимизирано предаване на изображения
не
yes
не
yes
yes

Оптимизирано предаване на инстанции
не
yes
не
yes
yes

Копиране при запис
не
yes
yes
yes
yes

На базата на блокове
не
не
yes
не
yes

Моментално клониране
не
yes
yes
yes
yes

Дисков шофьор, използваем в контейнер
yes
yes
не
не
не

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

Дискови квоти
да(*)
yes
yes
yes
не

Инициализация на мрежата и Storage Pool чрез асистента ^

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

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

lxd init

Искате ли да използвате клъстериране на LXD? (да/не) [по подразбиране=не]: 
Искате ли да конфигурирате ново хранилище? (да/не) [по подразбиране=да]: 
Име на новото хранилище [по подразбиране=по подразбиране]: ssdpool 
Име на използваемия задна хранилище (lvm, btrfs, dir) [по подразбиране=btrfs]: 
Създайте нов BTRFS пул? (да/не) [по подразбиране=да]: 
Искате ли да използвате съществуващо блочно устройство? (да/не) [по подразбиране=не]: 
Размер в GB на новото циклично устройство (мин. 1GB) [по подразбиране=15GB]: 10GB
Искате ли да се свържете с MAAS сървър? (да/не) [по подразбиране=не]: 
Искате ли да създадете нов локален мрежови мост? (да/не) [по подразбиране=да]: 
Как да се нарича новият мост? [по подразбиране=lxdbr0]: 
Кой IPv4 адрес да се използва? (CIDR нотация на подсети, “авто” или “няма”) [по подразбиране=авто]: 10.0.5.1/24
Искате ли LXD да NAT-ва IPv4 трафика на моста ви? [по подразбиране=да]: 
Кой IPv6 адрес да се използва? (CIDR нотация на подсети, “авто” или “няма”) [по подразбиране=авто]: няма
Искате ли LXD да бъде достъпен през мрежата? (да/не) [по подразбиране=не]: 
Искате ли остарелите кеширани изображения да се актуализират автоматично? (да/не) [по подразбиране=да] не
Искате ли YAML "lxd init" предварително задаване да бъде отпечатано? (да/не) [по подразбиране=не]:

Създаване на допълнителен Storage Pool ^

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

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

И така, преди създаването Storage Pool необходимо да се определи loopback файл или съществуващо разделение в файловата система, което да използва. За целта ще създадем и ще използваме файл с ограничение на размера до 10GB:

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 което съответства на дефолтното Storage Pool.

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

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

Нека изведем списък на всички Storage Pool на екрана:

lxc storage list

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

Увеличаване на размера на Storage Pool ^

След създаването Storage Pool, при необходимост, може да бъде разширен. За Storage Pool базирания на файловата система 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 при зареждането на хост системата.

Нека създадем unit файл от тип service в /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

Създаден символн за връзка /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

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

systemctl статус lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Зареден: зареден (/etc/systemd/system/lxd-hddpool.service; включен; настройка на производителя: деактивирана)
     Активен: активен (излезе) от Сря 2020-04-08 03:43:53 MSK; 1мин 37с назад
    Процес: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (код=излязъл, статус=0/УСПЕХ)
   Основен PID: 711 (код=излязъл, статус=0/УСПЕХ)

апр 08 03:43:52 manjaro systemd[1]: Започване на Losetup LXD Storage Pool (hddpool)...
апр 08 03:43:53 manjaro systemd[1]: Завършено 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 и как да създадем виртуален комутатор (мост) с помощта на клиентската команда.

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

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

Следващата команда създава комутатор с подсет и 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

+--------+----------+---------+-------------+---------+
|  ИМЕ  |   ТИП   | УПРАВЛЯВАН | ОПИСАНИЕ  | ИЗПОЛЗВА С |
+--------+----------+---------+-------------+---------+
| eno1   | физическа | НЯМА      |             | 0       |
+--------+----------+---------+-------------+---------+
| lxdbr0 | мост      | ДА       |             | 0       |
+--------+----------+---------+-------------+---------+

Също така, можете да се уверите в съществуването на мрежовото устройство с помощта на стандартния инструмент на Linux дистрибуцията — ip link или ip addr:

ip addr

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

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

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

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

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

lxc profile list

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

Пълен списък на наличните команди за работа с профила може да получите, добавяйки ключа --help:

lxc profile --help

Описание:
  Управление на профили

Използване:
  lxc profile [команда]

Налични команди:
  add         Добавете профили към инстанции
  assign      Присвояване на набори от профили към инстанции
  copy        Копиране на профили
  create      Създаване на профили
  delete      Изтриване на профили
  device      Управление на устройства на инстанцията
  edit        Редактиране на конфигурации на профили като YAML
  get         Вземете стойности за ключове на конфигурации на профили
  list        Списък на профили
  remove      Премахнете профили от инстанции
  rename      Преименуване на профили
  set         Задайте ключове на конфигурации на профили
  show        Покажете конфигурации на профили
  unset       Премахнете ключове на конфигурации на профили

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

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

Следната команда ще добави в конфигурационния профил устройство 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: []

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

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

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

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

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

По аналогичен начин, създаваме устройство от тип disk, но в този случай използващо Storage Pool — 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-daily: (за ежедневни Ubuntu образи)
images: (за поредица от други дистрибуции)

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

+----------------------------------------------+--------------+----------+------------+
|                   ОПИСАНИЕ                   | АРХИТЕКТУРА |   РАЗМЕР  |   ТИП     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | КОНТЕЙНЕР  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | КОНТЕЙНЕР  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | КОНТЕЙНЕР  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | КОНТЕЙНЕР  |
+----------------------------------------------+--------------+----------+------------+

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

За извеждане на списъка с образи е налична филтрация. Следната команда ще изведе списък на всички налични архитектури на дистрибутива AlpineLinux:

lxc image -c ldast list images:alpine/3.11

+------------------------------+--------------------------------------+--------------+
|            АЛИАС             |             ОПИСАНИЕ              | АРХИТЕКТУРА |
+------------------------------+--------------------------------------+--------------+
| 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. Ако методът списък не укаже репозиторий, по подразбиране ще се използва локалният репозиторий — local:

lxc image list local:

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

Управлението на образи в репозитория става чрез следните методи:

Екип
Описание

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

lxc image copy
Копиране на образи между сървъри

lxc image delete
Изтриване на образи

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

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

lxc image import
Импортиране на образи в хранилището за образи

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

lxc image списък
Списък с образи

lxc image refresh
Обновяване на образи

lxc image show
Показване на свойства на образа

Копираме образ от глобалния репозиторий в локалния. images::

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

Образът е успешно копиран!

Нека изведем списък на всички образи, налични в момента в локалния репозиторий. 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 на която се предават стойности репозиторий:образ и след това желан идентификатор за контейнера. Репозиторият може да бъде указан като локален. local: така и все глобално. Ако репозиторият не е посочен, тогава по подразбиране за търсене на образа се използва локален репозиторий. Ако образът е посочен от глобален репозиторий, първо образът ще бъде изтеглен в локалния репозиторий и след това използван за създаване на контейнера.

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

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

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

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

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

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

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

lxc config show alp

архитектура: x86_64
конфигурация:
  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
устройства:
  eth0:
    ipv4.address: 10.0.5.5
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: \/
    pool: hddpool
    type: disk
эфемерный: false
профили:
- по умолчанию
- hddroot
состояние: false
описание: ""

Изтриване на контейнер ^

Команда для удаления контейнера lxc delete, но перед тем как удалить контейнер, его необходимо остановить с помощью команды lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4        | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPED | 10.0.5.10 (eth0)  |      | КОНТЕЙНЕР | 0         |
+------+---------+-------------------+------+-----------+-----------+

После того как мы убедились, что контейнер теперь имеет состояние STOPPED, его можно удалить из Storage Pool:

lxc delete alp

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

Для выполнения команд внутри контейнера напрямую, минуя сетевые соединения, используется команда lxc exec , которая выполняет команды в контейнере без запуска системной оболочки. Если нужно выполнить команду в оболочке, используя шаблоны shell, такие как переменные, перенаправления файлов (pipe) и т.д., необходимо явно запустить оболочку и передать команду в качестве ключа, например:

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

архитектура: x86_64
конфигурация:
  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
dевices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

Ограничаване на ресурсите на CPU (ЦП) ^

За ограничаване на ресурсите на ЦП съществуват няколко типа ограничения:

limit.cpu — свързва контейнера с едно или няколко ядра на ЦП
limits.cpu.allowance — управлява или квотите на CFS планировчика, когато е изтекло времето, или универсалния механизъм за споделяне на ресурси на ЦП, когато е достигнат процент
limits.cpu.priority — приоритет на планировчика, когато за няколко инстанции, които споделят набор от процесори, е зададен един и същ процент от процесорите

lxc config set alp limits.cpu.allowance 40%

lxc config show alp

архитектура: x86_64
конфигурация:
  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
dевices: {}
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
...
dевices:
  root:
    path: \/
    pool: hddpool
    size: 2GB
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

За да видим използваните квоти на диска, можем да ги получим от командата lxc info:

lxc info alp
...
Ресурси:
  Процеси: 5
  Използване на диск:
    root: 1.05GB
  Използване на ЦП:
    Използване на ЦП (в секунди): 1
  Използване на памет:
    Памет (текуща): 5.46MB
  Използване на мрежа:
    eth0:
      Приети байтове: 802B
      Изпратени байтове: 1.59kB
      Приети пакети: 4
      Изпратени пакети: 14
    lo:
      Приети байтове: 0B
      Изпратени байтове: 0B
      Приети пакети: 0
      Изпратени пакети: 0

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

Ще създадем 2 нови идентични контейнера в едно и също Storage Pool (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         |
+------+---------+------------------+------+-----------+-----------+

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

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

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

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 монтираното като коренов дял е Storage Pool което тези контейнери използват, затова те го споделят на двамата.

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

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

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

lxc info alp
...
...
Снапшоты:
  snapshot1 (взято 2020/04/08 18:18 UTC) (без состояния)

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

lxc restore alp snapshot1

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

lxc delete alp/snapshot1

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

Какво още? ^

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

UPDATE 10.04.2020 15:00: Добавих навигация

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

FreeRDP - свободна реализация на протокол за отдален достъп до работен плот (RDP), публикувана под лицензия Apache, е форк на rdesktop. Най-значителните промени в релиза 2.0.0: .

Навигация