LXD — är en systemhanterare för containrar av nästa generation, så står det ClickHouse-Ninja/Proton. Den erbjuder ett användargränssnitt som liknar virtuella maskiner, men använder istället Linux-containrar.

Kärnan LXD — är en privilegierad demon (tjänst som körs med root-rättigheter) som tillhandahåller ett REST API via en lokal unix-socket, samt över nätverket om rätt konfiguration är installerad. Klienter, såsom kommandoradsverktyget som levereras med LXD, skickar förfrågningar via detta REST API. Det betyder att oavsett om du kontaktar den lokala värden eller en fjärransluten, fungerar allting likadant.

I den här artikeln kommer vi inte att gå in på koncepten LXD i detalj, vi kommer inte att diskutera alla tillgängliga möjligheter som beskrivs i dokumentationen, inklusive den senaste implementeringen i de senaste versionerna av LXD med stöd för virtuella maskiner QEMU parallellt med containrar. Istället kommer vi att lära oss om de grundläggande administrationsfunktionerna för containrar — vi ska konfigurera lagringspooler, nätverk, starta en container, tillämpa resursgränser och titta på hur man använder snapshots, så att du får en grundläggande förståelse för LXD och hur man använder containrar i Linux.

För att få fullständig information ska du hänvisa till den officiella källan:

• Utvecklarens webbplats
• Dokumentation
• Forum

Navigation

• Installation av LXD
  • Installation av LXD i Ubuntu-distributioner
  • Installation av LXD i Arch Linux-distributioner
• Lagring LXD (Storage)
• Initialisering av LXD
  • Val av filsystem för lagringspool
  • Initialisering av nätverk och lagringspool med hjälp av guiden
  • Skapa en ytterligare lagringspool
    • Öka storleken på lagringspoolen
    • Autointegrering av loopback-filen i loopback-enhetsslot
  • Säkerhet. Behörigheter för containrar
  • Skapa en virtuell nätverksbrygga
  • Konfigurationsprofil
    • Redigera profil
    • Skapa nya profiler
  • Bildrepo
    • Fjärrbildrepo
    • Lokalt bildrepo
  • Konfiguration av LXD
• Skapa och hantera containrar
  • Ange statisk IP-adress
  • Ta bort container
  • Åtkomst till container
  • Resurshantering för containrar
    • Resursbegränsning RAM (minne)
    • Resursbegränsning CPU (processor)
    • Begränsning av lagringsutrymme
    • Statistik om resursanvändning
  • Arbeta med snapshots

Installation av LXD ^

Installation av LXD i Ubuntu-distributioner ^

I Ubuntu-distributionen 19.10 har paketet lxd en översättning till snap-paket:

apt search lxd

lxd/eoan 1:0.7 all
  Övergångspaket - lxd -> snap (lxd)

Det betyder att två paket kommer att installeras samtidigt, ett systempaket och ett annat som snap-paket. Installation av två paket i systemet kan skapa ett problem där systempaketet kan bli ett föräldralöst paket om snap-paketet tas bort av snap-paketshanteraren.

Hitta paket lxd i snap-repositoriet kan göras med följande kommando:

snap find lxd

Namn             Version        Sammanfattning
lxd              3.21           Systemcontainerhanterare och API
lxd-demo-server  0+git.6d54658  Online mjukvarudemo-sessioner med LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Imagebyggare för LXC och LXD
fabrica          0.1            Bygg snap-paket genom att helt enkelt peka ett formulär till...
satellite        0.1.2          Avancerad skalbar öppen källkod intelligensplattform

Genom att köra kommandot list kan man försäkra sig om att paketet lxd inte är installerat än:

snap list

Namn  Version    Rev   Spårning  Utgivare   Noter
core  16-2.43.3  8689  stabil    canonical✓  core

Trots att LXD är ett snap-paket, måste det installeras via ett systempaket lxd, som kommer att skapa en motsvarande grupp i systemet, nödvändiga verktyg i /usr/bin och så vidare.

sudo apt update
sudo apt install lxd

Låt oss se till att paketet är installerat som ett snap-paket:

snap list

Namn  Version    Rev    Spårning  Utgivare   Noter
core  16-2.43.3  8689   stabil    canonical✓  core
lxd   3.21       13474  stabil/…  canonical✓  -

