ProHoster > Blog > administration > Grundlæggende funktioner i LXD - Linux containersystemer

Grundlæggende funktioner i LXD - Linux containersystemer

Grundlæggende funktioner i LXD - Linux containersystemer

LXD er næste generation af systemcontainermanager, så står der kilde. Det tilbyder en brugergrænseflade, der ligner virtuelle maskiner, men bruger Linux-containere i stedet.

LXD kerne er en privilegeret dæmon (en tjeneste, der kører med root-rettigheder), der giver en REST API via en lokal unix-socket, såvel som via netværket, hvis den relevante konfiguration er installeret. Klienter, såsom kommandolinjeværktøjet, der følger med LXD, fremsætter anmodninger via denne REST API. Det betyder, at uanset om du tilgår en lokal vært eller en fjernvært, fungerer alt på samme måde.

I denne artikel vil vi ikke dvæle i detaljer ved begreberne LXD, vi vil ikke overveje alle de tilgængelige funktioner, der er skitseret i dokumentationen, inklusive den seneste implementering i de seneste versioner af LXD af understøttelse af QEMU virtuelle maskiner parallelt med containere. I stedet lærer vi kun det grundlæggende i containerstyring – opsætning af lagerpuljer, netværk, kørsel af en container, anvendelse af ressourcebegrænsninger og hvordan du bruger snapshots, så du kan få en grundlæggende forståelse af LXD og bruge containere på Linux.

For fuldstændig information henvises til den officielle kilde:

Navigation

Installation LXD ^

Installation af LXD på Ubuntu-distributioner ^

I distributionspakken Ubuntu 19.10 lxd har en udsendelse på snap pakke:

apt search lxd

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

Det betyder, at to pakker vil blive installeret på én gang, den ene som en systempakke og den anden som en snap-pakke. Installation af to pakker på et system kan skabe nogle problemer, hvor systempakken kan blive forældreløs, hvis snap-pakken fjernes af snap-pakkehåndteringen.

Find pakken lxd i snap-lageret kan du bruge følgende kommando:

snap find lxd

Name             Version        Summary
lxd              3.21           System container manager and API
lxd-demo-server  0+git.6d54658  Online software demo sessions using LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Image builder for LXC and LXD
fabrica          0.1            Build snaps by simply pointing a web form to...
satellite        0.1.2          Advanced scalable Open source intelligence platform

Ved at køre kommandoen list du kan sikre dig, at pakken lxd endnu ikke installeret:

snap list

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

På trods af at LXD er en snap-pakke, skal den installeres gennem systempakken lxd, som vil oprette den tilsvarende gruppe i systemet, de nødvendige hjælpeprogrammer i /usr/bin etc.

sudo apt update
sudo apt install lxd

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

snap list

Name  Version    Rev    Tracking  Publisher   Notes
core  16-2.43.3  8689   stable    canonical✓  core
lxd   3.21       13474  stable/…  canonical✓  -

Installation af LXD på Arch Linux-distributioner ^

For at installere LXD-pakken på systemet skal du køre følgende kommandoer, den første vil opdatere listen over pakker på systemet, der er tilgængelige i lageret, den anden vil installere pakken direkte:

sudo pacman -Syyu && sudo pacman -S lxd

Efter installation af pakken, for at kunne administrere LXD af en almindelig bruger, skal den føjes til systemgruppen lxd:

sudo usermod -a -G lxd user1

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

id -Gn user1

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

Hvis gruppen lxd ikke er synlig på listen, så skal du aktivere brugersessionen igen. For at gøre dette skal du logge ud og logge ind under samme bruger.

Aktiver i systemd indlæsning af LXD-tjenesten ved systemstart:

sudo systemctl enable lxd

Lad os starte tjenesten:

sudo systemctl start lxd

Kontrol af servicestatus:

sudo systemctl status lxd

Storage LXD (Storage) ^

Før initialisering begynder, skal vi forstå, hvordan lagringen i LXD er logisk arrangeret.

