Incus : quand Docker fait plus mal que bien

J’ai utilisé Docker pendant plusieurs année. Puis j’ai vue les docker-compose.yml de 200 lignes, des volumes qui partent en couilles, des images qui pèsent 2 Go pour tourner nginx, les problèmes de sécurité, la difficultée du hardening. J’ai alors migré sur podman, que j’utilise encore majoritairement (j’ai un post la dessus).

Et il y a quelques mois j’ai découvert Incus. C’est un fork communautaire de LXD, maintenu par les gars qui l’ont créé. Il fait tout ce que Docker fait pas : system containers, VMs, snapshots ZFS, clustering, GPU passthrough. Et il le fait sous une seule commande.

Son idée principal, package non pas un process mais un service avec tout les process nécéssaire.

Lexique

C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• Incus: runtime de system containers et VMs, fork communautaire de LXD. Écrit en Go, Apache 2.0. Daemon incusd, CLI incus.
• System container: conteneur qui simule un OS complet — init system, systemd, cron, journald, multi-processus. Contrairement aux application containers de Docker.
• Application container: conteneur qui exécute un seul processus. C’est le modèle Docker.
• VM (QEMU/KVM): machine virtuelle avec son propre kernel. Incus les gère via --vm.
• OCI (Open Container Initiative): standard d’images conteneurs. Incus supporte nativement les images Docker/OCI depuis juillet 2024.
• Profile: configuration réutilisable (GPU, réseau, stockage) applicable à plusieurs instances.
• Instance: terme générique pour un container ou une VM chez Incus.
• ZFS: filesystem copy-on-write. Snapshots instantanés, zero cost until divergence.
• LXC: Linux Containers — le underlying technology des system containers. Incus est le manager au-dessus.

Il fait quoi de différent ?

Docker fait des application containers. Un container égal un processus. Tu veux tourner nginx + php-fpm + postgres ? Tu as besoin de 3 containers, d’un réseau overlay, de Docker Compose, et de volume mounts pour que les données persistent.

Incus fait des system containers. Un container égal un OS complet: systemd, cron, ssh, apt, journald — tout fonctionne. Tu veux tourner nginx + php-fpm + postgres ? Tu les mets dans le même container, tu apt install, et c’est parti. Comme un serveur. Mais léger.

Et Incus gère aussi des VMs. En une commande. --vm et tu as une machine virtuelle QEMU/KVM avec son propre kernel. Windows, BSD, n’importe quoi. La même interface pour les containers et les VMs.

Et surtout : Incus supporte nativement les images OCI. Docker Hub, GHCR, n’importe quelle registre OCI. Tu peux lancer une image Docker avec incus launch docker.io/nginx web. C’est tout.

L’installation

0# Debian 13+ / Ubuntu 24.04+
1$ sudo apt install incus
2
3# Ou via Zabbly (recommandé pour Ubuntu 22.04/24.04)
4$ sudo apt install zabbly-release
5$ sudo apt install incus
6
7# Initialiser
8$ sudo incus admin init

Pas de Snap. Pas de daemon Docker qui tourne en root. Pas de Docker Desktop avec sa VM Linux dans un macOS. Juste un package et un daemon. C’est tout ce qu’il te faut.

Pour les VMs, il te faut aussi QEMU :

0# Si tu veux tourner des VMs
1$ sudo apt install qemu-system

Et vérifie que ton CPU supporte la virtualisation :

0$ grep -E 'vmx|svm' /proc/cpuinfo
1# vmx (Intel) ou svm (AMD) = tu es bon

Les system containers — nouvelle révolution?

C’est là que Incus brille par rapport à Docker. Un system container, c’est un OS complet. Tu peux faire tout ce que tu ferais sur un serveur.

 0# Lancer un container Debian complet
 1$ incus launch images:debian/12 my-server
 2
 3# Shell dedans
 4$ incus exec my-server bash
 5root@my-server:~#
 6
 7# Installer des trucs
 8root@my-server:~# apt update && apt install nginx postgresql
 9
10# Systemd fonctionne
11root@my-server:~# systemctl enable --now nginx
12
13# Cron fonctionne
14root@my-server:~# crontab -e
15
16# SSH fonctionne
17root@my-server:~# systemctl enable --now ssh
18
19# Journald fonctionne
20root@my-server:~# journalctl -u nginx -f

Tu peux tout faire. SSH, cron, apt, systemctl. C’est un serveur léger. Pas un processus en cage.

Et la performance ? Un container Incus pèse 20 MB de RAM. Un VM pèse 256 MB+. Un container Docker ? Il est éphémère — il crashe, il disparaît. Lui, il est persistant. Tu l’arrêtes, tu le redémarres, tout est là.

Les VMs en une commande

 0# VM Ubuntu
 1$ incus launch images:ubuntu/24.04 ubuntu-vm --vm
 2
 3# VM Windows
 4$ incus launch images:windows/11 win-desktop --vm
 5
 6# VM avec GPU pour du ML
 7$ incus launch images:ubuntu/24.04 ml-box --vm \
 8    -c limits.cpu=16 \
 9    -c limits.memory=64GiB \
10    --device gpu,pci=0000:01:00.0

Le seul flag qui change : --vm. Même interface. Même CLI. incus list montre les containers ET les VMs. incus shell marche sur les deux. incus stop marche sur les deux.

C’est comme Docker Desktop mais en mieux. Pas de VM dans une VM. Pas de Snap. Pas de licence payante. Juste du QEMU/KVM natif.

Les images OCI — Docker Hub natif

Depuis juillet 2024, Incus supporte nativement les images OCI. Docker Hub, GHCR, n’importe quelle registre.

0# Lancer une image Docker directement
1$ incus launch docker.io/nginx web
2
3# Lancer PostgreSQL
4$ incus launch docker.io/postgres:16 pg-db
5
6# Lister les images disponibles
7$ incus image list images: alias=

C’est la fin du débat “Docker ou Incus”. Tu peux utiliser les deux. Les images Docker tournent sur Incus. Et si tu as besoin de Docker (pour CI/CD, pour des images spécifiques), tu peux le tourner à l’intérieur d’un container Incus :

0# Docker inside Incus
1$ incus launch images:debian/12 docker-box \
2    -c security.nesting=true \
3    -c security.syscalls.intercept.mknod=true \
4    -c security.syscalls.intercept.setxattr=true
5$ incus exec docker-box bash
6# docker run nginx  ← ça marche

Tu gardes le meilleur des deux mondes. Incus pour les system containers, Docker pour les application containers si besoin.

Les snapshots ZFS — la feature qui tue

C’est LE feature qui m’a convaincu. ZFS snapshots chez Incus, c’est :

• Instantané — pas de copie, pas de downtime
• Zero cost — 0 MB jusqu’à ce que tu modifies des données
• Rollback en 2 secondes — incus restore et c’est fini

 0# Snapshot avant un upgrade
 1$ incus snapshot my-server pre-upgrade
 2
 3# Lister les snapshots
 4$ incus info my-server | grep snap
 5
 6# Rollback si ça pète
 7$ incus restore my-server pre-upgrade
 8
 9# Snapshot d'un VM
10$ incus snapshot win-desktop pre-patch

En Docker ? Pas de snapshot. Tu utilises des volumes, des bind mounts, des images commitées. Tu veux rollback ? Tu détruis le container et tu le recrées. Si les données sont sur un volume, tu pries pour que ça marche.

Avec Incus + ZFS, tu snapshot avant chaque upgrade, chaque config change, chaque truc risqué. Si ça pète, tu rollback en 2 secondes. Pas de perte de données. Pas de downtime. C’est comme un Time Machine pour tes containers.

Les profiles — la config réutilisable

 0# Créer un profile avec GPU
 1$ incus profile create gpu-passthrough
 2$ incus profile set gpu-passthrough \
 3    --device gpu,pci=0000:01:00.0
 4
 5# Appliquer à un container
 6$ incus launch images:ubuntu/24.04 ml-box \
 7    --profile default \
 8    --profile gpu-passthrough
 9
10# Ou ajouter après coup
11$ incus profile add my-server gpu-passthrough

Profiles = config réutilisable. GPU, réseau, stockage, whatever. Tu crées un profile, tu l’appliques à 10 containers. Docker n’a rien de comparable.

Le clustering — multi-host natif

 0# Node 1 : init cluster
 1$ incus admin init
 2
 3# Node 2 : rejoindre le cluster
 4$ incus cluster join node1:8443
 5
 6# Lister les nodes
 7$ incus cluster list
 8
 9# Déployer sur le cluster
10$ incus launch images:ubuntu/24.04 web --target node2

Clustering intégré. Pas de Kubernetes. Pas de Swarm. Juste incus. Pour un homelab, c’est parfait. Tu as 3 serveurs ? Tu les mets en cluster et tu déploies sur le bon node.

Docker vs Incus — le comparatif

Les commandes essentielles

 0# Lancer un container
 1$ incus launch images:debian/12 web
 2
 3# Lancer une VM
 4$ incus launch images:ubuntu/24.04 vm --vm
 5
 6# Lister
 7$ incus list
 8
 9# Shell
10$ incus shell web
11
12# Arrêter / Supprimer
13$ incus stop web
14$ incus delete -f web
15
16# Snapshot
17$ incus snapshot web pre-upgrade
18
19# Rollback
20$ incus restore web pre-upgrade
21
22# Copier des fichiers
23$ incus file push index.html web/var/www/html/
24
25# Voir les logs
26$ incus info --show-log web
27
28# Info détaillée
29$ incus info web

S’il reprend pas l’interface Docker, comme podman, on retrouve les même commandes. La courbe d’apprentissage est minimale.

Les limites

Le projet est encore jeune, voici quelques trade-offs:

• Écosystème plus petit — Moins de tutos, moins de réponses Stack Overflow. Mais les images Docker tournent dessus, donc c’est moins grave.
• Pas de Docker Compose — Pas de docker-compose.yml. Tu utilises systemd à la place. C’est différent, et c’est mieux!
• Clustering plus complexe — C’est plus simple que Kubernetes, mais ça reste du clustering. Commence simple (1 node).
• VM performance — KVM = ~95-98% native. Suffisant pour la plupart des use cases, mais pas pour du HPC.

Mot de la fin

L’idée principal d’Incus c’est de simplifier les run-time, parckager par service et non par process, le tout en utilisant les outils utilisés tous les jours pour les VM linux pour assurer la stabilité du run.

Pour ma part je m’en sers des que j’ai envie de tester des runtime avec des droits beaucoup plus limités, tout en gardant toutes les capacité d’un full linux (dont la gestion des backup, snapshots, etc).

See ya space-cowboy!

Prompt pour générer l’image de l’article

A minimalist illustration of a digital anvil (cumulonimbus incus cloud shape) splitting apart two concepts: on the left, a tangled mess of Docker container icons, compose files, and fragile ephemeral boxes falling apart; on the right, clean solid system containers with systemd gears, ZFS snapshot clocks, and QEMU VM shields standing strong. The anvil has a subtle teal glow. Behind it, a clean workflow line flows from "launch" to "snapshot" to "restore" without obstacles. Dark navy background (#0d1117). Style: clean flat vector, Japanese ink wash influence, tech blog header aesthetic. No text, no logos, no watermarks. 16:9 aspect ratio.