Retour à l’aperçu de l’actualité

Incus 0.5 est maintenant disponible¶

26 janv. 2024

Introduction¶

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 0.5 !

C’est notre première version de l’année 2024, et elle est assez chargée ! C’est aussi la première version qui n’intègre aucun changement de LXD, depuis leur décision de passer en AGPLv3.

Cette version présente de nombreuses améliorations dans la CLI d’Incus, de nouvelles fonctionnalités pour les machines virtuelles, plus d’options pour gérer les évacuations dans les clusters et les extinctions de serveurs, et beaucoup d’autres nouvelles fonctionnalités et améliorations !

De plus, nous avons corrigé un grand nombre de bugs et apporté des améliorations dans notre base de données, ce qui devrait se traduire par une amélioration notable des performances d’Incus, notamment pour les clusters.

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

Points marquants¶

Ansible, Terraform/OpenTofu et Packer¶

Au cours des derniers mois, le support d’Incus s’est beaucoup développé dans ces outils !

• Un plugin de connexion pour Incus est maintenant disponible dans Ansible
• Nous avons un provider officiel pour Terraform et OpenTofu
• Il y a maintenant un plugin Packer pour Incus.

Paquets pour les distributions Linux¶

Depuis la dernière version d’Incus, des paquets supplémentaires sont désormais disponibles pour :

• Arch Linux
• Debian (testing/unstable)
• Ubuntu (noble)
• Void Linux

Vous trouverez toutes les instructions dans notre guide d’installation.

Traductions¶

Nous avons passé du temps à nettoyer les traductions et à configurer Weblate pour Incus.
Il est maintenant plus facile que jamais de traduire l’outil en ligne de commande Incus dans votre langage en vous connectant à Weblate.
Tous les changements sont automatiquement soumis sur Github.

Notes de mise à jour¶

Entrées subuid/subgid¶

Un bug de longue date dans le parseur idmap ignorait toutes les entrées de l’utilisateur root dans /etc/subuid et /etc/subgid, à l’exception de la première entrée suffisamment grande.

Cela posait des problèmes aux quelques utilisateurs qui avaient une raison légitime de diviser leur allocation d’uid/gid en deux, principalement pour de l’authentification à distance sur le système hôte.

Le bug a été résolu, mais la résolution a pour effet secondaire de faire échouer le lancement des conteneurs Incus sur les systèmes avec une configuration subuid/subgid invalide.

Si vous remarquez que vos conteneurs ne démarrent plus, vérifiez les fichiers /etc/subuid et /etc/subgid et assurez-vous qu’il y a au moins une entrée pour l’utilisateur root suffisamment large (au moins 65536 uid/gid). Plus important encore, assurez-vous qu’il n’y a aucun conflit ou chevauchement dans les allocations de l’utilisateur root.

Dans la plupart des cas, le plus simple est de supprimer toutes les entrées pour root de ces fichiers et de les remplacer par une entrée très large :

root:1000000:1000000000

Nouvelles fonctionnalités¶

Nouvelle commande incus file create¶

Une nouvelle commande incus file create a été ajoutée pour créer facilement des fichiers vierges, des liens symboliques, et des répertoires, sans avoir à transférer une arborescence existante.

stgraber@dakara:~$ incus file create demo/root/file
stgraber@dakara:~$ incus file create --type=symlink demo/root/symlink /etc/hosts
stgraber@dakara:~$ incus file create --type=directory demo/root/dir
stgraber@dakara:~$ incus exec demo -- ls -lh /root
total 2.5K
drwxr-xr-x 2 root root  2 Jan 26 03:38 dir
-rw-r--r-- 1 root root  0 Jan 26 03:37 file
lrwxrwxrwx 1 root root 10 Jan 26 03:38 symlink -> /etc/hosts

Nouvelle commande incus snapshot show¶

Une nouvelle commande incus snapshot show permet de consulter facilement les données de configuration contenues dans un instantané d’instance Incus.

Pour rappel, les instantanés d’Incus ne contiennent pas uniquement l’état du système de fichiers, mais également toute la configuration de l’instance (clefs de configuration, périphériques…) au moment de la prise de l’instantané.

stgraber@dakara:~$ incus snapshot create demo s1
stgraber@dakara:~$ incus snapshot list demo
+------+----------------------+----------------------+----------+
| NAME |       TAKEN AT       |      EXPIRES AT      | STATEFUL |
+------+----------------------+----------------------+----------+
| s1   | 2024/01/25 22:39 EST | 0000/12/31 19:03 LMT | NO       |
+------+----------------------+----------------------+----------+
stgraber@dakara:~$ incus snapshot show demo s1
expires_at: 0001-01-01T00:00:00Z
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Ubuntu jammy amd64 (20240125_07:42)
  image.os: Ubuntu
  image.release: jammy
  image.serial: "20240125_07:42"
  image.type: squashfs
  image.variant: default
  volatile.base_image: f9e9abeb4fc8691edf48078616a1aae628c6d5938b715e361c6b47cda0474679
  volatile.cloud-init.instance-id: f724feba-245a-424b-bc51-43167258dc2a
  volatile.eth0.host_name: vethecbb346e
  volatile.eth0.hwaddr: 00:16:3e:06:67:f0
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 8b8a1c75-977b-4197-9ad7-507b899432e9
  volatile.uuid.generation: 8b8a1c75-977b-4197-9ad7-507b899432e9
created_at: 2024-01-26T03:39:09.583020489Z
devices: {}
ephemeral: false
expanded_config:
  image.architecture: amd64
  image.description: Ubuntu jammy amd64 (20240125_07:42)
  image.os: Ubuntu
  image.release: jammy
  image.serial: "20240125_07:42"
  image.type: squashfs
  image.variant: default
  volatile.base_image: f9e9abeb4fc8691edf48078616a1aae628c6d5938b715e361c6b47cda0474679
  volatile.cloud-init.instance-id: f724feba-245a-424b-bc51-43167258dc2a
  volatile.eth0.host_name: vethecbb346e
  volatile.eth0.hwaddr: 00:16:3e:06:67:f0
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 8b8a1c75-977b-4197-9ad7-507b899432e9
  volatile.uuid.generation: 8b8a1c75-977b-4197-9ad7-507b899432e9
expanded_devices:
  eth0:
    name: eth0
    network: incusbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
last_used_at: 0001-01-01T00:00:00Z
name: s1
profiles:
- default
stateful: false
size: 53760

Plus d’options de complétion des commandes¶

Nous transitionnons lentement d’un script de complétion bash pour incus écrit à la main à une manière beaucoup plus dynamique de gérer la complétion.

Les profils de base pour la complétion des commandes peuvent être obtenus avec :

• incus completion bash
• incus completion fish
• incus completion powershell
• incus completion zsh

Pour les utilisateurs de bash, il est probablement plus intéressant de continuer à utiliser le script écrit à la main pour l’instant, mais nous espérons que les nouveaux profils générés dynamiquement prendront le relais dans une version ou deux.

Prise en charge de plusieurs binaires d’agents pour les machines virtuelles¶

Il est maintenant possible pour Incus de fournir plusieurs versions binaires de l’agent à ses machines virtuelles.

La fonctionnalité est utile dans deux scénarios :

• Gestion de plusieurs systèmes d’exploitation
• Gestion de plusieurs architectures

À ce stade, l’accent est mis sur le second point. Avec cette fonctionnalité, vous pouvez désormais lancer des machines virtuelles 32 bits sur votre système et les faire récupérer une version 32 bits de l’agent.

stgraber@castiana:~$ incus exec debian32 bash
root@debian32:~# uname -a
Linux debian32 6.1.0-17-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) i686 GNU/Linux
root@debian32:~# 
exit
stgraber@castiana:~$ incus exec debian32 bash
root@debian32:~# uname -m
i686
root@debian32:~# mount -t 9p agent /mnt
root@debian32:~# ls -lh /mnt
total 34M
-rwxr-xr-x 1 root root 17M Jan 24 10:10 incus-agent.linux.i686
-rwxr-xr-x 1 root root 18M Jan 24 10:10 incus-agent.linux.x86_64

Prise en charge de virtio-blk en tant qu’io.bus disque¶

Après l’ajout du support NVME dans Incus 0.2, nous étendons ce mécanisme pour proposer virtio-blk comme bus d’E/S disque dans nos machines virtuelles.

Pour l’utiliser, définissez la propriété io.bus du périphérique disk à virtio-blk.

stgraber@dakara:~$ incus launch images:debian/12 demo --vm
Launching demo
stgraber@dakara:~$ incus storage volume create default demo size=5GiB --type=block
Storage volume demo created
stgraber@dakara:~$ incus config device add demo extra disk pool=default source=demo io.bus=virtio-blk
Device extra added to demo
stgraber@dakara:~$ incus exec demo bash
root@demo:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   10G  0 disk 
├─sda1   8:1    0  100M  0 part /boot/efi
└─sda2   8:2    0  3.9G  0 part /
vda    253:0    0    5G  0 disk

Prise en charge du passthrough de périphériques réseau USB dans les VM¶

Lors de l’utilisation de nictype=physical pour une machine virtuelle dont le périphérique réseau parent est connecté sur un bus USB, Incus interprétera désormais en interne la situation comme un passthrough de périphérique USB vers la machine virtuelle.

stgraber@castiana:~$ incus launch images:debian/12 demo --vm
Launching demo
stgraber@castiana:~$ incus config device add demo eth1 nic nictype=physical parent=enx207bd2a0f9eb
Device eth1 added to demo
stgraber@castiana:~$ incus exec demo bash
root@demo:~# apt install usbutils
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libusb-1.0-0
The following NEW packages will be installed:
  libusb-1.0-0 usbutils
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 142 kB of archives.
After this operation, 492 kB of additional disk space will be used.
Do you want to continue? [Y/n]·
Get:1 http://deb.debian.org/debian bookworm/main amd64 libusb-1.0-0 amd64 2:1.0.26-1 [62.6 kB]
Get:2 http://deb.debian.org/debian bookworm/main amd64 usbutils amd64 1:014-1 [79.7 kB]
Fetched 142 kB in 1s (124 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libusb-1.0-0:amd64.
(Reading database ... 20425 files and directories currently installed.)
Preparing to unpack .../libusb-1.0-0_2%3a1.0.26-1_amd64.deb ...
Unpacking libusb-1.0-0:amd64 (2:1.0.26-1) ...
Selecting previously unselected package usbutils.
Preparing to unpack .../usbutils_1%3a014-1_amd64.deb ...
Unpacking usbutils (1:014-1) ...
Setting up libusb-1.0-0:amd64 (2:1.0.26-1) ...
Setting up usbutils (1:014-1) ...
Processing triggers for libc-bin (2.36-9+deb12u3) ...
root@demo:~# lsusb -tv
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 4: Dev 2, If 0, Class=Communications, Driver=cdc_ncm, 5000M
        ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
    |__ Port 4: Dev 2, If 1, Class=CDC Data, Driver=cdc_ncm, 5000M
        ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
root@demo:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:e7:f7:2d brd ff:ff:ff:ff:ff:ff
3: enx207bd2a0f9eb: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 20:7b:d2:a0:f9:eb brd ff:ff:ff:ff:ff:ff

Nouvelles options d’évacuation de cluster (force-stop et stateful-stop)¶

Quelques nouvelles options d’évacuation de cluster ont été ajoutées.

Celles-ci peuvent être sélectionnées pour chaque instance via la clef de configuration cluster.evacuate.

force-stop provoque l’arrêt immédiat de l’instance sans lui donner la possibilité de s’arrêter proprement. Cela n’a de sens que dans les cas où l’instance est effectivement sans état, puisqu’un tel arrêt ne permet pas de stocker un quelconque état sur le disque.

stateful-stop sauvegarde l’état de l’instance sur le disque avant son arrêt. À la restauration de l’instance, son état est également restauré, lui permettant de reprendre les opérations là où elle s’était arrêtée.
Cette option est actuellement principalement destinée aux machines virtuelles, car la préservation de l’état des conteneurs est assez complexe à réaliser.

Configuration de l’arrêt des instances à l’arrêt de l’hôte¶

Une nouvelle clef de configuration pour les instances, boot.host_shutdown_action, a été introduite. Les valeurs acceptées sont :

• stop (comportement d’arrêt classique)
• force-stop (voir ci-dessus)
• stateful-stop (voir ci-dessus)

Cela permet notamment de configurer certaines machines virtuelles de telle sorte que leurs états soient sauvegardés à l’extinction de l’hôte et restaurés à son redémarrage.

Démarrage automatique des instances à leur création¶

Une petite optimisation de notre API permet désormais de démarrer les instances dans la même requête qui sert à leur création, économisant un appel à l’API et simplifiant les interactions par des scripts tiers.

incus launch utilise désormais cette fonctionnalité.

Configuration du nom de l’instance Loki¶

Incus ajoute un ensemble de labels aux événements envoyés à Loki.

Parmi ceux-ci figurent instance et location. Attention, ici, instance correspond au producteur des données envoyées à Loki, pas à une instance Incus.

Jusqu’à présent, les deux labels ne différaient que dans le cas improbable où un serveur aurait transféré un événement provenant d’un autre serveur dans un cluster.

Néanmoins, dans des environnements en cluster, il semble pertinent de pouvoir fournir à Loki le nom des clusters, de telle sorte que l’on puisse filtrer facilement les informations par cluster.

À cette fin, nous avons ajouté une clef de configuration du serveur, loki.instance, qui remplace la valeur du label instance lorsqu’elle est définie.

Le tableau de bord Grafana par défaut a également été mis à jour pour pouvoir filtrer les événements, en considérant que le label instance de Loki correspond au nom du job Prometheus.

Support étendu de la méthode HEAD sur les fichiers¶

La méthode HEAD de l’API de gestion des fichiers d’Incus retourne à présent la taille des fichiers dans l’en-tête Content-Length.

L’intérêt premier de cet ajout est de permettre à des outils se basant sur l’API de gestion des fichiers d’Incus (par exemple, un explorateur de fichiers) d’afficher non seulement les noms et les types des fichiers ordinaires, mais également leurs tailles.

Utilisation de /run/incus pour les données d’exécution¶

Jusqu’à présent, Incus stockait une partie de ses données d’exécution dans ses répertoires de journaux, sous /var/log/incus/. Outre le fait que ce n’était clairement pas le bon emplacement pour ces données, cela causait des problèmes avec les systèmes qui font des rotations agressives de journaux.

Pour résoudre ce problème, Incus 0.5 placera désormais ses données d’exécution dans /run/incus, réservant /var/log/incus aux fichiers de journaux uniquement.

Dans le futur, nous déplacerons probablement une partie des données de /var/lib/incus vers /run/incus.

Liste complète des changements¶

Voici une liste complète de tous les changements apportés par cette version :

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.

Installation du serveur Incus sous Linux¶

Incus est disponible sur la plupart des distributions Linux courantes. Vous trouverez des instructions d’installation détaillées dans notre documentation.

https://linuxcontainers.org/incus/docs/main/installing/

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 est disponible sur Chocolatey pour les utilisateurs de Windows.

https://community.chocolatey.org/packages/incus/0.5

Paquet Winget du client Incus¶

Le client Incus est aussi disponible sur Winget pour les utilisateurs de Windows.

https://winstall.app/apps/LinuxContainers.Incus

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
Un support commercial est disponible sur : https://zabbly.com/incus
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues