Container Machines : un environnement Linux persistant sur Mac

L’outil container d’Apple a atteint la version 1.0 pendant la semaine de la WWDC, et sa fonctionnalité phare comble une lacune que les développeurs Mac contournent depuis des années : container machine, un environnement Linux persistant qui se comporte comme une partie intégrante de macOS.² La session WWDC qui le présente résume l’argumentaire en une phrase : « Une Container machine est rapide et légère, comme un conteneur, et persistante comme une machine virtuelle. »¹ Vos dépôts et vos dotfiles sont disponibles des deux côtés, l’utilisateur connecté correspond à votre compte Mac, et la machine conserve son système de fichiers entre les sessions : la chaîne d’outils Linux que vous avez configurée mardi est donc toujours là vendredi.³

Session 389, « Discover container machines ».

En bref

• container machine est livré dans container 1.0.0, publié sur GitHub pendant la semaine de la WWDC. Il fournit « des environnements Linux de longue durée avec une intégration étroite à l’hôte » par-dessus le framework Containerization qu’Apple a rendu open source à la WWDC 2025.²
• Là où les conteneurs sont « modélisés d’après une application », une container machine est « modélisée d’après un environnement Linux » : elle exécute le propre système d’init de l’image, conserve les modifications du système de fichiers et est créée à partir d’images OCI standard.³
• L’intégration à l’hôte est l’élément différenciateur. L’utilisateur connecté Linux correspond à votre compte Mac avec un sudo sans mot de passe et votre répertoire personnel est monté à l’intérieur de la machine,⁴ et un shell interactif vous dépose dans le même répertoire de travail que celui d’où vous veniez sur macOS.¹
• L’ensemble complet des sous-commandes est create, run, list, inspect, set, set-default, logs, stop et delete, avec m comme alias court.⁴
• La version 1.0 introduit également un changement incompatible qu’il vaut la peine de connaître avant de mettre à niveau : un fichier de configuration TOML situé à ~/.config/container/config.toml remplace les anciennes propriétés système adossées à UserDefaults, et les sous-commandes container system property ont disparu.²

Un environnement Linux, pas un bac à sable applicatif

La documentation d’Apple trace la frontière avec précision : « Les conteneurs sont généralement modélisés d’après une application. Une container machine est modélisée d’après un environnement Linux. »³ La distinction apparaît dans trois comportements. Une container machine exécute le propre système d’init de l’image, tel que systemd ou openrc, ce qui vous permet d’enregistrer des services de longue durée et de tester votre application sous un véritable superviseur de processus : systemctl start postgresql fonctionne comme sur une machine Linux.³ Elle conserve les modifications, de sorte que les outils que vous installez s’accumulent au fil du temps au lieu de disparaître avec le processus.¹ Et elle démarre à partir des mêmes images OCI que celles utilisées par les conteneurs : une image que vous construisez avec container build sert donc aussi de point de départ pour une machine.¹

La pull request qui a introduit la fonctionnalité énonce clairement la motivation : container exécute chaque charge de travail dans une VM éphémère, de sorte qu’avant la version 1.0 il n’existait aucun moyen intégré de conserver un environnement Linux persistant dans lequel vous pourriez vous connecter et travailler.⁴ En dessous, chaque container machine reçoit toujours le traitement Containerization : sa propre machine virtuelle légère, avec une isolation basée sur la VM et les temps de démarrage inférieurs à la seconde autour desquels le framework a été conçu.¹

La session présente les objectifs de conception en termes de flux de travail : le passage entre macOS et Linux doit être facile, les environnements doivent être rapides à créer, et « la création rapide permet à plusieurs projets de disposer de leur propre environnement dédié, sans craindre de dépendances ou de chaînes d’outils conflictuelles ».¹ Une machine par distribution cible est un modèle voulu, et chaque machine voit le même répertoire personnel et les mêmes dotfiles de votre Mac.³

La boucle : éditer sur le Mac, compiler dans Linux

La démo de la session est un serveur web Vapor, et le flux de travail qu’elle parcourt est tout l’intérêt de la chose.¹ Le projet est édité dans Xcode sur macOS. La compilation et l’exécution se déroulent à l’intérieur d’une container machine sur laquelle la chaîne d’outils Swift est installée. Safari sur le Mac charge le serveur en cours d’exécution par son adresse IP et son port. Lorsque le présentateur réexporte une icône d’application depuis Icon Composer sur le Mac et écrase le fichier, un rafraîchissement du navigateur affiche le nouvel élément sans étape de copie, car la machine et le Mac partagent les mêmes fichiers.¹

La documentation d’Apple généralise le modèle : votre dépôt réside dans $HOME sur macOS et est monté à l’intérieur de la machine, si bien que l’outillage natif macOS (profileurs, navigateurs, débogueurs graphiques) voit les mêmes fichiers que l’environnement Linux. Comme le formule la documentation, il n’y a pas d’étape de copie entre « je l’ai compilé » et « je l’inspecte ».³

L’intégration à l’hôte va plus loin qu’un simple montage partagé. La machine crée automatiquement un utilisateur Linux correspondant à votre nom d’utilisateur Mac, lui accorde un sudo sans mot de passe et reflète votre répertoire de travail courant, de sorte que whoami et pwd répondent la même chose à l’intérieur comme à l’extérieur.¹ La seule commande qui change de réponse est uname : Darwin sur le Mac, Linux dans la machine.¹

Un point de friction du premier jour vaut la peine d’être connu avant d’y être confronté : une container machine dispose d’un réseau isolé, et la session est explicite sur le fait qu’un serveur situé à l’intérieur doit écouter sur l’interface externe avant qu’un navigateur sur le Mac ne puisse l’atteindre.¹ La démo gère cela de la manière dont vous le ferez : container machine list affiche l’adresse IP de chaque machine à côté de son nom et de ses ressources, la configuration du serveur se lie à cette adresse, et Safari atteint l’application à l’adresse IP et au port de la machine.¹ Prévoyez l’étape de l’adresse IP dans tout flux de travail qui sert du trafic depuis la machine.

Les commandes

Le démarrage rapide tient en quatre lignes :³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run joue un double rôle : avec une commande, il l’exécute une fois puis se termine ; sans commande, il ouvre un shell interactif ; et si la machine est arrêtée, il la démarre d’abord.³ Une machine par défaut supprime l’option -n de chaque appel :

container machine set-default dev
container machine run                     # operates on dev

La gestion repose sur les verbes habituels : ls, inspect, logs, stop et rm, où la suppression d’une machine supprime aussi son stockage persistant.³ Les ressources sont ajustables après la création avec container machine set -n dev cpus=4 memory=8G, prenant effet au prochain arrêt et démarrage ; la mémoire est par défaut la moitié de la mémoire de l’hôte, et le montage du répertoire personnel peut être rw (la valeur par défaut), ro ou none.³ Chaque commande accepte également m comme alias, si bien que m run et m ls fonctionnent.⁴

Apportez votre propre image de machine

Toute image Linux qui inclut /sbin/init fonctionne comme une container machine.³ La documentation d’Apple fournit un Dockerfile complet qui transforme ubuntu:24.04 en une image de machine dotée de systemd, d’OpenSSH et d’outils en ligne de commande courants, puis masque les unités systemd qui n’ont aucun sens à l’intérieur d’une VM légère.³ Vous la construisez avec container build et passez le tag à container machine create.

Le provisionnement dispose d’une échappatoire. Par défaut, container exécute un script de configuration intégré au premier démarrage pour créer l’utilisateur correspondant. Un exécutable situé à /etc/machine/create-user.sh dans l’image remplace ce script ; il s’exécute une fois, en tant que root, au premier démarrage, avec CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME et CONTAINER_MACHINE_ID définis, de sorte qu’une organisation peut encoder sa propre configuration utilisateur dans une image de base partagée.³

Le reste de la version 1.0, y compris le changement incompatible

La fonctionnalité de machine est en tête d’affiche de cette version, mais la 1.0 apporte des changements qui affectent les utilisateurs existants.²

Le changement incompatible concerne la configuration. Un fichier TOML remplace les propriétés système adossées à UserDefaults, et les sous-commandes container system property get et set sont supprimées.² Le service lit ~/.config/container/config.toml au démarrage selon une priorité au premier correspondant (votre fichier utilisateur, puis un fichier facultatif livré avec l’installation du paquet, puis les valeurs par défaut codées en dur), et les modifications nécessitent un redémarrage du service pour prendre effet.⁶

Les ajouts de confort : une commande container cp pour copier des fichiers, une option --stop-signal sur container run, et une sortie structurée nettoyée (JSON, YAML, TOML) pour les commandes ls et inspect à travers les conteneurs, les images, les réseaux et les volumes.² Le réseau bénéficie d’une correction de justesse qui utilise les connexions XPC comme des baux pour mettre fin aux fuites d’adresses IP.² La compatibilité avec les API XPC version 0 est supprimée, une API versionnée étant promise dans une version ultérieure.²

Les prérequis restent stables par rapport à la branche 0.x : un Mac à processeur Apple silicon, exécutant macOS 26. Les mainteneurs indiquent qu’ils ne traiteront généralement pas les problèmes qui ne peuvent pas être reproduits sur macOS 26.⁵

Pourquoi les flux de travail d’agents devraient s’y intéresser

Une lecture depuis ma position, et non une affirmation d’Apple : une container machine a la forme d’environnement que recherchent les agents de codage. Les agents qui s’exécutent sur un Mac ont besoin d’un endroit où exécuter des compilations, lancer des serveurs et installer des dépendances sans toucher à l’hôte : rapide à créer, isolé par une véritable frontière de VM, suffisamment persistant pour qu’une chaîne d’outils installée lors d’une session survive jusqu’à la suivante. Jusqu’à présent, les réponses du Mac étaient des VM de type Docker Desktop (lourdes, un seul grand environnement partagé) ou des conteneurs éphémères (isolés mais sans mémoire). Une machine par projet, créée à partir d’une image OCI versionnée, avec le dépôt monté à l’intérieur et un sudo sans mot de passe, correspond à la façon dont les bacs à sable d’agents fonctionnent déjà sur les hôtes Linux.

La même propriété sert le travail multiplateforme classique. Swift côté serveur en est le bénéficiaire évident : la démo de la session est Vapor, et le framework Foundation Models passe en open source cet été avec une prise en charge de Linux, si bien que l’environnement de test pour « est-ce que mon code Swift s’exécute sur Ubuntu » se trouve désormais à un container machine create de distance. La comparaison qui viendra à l’esprit de quiconque a utilisé Windows est WSL, et la direction de l’intégration est la même : un véritable noyau Linux à portée de shell, avec vos fichiers visibles des deux côtés. La version d’Apple arrive avec un flux de travail basé sur les images déjà intégré.

FAQ

Qu’est-ce qu’une container machine ?

Une container machine est un environnement Linux persistant sur macOS, livré en tant que fonctionnalité de l’outil open source container d’Apple à partir de la version 1.0.0.² Elle s’exécute dans sa propre machine virtuelle légère via le framework Containerization, démarre à partir d’images OCI standard, exécute le système d’init de l’image et conserve les modifications du système de fichiers entre les sessions.¹ Les intégrations à l’hôte montent votre répertoire personnel à l’intérieur, font correspondre l’utilisateur Linux à votre compte Mac avec un sudo sans mot de passe et maintiennent la cohérence de votre répertoire de travail de part et d’autre de la frontière.⁴

En quoi est-ce différent d’un conteneur classique ?

La documentation d’Apple le résume en une ligne : les conteneurs sont « modélisés d’après une application », une container machine est « modélisée d’après un environnement Linux ».³ Une charge de travail container run classique est éphémère et centrée sur le processus. Une machine est dotée d’un état, exécute systemd ou openrc et est destinée à être réutilisée au fil du temps, comme une VM avec la vitesse de création d’un conteneur.¹

Que requiert-elle ?

Un Mac à processeur Apple silicon exécutant macOS 26, les mêmes prérequis que l’outil container en général.⁵ L’outil est open source sur GitHub, écrit en Swift.⁵

La mise à niveau vers la 1.0 casse-t-elle quelque chose ?

Une seule chose : la configuration système passe de propriétés adossées à UserDefaults à un fichier TOML situé à ~/.config/container/config.toml, et les sous-commandes container system property get/set sont supprimées.² Les notes de version de la 1.0 renvoient à un tutoriel pour la migration.² La compatibilité avec l’API XPC version 0 est également supprimée, ce qui importe si vous avez développé des clients basés sur cette API.²

Les container machines s’inscrivent dans la même histoire que cette WWDC n’a cessé de raconter : le Mac comme un véritable foyer pour le développement multiplateforme et agentique. Exécuter une IA agentique sur le Mac avec MLX couvre la partie « service de modèles » de cette histoire, et Quoi de neuf dans Swift (2026) couvre le travail sur le langage qui fait de Swift-sur-Linux une cible de premier ordre. Le hub complet de la série est la Série Écosystème Apple.

Références