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:
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:
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
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
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.
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
sì
sì
sì
sì
Creazione di istanze ottimizzata
no
sì
sì
sì
sì
Creazione di istantanee ottimizzata
no
sì
sì
sì
sì
Trasferimento immagini ottimizzato
no
sì
no
sì
sì
Trasferimento di istanze ottimizzato
no
sì
no
sì
sì
Copia su scrittura
no
sì
sì
sì
sì
Basato su blocchi
no
no
sì
no
sì
Clonazione istantanea
no
sì
sì
sì
sì
Driver di archiviazione utilizzabile all'interno di un contenitore
sì
sì
no
no
no
Ripristino da snapshot precedenti (non più recenti)
sì
sì
sì
no
sì
Quote di archiviazione
SÌ(*)
sì
sì
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]:
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:
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:
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:
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:
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.
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:
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:
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:
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:
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
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
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:
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.
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:
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
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:
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 |
+------+---------+------------------+------+-----------+--------------+
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:
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:
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:
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:
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.
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:
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
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 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.
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.