LXD is de next-generation container manager, zo luidt het bron. Het biedt een gebruikersinterface die lijkt op virtuele machines, maar in plaats daarvan Linux-containers gebruikt.

De LXD-kern is een privileged daemon (service uitgevoerd met root-rechten), die een REST API biedt via een lokale unix socket, evenals via het netwerk, mits de juiste configuratie is ingesteld. Clienttools zoals de commandoregeltool die bij LXD wordt geleverd, verzenden verzoeken via deze REST API. Dit betekent dat ongeacht of je verbinding maakt met de lokale host of een externe, alles hetzelfde werkt.

In dit artikel zullen we niet in detail ingaan op de concepten van LXD, en we zullen niet alle beschikbare mogelijkheden bespreken zoals uiteengezet in de documentatie, inclusief de recente implementatie in de laatste versies van LXD die ondersteuning biedt voor QEMU-virtuele machines naast containers. In plaats daarvan leren we alleen de basisfunctionaliteiten van containerbeheer - we zullen opslagpools, netwerken configureren, een container starten, resource-limieten toepassen, en we zullen ook bekijken hoe we snapshots kunnen gebruiken, zodat je een basisbegrip van LXD krijgt en containers in Linux kunt gebruiken.

Voor volledige informatie moet je de officiële bron raadplegen:

• Ontwikkelaarswebsite
• Documentation
• Forum

Navigatie

• Installatie van LXD
  • Installatie van LXD in Ubuntu-distributies
  • Installatie van LXD in Arch Linux-distributies
• LXD Opslag (Storage)
• Initialisatie van LXD
  • Kies een bestandssysteem voor de Storage Pool
  • Initialisatie van netwerk en Storage Pool met behulp van de wizard
  • Een extra Storage Pool aanmaken
    • De grootte van de Storage Pool vergroten
    • Automatische invoeging van de loopback-bestand in de loopback-apparaat slot
  • Beveiliging. Privileges van containers
  • Een virtuele netwerkswitch maken
  • Configuratieprofiel
    • Profiel bewerken
    • Nieuwe profielen aanmaken
  • Afbeeldingenrepository
    • Externe afbeeldingenrepositories
    • Lokaal afbeeldingenrepository
  • Configuratie van LXD
• Een container maken en beheren
  • Een statisch IP-adres instellen
  • Container verwijderen
  • Toegang tot de container
  • Beheer van de middelen van de container
    • Beperking van RAM-resources (geheugen)
    • Beperking van CPU-resources
    • Beperking van schijfruimte
    • Statistieken van resourcegebruik
  • Werken met snapshots

Installatie van LXD ^

Installatie van LXD in Ubuntu-distributies ^

In de Ubuntu 19.10 distributie is het pakket lxd heeft een transmissie op snap-pakket:

apt zoek lxd

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

Dit betekent dat er twee pakketten tegelijk worden geïnstalleerd, één systeempakket en een andere als snap-pakket. Het installeren van twee pakketten in het systeem kan een probleem creëren, waarbij het systeempakket een wees kan worden als het snap-pakket door de snap-pakketbeheerder wordt verwijderd.

Zoek pakket lxd in de snap-repository kan met de volgende commandocommand:

snap vinden lxd

Naam             Versie        Samenvatting
lxd              3.21           Beheerder van systeemcontainers en API
lxd-demo-server  0+git.6d54658  Online software-demo-sessies met LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Afbeeldingsbouwer voor LXC en LXD
fabrica          0.1            Bouw snaps door eenvoudig een webformulier aan te wijzen naar...
satellite        0.1.2          Geavanceerd schaalbaar open source-informatiesysteem

Door het commando uit te voeren lijst kunnen we bevestigen dat het pakket lxd nog niet is geïnstalleerd:

snap lijst

Naam  Versie    Rev   Tracking  Uitgever   Notities
core  16-2.43.3  8689  stabiel    canonical✓  core

Hoewel LXD een snap-pakket is, moet het via het systeempakket worden geïnstalleerd lxd, dat de bijbehorende groep en benodigde hulpprogramma's in het systeem zal creëren. /usr/bin enzovoorts.

sudo apt update
sudo apt install lxd

Laten we controleren of het pakket als snap-pakket is geïnstalleerd:

snap lijst

Naam  Versie    Rev    Tracking  Uitgever   Notities
core  16-2.43.3  8689   stabiel    canonical✓  core
lxd   3.21       13474  stabiel/...  canonical✓  -

Installatie van LXD in Arch Linux-distributies ^

Om het LXD-pakket in het systeem te installeren, moeten we de volgende commando's uitvoeren, de eerste actualiseert de lijst van beschikbare pakketten in de repository, de tweede installeert het pakket:

sudo pacman -Syyu && sudo pacman -S lxd

Na installatie van het pakket, om LXD als gewone gebruiker te beheren, moet deze aan de systeemgroep worden toegevoegd. lxd:

sudo usermod -a -G lxd user1

Laten we bevestigen dat de gebruiker user1 is toegevoegd aan de groep lxd:

id -Gn user1

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

Als de groep lxd niet zichtbaar is in de lijst, moet de gebruikerssessie opnieuw worden geactiveerd. Dit kan door uit te loggen en opnieuw in te loggen met dezelfde gebruiker.

Activeer bij systemd het opstarten van de LXD-service bij het opstarten van het systeem:

sudo systemctl enable lxd

Start de service:

sudo systemctl start lxd

Controleer de status van de service:

sudo systemctl status lxd

LXD Opslag (Storage) ^

Voordat we met de initialisatie beginnen, moeten we begrijpen hoe de opslag in LXD logisch is georganiseerd.

Opslag (Opslag) bestaat uit één of meer Storage Pool dat een van de ondersteunde bestandssystemen gebruikt, zoals ZFS, BTRFS, LVM of gewone directories. Elke Storage Pool wordt verdeeld in volumes (Opslagvolume) die afbeeldingen, containers of gegevens voor andere doeleinden bevatten.

• Afbeeldingen — zijn speciaal samengestelde distributies zonder de Linux-kernel en beschikbaar uit externe bronnen
• Containers — zijn uitgepakte distributies van afbeeldingen, klaar voor gebruik
• Snapshots — zijn momentopnamen van de toestand van containers waarnaar u kunt terugkeren

Voor het beheren van opslag in LXD wordt het commando gebruikt lxc storage de documentatie hiervan kan worden verkregen door de sleutel op te geven — lxc storage --help

Het volgende commando toont een lijst van alle Storage Pool in LXD opslag:

lxc storage list

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

Om een lijst van alle Opslagvolume in het geselecteerde Storage Pool wordt het commando gebruikt 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       |
+-----------+----------------------------------+-------------+---------+

Bovendien, als voor Storage Pool bij het aanmaken het bestandssysteem BTRFS is gekozen, kan de lijst van Opslagvolume of subvolumes in de interpretatie van BTRFS worden verkregen met behulp van de tools van dit bestandssysteem:

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

Initialisatie van LXD ^

Voor het creëren en gebruiken van containers moet een algemene initialisatie van LXD worden uitgevoerd, die het netwerk en de opslag instelt. Dit kan handmatig worden gedaan met behulp van de standaard cliëntcommando's die beschikbaar zijn in de lijst door het commando aan te roepen lxc --help of met behulp van de initialisatieassistent lxd init door het beantwoorden van enkele vragen.

Kies een bestandssysteem voor de Storage Pool ^

Tijdens de initialisatie stelt LXD een aantal vragen, waaronder het bepalen van het type bestandssysteem voor de standaard Storage Pool. Standaard wordt het bestandssysteem BTRFS gekozen. Het is niet mogelijk om na het creëren op een ander FS te wisselen. Voor de keuze van het FS wordt aangeboden vergelijkingstabel van mogelijkheden:

Kenmerk
Map
Btrfs
LVM
ZFS
CEPH

Geoptimaliseerde afbeeldingsopslag
no
ja
ja
ja
ja

Geoptimaliseerde instanties creatie
no
ja
ja
ja
ja

Geoptimaliseerde snapshot creatie
no
ja
ja
ja
ja

Geoptimaliseerde afbeeldingsoverdracht
no
ja
no
ja
ja

Geoptimaliseerde instantietransfer
no
ja
no
ja
ja

Kopie op schrijven
no
ja
ja
ja
ja

Blokgebaseerd
no
no
ja
no
ja

Directe kloning
no
ja
ja
ja
ja

Opslagdriver bruikbaar in een container
ja
ja
no
no
no

Herstellen van oudere snapshots (niet de laatste)
ja
ja
ja
no
ja

Opslagquota
ja(*)
ja
ja
ja
no

Initialisatie van netwerk en Storage Pool met behulp van de wizard ^

De volgende opdracht die we zullen bekijken, biedt de mogelijkheid om de belangrijkste componenten van LXD in te stellen door antwoorden op eenvoudige vragen via de initialisatie-assistent.

Voer de opdracht in lxc init en geef antwoorden op de vragen na de dubbele punt zoals getoond in het onderstaande voorbeeld of pas ze aan op basis van uw omstandigheden:

lxd init

