Qu’est-ce que LXD ? Gestion des con­te­neurs avec le Linux Container Daemon

LXD, le « Linux Container Daemon », est un outil de gestion des con­te­neurs du système d’ex­ploi­ta­tion Linux. Il a été développé par Canonical, la société à l’origine d’Ubuntu Linux. Canonical poursuit le dé­ve­lop­pe­ment de LXD jusqu’à aujourd’hui et dirige le projet.

LXD est une tech­no­lo­gie sœur de LXC, les « Linux Con­tai­ners ». LXC est une tech­no­lo­gies de vir­tua­li­sa­tion basée sur les con­te­neurs au niveau du système d’ex­ploi­ta­tion. Tech­ni­que­ment, LXC combine des espaces de noms isolés et les « cgroups » du noyau Linux pour créer des en­vi­ron­ne­ments isolés pour l’exécution du code. His­to­ri­que­ment, LXC a également été à la base de la tech­no­lo­gie de vir­tua­li­sa­tion largement utilisée Docker.

L’un des objectifs fon­da­men­taux du dé­ve­lop­pe­ment de LXD était de rendre la gestion des con­te­neurs LXC aussi pratique que celle des machines vir­tuelles. Toutefois, par rapport à l’uti­li­sa­tion d’une machine virtuelle, l’approche basée sur les con­te­neurs offre des per­for­mances su­pé­rieures.

LXD permet de con­fi­gu­rer et de contrôler les con­te­neurs du système d’ex­ploi­ta­tion Linux via un ensemble défini de commandes. LXD est donc adapté à l’au­to­ma­ti­sa­tion de la gestion des con­te­neurs de masse et utilisé dans l’in­for­ma­tique en cloud et les centres de données.

• Sécurité : les con­te­neurs fonc­tion­nent dans des espaces de noms isolés et ne peuvent accéder qu’à des res­sources définies.
• Évo­lu­ti­vité : LXD vous permet de gérer d’un seul conteneur sur votre or­di­na­teur portable à des milliers de con­te­neurs dans des en­vi­ron­ne­ments dis­tri­bués.
• Uti­li­sa­tion intuitive : LXD fournit une API simple et claire et un client en ligne de commande cor­res­pon­dant.
• Basé sur des images Linux : LXD fonc­tionne avec n’importe quelle image Linux et bénéficie ainsi du grand nombre de dis­tri­bu­tions Linux exis­tantes.
• Contrôle so­phis­ti­qué des res­sources : des res­tric­tions sont définies pour un conteneur pour le CPU, la mémoire, l’uti­li­sa­tion du réseau, l’uti­li­sa­tion du stockage de masse et les res­sources du noyau.
• Accès au matériel du système : si la con­fi­gu­ra­tion le permet, les con­te­neurs peuvent accéder à des pé­ri­phé­riques USB, à des GPU et à des supports de stockage de masse, entre autres.
• Gestion du réseau : les ponts et tunnels du réseau peuvent être créés par con­fi­gu­ra­tion.
• Gestion du stockage de masse : LXD prend en charge divers backends, pools de stockage et volumes de stockage.

Le principal avantage est que LXD permet la vir­tua­li­sa­tion d’un système d’ex­ploi­ta­tion Linux complet sur une base de conteneur. LXD combine ainsi le confort des machines vir­tuelles avec la per­for­mance des con­te­neurs.

Con­trai­re­ment à la plupart des cas d’uti­li­sa­tion basés sur Docker, LXD ne se concentre pas sur la vir­tua­li­sa­tion d’une seule ap­pli­ca­tion (« app vir­tua­li­za­tion »). C’est plutôt une image du système Linux qui sert de base à chaque conteneur LXD (« vir­tua­li­sa­tion du système »). Cette solution est avan­ta­geuse pour l’ad­mi­nis­tra­teur, car elle donne accès à un grand nombre de dis­tri­bu­tions Linux librement dis­po­nibles et permet l’uti­li­sa­tion d’un large éventail d’outils existants.

Toutefois, LXD présente un in­con­vé­nient par rapport aux autres tech­no­lo­gies de vir­tua­li­sa­tion : comme tous les con­te­neurs fonc­tion­nant sur un hôte accèdent au même noyau Linux, LXD Deamond n’est dis­po­nible que sous Linux. En outre, LXD ne peut vir­tua­li­ser Linux qu’en tant que système d’ex­ploi­ta­tion invité. Toutefois, le client en ligne de commande fonc­tionne également sur des systèmes d’ex­ploi­ta­tion non Linux.

L’API REST du démon LXD est ac­ces­sible sur le réseau. Cela permet de déplacer ou de copier les con­te­neurs entre les machines. En outre, LXD soutient la création de grappes de machines qui combinent de nom­breuses unités de calcul in­di­vi­duelles en un su­pe­ror­di­na­teur virtuel.