Opbevaring (Opbevaring) består af fra en eller flere opbevaringspool som bruger et af de understøttede filsystemer såsom ZFS, BTRFS, LVM eller almindelige mapper. Hver opbevaringspool er opdelt i bind (Opbevaringsvolumen), der indeholder billeder, beholdere eller data til andre formål.

  • billedsprog - disse er specielt sammensatte distributioner uden Linux-kernen og tilgængelige fra eksterne kilder
  • Containere - disse er distribuerede distributioner fra billeder, klar til brug
  • Snapshots - disse er øjebliksbilleder af tilstanden af ​​containere, som du kan vende tilbage til

Grundlæggende funktioner i LXD - Linux containersystemer

For at administrere lagring i LXD skal du bruge kommandoen lxc storage et certifikat, som du kan få ved at angive nøglen - lxc storage --help

Den følgende kommando viser en liste over alle opbevaringspool 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 en liste over alle Opbevaringsvolumen i det valgte opbevaringspool betjener holdet 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       |
+-----------+----------------------------------+-------------+---------+

Også hvis for opbevaringspool Ved oprettelse blev BTRFS-filsystemet valgt, og få derefter en liste Opbevaringsvolumen eller subvoluminer i BTRFS-fortolkningen kan du bruge værktøjssættet 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

Initialiserer LXD ^

Før du opretter og bruger containere, skal du udføre en generel LXD-initialisering, der opretter og konfigurerer netværket og lageret. Dette kan gøres manuelt ved at bruge standard klientkommandoer, der er tilgængelige på listen ved at kalde kommandoen lxc --help eller ved at bruge initialiseringsguiden lxd init besvare et par spørgsmål.

Valg af filsystem til Storage Pool ^

Under initialisering stiller LXD adskillige spørgsmål, herunder at bestemme filsystemtypen for standarden opbevaringspool. Som standard er BTRFS-filsystemet valgt til det. Det vil være umuligt at skifte til en anden FS efter oprettelse. For at vælge en FS foreslås det funktionssammenligningstabel:

Feature
Vejviser
btrfs
LVM
ZFS
CEPH

Optimeret billedlagring
ingen
Ja
Ja
Ja
Ja

Optimeret instansoprettelse
ingen
Ja
Ja
Ja
Ja

Optimeret snapshot-oprettelse
ingen
Ja
Ja
Ja
Ja

Optimeret billedoverførsel
ingen
Ja
ingen
Ja
Ja

Optimeret instansoverførsel
ingen
Ja
ingen
Ja
Ja

Kopi på skriv
ingen
Ja
Ja
Ja
Ja

Blok baseret
ingen
ingen
Ja
ingen
Ja

Øjeblikkelig kloning
ingen
Ja
Ja
Ja
Ja

Lagerdriver, der kan bruges inde i en container
Ja
Ja
ingen
ingen
ingen

Gendan fra ældre snapshots (ikke seneste)
Ja
Ja
Ja
ingen
Ja

Lagerkvoter
Ja(*)
Ja
Ja
Ja
ingen

Initialisering af netværket og lagerpuljen ved hjælp af guiden ^

Den næste kommando, vi vil se på, foreslår opsætning af hovedkomponenterne i LXD ved at besvare enkle spørgsmål ved hjælp af initialiseringsguiden.

Kør kommando lxc init og indtast svarene på spørgsmålene efter kolon som vist i eksemplet nedenfor, eller skift dem i henhold til dine forhold:

lxd init

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

Oprettelse af en ekstra lagerpool ^

I det forrige trin oprettede vi opbevaringspool som fik navnet ssdpool og hvis fil er placeret på mit system på /var/lib/lxd/disks/ssdpool.img. Denne filsystemadresse svarer til det fysiske SSD-drev på min pc.

Følgende handlinger, for at udvide forståelsen af ​​den rolle, som opbevaringspool i depotet, vil vi oprette en anden opbevaringspool som fysisk vil være placeret på en anden type disk, HDD. Problemet er, at LXD ikke tillader dig at oprette opbevaringspool ude af adresse /var/lib/lxd/disks/ og selv symbolske links virker ikke, se udviklerens svar. Vi kan omgå denne begrænsning under initialisering/formatering opbevaringspool ved at angive værdien som en blokenhed i stedet for stien til loopback-filen ved at angive dette i nøglen source.

Så før du opretter opbevaringspool du skal definere en loopback-fil eller en eksisterende partition på dit filsystem, som den vil bruge. For at gøre dette vil vi oprette og bruge en fil, som vi begrænser i størrelse 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

Lad os forbinde loopback-filen til en gratis loopback-enhed:

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

/dev/loop1

Takket være nøglen --show udførelse af kommandoen returnerer til skærmen navnet på den enhed, som vores loopback-fil er forbundet til. Om nødvendigt kan vi vise en liste over alle optaget 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 du finde, at enheden har /dev/loop1 loopback-fil inkluderet /mnt/work/lxd/hddpool.img, og i enheden /dev/loop0 loopback-fil inkluderet /var/lib/lxd/disks/ssdpool.img som svarer til standarden opbevaringspool.

Følgende kommando opretter en ny opbevaringspool i LXD baseret på loopback-filen, vi lige har forberedt. LXD vil formatere loopback-filen /mnt/work/lxd/hddpool.img i enheden /dev/loop1 for BTRFS-filsystemet:

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

Lad os vise en liste over alle opbevaringspool til skærm:

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 Storage Pool Størrelse ^

Efter skabelsen opbevaringspoolom nødvendigt kan den udvides. Til opbevaringspool baseret på BTRFS-filsystemet, kør 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 indsættelse af en loopback-fil i en loopback-enhedsslot ^

Vi har et lille problem, når du genstarter værtssystemet, filen /mnt/work/lxd/hddpool.img vil "flyve" ud af enheden /dev/loop1 og LXD-tjenesten vil gå ned, når den indlæses, fordi den ikke kan se den på denne enhed. For at løse dette problem skal du oprette en systemtjeneste, der indsætter denne fil i enheden /dev/loop1 når værtssystemet starter.

Lad os skabe enhed filtype tjeneste в /etc/systemd/system/ for SystemD initialiseringssystemet:

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

Aktiver tjenesten:

sudo systemctl enable lxd-hddpool

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

Efter genstart af værtssystemet kontrollerer vi tjenestestatus:

systemctl status lxd-hddpool.service 

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

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

Fra outputtet kan vi bekræfte, at servicetilstanden er aktiv, på trods af at udførelsen af ​​vores script fra en kommando blev fuldført, tillod indstillingen os at gøre dette RemainAfterExit=true.

Sikkerhed. Containerprivilegier ^

Da alle containerprocesser faktisk kører isoleret på værtssystemet ved hjælp af dets kerne, for yderligere at beskytte containerprocessernes adgang til værtssystemet, tilbyder LXD procesprivilegier, hvor:

  • Privilegerede containere - det er containere, hvor processer med UID og GID svarer til samme ejer som på værtssystemet. For eksempel har en proces, der kører i en container med et UID på 0, alle de samme adgangsrettigheder som en proces på værtssystemet med et UID på 0. Med andre ord har root-brugeren i containeren alle rettighederne ikke kun i containeren, men også på værtssystemet, hvis han kan gå uden for containerens isolerede navneområde.

  • Uprivilegerede containere - disse er containere, hvor processer tilhører ejeren af ​​UID og GID med et nummer fra 0 til 65535, men for værtssystemet er ejeren maskeret ved hjælp af henholdsvis de tilføjede SubUID og SubGID bits. For eksempel vil en bruger med UID=0 i en container blive set på værtssystemet som SubUID + UID. Dette beskytter værtssystemet, fordi hvis en proces i containeren er i stand til at undslippe sit isolerede navneområde, kan den kun kommunikere med værtssystemet som en proces med en ukendt, meget høj UID/GID.

