LXD ist der System-Container-Manager der nächsten Generation, heißt es Quelle. Es bietet eine ähnliche Benutzeroberfläche wie virtuelle Maschinen, verwendet jedoch stattdessen Linux-Container.

LXD-Kern ist ein privilegierter Daemon (ein Dienst, der mit Root-Rechten läuft), der eine REST-API über einen lokalen Unix-Socket sowie über das Netzwerk bereitstellt, wenn die entsprechende Konfiguration installiert ist. Clients, wie zum Beispiel das mit LXD bereitgestellte Befehlszeilentool, stellen Anfragen über diese REST-API. Das bedeutet, dass alles gleich funktioniert, egal ob Sie auf einen lokalen Host oder einen Remote-Host zugreifen.

In diesem Artikel werden wir uns nicht im Detail mit den Konzepten von LXD befassen und nicht alle in der Dokumentation beschriebenen verfügbaren Funktionen berücksichtigen, einschließlich der jüngsten Implementierung der Unterstützung für virtuelle QEMU-Maschinen parallel zu Containern in den neuesten Versionen von LXD. Stattdessen lernen wir nur die Grundlagen der Containerverwaltung – Einrichten von Speicherpools, Netzwerken, Ausführen eines Containers, Anwenden von Ressourcenbeschränkungen und die Verwendung von Snapshots, damit Sie ein grundlegendes Verständnis von LXD erlangen und Container unter Linux verwenden können.

Vollständige Informationen finden Sie in der offiziellen Quelle:

• Website des Entwicklers
• Dokumentation
• Forum

Navigation

• Installation LXD
  • LXD auf Ubuntu-Distributionen installieren
  • Installation von LXD auf Arch Linux-Distributionen
• Speicher LXD (Speicher)
• LXD wird initialisiert
  • Auswählen eines Dateisystems für den Speicherpool
  • Initialisieren des Netzwerks und des Speicherpools mithilfe des Assistenten
  • Erstellen eines zusätzlichen Speicherpools
    • Erhöhen der Speicherpoolgröße
    • Automatisches Einfügen einer Loopback-Datei in einen Loopback-Gerätesteckplatz
  • Sicherheit. Containerprivilegien
  • Erstellen eines virtuellen Netzwerk-Switches
  • Konfigurationsprofil
    • Profilbearbeitung
    • Neue Profile erstellen
  • Bild-Repository
    • Remote-Image-Repositorys
    • Lokales Bild-Repository
  • LXD-Konfiguration
• Erstellen und Verwalten eines Containers
  • Festlegen einer statischen IP-Adresse
  • Entfernen eines Containers
  • Containerzugang
  • Container-Ressourcenmanagement
    • Beschränkung der RAM-Ressourcen
    • CPU-Ressourcenlimit
    • Beschränkung des Speicherplatzes
    • Statistiken zum Ressourcenverbrauch
  • Arbeiten mit Schnappschüssen

Installation LXD ^

LXD auf Ubuntu-Distributionen installieren ^

Im Ubuntu 19.10-Distributionspaket lxd hat eine Sendung auf Snap-Paket:

apt search lxd

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

Das bedeutet, dass zwei Pakete gleichzeitig installiert werden, eines als Systempaket und das andere als Snap-Paket. Die Installation von zwei Paketen auf einem System kann zu Problemen führen, bei denen das Systempaket verwaist, wenn das Snap-Paket vom Snap-Paketmanager entfernt wird.

Paket finden lxd Im Snap-Repository können Sie den folgenden Befehl verwenden:

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

Durch Ausführen des Befehls list Sie können sicherstellen, dass das Paket lxd Noch nicht installiert:

snap list

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

Obwohl LXD ein Snap-Paket ist, muss es über das Systempaket installiert werden lxd, wodurch die entsprechende Gruppe im System und die erforderlichen Dienstprogramme erstellt werden /usr/bin usw.

sudo apt update
sudo apt install lxd

Stellen wir sicher, dass das Paket als Snap-Paket installiert ist:

snap list

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

Installation von LXD auf Arch Linux-Distributionen ^

Um das LXD-Paket auf dem System zu installieren, müssen Sie die folgenden Befehle ausführen. Der erste Befehl aktualisiert die Liste der im Repository verfügbaren Pakete auf dem System, der zweite installiert das Paket direkt:

sudo pacman -Syyu && sudo pacman -S lxd

Nach der Installation des Pakets muss es zur Verwaltung von LXD durch einen regulären Benutzer zur Systemgruppe hinzugefügt werden lxd:

sudo usermod -a -G lxd user1

Stellen wir sicher, dass der Benutzer user1 zur Gruppe hinzugefügt lxd:

id -Gn user1

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

Wenn die Gruppe lxd nicht in der Liste sichtbar ist, müssen Sie die Benutzersitzung erneut aktivieren. Dazu müssen Sie sich abmelden und unter demselben Benutzer anmelden.

Aktivieren Sie in systemd Laden des LXD-Dienstes beim Systemstart:

sudo systemctl enable lxd

Starten wir den Dienst:

sudo systemctl start lxd

Überprüfen des Servicestatus:

sudo systemctl status lxd

Speicher LXD (Speicher) ^

Bevor die Initialisierung beginnt, müssen wir verstehen, wie der Speicher in LXD logisch angeordnet ist.

Lagerung (Lagerung) состоит von einem oder mehreren Speicherpool das eines der unterstützten Dateisysteme wie ZFS, BTRFS, LVM oder reguläre Verzeichnisse verwendet. Jeden Speicherpool ist in Bände unterteilt (Speichervolumen), die Bilder, Container oder Daten für andere Zwecke enthalten.

• Bilder - Hierbei handelt es sich um speziell zusammengestellte Distributionen ohne den Linux-Kernel, die von externen Quellen erhältlich sind
• Container – Hierbei handelt es sich um bereitgestellte Distributionen aus Images, die sofort einsatzbereit sind
• Schnappschüsse – Dies sind Momentaufnahmen des Zustands von Containern, zu denen Sie zurückkehren können

Um den Speicher in LXD zu verwalten, verwenden Sie den Befehl lxc storage ein Zertifikat, das Sie durch Angabe des Schlüssels erhalten können - lxc storage --help

Der folgende Befehl zeigt eine Liste aller an Speicherpool im LXD-Speicher:

lxc storage list

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

Um eine Liste aller anzuzeigen Speichervolumen in der ausgewählten Speicherpool dient der Mannschaft 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       |
+-----------+----------------------------------+-------------+---------+

Auch wenn für Speicherpool Beim Erstellen wurde das BTRFS-Dateisystem ausgewählt, dann erhalten Sie eine Liste Speichervolumen oder Subvolumes In der BTRFS-Interpretation können Sie das Toolkit dieses Dateisystems verwenden:

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

LXD wird initialisiert ^

Bevor Sie Container erstellen und verwenden, müssen Sie eine allgemeine LXD-Initialisierung durchführen, die das Netzwerk und den Speicher erstellt und konfiguriert. Dies kann manuell mithilfe von Standard-Client-Befehlen erfolgen, die in der Liste verfügbar sind, indem Sie den Befehl aufrufen lxc --help oder mit dem Initialisierungsassistenten lxd init Beantwortung einiger Fragen.

Auswählen eines Dateisystems für den Speicherpool ^

Während der Initialisierung stellt LXD mehrere Fragen, einschließlich der Bestimmung des Dateisystemtyps als Standard Speicherpool. Standardmäßig ist dafür das BTRFS-Dateisystem ausgewählt. Ein Wechsel zu einem anderen FS ist nach der Erstellung nicht mehr möglich. Es wird empfohlen, einen FS auszuwählen Funktionsvergleichstabelle:

Merkmal
Verzeichnis
Btrfs
LVM
ZFS
CEPH

Optimierte Bildspeicherung
nicht
ja
ja
ja
ja

Optimierte Instanzerstellung
nicht
ja
ja
ja
ja

Optimierte Snapshot-Erstellung
nicht
ja
ja
ja
ja

Optimierte Bildübertragung
nicht
ja
nicht
ja
ja

Optimierte Instanzübertragung
nicht
ja
nicht
ja
ja

Beim Schreiben kopieren
nicht
ja
ja
ja
ja

Blockbasiert
nicht
nicht
ja
nicht
ja

Sofortiges Klonen
nicht
ja
ja
ja
ja