Installation av LXD i Arch Linux-distributioner ^

För att installera LXD-paketet i systemet måste följande kommandon köras, det första — uppdaterar listan över tillgängliga paket i systemets repository, det andra — installerar paketet direkt:

sudo pacman -Syyu && sudo pacman -S lxd

Efter installationen av paketet, för att hantera LXD som en vanlig användare, måste han läggas till i systemgruppen lxd:

sudo usermod -a -G lxd user1

Låt oss se till att användaren user1 har lagts till i gruppen lxd:

id -Gn user1

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

Om gruppen lxd inte syns i listan, behöver man aktivera användarsessionen igen. För detta måste man logga ut och logga in i systemet med samma användare.

Aktivera systemd LXD-tjänsten att starta vid systemstart:

sudo systemctl enable lxd

Startar tjänsten:

sudo systemctl start lxd

Kontrollerar tjänstens status:

sudo systemctl status lxd

Lagring LXD (Storage) ^

Innan initieringen måste vi förstå hur lagringen i LXD är logiskt strukturerad.

Lagring (Storage) består består av en eller flera Storage Pool som använder ett av de stödda filsystemen som ZFS, BTRFS, LVM eller vanliga kataloger. Varje Storage Pool delas upp i volymer (Storage Volume) som innehåller bilder, containrar eller data för andra ändamål.

• Avbilder — är specialt sammanställda distributioner utan Linux-kärna och tillgängliga från externa källor
• Containrar — är distribuerade distributioner från avbilder som är klara för drift
• Snapshots — är tillståndsbilder av containrar som man kan återgå till

För att hantera lagring i LXD används kommandot lxc storage varifrån man kan få hjälp genom att ange nyckeln — lxc storage --help

Följande kommando visar en lista över alla Storage Pool i LXD-lagring:

lxc storage list

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

För att se listan över alla Storage Volume i det valda Storage Pool används kommandot 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       |
+-----------+----------------------------------+-------------+---------+

Dessutom, om för Storage Pool en filsystem BTRFS valdes vid skapandet, kan man få en lista över Storage Volume eller subvolymer i BTRFS-tolkning med hjälp av verktygen för detta filsystem:

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

Initialisering av LXD ^

Innan containrar skapas och används, är det nödvändigt att utföra den grundläggande initieringen av LXD som skapar och konfigurerar nätverket samt lagringen. Detta kan göras manuellt med hjälp av grundläggande klientkommandon som finns i listan genom att anropa kommandot lxc --help eller med hjälp av installationsguiden lxd init genom att svara på några frågor.

Val av filsystem för lagringspool ^

Under LXD initialization, several questions are asked, including the type of file system for the default configuration. Storage PoolBy default, the BTRFS file system is selected for it. It will not be possible to change to another file system after creation.The following file systems are offered for selection: a comparison table of capabilities:

Funktion
Directory
Btrfs
LVM
ZFS
CEPH

Optimerad bildlagring
nej
ja
ja
ja
ja

Optimerad instanskapande
nej
ja
ja
ja
ja

Optimerad snapshotskapande
nej
ja
ja
ja
ja

Optimerad bildöverföring
nej
ja
nej
ja
ja

Optimerad instansöverföring
nej
ja
nej
ja
ja

Copy on write
nej
ja
ja
ja
ja

Blockbaserad
nej
nej
ja
nej
ja

Ögonblicklig kloning
nej
ja
ja
ja
ja

Lagringsdrivrutin användbar inom en behållare
ja
ja
nej
nej
nej

Återställ från äldre snapshots (inte senaste)
ja
ja
ja
nej
ja

Lagringskvoter
ja(*)
ja
ja
ja
nej

Initialisering av nätverk och lagringspool med hjälp av guiden ^

Den nästa kommandon vi kommer att titta på erbjuder att konfigurera huvudkomponenterna i LXD genom svar på enkla frågor med hjälp av en initieringsguid.

Kör kommandot lxc init och ange svaren på frågorna efter kolon som visas i exemplet nedan eller ändra dem enligt dina omständigheter:

lxd init