Som standard har nyoprettede containere en uprivilegeret status, og derfor skal vi definere et SubUID og SubGID.

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

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

For at anvende ændringerne skal LXD-tjenesten genstartes:

sudo systemctl restart lxd

Oprettelse af en virtuel netværksswitch ^

Da vi tidligere initialiserede netværket ved hjælp af initialiseringsguiden lxd init og oprettet en netværksenhed lxdbr0, så vil vi i dette afsnit blot stifte bekendtskab med netværk i LXD og hvordan man opretter en virtuel switch (bro) ved hjælp af klientkommandoen.

Følgende diagram viser, hvordan en switch (bro) forbinder værten og containerne til et netværk:

Grundlæggende funktioner i LXD - Linux containersystemer

Containere kan kommunikere via et netværk med andre containere eller værten, som disse containere serveres på. For at gøre dette skal du forbinde containernes virtuelle netværkskort med en virtuel switch. Vi opretter først en switch, og containerens netværksgrænseflader vil blive forbundet i efterfølgende kapitler, efter selve containeren er blevet oprettet.

Følgende kommando opretter en switch med et undernet 10.0.5.0/24 og IPv4-adresse 10.0.5.1/24, og omfatter også ipv4.nat så containere kan få adgang til internettet gennem værten ved hjælp af NAT-tjenesten:

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

Kontrollerer listen over tilgængelige netværksenheder i LXD:

lxc network list

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

Du kan også bekræfte, at en netværksenhed er blevet oprettet ved hjælp af standardværktøjet i Linux-distributionen - ip link eller ip addr:

ip addr

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

Konfigurationsprofil ^

Hver container i LXD har sin egen konfiguration og kan udvide den med globalt erklærede konfigurationer kaldet konfigurationsprofiler. Anvendelse af konfigurationsprofiler på en container har en kaskademodel, følgende eksempel viser dette:

Grundlæggende funktioner i LXD - Linux containersystemer

I dette eksempel er der oprettet tre profiler i LXD-systemet: default, hddpool и hostfs. Alle tre profiler anvendes på en container, der har en lokal konfiguration (grå område). Profil default har en enhed root som har en parameter pool er lig med ssdpool, men takket være applikationsmodellen til kaskadekonfiguration kan vi anvende en profil på beholderen hddpool som har en parameter pool vil tilsidesætte den samme parameter fra profilen default og beholderen modtager enhedskonfigurationen root med parameter pool lige hddpoolog profilen hostfs tilføjer blot en ny enhed til beholderen.

Brug følgende kommando for at se listen over tilgængelige konfigurationsprofiler:

lxc profile list

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

En komplet liste over tilgængelige kommandoer til at arbejde med en profil kan fås ved at tilføje nøglen --help:

lxc profile --help

Description:
  Manage profiles

Usage:
  lxc profile [command]

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

Redigering af din profil ^

Standard konfigurationsprofil default har ikke en netværkskortkonfiguration til containeren, og alle nyoprettede containere har ikke et 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 konfigurationen profil, der vil blive delt mellem alle containere, der bruger denne profil. På denne måde vil de umiddelbart efter kommandoen til at oprette en ny container have et netværk med netværksadgang. Samtidig er der ingen begrænsninger; vi kan altid oprette en lokal netværksenhed senere, hvis det er nødvendigt.

Følgende kommando tilføjer enheden 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 da vi faktisk føjede enheden til konfigurationsprofilen, hvis vi specificerede en statisk IP-adresse i enheden, vil alle containere, der vil bruge denne profil, dele den samme IP-adresse. Hvis der er behov for at oprette en container med en statisk IP-adresse tildelt containeren, så skal du oprette en netværksenhedskonfiguration på containerniveau (lokal konfiguration) med IP-adresseparameteren og ikke på profilniveau.