Speichertreiber, der in einem Container verwendet werden kann
ja
ja
nicht
nicht
nicht

Wiederherstellung von älteren Snapshots (nicht den neuesten)
ja
ja
ja
nicht
ja

Speicherkontingente
Ja(*)
ja
ja
ja
nicht

Initialisieren des Netzwerks und des Speicherpools mithilfe des Assistenten ^

Der nächste Befehl, den wir uns ansehen, schlägt vor, die Hauptkomponenten von LXD einzurichten, indem einfache Fragen mit dem Initialisierungsassistenten beantwortet werden.

Führen Sie den Befehl aus lxc init und geben Sie die Antworten auf die Fragen nach dem Doppelpunkt ein, wie im Beispiel unten gezeigt, oder ändern Sie sie entsprechend Ihren Bedingungen:

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

Erstellen eines zusätzlichen Speicherpools ^

Im vorherigen Schritt haben wir erstellt Speicherpool welches den Namen erhielt ssdpool und die Datei davon befindet sich auf meinem System unter /var/lib/lxd/disks/ssdpool.img. Diese Dateisystemadresse entspricht dem physischen SSD-Laufwerk in meinem PC.

Die folgenden Maßnahmen sollen das Verständnis für die gespielte Rolle erweitern Speicherpool Im Repository erstellen wir ein zweites Speicherpool die sich physisch auf einem anderen Datenträgertyp, der Festplatte, befindet. Das Problem ist, dass LXD das Erstellen nicht zulässt Speicherpool außer Adresse /var/lib/lxd/disks/ und selbst symbolische Links funktionieren nicht, Sehen Sie sich die Antwort des Entwicklers an. Wir können diese Einschränkung während der Initialisierung/Formatierung umgehen Speicherpool indem Sie den Wert als Blockgerät anstelle des Pfads zur Loopback-Datei angeben, indem Sie diesen im Schlüssel angeben source.

Also vor dem Erstellen Speicherpool Sie müssen eine Loopback-Datei oder eine vorhandene Partition in Ihrem Dateisystem definieren, die verwendet werden soll. Dazu erstellen und verwenden wir eine Datei, deren Größe wir auf 10 GB beschränken:

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

Verbinden wir die Loopback-Datei mit einem kostenlosen Loopback-Gerät:

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

/dev/loop1

Dank des Schlüssels --show Wenn Sie den Befehl ausführen, wird auf dem Bildschirm der Name des Geräts angezeigt, mit dem unsere Loopback-Datei verbunden ist. Bei Bedarf können wir eine Liste aller ausgelasteten Geräte dieses Typs anzeigen, um sicherzustellen, dass unsere Aktionen korrekt sind:

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

Anhand der Liste können Sie erkennen, dass das Gerät über Folgendes verfügt /dev/loop1 Loopback-Datei enthalten /mnt/work/lxd/hddpool.img, und im Gerät /dev/loop0 Loopback-Datei enthalten /var/lib/lxd/disks/ssdpool.img was der Vorgabe entspricht Speicherpool.

Der folgende Befehl erstellt ein neues Speicherpool in LXD basierend auf der Loopback-Datei, die wir gerade vorbereitet haben. LXD formatiert die Loopback-Datei /mnt/work/lxd/hddpool.img im Gerät /dev/loop1 für das BTRFS-Dateisystem:

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

Lassen Sie uns eine Liste aller anzeigen Speicherpool zum Screenen:

lxc storage list

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

Erhöhen der Speicherpoolgröße ^

Nach der Erstellung SpeicherpoolBei Bedarf kann es erweitert werden. Für Speicherpool Führen Sie basierend auf dem BTRFS-Dateisystem die folgenden Befehle aus:

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

Automatisches Einfügen einer Loopback-Datei in einen Loopback-Gerätesteckplatz ^

Wir haben ein kleines Problem, beim Neustart des Hostsystems die Datei /mnt/work/lxd/hddpool.img wird aus dem Gerät "fliegen". /dev/loop1 und der LXD-Dienst stürzt beim Laden ab, weil er ihn auf diesem Gerät nicht sieht. Um dieses Problem zu lösen, müssen Sie einen Systemdienst erstellen, der diese Datei in das Gerät einfügt /dev/loop1 wenn das Hostsystem bootet.

Lasst uns kreieren Einheit Dateityp в /etc/systemd/system/ für das SystemD-Initialisierungssystem:

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

Aktivieren Sie den Dienst:

sudo systemctl enable lxd-hddpool

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

Nach dem Neustart des Hostsystems überprüfen wir den Dienststatus:

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).

Anhand der Ausgabe können wir überprüfen, ob der Dienststatus vorliegt aktivObwohl die Ausführung unseres Skripts mit einem Befehl abgeschlossen war, ermöglichte uns die Option dies RemainAfterExit=true.

Sicherheit. Containerprivilegien ^

Da alle Containerprozesse tatsächlich isoliert auf dem Hostsystem unter Verwendung seines Kernels laufen, bietet LXD zum weiteren Schutz des Zugriffs von Containerprozessen auf das Hostsystem Prozessprivilegien, wobei:

• Privilegierte Container - Dies sind Container, in denen Prozesse mit UID und GID demselben Eigentümer entsprechen wie auf dem Hostsystem. Beispielsweise hat ein Prozess, der in einem Container mit der UID 0 läuft, dieselben Zugriffsrechte wie ein Prozess auf dem Hostsystem mit der UID 0. Mit anderen Worten: Der Root-Benutzer im Container hat alle Rechte, nicht nur in auf dem Container, sondern auch auf dem Hostsystem, wenn er den isolierten Namensraum des Containers verlassen kann.

• Unprivilegierte Container – Hierbei handelt es sich um Container, in denen Prozesse dem Eigentümer der UID und GID mit einer Nummer von 0 bis 65535 gehören, für das Hostsystem der Eigentümer jedoch mithilfe der hinzugefügten SubUID- bzw. SubGID-Bits maskiert wird. Beispielsweise wird ein Benutzer mit UID=0 in einem Container auf dem Hostsystem als angezeigt SubUID + UID. Dies schützt das Hostsystem, denn wenn ein Prozess im Container seinen isolierten Namensraum verlassen kann, kann er nur als Prozess mit einer unbekannten, sehr hohen UID/GID mit dem Hostsystem kommunizieren.

Standardmäßig haben neu erstellte Container einen unprivilegierten Status und daher müssen wir eine SubUID und eine SubGID definieren.

Erstellen wir zwei Konfigurationsdateien, in denen wir die Maske für SubUID bzw. SubGID festlegen:

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

Um die Änderungen zu übernehmen, muss der LXD-Dienst neu gestartet werden:

sudo systemctl restart lxd

Erstellen eines virtuellen Netzwerk-Switches ^

Da wir das Netzwerk zuvor mit dem Initialisierungsassistenten initialisiert haben lxd init und ein Netzwerkgerät erstellt lxdbr0, dann machen wir uns in diesem Abschnitt einfach mit der Vernetzung in LXD vertraut und lernen, wie man mit dem Client-Befehl einen virtuellen Switch (Bridge) erstellt.

Das folgende Diagramm zeigt, wie ein Switch (Bridge) den Host und die Container in einem Netzwerk verbindet:

Container können über ein Netzwerk mit anderen Containern oder dem Host, auf dem diese Container bereitgestellt werden, kommunizieren. Dazu müssen Sie die virtuellen Netzwerkkarten der Container mit einem virtuellen Switch verbinden. Wir erstellen zunächst einen Switch und verknüpfen die Netzwerkschnittstellen des Containers in den folgenden Kapiteln, nachdem der Container selbst erstellt wurde.

Der folgende Befehl erstellt einen Switch mit einem Subnetz 10.0.5.0/24 und IPv4-Adresse 10.0.5.1/24, und beinhaltet auch ipv4.nat Damit Container mithilfe des NAT-Dienstes über den Host auf das Internet zugreifen können:

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

Überprüfen der Liste der in LXD verfügbaren Netzwerkgeräte:

lxc network list

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

Sie können auch mit dem Standardtool der Linux-Distribution überprüfen, ob ein Netzwerkgerät erstellt wurde: ip link oder ip addr:

ip addr

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

Konfigurationsprofil ^

