apple/container, ajout de la fonctionnalité Container Machine

• Outil permettant de créer et d’exécuter des conteneurs Linux sur Mac sous forme de machines virtuelles légères
• La nouvelle fonctionnalité Container Machine, ajoutée à la WWDC26, permet d’exécuter un environnement Linux rapide, léger et persistant avec le répertoire personnel et les dépôts montés automatiquement
• Contrairement aux conteneurs traditionnels centrés sur une application, il modélise l’ensemble d’un environnement Linux (similaire à WSL2)
• Permet d’exécuter le système d’initialisation d’une image afin d’enregistrer des services de longue durée ou de tester des applications sous un gestionnaire de processus
• Sur les images où systemd est installé, il est possible d’exécuter de vrais services Linux comme systemctl start postgresql
• Mappe automatiquement le nom d’utilisateur et le répertoire personnel, ce qui permet de partager dépôts et dotfiles entre macOS et Linux
• Les dépôts sont situés dans le $HOME de macOS et montés en interne sous /Users/<username>, ce qui permet de les éditer avec un éditeur ou un IDE macOS tout en les compilant et en les exécutant à l’intérieur
• Des outils natifs macOS comme les profileurs, navigateurs ou débogueurs GUI reconnaissent les mêmes fichiers, supprimant l’étape de copie entre compilation et inspection
• Il est possible de créer autant de Container Machines que de distributions cibles (alpine, ubuntu, debian, etc.), chacune partageant le même $HOME et les mêmes dotfiles pour tester rapidement sur plusieurs distributions
  • Toute image Linux contenant /sbin/init peut être utilisée directement comme image Container Machine
• Comme il consomme et produit des images de conteneur compatibles OCI, il peut aussi pull et push des images Docker depuis des registres de conteneurs standard
  • Ces images peuvent également être exécutées dans d’autres applications compatibles OCI
  • La gestion bas niveau des conteneurs, images et processus repose sur le package Swift Containerization
• Son exécution nécessite un Mac équipé d’Apple silicon et la prise en charge est disponible sur macOS 26
  • Il exploite les nouvelles fonctionnalités et améliorations de virtualisation et de réseau de macOS 26 ; les versions antérieures de macOS ne sont pas prises en charge
• Licence Apache-2.0

Commandes de fonctionnement

container machine create alpine:latest --name dev  
container machine run -n dev whoami       # your host username, not root  
container machine run -n dev pwd          # /home/<you> — your Mac home dir, mounted in  
container machine run -n dev              # interactive shell; cd into your repos in $HOME  
  
container machine ls                  # list all container machines  
container machine inspect dev         # JSON detail for one  
container machine stop dev            # stop the container machine  
container machine rm dev              # delete, including its persistent storage  
  
container machine set -n dev cpus=4 memory=8G  
container machine stop dev  
container machine run -n dev -- nproc  

Vidéo de présentation de la WWDC26 - Découvrir Container Machine

• Containerization est un framework Swift open source présenté à la WWDC 25, qui sert de base à l’exécution de conteneurs Linux sur macOS
• Il a été conçu pour fournir à chaque conteneur une isolation basée sur une machine virtuelle, avec des machines virtuelles légères offrant de bonnes performances et un démarrage en moins d’une seconde
• Container machine est une nouvelle fonctionnalité construite au-dessus de Containerization, qui combine l’ergonomie et la vitesse des conteneurs avec la persistance des machines virtuelles, et dont les fonctions d’intégration donnent à l’environnement Linux l’impression d’être une extension de macOS

• Principes de conception

  • Container machine doit être rapide et léger afin de pouvoir s’intégrer aux workflows existants
  • Il doit être facile de passer de macOS à Linux et inversement
  • Les utilisateurs doivent pouvoir créer et personnaliser rapidement de nouveaux environnements, afin que plusieurs projets puissent disposer d’environnements dédiés sans craindre de conflits de dépendances ou de toolchain
  • Les outils et dépendances nécessaires peuvent évoluer au cours du cycle de développement ; il doit donc être possible d’ajouter des outils dans un environnement persistant et de les réutiliser dans le temps
  • Lors du développement pour plusieurs plateformes, cela ne doit pas nécessiter de gros changements de contexte ni l’apprentissage de nouveaux outils

[recast7838]

Les performances seront-elles suffisantes ?

[click]

À bien y regarder, on dirait juste la version Mac de WSL2, mais est-ce qu’au moins il n’y aura pas cette grosse chute des performances d’E/S quand on mappe des volumes hôte ?
Même maintenant, je fais tourner des conteneurs sur une VM avec limactl, donc j’ai aussi l’impression que ça ne change pas grand-chose.

[GN⁺]

Commentaires Hacker News

• Pour clarifier quelques points, cela ne désigne pas seulement les conteneurs OCI
  Container Machines prend en charge la persistance et les montages de système de fichiers, ce qui en fait un excellent environnement Linux léger pour les développeurs sur macOS
  Plus de détails ici : https://developer.apple.com/videos/play/wwdc2026/389

  • Ah, donc c’est un sous-système Darwin/BSD pour Linux

• OrbStack me convient très bien
  Je me demande comment cela se compare en termes de performances

  • Je suis le développeur d’OrbStack
    Au lieu de Virtualization.framework, on utilise directement une pile de virtualisation en Rust avec des périphériques et protocoles sur mesure pour des fonctionnalités comme le partage du système de fichiers
    C’est une pile fortement intégrée verticalement, hautement optimisée pour l’exécution de machines Linux et de conteneurs
    Le plus gros gain en performances/ressources vient de la mémoire dynamique, qui restitue à macOS la mémoire inutilisée et réduit fortement l’usage mémoire
    Les autres solutions, y compris Containerization, ne prennent pas cela en charge
    Après avoir essayé Container Machines, cela semble bien plus proche d’un conteneur OCI avec un montage bind par défaut que d’une machine OrbStack
    Il y a moins de fonctions d’intégration et il n’exécute pas systemd ni de système d’init classique, ce qui complique l’exécution de services
  • J’aime bien OrbStack sur le principe, mais avec autant d’alternatives open source et gratuites, j’ai du mal à justifier une licence à 96 dollars par an
    À ce stade, je préfère utiliser Podman ou Colima
  • J’aimerais aussi voir une comparaison avec https://tart.run/
    À mes yeux, c’est assez similaire
  • Ce n’est pas un environnement Docker complet, c’est plutôt conçu pour les builds
    On peut aussi lancer dockerd en option, et https://github.com/cpuguy83/crucible exécute buildkitd ou dockerd avec le framework Containerization, puis se connecte au CLI docker/buildx ou à l’outil client de votre choix
    Le framework Containerization est une bibliothèque construite au-dessus du framework Virtualization, donc chaque conteneur est sa propre VM
    Machine est un outil, au-dessus du framework Containerization, qui exécute plusieurs tâches sur les conteneurs à l’intérieur de la VM
  • J’aime vraiment OrbStack, et pour l’instant je ne vois pas bien pourquoi je devrais utiliser Container Machines à la place

• Ces conteneurs partagent-ils un noyau commun ? Ou bien chacun s’exécute-t-il dans une VM distincte ?
  Édition : c’est une VM par conteneur https://github.com/apple/container/blob/main/docs/technical-...

• Les conteneurs d’Apple sont bien adaptés pour fournir un sandbox à des agents de codage IA
  Je les ai emballés sous forme de MCP pour qu’ils soient faciles à découvrir par tous les agents de codage
  https://github.com/instavm/coderunner

• Je me demandais s’il était possible de placer les volumes de conteneur, par exemple, sur un disque externe
  C’est ce que je fais actuellement avec QMEU et des images qcow2, et ça fonctionne plutôt bien

• Je me demande pourquoi macOS n’essaie pas une approche de type WSL1
  Je comprends pourquoi cela n’a pas totalement réussi sur Windows, mais macOS est un autre *nix, donc beaucoup des difficultés rencontrées sur Windows devraient être plus simples sur Mac
  Avec seulement quelques nouvelles API, on dirait qu’on pourrait exécuter nativement la plupart des applications Linux sur macOS
  BSD a déjà quelque chose de ce genre, en pratique

  • Quel avantage cela apporterait-il par rapport à l’infrastructure VM dont Apple a de toute façon besoin ?
    L’ABI est bien plus simple et stable que celle du noyau Linux

• Est-ce que cela pourrait remplacer les solutions du type Docker Desktop et supprimer la grosse VM Linux coûteuse qui tourne à côté ?

  • C’était aussi ma première pensée
    La surcharge de Docker Desktop est assez lourde ; j’aimerais voir cela intégré nativement dans DD
    Vu que Docker a historiquement essayé d’améliorer les performances avant de devoir rapidement accepter les limites de la plateforme, cela semble plausible, et déplacer DD vers l’approche conteneur paraît naturel
  • Cela élimine en grande partie la grosse VM d’arrière-plan partagée et la remplace par des VM natives Apple plus petites et mieux isolées
    J’ai fait une expérience en migrant ma charge de travail Podman vers Apple container : https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
    En résumé, cela réduit l’usage de la RAM et du stockage, et reste très discret
  • D’autres l’ont mentionné ici aussi, mais je suis récemment passé à Colima
    Travailler en contournant Docker Desktop est pénible
  • Ce serait vraiment bien
    J’ai l’impression de faire un rm -rf ~/.colima tous les quelques jours

• Je suis surpris qu’Apple ait jugé cela assez important pour s’y investir
  Cela dit, je préfère toujours utiliser Linux, mais la valeur d’un MacBook reste énorme

  • Moi aussi, je voudrais toujours utiliser Linux, mais parfois l’entreprise me donne un MacBook
    Cet outil pourrait alors m’être utile

• Chaque fois que je vois Apple mettre en avant des conteneurs Linux, j’ai du mal à y voir autre chose qu’un aveu de défaite
  S’ils en avaient encore la capacité, Darwin aurait dû suffire

  • Apple a préparé sa propre défaite sur le marché des serveurs et des développeurs au moment même où ils ont décidé de faire de macOS du code propriétaire
    Pourquoi un développeur sérieux utiliserait-il du code source fermé qu’il ne peut ni déboguer ni corriger, surtout sur un serveur de production ?
    C’est aussi pour cela que les développeurs ou hackers sérieux n’utilisent pas macOS
    L’un des fondements du métier de développeur, c’est précisément la capacité à plonger dans n’importe quelle couche du code pour la déboguer et la corriger
  • Il suffit de réécrire 30 ans d’histoire d’Internet
  • Quelle serait l’alternative ?
    Apple a abandonné le marché des serveurs il y a 10 ans, et même avant cela le support réel était quasi inexistant
    Même s’ils prenaient en charge des conteneurs Darwin, à quoi cela servirait-il ? Littéralement personne ne construirait pour cette cible, Linux a gagné

• C’est une nouvelle fonctionnalité ?
  Je croyais que cela existait déjà
  Quand j’ai testé, les performances du système de fichiers n’étaient pas suffisantes dans des environnements de développement Node/Rust qui font énormément de stat sur de petits fichiers
  Mise à jour : ce qui est nouveau, c’est la sous-commande container machine
  J’ai voulu tester, mais dans mon environnement, container ne se lançait tout simplement pas : https://github.com/apple/container/issues/1681

  • Je me demande si tu as essayé OrbStack
    Il reste encore du travail, mais nous accueillons volontiers des charges de test
    Nous avons consacré beaucoup d’efforts à optimiser notre protocole maison de partage du système de fichiers d’OrbStack pour les petits fichiers et les charges de travail courantes des développeurs
    Ce n’est pas du virtiofs standard
  • Pour information, Podman fonctionne aussi sur macOS
    Il utilise le framework container existant pour exécuter les machines
    Cela fonctionne aussi bien en mode rootful qu’en mode rootless