ProHoster > Blog > Administration > Grundlæggende funktioner i LXD - container systemet i Linux

Grundlæggende funktioner i LXD - container systemet i Linux

Grundlæggende funktioner i LXD - container systemet i Linux

LXD — er en containersystemmanager af næste generation, sådan siger kilde. Det tilbyder et brugergrænseflade, der minder om virtuelle maskiner, men som i stedet bruger Linux-containere.

Kernen LXD — er en privilegeret daemon (service, der kører med root-rettigheder), som giver REST API via en lokal unix-socket, samt over netværket, hvis passende konfiguration er installeret. Klienter, såsom kommandolinjeværktøjet, der leveres med LXD, sender anmodninger gennem dette REST API. Det betyder, at uanset om du henvender dig til den lokale vært eller en fjernbetjening, fungerer alt ens.

I denne artikel vil vi ikke gå i dybden med LXD-konceptet, vi vil ikke gennemgå alle tilgængelige muligheder, der er beskrevet i dokumentationen, herunder den nylige implementering af understøttelse af QEMU virtuelle maskiner parallelt med containere i de seneste versioner af LXD. I stedet vil vi kun lære det grundlæggende i containeradministration — konfigurere lagringspuljer, netværk, starte containere, anvende ressourcegrænser, samt se på, hvordan man bruger snapshots, så du kan få en grundlæggende forståelse af LXD og bruge containere i Linux.

For at få fuld information, bør du se til den officielle kilde:

Navigation

Installation af LXD ^

Installation af LXD på Ubuntu-distributioner ^

I Ubuntu 19.10-distributionen har pakken lxd en overgang til snap-pakke:

apt search lxd

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

Dette betyder, at der vil blive installeret to pakker, en systempakke og en anden som en snap-pakke. Installation af to pakker i systemet kan skabe et problem, hvor systempakken kan blive en forældreløs pakke, hvis snap-pakken fjernes af snap-pakkemanageren.

Find pakke lxd i snap-repositoriet med følgende kommando:

snap find lxd

Navn             Version        Resumé
lxd              3.21           System container manager og API
lxd-demo-server  0+git.6d54658  Online software demo-sessioner med LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Image builder for LXC og LXD
fabrica          0.1            Byg snaps ved simpelthen at pege et webformular til...
satellite        0.1.2          Avanceret skalerbar open source intelligensplatform

Når du har kørt kommandoen list , kan du bekræfte, at pakken lxd endnu ikke er installeret:

snap list

Navn  Version    Rev   Tracking  Udgiver     Noter
core  16-2.43.3  8689  stabil    canonical✓  core

Selvom LXD er en snap-pakke, skal den installeres gennem systempakken lxd, som vil oprette den relevante gruppe i systemet og de nødvendige værktøjer i /usr/bin osv.

sudo apt update
sudo apt install lxd

Lad os sikre os, at pakken er installeret som en snap-pakke:

snap list

Navn  Version    Rev    Tracking  Udgiver     Noter
core  16-2.43.3  8689   stabil    canonical✓  core
lxd   3.21       13474  stabil/…  canonical✓  -

Installation af LXD på Arch Linux-distributioner ^

For at installere LXD-pakken i systemet skal du køre følgende kommandoer; den første opdaterer listen over tilgængelige pakker i systemet fra repositoriet, den anden installerer direkte pakken:

sudo pacman -Syyu && sudo pacman -S lxd

Efter installationen af pakken, for at styre LXD som en almindelig bruger, er det nødvendigt at tilføje den til systemgruppen lxd:

sudo usermod -a -G lxd user1

Lad os sikre os, at brugeren user1 er tilføjet til gruppen lxd:

id -Gn user1

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

Hvis gruppen lxd ikke vises på listen, skal brugersessionen aktiveres igen. For dette skal du logge ud og så logge ind på systemet med den samme bruger.

Aktiver ved systemd opstart af LXD-tjenesten ved systemstart:

sudo systemctl enable lxd

Start the service:

sudo systemctl start lxd

