LXD - гэта сістэмны менеджэр кантэйнераў наступнага пакалення, так абвяшчае крыніца. Ён прапануе карыстацкі інтэрфейс, падобны на віртуальныя машыны, але які выкарыстоўвае замест гэтага кантэйнеры Linux.

Ядро LXD - Гэта прывелераваны дэман (сэрвіс запушчаны з правамі root), які падае REST API праз лакальны unix сокет, а таксама праз сетку, калі ўсталявана адпаведная канфігурацыя. Кліенты, такія як інструмент каманднага радка які пастаўляецца з LXD пасылаюць запыты праз гэты REST API. Гэта азначае, што незалежна ад таго, ці звяртаецеся вы да лакальнага хаста ці да выдаленага, усё працуе аднолькава.

У гэтым артыкуле мы не будзем падрабязна спыняцца на канцэпцыях LXD, не будзем разглядаць усе даступныя магчымасці выкладзеныя ў дакументацыі, у тым ліку нядаўнюю рэалізацыю ў апошніх версіях LXD падтрымкі віртуальных машын QEMU паралельна з кантэйнерамі. Замест гэтага мы даведаемся толькі базавыя магчымасці кіравання кантэйнерамі - наладзім пулы сховішчаў, сетку, запусцім кантэйнер, прымянім ліміты на рэсурсы, а таксама разгледзім як выкарыстоўваць снепшоты, каб вы змаглі атрымаць базавую ўяўленне аб LXD і выкарыстоўваць кантэйнеры ў Linux.

Для атрымання поўнай інфармацыі трэба звярнуцца да афіцыйнай крыніцы:

• Сайт распрацоўніка
• Дакументацыя
• Форум

Навігацыя

• Усталёўка LXD
  • Усталёўка LXD у дыстрыбутывах Ubuntu
  • Усталёўка LXD у дыстрыбутывах Arch Linux
• Сховішча LXD (Storage)
• Ініцыялізацыя LXD
  • Выбар файлавай сістэмы для Storage Pool
  • Ініцыялізацыя сеткі і Storage Pool з дапамогай майстра
  • Стварэнне дадатковага Storage Pool
    • Павелічэнне памеру Storage Pool
    • Аўтаўстаўка loopback-файла ў слот loopback-прылады
  • Бяспека. Прывілеі кантэйнераў
  • Стварэнне віртуальнага камутатара сеткі
  • Профіль канфігурацыі
    • Рэдагаванне профілю
    • Стварэнне новых профіляў
  • Рэпазітар вобразаў
    • Выдаленыя рэпазітары вобразаў
    • Лакальны рэпазітар вобразаў
  • Канфігурацыя LXD
• Стварэнне і кіраванне кантэйнерам
  • Ўстаноўка статычнага IP адрасу
  • Выдаленне кантэйнера
  • Доступ да кантэйнера
  • Кіраванне рэсурсамі кантэйнера
    • Абмежаванне рэсурсаў RAM (АЗП)
    • Абмежаванне рэсурсаў CPU (ЦП)
    • Абмежаванне дыскавай прасторы
    • Статыстыка спажывання рэсурсаў
  • Праца са снежкамі

Усталёўка 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           System container manager and API
lxd-demo-server  0+git.6d54658  Online software demo sessions using LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Image builder for LXC and LXD
fabrica          0.1            Build snaps by simply pointing a web form to...
satellite        0.1.2          Advanced scalable Open source intelligence platform

Запусціўшы каманду list можна пераканаецца, што пакет lxd яшчэ не ўсталяваны:

snap list

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

Нягледзячы на ​​тое, што LXD з'яўляецца 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.

Сховішча (захоўванне) складаецца з аднаго ці некалькіх Басейн захоўвання які выкарыстоўвае адну з падтрымоўваных файлавых сістэм такія як ZFS, BTRFS, LVM ці звычайныя дырэкторыі. Кожны Басейн захоўвання падзяляецца на тамы (Аб'ём захоўвання) якія змяшчаюць вобразы, кантэйнеры або дадзеныя для іншых мэт.

• вобразы - гэта адмыслова сабраныя дыстрыбутывы без ядра Linux і даступныя з вонкавых крыніц
• кантэйнеры - гэта разгорнутыя дыстрыбутывы з выяў, гатовыя да эксплуатацыі.
• Сняпшоты - Гэта здымкі стану кантэйнераў да якіх можна вяртацца

Для кіравання сховішчам у LXD служыць каманда lxc storage даведку па якой можна атрымаць паказаўшы ключ lxc storage --help

Наступная каманда выводзіць на экран спіс усіх Басейн захоўвання у LXD сховішча:

lxc storage list

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

Для прагляду спісу ўсіх Аб'ём захоўвання у абраным Басейн захоўвання служыць каманда lxc storage volume list:

lxc storage volume list hddpool

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

lxc storage volume list ssdpool

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

Таксама, калі для Басейн захоўвання пры стварэнні была абрана файлавая сістэма BTRFS, то атрымаць спіс Аб'ём захоўвання або падтэмы у інтэрпрэтацыі BTRFS можна з дапамогай інструментара гэтай файлавай сістэмы:

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

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

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

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

Ініцыялізацыя LXD ^

Перад стварэннем і выкарыстаннем кантэйнераў неабходна выканаць агульную ініцыялізацыю LXD якая стварае і настройвае сетку, а таксама сховішча. Гэта можна зрабіць уручную з дапамогай стандартных каманд кліента якія даступныя ў спісе па выкліку каманды lxc --help ці з дапамогай майстра ініцыялізацыі lxd init адказаўшы на некалькі пытанняў.

Выбар файлавай сістэмы для Storage Pool ^

Падчас ініцыялізацыі LXD задае некалькі пытанняў, сярод якіх будзе вызначэнне тыпу файлавай сістэмы для дэфолтнага. Басейн захоўвання. Па змаўчанні для яго выбіраецца файлавая сістэма BTRFS. Памяняць на іншую ФС пасля стварэння будзе немагчыма. Для выбару ФС прапануецца табліца параўнання магчымасцяў:

асаблівасць
каталог
Btrfs
LVM
ZFS
CEPH

Optimized image storage
Няма.
ды
ды
ды
ды

Optimized instance creation
Няма.
ды
ды
ды
ды

Optimized snapshot creation
Няма.
ды
ды
ды
ды

Optimized image transfer
Няма.
ды
Няма.
ды
ды

Optimized instance transfer
Няма.
ды
Няма.
ды
ды

Капіяваць пры запісе
Няма.
ды
ды
ды
ды

На аснове блокаў
Няма.
Няма.
ды
Няма.
ды

Instant cloning
Няма.
ды
ды
ды
ды

Дапаможны індывідуальны driver
ды
ды
Няма.
Няма.
Няма.

Restore from older snapshots (адсутнасць)
ды
ды
ды
Няма.
ды

Storage quotas
yes(*)
ды
ды
ды
Няма.

Ініцыялізацыя сеткі і Storage Pool з дапамогай майстра ^

Наступная каманада, якую мы разгледзім, прапануе наладзіць асноўныя кампаненты LXD адказамі на простыя пытанні з дапамогай майстра ініцыялізацыі.

Запусціце каманду lxc init і ўвядзіце адказы на пытанні пасля знака двукроп'я, бо паказана ў прыкладзе ніжэй або зменіце іх згодна з вашымі ўмовамі:

lxd init

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

Стварэнне дадатковага Storage Pool ^

У папярэднім кроку мы стварылі Басейн захоўвання якому далі назву ssdpool і файл якога размясціўся ў маёй сістэме па адрасе /var/lib/lxd/disks/ssdpool.img. Гэты адрас файлавай сістэмы адпавядае фізічнаму SSD дыску ў маім ПК.

Наступнымі дзеяннямі, для пашырэння разумення таго, якую ролю гуляе Басейн захоўвання у сховішча, мы створым другі Басейн захоўвання які будзе фізічна размяшчацца на іншым тыпе дыска, на HDD. Праблема заключаецца ў тым, што LXD не дазваляе ствараць Басейн захоўвання па-за адрасам /var/lib/lxd/disks/ і нават сімвалічныя спасылкі не будуць працаваць, глядзіце адказ распрацоўніка. Абысці гэтае абмежаванне мы можам пры ініцыялізацыі/фарматаванні Басейн захоўвання паказаўшы значэнне як блокавая прылада замест шляху да loopback-файла паказаўшы гэта ў ключы source.

Такім чынам, да стварэння Басейн захоўвання неабходна вызначыць 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 які адпавядае дэфолтнаму Басейн захоўвання.

Наступная каманда стварае новы Басейн захоўвання у LXD на аснове толькі што падрыхтаванага loopback-файла. LXD адфарматуе loopback-файл /mnt/work/lxd/hddpool.img у прыладзе /dev/loop1 пад файлавую сістэму BTRFS:

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

Вывядзем спіс усіх Басейн захоўвання на экран:

lxc storage list

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

Павелічэнне памеру 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 пры загрузцы сістэмы хаста.

Створым блок файл тыпу абслугоўванне в /etc/systemd/system/ для сістэмы ініцыялізацыі SystemD:

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

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

[Install]
WantedBy=local-fs.target
EOF

Актывуем сэрвіс:

sudo systemctl enable lxd-hddpool

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

Пасля рэстарту хаставой сістэмы правяраем статус сэрвісу:

systemctl status lxd-hddpool.service 

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

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

З высновы мы можам пераканацца, што стан сэрвісу роўна актыўны, нягледзячы на ​​тое, што выкананне нашага скрыпту з адной каманды завяршылася, гэта дазволіла нам зрабіць опцыя RemainAfterExit=true.

Бяспека. Прывілеі кантэйнераў ^

Бо ўсе працэсы кантэйнера фактычна выконваюцца ў ізаляцыі на хаставой сістэме выкарыстоўваючы яго ядро, то для дадатковай абароны доступу працэсаў кантэйнера да сістэмы хаста LXD прапануе прывілеяванасць працэсаў, дзе:

• Прывелеяваныя кантэйнеры - Гэта кантэйнеры у якіх працэсы з UID і GID адпавядаюць таму ж уладальніку, што і на хаставой сістэме. Напрыклад, працэс запушчаны ў кантэйнеры з UID роўным 0 мае ўсё тыя ж правы доступу, што і працэс хаставой сістэмы з UID роўным 0. Іншымі словамі, root карыстач у кантэйнеры валодае ўсімі правамі не толькі ў кантэйнеры, але і на хаставой сістэме калі ён зможа выйсці за межы ізаляванай прасторы імёнаў кантэйнера.

• Непривелегированные кантэйнеры - Гэта кантэйнеры у якіх працэсы належаць уладальніку UID і GID з нумарам ад 0 да 65535, але для хаставой сістэмы ўладальнік маскіруецца з дапамогай дадаванага біта SubUID і SubGID адпаведна. Напрыклад, карыстач з UID=0 у кантэйнеры будзе заўважаны ў хаставой сістэме як SubUID + UID. Гэта абараняе хост-сістэму, паколькі, калі які-небудзь працэс у кантэйнеры зможа выйсці са сваёй ізаляванай прасторы імёнаў, ён можа ўзаемадзейнічаць з хост-сістэмай толькі як працэс з невядомым, вельмі высокім UID/GID.

Па змаўчанні, ізноў ствараныя кантэйнеры маюць статут непривелегированных і таму мы павінны вызначыць SubUID і SubGID.

Створым два канфігурацыйных файла ў якіх задамо маску для SubUID і SubGID адпаведна:

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

Для ўжывання змен, сэрвіс LXD павінен быць рэстараваны:

sudo systemctl restart lxd

Стварэнне віртуальнага камутатара сеткі ^

Бо мы раней ініцыялізавалі сетку з дапамогай майстра ініцыялізацыі. lxd init і стварылі сеткавую прыладу lxdbr0, то ў гэтым раздзеле мы проста азнаёмімся з сеткай у LXD і з тым, як ствараць віртуальны камутатар (сеткавы мост, 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: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:ee:7b:5a:6b:44 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet6 fe80::9571:11f3:6e0c:c07b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c2:38:90:df:cb:59 brd ff:ff:ff:ff:ff:ff
    inet 10.0.5.1/24 scope global lxdbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::c038:90ff:fedf:cb59/64 scope link 
       valid_lft forever preferred_lft forever
5: veth3ddab174@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
    link/ether ca:c3:5c:1d:22:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Профіль канфігурацыі ^

Кожны кантэйнер у LXD мае сваю ўласную канфігурацыю і можа пашыраць яе з дапамогай глабальна дэкларуемых канфігурацый якія называюцца профілямі канфігурацыі. Ужыванне профіляў канфігурацыі да кантэйнера мае каскадную мадэль, наступны прыклад дэманструе гэта:

У гэтым прыкладзе, у сістэме LXD створаны тры профіля: default, hddpool и hostfs. Усе тры профіля ўжытыя да кантэйнера ў якога маецца лакальная канфігурацыя (шэрая зона). Профіль default мае прыладу root у якога параметр pool роўны ssdpool, але дзякуючы каскаднай мадэлі прымянення канфігурацыі мы можам прымяніць для кантэйнера профіль hddpool у якога параметр pool перакрые гэты ж параметр з профілю default і кантэйнер атрымае канфігурацыю прылады root з параметрам pool роўным hddpool, а профіль hostfs проста дадае новую прыладу ў кантэйнер.

Для таго каб убачыць спіс даступных профіляў канфігурацыі служыць наступная каманда:

lxc profile list

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

Поўны спіс даступных каманд для працы з профілем можна атрымаць дадаўшы ключ --help:

lxc profile --help

Description:
  Manage profiles

Usage:
  lxc profile [command]

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

Рэдагаванне профілю ^

Профіль канфігурацыі па змаўчанні default не мае канфігурацыі сеткавай карты для кантэйнера і ўсё ізноў ствараныя кантэйнеры не маюць сетку, для іх неабходна ствараць лакальныя (вылучаныя) прылады сеткі асобнай камандай, але мы можам стварыць у профілі канфігурацыі глабальная сеткавая прылада якое будзе падзяляцца паміж усімі кантэйнерамі выкарыстоўвалымі гэты профіль. Такім чынам, адразу пасля каманды стварэння новага кантэйнера ў іх будзе сетка з доступам у сетку. Пры гэтым, няма абмежаванняў, мы заўсёды можам пазней стварыць лакальную сеткавую прыладу калі будзе ў гэтым неабходнасць.

Наступная каманда дадасць у профіль канфігурацыі прыладу eth0 тыпу nic які далучаецца да сеткі lxdbr0:

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

Важна адзначыць, што бо мы фактычна дадалі прыладу ў профіль канфігурацыі, то калі б мы паказалі ў прыладзе статычны IP адрас, то ўсе кантэйнеры якія будуць ужываць гэты профіль падзеляць адзін і той жа IP адрас. Калі ёсць неабходнасць стварыць кантэйнер з вылучаным для кантэйнера статычным IP адрасам, тады варта стварыць канфігурацыю сеткавай прылады на ўзроўні кантэйнера (лакальная канфігурацыя) з параметрам IP адрасы, а не на ўзроўні профіля.

Праверым профіль:

lxc profile show default

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

У гэтым профілі мы можам убачыць, што для ўсіх ізноў ствараных кантэйнераў будуць створаны дзве прылады (devices):

• eth0 - Прылада тыпу nic злучанае з камутатарам (сеткавым мастом) lxdbr0
• root - Прылада тыпу disk якое выкарыстоўвае пул сховішчы ssdpool

Стварэнне новых профіляў ^

Для выкарыстання раней створаных Басейн захоўвання кантэйнерамі, створым профіль канфігурацыі ssdroot у якім дадамо прыладу тыпу disk з кропкай мантавання / (root) выкарыстоўвалае раней створанае Басейн захоўвання - ssdpool:

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

Аналагічна, ствараем прыладу тыпу disk, але ў гэтым выпадку выкарыстоўвалае Басейн захоўвання - hddpool:

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

Правяраем профілі канфігурацыі:

lxc profile show ssdroot

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

lxc profile show hddroot

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

Рэпазітар вобразаў ^

Кантэйнеры ствараюцца з выяў якія з'яўляюцца адмыслова сабранымі дыстрыбутывамі не мелыя ядры Linux. Таму, перш чым запусціць кантэйнер, ён павінен быць разгорнуты з гэтай выявы. Крыніцай выяў служыць лакальны рэпазітар у які выявы загружаюцца з вонкавых рэпазітараў.

Выдаленыя рэпазітары вобразаў ^

Па змаўчанні LXD наладжаны на атрыманне выяў з трох выдаленых крыніц:

• ubuntu: (for stable Ubuntu images)
• ubuntu-daily: (for daily Ubuntu images)
• выявы: (для bunch of other distros)

lxc remote list

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

Напрыклад, рэпазітар ubuntu: мае наступныя выявы:

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

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

Каб вывесці абмежаваную колькасць калонак мы выкарыстоўвалі опцыю -c з параметрамі dasut, а таксама абмежавалі даўжыню спісу камандай head.

Для вываду спісу выяў даступная фільтраванне. Наступная каманда выведзе спіс усіх даступных архітэктур дыстрыбутыва AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Лакальны рэпазітар вобразаў ^

Для пачатку эксплуатацыі кантэйнера неабходна дадаць выяву з глабальнага рэпазітара ў лакальны. local:. Цяпер лакальны рэпазітар пусты, пераканаецца ў гэтым нам дасць каманда. lxc image list. Калі метаду list не паказаць рэпазітар, то па змаўчанні будзе выкарыстоўвацца лакальны рэпазітар local:

lxc image list local:

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

Кіраванне выявамі ў рэпазітары вырабляецца наступнымі метадамі:

Каманда
Апісанне

lxc image псеўданім
Manage image aliases

lxc image копія
Copy images between servers

lxc image выдаляць
Выдаліць выявы

lxc image рэдагаваць
Edit image properties

lxc image экспарт
Export and download images

lxc image імпарт
Import images into the image store

lxc image інфармацыя
Show useful information about images

lxc image спіс
List images

lxc image абнаўленне
Refresh images

lxc image Паказваць
Show image properties

Капіяваны выява ў лакальны рэпазітар з глабальнага images::

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

Image copied successfully!

Вывядзем спіс усіх вобразаў даступных зараз у лакальным рэпазітары local::

lxc image -c lfdatsu list local:

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

Канфігурацыя LXD ^

Акрамя інтэрактыўнага рэжыму, LXD падтрымлівае таксама неінтэрактыўны рэжым усталёўкі канфігурацыі, гэта калі канфігурацыя задаецца ў выглядзе YAML-файла, адмысловага фармату, які дазваляе ўсталяваць усю канфігурацыю за адзін раз, абыходзячы выкананні мноства інтэрактыўных каманд якія былі разгледжаны вышэй у гэтым артыкуле, у тым ліку канфігурацыю сеткі, стварэнне профіляў канфігурацыі і т.д. Тут мы не будзем разглядаць гэтую вобласць, вы можаце самастойна азнаёміцца ​​з гэтым у дакументацыі.

Наступная інтэрактыўная каманда lxc config якую мы разгледзім, дазваляе ўсталёўваць канфігурацыю. Напрыклад, для таго, каб загружаныя выявы ў лакальны рэпазітар не абнаўляліся аўтаматычна з глабальных рэпазітараў, мы можам уключыць гэтыя паводзіны наступнай камандай:

lxc config set images.auto_update_cached=false

Стварэнне і кіраванне кантэйнерам ^

Для стварэння кантэйнера служыць каманда lxc init якой перадаюцца значэння репозиторий:образ і затым жаданы ідэнтыфікатар для кантэйнера. Рэпазітар можа быць пазначаны як лакальны local: так і любы глабальны. Калі рэпазітар не паказаны, то па змаўчанні, для пошуку выявы выкарыстоўваецца лакальны рэпазітар. Калі выява паказаны з глабальнага рэпазітара, то ў пачатку выява будзе загружаны ў лакальны рэпазітар, а затым выкарыстаны для стварэння кантэйнера.

Выканаем наступную каманду каб стварыць наш першы кантэйнер:

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

Разбяром па парадку ключы каманды якія мы тут выкарыстоўваем:

• alpine3 - Указваецца альяс (псеўданім) для выявы які раней быў загружаны ў лакальны рэпазітар. Калі б альяс быў не створаны для гэтай выявы, то заўсёды можна спаслацца на выяву па ім выяве. адбітак пальца які выводзіцца ў табліцы.
• alp - Задаецца ідэнтыфікатар для кантэйнера
• --storage - Гэты ключ паказвае ў якім Басейн захоўвання будзе створаны кантэйнер
• --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 мы можам пераканацца, што гэты кантэйнер выкарыстоўвае два профіля канфігурацыі — default и hddroot. У секцыі devices мы можам выявіць толькі адна прылада, бо сеткавая прылада была створана на ўзроўні профіля default. Для таго, каб убачыць усе прылады выкарыстоўваныя кантэйнерам неабходна дадаць ключ --expanded:

lxc config show alp --expanded

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

Ўстаноўка статычнага IP адрасу ^

Калі мы паспрабуем усталяваць IP адрас для сеткавай прылады eth0 камандай lxc config device set alp прызначанай для канфігурацыі кантэйнера, то мы атрымаем памылку якая паведаміць, што прылада не існуе таму што прылада eth0 якое выкарыстоўваецца кантэйнерам належыць профілі default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Мы можам вядома ўсталяваць статычны IP адрас для eth0 прылады ў профілі, але ён будзе адзіны для ўсіх кантэйнераў якія гэты профіль будуць выкарыстоўваць. Таму, дадамо выдзеленую для кантэйнера прыладу:

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

Затым трэба рэстартаваць кантэйнер:

lxc restart alp

Калі мы зараз паглядзім на канфігурацыю кантэйнера, то нам не трэба прымяняць опцыю --expanded каб убачыць сеткавую прыладу eth0, бо мы стварылі яго на ўзроўні кантэйнера і яно каскадна перакрыла гэта ж прылада з профілю default:

lxc config show alp

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

Выдаленне кантэйнера ^

Для выдалення кантэйнера служыць каманда lxc delete, Але перш чым выдаліць кантэйнер, ён павінен быць спынены з дапамогай каманды lxc stop:

lxc stop alp

lxc list

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

Пасля таго як мы пераканаліся, што стан кантэйнера стала STOPPED, яго можна выдаліць з Басейн захоўвання:

lxc delete alp

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

Для выканання каманд у кантэйнеры, наўпрост, абыходзячы сеткавыя злучэнні, служыць каманда lxc exec якая выконвае каманды ў кантэйнеры без запуску сістэмнай абалонкі. Калі вам трэба выканаць каманду ў абалонцы, выкарыстоўваючы shell патэрны, такія як зменныя, файлавыя перанакіраванні (pipe) і г.д., то неабходна відавочна запускаць абалонку і перадаваць каманду ў якасці ключа, напрыклад:

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

У камандзе быў задзейнічаны спецзнак экранавання для спецзнака $ каб пераменная $HOME не інтэрпрэтавалася на хаставой машыне, а была інтэрпрэтаваная толькі ўнутры кантэйнера.

Таксама, магчыма запусціць інтэрактыўны рэжым абалонкі, а пасля завяршыць сеанс выканаўшы hotkey 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 (ЦП) ^

Для абмежавання рэсурсаў ЦП існуе некалькі тыпаў абмежаванняў:

• limit.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 новых аднолькавых кантэйнера ў адным і тым жа Басейн захоўвання (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

Калі мы паглядзім у другім кантэйнеры, праверым існаванне файла ў тым жа самым месцы, то гэтага файла не будзе, што чакана, бо кантэйнеры ствараюцца ў сваіх уласных Аб'ём захоўвання у гэтым жа Басейн захоўвання:

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 змантаванае як каранёвая частка Басейн захоўвання якое гэтыя кантэйнеры выкарыстоўваюць, таму яны падзяляюць яго аб'ём на дваіх.

Статыстыка спажывання рэсурсаў ^

Прагледзець статыстыку спажывання рэсурсаў для кантэйнера можна з дапамогай каманды:

lxc info alp

Name: alp
Location: none
Remote: unix://
Architecture: x86_64
Created: 2020/04/08 18:05 UTC
Status: Running
Type: container
Profiles: default, hddroot
Pid: 19219
Ips:
  eth0: inet    10.0.5.5        veth2a1dc59d
  eth0: inet6   fe80::216:3eff:fe0e:e271        veth2a1dc59d
  lo:   inet    127.0.0.1
  lo:   inet6   ::1
Resources:
  Processes: 5
  Disk usage:
    root: 495.62kB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 4.79MB
  Network usage:
    eth0:
      Bytes received: 730B
      Bytes sent: 1.59kB
      Packets received: 3
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

Праца са снежкамі ^

У LXD маецца магчымасць стварэння снапшотаў і ўзнаўленні з іх стану кантэйнера.

Каб стварыць снэпшот, выканайце наступную каманду:

lxc snapshot alp snapshot1

У каманды lxc snapshot няма ключа list, таму, каб прагледзець спіс снэпшотаў трэба скарыстацца камандай выводзіць агульную інфармацыю аб кантэйнеры:

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

Аднавіць кантэйнер са снэпшота можна камандай lxc restore паказаўшы кантэйнер для якога будзе праведзена аднаўленне і псеўданім снэпшота:

lxc restore alp snapshot1

Наступная каманда служыць для выдалення снепшота. Звярніце ўвагу, што сінтаксіс каманды не падобны на ўсе астатнія, тут неабходна ўказаць прамы слеш пасля імя кантэйнера. Калі слеш апусціць, то каманда выдалення снэпшота інтэрпрэтуецца як каманда выдалення кантэйнера!

lxc delete alp/snapshot1

У прыведзеным вышэй прыкладзе мы разгледзелі так званыя stateless-снапшоты. У LXD ёсць і іншы тып снапшотаў - stateful, у якіх захоўваецца бягучы стан усіх працэсаў у кантэйнеры. Са stateful-снапшотамі звязаны шэраг цікавых і карысных функцый.

Што яшчэ? ^

• Для Python распрацоўшчыкаў даступны модуль PyLXD які дае API да LXD

UPDATE 10.04.2020 15:00: Дадаў навігацыю

Крыніца: habr.com