Lad os tjekke 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 denne profil kan vi se, at for alle nyoprettede containere vil der blive oprettet to enheder:

  • eth0 — Enhedstype nic tilsluttet en switch (netværksbro) lxdbr0
  • root — Enhedstype disk som bruger en opbevaringspool ssdpool

Oprettelse af nye profiler ^

For at bruge tidligere oprettede opbevaringspool containere, skal du oprette en konfigurationsprofil ssdroot hvor vi vil tilføje en enhed som disk med monteringspunkt / (root) ved hjælp af den tidligere oprettede opbevaringspool — ssdpool:

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

På samme måde skaber vi en enhed som disk, men i dette tilfælde ved hjælp af opbevaringspool — hddpool:

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

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

Billedlager ^

Containere er skabt ud fra billeder, der er specielt sammensatte distributioner, der ikke har en Linux-kerne. Før du kører containeren, skal den derfor implementeres fra dette billede. Kilden til billeder er et lokalt lager, hvori billeder downloades fra eksterne lagre.

Fjernbilleder ^

Som standard er LXD konfigureret til at modtage billeder fra tre fjernkilder:

  • ubuntu: (til stabile Ubuntu-billeder)
  • ubuntu-dagligt: (til daglige Ubuntu-billeder)
  • billeder: (for en masse andre distros)

lxc remote list

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

For eksempel repository ubuntu: har følgende billeder:

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

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

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

Filtrering er tilgængelig for at vise en liste over billeder. Den følgende kommando viser alle tilgængelige distributionsarkitekturer AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Lokalt billedlager ^

For at begynde at bruge containeren skal du tilføje et billede fra det globale lager til det lokale local:. Nu er det lokale lager tomt, kommandoen sørger for dette lxc image list. Hvis metoden list angiv ikke et lager, så vil det lokale lager blive brugt som standard - local:

lxc image list local:

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

Billeder i depotet administreres ved hjælp af følgende metoder:

Team
beskrivelse

lxc billede alias
Administrer billedaliasser

lxc billede kopiere
Kopier billeder mellem servere

lxc billede slette
Slet billeder

lxc billede redigere
Rediger billedegenskaber

lxc billede eksport
Eksporter og download billeder

lxc billede importere
Importer billeder til billedlageret

lxc billede info
Vis nyttige oplysninger om billeder

lxc billede liste
Liste billeder

lxc billede Opdater
Opdater billeder

lxc billede Vis
Vis billedegenskaber

Kopier billedet til det lokale lager fra det globale images::

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

Image copied successfully!

Lad os vise en liste over alle billeder, der i øjeblikket er tilgængelige i det lokale lager local::

lxc image -c lfdatsu list local:

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

LXD konfiguration ^

Ud over den interaktive tilstand understøtter LXD også en ikke-interaktiv konfigurationsinstallationstilstand, dette er når konfigurationen er angivet i form af en YAML-fil, et specielt format, der giver dig mulighed for at installere hele konfigurationen på én gang, uden at udførelsen af mange interaktive kommandoer, der blev diskuteret ovenfor i denne artikel, herunder netværkskonfiguration, oprettelse af konfigurationsprofiler osv. Vi vil ikke dække dette område her, du kan tjekke det ud på egen hånd. i dokumentation.

Næste interaktive kommando lxc config som vi vil se på giver dig mulighed for at indstille konfigurationen. For for eksempel at sikre, at downloadede billeder til det lokale lager ikke automatisk opdateres fra de globale lagre, kan vi aktivere denne adfærd med følgende kommando:

lxc config set images.auto_update_cached=false

Oprettelse og administration af en container ^

Brug kommandoen for at oprette en container lxc init som værdier overføres til репозиторий:образ og derefter det ønskede ID for containeren. Depotet kan angives som lokalt local: det samme er enhver global. Hvis lageret ikke er angivet, bruges det lokale lager som standard til at søge efter billedet. Hvis billedet er angivet fra det globale lager, vil billedet først blive downloadet til det lokale lager og derefter brugt til at oprette containeren.

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

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

