ProHoster > Log > administrasjon > Grunnleggende funksjoner i LXD - Linux containersystemer

Grunnleggende funksjoner i LXD - Linux containersystemer

Grunnleggende funksjoner i LXD - Linux containersystemer

LXD er neste generasjons system container manager, så står det kilde. Den tilbyr et brukergrensesnitt som ligner på virtuelle maskiner, men bruker Linux-beholdere i stedet.

LXD kjerne er en privilegert demon (en tjeneste som kjører med rotrettigheter) som gir en REST API via en lokal unix-socket, så vel som via nettverket hvis riktig konfigurasjon er installert. Klienter, for eksempel kommandolinjeverktøyet som følger med LXD, sender forespørsler gjennom denne REST API. Dette betyr at uansett om du har tilgang til en lokal vert eller en ekstern vert, fungerer alt på samme måte.

I denne artikkelen vil vi ikke dvele i detalj på konseptene til LXD, vi vil ikke vurdere alle tilgjengelige funksjoner som er skissert i dokumentasjonen, inkludert den nylige implementeringen i de nyeste versjonene av LXD av støtte for virtuelle QEMU-maskiner parallelt med containere. I stedet lærer vi bare det grunnleggende om containeradministrasjon – å sette opp lagringsbassenger, nettverk, kjøre en container, bruke ressursgrenser og hvordan du bruker øyeblikksbilder slik at du kan få en grunnleggende forståelse av LXD og bruke containere på Linux.

For fullstendig informasjon, vennligst se den offisielle kilden:

Navigasjon

Installasjon LXD ^

Installere LXD på Ubuntu-distribusjoner ^

I distribusjonspakken Ubuntu 19.10 lxd har en sending på snap pakke:

apt search lxd

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

Dette betyr at to pakker vil bli installert på en gang, en som en systempakke og den andre som en snappakke. Installering av to pakker på et system kan skape problemer der systempakken kan bli foreldreløs hvis snap-pakken fjernes av snap-pakkebehandlingen.

Finn pakke lxd i snap-lageret kan du bruke 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 å kjøre kommandoen list du kan sørge for at pakken lxd ennå ikke installert:

snap list

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

Til tross for at LXD er en snap-pakke, må den installeres gjennom systempakken lxd, som vil opprette den tilsvarende gruppen i systemet, de nødvendige verktøyene i /usr/bin etc.

sudo apt update
sudo apt install lxd

La oss sørge for at pakken er installert som en snappakke:

snap list

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

Installere LXD på Arch Linux-distribusjoner ^

For å installere LXD-pakken på systemet, må du kjøre følgende kommandoer, den første vil oppdatere listen over pakker på systemet som er tilgjengelig i depotet, den andre vil installere pakken direkte:

sudo pacman -Syyu && sudo pacman -S lxd

Etter å ha installert pakken, for å administrere LXD av en vanlig bruker, må den legges til systemgruppen lxd:

sudo usermod -a -G lxd user1

La oss sørge for brukeren user1 lagt til i gruppen lxd:

id -Gn user1

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

Hvis gruppen lxd ikke er synlig i listen, må du aktivere brukerøkten på nytt. For å gjøre dette må du logge ut og logge inn under samme bruker.

Aktiver inn systemd lasting av LXD-tjenesten ved systemstart:

sudo systemctl enable lxd

La oss starte tjenesten:

sudo systemctl start lxd

Sjekke tjenestestatusen:

sudo systemctl status lxd

Storage LXD (Storage) ^

Før initialisering begynner, må vi forstå hvordan lagringen i LXD er logisk ordnet.

Oppbevaring (oppbevaring) består av fra en eller flere Oppbevaringsbasseng som bruker et av de støttede filsystemene som ZFS, BTRFS, LVM eller vanlige kataloger. Hver Oppbevaringsbasseng er delt inn i volumer (Lagringsvolum) som inneholder bilder, beholdere eller data for andre formål.

  • bilder - Dette er spesialmonterte distribusjoner uten Linux-kjernen og tilgjengelig fra eksterne kilder
  • containere - Dette er distribuerte distribusjoner fra bilder, klare til bruk
  • Øyeblikksbilder - Dette er øyeblikksbilder av tilstanden til containere du kan gå tilbake til

Grunnleggende funksjoner i LXD - Linux containersystemer

For å administrere lagring i LXD, bruk kommandoen lxc storage et sertifikat som du kan få ved å spesifisere nøkkelen - lxc storage --help

Følgende kommando viser en liste over alle Oppbevaringsbasseng i LXD-lagring:

lxc storage list

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

For å se en liste over alle Lagringsvolum i den valgte Oppbevaringsbasseng betjener laget 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 Oppbevaringsbasseng Når du oppretter, ble BTRFS-filsystemet valgt, og få en liste Lagringsvolum eller delvolumer i BTRFS-tolkningen kan du bruke verktøysettet til dette filsystemet:

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 oppretter og bruker containere, må du utføre en generell LXD-initialisering som oppretter og konfigurerer nettverket og lagringen. Dette kan gjøres manuelt ved å bruke standard klientkommandoer som er tilgjengelige i listen ved å kalle kommandoen lxc --help eller ved å bruke initialiseringsveiviseren lxd init svarer på noen spørsmål.

Velge et filsystem for Storage Pool ^

Under initialisering stiller LXD flere spørsmål, inkludert å bestemme filsystemtypen for standarden Oppbevaringsbasseng. Som standard er BTRFS-filsystemet valgt for det. Det vil være umulig å bytte til en annen FS etter opprettelse. For å velge en FS foreslås det funksjonssammenligningstabell:

Trekk
Directory
btrfs
LVM
ZFS
CEPH

Optimalisert bildelagring
Nei.
ja
ja
ja
ja

Optimalisert forekomstoppretting
Nei.
ja
ja
ja
ja

Optimalisert øyeblikksbildeoppretting
Nei.
ja
ja
ja
ja

Optimalisert bildeoverføring
Nei.
ja
Nei.
ja
ja

Optimalisert forekomstoverføring
Nei.
ja
Nei.
ja
ja

Kopier på skriv
Nei.
ja
ja
ja
ja

Blokkbasert
Nei.
Nei.
ja
Nei.
ja

Øyeblikkelig kloning
Nei.
ja
ja
ja
ja

Lagringsdriver som kan brukes inne i en container
ja
ja
Nei.
Nei.
Nei.

Gjenopprett fra eldre øyeblikksbilder (ikke nyeste)
ja
ja
ja
Nei.
ja

Lagringskvoter
ja(*)
ja
ja
ja
Nei.

Initialisere nettverket og lagringspoolen ved hjelp av veiviseren ^

Den neste kommandoen vi skal se på foreslår å sette opp hovedkomponentene til LXD ved å svare på enkle spørsmål ved å bruke initialiseringsveiviseren.

Kjør kommando lxc init og skriv inn svarene på spørsmålene etter kolon som vist i eksemplet nedenfor, eller endre 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]:

Opprette et ekstra lagringsbasseng ^

I forrige trinn opprettet vi Oppbevaringsbasseng som fikk navnet ssdpool og filen som ligger på systemet mitt på /var/lib/lxd/disks/ssdpool.img. Denne filsystemadressen tilsvarer den fysiske SSD-stasjonen i PC-en min.

Følgende handlinger, for å utvide forståelsen av rollen som spilles av Oppbevaringsbasseng i depotet vil vi lage en andre Oppbevaringsbasseng som vil være fysisk plassert på en annen type disk, HDD. Problemet er at LXD ikke lar deg lage Oppbevaringsbasseng ute av adresse /var/lib/lxd/disks/ og til og med symbolske lenker vil ikke fungere, se utviklerens svar. Vi kan omgå denne begrensningen under initialisering/formatering Oppbevaringsbasseng ved å angi verdien som en blokkenhet i stedet for banen til loopback-filen ved å spesifisere dette i nøkkelen source.