Jeder Container in LXD hat seine eigene Konfiguration und kann diese mit global deklarierten Konfigurationen namens erweitern Konfigurationsprofile. Das Anwenden von Konfigurationsprofilen auf einen Container erfolgt nach einem Kaskadenmodell. Das folgende Beispiel zeigt dies:

In diesem Beispiel wurden drei Profile im LXD-System erstellt: default, hddpool и hostfs. Alle drei Profile werden auf einen Container angewendet, der eine lokale Konfiguration hat (Graubereich). Profil default hat ein Gerät root welches einen Parameter hat pool ist ssdpool, aber dank des Anwendungsmodells der Kaskadenkonfiguration können wir ein Profil auf den Container anwenden hddpool welches einen Parameter hat pool überschreibt denselben Parameter aus dem Profil default und der Container erhält die Gerätekonfiguration root mit Parameter pool gleich hddpool, und das Profil hostfs fügt dem Container einfach ein neues Gerät hinzu.

Um die Liste der verfügbaren Konfigurationsprofile anzuzeigen, verwenden Sie den folgenden Befehl:

lxc profile list

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

Eine vollständige Liste der verfügbaren Befehle zum Arbeiten mit einem Profil erhalten Sie durch Hinzufügen des Schlüssels --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

Profilbearbeitung ^

Standardkonfigurationsprofil default Hat keine Netzwerkkartenkonfiguration für den Container und alle neu erstellten Container haben kein Netzwerk, für sie ist es notwendig, lokale (dedizierte) Netzwerkgeräte mit einem separaten Befehl zu erstellen, aber wir können in der Konfiguration ein globales Netzwerkgerät erstellen Profil, das von allen Containern gemeinsam genutzt wird, die dieses Profil verwenden. Auf diese Weise verfügen sie unmittelbar nach dem Befehl zum Erstellen eines neuen Containers über ein Netzwerk mit Netzwerkzugriff. Gleichzeitig gibt es keine Einschränkungen, wir können bei Bedarf jederzeit später ein lokales Netzwerkgerät erstellen.

Mit dem folgenden Befehl wird das Gerät zum Konfigurationsprofil hinzugefügt eth0 типа nic mit dem Netzwerk verbunden lxdbr0:

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

Da wir das Gerät tatsächlich zum Konfigurationsprofil hinzugefügt haben, ist es wichtig zu beachten, dass alle Container, die dieses Profil verwenden, dieselbe IP-Adresse verwenden, wenn wir im Gerät eine statische IP-Adresse angegeben haben. Wenn ein Container mit einer für den Container zugewiesenen statischen IP-Adresse erstellt werden muss, sollten Sie eine Netzwerkgerätekonfiguration auf Containerebene (lokale Konfiguration) mit dem IP-Adressparameter und nicht auf Profilebene erstellen.

Schauen wir uns das Profil an:

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

In diesem Profil können wir sehen, dass für alle neu erstellten Container zwei Geräte erstellt werden:

• eth0 - Gerätetyp nic verbunden mit einem Switch (Netzwerkbrücke) lxdbr0
• root - Gerätetyp disk das einen Speicherpool nutzt ssdpool

Neue Profile erstellen ^

Zuvor erstellte verwenden Speicherpool Container erstellen Sie ein Konfigurationsprofil ssdroot in dem wir ein Gerät wie hinzufügen werden disk mit Mountpunkt / (root) mit dem zuvor erstellten Speicherpool - ssdpool:

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

Ebenso erstellen wir ein Gerät wie disk, aber in diesem Fall mit Speicherpool - hddpool:

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

Konfigurationsprofile prüfen:

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

Bild-Repository ^

Container werden aus Images erstellt, bei denen es sich um speziell zusammengestellte Distributionen handelt, die keinen Linux-Kernel haben. Daher muss der Container vor der Ausführung über dieses Image bereitgestellt werden. Die Quelle der Bilder ist ein lokales Repository, in das Bilder von externen Repositorys heruntergeladen werden.

Remote-Image-Repositorys ^

Standardmäßig ist LXD so konfiguriert, dass es Bilder von drei Remote-Quellen empfängt:

• Ubuntu: (für stabile Ubuntu-Images)
• Ubuntu-täglich: (für tägliche Ubuntu-Images)
• Bilder: (für eine Reihe anderer Distributionen)

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    |
+-----------------+------------------------------------------+--------+--------+

Zum Beispiel Repository ubuntu: hat folgende 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  |
+----------------------------------------------+--------------+----------+------------+

Um eine begrenzte Anzahl von Spalten anzuzeigen, haben wir die Option verwendet -c mit Parametern dasut, und begrenzte auch die Länge der Liste mit dem Befehl head.

Für die Anzeige einer Liste von Bildern steht eine Filterung zur Verfügung. Der folgende Befehl listet alle verfügbaren Distributionsarchitekturen auf 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        |
+------------------------------+--------------------------------------+--------------+

Lokales Bild-Repository ^

Um den Container verwenden zu können, müssen Sie ein Image aus dem globalen Repository zum lokalen hinzufügen local:. Jetzt ist das lokale Repository leer, der Befehl stellt dies sicher lxc image list. Wenn die Methode list Geben Sie kein Repository an, dann wird standardmäßig das lokale Repository verwendet - local:

lxc image list local:

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

Bilder im Repository werden mit den folgenden Methoden verwaltet:

Team
Beschreibung

lxc-Bild alias
Bild-Aliase verwalten

lxc-Bild Kopieren
Bilder zwischen Servern kopieren

lxc-Bild löschen
Bilder löschen

lxc-Bild bearbeiten
Bildeigenschaften bearbeiten

lxc-Bild exportieren
Bilder exportieren und herunterladen

lxc-Bild importieren
Importieren Sie Bilder in den Bildspeicher

lxc-Bild Info
Zeigen Sie nützliche Informationen zu Bildern an

lxc-Bild Liste
Bilder auflisten

lxc-Bild erfrischen
Bilder aktualisieren

lxc-Bild erklären
Bildeigenschaften anzeigen

Kopieren Sie das Image vom globalen in das lokale Repository images::

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

Image copied successfully!

Lassen Sie uns eine Liste aller derzeit im lokalen Repository verfügbaren Bilder anzeigen local::

lxc image -c lfdatsu list local:

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

LXD-Konfiguration ^

Zusätzlich zum interaktiven Modus unterstützt LXD auch einen nicht interaktiven Konfigurationsinstallationsmodus. Dabei wird die Konfiguration in Form einer YAML-Datei angegeben, einem speziellen Format, das es Ihnen ermöglicht, die gesamte Konfiguration auf einmal zu installieren und die Ausführung zu umgehen von vielen interaktiven Befehlen, die oben in diesem Artikel besprochen wurden, einschließlich Netzwerkkonfiguration, Erstellung von Konfigurationsprofilen usw. Auf diesen Bereich gehen wir hier nicht ein, Sie können sich selbst einen Überblick verschaffen. in der Dokumentation.

Nächster interaktiver Befehl lxc config Mit dem, das wir uns ansehen werden, können Sie die Konfiguration festlegen. Um beispielsweise sicherzustellen, dass heruntergeladene Bilder in das lokale Repository nicht automatisch von den globalen Repositorys aktualisiert werden, können wir dieses Verhalten mit dem folgenden Befehl aktivieren:

lxc config set images.auto_update_cached=false

Erstellen und Verwalten eines Containers ^

Um einen Container zu erstellen, verwenden Sie den Befehl lxc init an welche Werte übergeben werden репозиторий:образ und dann die gewünschte ID für den Container. Das Repository kann als lokal angegeben werden local: das gilt auch für alle globalen. Wenn das Repository nicht angegeben ist, wird standardmäßig das lokale Repository für die Suche nach dem Bild verwendet. Wenn das Image aus dem globalen Repository angegeben wird, wird das Image zunächst in das lokale Repository heruntergeladen und dann zum Erstellen des Containers verwendet.

Führen wir den folgenden Befehl aus, um unseren ersten Container zu erstellen:

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

Schauen wir uns die Befehlstasten an, die wir hier in der Reihenfolge verwenden:

• alpine3 — Für das Bild, das zuvor in das lokale Repository hochgeladen wurde, wird ein Alias ​​(Alias) angegeben. Wenn der Alias ​​nicht für dieses Bild erstellt wurde, können Sie jederzeit über seinen Alias ​​auf das Bild verweisen Fingerabdruck welches in der Tabelle angezeigt wird.
• alp – Legt die Kennung für den Container fest
• --storage — Dieser Schlüssel gibt an, in welchem Speicherpool Es wird ein Container erstellt
• --profile – Diese Schlüssel kaskadieren die Konfiguration von zuvor erstellten Konfigurationsprofilen auf den Container

Wir starten den Container, der das Init-System der Distribution startet:

lxc start alp

Sie können auch den Befehl verwenden lxc launch wodurch Sie Teams kombinieren können lxc init и lxc start in einem Arbeitsgang.

Zustand des Containers prüfen:

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

Überprüfung der Containerkonfiguration:

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

Im Bereich profiles Wir können sicherstellen, dass dieser Container zwei Konfigurationsprofile verwendet: default и hddroot. Im Abschnitt devices Wir können nur ein Gerät erkennen, da das Netzwerkgerät auf Profilebene erstellt wurde default. Um alle vom Container verwendeten Geräte anzuzeigen, müssen Sie einen Schlüssel hinzufügen --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: ""

Festlegen einer statischen IP-Adresse ^

Wenn wir versuchen, eine IP-Adresse für ein Netzwerkgerät festzulegen eth0 Team lxc config device set alp Für die Containerkonfiguration vorgesehen, erhalten wir eine Fehlermeldung, die besagt, dass das Gerät aufgrund des Geräts nicht vorhanden ist eth0 welches vom Container verwendet wird, gehört zum Profil default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Wir können natürlich eine statische IP-Adresse festlegen eth0 Geräte im Profil, aber es ist für alle Container gleich, die dieses Profil verwenden. Fügen wir daher ein dem Container gewidmetes Gerät hinzu:

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

Dann müssen Sie den Container neu starten:

lxc restart alp

Wenn wir uns jetzt die Containerkonfiguration ansehen, müssen wir die Option nicht verwenden --expanded um das Netzwerkgerät zu sehen eth0, da wir es auf Containerebene erstellt haben und es vom Profil aus über dasselbe Gerät kaskadiert wurde 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: ""

Entfernen eines Containers ^

Um einen Container zu entfernen, verwenden Sie den Befehl lxc delete, aber bevor der Container entfernt wird, muss er mit dem Befehl gestoppt werden lxc stop:

lxc stop alp

lxc list

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

Nachdem wir überprüft haben, ob sich der Zustand des Containers geändert hat GESTOPPT, es kann entfernt werden Speicherpool:

lxc delete alp

Containerzugang ^

Um Befehle in einem Container direkt und unter Umgehung von Netzwerkverbindungen auszuführen, verwenden Sie den Befehl lxc exec die Befehle im Container ausführt, ohne die System-Shell zu starten. Wenn Sie einen Befehl in einer Shell mithilfe von Shell-Mustern wie Variablen, Dateiumleitungen (Pipe) usw. ausführen müssen, müssen Sie die Shell explizit starten und den Befehl als Schlüssel übergeben, zum Beispiel:

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

Der Befehl verwendete ein spezielles Escape-Zeichen für besonderen Charakter $ damit die Variable $HOME wurde nicht auf dem Host-Computer interpretiert, sondern nur innerhalb des Containers.

Es ist auch möglich, den interaktiven Shell-Modus zu starten und die Sitzung dann durch Ausführen eines Hotkeys zu beenden CTRL+D:

lxc exec alp -- /bin/sh

Container-Ressourcenmanagement ^

In LXD können Sie Containerressourcen mithilfe eines speziellen Konfigurationssatzes verwalten. Eine vollständige Liste der Containerkonfigurationsparameter finden Sie hier in der Dokumentation.

Beschränkung der RAM-Ressourcen ^

Parameter limits.memory Begrenzt die Menge an RAM, die dem Container zur Verfügung steht. Der Wert ist eine Zahl und einer von verfügbare Suffixe.

Stellen wir das RAM-Limit des Containers auf 256 MB ein:

lxc config set alp limits.memory 256MB

Darüber hinaus gibt es noch weitere Parameter zur Speicherbegrenzung:

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

Team lxc config show ermöglicht Ihnen die Anzeige der gesamten Containerkonfiguration, einschließlich des angewendeten Ressourcenlimits, das festgelegt wurde:

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

Es gibt mehrere Möglichkeiten, die CPU-Ressourcen zu begrenzen. Arten von Einschränkungen:

• limit.cpu – bindet einen Container an einen oder mehrere CPU-Kerne
• limits.cpu.allowance - verwaltet entweder CFS-Scheduler-Kontingente, wenn das Zeitlimit abgelaufen ist, oder den universellen Mechanismus zur gemeinsamen Nutzung von CPU-Ressourcen, wenn der Prozentsatz abgelaufen ist
• limits.cpu.priority - Scheduler-Priorität, wenn mehreren Instanzen, die sich einen Prozessorsatz teilen, der gleiche Prozentsatz an Prozessoren zugewiesen wird

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

Beschränkung des Speicherplatzes ^

Neben Einschränkungen wie z limits.read, limits.write Wir können auch den vom Container verbrauchten Speicherplatz begrenzen (funktioniert nur mit ZFS oder BTRFS):

lxc config device set alp root size=2GB

Nach der Installation im Parameter devices.root.size Wir können das eingestellte Limit überprüfen:

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

Um die verwendeten Festplattenkontingente anzuzeigen, können wir den Befehl abrufen 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

Obwohl wir für das Root-Gerät des Containers ein Limit von 2 GB festgelegt haben, können Systemdienstprogramme wie z df wird diese Einschränkung nicht sehen. Dazu führen wir einen kleinen Test durch und finden heraus, wie es funktioniert.

Lassen Sie uns zwei neue identische Container im selben erstellen Speicherpool (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         |
+------+---------+------------------+------+-----------+-----------+

Erstellen wir eine 1-GB-Datei in einem der Container:

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

Stellen wir sicher, dass die Datei erstellt wird:

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

Wenn wir im zweiten Container nachsehen, ob eine Datei am selben Speicherort vorhanden ist, ist diese Datei nicht vorhanden, was zu erwarten ist, da Container in einem eigenen Container erstellt werden Speichervolumen im gleichen Speicherpool:

lxc exec alp2 -- ls -lh
total 0

Aber vergleichen wir die Werte, die es erzeugt df auf dem einen und dem anderen Container:

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

Gerät /dev/loop1 gemountet, wie die Root-Partition ist Speicherpool die diese Behälter nutzen, sodass sie ihr Volumen zwischen zwei teilen.

Statistiken zum Ressourcenverbrauch ^

Mit dem folgenden Befehl können Sie Statistiken zum Ressourcenverbrauch für einen Container anzeigen:

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

Arbeiten mit Schnappschüssen ^

LXD bietet die Möglichkeit, Snapshots zu erstellen und daraus den Containerstatus wiederherzustellen.

Um einen Snapshot zu erstellen, führen Sie den folgenden Befehl aus:

lxc snapshot alp snapshot1

Team lxc snapshot kein Schlüssel vorhanden listUm die Liste der Snapshots anzuzeigen, müssen Sie daher den Befehl verwenden, der allgemeine Informationen zum Container anzeigt:

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

Mit dem Befehl können Sie einen Container aus einem Snapshot wiederherstellen lxc restore Angabe des Containers, für den die Wiederherstellung durchgeführt wird, und des Snapshot-Alias:

lxc restore alp snapshot1

Mit dem folgenden Befehl wird ein Snapshot gelöscht. Bitte beachten Sie, dass die Befehlssyntax nicht mit allen anderen übereinstimmt; hier müssen Sie einen Schrägstrich nach dem Containernamen angeben. Wenn der Schrägstrich weggelassen wird, wird der Befehl zum Löschen eines Snapshots als Befehl zum Löschen eines Containers interpretiert!

lxc delete alp/snapshot1

Im obigen Beispiel haben wir uns sogenannte Stateless Snapshots angesehen. LXD verfügt über eine andere Art von Snapshots – Stateful, der den aktuellen Status aller Prozesse im Container speichert. Mit Stateful Snapshots sind eine Reihe interessanter und nützlicher Funktionen verbunden.

Was sonst? ^

• Für Python-Entwickler steht ein Modul zur Verfügung PyLXD die eine API für LXD bereitstellt

UPDATE 10.04.2020 15:00: Navigation hinzugefügt

Source: habr.com