Containerization - un package Swift pour exécuter des conteneurs Linux sur macOS

 (github.com/apple)
6 points par GN⁺ 2025-06-10 | 1 commentaires | Partager sur WhatsApp
  • Containerization est un outil open source basé sur Swift qui permet d’exécuter des conteneurs Linux sur macOS
  • Il fonctionne sur les Mac équipés d’Apple Silicon et s’appuie sur Virtualization.framework pour isoler chaque conteneur dans une machine virtuelle légère
  • Il inclut diverses fonctionnalités comme la gestion des images OCI, l’intégration avec des registres distants, la création de systèmes de fichiers ext4 et le contrôle de l’environnement des conteneurs
  • Il peut aussi prendre en charge l’exécution de processus x86_64 sur Apple Silicon grâce à Rosetta 2
  • Il améliore la flexibilité et les performances pour les développeurs grâce à un démarrage quasi instantané, un environnement léger et la personnalisation de la version du noyau

Aperçu du projet

  • Containerization est un package Swift qui aide les applications à utiliser des conteneurs Linux
  • Il est implémenté en Swift et fonctionne sur les Mac Apple Silicon en utilisant Virtualization.framework
  • L’API fournit les fonctions suivantes
    • gestion des images OCI
    • intégration avec des registres de conteneurs distants
    • création et déploiement de systèmes de fichiers ext4
    • interaction avec la famille de sockets Netlink
    • fourniture d’un noyau Linux optimisé pour un démarrage rapide
    • création et gestion de machines virtuelles légères
    • contrôle de l’environnement d’exécution des machines virtuelles
    • création et contrôle de processus conteneurisés
    • exécution de processus x86_64 sur Apple Silicon à l’aide de Rosetta 2
  • La documentation de l’API est disponible sur une page officielle distincte

Conception et architecture

  • Chaque conteneur Linux s’exécute dans une machine virtuelle indépendante
  • Une adresse IP dédiée peut être attribuée à chaque conteneur, ce qui simplifie la gestion réseau sans avoir recours au port forwarding
  • Grâce à une configuration de noyau optimisée et à un système de fichiers racine léger, le démarrage du conteneur en moins d’une seconde est possible
  • vminitd est un sous-projet de Containerization, un système init léger qui agit comme processus initial dans la machine virtuelle
    • Il configure l’environnement d’exécution via une API gRPC et prend en charge l’exploitation et l’administration des processus du conteneur
    • Il transmet les entrées/sorties, les signaux et les événements au processus appelant

Exigences

  • Un appareil Mac Apple Silicon est requis
  • Pour construire le package, il faut
    • macOS 15 ou ultérieur et Xcode 26 Beta
    • ou macOS 26 Beta 1 ou ultérieur
  • En cas d’utilisation avec macOS 15, les fonctionnalités suivantes sont limitées
    • mise en réseau de conteneurs non isolés : la communication entre conteneurs sur le même réseau vmnet n’est pas possible

Exemples d’utilisation

  • Un exécutable cctl est fourni : il sert de playground pour expérimenter diverses fonctions de l’API
    • Exemples de commandes principales
      • manipulation des images OCI
      • connexion à un registre de conteneurs
      • création de blocs de système de fichiers racine
      • exécution d’un conteneur Linux simple

Configuration du noyau Linux

  • Un noyau Linux est nécessaire pour exécuter des machines virtuelles légères dédiées aux conteneurs
  • La configuration de noyau optimisée fournie par Containerization se trouve dans le répertoire kernel
  • Cette configuration n’inclut que le strict minimum afin d’offrir un démarrage rapide et un environnement léger
  • Une API permet, selon les besoins, de définir différemment la configuration du noyau et sa version pour chaque conteneur
    • Il est possible de tester différentes versions et configurations du noyau
  • Il est possible d’utiliser des noyaux précompilés comme vmlinux.container fournis par le projet Kata Containers
    • Toutefois, les pilotes VIRTIO doivent être intégrés directement au noyau (compiled-in)

Résumé du processus de développement et de test

  • Il faut préparer l’environnement, notamment Swift et le Static Linux SDK
  • Le code source peut être compilé et testé (make all, make test integration, etc.)
    • Une image du noyau est nécessaire pour exécuter les tests d’intégration
  • La configuration des dépendances prend en charge des versions spécifiques liées à gRPC/Protobuf
  • La génération automatique de la documentation de l’API et un aperçu local sont inclus

Contribution open source et état du projet

  • Les contributions sont les bienvenues
  • La version 0.1.0 est la première version officielle, et la stabilité du code source n’est garantie qu’à l’intérieur du périmètre d’une version mineure
  • Cette politique pourra évoluer dans de futures versions mineures

Résumé

  • Containerization est un package Swift innovant qui permet aux développeurs de gérer, exécuter et développer des conteneurs Linux sur macOS dans un environnement optimisé
  • En faisant tourner chaque conteneur dans une machine virtuelle dédiée et légère, il apporte des avantages en matière d’isolation, de performances, de réseau et de personnalisation du noyau
  • C’est une solution adaptée aux développeurs qui veulent étendre les environnements de conteneurs open source à une expérience native sur macOS

À lire aussi

1 commentaires

 
GN⁺ 2025-06-10
Avis Hacker News

  • Je partage ce qui me semble être l’aspect le plus surprenant et intéressant

    le message indiquant que les contributions au projet "container" sont bienvenues et encouragées donne l’impression d’une attitude d’Apple assez inhabituelle
    WebKit était un fork hostile de KHTML, et Darwin donnait aussi l’impression qu’on lançait des pièces par-dessus un mur, une par une
    J’espère que ce genre de projets récemment publiés par Apple sur GitHub encouragera une collaboration active entre utilisateurs et développeurs
    J’ai une sensibilité F/OSS (open source), mais à cause de la politique de mon entreprise je ne peux pas utiliser Linux et je suis donc contraint d’utiliser un Mac tous les jours
    Depuis l’arrivée de l’Apple Silicon, j’ai aussi remplacé mon portable personnel par un Mac, mais ces derniers temps les alternatives plus favorables à Linux semblent se rapprocher, ce qui est encourageant
    Ce changement est un signal positif, et pour des utilisateurs comme moi qui avaient un conflit intérieur, c’est une évolution rassurante
    Si cette collaboration open source pouvait enclencher un cercle vertueux, je pense que la culture de collaboration entre Apple et la communauté pourrait encore grandir
    J’imagine une ambiance où des développeurs comme moi bénéficieraient directement de ces changements tout en gagnant aussi du respect pour Apple

    • Avis selon lequel il n’y a pas tant lieu que ça d’être surpris par la participation d’Apple à la communauté open source
      Mention du fait que Swift et ses frameworks associés reçoivent eux aussi de nombreuses contributions de la communauté open source

    • Comme ce projet touche à Linux, certains estiment qu’en raison du copyleft de Linux (licence open source forte), Apple n’avait de toute façon pas d’autre choix que d’adopter une approche collaborative

  • Recommandation de la vidéo associée, la présentation WWDC 2025 (https://developer.apple.com/videos/play/wwdc2025/346/)
    Chaque conteneur est isolé dans une VM Linux légère
    On peut le lancer directement en téléchargeant l’outil container (https://github.com/apple/container/releases), macOS 26 requis

    • Cette soumission concerne https://github.com/apple/containerization, et non le projet container
      containerization sert à déployer des apps avec un sidecar de conteneur, ce qui en fait une annonce plus intéressante
      À l’inverse, container vise à fournir aux développeurs un environnement du type 'docker run ...'
      Pour container, un fil HN séparé est indiqué (https://news.ycombinator.com/item?id=44229239)

    • À noter que cela fonctionne aussi sur macOS 15, même si certaines fonctions réseau peuvent être limitées

  • Le communiqué de presse et la session WWDC mentionnent que l’outil CLI se trouve sur https://github.com/apple/container
    Comme j’aime beaucoup ce type d’outils, j’espérais qu’il serait inclus par défaut dans la dernière Xcode Beta, mais ce n’est pas encore le cas
    Un paquet précompilé est en préparation pour le moment, et l’avancement peut être suivi dans l’issue publique (https://github.com/apple/container/issues/54)

  • Je me demande ce que Docker en pense
    J’imagine qu’une part importante des utilisateurs de Docker for Desktop utilise un Mac

    • Avis selon lequel ce changement facilite au contraire énormément le développement de Docker Desktop
      Il n’est désormais plus nécessaire de configurer une VM Linux séparée, ce qui réduit la difficulté de développement
      Malgré cela, beaucoup d’utilisateurs continueront probablement à préférer Docker Desktop pour son CLI familier, Docker Compose et les diverses UX propriétaires de Docker
      Changer de runtime de conteneur n’est pas quelque chose de simple

    • Supposition que, du point de vue de Docker, cela doit provoquer un sentiment proche de celui qu’ils ont face à podman

    • Comme Docker Desktop est un logiciel commercial closed source et que ce projet est un logiciel libre, certains y voient une bonne nouvelle du point de vue des utilisateurs

  • Je me demande si cette technologie peut servir à intégrer des conteneurs Linux dans des apps macOS
    Par exemple, cela pourrait être nécessaire pour permettre à un outil comme GPT d’accéder à un environnement Linux sans commande CLI en root

    • Si le fait que cela ne fonctionne que sur macOS 26 ne pose pas problème, on peut déjà l’utiliser immédiatement à cette fin
      Sinon, c’est aussi possible en utilisant directement Virtualization.framework, mais cela demande davantage de travail

    • Conviction que cette technologie a précisément été conçue pour ce type d’usage

  • Le fait que chaque conteneur s’exécute dans sa propre VM isolée, avec isolement complet et attribution d’une IP distincte, est intéressant, mais ce type d’architecture n’est pas familier sur Linux ou Windows
    Si, dans l’équipe de développement, ne serait-ce qu’une seule personne n’utilise pas de Mac, le modèle de développement local s’effondre
    Conclusion : il sera difficile de remplacer Docker/Compose

  • Deux des trois grands OS desktop permettent désormais officiellement d’exécuter des VM Linux pour faire tourner des applications nativement Linux
    À voir cette évolution, on peut soutenir que Linux a de fait gagné
    L’API des appels système Linux occupe maintenant presque partout la place d’API universelle

    • Réponse selon laquelle le simple fait qu’il faille désormais développer normalement des applications Linux sur deux grands OS non-Linux ne suffit pas à parler de "victoire de Linux"
      Témoignage selon lequel la réalité de Linux sur desktop reste encore instable et difficile à recommander
      Retour honnête : même en installant Fedora/Ubuntu chaque année sur des PC ou portables récents, on ne ressent toujours pas une vraie utilisabilité ni une vraie stabilité

    • Point de vue inverse : en fournissant sur les deux autres plateformes un moyen d’utiliser Linux sans quitter leur écosystème, cela ralentit encore davantage la progression de la part de marché de Linux sur le desktop

    • Mise en avant du fait qu’il n’existe toujours pas de solution vraiment satisfaisante pour le graphisme, l’audio et le GUI

    • Question : "Si le seul joueur de la partie, c’est toi, est-ce vraiment une victoire ?"
      Plaisanterie sur le fait que, pour les utilisateurs ordinaires de Windows ou de Mac, Linux est un nom qu’ils ne connaissent même pas

    • Avis selon lequel le simple fait d’avoir "macOS avec Linux" est en soi marquant

  • Je me demande s’ils ont aussi optimisé la gestion mémoire, notamment pour éviter que les VM n’utilisent plus de mémoire que nécessaire

  • Je ne sais pas exactement à quelle étape cela se produit, mais j’ai l’impression que les builds sont très lents
    J’ai essayé d’augmenter davantage les ressources CPU/mémoire avec les options -c et -m, mais l’effet reste limité

    • Question sur la référence de comparaison utilisée pour dire que c’est lent
      Partage d’une expérience passée avec un Mac Apple Silicon + Rancher Desktop, où cela prétendait construire des images x86, mais où ces images ne fonctionnaient pas correctement sur du vrai matériel x86

  • Dans la courte démo (https://developer.apple.com/videos/play/wwdc2025/346), le fait que la VM puisse démarrer en quelques centaines de millisecondes est impressionnant
    Cela repose sur Virtualization.framework, une technologie également utilisée de manière optionnelle par Docker Desktop/Colima/UTM, entre autres
    On se demande quel est le surcoût mémoire quand plusieurs conteneurs tournent en parallèle

    • Explication : la vitesse de démarrage des conteneurs a été réduite à moins d’une seconde grâce à une configuration optimisée du noyau Linux (kernel config, https://github.com/apple/containerization/…), à un système de fichiers racine minimal et à un système d’init léger