Tjek status for tjenesten:

sudo systemctl status lxd

LXD Storage ^

Inden vi påbegynder initialiseringen, skal vi forstå, hvordan lagringen er logisk struktureret i LXD.

Lagring (Storage) består af en eller flere Storage Pool som bruger et af de understøttede filsystemer såsom ZFS, BTRFS, LVM eller almindelige mapper. Hver Storage Pool er opdelt i volumener (Storage Volume) der indeholder billeder, containere eller data til andre formål.

  • Billeder — det er specielt sammensatte distributioner uden Linux-kerne, som er tilgængelige fra eksterne kilder
  • Containere — det er udvidede distributioner fra billeder, klar til brug
  • Snapshots — det er tilstandsbilleder af containere, man kan vende tilbage til

Grundlæggende funktioner i LXD - container systemet i Linux

Til at styre lageret i LXD bruges kommandoen lxc storage hvor man kan få hjælp ved at angive nøglen — lxc storage --help

Den følgende kommando viser en liste over alle Storage Pool i LXD lager:

lxc storage list

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

For at se listen over alle Storage Volume i den valgte Storage Pool bruges kommandoen 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       |
+-----------+----------------------------------+-------------+---------+

Hvis der for Storage Pool under oprettelsen blev valgt filsystemet BTRFS, kan man få listen over Storage Volume eller subvolumes i BTRFS's fortolkning ved hjælp af værktøjerne til dette 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 af LXD ^

Før oprettelse og brug af containere skal man udføre en generel initialization af LXD, som opretter og konfigurerer netværk samt lager. Dette kan udføres manuelt ved hjælp af standard klientkommandoer, der er tilgængelige i listen ved at kalde kommandoen lxc --help eller ved hjælp af initialiseringsguiden lxd init ved at besvare et par spørgsmål.

Valg af filsystem til Storage Pool ^

Under initialisation, LXD asks several questions, among which is the choice of the file system type for the default. Storage PoolBy default, the BTRFS file system is selected for it. Changing to another file system after creation will be impossible.To select a file system, a comparison table of features:

Funktion
Directory
Btrfs
LVM
ZFS
CEPH

Optimeret billedlagring
nej
yes
yes
yes
yes

Optimeret instansoprettelse
nej
yes
yes
yes
yes

Optimeret snapshotoprettelse
nej
yes
yes
yes
yes

Optimeret billederoverførsel
nej
yes
nej
yes
yes

Optimeret instansoverførsel
nej
yes
nej
yes
yes

Kopier ved skrivning
nej
yes
yes
yes
yes

Blokbaseret
nej
nej
yes
nej
yes

Øjeblikkelig kloning
nej
yes
yes
yes
yes

Lagerdriver anvendelig inden i en container
yes
yes
nej
nej
nej

Gendan fra ældre snapshots (ikke nyeste)
yes
yes
yes
nej
yes

Lagringskvoter
ja(*)
yes
yes
yes
nej

Initialisering af netværk og Storage Pool med guiden ^

Den næste kommando, vi vil se på, giver mulighed for at konfigurere de grundlæggende komponenter i LXD ved at besvare enkle spørgsmål via guiden til initialisering.

Kør kommandoen lxc init og indtast svarene på spørgsmålene efter kolon, som vist i eksemplet nedenfor, eller ændre dem i henhold til dine betingelser:

lxd init