Vill du använda LXD-klustering? (ja/nej) [standard=nej]: 
Vill du konfigurera en ny lagringspool? (ja/nej) [standard=ja]: 
Namn på den nya lagringspoolen [standard=default]: ssdpool         
Namn på lagringsbackend att använda (lvm, btrfs, dir) [standard=btrfs]: 
Vill du skapa en ny BTRFS-pool? (ja/nej) [standard=ja]: 
Vill du använda en befintlig blockenhet? (ja/nej) [standard=nej]: 
Storlek i GB på den nya loop-enheten (minst 1GB) [standard=15GB]: 10GB
Vill du ansluta till en MAAS-server? (ja/nej) [standard=nej]: 
Vill du skapa en ny lokal nätverksbro? (ja/nej) [standard=ja]: 
Vad ska den nya bron kallas? [standard=lxdbr0]: 
Vilken IPv4-adress ska användas? (CIDR-subnätnotation, “auto” eller “none”) [standard=auto]: 10.0.5.1/24
Vill du att LXD ska NAT IPv4-trafik på din bro? [standard=ja]: 
Vilken IPv6-adress ska användas? (CIDR-subnätnotation, “auto” eller “none”) [standard=auto]: ingen
Vill du att LXD ska vara tillgängligt över nätverket? (ja/nej) [standard=nej]: 
Vill du att föråldrade cachelagrade bilder ska uppdateras automatiskt? (ja/nej) [standard=ja] nej
Vill du att en YAML "lxd init" preseed ska skrivas ut? (ja/nej) [standard=nej]: 

Skapa en ytterligare lagringspool ^

I det föregående steget skapade vi Storage Pool som vi gav namnet ssdpool och vars fil ligger på min dator på adressen /var/lib/lxd/disks/ssdpool.img. Denna filsystemadress motsvarar den fysiska SSD-disken i min dator.

De följande åtgärderna, för att utöka förståelsen av vilken roll Storage Pool spelar i lagringen, kommer vi att skapa en andra Storage Pool som kommer att ligga fysiskt på en annan typ av disk, på HDD. Problemet är att LXD inte tillåter skapelse Storage Pool utanför adressen /var/lib/lxd/disks/ och inte ens symboliska länkar kommer att fungera, se utvecklarens svar. Vi kan kringgå denna begränsning vid initiering/formatering Storage Pool genom att ange värdet som en blockenhet istället för en sökväg till en loopback-fil genom att ange detta i nyckeln source.

Så, före skapandet Storage Pool Du måste ange en loopback-fil eller en befintlig partition i ditt filsystem som den kommer att använda. För detta ska vi skapa och använda en fil som begränsas till 10 GB:

dd if=/dev/zero of=/mnt/work/lxd/hddpool.img bs=1MB count=10000

10000+0 poster in
10000+0 poster ut
10000000000 byte (10 GB, 9,3 GiB) kopierat, 38,4414 s, 260 MB/s

Vi kopplar loopback-filen till en ledig loopback-enhet:

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

/dev/loop1

Tack vare nyckeln --show returnerar kommandots utförande namnet på enheten som vår loopback-fil har kopplats till. Vid behov kan vi visa en lista över alla upptagna enheter av detta slag, för att säkerställa att våra åtgärder var korrekta:

losetup -l

NAMN        STORLEK BEGRÄNSNING OFFSET AUTOCLEAR RO BACK-FIL                      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

Från listan kan man upptäcka att enheten /dev/loop1 har en loopback-fil kopplad /mnt/work/lxd/hddpool.img, och enheten /dev/loop0 har en loopback-fil kopplad /var/lib/lxd/disks/ssdpool.img som motsvarar standard Storage Pool.

Nästa kommando skapar en ny Storage Pool i LXD baserat på den just förberedda loopback-filen. LXD kommer att formatera loopback-filen /mnt/work/lxd/hddpool.img i enheten /dev/loop1 till BTRFS-filsystemet:

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

Vi listar alla Storage Pool på skärmen:

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAMN  | BESKRIVNING | DRIVARE |             KÄLLA              | ANVÄND AV |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | /dev/loop1                     | 0       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | /var/lib/lxd/disks/ssdpool.img | 0       |
+---------+-------------+--------+--------------------------------+---------+

Öka storleken på lagringspoolen ^

Efter skapandet Storage Pool, om nödvändigt kan den utökas. För Storage Pool baserat på BTRFS-filsystemet, kör följande kommandon:

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

Autointegrering av loopback-filen i loopback-enhetsslot ^