L’élément central de LXD est le démon pri­vi­lé­gié, qui attribue des noms et fonc­tionne sur le système hôte Linux. Le démon LXD fournit un API REST est dis­po­nible via une socket Linux locale. Le démon peut également être ac­ces­sible sur le réseau par des pa­ra­mètres de con­fi­gu­ra­tion. En parallèle, LXD accède à LXC comme backend via la bi­blio­thèque liblxc et ses go-bindings.

Un client interagit avec le démon via l’API REST. L’API définit un langage avec lequel les con­te­neurs peuvent être créés, contrôlés et modifiés. Le client le plus simple est l’outil officiel de la ligne de commande. Le client en ligne de commande fournit des commandes pour de nom­breuses opé­ra­tions courantes et accède à l’API REST en interne.

Dans ce qui suit, nous avons compilé quelques commandes LXD de base. Ne vous y trompez pas : le nom de la ligne de commande LXD est lxc, et non lxd. Vous pouvez essayer les commandes vous-même sans avoir à installer le client en ligne de commande sur votre système. Il suffit d’utiliser l’interface basée sur le Web sur le projet li­nux­con­tai­ners.org.

En principe, LXD peut être installé sur tout système Linux moderne. D’une part, LXD peut être utilisé sur des or­di­na­teurs privés, d’autre part, le LXD est également utilisé dans les pla­te­formes de cloud computing et les centres de données dis­tri­bués. L’objectif premier de LXD est de vir­tua­li­ser un système d’ex­ploi­ta­tion Linux complet et durable à l’usage. LXD est à l’opposé de Docker, qui se concentre davantage sur les con­te­neurs à courte durée de vie qui en­cap­su­lent une seule ap­pli­ca­tion Selon les mots du dé­ve­lop­peur LXD Stéphane Graber :

Ces con­te­neurs ont gé­né­ra­le­ment une longue durée de vie et sont conçus pour contrôler un petit nombre de con­te­neurs, le client en ligne de commande fourni avec le logiciel est adapté. Cependant, il n’est pas prévu pour gérer un grand nombre de con­te­neurs sur un grand nombre d’hôtes dis­tri­bués. Pour ces cas d’uti­li­sa­tion, des con­nexions aux pla­te­formes OpenStack et Open­Ne­bula sont utilisées.

Les prin­ci­paux com­po­sants de LXD sont le démon, l’API REST fournie par ce dernier et le client en ligne de commande. Dans ce qui suit, nous exa­mi­ne­rons les entités qui sont prin­ci­pa­le­ment utilisées lorsque l’on travaille avec LXD.

Le conteneur est l’abs­trac­tion de base fournie par LXD. Un conteneur LXD présente les pro­prié­tés suivantes :

• Un système de fichiers Linux
• Les pa­ra­mètres de con­fi­gu­ra­tion tels que les limites de res­sources, les variables d’en­vi­ron­ne­ment, les options de sécurité, etc.
• Des dis­po­si­tifs de stockage de masse et de réseau
• Des profils de con­fi­gu­ra­tion dont le conteneur hérite des pa­ra­mètres
• Des pro­prié­tés générales telles que l’ar­chi­tec­ture du conteneur, le nom et le fait que le conteneur soit de courte ou de longue durée de vie
• Les états d’exécution tel que le débit du réseau, l’uti­li­sa­tion de la mémoire, etc.

Comme souvent avec les tech­no­lo­gies de vir­tua­li­sa­tion, des ins­tan­ta­nés (« snapshots ») peuvent être créés à partir d’un conteneur. Un ins­tan­tané est identique au contenant sous-jacent. Les clichés sont « immuables » et ne peuvent être modifiés. Ils ne peuvent être que renommés et supprimés. À partir d’un ins­tan­tané, il est possible de restaurer l’état exact d’un conteneur.

Bien que LXD soit une tech­no­lo­gie basée sur un conteneur, une image du système Linux est utilisée pour créer le conteneur. Par dé­fi­ni­tion, chaque conteneur LXD provient d’une image.

Les images sont gé­né­ra­le­ment des dis­tri­bu­tions Linux non modifiées comme celles utilisées pour les machines vir­tuelles ou les instances de cloud. Une image est iden­ti­fiée de manière unique par son hachage SHA256. Pour rendre l’af­fec­ta­tion plus con­vi­viale pour les uti­li­sa­teurs humains, un nom d’alias peut être défini pour une image.

Les images Linux à utiliser avec LXD peuvent être obtenues en ligne auprès de diverses sources. Les serveurs d’images suivants sont pré­dé­fi­nis en LXD :

• Ubuntu : fournit des images Ubuntu stables
• ubuntu-daily : fournit des ensembles quo­ti­diens d’images Ubuntu
• Image s : fournit une variété d’images d’autres dis­tri­bu­tions Linux (géré par la com­mu­nauté elle-même)

Les images té­lé­char­gées par le démon LXD sont au­to­ma­ti­que­ment mises en cache afin qu’elles soient dis­po­nibles sans délai pour un usage répété. Sauf con­fi­gu­ra­tion contraire, LXD vérifie la version des images té­lé­char­gées et té­lé­charge les nouvelles versions si né­ces­saire. Comme pour le concept de la « Vagrant Box », LXD peut publier un conteneur existant sous la forme d’une nouvelle image.

Un profil LXD regroupe divers pa­ra­mètres de con­fi­gu­ra­tion des con­te­neurs. Un profil peut être appliqué à plusieurs con­te­neurs et plusieurs profils peuvent être appliqués à un conteneur l’un après l’autre. Enfin, la con­fi­gu­ra­tion locale des con­te­neurs est importée. Au cours de ce processus, les valeurs de con­fi­gu­ra­tion qui ont été définies plusieurs fois peuvent être écrasées. Cela permet de créer fa­ci­le­ment des familles de con­te­neurs. LXD est livré avec deux profils existants :

• Le profil défaut est au­to­ma­ti­que­ment appliqué à un conteneur, à moins qu’un profil al­ter­na­tif ne soit spécifié. Ce profil comprend des pa­ra­mètres de con­fi­gu­ra­tion de base, tels que le dis­po­si­tif de réseau eth0 du conteneur.
• Le profil docker est utilisé pour con­fi­gu­rer un conteneur LXD qui doit contenir des con­te­neurs de docker. Le profil fait en sorte que le conteneur LXD charge les modules de noyau né­ces­saires et règle les pa­ra­mètres du dis­po­si­tif. Il permet également l’em­boî­te­ment des con­te­neurs.

LXD est un démon de réseau : le client en ligne de commande peut com­mu­ni­quer avec plusieurs serveurs LXD et serveurs d’images distants. Plusieurs serveurs peuvent être définis comme serveurs à distance par con­fi­gu­ra­tion. Ceci permet de copier et de déplacer les con­te­neurs existants entre les serveurs LXD et d’accéder aux serveurs d’images via les té­lé­com­mandes. En plus des serveurs d’images déjà présentés dans la section « Images », le client en ligne de commande connaît également le serveur à distance « local » par défaut. Il est utilisé pour com­mu­ni­quer avec le démon LXD local via une socket UNIX.

Aujourd’hui, il existe un large éventail de tech­no­lo­gies de vir­tua­li­sa­tion qui peuvent en principe être utilisées comme al­ter­na­tives à LXD. Ceux-ci diffèrent en fonction de plusieurs critères, et peuvent être divisés en deux grands groupes. En plus des outils de vir­tua­li­sa­tion tra­di­tion­nels basés sur les machines vir­tuelles, les tech­no­lo­gies basées sur les con­te­neurs sont de plus en plus acceptées. Ici, LXD se distingue et utilise une approche hybride dans laquelle un système d’ex­ploi­ta­tion Linux entier est vir­tua­lisé sur la base d’un conteneur.

Certains outils de vir­tua­li­sa­tion ont besoin de Linux comme système hôte, tandis que d’autres fonc­tion­nent sur tous les systèmes d’ex­ploi­ta­tion courants. De même, certains en­vi­ron­ne­ments de vir­tua­li­sa­tion ne sup­por­tent que Linux en tant que système invité, alors que d’autres en sup­por­tent plusieurs. De nom­breuses tech­no­lo­gies basées sur les con­te­neurs se con­centrent prin­ci­pa­le­ment sur la vir­tua­li­sa­tion des ap­pli­ca­tions, tandis que les machines vir­tuelles sont toujours basées sur un système d’ex­ploi­ta­tion complet.

Comme LXD est basé sur LXC, il est possible d’utiliser une ins­tal­la­tion LXC « nue » en tant qu’al­ter­na­tive à LXD. Dans ce cas, l’uti­li­sa­tion peut toutefois être moins con­for­table. Comme aucun démon n’est utilisé sans LXD, la vir­tua­li­sa­tion ne peut être contrôlée sur le réseau. En outre, il manque alors l’interface uniforme REST-API.

Parmi les outils de vir­tua­li­sa­tion courants, con­tai­nerd est pro­ba­ble­ment le plus com­pa­rable à LXD. Ainsi, con­tai­nerd fonc­tionne également comme un démon qui fournit une API. Comme LXD, il permet de gérer les con­te­neurs sur le réseau. La tech­no­lo­gie est intégrée dans Docker et est utilisée fré­quem­ment.

En général, il est conseillé de choisir la tech­no­lo­gie ap­pro­priée en fonction des exigences spé­ci­fiques. Voici un aperçu des tech­no­lo­gies de vir­tua­li­sa­tion fré­quem­ment utilisées :