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
  Transitional package - lxd -> snap (lxd)

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

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

snap find lxd

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

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

snap list

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

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

sudo apt update
sudo apt install lxd

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

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 (Storage) ^

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

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

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

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

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

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| 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

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

Също така, ако за 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 на новото loop устройство (минимум 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 като посочим стойността като блоково устройство вместо пътя до loopback файла, посочвайки това в ключа източник.

И така, преди създаването 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 status 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).

От изхода можем да се уверим, че статусът на услугата е равен на active, въпреки че изпълнението на нашия скрипт от една команда приключи, това ни позволи да направим опцията 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 и с това как да създадем виртуален комутатор (мрежов мост, bridge) с помощта на клиентската команда.

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

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

Следната команда създава комутатор с подсет и 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:  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 са създадени три профила: 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: По подразбиране LXD профил
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: \/
    pool: ssdpool
    type: disk
name: default
used_by: []

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

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

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

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

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

По аналогия, създаваме устройство от тип диск, но в този случай използващо 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       | ДА     | НЕ     |
+-----------------+------------------------------------------+--------+--------+
| local (default) | unix://                                  | НЕ     | ДА     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | ДА     | ДА     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | ДА     | ДА     |
+-----------------+------------------------------------------+--------+--------+

Например, репозиториите 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)          | Alpine 3.11 amd64 (20200220_13:00)   | x86_64       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/arm64 (още 1)    | Alpine 3.11 arm64 (20200220_13:00)   | aarch64      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/armhf (още 1)    | Alpine 3.11 armhf (20200220_13:00)   | armv7l       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/i386 (още 1)     | Alpine 3.11 i386 (20200220_13:01)    | i686         |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/ppc64el (още 1)  | Alpine 3.11 ppc64el (20200220_13:00) | ppc64le      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/s390x (още 1)    | Alpine 3.11 s390x (20200220_13:00)   | s390x        |
+------------------------------+--------------------------------------+--------------+

Локален репозиторий на изображения ^

За да започнете с експлоатацията на контейнера, е необходимо да добавите образ от глобалния репозиторий в локалния. local:. В момента локалният репозиторий е празен, което можем да потвърдим с командата lxc image list. Ако не укажете репозиторий за метода, по подразбиране ще се използва локалният репозиторий — list lxc image list local:+-------+-------------+--------+-------------+--------------+------+------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | +-------+-------------+--------+-------------+--------------+------+------+ local:

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

lxc image

Команда
Описание

Управление на псевдоними на образи alias
Копиране на образи между сървъри

Управление на псевдоними на образи copy
Изтриване на образи

Управление на псевдоними на образи изтрий
Редактиране на свойства на образа

Управление на псевдоними на образи edit
export

Управление на псевдоними на образи Експорт и изтегляне на образи
Импортиране на образи в хранилището на образи

Управление на псевдоними на образи import
info

Управление на псевдоними на образи Показване на полезна информация за образите
Списък на образите

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

Управление на псевдоними на образи refresh
show

Управление на псевдоними на образи Показване на свойства на образа
Копираме образ в локалния репозиторий от глобалния

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3Образът беше успешно копиран! images::

Да изведем списък на всички образи, достъпни в момента в локалния репозиторий

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

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

Следващата интерактивна команда в документацията.

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

В секцията профили можем да се уверим, че този контейнер използва два профила на конфигурация — default и hddroot. В секцията устройства можем да открием само едно устройство, тъй като мрежовото устройство беше създадено на ниво профил defaultЗа да видите всички устройства, използвани от контейнера, трябва да добавите ключа --разширено:

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: 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
устройства:
  eth0:
    име: eth0
    мрежа: lxdbr0
    тип: nic
  root:
    път: /\
    пул: hddpool
    тип: диск
епхемерално: false
профили:
- default
- hddroot
състояние: false
описание: ""

Настройка на статичен IP адрес ^

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

lxc config device set alp eth0 ipv4.address 10.0.5.5

Грешка: Устройството не съществува

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

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

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

lxc restart alp

Ако сега погледнем конфигурацията на контейнера, не ни трябва да прилагаме опцията --разширено за да видим мрежовото устройство 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         |
+------+---------+-------------------+------+-----------+-----------+

След като се уверим, че състоянието на контейнера е STOPPED, той може да бъде изтрит от Storage Pool:

lxc delete alp

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

Командата за изпълнение на команди в контейнера, директно, без мрежови връзки, е lxc exec , която изпълнява команди в контейнера без да стартира системна обвивка. Ако искате да изпълните команда в обвивка, използвайки шаблони на обвивка, като променливи, пренасочвания на файлове (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

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

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

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

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

lxc info alp
...
...
Снимки:
  snapshot1 (сделан 2020/04/08 18:18 UTC) (без состояния)

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

lxc restore alp snapshot1

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

lxc delete alp/snapshot1

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

Какво още? ^

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

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

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

Основни възможности на LXD — системи за контейнери в Linux

Навигация