Vi har ett litet problem, vid omstart av värdsystemet kommer filen /mnt/work/lxd/hddpool.img "att "flyga ut" ur enheten /dev/loop1 och LXD-tjänsten kommer att krascha vid uppstart eftersom den inte ser den i denna enhet. För att lösa detta problem måste vi skapa en systemtjänst som kommer att montera denna fil i enheten /dev/loop1 vid uppstart av värdsystemet.

Vi skapar -tester i projektet, samt i relation till filer. fil av typen service på /etc/systemd/system/ för systeminitiering 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

Vi aktiverar tjänsten:

sudo systemctl enable lxd-hddpool

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

Efter omstart av värdsystemet kontrollerar vi statusen för tjänsten:

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Lagringspool (hddpool)
     Laddad: laddad (/etc/systemd/system/lxd-hddpool.service; aktiverad; leverantörens förinställning: inaktiverad)
     Aktiv: aktiv (utgången) sedan ons 2020-04-08 03:43:53 MSK; 1min 37s sedan
    Process: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (kod=utgången, status=0/SUCCES)
   Huvud-PID: 711 (kod=utgången, status=0/SUCCES)

apr 08 03:43:52 manjaro systemd[1]: Startar Losetup LXD Lagringspool (hddpool)...
apr 08 03:43:53 manjaro systemd[1]: Klarade Losetup LXD Lagringspool (hddpool).

Från utskriften kan vi bekräfta att tjänstens tillstånd är active, trots att körningen av vårt skript från en enda kommando avslutades, detta möjliggjordes av alternativet RemainAfterExit=true.

Säkerhet. Behörigheter för containrar ^

Eftersom alla processer i containern faktiskt körs isolerat på värdsystemet med hjälp av dess kärna, erbjuder LXD en privilegium för containerns processer för att ytterligare skydda åtkomsten till värdsystemet, där:

• Privilegierade containrar — är containrar där processerna har UID och GID som motsvarar samma ägare som på värdsystemet. Till exempel, en process som körs i en container med UID lika med 0 har alla samma åtkomsträttigheter som processen på värdsystemet med UID lika med 0. Med andra ord har root-användaren i containern alla rättigheter inte bara i containern utan också på värdsystemet om han kan gå utanför den isolerade namnområdet.

• Icke-privilegierade containrar — är containrar där processerna tillhör ägaren med UID och GID mellan 0 och 65535, men för värdsystemet maskeras ägaren med hjälp av den tillagda SubUID- och SubGID-biten. Till exempel, en användare med UID=0 i containern kommer att betraktas på värdsystemet som SubUID + UID. Detta skyddar värdsystemet, eftersom om någon process i containern lyckas gå ut ur sitt isolerade namnområde kan den interagera med värdsystemet endast som en process med en okänd, mycket hög UID/GID.

Som standard har nyligen skapade containrar status som icke-privilegierade och därför måste vi definiera SubUID och SubGID.

Vi skapar två konfigurationsfiler där vi ställer in masken för SubUID och SubGID respektive:

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

För att tillämpa ändringarna måste LXD-tjänsten startas om:

sudo systemctl restart lxd

Skapa en virtuell nätverksbrygga ^

Eftersom vi tidigare har initierat nätverket med hjälp av guiden för initiering lxd init och skapat en nätverksenhet lxdbr0, så kommer vi i detta avsnitt bara att bekanta oss med nätverket i LXD och hur man skapar en virtuell switch (nätverksbro) med hjälp av klientkommandot.

Den följande schemat visar hur switchen (nätverksbron) kopplar ihop värden och containrar i nätverket:

Containrar kan interagera via nätverket med andra containrar eller värden som dessa containrar körs på. För detta behöver vi länka de virtuella nätverksgränssnitten i containrarna med den virtuella switchen. Först kommer vi att skapa switchen, och nätverksgränssnitten för containern kommer att länkas i senare kapitel, efter att containern har skapats.

Det följande kommandot skapar en switch med ett undermedverkan 10.0.5.0/24 och en IPv4-adress 10.0.5.1/24, samt aktiverar ipv4.nat så att containrarna kan få internet genom värden med hjälp av NAT-tjänsten:

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

Kontrollera listan över nätverksenheter som är tillgängliga för LXD:

lxc network list