Lad os se på kommandotasterne, som vi bruger her i rækkefølge:

  • alpine3 — Et alias (alias) er angivet for det billede, der tidligere blev uploadet til det lokale lager. Hvis aliaset ikke blev oprettet for dette billede, kan du altid henvise til billedet ved dets Fingeraftryk som er vist i tabellen.
  • alp — Indstiller identifikatoren for beholderen
  • --storage — Denne tast angiver i hvilken opbevaringspool en container vil blive oprettet
  • --profile — Disse nøgler kaskade anvender konfiguration fra tidligere oprettede konfigurationsprofiler til containeren

Vi starter containeren, som begynder at starte distributionens init-system:

lxc start alp

Du kan også bruge kommandoen lxc launch som giver dig mulighed for at kombinere hold lxc init и lxc start i én operation.

Kontrol af beholderens tilstand:

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

Kontrol af beholderkonfigurationen:

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 afsnittet profiles vi kan sikre, at denne container bruger to konfigurationsprofiler − default и hddroot. I afsnittet devices vi kan kun registrere én enhed, da netværksenheden blev oprettet på profilniveau default. For at se alle enheder, der bruges af containeren, skal du tilføje en nøgle --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: ""

Indstilling af en statisk IP-adresse ^

Hvis vi forsøger at indstille en IP-adresse til en netværksenhed eth0 hold lxc config device set alp beregnet til containerkonfigurationen, så vil vi modtage en fejl, der vil rapportere, at enheden ikke eksisterer, fordi enheden eth0 som bruges af containeren hører til 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 til eth0 enheder i profilen, men det vil være det samme for alle containere, der vil bruge denne profil. Lad os derfor tilføje en enhed dedikeret til beholderen:

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

Så skal du genstarte beholderen:

lxc restart alp

Hvis vi ser på containerkonfigurationen nu, behøver vi ikke bruge muligheden --expanded for at se netværksenheden eth0, da vi oprettede det på beholderniveau, og det kom over den samme enhed fra profilen default:

lxc config show alp

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

Fjernelse af en beholder ^

Brug kommandoen for at fjerne en beholder lxc delete, men før du fjerner beholderen, skal den stoppes ved hjælp af kommandoen lxc stop:

lxc stop alp

lxc list

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

Efter at vi har verificeret, at containerens tilstand er blevet HOLDT OP, kan den fjernes fra opbevaringspool:

lxc delete alp

Container adgang ^

For at udføre kommandoer i en container direkte, omgå netværksforbindelser, skal du bruge kommandoen lxc exec som udfører kommandoer i containeren uden at starte systemskallen. Hvis du har brug for at udføre en kommando i en shell ved hjælp af shell-mønstre såsom variabler, filomdirigeringer (pipe) osv., så skal du eksplicit starte shellen og sende kommandoen som en nøgle, for eksempel:

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

Kommandoen brugte et særligt escape-tegn for speciel karakter $ således at variablen $HOME blev ikke fortolket på værtsmaskinen, men blev kun fortolket inde i containeren.

Det er også muligt at starte den interaktive shell-tilstand og derefter afslutte sessionen ved at udføre genvejstasten CTRL+D:

lxc exec alp -- /bin/sh

Container ressourcestyring ^

I LXD kan du administrere containerressourcer ved hjælp af et særligt sæt konfigurationer. En komplet liste over containerkonfigurationsparametre kan findes i dokumentation.

RAM-ressourcebegrænsning ^

Parameter limits.memory begrænser mængden af ​​RAM til rådighed for beholderen. Værdien er et tal og en af tilgængelige suffikser.

Lad os sætte containerens RAM-grænse til 256 MB:

lxc config set alp limits.memory 256MB

Der er også andre parametre til at begrænse hukommelsen:

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

