Funzionalità di base dei sistemi contenitore LXD - Linux

Funzionalità di base dei sistemi contenitore LXD - Linux

LXD è il gestore di contenitori di sistema di prossima generazione, così dice fonte. Offre un'interfaccia utente simile alle macchine virtuali, ma utilizza invece contenitori Linux.

Nucleo LXD è un demone privilegiato (un servizio eseguito con diritti di root) che fornisce un'API REST tramite un socket Unix locale, nonché tramite la rete se è installata la configurazione appropriata. I client, come lo strumento da riga di comando fornito con LXD, effettuano richieste tramite questa API REST. Ciò significa che, sia che tu acceda a un host locale o a un host remoto, tutto funziona allo stesso modo.

In questo articolo non ci soffermeremo nel dettaglio sui concetti di LXD, non prenderemo in considerazione tutte le funzionalità disponibili descritte nella documentazione, inclusa la recente implementazione nelle ultime versioni di LXD del supporto per macchine virtuali QEMU in parallelo ai container. Impareremo invece solo le nozioni di base della gestione dei contenitori: configurazione di pool di archiviazione, networking, esecuzione di un contenitore, applicazione dei limiti delle risorse e come utilizzare gli snapshot in modo da poter acquisire una conoscenza di base di LXD e utilizzare i contenitori su Linux.

Per informazioni complete vi rimandiamo alla fonte ufficiale:

Navigazione

Installazione LXD ^

Installazione di LXD su distribuzioni Ubuntu ^

Nel pacchetto di distribuzione Ubuntu 19.10 lxd ha una trasmissione in corso pacchetto a scatto:

apt search lxd

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

Ciò significa che verranno installati due pacchetti contemporaneamente, uno come pacchetto di sistema e l'altro come pacchetto snap. L'installazione di due pacchetti su un sistema può creare qualche problema in cui il pacchetto di sistema potrebbe diventare orfano se il pacchetto snap viene rimosso dal gestore pacchetti snap.

Trova pacchetto lxd nel repository snap è possibile utilizzare il seguente comando:

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

Eseguendo il comando list puoi assicurarti che il pacchetto lxd non ancora installato:

snap list

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

Nonostante LXD sia un pacchetto snap, deve essere installato tramite il pacchetto di sistema lxd, che creerà il gruppo corrispondente nel sistema, le utilità necessarie in /usr/bin eccetera

sudo apt update
sudo apt install lxd

Assicuriamoci che il pacchetto sia installato come pacchetto snap:

snap list

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

Installazione di LXD sulle distribuzioni Arch Linux ^

Per installare il pacchetto LXD sul sistema è necessario eseguire i seguenti comandi, il primo aggiornerà l'elenco dei pacchetti presenti sul sistema disponibili nel repository, il secondo installerà direttamente il pacchetto:

sudo pacman -Syyu && sudo pacman -S lxd

Dopo aver installato il pacchetto, per poter gestire LXD da un utente normale, è necessario aggiungerlo al gruppo di sistema lxd:

sudo usermod -a -G lxd user1

Assicuriamoci che l'utente user1 aggiunto al gruppo lxd:

id -Gn user1

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

Se il gruppo lxd non è visibile nell'elenco, è necessario attivare nuovamente la sessione utente. Per fare ciò, è necessario disconnettersi e accedere con lo stesso utente.

Attiva dentro systemd caricamento del servizio LXD all'avvio del sistema:

sudo systemctl enable lxd

Iniziamo il servizio:

sudo systemctl start lxd

Verifica dello stato del servizio:

sudo systemctl status lxd

Stoccaggio LXD (Stoccaggio) ^

Prima che inizi l'inizializzazione, dobbiamo capire come è organizzata logicamente l'archiviazione in LXD.

Magazzinaggio (Archiviazione) consiste di da uno o più Pool di archiviazione che utilizza uno dei file system supportati come ZFS, BTRFS, LVM o directory normali. Ogni Pool di archiviazione è diviso in volumi (Volume di archiviazione) che contengono immagini, contenitori o dati per altri scopi.

  • immagini - si tratta di distribuzioni appositamente assemblate senza kernel Linux e disponibili da fonti esterne
  • contenitori - si tratta di distribuzioni distribuite da immagini, pronte per l'uso
  • Istantanee - queste sono istantanee dello stato dei contenitori a cui puoi tornare