+--------+----------+---------+-------------+---------+
|  NAMN  |   TYP    | HANDBOK | BESKRIVNING  | ANVÄNDS AV |
+--------+----------+---------+-------------+---------+
| eno1   | fysisk   | NEJ     |             | 0       |
+--------+----------+---------+-------------+---------+
| lxdbr0 | bro      | JA      |             | 0       |
+--------+----------+---------+-------------+---------+

Du kan också verifiera skapandet av nätverksenheten med hjälp av det inbyggda verktyget i Linux-distributionen — ip link eller 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

Konfigurationsprofil ^

Varje container i LXD har sin egen konfiguration och kan utökas med hjälp av globalt deklarerade konfigurationer som kallas konfigurationsprofiler. Tillämpningen av konfigurationsprofiler på en behållare har en kaskadmodell, följande exempel visar detta:

I det här exemplet har tre profiler skapats i LXD-systemet: default, hddpool och hostfs. Alla tre profiler har tillämpats på en behållare som har en lokal konfiguration (grå zon). Profilen default har en enhet root som har parametern pool är ssdpool, men tack vare den kaskadmodell för tillämpning av konfiguration kan vi tillämpa profilen för behållaren hddpool som har parametern pool överskrider denna samma parameter från profilen default och behållaren får enhetskonfigurationen root med parametern pool lika med hddpool, medan profilen hostfs bara lägger till en ny enhet i behållaren.

För att se listan över tillgängliga konfigurationsprofiler används följande kommando:

lxc profile list

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

Den kompletta listan över tillgängliga kommandon för att arbeta med profiler kan fås genom att lägga till nyckeln --help:

lxc profile --help

Description:
  Hantera profiler

Usage:
  lxc profile [kommando]

Available Commands:
  add         Lägg till profiler till instanser
  assign      Tilldela profiler till instanser
  copy        Kopiera profiler
  create      Skapa profiler
  delete      Ta bort profiler
  device      Hantera enhetsinstanser
  edit        Redigera profilkonfigurationer som YAML
  get         Hämta värden för profilkonfigurationsnycklar
  list        Lista profiler
  remove      Ta bort profiler från instanser
  rename      Byt namn på profiler
  set         Ställ in profilkonfigurationsnycklar
  show        Visa profilkonfigurationer
  unset       Avmarkera profilkonfigurationsnycklar

Redigera profil ^

Standardkonfigurationsprofilen default har ingen nätverkskortkonfiguration för behållaren, och alla nyss skapade behållare har ingen nätverksanslutning. För dem är det nödvändigt att skapa lokala (dedikerade) nätverksenheter med ett separat kommando, men vi kan skapa en global nätverksenhet i konfigurationsprofilen som delas mellan alla behållare som använder denna profil. På så sätt kommer de omedelbart efter skapandet av en ny behållare att ha nätverksanslutning. Det finns inga begränsningar, vi kan alltid skapa en lokal nätverksenhet senare om det skulle vara nödvändigt.

Nästa kommando kommer att lägga till en enhet i konfigurationsprofilen eth0 av typen nic ansluten till nätverket lxdbr0:

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

Det är viktigt att notera att eftersom vi faktiskt har lagt till en enhet i konfigurationsprofilen, om vi skulle ange en statisk IP-adress för enheten, skulle alla containrar som använder denna profil dela samma IP-adress. Om det är nödvändigt att skapa en container med en dedikerad statisk IP-adress, bör man istället skapa en nätverkskonfigurationsprofil på containernivå (lokal konfiguration) med IP-adressparametern, istället för på profilenivån.

Låt oss kontrollera profilen:

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

I denna profil kan vi se att två enheter (devices) kommer att skapas för alla ny skapade containrar:

• eth0 — Enhetstyp nic ansluten till en switch (nätverksbro) lxdbr0
• root — Enhetstyp disk som använder lagringspoolen ssdpool

Skapa nya profiler ^

För att använda de tidigare skapade Storage Pool containrar, skapar vi en konfigurationsprofil ssdroot där vi lägger till enhetstypen disk med monteringspunkt / (root) som använder den tidigare skapade Storage Pool — ssdpool:

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

På samma sätt skapar vi en enhet av typen disk, men i detta fall använder Storage Pool — hddpool:

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

Vi kontrollerar konfigurationsprofiler:

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

Bildrepo ^