Vil du bruge LXD-klustering? (ja/nej) [standard=nej]: 
Vil du konfigurere en ny lagerpulje? (ja/nej) [standard=ja]: 
Navn på den nye lagerpulje [standard=default]: ssdpool         
Navn på den lagerbackend, der skal bruges (lvm, btrfs, dir) [standard=btrfs]: 
Opret en ny BTRFS-pulje? (ja/nej) [standard=ja]: 
Vil du bruge et eksisterende blokdevice? (ja/nej) [standard=nej]: 
Størrelse i GB af den nye loop-enhed (mindst 1GB) [standard=15GB]: 10GB
Vil du oprette forbindelse til en MAAS-server? (ja/nej) [standard=nej]: 
Vil du oprette en ny lokal netværksbro? (ja/nej) [standard=ja]: 
Hvad skal den nye bro hedde? [standard=lxdbr0]: 
Hvilken IPv4-adresse skal bruges? (CIDR subnet notation, “auto” eller “none”) [standard=auto]: 10.0.5.1/24
Vil du have LXD til at NAT IPv4-trafik på din bro? [standard=ja]: 
Hvilken IPv6-adresse skal bruges? (CIDR subnet notation, “auto” eller “none”) [standard=auto]: none
Vil du have LXD til at være tilgængelig over netværket? (ja/nej) [standard=nej]: 
Vil du have forældede cachede billeder til at blive opdateret automatisk? (ja/nej) [standard=ja]: nej
Vil du have en YAML "lxd init" preseed til at blive udskrevet? (ja/nej) [standard=nej]:

Oprettelse af en ekstra Storage Pool ^

I det forrige trin oprettede vi Storage Pool hvor vi gav navnet ssdpool og hvis fil placeres i mit system på adressen /var/lib/lxd/disks/ssdpool.img. Denne adresse for filsystemet svarer til det fysiske SSD-disk i min PC.

De næste trin, for at udvide forståelsen af, hvilken rolle Storage Pool spiller i lageret, vil vi oprette en anden Storage Pool som vil være fysisk placeret på en anden type disk, på HDD. Problemet er, at LXD ikke tillader oprettelse af Storage Pool uden for adressen /var/lib/lxd/disks/ og selv symboliske links vil ikke fungere, se udviklerens svar. Vi kan omgå denne begrænsning under initialisering/formatering, Storage Pool ved at angive værdien som et blokdevice i stedet for en sti til loopback-filen angivet i nøglen source.

Så, før oprettelsen Storage Pool Det er nødvendigt at definere loopback-filen eller den eksisterende partition i dit filsystem, som den vil bruge. For dette vil vi oprette og bruge en fil, som vi begrænser størrelsen på til 10 GB:

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

10000+0 records in
10000+0 records out
10000000000 bytes (10 GB, 9,3 GiB) copied, 38,4414 s, 260 MB/s

Vi tilslutter loopback-filen til en ledig loopback-enhed:

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

/dev/loop1

Tak til nøgleordet --show returnerer kommandoens udførelse enhedens navn, som vores loopback-fil er tilsluttet. Om nødvendigt kan vi vise en liste over alle optagne enheder af denne type for at sikre, at vores handlinger er korrekte:

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

Fra listen kan man se, at enheden /dev/loop1 har loopback-filen tilsluttet /mnt/work/lxd/hddpool.img, og enheden /dev/loop0 har loopback-filen tilsluttet /var/lib/lxd/disks/ssdpool.img der svarer til den standard Storage Pool.

Den følgende kommando opretter en ny Storage Pool i LXD baseret på den nyligt forberedte loopback-fil. LXD vil formatere loopback-filen /mnt/work/lxd/hddpool.img i enheden /dev/loop1 til BTRFS-filsystemet:

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

Lad os vise listen over alle Storage Pool på skærmen:

lxc storage list

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

Forøgelse af størrelsen på Storage Pool ^

Efter oprettelsen Storage Pool, hvis nødvendigt kan det udvides. For Storage Pool baseret på BTRFS-filsystemet skal du udføre følgende kommandoer:

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

Automatisk indlæsning af loopback-fil i loopback-enhedens slot ^

Vi har et lille problem; ved genstart af værtsystemet vil filen /mnt/work/lxd/hddpool.img "falde ud" af enheden /dev/loop1 og LXD-tjenesten vil fejle ved opstart, da den ikke vil kunne finde den i denne enhed. For at løse dette problem skal vi oprette en systemtjeneste, der vil montere denne fil i enheden /dev/loop1 ved opstart af værtsystemet.