Team lxc config show giver dig mulighed for at vise hele containerkonfigurationen, inklusive den anvendte ressourcegrænse, der blev angivet:

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200220_13:00)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200220_13:00"
  image.type: squashfs
  limits.memory: 256MB
  volatile.base_image: 73a3093d4a5ce0148fd84b95369b3fbecd19a537ddfd2e2d20caa2eef0e8fd60
  volatile.eth0.host_name: veth75b6df07
  volatile.eth0.hwaddr: 00:16:3e:a1:e7:46
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

CPU-ressourcegrænse ^

Der er flere måder at begrænse CPU-ressourcer på. typer af restriktioner:

  • limit.cpu - binder en beholder til en eller flere CPU-kerner
  • limits.cpu.allowance - administrerer enten CFS-planlægningskvoter, når tidsgrænsen er udløbet, eller den universelle CPU-ressourcedelingsmekanisme, når procentdelen er passeret
  • limits.cpu.priority - skemalæggerprioritet, når flere instanser, der deler et sæt processorer, tildeles den samme procentdel af 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 af diskplads ^

Ud over begrænsninger som f.eks limits.read, limits.write vi kan også begrænse mængden af ​​diskplads, der forbruges af containeren (virker kun med ZFS eller BTRFS):

lxc config device set alp root size=2GB

Efter installationen, i parameteren devices.root.size Vi kan verificere den fastsatte grænse:

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 brugte diskkvoter kan vi få fra 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

På trods af at vi har sat en grænse for containerens rodenhed til 2GB, er systemværktøjer som f.eks. df vil ikke se denne begrænsning. For at gøre dette vil vi lave en lille test og finde ud af, hvordan det virker.

Lad os skabe 2 nye identiske beholdere i samme opbevaringspool (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         |
+------+---------+------------------+------+-----------+-----------+

Lad os oprette en 1 GB fil i en af ​​containerne:

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

Lad os sørge for, 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, skal du kontrollere, om der findes en fil på samme placering, så vil denne fil ikke være der, hvilket forventes, da containere er oprettet i deres egen Opbevaringsvolumen i det samme opbevaringspool:

lxc exec alp2 -- ls -lh
total 0

Men lad os sammenligne de værdier, det producerer df på den ene og den anden beholder:

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 monteret som rodpartitionen er opbevaringspool som disse beholdere bruger, så de deler volumen mellem to.

Ressourceforbrugsstatistik ^

Du kan se ressourceforbrugsstatistik for en container 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

Arbejde med snapshots ^

LXD har evnen til at oprette snapshots og gendanne containertilstanden fra dem.

For at oprette et snapshot skal du køre følgende kommando:

lxc snapshot alp snapshot1

Holdet lxc snapshot ingen nøgle tilgængelig list, derfor skal du bruge kommandoen, der viser generel information om beholderen for at se listen over snapshots:

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

Du kan gendanne en beholder fra et øjebliksbillede ved hjælp af kommandoen lxc restore angivelse af containeren, som gendannelsen skal udføres for, og snapshot-aliaset:

lxc restore alp snapshot1

Følgende kommando bruges til at slette et snapshot. Bemærk venligst, at kommandosyntaksen ikke ligner alle andre; her skal du angive en skråstreg efter containernavnet. Hvis skråstreget udelades, så tolkes kommandoen til at slette et snapshot som en kommando til at slette en container!

lxc delete alp/snapshot1

I eksemplet ovenfor har vi set på såkaldte statsløse snapshots. LXD har en anden type snapshots - stateful, som gemmer den aktuelle tilstand af alle processer i containeren. Der er en række interessante og nyttige funktioner forbundet med stateful snapshots.

Hvad ellers? ^

  • Et modul er tilgængeligt for Python-udviklere PyLXD som giver en API til LXD

OPDATERING 10.04.2020/15/00 XNUMX:XNUMX: Tilføjet navigation

Kilde: www.habr.com

Tilføj en kommentar