Containrar skapas från bilder som är speciellt sammanställda distributioner utan en Linux-kärna. Därför, innan en container kan startas, måste den distribueras från denna bild. Källan till bilder är det lokala arkivet där bilder laddas ner från externa arkiv.

Fjärrbildrepo ^

Som standard är LXD konfigurerat för att hämta bilder från tre externa källor:

• ubuntu: (för stabila Ubuntu-bilder)
• ubuntu-daily: (för dagliga Ubuntu-bilder)
• images: (för en mängd andra distributioner)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NAMN      |                   URL                    | OFFENTLIG | STATISK |
+-----------------+------------------------------------------+--------+--------+
| bilder          | https://images.linuxcontainers.org       | JA     | NEJ    |
+-----------------+------------------------------------------+--------+--------+
| lokal (standard) | unix://                                  | NEJ    | JA     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | JA     | JA     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | JA     | JA     |
+-----------------+------------------------------------------+--------+--------+

Till exempel har repot ubuntu: följande bilder:

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

+----------------------------------------------+--------------+----------+------------+
|                   BESKRIVNING                | ARCHITEKTUR  |   STORLEK |   TYP     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | BEHÅLLARE  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | BEHÅLLARE  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | BEHÅLLARE  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | BEHÅLLARE  |
+----------------------------------------------+--------------+----------+------------+

För att visa ett begränsat antal kolumner använde vi alternativet -c med parametrarna dasut, och begränsade också längden på listan med kommandot head.

För att visa listan över tillgängliga bilder kan filtrering användas. Följande kommando visar listan över alla tillgängliga distributioners arkitekturer AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Lokalt bildrepo ^

För att börja använda containern måste du lägga till en bild från det globala arkivet till det lokala. lokal:. Just nu är det lokala arkivet tomt, vilket kommer att bekräftas av kommandot lxc image list. Om metoden list inte anger ett arkiv kommer det lokala arkivet att användas som standard — lokal:

lxc image list local:

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

Hantera bilder i arkivet görs med följande metoder:

Team
Beskrivning

lxc image alias
Hantera bildalias

lxc image copy
Kopiera bilder mellan servrar

lxc image ta bort
Ta bort bilder

lxc image edit
Redigera bildens egenskaper

lxc image export
Exportera och ladda ner bilder

lxc image import
Importera bilder till bildlagret

lxc image info
Visa användbar information om bilder

lxc image list
Lista bilder

lxc image refresh
Uppdatera bilder

lxc image visa
Visa bildens egenskaper

Kopiera bilden till det lokala arkivet från det globala images::

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

Bild kopierad framgångsrikt!

Vi kommer att visa en lista över alla bilder som för närvarande är tillgängliga i det lokala arkivet. lokal::

lxc image -c lfdatsu list local:

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

Konfiguration av LXD ^

Förutom interaktivt läge stöder LXD även icke-interaktiv installation av konfiguration, detta innebär att konfigurationen anges i form av en YAML-fil, ett specialformat som gör det möjligt att ställa in hela konfigurationen på en gång, utan att behöva utföra flera interaktiva kommandon som har diskuterats ovan i denna artikel, inklusive nätverkskonfiguration, skapande av konfigurationsprofiler m.m. Här kommer vi inte att behandla detta område, du kan själv bekanta dig med detta. i dokumentationen.

Det följande interaktiva kommandot lxc config som vi kommer att behandla, tillåter att ställa in konfigurationen. Till exempel, för att de uppladdade bilderna i det lokala arkivet inte ska uppdateras automatiskt från globala arkiv, kan vi aktivera detta beteende med följande kommando:

lxc config set images.auto_update_cached=false

Skapa och hantera containrar ^

För att skapa en container används kommandot lxc init som tar emot värden arkiv:bild och sedan önskat identifierare för containern. Arkivet kan anges som lokalt. lokal: även om vilket som helst globalt. Om inget register anges, används som standard det lokala registret för att söka efter bilden. Om bilden anges från det globala registret, laddas först bilden upp till det lokala registret och används sedan för att skapa containern.

Låt oss köra följande kommando för att skapa vår första container:

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

Låt oss gå igenom kommandots nycklar som vi här använder:

• alpine3 — Detta anges som alias (smeknamn) för bilden som tidigare laddats upp till det lokala registret. Om inget alias skapades för denna bild kan den alltid refereras till med dess Fingerprint som visas i tabellen.
• alp — Här anges identifieraren för containern.
• --storage — Denna nyckel anger i vilket Storage Pool containern kommer att skapas.
• --profile — Dessa nycklar tillämpar kaskadkonfigurationen på containern från tidigare skapade konfigurationsprofiler.

Vi startar containern, som börjar köra init-systemet för distributionen:

lxc start alp

Du kan också använda kommandot lxc launch vilket tillåter att kombinera kommandon lxc init och lxc start till en enda operation.

Kontrollera tillståndet för containern:

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

Kontrollera konfigurationen för containern:

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

I avsnittet profiler vi kan säkerställa att denna container använder två konfigurationsprofiler — default och hddroot. I sektionen devices kan vi upptäcka att det endast finns en enhet, eftersom nätverksenheten skapades på profilsnivå. default. För att se alla enheter som används av containern måste du lägga till nyckeln --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: ""

Ange statisk IP-adress ^

Om vi försöker ställa in en IP-adress för nätverksenheten eth0 med kommandot lxc config device set alp som är avsedd för kontrollering av containern, kommer vi få ett felmeddelande som säger att enheten inte finns eftersom enheten eth0 som används av containern tillhör profilen default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: Enheten finns inte

Vi kan självklart ställa in en statisk IP-adress för eth0 enheten i profilen, men den kommer att vara densamma för alla containrar som använder denna profil. Därför lägger vi till en dedikerad enhet för containern:

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

Därefter måste containern startas om:

lxc restart alp

Om vi nu kollar konfigurationen av containern behöver vi inte tillämpa alternativet --expanded för att se nätverksenheten eth0, eftersom vi har skapat den på containernivå och den har kaskadöverskrivit samma enhet från profilen default:

lxc config show alp

arkitektur: x86_64
konfiguration:
  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
profiler:
- default
- hddroot
stateful: false
description: ""

Ta bort container ^

För att ta bort en behållare används kommandot lxc delete, men innan du tar bort behållaren måste den stoppas med kommandot lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAMN |  STATUS |       IPV4        | IPV6 |   TYP     | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPAD | 10.0.5.10 (eth0)  |      | BEHÅLLARE | 0         |
+------+---------+-------------------+------+-----------+-----------+

När vi har bekräftat att behållarens tillstånd är STOPPAD, kan den tas bort från Storage Pool:

lxc delete alp

Åtkomst till container ^

För att köra kommandon i behållaren direkt, utan nätverksanslutningar, används kommandot lxc exec , vilket utför kommandon i behållaren utan att starta ett skal. Om du behöver köra ett kommando i ett skal, med hjälp av shell-mönster som variabler, filomdirigeringar (pipe) etc., måste skalet startas explicit och kommandot överlämnas som en nyckel, till exempel:

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

Kommandot involverade specialtecknet för undantag för specialtecknet $ så att variabeln $HOME inte tolkades på värdmaskinen, utan bara inuti behållaren.

Det är också möjligt att starta interaktivt läge för skalet, och avsluta sessionen med hotkey CTRL+D:

lxc exec alp -- \/bin\/sh

Resurshantering för containrar ^

I LXD kan resurser för behållaren hanteras med hjälp av en speciell uppsättning konfigurationer. Den kompletta listan över konfigurationsparametrar för behållaren kan hittas i dokumentationen.

Resursbegränsning RAM (minne) ^

Parameter limits.memory begränsar mängden RAM som är tillgänglig för behållaren. Som värde anges ett nummer och en av tillgängliga suffix.

Vi sätter en gräns på behållen RAM på 256 MB:

lxc config set alp limits.memory 256MB

Det finns också andra parametrar för att begränsa minnet:

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

Team lxc config show visar hela konfigurationen av containern, inklusive det tillämpade resurssambandet som har ställts in:

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

Resursbegränsning CPU (processor) ^

För att begränsa CPU-resurser finns det flera typer av begränsningar:

• limit.cpu — binder containern till en eller flera CPU-kärnor
• limits.cpu.allowance — hanterar antingen CFS-schemaläggarens kvoter, när tidsgränsen har överskridits, eller en allmän mekanism för resursdelning, när procentandelen har överskridits
• limits.cpu.priority — schemaläggningsprioritet när flera instanser som delar en uppsättning processorer tilldelas samma procentandel av processorer

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

Begränsning av lagringsutrymme ^

Förutom begränsningar som limits.read, limits.write kan vi också begränsa mängden diskutrymme som containern använder (fungerar endast med ZFS eller BTRFS):

lxc config device set alp root size=2GB

Efter inställningen kan vi i parametern devices.root.size kontrollera den aktuella begränsningen:

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

För att se de använda disk kvoterna kan vi få från kommandot 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

Trots att vi har ställt in en begränsning för det rotanordningen i containern till 2 GB, kommer systemverktyg som df inte att se denna begränsning. För att demonstrera detta kommer vi att genomföra ett litet test och se hur det fungerar.

Vi skapar 2 nya identiska containrar i samma 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
+------+---------+------------------+------+-----------+-----------+
| NAMN |  STATUS  |       IPV4       | IPV6 |   TYP     | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | KÖRANDE | 10.0.5.46 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | KÖRANDE | 10.0.5.30 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+

I en av containrarna skapar vi en fil som är 1 GB stor:

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

Låt oss verifiera att filen har skapats:

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

Om vi tittar i den andra containern och kontrollerar filens existens på samma plats, så kommer filen inte att finnas, vilket är förväntat, eftersom containrarna skapas i sina egna Storage Volume i samma Storage Pool:

lxc exec alp2 -- ls -lh
total 0

Men låt oss jämföra värdena som ges df i de båda containrarna:

lxc exec alp1 -- df -hT
Filsystem           Typ            Storlek      Använd Tillgänglig Använd% Monterad på
\/dev\/loop1           btrfs           9.3G   1016.4M      7.8G  11% \/
...

lxc exec alp2 -- df -hT
Filsystem           Typ            Storlek      Använd Tillgänglig Använd% Monterad på
\/dev\/loop1           btrfs           9.3G   1016.4M      7.8G  11% \/
...

Enheten /dev/loop1 Monterat som rotpartition är Storage Pool vilket dessa containrar använder, så de delar dess kapacitet mellan sig.

Statistik om resursanvändning ^

För att se resursförbrukningsstatistik för containern kan du använda kommandot:

lxc info alp

Namn: alp
Plats: ingen
Fjärr: unix:\/\/ 
Arkitektur: x86_64
Skapad: 2020\/04\/08 18:05 UTC
Status: Körande
Typ: container
Profiler: 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
Resurser:
  Processer: 5
  Diskanvändning:
    root: 495.62kB
  CPU-användning:
    CPU-användning (i sekunder): 1
  Minnesanvändning:
    Minne (nuvarande): 4.79MB
  Nätverksanvändning:
    eth0:
      Mottagna byte: 730B
      Skickade byte: 1.59kB
      Mottagna paket: 3
      Skickade paket: 14
    lo:
      Mottagna byte: 0B
      Skickade byte: 0B
      Mottagna paket: 0
      Skickade paket: 0

Arbeta med snapshots ^

I LXD finns möjligheten att skapa snapshots och återställa containerns tillstånd från dem.

För att skapa en snapshot, kör följande kommando:

lxc snapshot alp snapshot1

Kommandot lxc snapshot har ingen nyckel list, så för att se listan över snapshots måste du använda ett kommando som visar allmän information om containern:

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

Återställa containern från en snapshot görs med kommandot lxc restore ange containern som återställningen ska göras för och aliaset för snapshotet:

lxc restore alp snapshot1

Följande kommando används för att ta bort en snapshot. Observera att syntaxen för kommandot inte liknar de andra, här måste en snedstreck följas efter containerns namn. Om snedstrecket utelämnas, kommer kommandot för att ta bort snapshotet att tolkas som kommandot för att ta bort containern!

lxc delete alp/snapshot1

I det ovanstående exemplet har vi sett så kallade stateless-snapshots. I LXD finns det en annan typ av snapshots — stateful, där det aktuella tillståndet av alla processer i containern sparas. Med stateful-snapshots är det kopplade intressanta och användbara funktioner.

Vad mer? ^

• För Python-utvecklare är modulen tillgänglig PyLXD som tillhandahåller API till LXD

UPPDATERING 10.04.2020 15:00: Jag har lagt till navigering

Källa: habr.com