Vi opretter unit filtype service i /etc/systemd/system/ til SystemD init-systemet:

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 aktiverer tjenesten:

sudo systemctl enable lxd-hddpool

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

Efter genstart af værtsystemet tjekker vi status for tjenesten:

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Indlæst: indlæst (/etc/systemd/system/lxd-hddpool.service; aktiveret; leverandørpræference: deaktiveret)
     Aktiv: aktiv (afsluttet) siden ons 2020-04-08 03:43:53 MSK; 1min 37s siden
    Proces: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (kode=afsluttet, status=0/SUCCES)
   Hoved PID: 711 (kode=afsluttet, status=0/SUCCES)

apr 08 03:43:52 manjaro systemd[1]: Starter Losetup LXD Storage Pool (hddpool)...
apr 08 03:43:53 manjaro systemd[1]: Færdig Losetup LXD Storage Pool (hddpool).

Fra output kan vi se, at tjenestens tilstand er active, på trods af at udførelsen af vores skript fra en enkelt kommando blev afsluttet, gjorde denne mulighed det muligt for os RemainAfterExit=true.

Sikkerhed. Privilegier for containere ^

Da alle containerprocesser faktisk kører isoleret på værtsystemet ved at bruge dens kerne, tilbyder LXD privilegier til processerne for yderligere at beskytte adgangen til værtsystemet, hvor:

  • Privilegerede containere — er containere, hvor processerne med UID og GID svarer til den samme ejer som på værtsystemet. For eksempel har en proces, der kører i en container med UID lig med 0, de samme adgangsrettigheder som en proces på værtsystemet med UID lig med 0. Med andre ord har root-brugeren i containeren alle rettigheder ikke kun i containeren, men også på værtsystemet, hvis han kan træde ud over den isolerede navnerum for containeren.

  • Ikke-privilegerede containere — er containere, hvor processerne tilhører ejeren med UID og GID mellem 0 og 65535, men for værtsystemet er ejeren maskeret ved hjælp af de tilføjede SubUID- og SubGID-bits. For eksempel vil en bruger med UID=0 i containeren blive set i værtsystemet som SubUID + UID. Dette beskytter værtsystemet, da, hvis en hvilken som helst proces i containeren kan træde ud over sit isolerede navnerum, kan den interagere med værtsystemet kun som en proces med en ukendt, meget høj UID/GID.

Som standard har nyoprettede containere status som ikke-privilegerede, og derfor skal vi definere SubUID og SubGID.

Lad os oprette to konfigurationsfiler, hvor vi angiver masken for SubUID og SubGID henholdsvis:

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

For the changes to take effect, the LXD service must be restarted:

sudo systemctl restart lxd

Oprettelse af et virtuelt netværksswitch ^

Since we previously initialized the network using the initialization wizard lxd init and created a network device lxdbr0, in this section, we will simply familiarize ourselves with the network in LXD and how to create a virtual switch (network bridge) using the client command.

The following diagram illustrates how the switch (network bridge) connects the host and containers in the network:

Grundlæggende funktioner i LXD - container systemet i Linux

Containers can interact via the network with other containers or the host on which these containers are managed. To do this, it is necessary to link the virtual network interfaces of the containers to the virtual switch. First, we will create the switch, and the container's network interfaces will be linked in subsequent chapters after the container itself is created.

The following command creates a switch with a subnet 10.0.5.0/24 and an IPv4 address 10.0.5.1/24, and also enables ipv4.nat so that containers can access the internet through the host using NAT services:

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

Checking the list of network devices available in LXD:

lxc network list

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

You can also verify the creation of the network device using the standard tool of your Linux distribution — 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 ^

Each container in LXD has its own configuration and can extend it with globally declared configurations called konfigurationsprofiler. Anvendelse af konfigurationsprofiler til en container følger en kaskademodel, det følgende eksempel demonstrerer dette:

Grundlæggende funktioner i LXD - container systemet i Linux

I dette eksempel er der oprettet tre profiler i LXD-systemet: default, hddpool og hostfs. Alle tre profiler er anvendt på en container, som har en lokal konfiguration (gray zone). Profilen default har en enhed root hvor parameteren pool , så denne funktion konfigurerer socket'en med indstillingen ssdpool, men takket være kaskademodellen til anvendelse af konfiguration kan vi anvende profil til containeren hddpool hvor parameteren pool overskriver denne samme parameter fra profilen default og containeren får konfigurationen af enheden root with the parameter pool lig med hddpool, mens profilen hostfs bare tilføjer en ny enhed til containeren.

For at se listen over tilgængelige konfigurationsprofiler kan følgende kommando anvendes:

lxc profile list

+---------+---------+
|  NAVN   | BRUGT AF |
+---------+---------+
| default | 1       |
+---------+---------+
| hddroot | 0       |
+---------+---------+
| ssdroot | 1       |
+---------+---------+

Den fulde liste over tilgængelige kommandoer til arbejde med profiler kan opnås ved at tilføje nøglen --help:

lxc profile --help

Beskrivelse:
  Administrer profiler

Brug:
  lxc profile [kommando]

Tilgængelige kommandoer:
  add         Tilføj profiler til instanser
  assign      Tildel sæt af profiler til instanser
  copy        Kopier profiler
  create      Opret profiler
  delete      Slet profiler
  device      Administrer instansens enheder
  edit        Rediger profilkonfigurationer som YAML
  get         Hent værdier for profilkonfigurationsnøgler
  list        Liste profiler
  remove      Fjern profiler fra instanser
  rename      Omdøb profiler
  set         Indstil profileringsnøgler
  show        Vis profilkonfigurationer
  unset       Nulstil profileringsnøgler

Redigering af profil ^

Standard konfigurationsprofil default har ingen netværkskortkonfiguration til containeren, og alle nyoprettede containere har ikke netværk, for dem er det nødvendigt at oprette lokale (dedikerede) netværksenheder med en separat kommando, men vi kan oprette en global netværksenhed i konfigurationsprofilen, som vil blive delt mellem alle containere, der bruger denne profil. På den måde har de straks efter kommandoen til oprettelse af en ny container netværk med adgang til nettet. Der er ingen begrænsninger, vi kan altid bagefter oprette en lokal netværksenhed, hvis det er nødvendigt.

Den næste kommando tilføjer en enhed til konfigurationsprofilen eth0 typen nic tilsluttet netværket lxdbr0:

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

Det er vigtigt at bemærke, at når vi faktisk har tilføjet en enhed til konfigurationsprofilen, så hvis vi specificerede en statisk IP-adresse for enheden, ville alle containere, der anvender denne profil, dele den samme IP-adresse. Hvis det er nødvendigt at oprette en container med en dedikeret statisk IP-adresse, skal der oprettes en netværksenhed på niveau med containeren (lokal konfiguration) med IP-adresseparametret, og ikke på niveau med profilen.

Lad os tjekke profilen:

lxc profile show default

config: {}
description: Standard LXD-profil
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: \/
    pool: ssdpool
    type: disk
name: default
used_by: []

I denne profil kan vi se, at der for alle nyoprettede containere vil blive oprettet to enheder (devices):

  • eth0 — Enhedstype nic forbundet til en switch (netværksbro) lxdbr0
  • root — Enhedstype disk som bruger lagerpuljen ssdpool

Oprettelse af nye profiler ^

For at bruge de tidligere oprettede Storage Pool containere, vil vi oprette en konfigurationsprofil ssdroot hvor vi tilføjer en enhedstype disk med monteringspunkt / (root) der bruger den tidligere oprettede Storage Pool — ssdpool:

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

På samme måde opretter vi en enhedstype disk, men i dette tilfælde bruger den Storage Pool — hddpool:

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

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

Billedrepository ^

Containere oprettes fra billeder, som er specielt sammensatte distributioner uden en Linux-kerne. Derfor skal en container være udtaget fra dette billede, før den kan startes. Kilden til billederne er et lokalt depot, hvor billederne uploades fra eksterne depoter.

Fjernbilledrepositories ^

Som standard er LXD konfigureret til at hente billeder fra tre eksterne kilder:

  • ubuntu: (for stabile Ubuntu-billeder)
  • ubuntu-daily: (for daglige Ubuntu-billeder)
  • images: (for en række andre distributioner)

lxc remote list

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

For eksempel, repositoriet ubuntu: har følgende billeder:

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

+----------------------------------------------+--------------+----------+------------+
|                   BESKRIVELSE                 | ARCHITEKTUR  |   STØRRELSE   |   TYPE     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | BEHOLDER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | BEHOLDER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | BEHOLDER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | BEHOLDER  |
+----------------------------------------------+--------------+----------+------------+

For at vise et begrænset antal kolonner brugte vi indstillingen -c med parametrene dasut, og vi begrænsede også længden af listen med kommandoen head.

Filtrering er tilgængelig for at vise listen over billeder. Den følgende kommando viser listen over alle tilgængelige arkitekturer for distributionen AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Lokalt billedrepository ^

For at begynde at bruge containeren, er det nødvendigt at tilføje et billede fra det globale repository til det lokale. local:. Det lokale repository er i øjeblikket tomt, hvilket bekræftes med kommandoen lxc image list. Hvis der ikke angives et repository, vil det lokale repository blive brugt som standard — list lxc image list local:+-------+-------------+--------+-------------+--------------+------+------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | +-------+-------------+--------+-------------+--------------+------+------+ local:

Håndtering af billeder i repository'et foretages med følgende metoder:

lxc image

Kommandoen
Description

Administrer billedealiaser alias
Kopier billeder mellem servere

Administrer billedealiaser copy
Slet billeder

Administrer billedealiaser slet
Rediger billedeegenskaber

Administrer billedealiaser edit
Eksporter og download billeder

Administrer billedealiaser export
Importér billeder til billedlageret

Administrer billedealiaser import
Vis nyttige oplysninger om billeder

Administrer billedealiaser info
Liste billeder

Administrer billedealiaser list
Opdater billeder

Administrer billedealiaser refresh
vis

Administrer billedealiaser Vis billedeegenskaber
Kopierer billedet til det lokale repository fra det globale.

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3Billedet er kopieret med succes! images::

Lad os vise listen over alle billeder, der nu er tilgængelige i det lokale repository.

lxc image -c lfdatsu list local:+---------+--------------+------------------------------------+--------------+ | ALIAS | FINGERPRINT | DESCRIPTION | ARCHITECTURE | +---------+--------------+------------------------------------+--------------+ | alpine3 | 73a3093d4a5c | Alpine 3.11 amd64 (20200220_13:00) | x86_64 | +---------+--------------+------------------------------------+--------------+ local::

Ud over interaktiv tilstand understøtter LXD også ikke-interaktiv tilstand for konfiguration, hvor konfigurationen angives i form af en YAML-fil, et specielt format, der tillader at indstille hele konfigurationen på én gang, uden at måtte udføre mange interaktive kommandoer, som blev gennemgået ovenfor i denne artikel, herunder netværkskonfiguration, oprettelse af konfigurationsprofiler osv. Her vil vi ikke dække dette område, du kan selv læse om det.

LXD-konfiguration ^

Den næste interaktive kommando i dokumentationen.

lxc config som vi vil gennemgå, tillader at indstille konfiguration. For eksempel, for at sikre, at de downloadede billeder i det lokale repository ikke automatisk opdateres fra de globale repositories, kan vi aktivere denne adfærd med følgende kommando: lxc config set images.auto_update_cached=false

For at oprette en container bruges kommandoen

Oprettelse og styring af container ^

hvor værdierne overføres som lxc init repository:image og derefter den ønskede identifikator for containeren. Repository'et kan angives som lokalt. og derefter den ønskede identifikator for containeren. Repository'et kan angives som lokalt. local: såvel som enhver global. Hvis repository ikke er angivet, bruges som standard det lokale repository til at søge efter billedet. Hvis billedet er angivet fra et globalt repository, vil det først blive downloadet til det lokale repository, og derefter bruges til at oprette containeren.

