Linux Containers - Incus

7 oct. 2023

Introduction¶

L’équipe de Linux Containers est très heureuse de vous annoncer la version initiale d’Incus !

Incus est un fork de Canonical LXD géré par la communauté créé par @cyphar et faisant à présent partie du projet Linux Containers.

Cette version initiale est à peu près équivalente à LXD 5.18, mais avec un certain nombre de changements cassant la compatibilité (en plus du renommage).

Vous pouvez l’essayer vous-même en ligne : https://linuxcontainers.org/incus/try-it/

Changements¶

Avec cette première version d’Incus, nous en avons profité pour supprimer de nombreuses fonctionnalités inutilisées ou problématiques de LXD. La plupart de ces changements sont des choses que nous aurions aimé faire dans LXD, mais que nos exigences de rétrocompatibilité ne nous ont pas permis de réaliser.

Incus sera tout aussi strict avec la rétrocompatibilité dans le futur, mais puisqu’il s’agit de la première version de notre fork, c’était l’occasion de changer les choses qui devaient l’être.

Cela dit, l’API et l’interface en ligne de commande sont toujours très proches de celles de LXD, rendant le passage de LXD à Incus trivial (voire presque complètement transparent).

API¶

Suppression de `/1.0/containers` et `/1.0/virtual-machines`¶

LXD a débuté en tant que gestionnaire de conteneurs uniquement, et son API REST utilisait /1.0/containers.

Lorsque les machines virtuelles ont été rajoutées, un nouvel endpoint /1.0/instances a pris le relais pour les opérations sur les conteneurs et les machines virtuelles, mais /1.0/containers a été conservé pour des raisons de rétrocompatibilité. En outre, un endpoint /1.0/virtual-machines avait été ajouté, bien que jamais utilisé en pratique.

Dans Incus, tout se passe dans /1.0/instances et les deux autres endpoints ont été supprimés.

Remplacement de /dev/lxd par /dev/incus¶

Dans le cadre du changement de nom de LXD pour Incus, l’API des systèmes invités est passée de /dev/lxd à /dev/incus.

Des liens symboliques sont présents pour le moment, pour que les instances migrées depuis LXD continuent à fonctionner sur Incus.

Changement de type pour la configuration serveur¶

La configuration du serveur LXD a toujours été typée de manière quelque peu étrange, avec des map[string]any plutôt que des map[string]string. La raison de cette incohérence est due à core.trust_password, l’ancienne méthode d’authentification utilisée par LXD dans ses premières versions.

LXD ne stockait jamais les mots de passe en clair ; ceux-ci étaient hashés et ce sont les hashs qui étaient stockés. Il était donc impossible de renvoyer la configuration complète à l’utilisateur. Au lieu de cela, lorsqu’un mot de passe était défini, un booléen true était renvoyé à la place d’une chaîne de caractères.

core.trust_password étant déprécié, il a été remplacé par de l’authentification par jeton, par certificat TLS, ou par des mécanismes externes.

Incus a complètement supprimé le support de core.trust_password (voir ci-dessous), donc toute la configuration peut désormais être typée en map[string]string.

Suppression des anciennes fonctions `Container` de l’API Go¶

Suite à la suppression de /1.0/containers et /1.0/virtual-machines, les fonctions correspondantes dans le paquet Go du client ont également été supprimées.

À la place, il faut utiliser les fonctions Instance (par exemple, CreateInstance au lieu de CreateContainer).

CLI¶

Ajout de la sous-commande `incus snapshot`¶

Un point irritant de longue date dans l’interface en ligne de commande de LXD est la gestion des instantanés. Alors que la plupart des opérations ont leurs propres sous-commandes (file, config…), les instantanés sont restés au premier niveau, avec les commandes snapshot et restore.

Cette incohérence nous forçait à gérer les renommages et les suppressions des instantanés avec les commandes lxc rename et lxc delete. Une sous-commande lxc snapshot permettant de lancer lxc snapshot create aurait été beaucoup plus logique, mais cela ne pouvait pas être fait sans rendre inopérants les anciens scripts utilisant lxc snapshot.

Il est temps de corriger cela, donc nous avons créé la sous commande incus snapshot contenant :

incus snapshot create
incus snapshot delete
incus snapshot list
incus snapshot rename
incus snapshot restore

Gestion de `incus config trust add` et `incus cluster add`¶

Incus ayant abandonné l’authentification par mot de passe au profit de jetons, il était important de rendre la génération des jetons simple et cohérente.

En conséquence, incus config trust add et incus cluster add prennent désormais un nom en argument et retournent un jeton valide.

La logique de gestion des certificats par incus config trust add a maintenant été déplacée dans incus config trust add-certificate.

Ajout de la sous-commande `incus admin`¶

Autre irritant de longue date dans LXD, le besoin d’interagir à la fois avec les commandes lxc et lxd pour configurer un serveur. Avec Incus, le binaire incusd peut être caché puisque personne ne devrait avoir besoin de l’utiliser directement.

À la place, nous avons maintenant la sous-commande incus admin :

incus admin cluster
incus admin init
incus admin recover
incus admin shutdown
incus admin waitready

Dépendances¶

Transition vers Cowsql¶

https://github.com/cowsql/cowsql

Peu après que @cyphar a créé le fork de LXD, @freeekanayaka, l’auteur original de Dqlite, a également décidé de faire un fork de Dqlite, Cowsql. Étant donné que @freeekanayaka est aussi mainteneur d’Incus, il était logique de porter Incus sur Cowsql.

Comme pour Incus, Cowsql est un fork géré par la communauté de Canonical Dqlite, largement compatible avec Dqlite, permettant à Incus d’importer facilement les données existantes pendant la phase de migration.

Jusqu’à présent, l’accent a été mis dans Cowsql sur l’amélioration des tests de performance et de nombreux changements ont été apportés à Raft et Cowsql pour en améliorer les performances dans Incus.

Version minimale de Go¶

Pour les personnes compilant les sources d’Incus, la version minimale requise de Go est maintenant Go 1.20.
Nous essaierons de continuer à supporter la compilation d’Incus sur la version courante de Go ainsi que sur des versions plus anciennes.

Suppression de fonctionnalités¶

Un certain nombre de fonctionnalités de LXD ont été retirées d’Incus.
Il s’agit principalement de fonctionnalités qui ont été ajoutées pour des raisons liées à l’écosystème de LXD et/ou qui dépendaient de logiciels obsolètes ou peu maintenus.

Suppression des bridges Ubuntu Fan¶

Les bridges Ubuntu Fan dépendent de correctifs appliqués sur le noyau Linux présents uniquement sous Ubuntu, ainsi que de modifications sur iproute2. Bien que cette fonctionnalité soit toujours maintenue dans le noyau Ubuntu, elle n’est ni présente dans le noyau générique, ni dans les noyaux d’autres distributions.

Bien que pratiques dans certains environnements, les bridges Ubuntu Fan ne font pas le poids face aux possibilités offertes par l’intégration d’Incus avec OVN.

Les clefs de configuration réseau suivantes ont donc été supprimées :

bridge.mode
fan.overlay_subnet
fan.underlay_subnet
fan.type

Suppression d’Ubuntu shiftfs¶

Autre fonctionnalité propre au noyau Ubuntu, shiftfs était une tentative de fournir des décalages d’uid/gid flexibles au niveau du noyau.

Bien que LXD ait pris en charge shiftfs pendant des années, il n’était jamais activé par défaut à cause d’un certain nombre de problèmes dans le noyau. Au lieu de cela, une solution plus propre a été développée, le VFS idmap shifting. La fonctionnalité est désormais disponible dans les noyaux Linux récents et est automatiquement utilisée par Incus lorsqu’elle est présente.

Suppression de l’authentification Canonical Candid¶

À l’époque, Canonical développait son propre système d’authentification utilisant des Macaroons. Le serveur central d’authentification utilisant ce système était nommé Candid.

Le support de Candid a été ajouté dans LXD, permettant aux utilisateurs de se connecter par l’intermédiaire d’une variété de fournisseurs.

De nos jours, Candid n’est pratiquement plus maintenu et l’accent a été mis sur le passage à des standards industriels, notamment OpenID Connect.

Par conséquent, les clefs de configuration suivantes ont été supprimées :

candid.api.key
candid.api.url
candid.domains
candid.expiry

Incus prend déjà en charge OpenID Connect pour l’authentification externe, et il existe de nombreux serveurs OIDC qui fournissent autant, voire plus, de fonctionnalités que Candid.

Suppression de l’autorisation Canonical RBAC¶

Canonical RBAC était un système propriétaire de contrôle d’accès basé sur les rôles (RBAC) construit par-dessus Macaroons et Candid.

Il n’était guère utilisé que par MAAS et LXD et a été très peu adopté, principalement du fait de son caractère propriétaire et de la difficulté d’y accéder.

Canonical RBAC n’est pratiquement plus maintenu et l’accent a été mis sur le passage à des protocoles plus éprouvés, comme OpenFGA.

Par conséquent, les clefs de configuration suivantes ont été supprimées :

rbac.agent.url
rbac.agent.username
rbac.agent.private_key
rbac.agent.public_key
rbac.api.expiry
rbac.api.key
rbac.api.url
rbac.expiry

Incus ne supporte pas encore OpenFGA, donc les personnes utilisant Canonical RBAC devraient rester sur LXD tant que nous ne fournissons pas d’alternative avec OIDC et OpenFGA.

Suppression de l’intégration Canonical MAAS¶

LXD supporte l’intégration avec l’API MAAS pour utiliser MAAS comme une sorte de solution d’IPAM (IP Address Management).

Cela permet de faire correspondre des sous-réseaux LXD avec des sous-réseaux MAAS et de faire en sorte que MAAS crée des enregistrements pour chaque instance du réseau, leur donnant une adresse statique et un enregistrement DNS.

Malheureusement, cette intégration est très peu utilisée et MAAS présente en soi de nombreuses contraintes qui rendent l’intégration problématique :

Les adresses MAC dans MAAS sont globalement uniques, alors que dans LXD, elles n’ont besoin d’être uniques qu’au sein d’un même réseau pour les instances en cours d’exécution. Cette différence rend certaines opérations de copie impossibles.
Les noms des instances doivent être globalement uniques dans MAAS, même si celles-ci sont attachées à des zones DNS complètement différentes. Cela rend l’utilisation des projets LXD impossible, car les instances peuvent facilement entrer en conflit.

Entre ces problèmes et le manque d’adoption de la fonctionnalité, nous avons pris la décision de retirer le support de MAAS d’Incus ; les clefs de configuration suivantes ont donc été supprimées :

maas.api.key
maas.api.url
maas.subnet.ipv4
maas.subnet.ipv6

Suppression des mots de passe de confiance¶

Aux débuts de LXD, la seule manière de se connecter à un serveur distant était d’utiliser un mot de passe de confiance, c’est-à-dire un secret fixe qui permettait à un client d’ajouter son certificat TLS au magasin de confiance du serveur.

En pratique, cela permettait à toute personne connaissant ou étant en mesure de trouver le mot de passe de confiance d’ajouter son propre certificat au magasin de confiance.

Il fallait donc conserver ce mot de passe en toute sécurité, ou le désactiver immédiatement après l’ajout d’un nouveau client. C’était malheureusement rarement le cas, ce qui ouvrait la porte à des attaques par bruteforce sur le mot de passe de confiance, permettant dans certains cas à un attaquant de prendre le contrôle sur LXD et les serveurs qu’il gère.

Pour remédier à cela, le support de jetons de confiance à usage unique a été ajouté il y a quelques temps, et la documentation a été mise à jour pour décourager les utilisateurs d’utiliser des mots de passe de confiance.

Dans Incus, nous sommes allés plus loin et avons complètement supprimé le support des mots de passe de confiance. L’ajout de nouveaux clients ou de nouveaux serveurs à un cluster doit maintenant se faire à l’aide de jetons à usage unique, ou avec une authentification externe via OIDC.

Par conséquent, la clef de configuration de serveur suivante a été supprimée :

core.trust_password

Divers¶

Changement dans les informations DMI¶

Pour les machines virtuelles Incus, le constructeur est maintenant Linux Containers et le produit Incus.

Changement du marqueur virtio-serial¶

Le périphérique virtio-serial utilisé pour la communication avec Incus avant l’établissement de la connexion de l’agent en vsock est maintenant org.linuxcontainers.incus.

Migration depuis LXD¶

Incus dispose d’un outil, lxd-to-incus, qui peut être utilisé pour passer de LXD à Incus.

Les principales restrictions à ce stade sont :

Version minimale de LXD : 4.0
Version maximale de LXD : 5.18
Pas de support pour la migration des clusters (nous y travaillons)

Documentation¶

La documentation d’Incus peut être consultée sur :
https://linuxcontainers.org/incus/docs/main/

Paquets¶

Incus ne fournit pas de paquet d’installation mais bien un tarball à chaque version. Vous trouverez ci-dessous différentes solutions pour mettre Incus en service.

Paquets Zabbly pour Debian et Ubuntu¶

Zabbly fournit à la fois des paquets stables et des paquets générés quotidiennement pour Incus à destination des systèmes Debian et Ubuntu :
https://github.com/zabbly/incus

Paquet Homebrew du client Incus¶

Le client Incus est disponible sur Homebrew pour Linux et macOS.

https://formulae.brew.sh/formula/incus

Paquet Chocolatey du client Incus¶

Le client Incus sera bientôt disponible sur Chocolatey pour les utilisateurs de Windows.
En attendant, les binaires peuvent être obtenus ici : https://github.com/lxc/incus/releases/tag/v0.1.0

Support¶

À ce stade, chaque version d’Incus ne sera supportée que jusqu’à la sortie de la suivante. Cela changera dans quelques mois, car nous prévoyons de sortir une version LTS qui coïncidera avec les versions LTS de LXC et LXCFS.

Le support communautaire est disponible sur : https://discuss.linuxcontainers.org
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues

Contents

Incus 0.1 est maintenant disponible

Incus 0.1 est maintenant disponible¶