Funzionalità di base dei sistemi contenitore LXD - Linux

Per gestire l'archiviazione in LXD, utilizzare il comando lxc storage un certificato per il quale è possibile ottenere specificando la chiave - lxc storage --help

Il comando seguente visualizza un elenco di tutti Pool di archiviazione nello spazio di archiviazione LXD:

lxc storage list

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

Per visualizzare un elenco di tutti Volume di archiviazione nel selezionato Pool di archiviazione serve la squadra 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       |
+-----------+----------------------------------+-------------+---------+

Inoltre, se per Pool di archiviazione Durante la creazione, è stato selezionato il file system BTRFS, quindi ottieni un elenco Volume di archiviazione o sottovolumi nell'interpretazione BTRFS, puoi utilizzare il toolkit di questo file system:

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

Inizializzazione di LXD ^

Prima di creare e utilizzare i contenitori, è necessario eseguire un'inizializzazione generale di LXD che crei e configuri la rete e l'archiviazione. Questa operazione può essere eseguita manualmente utilizzando i comandi client standard disponibili nell'elenco richiamando il comando lxc --help o utilizzando la procedura guidata di inizializzazione lxd init rispondendo ad alcune domande.

Selezione di un file system per lo storage pool ^

Durante l'inizializzazione, LXD pone diverse domande, inclusa la determinazione del tipo di file system predefinito Pool di archiviazione. Per impostazione predefinita, è selezionato il file system BTRFS. Sarà impossibile passare ad un altro FS dopo la creazione. Si consiglia di selezionare un FS tabella comparativa delle caratteristiche:

caratteristica
elenco
Btrfs
LVM
ZFS
CEPH

Archiviazione immagini ottimizzata
no



Creazione di istanze ottimizzata
no



Creazione di istantanee ottimizzata
no



Trasferimento immagini ottimizzato
no

no

Trasferimento di istanze ottimizzato
no

no

Copia su scrittura
no



Basato su blocchi
no
no

no

Clonazione istantanea
no



Driver di archiviazione utilizzabile all'interno di un contenitore


no
no
no

Ripristino da snapshot precedenti (non più recenti)



no

Quote di archiviazione
SÌ(*)



no

Inizializzazione della rete e dello storage pool tramite la procedura guidata ^

Il prossimo comando che vedremo suggerisce di configurare i componenti principali di LXD rispondendo a semplici domande utilizzando la procedura guidata di inizializzazione.

Esegui comando lxc init e inserisci le risposte alle domande dopo i due punti come mostrato nell'esempio seguente oppure modificale in base alle tue condizioni:

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

Creazione di uno storage pool aggiuntivo ^

Nel passaggio precedente abbiamo creato Pool di archiviazione a cui è stato dato il nome ssdpool e il cui file si trova sul mio sistema all'indirizzo /var/lib/lxd/disks/ssdpool.img. Questo indirizzo del file system corrisponde all'unità SSD fisica del mio PC.

Le seguenti azioni, per ampliare la comprensione del ruolo svolto da Pool di archiviazione nel repository, ne creeremo un secondo Pool di archiviazione che sarà fisicamente posizionato su un diverso tipo di disco, HDD. Il problema è che LXD non ti consente di creare Pool di archiviazione fuori indirizzo /var/lib/lxd/disks/ e anche i collegamenti simbolici non funzioneranno, vedere la risposta dello sviluppatore. Possiamo aggirare questa limitazione durante l'inizializzazione/formattazione Pool di archiviazione specificando il valore come dispositivo a blocchi invece del percorso del file di loopback specificandolo nella chiave source.

Quindi, prima di creare Pool di archiviazione è necessario definire un file di loopback o una partizione esistente sul file system che verrà utilizzato. Per fare ciò, creeremo e utilizzeremo un file la cui dimensione limiteremo a 10 GB:

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

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

Colleghiamo il file di loopback a un dispositivo di loopback libero:

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

/dev/loop1

Grazie alla chiave --show l'esecuzione del comando riporta sullo schermo il nome del dispositivo a cui è connesso il nostro file di loopback. Se necessario, possiamo visualizzare un elenco di tutti i dispositivi di questo tipo occupati per assicurarci che le nostre azioni siano corrette:

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

Dall'elenco puoi scoprire che il dispositivo ha /dev/loop1 file di loopback incluso /mnt/work/lxd/hddpool.imge nel dispositivo /dev/loop0 file di loopback incluso /var/lib/lxd/disks/ssdpool.img che corrisponde al valore predefinito Pool di archiviazione.

Il comando seguente ne crea uno nuovo Pool di archiviazione in LXD in base al file di loopback che abbiamo appena preparato. LXD formatterà il file di loopback /mnt/work/lxd/hddpool.img nel dispositivo /dev/loop1 per il file system BTRFS:

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

Visualizziamo un elenco di tutti Pool di archiviazione sullo schermo:

lxc storage list

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

Aumento della dimensione dello storage pool ^

Dopo la creazione Pool di archiviazione, se necessario, può essere ampliato. Per Pool di archiviazione in base al file system BTRFS, eseguire i seguenti comandi:

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

Inserimento automatico di un file di loopback nello slot del dispositivo di loopback ^

Abbiamo un piccolo problema, quando riavviiamo il sistema host, il file /mnt/work/lxd/hddpool.img "volerà" fuori dal dispositivo /dev/loop1 e il servizio LXD si bloccherà durante il caricamento perché non lo vedrà in questo dispositivo. Per risolvere questo problema è necessario creare un servizio di sistema che inserirà questo file nel dispositivo /dev/loop1 all'avvio del sistema host.

Creiamo unità tipo di file servizio в /etc/systemd/system/ per il sistema di inizializzazione SystemD:

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

Attiva il servizio:

sudo systemctl enable lxd-hddpool

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

Dopo aver riavviato il sistema host, controlliamo lo stato del servizio:

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

Dall'output possiamo verificare che lo stato del servizio sia attivo, nonostante il fatto che l'esecuzione del nostro script da un comando sia stata completata, l'opzione ci ha permesso di farlo RemainAfterExit=true.

Sicurezza. Privilegi del contenitore ^

Poiché tutti i processi contenitore vengono effettivamente eseguiti in isolamento sul sistema host utilizzando il relativo kernel, per proteggere ulteriormente l'accesso dei processi contenitore al sistema host, LXD offre privilegi di processo, dove:

  • Contenitori privilegiati - si tratta di contenitori in cui i processi con UID e GID corrispondono allo stesso proprietario del sistema host. Ad esempio, un processo in esecuzione in un contenitore con un UID pari a 0 ha tutti gli stessi diritti di accesso di un processo sul sistema host con un UID pari a 0. In altre parole, l'utente root nel contenitore ha tutti i diritti non solo in nel contenitore, ma anche sul sistema host se può uscire dallo spazio dei nomi isolato del contenitore.

  • Contenitori non privilegiati - si tratta di contenitori in cui i processi appartengono al proprietario dell'UID e del GID con un numero da 0 a 65535, ma per il sistema host il proprietario viene mascherato utilizzando rispettivamente i bit SubUID e SubGID aggiunti. Ad esempio, un utente con UID=0 in un contenitore verrà visualizzato sul sistema host come SubUID + UID. Ciò protegge il sistema host perché se un processo nel contenitore riesce a sfuggire al suo spazio dei nomi isolato, può comunicare con il sistema host solo come un processo con un UID/GID sconosciuto e molto alto.

Per impostazione predefinita, i contenitori appena creati hanno uno stato non privilegiato e quindi dobbiamo definire un SubUID e un SubGID.

Creiamo due file di configurazione nei quali imposteremo rispettivamente la maschera per SubUID e SubGID:

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

Per applicare le modifiche è necessario riavviare il servizio LXD:

sudo systemctl restart lxd

Creazione di uno switch di rete virtuale ^

Poiché in precedenza abbiamo inizializzato la rete utilizzando la procedura guidata di inizializzazione lxd init e creato un dispositivo di rete lxdbr0, in questa sezione impareremo semplicemente la rete in LXD e come creare uno switch virtuale (bridge) utilizzando il comando client.

Il diagramma seguente mostra come uno switch (bridge) collega l'host e i contenitori a una rete:

Funzionalità di base dei sistemi contenitore LXD - Linux

I contenitori possono comunicare tramite una rete con altri contenitori o con l'host su cui vengono serviti questi contenitori. Per fare ciò è necessario collegare le schede di rete virtuali dei contenitori con uno switch virtuale. Creeremo prima uno switch e le interfacce di rete del contenitore verranno collegate nei capitoli successivi, dopo che il contenitore stesso sarà stato creato.

Il comando seguente crea uno switch con una sottorete 10.0.5.0/24 e indirizzo IPv4 10.0.5.1/24, e include anche ipv4.nat in modo che i contenitori possano accedere a Internet tramite l'host utilizzando il servizio NAT:

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

Controllo dell'elenco dei dispositivi di rete disponibili in LXD:

lxc network list

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

Puoi anche verificare che un dispositivo di rete sia stato creato utilizzando lo strumento standard della distribuzione Linux - ip link o 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

Profilo di configurazione ^

Ogni contenitore in LXD ha la propria configurazione e può estenderla con configurazioni dichiarate globalmente chiamate profili di configurazione. L'applicazione dei profili di configurazione a un contenitore ha un modello a cascata, l'esempio seguente lo dimostra:

Funzionalità di base dei sistemi contenitore LXD - Linux

In questo esempio, nel sistema LXD sono stati creati tre profili: default, hddpool и hostfs. Tutti e tre i profili vengono applicati a un contenitore che ha una configurazione locale (area grigia). Profilo default ha un dispositivo root che ha un parametro pool è uguale a ssdpool, ma grazie al modello applicativo di configurazione in cascata, possiamo applicare un profilo al contenitore hddpool che ha un parametro pool sovrascriverà lo stesso parametro dal profilo default e il contenitore riceverà la configurazione del dispositivo root con parametro pool pari hddpoole il profilo hostfs aggiunge semplicemente un nuovo dispositivo al contenitore.

Per visualizzare l'elenco dei profili di configurazione disponibili, utilizzare il seguente comando:

lxc profile list

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

Un elenco completo dei comandi disponibili per lavorare con un profilo può essere ottenuto aggiungendo la chiave --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

Modificare il tuo profilo ^

Profilo di configurazione predefinito default non ha una configurazione della scheda di rete per il contenitore e tutti i contenitori appena creati non hanno una rete, per loro è necessario creare dispositivi di rete locali (dedicati) con un comando separato, ma possiamo creare un dispositivo di rete globale nella configurazione profilo che sarà condiviso tra tutti i contenitori che utilizzano questo profilo. In questo modo, subito dopo il comando di creazione di un nuovo contenitore, avranno una rete con accesso alla rete. Allo stesso tempo non ci sono restrizioni: possiamo sempre creare un dispositivo di rete locale in un secondo momento, se necessario.

Il comando seguente aggiungerà il dispositivo al profilo di configurazione eth0 типа nic connesso alla rete lxdbr0:

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

È importante notare che, poiché abbiamo effettivamente aggiunto il dispositivo al profilo di configurazione, se abbiamo specificato un indirizzo IP statico nel dispositivo, tutti i contenitori che utilizzeranno questo profilo condivideranno lo stesso indirizzo IP. Se è necessario creare un contenitore con un indirizzo IP statico allocato per il contenitore, è necessario creare una configurazione del dispositivo di rete a livello di contenitore (configurazione locale) con il parametro dell'indirizzo IP e non a livello di profilo.

Controlliamo il profilo:

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 questo profilo possiamo vedere che per tutti i contenitori appena creati verranno creati due dispositivi:

  • eth0 - Tipo di dispositivo nic collegato a uno switch (bridge di rete) lxdbr0
  • root - Tipo di dispositivo disk che utilizza un pool di archiviazione ssdpool

Creazione di nuovi profili ^

Da utilizzare creato in precedenza Pool di archiviazione contenitori, creare un profilo di configurazione ssdroot in cui aggiungeremo un dispositivo come disk con punto di montaggio / (root) utilizzando il file creato in precedenza Pool di archiviazione - ssdpool:

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

Allo stesso modo, creiamo un dispositivo come disk, ma in questo caso utilizzando Pool di archiviazione - hddpool:

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

Controllo dei profili di configurazione:

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

Deposito di immagini ^

I contenitori vengono creati da immagini che sono distribuzioni appositamente assemblate che non dispongono di un kernel Linux. Pertanto, prima di eseguire il contenitore, è necessario distribuirlo da questa immagine. L'origine delle immagini è un repository locale in cui le immagini vengono scaricate da repository esterni.

Repository di immagini remote ^

Per impostazione predefinita, LXD è configurato per ricevere immagini da tre fonti remote:

  • Ubuntu: (per immagini Ubuntu stabili)
  • ubuntu-quotidiano: (per le immagini Ubuntu giornaliere)
  • immagini: (per un sacco di altre distribuzioni)

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

Ad esempio, deposito ubuntu: ha le seguenti immagini:

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

Per visualizzare un numero limitato di colonne abbiamo utilizzato l'opzione -c con parametri dasute ha anche limitato la lunghezza dell'elenco con il comando head.

È disponibile il filtraggio per visualizzare un elenco di immagini. Il comando seguente elencherà tutte le architetture di distribuzione disponibili Alpine Linux:

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

Repository di immagini locale ^

Per iniziare a utilizzare il contenitore, è necessario aggiungere un'immagine dal repository globale a quello locale local:. Ora il repository locale è vuoto, il comando se ne assicurerà lxc image list. Se il metodo list non specificare un repository, per impostazione predefinita verrà utilizzato il repository locale - local:

lxc image list local:

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

Le immagini nel repository vengono gestite utilizzando i seguenti metodi:

Squadra
descrizione

immagine lxc alias
Gestisci gli alias delle immagini

immagine lxc copia
Copia immagini tra server

immagine lxc delete
Elimina immagini

immagine lxc edit
Modifica le proprietà dell'immagine

immagine lxc export
Esporta e scarica immagini

immagine lxc importare
Importa immagini nell'archivio immagini

immagine lxc info
Mostra informazioni utili sulle immagini

immagine lxc stratagemma
Elenco immagini

immagine lxc rinfrescare
Aggiorna le immagini

immagine lxc mostrare attraverso le sue creazioni
Mostra le proprietà dell'immagine

Copia l'immagine nel repository locale da quello globale images::

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

Image copied successfully!

Visualizziamo un elenco di tutte le immagini attualmente disponibili nel repository locale local::

lxc image -c lfdatsu list local:

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

Configurazione LXD ^

Oltre alla modalità interattiva, LXD supporta anche una modalità di installazione della configurazione non interattiva, ovvero quando la configurazione viene specificata sotto forma di file YAML, un formato speciale che consente di installare l'intera configurazione in una sola volta, bypassando l'esecuzione di molti comandi interattivi discussi in precedenza in questo articolo, inclusa la configurazione di rete, la creazione di profili di configurazione, ecc. Non copriremo quest'area qui, puoi verificarla da solo. nella documentazione.

Comando interattivo successivo lxc config che vedremo permette di impostare la configurazione. Ad esempio, per garantire che le immagini scaricate nel repository locale non vengano aggiornate automaticamente dai repository globali, possiamo abilitare questo comportamento con il seguente comando:

lxc config set images.auto_update_cached=false

Creazione e gestione di un contenitore ^

Per creare un contenitore utilizzare il comando lxc init a cui vengono passati i valori репозиторий:образ e quindi l'ID desiderato per il contenitore. Il repository può essere specificato come locale local: così è qualsiasi globale. Se il repository non è specificato, per impostazione predefinita viene utilizzato il repository locale per cercare l'immagine. Se l'immagine viene specificata dal repository globale, l'immagine verrà prima scaricata nel repository locale e quindi utilizzata per creare il contenitore.

Eseguiamo il comando seguente per creare il nostro primo contenitore:

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

Diamo un'occhiata ai tasti di comando che usiamo qui in ordine:

  • alpine3 — Viene specificato un alias (alias) per l'immagine precedentemente caricata nel repository locale. Se l'alias non è stato creato per questa immagine, puoi sempre fare riferimento all'immagine tramite il suo Fingerprint che viene visualizzato nella tabella.
  • alp — Imposta l'identificatore per il contenitore
  • --storage — Questa chiave indica in quale Pool di archiviazione verrà creato un contenitore
  • --profile — Queste chiavi applicano a cascata la configurazione dai profili di configurazione creati in precedenza al contenitore

Lanciamo il contenitore, che inizia a lanciare il sistema init della distribuzione:

lxc start alp

Puoi anche usare il comando lxc launch che ti consente di unire le squadre lxc init и lxc start in una sola operazione.

Controllo dello stato del contenitore:

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

Verifica della configurazione del contenitore:

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

Nella sezione profiles possiamo assicurarci che questo contenitore utilizzi due profili di configurazione − default и hddroot. Nella sezione devices possiamo rilevare solo un dispositivo perché il dispositivo di rete è stato creato a livello di profilo default. Per vedere tutti i dispositivi utilizzati dal contenitore è necessario aggiungere una chiave --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: ""

Impostazione di un indirizzo IP statico ^

Se proviamo a impostare un indirizzo IP per un dispositivo di rete eth0 Il gruppo lxc config device set alp destinato alla configurazione del contenitore, riceveremo un errore che segnalerà che il dispositivo non esiste perché il file device eth0 utilizzato dal contenitore appartiene al profilo default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Ovviamente possiamo impostare un indirizzo IP statico per eth0 dispositivi nel profilo, ma sarà lo stesso per tutti i contenitori che utilizzeranno questo profilo. Aggiungiamo quindi un dispositivo dedicato al contenitore:

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

Quindi è necessario riavviare il contenitore:

lxc restart alp

Se esaminiamo ora la configurazione del contenitore, non è necessario utilizzare l'opzione --expanded per vedere il dispositivo di rete eth0, poiché l'abbiamo creato a livello di contenitore ed è stato distribuito a cascata sullo stesso dispositivo dal profilo 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: ""

Rimozione di un contenitore ^

Per rimuovere un contenitore, utilizzare il comando lxc delete, ma prima di rimuovere il contenitore è necessario fermarlo utilizzando il comando lxc stop:

lxc stop alp

lxc list

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

Dopo aver verificato che lo stato del contenitore sia diventato FERMATO, può essere rimosso da Pool di archiviazione:

lxc delete alp

Accesso al contenitore ^

Per eseguire comandi direttamente in un contenitore, ignorando le connessioni di rete, utilizzare il comando lxc exec che esegue comandi nel contenitore senza avviare la shell di sistema. Se è necessario eseguire un comando in una shell utilizzando modelli di shell come variabili, reindirizzamenti di file (pipe), ecc., è necessario avviare esplicitamente la shell e passare il comando come chiave, ad esempio:

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

Il comando utilizzava uno speciale carattere di escape per carattere speciale $ in modo che la variabile $HOME non è stato interpretato sul computer host, ma è stato interpretato solo all'interno del contenitore.

È anche possibile avviare la modalità shell interattiva e quindi terminare la sessione eseguendo il tasto di scelta rapida CTRL+D:

lxc exec alp -- /bin/sh

Gestione delle risorse del contenitore ^

In LXD, puoi gestire le risorse del contenitore utilizzando un set speciale di configurazione. È possibile trovare un elenco completo dei parametri di configurazione del contenitore nella documentazione.

Limitazione delle risorse RAM ^

Parametro limits.memory limita la quantità di RAM disponibile per il contenitore. Il valore è un numero e uno di suffissi disponibili.

Impostiamo il limite RAM del contenitore su 256 MB:

lxc config set alp limits.memory 256MB

Inoltre, ci sono altri parametri per limitare la memoria:

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

Squadra lxc config show consente di visualizzare l'intera configurazione del contenitore, incluso il limite di risorse applicato che è stato impostato:

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

Limite delle risorse della CPU ^

Esistono diversi modi per limitare le risorse della CPU. tipi di restrizioni:

  • limit.cpu - lega un contenitore a uno o più core della CPU
  • limits.cpu.allowance - gestisce le quote dello scheduler CFS quando è trascorso il limite di tempo o il meccanismo universale di condivisione delle risorse della CPU quando la percentuale è passata
  • limits.cpu.priority - priorità dello scheduler quando a più istanze che condividono un set di processori viene assegnata la stessa percentuale di processori

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

Limitazione dello spazio su disco ^

Oltre a restrizioni come limits.read, limits.write possiamo anche limitare la quantità di spazio su disco consumato dal contenitore (funziona solo con ZFS o BTRFS):

lxc config device set alp root size=2GB

Dopo l'installazione, nel parametro devices.root.size Possiamo verificare il limite impostato:

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

Per visualizzare le quote del disco utilizzato possiamo ottenere dal comando 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

Nonostante abbiamo impostato un limite per il dispositivo root del contenitore a 2 GB, utilità di sistema come df non vedrà questa restrizione. Per fare ciò, effettueremo un piccolo test e scopriremo come funziona.

Creiamo 2 nuovi contenitori identici nello stesso Pool di archiviazione (pool hd):

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

Creiamo un file da 1 GB in uno dei contenitori:

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

Assicuriamoci che il file sia creato:

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

Se guardiamo nel secondo contenitore, controlliamo l'esistenza di un file nella stessa posizione, allora questo file non sarà lì, cosa prevista, poiché i contenitori vengono creati da soli Volume di archiviazione nello stesso Pool di archiviazione:

lxc exec alp2 -- ls -lh
total 0

Ma confrontiamo i valori che produce df sull'uno e sull'altro contenitore:

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

Dispositivo /dev/loop1 montata come lo è la partizione root Pool di archiviazione che utilizzano questi contenitori, quindi condividono il volume tra due.

Statistiche sul consumo delle risorse ^

Puoi visualizzare le statistiche sul consumo di risorse per un contenitore utilizzando il comando:

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

Lavorare con le istantanee ^

LXD ha la capacità di creare istantanee e ripristinare da esse lo stato del contenitore.

Per creare uno snapshot, esegui il comando seguente:

lxc snapshot alp snapshot1

Il gruppo lxc snapshot nessuna chiave disponibile list, pertanto, per visualizzare l'elenco degli snapshot è necessario utilizzare il comando che visualizza informazioni generali sul contenitore:

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

È possibile ripristinare un contenitore da uno snapshot utilizzando il comando lxc restore specificando il contenitore per il quale verrà eseguito il ripristino e l'alias dello snapshot:

lxc restore alp snapshot1

Il comando seguente viene utilizzato per eliminare uno snapshot. Tieni presente che la sintassi del comando non è simile a tutte le altre; qui è necessario specificare una barra dopo il nome del contenitore. Se la barra viene omessa, il comando per eliminare uno snapshot viene interpretato come un comando per eliminare un contenitore!

lxc delete alp/snapshot1

Nell'esempio sopra abbiamo esaminato le cosiddette istantanee senza stato. LXD ha un altro tipo di snapshot: stateful, che salva lo stato corrente di tutti i processi nel contenitore. Esistono numerose funzionalità interessanti e utili associate agli snapshot con stato.

Cos'altro? ^

  • È disponibile un modulo per gli sviluppatori Python PyLXD che fornisce un'API a LXD

AGGIORNAMENTO 10.04.2020/15/00 XNUMX:XNUMX: Aggiunta la navigazione

Fonte: habr.com

Aggiungi un commento