Premier conteneur Incus — launch, exec, shell, snapshots, limites — tutoriel 2026

📍 Article principal du sujet : Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine
Pour la vue d’ensemble, lisez d’abord l’article principal qui pose les concepts d’instance, profil, projet et stockage.

Une fois Incus installé sur votre serveur, la prochaine étape consiste à créer votre premier conteneur, à interagir avec, et à comprendre les commandes que vous utiliserez quotidiennement par la suite. Cinq commandes principales — incus launch, incus list, incus exec, incus shell, incus stop/delete — couvrent 80 % des manipulations courantes. Ce tutoriel les explore en profondeur, avec les pièges habituels et les variantes utiles à connaître pour ne pas redécouvrir l’eau chaude au bout d’une semaine.

L’objectif n’est pas seulement de copier-coller les commandes mais de comprendre ce qui se passe sous le capot à chaque étape : où sont stockées les données de l’instance, comment fonctionne le réseau, comment Incus distingue un conteneur d’une VM, et comment utiliser ces connaissances pour exploiter sereinement plusieurs dizaines d’instances sur le même hôte.

Prérequis

• Un serveur Incus 6 LTS opérationnel — voir Installer Incus sur Ubuntu Server avec Zabbly si ce n’est pas encore fait.
• Accès SSH avec un utilisateur dans le groupe incus-admin
• Connexion internet sortante (pour télécharger les images depuis images.linuxcontainers.org)
• Niveau attendu : ligne de commande Linux confortable, notion d’utilisateur/groupe
• Temps estimé : 30 à 45 minutes pour parcourir l’ensemble

Étape 1 — Choisir une image et lancer l’instance

La commande qui crée et démarre une instance en une seule fois s’appelle incus launch. Sa syntaxe minimale prend deux arguments : la source d’image et le nom de l’instance. La source d’image suit la convention distant:nom/version où le préfixe images: désigne le serveur public officiel de Linux Containers.

incus launch images:debian/12 mon-premier
# Creating mon-premier
# Retrieving image: 100% (rootfs)
# Starting mon-premier

Que s’est-il passé concrètement ? Incus a interrogé le serveur d’images officiel, identifié l’image debian/12 la plus récente pour votre architecture (amd64, arm64 ou armhf), l’a téléchargée si elle n’était pas déjà en cache local, l’a copiée dans votre pool de stockage par défaut, a créé une nouvelle instance dérivée, lui a attribué une IP via DHCP sur incusbr0, et l’a démarrée. Le tout en moins de deux minutes la première fois, et en moins de deux secondes les fois suivantes une fois l’image en cache.

Vous pouvez préciser une distribution différente avec la même syntaxe :

incus launch images:ubuntu/24.04 web-srv
incus launch images:alpine/3.19 alpine-test
incus launch images:rockylinux/9 rocky-srv
incus launch images:archlinux arch-test

Pour explorer le catalogue complet, incus image list images: debian filtre par mot-clé. Au moment d’écrire ces lignes, le serveur public propose plus de 600 variantes (combinaisons distribution × version × architecture × variante cloud). La variante cloud est intéressante : elle inclut cloud-init pré-configuré, ce qui permet d’injecter des configurations à la création.

Étape 2 — Explorer la liste des instances

La commande incus list affiche toutes les instances du projet courant avec leur état, leurs adresses IP, leur type (conteneur ou VM) et le nombre de snapshots :

incus list
# +-------------+---------+----------------------+------+-----------+
# | NOM         | ÉTAT    | IPv4                 | TYPE | SNAPSHOTS |
# +-------------+---------+----------------------+------+-----------+
# | mon-premier | RUNNING | 10.124.10.42 (eth0)  | CONT | 0         |
# | web-srv     | RUNNING | 10.124.10.43 (eth0)  | CONT | 0         |
# +-------------+---------+----------------------+------+-----------+

L’IPv4 affichée provient du serveur DHCP intégré au bridge incusbr0. Cette IP est privée, attribuée pour la durée de vie de l’instance, et ne survit pas à un changement de bridge. Pour des cas de production, on remplace souvent ce DHCP par une IP statique fixée dans le profil — voir le tutoriel dédié aux IPs statiques.

Plusieurs filtres sont utiles. incus list -c ns,4 limite l’affichage aux colonnes nom, état et IPv4. incus list --format json sort en JSON pour parsing par script. incus list status=running ne montre que les instances actives. Pour un parc dépassant la dizaine d’instances, ces filtres deviennent essentiels.

Étape 3 — Exécuter une commande dans l’instance

Deux modes existent pour exécuter quelque chose dans une instance : incus exec qui lance une commande non interactive et retourne le résultat, et incus shell qui ouvre un shell interactif. Le premier est l’outil de scripting et d’automatisation, le second est l’outil d’exploration et de débogage.

incus exec mon-premier -- cat /etc/os-release
# PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
# NAME="Debian GNU/Linux"

incus exec mon-premier -- apt update
# Get:1 http://deb.debian.org/debian bookworm InRelease ...

incus exec mon-premier -- apt install -y nginx
# (Reading database ... 14352 files ...)
# Setting up nginx ...

Le double tiret -- sépare les arguments d’incus de ceux de la commande à exécuter. Sans lui, des options comme -y seraient interprétées par incus et provoqueraient une erreur. C’est une convention shell standard mais qui surprend la première fois.

Pour ouvrir un shell interactif :

incus shell mon-premier
# Now in /root inside mon-premier
root@mon-premier:~# ls
root@mon-premier:~# uname -a
Linux mon-premier 6.5.0-x ...
root@mon-premier:~# exit

La commande incus shell est un raccourci pour incus exec mon-premier -- bash ou incus exec mon-premier -- /bin/sh selon la distribution. Vous arrivez par défaut en root dans le conteneur, sans devoir saisir de mot de passe — Incus passe par un canal d’administration interne, pas par SSH. Cela vaut la peine de noter : pour les conteneurs Incus, on n’a généralement pas besoin de configurer un serveur SSH ; on entre par incus shell depuis l’hôte.

Étape 4 — Cycle de vie : start, stop, restart

Une instance peut être dans plusieurs états : running, stopped, frozen, error. La transition entre états se fait par les commandes correspondantes :

incus stop mon-premier        # arrêt propre (envoie SIGTERM puis SIGKILL après timeout)
incus stop --force mon-premier  # arrêt brutal (SIGKILL immédiat)
incus start mon-premier
incus restart mon-premier
incus pause mon-premier       # gel des processus, conserve la RAM
incus resume mon-premier      # reprise après pause

L’arrêt propre donne d’abord 30 secondes aux processus de l’instance pour se fermer correctement (sauvegarder leur état, fermer les connexions). Si un service mal codé ne réagit pas au SIGTERM, l’arrêt force un SIGKILL après le timeout — comportement équivalent à un poweroff brutal sur une machine physique. Pour les instances qui hébergent une base de données, cette différence compte : un PostgreSQL arrêté brutalement doit faire un crash recovery au prochain démarrage, ce qui prend du temps sur de gros datasets.

Pour une instance qui n’a pas vocation à rester active mais qu’on veut conserver, incus pause gèle les processus sans les arrêter — la RAM reste allouée, l’état du système est conservé tel quel, mais aucun cycle CPU n’est consommé. Utile pour des environnements de démo qu’on relance périodiquement sans payer la latence d’un cold start.

Étape 5 — Snapshots et restauration

Avant toute manipulation à risque, le réflexe à acquérir est de prendre un snapshot. Sur un pool de stockage ZFS ou Btrfs, l’opération est instantanée et n’occupe quasiment pas d’espace tant que les données ne divergent pas.

incus snapshot create mon-premier avant-modif
incus snapshot list mon-premier
# +-------------+----------------------+----------+----------+
# | NOM         | DATE DE CRÉATION     | DATE EXP | EN MARCHE|
# +-------------+----------------------+----------+----------+
# | avant-modif | 2026/04/29 09:15 UTC |          | YES      |
# +-------------+----------------------+----------+----------+

# ... vous faites des bêtises dans le conteneur ...

incus snapshot restore mon-premier avant-modif
# L'état du conteneur revient à l'instant du snapshot

Le snapshot capture à la fois le système de fichiers ET l’état d’exécution si l’instance tournait au moment de la prise (option --stateful requise et image compatible). Pour la grande majorité des cas, on prend des snapshots cold (instance arrêtée ou snapshot du seul filesystem), suffisants pour reverter une mauvaise configuration ou un upgrade qui s’est mal passé.

Une bonne pratique consiste à automatiser un snapshot quotidien des instances de production. Une ligne dans le cron de l’hôte fait l’affaire :

# /etc/cron.d/incus-snapshots
0 2 * * * root incus snapshot create web-srv auto-$(date +\%Y\%m\%d) --reuse

Combiné à une politique d’expiration (incus config set web-srv snapshots.expiry 7d), vous obtenez une rotation automatique de snapshots quotidiens conservés sept jours, sans script externe ni cron supplémentaire à maintenir.

Étape 6 — Configurer les ressources d’une instance

Par défaut, un conteneur Incus n’a aucune limite de CPU ou de RAM — il peut consommer tout ce que l’hôte lui laisse. Pour des environnements partagés, ce n’est pas viable. Trois directives de configuration suffisent à border une instance proprement :

incus config set mon-premier limits.cpu 2
incus config set mon-premier limits.memory 1GB
incus config set mon-premier limits.memory.swap false

Ces limites sont appliquées immédiatement via les cgroups Linux : le conteneur voit deux processeurs maximum dans /proc/cpuinfo, ne peut pas dépasser 1 Go de RAM, et n’a pas accès au swap. Si un processus dans le conteneur tente d’allouer plus de RAM, le OOM killer s’active et tue ce processus, sans toucher aux autres instances ni à l’hôte. Pour visualiser ces limites :

incus config show mon-premier
# architecture: x86_64
# config:
#   limits.cpu: "2"
#   limits.memory: 1GB
#   limits.memory.swap: "false"
#   image.architecture: amd64
#   image.description: Debian bookworm amd64
# devices: {}
# ephemeral: false
# profiles:
# - default

Le YAML de configuration affiche tous les paramètres effectifs, y compris ceux hérités du profil default. La section devices est vide ici parce que les périphériques (disque, réseau) sont définis au niveau du profil et non de l’instance — c’est ce qui permet de réutiliser un même profil pour plusieurs instances.

Étape 7 — Supprimer une instance

La suppression définitive d’une instance se fait avec incus delete. Par sécurité, l’instance doit être arrêtée sauf si vous passez --force. Ce qui suit la suppression : son rootfs est libéré du pool de stockage, ses snapshots sont supprimés, son adresse IP est rendue au pool DHCP, et son nom redevient disponible.

incus stop mon-premier
incus delete mon-premier
# OU en une commande
incus delete --force mon-premier

Pour les instances importantes, on peut les protéger contre la suppression accidentelle :

incus config set web-prod security.protection.delete true

Avec cette protection, toute tentative de delete renvoie une erreur explicite. Pour réellement supprimer, il faut d’abord désactiver la protection. C’est un filet de sécurité simple qui évite la catastrophe d’un tab tab tab mal placé sur la commande de suppression.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Sur un VPS depuis Dakar ou Abidjan, le téléchargement initial de l’image Debian (environ 100 Mo) prend une à deux minutes. Pour démarrer rapidement plusieurs instances de la même base, lancez un premier conteneur, puis dupliquez-le avec incus copy au lieu de re-télécharger l’image — la copie est instantanée sur ZFS ou Btrfs grâce au copy-on-write. Sur un parc de PME avec dix sites WordPress, on lance ainsi un conteneur modèle bien configuré, puis on en clone autant que nécessaire en quelques secondes.

Côté budget, un VPS 4 Go RAM sur Hostinger tient confortablement six à huit conteneurs Debian/Alpine bien dimensionnés (limits.memory à 512 Mo chacun). C’est largement suffisant pour servir l’infrastructure d’une petite agence : un conteneur par projet client, une isolation totale, et un coût total inférieur à 5 USD par mois.

Tutoriels frères

• Installer Incus 6 LTS sur Ubuntu Server avec Zabbly — l’étape précédente.
• Snapshots et restauration d’instance Incus — pour aller plus loin sur les backups.
• Profils Incus : créer, modifier, appliquer — pour scaler quand vous avez plusieurs instances similaires.

Pour aller plus loin

• 🔝 Retour à l’article principal sur Incus
• Documentation officielle des instances
• Référence complète des options d’instance
• Pour pratiquer : Hostinger Cloud VPS

FAQ

Différence entre incus init et incus launch ?
incus init crée l’instance sans la démarrer, incus launch crée et démarre en une seule commande. init est utile quand on veut configurer l’instance avant son premier boot (limites, périphériques, profils).

Comment renommer une instance ?
incus rename ancien-nom nouveau-nom, l’instance doit être arrêtée. La commande met à jour la config et le nom du dataset de stockage en une opération atomique.

Peut-on copier une instance entre serveurs Incus ?
Oui. incus copy serveurA:web-srv serveurB:web-srv transfère l’instance et ses snapshots via une connexion TLS authentifiée. Les serveurs doivent se faire confiance mutuellement (étape de trust pin).

Le conteneur survit à un reboot de l’hôte ?
Par défaut oui : Incus enregistre l’état souhaité (started/stopped) et restaure l’instance dans son état au démarrage du démon. Pour qu’une instance ne redémarre pas automatiquement après reboot : incus config set instance boot.autostart false.

Comment voir les logs de boot d’une instance ?
incus console mon-premier --show-log affiche le journal de la dernière session de boot. Pour les conteneurs avec systemd, incus exec mon-premier -- journalctl -b donne la même chose depuis l’intérieur.