LXD — est un gestionnaire de conteneurs de nouvelle génération, c'est ce que dit source. Il offre une interface utilisateur semblable à celle des machines virtuelles, mais utilisant plutôt des conteneurs Linux.

Le noyau LXD — est un démon privilégié (service exécuté avec les droits root) qui fournit une API REST via un socket unix local, ainsi qu'à travers le réseau, si la configuration appropriée est installée. Les clients, tels que l'outil en ligne de commande fourni avec LXD, envoient des requêtes via cette API REST. Cela signifie que peu importe que vous vous connectiez à un hôte local ou distant, tout fonctionne de la même manière.

Dans cet article, nous ne nous attarderons pas sur les concepts de LXD, ni ne passerons en revue toutes les fonctionnalités disponibles exposées dans la documentation, y compris la récente mise en œuvre dans les dernières versions de LXD apportant le support des machines virtuelles QEMU parallèlement aux conteneurs. Au lieu de cela, nous allons simplement découvrir les fonctionnalités de base de gestion des conteneurs — configurer des pools de stockage, un réseau, lancer un conteneur, appliquer des limites de ressources, et voir comment utiliser des snapshots, afin que vous puissiez avoir une compréhension de base de LXD et utiliser des conteneurs sous Linux.

Pour des informations complètes, veuillez consulter la source officielle :

• Site du développeur
• Documentation
• Forum

Navigation

• Installation de LXD
  • Installation de LXD sur les distributions Ubuntu
  • Installation de LXD sur les distributions Arch Linux
• Stockage LXD (Storage)
• Initialisation de LXD
  • Choix du système de fichiers pour le Storage Pool
  • Initialisation du réseau et du Storage Pool à l'aide de l'assistant
  • Création d'un Storage Pool supplémentaire
    • Augmenter la taille du Storage Pool
    • Insertion automatique d'un fichier loopback dans le slot du périphérique loopback
  • Sécurité. Privilèges des conteneurs
  • Création d'un commutateur virtuel de réseau
  • Profil de configuration
    • Édition du profil
    • Création de nouveaux profils
  • Dépôt d'images
    • Dépôts d'images distants
    • Dépôt local d'images
  • Configuration de LXD
• Création et gestion des conteneurs
  • Configuration d'une adresse IP statique
  • Suppression du conteneur
  • Accès au conteneur
  • Gestion des ressources du conteneur
    • Limitation des ressources RAM
    • Limitation des ressources CPU
    • Limitation de l'espace disque
    • Statistiques de consommation des ressources
  • Travail avec des snapshots

Installation de LXD ^

Installation de LXD sur les distributions Ubuntu ^

Dans la distribution Ubuntu 19.10, le paquet lxd a une traduction en Multipass extrait automatiquement l'image nécessaire du système d'exploitation et la maintient à jour. Pour la configuration, cloud-init peut être appliqué. Il est possible de monter des partitions externes dans l'environnement virtuel (commande multipass mount), mais des outils sont également fournis pour transférer des fichiers individuels entre le système hôte et la machine virtuelle (multipass transfer). Le répertoire personnel de l'utilisateur est automatiquement monté dans la machine virtuelle en tant que ~/Home. Une intégration complète de la machine virtuelle installée avec le bureau principal est soutenue (des icônes d'applications, un menu système et des notifications sont ajoutés).:

apt search lxd

lxd/eoan 1:0.7 all
  Paquet de transition - lxd -> snap (lxd)

Cela signifie que deux paquets seront installés, un paquet système et un autre en tant que paquet snap. L'installation de deux paquets dans le système peut créer un problème, où le paquet système pourrait devenir orphelin si le paquet snap est supprimé par le gestionnaire de paquets snap.

Trouver un paquet lxd dans le dépôt snap avec la commande suivante :

snap find lxd

Nom                      Version         Résumé
lxd                       3.21            Gestionnaire de conteneurs système et API
lxd-demo-server           0+git.6d54658   Sessions de démonstration de logiciels en ligne utilisant LXD
nova                      ocata           Service de calcul OpenStack (nova)
nova-hypervisor           ocata           Service de calcul OpenStack - Hyperviseur KVM (nova)
distrobuilder             1.0             Générateur d'images pour LXC et LXD
fabrica                   0.1             Créez des snaps en pointant simplement un formulaire web vers...
satellite                 0.1.2           Plateforme d'intelligence open source avancée et évolutive

En exécutant la commande list vous pouvez vous assurer que le paquet lxd n'est pas encore installé :

snap list

Nom     Version     Rev    Tracking    Éditeur       Notes
core    16-2.43.3   8689   stable      canonical✓    core

Bien que LXD soit un paquet snap, il doit être installé via le paquet système lxd, qui créera dans le système le groupe approprié, les utilitaires nécessaires dans /usr/bin etc.

sudo apt update
sudo apt install lxd

Vérifions que le paquet est installé en tant que paquet snap :

snap list

Nom     Version     Rev     Tracking    Éditeur       Notes
core    16-2.43.3   8689    stable      canonical✓    core
lxd     3.21        13474   stable/...  canonical✓    -

Installation de LXD sur les distributions Arch Linux ^

Pour installer le paquet LXD dans le système, il est nécessaire d'exécuter les commandes suivantes, la première met à jour la liste des paquets disponibles dans le dépôt, la seconde installera directement le paquet :

sudo pacman -Syyu && sudo pacman -S lxd

Après l'installation du paquet, pour gérer LXD en tant qu'utilisateur normal, il faut l'ajouter au groupe système lxd:

sudo usermod -a -G lxd user1

Vérifions que l'utilisateur user1 a été ajouté au groupe lxd:

id -Gn user1

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

Si le groupe lxd n'est pas visible dans la liste, alors il faut réactiver la session de l'utilisateur. Pour cela, déconnectez-vous et reconnectez-vous sous ce même utilisateur.

Activer le service LXD au démarrage du système : systemd sudo systemctl enable lxd

Démarrons le service :

sudo systemctl start lxd

Vérifions l'état du service :

sudo systemctl status lxd

Avant de commencer l'initialisation, nous devons comprendre comment le stockage est logiquement organisé dans LXD.

Stockage LXD (Storage) ^

Le stockage (

se composeStockage) d'une ou plusieurs piscines de stockage Storage Pool qui utilise l'un des systèmes de fichiers pris en charge comme ZFS, BTRFS, LVM ou des répertoires ordinaires. Chaque Storage Pool est divisé en volumes (Storage Volume) qui contiennent des images, des conteneurs ou des données à d'autres fins.

• Images — ce sont des distributions spécialement assemblées sans noyau Linux et disponibles à partir de sources externes
• Conteneurs — ce sont des distributions déployées à partir d'images, prêtes à l'emploi
• Snapshots — ce sont des instantanés de l'état des conteneurs vers lesquels on peut revenir

Pour gérer le stockage dans LXD, la commande est lxc storage dont on peut obtenir de l'aide en spécifiant la clé — lxc storage --help

La commande suivante affiche la liste de tous Storage Pool dans LXD stockages :

lxc storage list

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

Pour afficher la liste de tous Storage Volume dans le stockage sélectionné Storage Pool la commande est 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       |
+-----------+----------------------------------+-------------+---------+

Aussi, si pour Storage Pool à la création, le système de fichiers BTRFS a été choisi, on peut obtenir la liste des Storage Volume ou subvolumes dans l'interprétation de BTRFS à l'aide des outils de ce système de fichiers :

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

Initialisation de LXD ^

Avant de créer et d'utiliser des conteneurs, il est nécessaire d'exécuter une initialisation générale de LXD qui crée et configure le réseau ainsi que le stockage. Cela peut être fait manuellement à l'aide des commandes standard du client disponibles dans la liste en appelant la commande lxc --help ou à l'aide de l'assistant d'initialisation lxd init en répondant à quelques questions.

Choix du système de fichiers pour le Storage Pool ^

Lors de l'initialisation, LXD pose plusieurs questions, dont la définition du type de système de fichiers par défaut. Storage PoolPar défaut, le système de fichiers BTRFS est sélectionné. Il sera impossible de changer pour un autre système de fichiers après la création.Pour choisir le système de fichiers, une table de comparaison des fonctionnalités:

Fonctionnalité
Répertoire
, y compris la capacité de démarrer à partir d'une partition Btrfs.
LVM
ZFS
CEPH

Stockage d'image optimisé
non
yes
yes
yes
yes

Création d'instance optimisée
non
yes
yes
yes
yes

Création de snapshot optimisée
non
yes
yes
yes
yes

Transfert d'image optimisé
non
yes
non
yes
yes

Transfert d'instance optimisé
non
yes
non
yes
yes

Copie sur écriture
non
yes
yes
yes
yes

Basée sur les blocs
non
non
yes
non
yes

Clonage instantané
non
yes
yes
yes
yes

Pilote de stockage utilisable dans un conteneur
yes
yes
non
non
non

Restauration de snapshots plus anciens (pas le plus récent)
yes
yes
yes
non
yes

Quotas de stockage
oui(*)
yes
yes
yes
non

Initialisation du réseau et du Storage Pool à l'aide de l'assistant ^

La prochaine commande que nous allons examiner permet de configurer les principaux composants de LXD en répondant à des questions simples via un assistant d'initialisation.

Exécutez la commande lxc init et entrez les réponses aux questions après les deux points comme indiqué dans l'exemple ci-dessous ou modifiez-les selon vos conditions :

lxd init

Souhaitez-vous utiliser le clustering LXD ? (oui/non) [par défaut=non] : 
Voulez-vous configurer un nouveau pool de stockage ? (oui/non) [par défaut=oui] : 
Nom du nouveau pool de stockage [par défaut=default] : ssdpool         
Nom du backend de stockage à utiliser (lvm, btrfs, dir) [par défaut=btrfs] : 
Créer un nouveau pool BTRFS ? (oui/non) [par défaut=oui] : 
Souhaitez-vous utiliser un dispositif de bloc existant ? (oui/non) [par défaut=non] : 
Taille en Go du nouveau dispositif loop (1 Go minimum) [par défaut=15 Go] : 10 Go
Souhaitez-vous vous connecter à un serveur MAAS ? (oui/non) [par défaut=non] : 
Souhaitez-vous créer un nouveau pont réseau local ? (oui/non) [par défaut=oui] : 
Quel doit être le nom du nouveau pont ? [par défaut=lxdbr0] : 
Quelle adresse IPv4 doit être utilisée ? (notation CIDR, “auto” ou “aucun”) [par défaut=auto] : 10.0.5.1/24
Souhaitez-vous que LXD NAT le trafic IPv4 sur votre pont ? [par défaut=oui] : 
Quelle adresse IPv6 doit être utilisée ? (notation CIDR, “auto” ou “aucun”) [par défaut=auto] : aucun
Souhaitez-vous que LXD soit disponible sur le réseau ? (oui/non) [par défaut=non] : 
Souhaitez-vous que les images mises en cache obsolètes soient mises à jour automatiquement ? (oui/non) [par défaut=oui] non
Voulez-vous qu'un préseed YAML "lxd init" soit imprimé ? (oui/non) [par défaut=non] : 

Création d'un Storage Pool supplémentaire ^

Lors de l'étape précédente, nous avons créé Storage Pool que nous avons nommé ssdpool et dont le fichier se trouve sur mon système à l'adresse /var/lib/lxd/disks/ssdpool.img. Cette adresse système de fichiers correspond au disque SSD physique dans mon PC.

Dans les prochaines étapes, pour mieux comprendre le rôle que joue Storage Pool dans le stockage, nous allons créer un second Storage Pool qui sera physiquement situé sur un autre type de disque, un HDD. Le problème est que LXD ne permet pas de créer Storage Pool en dehors de l'adresse /var/lib/lxd/disks/ et même les liens symboliques ne fonctionneront pas, voir la réponse du développeur. Nous pouvons contourner cette restriction lors de l'initialisation/formatage en spécifiant la valeur comme un dispositif de bloc au lieu du chemin d'accès au fichier loopback dans la clé Storage Pool Alors, avant de créer source.

Ainsi, avant de créer Storage Pool Il est nécessaire de définir un fichier loopback ou une partition existante dans votre système de fichiers qu'il utilisera. Pour ce faire, nous allons créer et utiliser un fichier que nous limiterons à une taille de 10 Go :

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

10000+0 enregistrements lus
10000+0 enregistrements écrits
10000000000 octets (10 Go, 9,3 GiB) copiés, 38,4414 s, 260 Mo/s

Connectons le fichier loopback à un périphérique loopback libre :

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

/dev/loop1

Grâce à l'option --show , l'exécution de la commande renvoie à l'écran le nom du périphérique auquel notre fichier loopback est connecté. Si nécessaire, nous pouvons afficher la liste de tous les périphériques occupés de ce type, afin de nous assurer de l'exactitude de nos actions :

losetup -l

NOM       SIZELIMIT OFFSET AUTOCLEAR RO FICHIER-ARRIÈRE                  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

Dans la liste, on peut constater que le fichier loopback est connecté au périphérique /dev/loop1 , et sur le périphérique /mnt/work/lxd/hddpool.imgqui correspond à la valeur par défaut /dev/loop0 , et sur le périphérique /var/lib/lxd/disks/ssdpool.img La commande suivante crée un nouveau Storage Pool.

dans LXD basé sur le fichier loopback juste préparé. LXD va formater le fichier loopback Storage Pool dans le périphérique /mnt/work/lxd/hddpool.img avec le système de fichiers BTRFS : /dev/loop1 lxc storage create hddpool btrfs size=10GB source=/dev/loop1

Affichons la liste de tous les

à l'écran : Storage Pool lxc storage list+---------+-------------+--------+--------------------------------+---------+ | NOM | DESCRIPTION | PILOTE | SOURCE | UTILISÉ PAR | +---------+-------------+--------+--------------------------------+---------+ | hddpool | | btrfs | /dev/loop1 | 0 | +---------+-------------+--------+--------------------------------+---------+ | ssdpool | | btrfs | /var/lib/lxd/disks/ssdpool.img | 0 | +---------+-------------+--------+--------------------------------+---------+

Après la création

Augmenter la taille du Storage Pool ^

, si nécessaire, il peut être agrandi. Pour Storage Poolbasé sur le système de fichiers BTRFS, exécutez les commandes suivantes : Storage Pool 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

Nous avons un petit problème, lors du redémarrage du système hôte, le fichier

Insertion automatique d'un fichier loopback dans le slot du périphérique loopback ^

"sortira" du périphérique /mnt/work/lxd/hddpool.img et le service LXD échouera au démarrage car il ne le verra pas dans ce périphérique. Pour résoudre ce problème, il faut créer un service système qui insérera ce fichier dans le périphérique /dev/loop1 lors du démarrage du système hôte. /dev/loop1 fichier de type

Créons unit pour le système d'initialisation SystemD : service dans /etc/systemd/system/ cat << EOF | sudo tee -a /etc/systemd/system/lxd-hddpool.service [Unit] Description=Losetup LXD Storage Pool (hddpool) After=local-fs.target[Service] Type=oneshot ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img RemainAfterExit=true[Install] WantedBy=local-fs.target EOF

Nous activons le service :

Nous activons le service :

sudo systemctl enable lxd-hddpool

Création d'un lien symbolique vers /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

Après le redémarrage du système hôte, vérifions l'état du service :

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Chargé : chargé (/etc/systemd/system/lxd-hddpool.service; activé; modèle du fournisseur : désactivé)
     Actif : actif (sorti) depuis le Wed 2020-04-08 03:43:53 MSK; il y a 1 min 37 s
    Processus : 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (code=sorti, état=0/SUCCÈS)
   PID principal : 711 (code=sorti, état=0/SUCCÈS)

avr 08 03:43:52 manjaro systemd[1] : Démarrage de Losetup LXD Storage Pool (hddpool)...
avr 08 03:43:53 manjaro systemd[1] : Fin de Losetup LXD Storage Pool (hddpool).

À partir de la sortie, nous pouvons confirmer que l'état du service est égal à active, bien que l'exécution de notre script d'une seule commande soit terminée, cela nous a été permis grâce à l'option RemainAfterExit=true.

Sécurité. Privilèges des conteneurs ^

Étant donné que tous les processus du conteneur s'exécutent effectivement en isolation sur le système hôte en utilisant son noyau, LXD propose une privilège des processus pour une protection supplémentaire de l'accès des processus du conteneur au système hôte, où :

• Conteneurs privilégiés — ce sont des conteneurs dans lesquels les processus avec UID et GID correspondent au même propriétaire que sur le système hôte. Par exemple, un processus exécuté dans un conteneur avec un UID égal à 0 a tous les mêmes droits d'accès que le processus du système hôte avec un UID égal à 0. En d'autres termes, l'utilisateur root dans le conteneur a tous les droits non seulement dans le conteneur, mais aussi sur le système hôte s'il peut sortir de l'espace de noms isolé du conteneur.

• Conteneurs non privilégiés — ce sont des conteneurs dans lesquels les processus appartiennent à un propriétaire UID et GID compris entre 0 et 65535, mais pour le système hôte, le propriétaire est masqué à l'aide du bit SubUID et SubGID respectivement. Par exemple, un utilisateur avec UID=0 dans le conteneur sera vu dans le système hôte comme SubUID + UID. Cela protège le système hôte, car si un processus dans le conteneur peut sortir de son espace de noms isolé, il peut interagir avec le système hôte uniquement en tant que processus avec un UID/GID très élevé et inconnu.

Par défaut, les nouveaux conteneurs sont non privilégiés et nous devons donc définir SubUID et SubGID.

Créons deux fichiers de configuration dans lesquels nous définirons le masque pour SubUID et SubGID respectivement :

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

Pour appliquer les modifications, le service LXD doit être redémarré :

sudo systemctl restart lxd

Création d'un commutateur virtuel de réseau ^

Puisque nous avons précédemment initialisé le réseau à l'aide de l'assistant d'initialisation lxd init et créé un périphérique réseau lxdbr0, dans cette section, nous allons simplement nous familiariser avec le réseau LXD et comment créer un commutateur virtuel (bridge) à l'aide de la commande du client.

Le schéma suivant montre comment le commutateur (bridge) relie l'hôte et les conteneurs au réseau :

Les conteneurs peuvent interagir via le réseau avec d'autres conteneurs ou l'hôte sur lequel ces conteneurs sont hébergés. Pour cela, il est nécessaire de connecter les cartes réseau virtuelles des conteneurs au commutateur virtuel. Commençons par créer le commutateur, et les interfaces réseau du conteneur seront connectées dans les chapitres suivants, après que le conteneur lui-même a été créé.

La commande suivante crée un commutateur avec un sous-réseau 10.0.5.0/24 et une adresse IPv4 10.0.5.1/24, et active ipv4.nat pour que les conteneurs puissent accéder à Internet via l'hôte en utilisant le service NAT :

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

Vérifions la liste des périphériques réseau disponibles dans LXD :

lxc network list

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

De plus, vous pouvez vérifier la création du périphérique réseau avec un outil standard de la distribution Linux — ip link ou ip addr:

ip addr

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

Profil de configuration ^

Chaque conteneur dans LXD a sa propre configuration et peut l'étendre grâce à des configurations globalement déclarées appelées profils de configuration. L'application des profils de configuration à un conteneur suit un modèle en cascade, l'exemple suivant le démontre :

Dans cet exemple, trois profils sont créés dans le système LXD : default, hddpool et hostfs. Les trois profils sont appliqués à un conteneur qui possède une configuration locale (zone grise). Le profil default dispose d'un dispositif root qui a le paramètre pool est égal à ssdpool, mais grâce au modèle en cascade d'application de la configuration, nous pouvons appliquer pour le conteneur un profil hddpool qui a le paramètre pool qui va écraser ce même paramètre du profil default et le conteneur obtiendra la configuration du dispositif root avec le paramètre pool égale à hddpool, tandis que le profil hostfs ajoute simplement un nouveau dispositif au conteneur.

Pour voir la liste des profils de configuration disponibles, utilisez la commande suivante :

lxc profile list

+---------+---------+
|  NOM   | UTILISÉ PAR |
+---------+---------+
| default | 1       |
+---------+---------+
| hddroot | 0       |
+---------+---------+
| ssdroot | 1       |
+---------+---------+

La liste complète des commandes disponibles pour travailler avec les profils peut être obtenue en ajoutant l'option --help:

lxc profile --help

Description :
  Gérer les profils

Utilisation :
  lxc profile [commande]

Commandes disponibles :
  add         Ajouter des profils aux instances
  assign      Attribuer des ensembles de profils aux instances
  copy        Copier des profils
  create      Créer des profils
  delete      Supprimer des profils
  device      Gérer les dispositifs d'instance
  edit        Modifier les configurations de profil en YAML
  get         Obtenir des valeurs pour les clés de configuration du profil
  list        Lister les profils
  remove      Retirer des profils des instances
  rename      Renommer des profils
  set         Définir des clés de configuration de profil
  show        Afficher les configurations de profil
  unset       Annuler les clés de configuration de profil

Édition du profil ^

Le profil de configuration par défaut default n'a pas de configuration de carte réseau pour le conteneur et tous les nouveaux conteneurs créés n'ont pas de réseau, des dispositifs réseau locaux (dédiés) doivent être créés avec une commande distincte, mais nous pouvons créer dans le profil de configuration un dispositif réseau global qui sera partagé entre tous les conteneurs utilisant ce profil. Ainsi, immédiatement après la commande de création d'un nouveau conteneur, ils auront un réseau avec accès à Internet. De plus, il n'y a pas de restrictions, nous pouvons toujours créer ultérieurement un dispositif réseau local si nécessaire.

La commande suivante ajoutera un dispositif au profil de configuration eth0 de type nic connecté au réseau lxdbr0:

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

Il est important de noter que puisque nous avons effectivement ajouté un appareil au profil de configuration, si nous avions spécifié une adresse IP statique pour l'appareil, tous les conteneurs qui appliqueraient ce profil partageraient la même adresse IP. S'il est nécessaire de créer un conteneur avec une adresse IP statique dédiée, alors il faut créer une configuration d'appareil réseau au niveau du conteneur (configuration locale) avec le paramètre d'adresse IP, et non au niveau du profil.

Vérifions le profil :

lxc profile show default

config: {}
description: Profil LXD par défaut
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: \/
    pool: ssdpool
    type: disk
name: default
used_by: []

Dans ce profil, nous pouvons voir que deux appareils (devices) seront créés pour tous les conteneurs nouvellement créés :

• eth0 — Type de dispositif nic connecté à un commutateur (pont réseau) lxdbr0
• root — Type de dispositif disk qui utilise le pool de stockage ssdpool

Création de nouveaux profils ^

Pour utiliser les précédemment créés Storage Pool conteneurs, créons un profil de configuration ssdroot dans lequel nous ajouterons un appareil de type disk avec un point de montage / (root) utilisant l'ancien Storage Pool — ssdpool:

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

De même, nous créons un dispositif de type disk, mais dans ce cas, utilisant Storage Pool — hddpool:

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

Vérifions les profils de configuration :

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

Dépôt d'images ^

Les conteneurs sont créés à partir d'images qui sont des distributions spécialement assemblées n'ayant pas de noyau Linux. Par conséquent, avant de lancer un conteneur, celui-ci doit être déployé à partir de cette image. La source des images est un dépôt local dans lequel les images sont chargées depuis des dépôts externes.

Dépôts d'images distants ^

Par défaut, LXD est configuré pour obtenir des images à partir de trois sources distantes :

• ubuntu : (pour les images Ubuntu stables)
• ubuntu-daily : (pour les images Ubuntu journalières)
• images : (pour un tas d'autres distributions)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NOM       |                   URL                    | PUBLIC | STATIC |
+-----------------+------------------------------------------+--------+--------+
| images          | https://images.linuxcontainers.org       | OUI    | NON    |
+-----------------+------------------------------------------+--------+--------+
| local (défaut)  | unix://                                  | NON    | OUI    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | OUI    | OUI    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | OUI    | OUI    |
+-----------------+------------------------------------------+--------+--------+

Par exemple, le dépôt ubuntu : a les images suivantes :

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

+----------------------------------------------+--------------+----------+------------+
|                   DESCRIPTION                | ARCHITECTURE |   TAILLE |   TYPE     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | CONTENEUR  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | CONTENEUR  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | CONTENEUR  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | CONTENEUR  |
+----------------------------------------------+--------------+----------+------------+

Pour afficher un nombre limité de colonnes, nous avons utilisé l'option -c avec les paramètres dasut, et avons également limité la longueur de la liste avec la commande head.

La filtration est disponible pour la liste des images. La commande suivante affichera la liste de toutes les architectures disponibles du système d'exploitation AlpineLinux:

lxc image -c ldast list images:alpine/3.11

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

Dépôt local d'images ^

Pour commencer à utiliser le conteneur, vous devez ajouter une image du dépôt global au dépôt local local:. Actuellement, le dépôt local est vide, ce qui peut être vérifié avec la commande lxc image list. Si le dépôt n'est pas spécifié, le dépôt local sera utilisé par défaut — list lxc image list local:+-------+-------------+--------+-------------+--------------+------+------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | +-------+-------------+--------+-------------+--------------+------+------+ local:

La gestion des images dans le dépôt se fait par les méthodes suivantes :

lxc image

Commande
Description

Gérer les alias d'images alias
Copier des images entre serveurs

Gérer les alias d'images copy
Supprimer des images

Gérer les alias d'images supprimer
Modifier les propriétés des images

Gérer les alias d'images edit
exporter

Gérer les alias d'images Exporter et télécharger des images
Importer des images dans le dépôt d'images

Gérer les alias d'images importer
Afficher des informations utiles sur les images

Gérer les alias d'images info
Lister les images

Gérer les alias d'images list
Actualiser les images

Gérer les alias d'images un refresh
montrer

Gérer les alias d'images Afficher les propriétés des images
Nous copions l'image du dépôt global vers le dépôt local

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3Image copiée avec succès! images ::

Affichons la liste de toutes les images actuellement disponibles dans le dépôt local

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

En plus du mode interactif, LXD prend également en charge le mode non interactif pour la configuration, où la configuration est définie sous forme de fichier YAML, un format spécial qui permet de configurer tout d'un coup, évitant ainsi d'exécuter de nombreuses commandes interactives abordées précédemment dans cet article, y compris la configuration réseau, la création de profils de configuration, etc. Nous ne traiterons pas de ce domaine ici, vous pouvez vous y familiariser vous-même.

Configuration de LXD ^

La commande interactive suivante dans la documentation.

lxc config que nous allons examiner, permet de définir la configuration. Par exemple, pour que les images téléchargées dans le dépôt local ne soient pas mises à jour automatiquement à partir des dépôts globaux, nous pouvons activer ce comportement avec la commande suivante : lxc config set images.auto_update_cached=false

La commande pour créer un conteneur est

Création et gestion des conteneurs ^

qui prend les valeurs lxc init dépôt:image et ensuite l'identifiant souhaité pour le conteneur. Le dépôt peut être spécifié comme local. local local: C'est également le cas pour tout référentiel global. Si le référentiel n'est pas spécifié, le référentiel local est utilisé par défaut pour rechercher l'image. Si l'image est spécifiée à partir d'un référentiel global, elle sera d'abord téléchargée dans le référentiel local avant d'être utilisée pour créer le conteneur.

Exécutons la commande suivante pour créer notre premier conteneur :

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

Analysons les clés de la commande que nous utilisons ici :

• alpine3 — Spécifie l'alias pour l'image qui a été précédemment téléchargée dans le référentiel local. Si l'alias n'a pas été créé pour cette image, on peut toujours s'y référer par son Fingerprint qui est affiché dans le tableau.
• alp — Définit l'identifiant pour le conteneur
• --storage — Cette clé indique dans quel Storage Pool le conteneur sera créé
• --profile — Ces clés appliquent de manière cascade la configuration du conteneur à partir de profils de configuration préalablement créés

Démarrons le conteneur, qui commence à exécuter le système d'initialisation de la distribution :

lxc start alp

On peut également utiliser la commande lxc launch qui permet de combiner les commandes lxc init et lxc start en une seule opération.

Vérifions l'état du conteneur :

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

Vérifions la configuration du conteneur :

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

Dans la section profils nous pouvons vérifier que ce conteneur utilise deux profils de configuration — default et hddroot. Dans la section devices nous ne pouvons détecter qu'un seul appareil, car le périphérique réseau a été créé au niveau du profil. default. Pour voir tous les appareils utilisés par le conteneur, il faut ajouter la clé --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: ""

Configuration d'une adresse IP statique ^

Si nous essayons de définir une adresse IP pour l'appareil réseau eth0 la commande lxc config device set alp destinée à la configuration du conteneur, nous obtiendrons une erreur indiquant que l'appareil n'existe pas car l'appareil eth0 utilisé par le conteneur appartient au profil default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

Nous pouvons bien sûr définir une adresse IP statique pour eth0 l'appareil dans le profil, mais elle sera unique pour tous les conteneurs utilisant ce profil. Donc, ajoutons un appareil dédié pour le conteneur:

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

Ensuite, il faut redémarrer le conteneur:

lxc restart alp

Si nous regardons maintenant la configuration du conteneur, il n'est pas nécessaire d'appliquer l'option --expanded pour voir l'appareil réseau eth0, car nous l'avons créé au niveau du conteneur et il a remplacé en cascade cet appareil du profil 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: ""

Suppression du conteneur ^

La commande pour supprimer le conteneur est lxc delete, mais avant de supprimer le conteneur, il doit être arrêté à l'aide de la commande lxc stop:

lxc stop alp

lxc list

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

Après avoir vérifié que l'état du conteneur est devenu STOPPED, il peut être supprimé de Storage Pool:

lxc delete alp

Accès au conteneur ^

La commande pour exécuter des commandes dans le conteneur, directement, sans passer par des connexions réseau, est lxc exec qui exécute des commandes dans le conteneur sans lancer de shell. Si vous devez exécuter une commande dans le shell en utilisant des motifs shell, tels que des variables, des redirections de fichiers (pipe), etc., il est nécessaire de lancer explicitement le shell et de transmettre la commande comme clé, par exemple :

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

La commande impliquait un caractère spécial d'échappement pour le caractère spécial $ afin que la variable $HOME ne soit pas interprétée sur la machine hôte, mais interprétée uniquement à l'intérieur du conteneur.

Il est également possible de lancer un mode interactif du shell, puis de terminer la session en utilisant la combinaison de touches CTRL+D:

lxc exec alp -- \/bin\/sh

Gestion des ressources du conteneur ^

Dans LXD, vous pouvez gérer les ressources du conteneur à l'aide d'un ensemble spécial de configurations. La liste complète des paramètres de configuration du conteneur peut être trouvée dans la documentation.

Limitation des ressources RAM ^

Paramètre limits.memory limite la quantité de RAM disponible pour le conteneur. La valeur doit être un nombre suivi de l'un des suffixes disponibles.

Fixons une limite de RAM de 256 Mo pour le conteneur :

lxc config set alp limits.memory 256MB

De plus, il existe d'autres paramètres pour limiter la mémoire :

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

Commande lxc config show permet d'afficher toute la configuration du conteneur, y compris la restriction de ressources appliquée qui a été mise en place :

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

Limitation des ressources CPU ^

Pour limiter les ressources CPU, il existe plusieurs types de contraintes:

• limit.cpu — attache le conteneur à un ou plusieurs cœurs de CPU
• limits.cpu.allowance — gère soit les quotas du planificateur CFS, lorsque la limite de temps est atteinte, soit un mécanisme universel de partage des ressources CPU, lorsque la valeur en pourcentage est atteinte
• limits.cpu.priority — priorité du planificateur, lorsque plusieurs instances partageant un ensemble de processeurs ont reçu le même pourcentage de processeurs

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

Limitation de l'espace disque ^

En plus des restrictions telles que limits.read, limits.write nous pouvons également limiter l'espace disque consommé par le conteneur (fonctionne uniquement avec ZFS ou BTRFS) :

lxc config device set alp root size=2GB

Après configuration, dans le paramètre devices.root.size nous pouvons vérifier la limite appliquée :

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

Pour consulter les quotas de disque utilisés, nous pouvons obtenir à partir de la commande 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

Bien que nous ayons fixé une limite de 2 Go pour le périphérique racine du conteneur, des utilitaires système tels que df ne verront pas cette restriction. Pour cela, nous allons effectuer un petit test et voir comment cela fonctionne.

Créons 2 nouveaux conteneurs identiques dans le même Storage Pool (hddpool):

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

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAME |  ÉTAT  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | EN COURS | 10.0.5.46 (eth0) |      | CONTENEUR | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | EN COURS | 10.0.5.30 (eth0) |      | CONTENEUR | 0         |
+------+---------+------------------+------+-----------+-----------+

Dans l'un des conteneurs, créons un fichier de 1 Go :

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

Vérifions que le fichier a été créé :

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

Si nous regardons dans le deuxième conteneur, en vérifiant l'existence du fichier au même endroit, ce fichier ne sera pas là, ce qui est attendu, car les conteneurs sont créés dans leurs propres Storage Volume dans celui-ci Storage Pool:

lxc exec alp2 -- ls -lh
total 0

Mais comparons les valeurs affichées df dans les deux conteneurs :

lxc exec alp1 -- df -hT
Système de fichiers      Type            Taille      Utilisé Disponible Utilisé% Monté sur
/dev/loop1              btrfs           9.3G   1016.4M      7.8G  11% /n...

lxc exec alp2 -- df -hT
Système de fichiers      Type            Taille      Utilisé Disponible Utilisé% Monté sur
/dev/loop1              btrfs           9.3G   1016.4M      7.8G  11% /n...

Appareil /dev/loop1 monté comme partition racine est Storage Pool ce que ces conteneurs utilisent, donc ils partagent son volume à deux.

Statistiques de consommation des ressources ^

Pour afficher les statistiques d'utilisation des ressources d'un conteneur, vous pouvez utiliser la commande :

lxc info alp

Nom : alp
Emplacement : aucun
Distant : unix://
Architecture : x86_64
Créé : 2020/04/08 18:05 UTC
Statut : En cours
Type : conteneur
Profils : 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
Ressources :
  Processus : 5
  Utilisation du disque :
    racine : 495.62kB
  Utilisation CPU :
    Utilisation CPU (en secondes) : 1
  Utilisation de la mémoire :
    Mémoire (actuelle) : 4.79MB
  Utilisation réseau :
    eth0 :
      Octets reçus : 730B
      Octets envoyés : 1.59kB
      Paquets reçus : 3
      Paquets envoyés : 14
    lo :
      Octets reçus : 0B
      Octets envoyés : 0B
      Paquets reçus : 0
      Paquets envoyés : 0

Travail avec des snapshots ^

LXD permet de créer des snapshots et de restaurer l'état d'un conteneur à partir de ceux-ci.

Pour créer un snapshot, exécutez la commande suivante :

lxc snapshot alp snapshot1

La commande lxc snapshot n'a pas de clé list, donc, pour voir la liste des snapshots, il faut utiliser la commande qui affiche les informations générales sur le conteneur :

lxc info alp
...
...
Snapshots:
  snapshot1 (prenant à 2020/04/08 18:18 UTC) (sans état)

Vous pouvez restaurer le conteneur à partir d'un instantané avec la commande lxc restore en spécifiant le conteneur pour lequel la restauration sera effectuée et le nom de l'instantané :

lxc restore alp snapshot1

La commande suivante sert à supprimer un instantané. Notez que la syntaxe de la commande est différente des autres ; ici, un slash direct doit être spécifié après le nom du conteneur. Si le slash est omis, la commande de suppression de l'instantané est interprétée comme une commande de suppression du conteneur !

lxc delete alp/snapshot1

Dans l'exemple ci-dessus, nous avons examiné les soi-disant instantanés sans état. LXD dispose également d'un autre type d'instantanés — ceux avec état, qui conservent l'état actuel de tous les processus dans le conteneur. Les instantanés avec état sont associés à plusieurs fonctionnalités intéressantes et utiles.

Quoi d'autre ? ^

• Pour les développeurs Python, un module est disponible PyLXD qui fournit une API à LXD

MISE À JOUR 10.04.2020 15:00 : Navigation ajoutée

Source : habr.com