Wilt u LXD-clustering gebruiken? (ja/nee) [standaard=nee]: 
Wilt u een nieuwe opslagpool configureren? (ja/nee) [standaard=ja]: 
Naam van de nieuwe opslagpool [standaard=default]: ssdpool         
Naam van de te gebruiken opslagbackend (lvm, btrfs, dir) [standaard=btrfs]: 
Wilt u een nieuwe BTRFS-pool maken? (ja/nee) [standaard=ja]: 
Wilt u een bestaand blockapparaat gebruiken? (ja/nee) [standaard=nee]: 
Grootte in GB van het nieuwe loopapparaat (minimaal 1GB) [standaard=15GB]: 10GB
Wilt u verbinding maken met een MAAS-server? (ja/nee) [standaard=nee]: 
Wilt u een nieuwe lokale netwerkkoppelvlak creëren? (ja/nee) [standaard=ja]: 
Wat moet de nieuwe brug heten? [standaard=lxdbr0]: 
 welk IPv4-adres moet worden gebruikt? (CIDR-subnetnotatie, “auto” of “geen”) [standaard=auto]: 10.0.5.1/24
Wilt u dat LXD IPv4-verkeer NAT op uw brug? [standaard=ja]: 
Welk IPv6-adres moet worden gebruikt? (CIDR-subnetnotatie, “auto” of “geen”) [standaard=auto]: geen
Wilt u dat LXD beschikbaar is via het netwerk? (ja/nee) [standaard=nee]: 
Wilt u dat verouderde gecachte afbeeldingen automatisch worden bijgewerkt? (ja/nee) [standaard=ja] nee
Wilt u een YAML "lxd init" voorinstelling laten afdrukken? (ja/nee) [standaard=nee]: 

Een extra Storage Pool aanmaken ^

In de vorige stap hebben we gemaakt Storage Pool dat de naam kreeg ssdpool en dat het bestand op mijn systeem is geplaatst op adres /var/lib/lxd/disks/ssdpool.img. Dit adres van het bestandssysteem komt overeen met de fysieke SSD-schijf in mijn pc.

Volgende stappen om een beter begrip te krijgen van de rol van Storage Pool in de opslag wordt, zullen we een tweede aanmaken Storage Pool die fysiek op een ander type schijf zal staan, op een HDD. Het probleem is dat LXD het niet toestaat om te creëren Storage Pool buiten het adres /var/lib/lxd/disks/ en zelfs symbolische links zullen niet werken, zie het antwoord van de ontwikkelaar. Dit beperking kunnen we omzeilen door tijdens de initialisatie/formaat te Storage Pool de waarde als een blokapparaat in te stellen in plaats van een pad naar een loopback-bestand in te voeren in de sleutel source.

Dus, voordat we gaan creëren Storage Pool U moet het loopback-bestand of een bestaande partitie in uw bestandssysteem bepalen die het zal gebruiken. Hiervoor zullen we een bestand aanmaken en gebruiken dat we beperken tot een grootte van 10GB:

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

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

We zullen het loopback-bestand koppelen aan een vrij loopback-apparaat:

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

/dev/loop1

Dankzij de sleutel --show geeft de uitvoering van het commando de naam van het apparaat terug waar ons loopback-bestand aan is gekoppeld. Indien nodig kunnen we een lijst van alle bezette apparaten van dit type weergeven, om de juistheid van onze acties te controleren:

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

Uit de lijst blijkt dat in het apparaat /dev/loop1 het loopback-bestand is gekoppeld /mnt/work/lxd/hddpool.img, en in het apparaat /dev/loop0 het loopback-bestand is gekoppeld /var/lib/lxd/disks/ssdpool.img dat overeenkomt met de standaard Storage Pool.

Het volgende commando maakt een nieuwe Storage Pool in LXD op basis van het zojuist voorbereide loopback-bestand. LXD formatteert het loopback-bestand /mnt/work/lxd/hddpool.img in het apparaat /dev/loop1 tot een BTRFS-bestandssysteem:

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

Laten we de lijst van alle Storage Pool op het scherm weergeven:

lxc storage list

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

De grootte van de Storage Pool vergroten ^

Na aanmaak Storage Pool, indien nodig, kan deze worden uitgebreid. Voor Storage Pool gebaseerd op het BTRFS-bestandssysteem, voert u de volgende commando's uit:

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

Automatische invoeging van de loopback-bestand in de loopback-apparaat slot ^

We hebben een klein probleem; bij het herstarten van het hostsysteem, "valt" het bestand uit het apparaat /mnt/work/lxd/hddpool.img en zal de LXD-service bij het opstarten crashen, omdat het dit niet in het apparaat zal zien. Om dit probleem op te lossen, moet er een systeemsdienst worden aangemaakt die dit bestand in het apparaat invoegt /dev/loop1 bij het opstarten van het hostsysteem. /dev/loop1 Laten we een

unit type service voor het SystemD-initiesysteem: in /etc/systemd/system/ 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

Activeer de service:

We activeren de service:

sudo systemctl enable lxd-hddpool

Gecreëerd symlink /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

Na het opnieuw opstarten van het host-systeem controleren we de status van de service:

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Loaded: geladen (/etc/systemd/system/lxd-hddpool.service; ingeschakeld; vendor preset: uitgeschakeld)
     Active: actief (verlaat) sinds Wed 2020-04-08 03:43:53 MSK; 1min 37s geleden
    Process: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (code=verlaat, status=0/SUCCESS)
   Main PID: 711 (code=verlaat, status=0/SUCCESS)

apr 08 03:43:52 manjaro systemd[1]: Startende Losetup LXD Storage Pool (hddpool)...
apr 08 03:43:53 manjaro systemd[1]: Voltooid Losetup LXD Storage Pool (hddpool).

Uit de output kunnen we opmaken dat de status van de service gelijk is aan actief, hoewel de uitvoering van ons script als één commando is voltooid, stelde deze optie ons in staat om RemainAfterExit=true.

Beveiliging. Privileges van containers ^

Aangezien alle processen van de container feitelijk in isolatie op het host-systeem worden uitgevoerd met behulp van zijn kernel, biedt LXD voor extra beveiliging van de toegang van containerprocessen tot het host-systeem de privilege van processen, waarbij:

• Geprivilegieerde containers — zijn containers waarin processen met UID en GID overeenkomen met dezelfde eigenaar als op het host-systeem. Bijvoorbeeld, een proces dat wordt uitgevoerd in een container met UID gelijk aan 0, heeft dezelfde toegangsrechten als het proces op het host-systeem met UID gelijk aan 0. Met andere woorden, de root-gebruiker in de container heeft alle rechten, niet alleen in de container, maar ook op het host-systeem als hij in staat is om buiten de geïsoleerde namespace van de container te komen.

• Niet-geprivilegieerde containers — zijn containers waarin processen eigendom zijn van een eigenaar met UID en GID van 0 tot 65535, maar voor het host-systeem wordt de eigenaar gemaskeerd met behulp van de toegevoegde SubUID- en SubGID-bit. Bijvoorbeeld, een gebruiker met UID=0 in de container zal op het host-systeem worden gezien als SubUID + UID. Dit beschermt het host-systeem, aangezien, als een proces in de container zijn geïsoleerde namespace kan verlaten, hij alleen met het host-systeem kan interageren als een proces met een onbekende, zeer hoge UID/GID.

Standaard hebben nieuw gemaakte containers de status van niet-geprivilegieerd en daarom moeten we SubUID en SubGID definiëren.

Laten we twee configuratiebestanden aanmaken waarin we de maskers voor SubUID en SubGID respectievelijk instellen:

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

Om de wijzigingen toe te passen, moet de LXD-service opnieuw worden gestart:

sudo systemctl restart lxd

Een virtuele netwerkswitch maken ^

Aangezien we eerder het netwerk hebben geconfigureerd met behulp van de initialisatiewizard lxd init en een netwerkinrichting hebben aangemaakt lxdbr0, zullen we in dit gedeelte eenvoudig kennismaken met het netwerk in LXD en hoe we een virtuele switch (netwerkbrug, bridge) kunnen maken met behulp van de clientopdracht.

Het volgende schema toont hoe een switch (netwerkbrug, bridge) de host en de containers in een netwerk verbindt:

Containers kunnen via het netwerk communiceren met andere containers of de host waarop deze containers draaien. Dit vereist dat de virtuele netwerkkaarten van de containers zijn gekoppeld aan de virtuele switch. Eerst maken we de switch, en de netwerkinterfaces van de container worden in de volgende hoofdstukken gekoppeld nadat de container zelf is aangemaakt.

De volgende opdracht maakt een switch met een subnet 10.0.5.0/24 en een IPv4-adres 10.0.5.1/24, en schakelt ook ipv4.nat zodat containers via de host toegang tot internet kunnen krijgen via de NAT-service:

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

Controleer de lijst van netwerkinrichtingen die beschikbaar zijn voor LXD:

lxc network list

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

Bovendien kan de creatie van een netwerkinrichting worden gecontroleerd met behulp van de standaardtool in de Linux-distributie — ip link of ip addr:

ip addr

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

Configuratieprofiel ^

Elke container in LXD heeft zijn eigen configuratie en kan deze uitbreiden met behulp van globaal gedeclareerde configuraties die configuraties worden genoemd configuratieprofielen. Het toepassen van configuratieprofielen op een container volgt een cascade-model, het volgende voorbeeld illustreert dit:

In dit voorbeeld zijn er drie profielen aangemaakt in het LXD-systeem: default, hddpool en hostfs. Alle drie de profielen zijn toegepast op een container met een lokale configuratie (grijze zone). Het profiel default heeft een apparaat root met de parameter pool is gelijk aan ssdpool, maar dankzij het cascade-model van configuratietoepassing kunnen we voor de container het profiel hddpool met de parameter pool dezezelfde parameter van het profiel overschrijven default en de container krijgt de apparaatconfiguratie root met de parameter pool gelijk aan hddpool, terwijl het profiel hostfs gewoon een nieuw apparaat aan de container toevoegt.

Om de lijst met beschikbare configuratieprofielen te zien, dient de volgende opdracht gebruikt te worden:

lxc profile list

+---------+---------+
|  NAAM  | GEBRUIKT DOOR |
+---------+---------+
| default | 1       |
+---------+---------+
| hddroot | 0       |
+---------+---------+
| ssdroot | 1       |
+---------+---------+

De volledige lijst met beschikbare opdrachten voor het werken met profielen kan worden verkregen door de sleutel toe te voegen --help:

lxc profile --help

Beschrijving:
  Beheer profielen

Gebruik:
  lxc profile [commando]

Beschikbare commando's:
  add         Voeg profielen toe aan instanties
  assign      Wijs sets profielen toe aan instanties
  copy        Kopieer profielen
  create      Maak profielen aan
  delete      Verwijder profielen
  device      Beheer apparaatspecificaties
  edit        Bewerk profielconfiguraties als YAML
  get         Verkrijg waarden voor profielconfiguratiesleutels
  list        Lijst profielen
  remove      Verwijder profielen uit instanties
  rename      Hernoem profielen
  set         Stel profielconfiguratiesleutels in
  show        Toon profielconfiguraties
  unset       Maak profielconfiguratiesleutels ongedaan

Profiel bewerken ^

Standaard configuratieprofiel default heeft geen netwerkaansluitingen voor de container en alle nieuw aangemaakte containers hebben geen netwerk. Voor hen moeten afzonderlijke lokale (dedicated) netwerkapparaten worden aangemaakt met een aparte opdracht, maar we kunnen een globaal netwerkapparaat in het configuratieprofiel maken dat zal worden gedeeld tussen alle containers die dit profiel gebruiken. Op deze manier hebben ze direct na de opdracht voor het aanmaken van een nieuwe container toegang tot het netwerk. Daarbij zijn er geen beperkingen, we kunnen altijd later een lokaal netwerkapparaat aanmaken indien nodig.

De volgende opdracht zal een apparaat van het configuratieprofiel toevoegen eth0 van het type nic verbonden met het netwerk lxdbr0:

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

Het is belangrijk op te merken dat omdat we daadwerkelijk een apparaat aan het configuratieprofiel hebben toegevoegd, als we een statisch IP-adres aan het apparaat zouden toewijzen, alle containers die dit profiel toepassen hetzelfde IP-adres zouden delen. Als er behoefte is aan een container met een exclusief statisch IP-adres, moet er een netwerkapparaatconfiguratie op het niveau van de container (lokale configuratie) met het IP-adresparameter worden gemaakt, en niet op het niveau van het profiel.

Laten we het profiel controleren:

lxc profile show default

config: {}
beschrijving: Standaard LXD-profiel
devices:
  eth0:
    naam: eth0
    netwerk: lxdbr0
    type: nic
  root:
    pad: \/
    pool: ssdpool
    type: disk
naam: default
gebruikt door: []

In dit profiel zien we dat er voor alle nieuw te maken containers twee apparaten (devices) zullen worden gemaakt:

• eth0 — Apparaat van het type nic verbonden met de switch (netwerkbrug) lxdbr0
• root — Apparaat van het type disk dat de opslagpool gebruikt ssdpool

Nieuwe profielen aanmaken ^

Om gebruik te maken van de eerder gemaakte Storage Pool containers, maken we een configuratieprofiel aan ssdroot waarin we een apparaat van het type toevoegen disk met het aanknopingspunt / (root) dat de eerder gemaakte gebruikt Storage Pool — ssdpool:

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

Evenzo creëren we een apparaat van het type disk, maar in dit geval gebruikt Storage Pool — hddpool:

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

Controleren we de configuratieprofielen:

lxc profile show ssdroot

config: {}
beschrijving: ""
devices:
  root:
    pad: \/
    pool: ssdpool
    type: disk
naam: ssdroot
gebruikt door: []

lxc profile show hddroot

config: {}
beschrijving: ""
devices:
  root:
    pad: \/
    pool: hddpool
    type: disk
naam: hddroot
gebruikt door: []

Afbeeldingenrepository ^

Containers worden gemaakt uit beelden die speciaal samengestelde distributies zijn zonder een Linux-kernel. Daarom moet de container, voordat deze wordt gestart, vanuit dit beeld worden uitgepakt. De bron van de beelden is een lokale repository waarin beelden worden geüpload vanuit externe repositories.

Externe afbeeldingenrepositories ^

Standaard is LXD ingesteld om beelden te verkrijgen van drie externe bronnen:

• ubuntu: (voor stabiele Ubuntu-beelden)
• ubuntu-daily: (voor dagelijkse Ubuntu-beelden)
• beelden: (voor een aantal andere distributies)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NAAM      |                   URL                    | OPENBAAR | STATISCH |
+-----------------+------------------------------------------+--------+--------+
| images          | https://images.linuxcontainers.org      | JA     | NEE    |
+-----------------+------------------------------------------+--------+--------+
| local (standaard)| unix://                                 | NEE    | JA     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | JA     | JA     |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | JA     | JA     |
+-----------------+------------------------------------------+--------+--------+

Bijvoorbeeld, de repository ubuntu: heeft de volgende afbeeldingen:

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

+----------------------------------------------+--------------+----------+------------+
|                   BESCHRIJVING                | ARCHITECTUUR |   GROOTTE   |   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  |
+----------------------------------------------+--------------+----------+------------+

Om een beperkt aantal kolommen weer te geven, hebben we de optie gebruikt -c met parameters dasut, en we hebben ook de lengte van de lijst beperkt met het commando head.

Voor het opvragen van de lijst van afbeeldingen is filtering beschikbaar. Het volgende commando toont een lijst van alle beschikbare architecturen van de distributie AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Lokaal afbeeldingenrepository ^

Om te beginnen met het gebruik van de container, moet je een afbeelding uit de wereldwijde repository aan de lokale toevoegen. local:. De lokale repository is momenteel leeg, en dat bevestigt de opdracht lxc image list. Als er geen repository wordt opgegeven, zal standaard de lokale repository worden gebruikt — lijst lxc image list local:+-------+-------------+--------+-------------+--------------+------+------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | +-------+-------------+--------+-------------+--------------+------+------+ local:

Beheer van afbeeldingen in de repository gebeurt met de volgende methodes:

lxc image

Opdracht
Omschrijving

alias beheer van afbeeldingsaliassen
Kopieer afbeeldingen tussen servers

alias copy
verwijderen

alias Verwijder afbeeldingen
bewerk

alias Bewerk afbeeldingsparameters
exporteer

alias Exporteer en download afbeeldingen
Importeer afbeeldingen in de afbeeldingsopslag

alias import
info

alias Toon nuttige informatie over afbeeldingen
Lijst afbeeldingen

alias lijst
vernieuwen

alias Vernieuw afbeeldingen
toon

alias Toon afbeeldingsparameters
We kopiëren de afbeelding van de wereldwijde naar de lokale repository

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3Afbeelding succesvol gekopieerd! beelden::

We geven een lijst weer van alle afbeeldingen die momenteel beschikbaar zijn in de lokale repository

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

Naast de interactieve modus ondersteunt LXD ook een niet-interactieve configuratiemodus, waarbij de configuratie wordt opgegeven in de vorm van een YAML-bestand, een speciaal formaat dat het mogelijk maakt om de volledige configuratie in één keer in te stellen, zonder dat er veel interactieve opdrachten uitgevoerd hoeven te worden die eerder in dit artikel zijn behandeld, inclusief netwerkinstellingen, het aanmaken van configuratieprofielen, enzovoort. We zullen dit hier niet bespreken, u kunt dit zelf doen

Configuratie van LXD ^

in de documentatie De volgende interactieve opdracht.

lxc config die we zullen bespreken, stelt je in staat om de configuratie in te stellen. Bijvoorbeeld, om ervoor te zorgen dat de geladen afbeeldingen in de lokale repository niet automatisch worden bijgewerkt vanuit de wereldwijde repositories, kunnen we dit gedrag inschakelen met de volgende opdracht: lxc config set images.auto_update_cached=false

Om een container aan te maken, gebruik je de opdracht

Een container maken en beheren ^

waarbij de waarden worden doorgegeven lxc init repository:image en vervolgens de gewenste identificatie voor de container. De repository kan als lokaal worden opgegeven. en vervolgens de gewenste identificatie voor de container. De repository kan als lokaal worden opgegeven. local: net als elk wereldwijd. Als de repository niet is opgegeven, wordt standaard de lokale repository gebruikt voor het zoeken naar een afbeelding. Als de afbeelding uit een wereldwijde repository is opgegeven, wordt de afbeelding eerst in de lokale repository geladen en daarna gebruikt voor het maken van de container.

Laten we de volgende opdracht uitvoeren om onze eerste container te maken:

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

Laten we de sleutels van de opdracht die we hier gebruiken een voor een doornemen:

• alpine3 — Dit geeft de alias (pseudoniem) op voor de afbeelding die eerder in de lokale repository is geladen. Als er geen alias voor deze afbeelding was aangemaakt, kan altijd naar de afbeelding worden verwezen met zijn Fingerprint die in de tabel wordt weergegeven.
• alp — Dit stelt de identifier voor de container in.
• --storage — Deze sleutel geeft aan in welke Storage Pool de container zal worden aangemaakt.
• --profile — Deze sleutels passen de configuratie van eerder gemaakte configuratieprofielen cascade toe op de container.

We starten de container, die begint met het opstarten van het init-systeem van de distributie:

lxc start alp

Daarnaast kan de opdracht lxc launch worden gebruikt, die de opdrachten lxc init en lxc start combineert tot één operatie.

Laten we de status van de container controleren:

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

Laten we de configuratie van de container controleren:

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

In de sectie profielen kunnen we bevestigen dat deze container twee configuratieprofielen gebruikt — default en hddroot. In de sectie devices kunnen we slechts één apparaat ontdekken, aangezien het netwerkapparaat op profielniveau is aangemaakt. default. Om alle door de container gebruikte apparaten te zien, moet de sleutel worden toegevoegd --expanded:

lxc config show alp --expanded

architectuur: 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
effecten:
  eth0:
    naam: eth0
    netwerk: lxdbr0
    type: nic
  root:
    pad: \/
    pool: hddpool
    type: disk
ephemeraal: false
profielen:
- standaard
- hddroot
stateful: false
beschrijving: ""

Een statisch IP-adres instellen ^

Als we proberen een IP-adres in te stellen voor het netwerkapparaat eth0 met het commando lxc config device set alp bestemd voor de containerconfiguratie, dan krijgen we een foutmelding die aangeeft dat het apparaat niet bestaat omdat het apparaat eth0 dat door de container wordt gebruikt, eigendom is van het profiel default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Fout: Het apparaat bestaat niet

We kunnen natuurlijk een statisch IP-adres instellen voor eth0 het apparaat in het profiel, maar het zal hetzelfde zijn voor alle containers die dit profiel gebruiken. Daarom, laten we een specifiek apparaat voor de container toevoegen:

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

Vervolgens moet de container worden herstart:

lxc restart alp

Als we nu naar de configuratie van de container kijken, hebben we de optie niet nodig --expanded om het netwerkapparaat te zien eth0, omdat we het op het niveau van de container hebben aangemaakt en het ditzelfde apparaat uit het profiel heeft overschreven default:

lxc config show alp

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

Container verwijderen ^

De opdracht voor het verwijderen van de container is lxc delete, maar voordat je de container verwijdert, moet deze worden gestopt met de opdracht lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAAM | STATUS  |       IPV4        | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPED | 10.0.5.10 (eth0)  |      | CONTAINER | 0         |
+------+---------+-------------------+------+-----------+-----------+

Nadat we hebben bevestigd dat de status van de container is geworden STOPPED, kan deze worden verwijderd uit Storage Pool:

lxc delete alp

Toegang tot de container ^

Om opdrachten direct in de container uit te voeren, zonder netwerkverbindingen, gebruik je de opdracht lxc exec die opdrachten in de container uitvoert zonder een shell op te starten. Als je een opdracht in de shell wilt uitvoeren met behulp van shell-patronen zoals variabelen, bestandsomleidingen (pipe), enz., moet je expliciet de shell starten en de opdracht doorgeven als een sleutel, bijvoorbeeld:

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

In de opdracht werd een speciaal teken voor het escapen gebruikt voor het speciaal teken $ zodat de variabele $HOME niet op de hostmachine wordt geïnterpreteerd, maar alleen binnen de container.

Het is ook mogelijk om de interactieve modus van de shell te starten en de sessie te beëindigen met de hotkey CTRL+D:

lxc exec alp -- \/bin\/sh

Beheer van de middelen van de container ^

In LXD kunnen de bronnen van de container worden beheerd met behulp van een specifieke set configuraties. Een volledige lijst van de configuratieparameters van de container kan worden gevonden De volgende interactieve opdracht.

Beperking van RAM-resources (geheugen) ^

Parameter limits.memory beperkt de hoeveelheid RAM die beschikbaar is voor de container. Als waarde wordt een getal en een van de beschikbare suffixen opgegeven..

We stellen de container in op een RAM-limiet van 256 MB:

lxc config set alp limits.memory 256MB

Daarnaast zijn er andere parameters om het geheugen te limiteren:

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

Opdracht lxc config show toont alle configuraties van de container, inclusief de toegepaste resourcebeperkingen:

lxc config show alp

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

Beperking van CPU-resources ^

Voor het beperken van CPU-resources zijn er verschillende soorten beperkingen:

• limit.cpu — bindt de container aan een of meerdere CPU-kernen
• limits.cpu.allowance — regelt ofwel de CFS-schedulerquota's wanneer de tijdslimiet is overschreden, of een universeel mechanisme voor het delen van CPU-resources wanneer het percentage is overschreden
• limits.cpu.priority — prioriteit van de scheduler wanneer meerdere instanties een set van processoren delen en hetzelfde percentage processoren is toegewezen

lxc config set alp limits.cpu.allowance 40%

lxc config show alp

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

Beperking van schijfruimte ^

Naast beperkingen zoals limits.read, limits.write kunnen we ook de schijfcapaciteit die door de container wordt gebruikt beperken (werkt alleen met ZFS of BTRFS):

lxc config device set alp root size=2GB

Na het instellen, in de parameter devices.root.size kunnen we de ingestelde beperking controleren:

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

Om de gebruikte schijfquota te bekijken, kunnen we de opdracht lxc info:

lxc info alp
...
Resources:
  Processes: 5
  Schijfgebruik:
    root: 1.05GB
  CPU-gebruik:
    CPU-gebruik (in seconden): 1
  Geheugenverbruik:
    Geheugen (huidig): 5.46MB
  Netwerkgebruik:
    eth0:
      Ontvangen bytes: 802B
      Verzonden bytes: 1.59kB
      Ontvangen pakketten: 4
      Verzonden pakketten: 14
    lo:
      Ontvangen bytes: 0B
      Verzonden bytes: 0B
      Ontvangen pakketten: 0
      Verzonden pakketten: 0

Hoewel we een limiet voor het rootapparaat van de container op 2GB hebben ingesteld, zullen systeemhulpmiddelen zoals df dit limiet niet zien. Hiervoor gaan we een kleine test uitvoeren om te bekijken hoe dit werkt.

Laten we twee nieuwe identieke containers maken in hetzelfde Storage Pool (hddpool):

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

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAAM | STATUS  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | LOPEND  | 10.0.5.46 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | LOPEND  | 10.0.5.30 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+

In een van de containers maken we een bestand van 1GB:

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

Laten we controleren of het bestand is aangemaakt:

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

Als we in de tweede container kijken en controleren of het bestand op dezelfde locatie bestaat, zal dit bestand er niet zijn, wat te verwachten is, aangezien containers in hun eigen Opslagvolume in deze Storage Pool:

lxc exec alp2 -- ls -lh
totaal 0

Maar laten we de waarden vergelijken die worden weergegeven df in beide containers:

lxc exec alp1 -- df -hT
Bestandssysteem          Type            Grootte    Gebruik Beschikbaar Gebruik% Gemount op
/dev/loop1              btrfs           9.3G   1016.4M      7.8G  11% 
...

lxc exec alp2 -- df -hT
Bestandssysteem          Type            Grootte    Gebruik Beschikbaar Gebruik% Gemount op
/dev/loop1              btrfs           9.3G   1016.4M      7.8G  11% 
...

Apparaat /dev/loop1 Gemount als de rootpartitie is Storage Pool die deze containers gebruiken, waardoor ze de ruimte delen.

Statistieken van resourcegebruik ^

U kunt de resourcegebruikstatistieken voor de container bekijken met de volgende opdracht:

lxc info alp

Naam: alp
Locatie: geen
Afstand: unix://
Architectuur: x86_64
Gemaakt: 2020/04/08 18:05 UTC
Status: Lopend
Type: container
Profielen: 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:
  Processen: 5
  Schijftoepassing:
    root: 495.62kB
  CPU-gebruik:
    CPU-gebruik (in seconden): 1
  Geheugengebruik:
    Geheugen (huidig): 4.79MB
  Netwerkgebruik:
    eth0:
      Ontvangen bytes: 730B
      Verzonden bytes: 1.59kB
      Ontvangen pakketten: 3
      Verzonden pakketten: 14
    lo:
      Ontvangen bytes: 0B
      Verzonden bytes: 0B
      Ontvangen pakketten: 0
      Verzonden pakketten: 0

Werken met snapshots ^

In LXD is het mogelijk om snapshots te maken en de status van de container hiervan te herstellen.

Om een snapshot te maken, voert u de volgende opdracht uit:

lxc snapshot alp snapshot1

De opdracht lxc snapshot heeft niet de optie lijst, dus om de lijst met snapshots te bekijken, moet u de opdracht gebruiken die algemene informatie over de container weergeeft:

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

Herstel de container uit een snapshot met het commando lxc restore door de container aan te geven waarvoor het herstel zal plaatsvinden en de alias van het snapshot:

lxc restore alp snapshot1

Het volgende commando dient voor het verwijderen van een snapshot. Let op, de syntaxis van het commando verschilt van de andere, hier moet een directe schuine streep na de naam van de container worden opgegeven. Als de schuine streep wordt weggelaten, wordt het verwijdercommando voor het snapshot geïnterpreteerd als een commando voor het verwijderen van de container!

lxc delete alp/snapshot1

In het bovenstaande voorbeeld hebben we de zogenaamde stateless-snapshots bekeken. In LXD is er ook een ander type snapshots — stateful, waarin de huidige status van alle processen in de container wordt opgeslagen. Met stateful-snapshots zijn een aantal interessante en nuttige functies verbonden.

Wat nog meer? ^

• Voor Python-ontwikkelaars is er een module beschikbaar PyLXD die een API biedt voor LXD

UPDATE 10.04.2020 15:00: Navigatie toegevoegd

Bron: habr.com