Så før du lager Oppbevaringsbasseng du må definere en loopback-fil eller en eksisterende partisjon på filsystemet som den skal bruke. For å gjøre dette vil vi opprette og bruke en fil som vi begrenser 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

La oss koble loopback-filen til en gratis loopback-enhet:

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

/dev/loop1

Takket være nøkkelen --show utførelse av kommandoen returnerer til skjermen navnet på enheten som loopback-filen vår er koblet til. Om nødvendig kan vi vise en liste over alle opptatte enheter av denne typen for å sikre at handlingene våre er riktige:

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 finne at enheten har /dev/loop1 loopback-fil inkludert /mnt/work/lxd/hddpool.img, og i enheten /dev/loop0 loopback-fil inkludert /var/lib/lxd/disks/ssdpool.img som tilsvarer standarden Oppbevaringsbasseng.

Følgende kommando oppretter en ny Oppbevaringsbasseng i LXD basert på loopback-filen vi nettopp har forberedt. LXD vil formatere loopback-filen /mnt/work/lxd/hddpool.img i enheten /dev/loop1 for BTRFS-filsystemet:

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

La oss vise en liste over alle Oppbevaringsbasseng til skjerm:

lxc storage list

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

Øke størrelsen på oppbevaringsbassenget ^

Etter skapelsen Oppbevaringsbasseng, om nødvendig kan den utvides. Til Oppbevaringsbasseng basert på BTRFS-filsystemet, kjø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 innsetting av en loopback-fil i en loopback-enhetsspor ^

Vi har ett lite problem, når du starter vertssystemet på nytt, filen /mnt/work/lxd/hddpool.img vil "fly" ut av enheten /dev/loop1 og LXD-tjenesten vil krasje ved lasting fordi den ikke vil se den på denne enheten. For å løse dette problemet må du opprette en systemtjeneste som setter inn denne filen i enheten /dev/loop1 når vertssystemet starter opp.

La oss skape enhet 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.

Etter å ha startet vertssystemet på nytt, sjekker vi tjenestestatusen:

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 utgangen kan vi bekrefte at tjenestetilstanden er aktiv, til tross for at utførelsen av skriptet vårt fra én kommando ble fullført, tillot alternativet oss å gjøre dette RemainAfterExit=true.

Sikkerhet. Containerprivilegier ^

Siden alle beholderprosesser faktisk kjører isolert på vertssystemet ved å bruke kjernen, for ytterligere å beskytte tilgangen til beholderprosesser til vertssystemet, tilbyr LXD prosessprivilegier, der:

  • Privilegerte containere - dette er containere hvor prosesser med UID og GID tilsvarer samme eier som på vertssystemet. For eksempel har en prosess som kjører i en container med en UID på 0 alle de samme tilgangsrettighetene som en prosess på vertssystemet med en UID på 0. Med andre ord har rotbrukeren i containeren alle rettighetene ikke bare i containeren, men også på vertssystemet hvis han kan gå utenfor containerens isolerte navneområde.

  • Uprivilegerte containere - dette er containere hvor prosesser tilhører eieren av UID og GID med et nummer fra 0 til 65535, men for vertssystemet er eieren maskert ved hjelp av de tilføyde SubUID- og SubGID-bitene, henholdsvis. For eksempel vil en bruker med UID=0 i en container bli sett på vertssystemet som SubUID + UID. Dette beskytter vertssystemet fordi hvis en prosess i beholderen er i stand til å unnslippe det isolerte navneområdet, kan den bare kommunisere med vertssystemet som en prosess med en ukjent, svært høy UID/GID.

Som standard har nyopprettede beholdere en uprivilegert status og derfor må vi definere en SubUID og SubGID.

La oss lage to konfigurasjonsfiler der vi vil sette 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 å bruke endringene må LXD-tjenesten startes på nytt:

sudo systemctl restart lxd

Opprette en virtuell nettverkssvitsj ^

Siden vi tidligere initialiserte nettverket ved hjelp av initialiseringsveiviseren lxd init og opprettet en nettverksenhet lxdbr0, så i denne delen vil vi ganske enkelt bli kjent med nettverk i LXD og hvordan lage en virtuell svitsj (bro) ved hjelp av klientkommandoen.

Følgende diagram viser hvordan en svitsj (bro) kobler verten og beholderne til et nettverk:

Grunnleggende funksjoner i LXD - Linux containersystemer

Containere kan kommunisere via et nettverk med andre containere eller verten som disse containerne serveres på. For å gjøre dette må du koble de virtuelle nettverkskortene til beholderne med en virtuell svitsj. Vi oppretter først en svitsj, og containerens nettverksgrensesnitt vil bli koblet sammen i påfølgende kapitler, etter at selve containeren er opprettet.

Følgende kommando oppretter en svitsj med et subnett 10.0.5.0/24 og IPv4-adresse 10.0.5.1/24, og inkluderer også ipv4.nat slik at containere kan få tilgang til Internett gjennom verten ved å bruke NAT-tjenesten:

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

Sjekke listen over tilgjengelige nettverksenheter i LXD:

lxc network list

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

Du kan også bekrefte at en nettverksenhet er opprettet ved å bruke standardverktøyet til Linux-distribusjonen - 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

Konfigurasjonsprofil ^

Hver container i LXD har sin egen konfigurasjon og kan utvide den med globalt erklærte konfigurasjoner kalt konfigurasjonsprofiler. Bruk av konfigurasjonsprofiler på en beholder har en kaskademodell, følgende eksempel viser dette:

Grunnleggende funksjoner i LXD - Linux containersystemer

I dette eksemplet er det opprettet tre profiler i LXD-systemet: default, hddpool и hostfs. Alle tre profilene brukes på en beholder som har en lokal konfigurasjon (grå område). Profil default har en enhet root som har en parameter pool er lik ssdpool, men takket være applikasjonsmodellen for kaskadekonfigurasjon kan vi bruke en profil på beholderen hddpool som har en parameter pool vil overstyre den samme parameteren fra profilen default og beholderen vil motta enhetskonfigurasjonen root med parameter pool lik hddpool, og profilen hostfs bare legger til en ny enhet i beholderen.

For å se listen over tilgjengelige konfigurasjonsprofiler, bruk følgende kommando:

lxc profile list

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

En fullstendig liste over tilgjengelige kommandoer for å jobbe med en profil kan fås ved å legge til nøkkelen --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

Redigerer profilen din ^

Standard konfigurasjonsprofil default har ikke en nettverkskortkonfigurasjon for containeren og alle nyopprettede containere har ikke et nettverk, for dem er det nødvendig å opprette lokale (dedikerte) nettverksenheter med en egen kommando, men vi kan opprette en global nettverksenhet i konfigurasjonen profil som deles mellom alle beholdere som bruker denne profilen. På denne måten, umiddelbart etter kommandoen for å opprette en ny beholder, vil de ha et nettverk med nettverkstilgang. Samtidig er det ingen begrensninger; vi kan alltid opprette en lokal nettverksenhet senere om nødvendig.

Følgende kommando vil legge til enheten i konfigurasjonsprofilen eth0 типа nic koblet til nettverket lxdbr0:

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

Det er viktig å merke seg at siden vi faktisk la til enheten i konfigurasjonsprofilen, hvis vi spesifiserte en statisk IP-adresse i enheten, vil alle beholdere som vil bruke denne profilen dele den samme IP-adressen. Hvis det er behov for å opprette en beholder med en statisk IP-adresse tildelt beholderen, bør du opprette en nettverksenhetskonfigurasjon på beholdernivå (lokal konfigurasjon) med IP-adresseparameteren, og ikke på profilnivå.

La oss sjekke 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 profilen kan vi se at for alle nyopprettede beholdere vil det bli opprettet to enheter:

  • eth0 - Enhetstype nic koblet til en svitsj (nettverksbro) lxdbr0
  • root - Enhetstype disk som bruker et lagringsbasseng ssdpool

Opprette nye profiler ^

For å bruke tidligere opprettet Oppbevaringsbasseng containere, opprette en konfigurasjonsprofil ssdroot der vi vil legge til en enhet som disk med monteringspunkt / (root) ved å bruke den tidligere opprettede Oppbevaringsbasseng - ssdpool:

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

På samme måte lager vi en enhet som disk, men i dette tilfellet bruker Oppbevaringsbasseng - hddpool:

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

Sjekker konfigurasjonsprofiler:

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

Bildelager ^

Beholdere er laget av bilder som er spesialmonterte distribusjoner som ikke har en Linux-kjerne. Derfor, før du kjører beholderen, må den distribueres fra dette bildet. Kilden til bilder er et lokalt arkiv hvor bilder lastes ned fra eksterne arkiver.

Eksterne bildelager ^

Som standard er LXD konfigurert til å motta bilder fra tre eksterne kilder:

  • ubuntu: (for stabile Ubuntu-bilder)
  • ubuntu-daglig: (for daglige Ubuntu-bilder)
  • Bilder: (for en haug med andre distroer)

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

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 å vise et begrenset antall kolonner brukte vi alternativet -c med parametere dasut, og begrenset også lengden på listen med kommandoen head.

Filtrering er tilgjengelig for å vise en liste over bilder. Følgende kommando vil vise alle tilgjengelige distribusjonsarkitekturer 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 bildelager ^

For å begynne å bruke beholderen, må du legge til et bilde fra det globale depotet til det lokale local:. Nå er det lokale depotet tomt, kommandoen vil sørge for dette lxc image list. Hvis metoden list ikke spesifiser et depot, da vil det lokale depotet bli brukt som standard - local:

lxc image list local:

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

Bilder i depotet administreres ved hjelp av følgende metoder:

Lag
beskrivelse

lxc bilde alias
Administrer bildealiaser

lxc bilde kopiere
Kopier bilder mellom servere

lxc bilde slette
Slett bilder

lxc bilde redigere
Rediger bildeegenskaper

lxc bilde eksportere
Eksporter og last ned bilder

lxc bilde importere
Importer bilder til bildelageret

lxc bilde info
Vis nyttig informasjon om bilder

lxc bilde liste
Liste bilder

lxc bilde refresh
Oppdater bilder

lxc bilde Vis
Vis bildeegenskaper

Kopier bildet til det lokale depotet fra det globale images::

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

Image copied successfully!

La oss vise en liste over alle bilder som for øyeblikket er tilgjengelige i det lokale depotet local::

lxc image -c lfdatsu list local:

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

LXD-konfigurasjon ^

I tillegg til den interaktive modusen, støtter LXD også en ikke-interaktiv konfigurasjonsinstallasjonsmodus, dette er når konfigurasjonen er spesifisert i form av en YAML-fil, et spesielt format som lar deg installere hele konfigurasjonen på en gang, og omgå utførelsen av mange interaktive kommandoer som ble diskutert ovenfor i denne artikkelen, inkludert nettverkskonfigurasjon, opprettelse av konfigurasjonsprofiler, etc. Vi vil ikke dekke dette området her, du kan sjekke det ut på egen hånd. i dokumentasjon.

Neste interaktive kommando lxc config som vi skal se på lar deg stille inn konfigurasjonen. For eksempel, for å sikre at nedlastede bilder til det lokale depotet ikke automatisk oppdateres fra de globale depotene, kan vi aktivere denne virkemåten med følgende kommando:

lxc config set images.auto_update_cached=false

Opprette og administrere en beholder ^

Bruk kommandoen for å lage en beholder lxc init som verdier overføres til репозиторий:образ og deretter ønsket ID for beholderen. Depotet kan spesifiseres som lokalt local: det samme er enhver global en. Hvis depotet ikke er spesifisert, brukes som standard det lokale depotet til å søke etter bildet. Hvis bildet er spesifisert fra det globale depotet, vil bildet først lastes ned til det lokale depotet og deretter brukes til å opprette beholderen.

La oss kjøre følgende kommando for å lage vår første beholder:

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

La oss se på kommandotastene som vi bruker her i rekkefølge:

  • alpine3 — Et alias (alias) er spesifisert for bildet som tidligere ble lastet opp til det lokale depotet. Hvis aliaset ikke ble opprettet for dette bildet, kan du alltid referere til bildet etter det Fingeravtrykk som vises i tabellen.
  • alp — Angir identifikatoren for beholderen
  • --storage — Denne tasten indikerer i hvilken Oppbevaringsbasseng en beholder vil bli opprettet
  • --profile — Disse nøklene bruker konfigurasjon fra tidligere opprettede konfigurasjonsprofiler til beholderen

Vi starter beholderen, som begynner å lansere init-systemet for distribusjonen:

lxc start alp

Du kan også bruke kommandoen lxc launch som lar deg kombinere lag lxc init и lxc start i én operasjon.

Kontroller statusen til beholderen:

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

Sjekke beholderkonfigurasjonen:

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 seksjonen profiles vi kan sørge for at denne beholderen bruker to konfigurasjonsprofiler − default и hddroot. I seksjon devices vi kan bare oppdage én enhet siden nettverksenheten ble opprettet på profilnivå default. For å se alle enhetene som brukes av beholderen, må du legge til en nøkkel --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: ""

Angi en statisk IP-adresse ^

Hvis vi prøver å angi en IP-adresse for en nettverksenhet eth0 team lxc config device set alp beregnet for containerkonfigurasjonen, vil vi motta en feilmelding som vil rapportere at enheten ikke eksisterer fordi enheten eth0 som brukes av 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 sette en statisk IP-adresse for eth0 enheter i profilen, men det vil være det samme for alle beholdere som skal bruke denne profilen. La oss derfor legge til en enhet dedikert til beholderen:

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

Deretter må du starte beholderen på nytt:

lxc restart alp

Hvis vi ser på beholderkonfigurasjonen nå, trenger vi ikke bruke alternativet --expanded for å se nettverksenheten eth0, siden vi opprettet den på beholdernivå og den gikk over den samme enheten 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: ""

Fjerne en beholder ^

For å fjerne en beholder, bruk kommandoen lxc delete, men før du fjerner beholderen, må den stoppes ved hjelp av kommandoen lxc stop:

lxc stop alp

lxc list

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

Etter at vi har verifisert at tilstanden til beholderen har blitt STOPPET, kan den fjernes fra Oppbevaringsbasseng:

lxc delete alp

Containertilgang ^

For å utføre kommandoer i en container direkte, omgå nettverkstilkoblinger, bruk kommandoen lxc exec som utfører kommandoer i beholderen uten å starte systemskallet. Hvis du trenger å utføre en kommando i et skall ved hjelp av skallmønstre som variabler, filomdirigeringer (pipe), etc., må du eksplisitt starte skallet og sende kommandoen som en nøkkel, for eksempel:

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

Kommandoen brukte et spesielt escape-tegn for spesiell karakter $ slik at variabelen $HOME ble ikke tolket på vertsmaskinen, men ble tolket kun inne i containeren.

Det er også mulig å starte den interaktive skallmodusen, og deretter avslutte økten ved å kjøre hurtigtast CTRL+D:

lxc exec alp -- /bin/sh

Beholderressursstyring ^

I LXD kan du administrere containerressurser ved å bruke et spesielt sett med konfigurasjon. Du finner en fullstendig liste over konfigurasjonsparametere for beholder i dokumentasjon.

RAM-ressursbegrensning ^

Parameter limits.memory begrenser mengden RAM som er tilgjengelig for beholderen. Verdien er et tall og en av tilgjengelige suffikser.

La oss sette beholderens RAM-grense til 256 MB:

lxc config set alp limits.memory 256MB

Det er også andre parametere for å begrense minne:

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

Lag lxc config show lar deg vise hele beholderkonfigurasjonen, inkludert den anvendte ressursgrensen som ble angitt:

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-ressursgrense ^

Det er flere måter å begrense CPU-ressurser på. typer restriksjoner:

  • limit.cpu - binder en beholder til en eller flere CPU-kjerner
  • limits.cpu.allowance - administrerer enten CFS-planleggerkvoter når tidsgrensen har passert, eller den universelle CPU-ressursdelingsmekanismen når prosentandelen har passert
  • limits.cpu.priority - planleggerprioritet når flere forekomster som deler et sett med prosessorer blir tildelt samme prosentandel av prosessorer

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

Diskplassbegrensning ^

I tillegg til restriksjoner som f.eks limits.read, limits.write vi kan også begrense mengden diskplass som forbrukes av beholderen (fungerer bare med ZFS eller BTRFS):

lxc config device set alp root size=2GB

Etter installasjon, i parameteren devices.root.size Vi kan bekrefte den angitte grensen:

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

For å se de brukte diskkvotene 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

Til tross for at vi har satt en grense for rotenheten til beholderen til 2GB, systemverktøy som f.eks. df vil ikke se denne begrensningen. For å gjøre dette vil vi gjennomføre en liten test og finne ut hvordan det fungerer.

La oss lage 2 nye identiske beholdere i samme Oppbevaringsbasseng (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         |
+------+---------+------------------+------+-----------+-----------+

La oss lage en 1 GB fil i en av beholderne:

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

La oss sørge for at filen er opprettet:

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 andre beholderen, sjekk for eksistensen av en fil på samme plassering, så vil denne filen ikke være der, noe som forventes, siden beholdere er opprettet i sine egne Lagringsvolum i den samme Oppbevaringsbasseng:

lxc exec alp2 -- ls -lh
total 0

Men la oss sammenligne verdiene den produserer df på den ene og den andre beholderen:

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

enhet /dev/loop1 montert som rotpartisjonen er Oppbevaringsbasseng som disse beholderne bruker, så de deler volumet mellom to.

Ressursforbruksstatistikk ^

Du kan se ressursforbruksstatistikk for en beholder ved å bruke 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

Jobber med øyeblikksbilder ^

LXD har muligheten til å lage øyeblikksbilder og gjenopprette beholdertilstanden fra dem.

For å lage et øyeblikksbilde, kjør følgende kommando:

lxc snapshot alp snapshot1

Teamet lxc snapshot ingen nøkkel tilgjengelig list, derfor, for å se listen over øyeblikksbilder, må du bruke kommandoen som viser generell informasjon om beholderen:

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

Du kan gjenopprette en beholder fra et øyeblikksbilde ved å bruke kommandoen lxc restore spesifisere beholderen som gjenopprettingen skal utføres for og øyeblikksbildealiaset:

lxc restore alp snapshot1

Følgende kommando brukes til å slette et øyeblikksbilde. Vær oppmerksom på at kommandosyntaksen ikke er lik alle andre; her må du spesifisere en skråstrek etter beholdernavnet. Hvis skråstreken utelates, tolkes kommandoen for å slette et øyeblikksbilde som en kommando for å slette en beholder!

lxc delete alp/snapshot1

I eksempelet ovenfor så vi på såkalte statsløse øyeblikksbilder. LXD har en annen type øyeblikksbilder - stateful, som lagrer gjeldende tilstand for alle prosesser i containeren. Det er en rekke interessante og nyttige funksjoner knyttet til stateful snapshots.

Hva annet? ^

  • En modul er tilgjengelig for Python-utviklere PyLXD som gir en API til LXD

OPPDATERING 10.04.2020/15/00 XNUMX:XNUMX: Lagt til navigasjon

Kilde: www.habr.com

Legg til en kommentar