Lad os udføre følgende kommando for at oprette vores første container:

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

Lad os gennemgå kommandoens nøgler, som vi bruger her:

  • alpine3 — Angiver et alias (pseudonym) for billedet, der tidligere er downloadet til det lokale repository. Hvis aliaset ikke var oprettet for dette billede, kan man altid referere til billedet ved dets Fingerprint som vises i tabellen.
  • alp — Angiver et ID for containeren.
  • --storage — Denne nøgle angiver, hvor Storage Pool containeren vil blive oprettet.
  • --profile — Disse nøgler anvender kaskadevis konfigurationen fra tidligere oprettede konfigurationsprofiler til containeren.

Vi starter containeren, som begynder at starte init-systemet for distributionen:

lxc start alp

Man kan også bruge kommandoen lxc launch som tillader at kombinere kommandoerne lxc init og lxc start til én operation.

Lad os tjekke containerens tilstand:

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

Lad os tjekke containerens konfiguration:

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 sektionen profiler vi kan bekræfte, at denne container bruger to konfigurationsprofiler — default og hddroot. I sektionen enheder vi kan kun finde én enhed, da netværksenheden blev oprettet på profilniveau. defaultFor at se alle enheder, som bruges af containeren, skal du tilføje nøglen --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: ""

Installation af statisk IP-adresse ^

Hvis vi prøver at indstille IP-adressen for netværksenheden eth0 med kommandoen lxc config device set alp som er beregnet til containerens konfiguration, vil vi få en fejlmeddelelse, der informerer os om, at enheden ikke findes, fordi enheden eth0 som bruges af containeren tilhører profilen default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Vi kan selvfølgelig indstille en statisk IP-adresse for eth0 enheden i profilen, men den vil være den samme for alle containere, der bruger denne profil. Derfor tilføjer vi en dedikeret enhed til containeren:

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

Derefter skal containeren genstartes:

lxc restart alp

Hvis vi nu ser på konfigurationen af containeren, skal vi ikke anvende muligheden --expanded for at se netværksenheden eth0, da vi har oprettet den på containerens niveau, og den har kaskadisk overskrevet den samme enhed fra 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: KØRSEL
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:
- standard
- hddroot
stateful: false
beskrivelse: ""

Sletning af container ^

For at slette containeren bruges kommandoen lxc delete, men før du kan slette containeren, skal den stoppes med kommandoen lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAVN | STATUS  |       IPV4        | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPET | 10.0.5.10 (eth0)  |      | CONTAINER | 0         |
+------+---------+-------------------+------+-----------+-----------+

Når vi har bekræftet, at containerens tilstand er STOPPED, kan den slettes fra Storage Pool:

lxc delete alp

Adgang til container ^

For at udføre kommandoer i containeren direkte, uden netværksforbindelser, bruges kommandoen lxc exec som udfører kommandoer i containeren uden at starte et systemskald. Hvis du har brug for at udføre en kommando i et skald ved at bruge shell-mønstre som variabler, filomdirigeringer (pipe) osv., skal skalden startes eksplicit og kommandoen overføres som en nøgle, for eksempel:

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

I kommandoen blev der brugt et specielt escape-tegn for specielt tegnet $ for at variablen $HOME ikke blev fortolket på værtsmaskinen, men kun inde i containeren.

Det er også muligt at starte en interaktiv skalds session og afslutte den med en hotkey lxc config device add:

lxc exec alp -- \/bin\/sh

Styring af containerressourcer ^

I LXD kan du administrere ressourcerne for containeren ved hjælp af et specielt konfigurationssæt. Den komplette liste over konfigurationsparametre for containeren kan findes i dokumentationen.

Begrænsning af RAM-ressourcer ^

Parameter limits.memory begrænser mængden af RAM, der er tilgængelig for containeren. Værdien angives som et nummer og en af de tilgængelige suffikser.

Lad os sætte en grænse på containerens RAM-mængde til 256 MB:

lxc config set alp limits.memory 256MB

Derudover er der andre parametre til at begrænse hukommelsen:

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

Kommandoen lxc config show viser hele containerens konfiguration, inklusive de anvendte ressourc begrænsninger, som er blevet fastsat:

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

Begrænsning af CPU-ressourcer ^

Til begrænsning af CPU-ressourcer er der flere typer af begrænsninger:

  • limit.cpu — binder containeren til en eller flere CPU-kerner
  • limits.cpu.allowance — styrer enten CFS-planlæggerens kvoter, når tidsgrænsen er overskredet, eller en universel mekanisme til ressourceudnyttelse af CPU, når procentdelen er overskredet
  • limits.cpu.priority — prioriteten for planlægningsmekanismen, når flere instanser deler en CPU-gruppe med samme procesprocent

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 af diskplads ^

Udover begrænsninger såsom limits.read, limits.write kan vi også begrænse mængden af disklagring, som containeren bruger (kun fungerer med ZFS eller BTRFS):

lxc config device set alp root size=2GB

Efter installationen kan vi se den fastsatte grænse i devices.root.size vi kan bekræfte den idriftsatte begrænsning:

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

For at se de anvendte diskquotaer kan vi bruge kommandoen 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

Selvom vi har sat en grænse for root-enheden af containeren til 2 GB, vil systemværktøjer som df ikke se denne grænse. For dette vil vi gennemføre en lille test og finde ud af, hvordan det fungerer.

Lad os oprette 2 nye identiske containere i samme Storage Pool (hddpool):

lxc init alpine3 alp1 --storage=hddpool --profile=default --profile=hddroot
lxc init alpine3 alp2 --storage=hddpool --profile=default --profile=hddroot

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | RUNNING | 10.0.5.46 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | RUNNING | 10.0.5.30 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+

I en af containerne opretter vi en fil på 1 GB:

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

Lad os sikre os, at filen er oprettet:

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

Hvis vi ser i den anden container, og kontrollerer eksistensen af filen på samme sted, vil denne fil ikke være der, som forventet, da containerne oprettes i deres egne Storage Volume i denne Storage Pool:

lxc exec alp2 -- ls -lh
total 0

Men lad os sammenligne værdierne, som gives df i de to containere:

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

Enhed /dev/loop1 det monterede som root-partition er Storage Pool som disse containere bruger, så de deler dets volumen imellem sig.

Statistik over ressourceforbrug ^

Du kan se ressourceforbruget for containeren ved hjælp af kommandoen:

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

Arbejder med snapshots ^

I LXD er der mulighed for at oprette snapshots og gendanne tilstanden fra dem.

For at oprette et snapshot, udfør følgende kommando:

lxc snapshot alp snapshot1

Kommandoen lxc snapshot har ikke en nøgle list, så for at se listen over snapshots skal du bruge kommandoen, der viser generel information om containeren:

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

Du kan gendanne en container fra et snapshot med kommandoen lxc restore angivende containeren, som der skal udføres gendannelse for, og snapshot-aliaset:

lxc restore alp snapshot1

Den følgende kommando bruges til at slette et snapshot. Vær opmærksom på, at syntaksen for kommandoen ikke ligner de andre; her skal der angives et skråstreg efter containerens navn. Hvis skråstregen udelades, vil kommandoen til sletning af snapshot blive fortolket som en kommando til sletning af containeren!

lxc delete alp/snapshot1

I det ovenstående eksempel har vi set på, hvad der kaldes stateless-snapshots. I LXD er der en anden type snapshots — stateful, hvor den aktuelle tilstand af alle processer i containeren gemmes. Stateful-snapshots er forbundet med en række interessante og nyttige funktioner.

Hvad mere? ^

  • For Python-udviklere er der tilgængeligt et modul PyLXD som giver API-adgang til LXD

OPDATERING 10.04.2020 15:00: Navigation tilføjet

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster