Nspawn 3.0 apporte la compatibilité avec l'API Docker aux conteneurs systemd-nspawn

Le projet Nspawn a publié la version 3.0, une mise à jour majeure qui ajoute une API Engine compatible avec Docker pour la gestion des conteneurs systemd-nspawn. Publiée le 7 novembre 2026, cette version permet aux développeurs et aux administrateurs système d'utiliser les outils Docker familiers, tels que l'interface en ligne de commande docker et GitLab Runner, pour interagir avec les machines nspawn. Cette initiative comble le fossé entre l'isolation légère basée sur systemd et le vaste écosystème des outils d'orchestration compatibles avec Docker.

Ce qu'il s'est passé

Nspawn 3.0 introduit un nouveau socket d'API situé dans /run/nspawn/api.sock sur le système hôte. Contrairement aux versions précédentes où le socket à l'intérieur d'une machine était en lecture seule, cette mise à jour active des capacités de gestion complètes lorsqu'il est monté en lecture-écriture. Les utilisateurs peuvent désormais créer, démarrer, exécuter des commandes dans et supprimer des conteneurs, ainsi que tirer des images et gérer les volumes et réseaux via l'API. Le service est conçu pour être compatible avec les clients Docker existants, permettant aux équipes de tirer parti de leurs workflows actuels sans migrer entièrement vers un autre runtime de conteneur.

La publication inclut également des mises à jour immédiates dans les versions 3.1.0 et 3.2.0. La version 3.1.0 ajoute la prise en charge de l'accès dynamique aux périphériques via --device-cgroup-rule, utile pour les tâches matérielles telles que le flashage de périphériques USB. La version 3.2.0 standardise la manière dont les noms de machines et d'images sont résolus dans les commandes, garantissant la cohérence que les utilisateurs fassent référence à une image par son nom local ou sa référence complète. Ces itérations rapides répondent aux premiers retours et affinent l'expérience utilisateur pour ceux adoptant la nouvelle API.

Détails clés

• Accès au socket d'API : Le socket hôte /run/nspawn/api.sock prend en charge les opérations en lecture-écriture pour la gestion complète du cycle de vie des conteneurs, tandis que les montages en lecture seule limitent les actions aux journaux et à l'inspection.
• Changements cassants : Les enregistrements tirés ou construits mais jamais exécutés sont désormais classés comme des images plutôt que comme des conteneurs, affectant leur apparence dans les commandes list et prune.
• Rapport d'erreurs : Les méthodes échouées renvoient désormais des noms d'erreur spécifiques sous org.nspawn.Error, tels que NotAuthorized, NoSuchMachine et InUse, fournissant des informations de débogage plus claires.
• Variables d'environnement : Les variables peuvent désormais contenir des sauts de ligne, et les variables non définies passées avec -e VAR sont omises plutôt que de provoquer des erreurs, améliorant la compatibilité avec les configurations complexes.
• Améliorations de la journalisation : La mise à jour empêche la perte de journaux due aux limites de débit de journald en définissant un intervalle en microsecondes avec une capacité de rafale élevée, garantissant que toutes les lignes de sortie sont capturées.
• Lacunes connues : Certaines fonctionnalités Docker comme le mode swarm, les plugins et la construction d'images via l'API ne sont pas prises en charge et renvoient des erreurs 501 ; les utilisateurs doivent utiliser nspawn build à la place.

Contexte

Systemd-nspawn est une technologie de conteneurisation légère intégrée au système d'init systemd, souvent utilisée pour exécuter des services isolés ou des environnements de test sans la surcharge des machines virtuelles complètes. Historiquement, la gestion des conteneurs nspawn nécessitait des outils en ligne de commande spécifiques ou des scripts personnalisés, ce qui créait des frictions pour les équipes habituées à l'écosystème Docker. L'API Engine de Docker est devenue un standard de facto pour l'orchestration de conteneurs, soutenue par une vaste gamme d'outils tiers, de pipelines CI/CD et de solutions de surveillance.

En implémentant une API compatible avec Docker, Nspawn 3.0 permet à ces outils existants de communiquer avec les machines nspawn comme s'il s'agissait de conteneurs Docker. Cette couche de compatibilité ne remplace pas la commande native nspawn, mais offre une interface alternative pour l'automatisation et l'intégration. Elle permet aux organisations de conserver la sécurité et la simplicité des conteneurs basés sur systemd tout en utilisant le riche paysage d'outils développés autour de Docker.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, cette version réduit considérablement la charge opérationnelle liée à la maintenance de scripts personnalisés de gestion de conteneurs. Les ingénieurs peuvent désormais utiliser les commandes Docker standard pour inspecter les journaux, gérer les volumes et déployer des services dans les environnements nspawn. Cela est particulièrement précieux pour les pipelines CI/CD, tels que ceux utilisant GitLab Runner, qui peuvent désormais cibler directement les machines nspawn en utilisant leur executor Docker. Cette compatibilité simplifie les chemins de migration pour les projets souhaitant tirer parti des fonctionnalités d'isolation de systemd sans abandonner leur infrastructure d'automatisation existante.

Cependant, l'introduction de l'accès API en lecture-écriture nécessite une réflexion prudente sur la sécurité. Puisque root à l'intérieur d'une machine avec un socket monté en lecture-écriture peut contrôler d'autres machines et voir les variables d'environnement, une configuration appropriée est critique. Les équipes doivent s'assurer que seuls les services fiables ont un accès en écriture au socket d'API, tandis que les montages en lecture seule doivent être utilisés pour les outils de surveillance comme Traefik ou Dozzle. Comprendre ces permissions est essentiel pour maintenir les frontières de sécurité qui font de nspawn une option attrayante pour l'auto-hébergement.

Ce que vous pouvez faire

• Évaluer la compatibilité : Testez vos outils et scripts basés sur Docker existants contre l'API Nspawn 3.0 pour identifier les fonctionnalités non prises en charge, telles que le mode swarm ou la construction d'images.
• Sécuriser l'accès API : Configurez soigneusement les montages de sockets, en utilisant des permissions en lecture seule pour les outils de surveillance et en restreignant l'accès en lecture-écriture uniquement aux services de gestion fiables.
• Mettre à jour les pipelines CI : Si vous utilisez GitLab Runner ou des outils similaires, configurez-les pour utiliser le socket d'API Nspawn afin de tirer parti de systemd-nspawn pour l'exécution des jobs.
• Vérifier les paramètres de journalisation : Assurez-vous que votre infrastructure de journalisation peut gérer le volume accru de journaux désormais capturés sans limitation de débit de journald.
• Vérifier les exigences de version : Assurez-vous que votre système hôte répond aux exigences de Nspawn 3.0 et envisagez de passer à la version 3.2.0 pour une meilleure cohérence de résolution des noms.
• Surveiller les lacunes connues : Évitez de compter sur les fonctionnalités de l'API Docker non prises en charge comme la gestion des plugins ou l'exportation de conteneurs, et utilisez les commandes natives nspawn pour ces tâches à la place.