Apple vient de créer un WSL pour Mac (Container Machines)

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Bien caché derrière tout le battage autour d'Apple Intelligence à la WWDC cette année,
00:00:03Apple a discrètement publié sa propre version du sous-système Windows pour Linux appelée Container
00:00:06Machines. Ils vous offrent un environnement Linux persistant et léger sur votre Mac, vraiment facile
00:00:10à utiliser, et ils sont en réalité construits au-dessus du projet de conteneurs d'Apple qu'ils ont
00:00:14sorti l'an dernier, qui est une alternative à Docker, le tout étant bien sûr optimisé pour Apple
00:00:18Silicon. Voyons donc ce que sont les Container Machines, comment ils fonctionnent,
00:00:21et faisons aussi un récapitulatif rapide des conteneurs Apple pour ceux qui les ont manqués.
00:00:29Je vais commencer par configurer une machine de conteneur, puis j'expliquerai comment tout
00:00:32cela fonctionne un peu plus tard. Mais celle que je veux sera un environnement Ubuntu Linux. Donc je
00:00:37ai simplement un fichier Docker ici avec l'image Ubuntu, et quelques éléments dedans pour installer des outils
00:00:41courants. Cela fonctionnera avec n'importe quelle image compatible OCI, donc à peu près toutes celles que vous
00:00:46utilisez déjà avec Docker. La seule chose nécessaire pour en faire une VM est le programme d'initialisation
00:00:50système. Une fois que nous avons l'image Docker que nous voulons utiliser pour notre VM, il suffit de
00:00:54la construire en utilisant l'outil de conteneur d'Apple. Vous pouvez voir la commande que j'utilise pour la mienne,
00:00:58puisque j'ai le fichier Docker dans ce dossier, et je vais simplement l'étiqueter comme une
00:01:01machine Ubuntu locale, et on peut appuyer sur entrée pour construire. L'outil de conteneur,
00:01:05soit dit en passant, fonctionne sur macOS 26 et supérieur, et vous pouvez l'installer depuis GitHub en allant simplement sur le
00:01:09dépôt, dans les versions, et en téléchargeant le dernier paquet. Il semble que la construction de mon image soit
00:01:13terminée, et vous pouvez voir que c'est très similaire à Docker. C'est juste la construction d'une image OCI.
00:01:17C'est tout ce dont nous avons besoin pour une machine de conteneur, donc maintenant on peut simplement faire container machine create,
00:01:21indiquer l'image que nous voulons pour notre machine, lui donner un nom convivial,
00:01:24et je vais aussi la définir par défaut, comme ça n'importe quelle commande que je lance supposera
00:01:27que je suis sur cette machine de conteneur, et je n'aurai pas à la spécifier par son nom. On peut appuyer sur
00:01:31entrée, et en quelques secondes, tout est configuré. On peut voir quelques informations sur la
00:01:35machine de conteneur que je viens de créer en faisant container machine list. Ici, vous pouvez voir qu'il y a
00:01:38l'Ubuntu que je viens de créer, l'adresse IP, 7 processeurs et 18 gigaoctets de mémoire. Le processeur et la mémoire
00:01:44sont configurables, soit dit en passant, mais par défaut, elle utilisera la moitié de la mémoire de votre Mac. Pour vraiment commencer
00:01:48à utiliser votre machine de conteneur, il vous suffit de faire container machine run,
00:01:51et vous pouvez laisser cela vide si vous voulez entrer dans le terminal interactif, ou vous pouvez simplement
00:01:54ajouter une commande après si vous voulez l'exécuter sur votre machine Linux. Dans ce cas, vous voyez que je
00:01:58viens d'appuyer sur entrée, et maintenant je suis dans un terminal interactif sur mon environnement Linux. On peut confirmer
00:02:02cela en faisant quelque chose comme uname-a, et vous voyez que cela affiche bien Linux Ubuntu,
00:02:06contrairement à quand je lance cela sur mon Mac et qu'on obtient Darwin. Maintenant, l'un des trucs géniaux des
00:02:10machines de conteneur, c'est le partage automatique d'utilisateur ; mon utilisateur a déjà été copié depuis mon Mac
00:02:14vers mon environnement Linux, et la même chose s'applique à votre répertoire personnel. Cela montera votre
00:02:18répertoire personnel entier en lecture-écriture, donc j'ai accès dans cet environnement Linux à tous les fichiers que j'ai
00:02:23sur mon Mac. Vous pouvez voir là où j'ai exécuté container run, ça m'a mis directement dans ce fichier
00:02:27dans l'environnement Linux, et nous avons déjà ces fichiers là-bas. Il possède aussi son propre volume,
00:02:31donc si on navigue vers le répertoire personnel de cette machine Ubuntu, vous pouvez voir qu'il n'y a actuellement
00:02:35rien, même s'il y a des choses sur mon Mac, et c'est parce que celui-ci est l'environnement
00:02:39Linux, et c'est là que vous mettez vos fichiers .files spécifiques à Linux. Le partage de dossier
00:02:43rend très facile le développement sur votre Mac en utilisant tous vos outils habituels, et peut-être même certains
00:02:48qui ne sont compatibles qu'avec macOS, puis de basculer simplement sur Linux quand vous avez besoin de tester quelque chose.
00:02:52Par exemple, j'ai une application BUN très simple ici, et je veux la compiler en un seul
00:02:56exécutable qui fonctionnera sur Linux, mais je ne peux pas vraiment tester Linux sur mon macOS, donc en exécutant cela,
00:03:01je ne sais pas si ça a marché ou non. Si on passe sur la machine de conteneur,
00:03:04vous voyez que je peux simplement lancer la commande directement. Je n'ai pas besoin de transférer des fichiers ni rien,
00:03:08grâce au fait qu'il partage le même système de fichiers. Si j'appuie sur entrée ici, ça fonctionne parfaitement.
00:03:12Cette application était juste un serveur web très simple avec cette page web ici, qui affiche ce sur quoi elle
00:03:16tourne, donc elle tourne actuellement sur Ubuntu 24. Vous pouvez aussi voir qu'il y a un abonnement en cours,
00:03:20quelque chose que vous devriez absolument faire. J'étais justement en train de tester l'exécution du serveur
00:03:23de développement BUN sur l'environnement Linux, et tout fonctionne, ce qu'on peut voir ici,
00:03:27ça tourne sur BUN dev, et ce n'est pas compilé. Mais si je modifie l'un des fichiers source depuis mon Mac
00:03:31ici, disons pour dire “hello” au lieu de s'abonner, je remarque que le rechargement à chaud ne semble pas
00:03:35détecter ce comportement, et je dois redémarrer le serveur de développement BUN pour que les changements soient
00:03:39appliqués. Voilà, maintenant ça dit “hello”. Je pense que le rechargement à chaud fonctionnera de la même manière que les points d'arrêt,
00:03:43où ils ne fonctionnent pas vraiment si vous êtes sur votre version de code macOS, mais ce que vous pouvez faire, c'est configurer
00:03:47votre éditeur pour qu'il se connecte à la machine de conteneur via SSH, et ensuite éditer les fichiers de cette façon,
00:03:52et ainsi les points d'arrêt et le rechargement à chaud fonctionneront probablement. Ils ont en fait un tutoriel sur la façon de faire cela
00:03:55dans leur documentation. C'est à peu près tout ce qu'il y a à montrer en ce qui concerne l'utilisation réelle d'une
00:03:59machine de conteneur. Je veux dire, c'est juste un environnement Ubuntu maintenant, et honnêtement, toute l'expérience
00:04:03est plutôt transparente. Il vaut aussi la peine de souligner que vous n'êtes pas limité à une seule machine. Vous pourriez
00:04:08avoir une machine Alpine, une Ubuntu, et une Debian côte à côte, donc vous avez une distribution
00:04:12par cible, et honnêtement c'est très agréable si vous faites du travail multi-cibles. De plus, parce que ces machines
00:04:17peuvent réellement exécuter un vrai SystemD, vous pouvez tester une pile de services appropriée, comme avoir Postgres
00:04:22tournant en tant que service réel avec votre application à côté, et le tout se comportera comme le
00:04:26serveur Linux sur lequel vous allez déployer. La simplicité est l'un des principes de conception fondamentaux que
00:04:30Apple poussait lors du développement des Container Machines. Ils voulaient des VM rapides et légères qui
00:04:34s'intègrent dans votre flux de travail existant et soient super faciles à lancer selon vos besoins, tout en étant persistantes
00:04:39au fil du temps, afin que vous puissiez configurer toute une VM d'environnement de développement qui a tous les outils dont
00:04:42vous avez normalement besoin, prêts quand vous en avez besoin. Encore une fois, c'est assez similaire à ce que le sous-système Windows
00:04:47pour Linux essayait d'atteindre. Quant à savoir comment tout cela est construit et comment cela se compare à Docker et
00:04:51OrbStack, nous devons d'abord comprendre l'outil de conteneur qui est sorti l'an dernier. Il est écrit
00:04:55en Swift et se veut être une alternative à Docker capable d'exécuter des conteneurs, et il exécute n'importe quelle image
00:04:59OCI standard, donc tout ce que vous pouvez extraire de Docker Hub fonctionnera toujours. La chose unique à propos
00:05:04de l'approche d'Apple, cependant, est que chaque conteneur obtient sa propre machine virtuelle légère via leur
00:05:08framework de virtualisation, plutôt qu'un groupe de conteneurs partageant une seule grosse VM Linux, ce qui est ce que
00:05:13Docker Desktop fait. Certains avantages de cette approche peuvent être la sécurité, puisque chaque conteneur possède les
00:05:17propriétés d'isolation d'une VM complète. Ensuite, il y a aussi la confidentialité, puisque vous ne montez que les données nécessaires
00:05:22dans chaque VM, tandis que lorsque vous avez une VM partagée, vous montez en fait toutes les données dans cette
00:05:27VM partagée, donc elles peuvent être montées sélectivement dans les conteneurs individuels. Enfin, il peut aussi y avoir
00:05:31un avantage en termes de performance, puisque les conteneurs créés en utilisant Apple Container nécessitent réellement moins de mémoire qu'une
00:05:36VM complète, et les temps de démarrage sont assez similaires à ceux de Docker et d'autres outils. Si nous regardons en fait quelques
00:05:41benchmarks que RepoFlow a effectués ici, comparant Apple Containers avec OrbStack et Docker Desktop, nous pouvons voir que les
00:05:46résultats ne sont pas trop mauvais. C'est difficile à dire ici, mais Apple Containers atteint effectivement le
00:05:50plus grand nombre d'événements processeur à thread unique, mais OrbStack était assez proche, c'est une question de fractions, et cette
00:05:55même histoire se poursuit quand on passe au multi-thread, ils fonctionnent tous très bien. Là où Apple
00:06:00semble prendre un peu d'avance, cependant, c'est au niveau du débit mémoire, avec OrbStack en deuxième et Docker
00:06:04Desktop dernier, mais en ce qui concerne les temps de démarrage pour un minuscule conteneur, il semble qu'Apple a encore
00:06:09du travail à faire ici, mais c'est quand même sous la seconde, c'est juste que Docker Desktop et OrbStack le font en moins
00:06:14d'un quart de seconde. Il y a plein d'autres benchmarks ici, donc je laisserai un lien vers ceci,
00:06:17mais en gros le reste montre qu'OrbStack a des performances exceptionnelles sur le système de fichiers et les petits fichiers,
00:06:22mais ils montrent aussi qu'Apple Containers est à peu près au même niveau, voire meilleur que Docker Desktop.
00:06:27Il y a quelques pièges cependant dont vous voudrez être conscients avant d'utiliser les Container Machines,
00:06:30et le premier est la mémoire. Comme je l'ai mentionné plus tôt, la machine utilise par défaut la moitié de la RAM de votre système,
00:06:35donc il est bon de savoir qu'elle ne la rend jamais vraiment. Donc si vous avez une charge de travail intensive
00:06:39en mémoire dans le conteneur, peut-être pendant une grosse compilation, cette mémoire est en fait conservée jusqu'à ce que vous
00:06:43redémarriez la machine. C'est en fait l'un des avantages uniques d'OrbStack, où il possède une mémoire dynamique,
00:06:47qui réduit l'utilisation de la mémoire en libérant cette mémoire inutilisée vers macOS. Autant que je sache,
00:06:53rien d'autre ne fait cela. Deuxièmement, il n'y a pas non plus de transfert de GPU ni de port USB. J'ai vu des problèmes ouverts
00:06:57pour les deux sur ce GitHub cependant, donc peut-être que ce sera pris en charge à l'avenir. Troisièmement, il semble aussi
00:07:02un peu complexe de faire fonctionner des applications GUI, comme peut-être si vous vouliez exécuter la version Linux de
00:07:06VS Code ou d'autres applications réservées à Linux. Ce n'est certainement pas une expérience transparente, j'utiliserais probablement autre chose pour
00:07:11cela. Enfin, il y a aussi un compromis de sécurité car, comme je l'ai mentionné plus tôt, ce montage du répertoire personnel
00:07:15qui rend tout si pratique est en lecture-écriture par défaut, ce qui signifie que tout ce que vous exécutez
00:07:20à l'intérieur de cette machine Linux peut toucher vos clés SSH, vos informations d'identification cloud, et tout ce qu'il y a sur
00:07:25votre Mac. Il semble que vous puissiez en fait seulement définir le montage en lecture seule ou le désactiver complètement. Il
00:07:29ne semble pas y avoir de possibilité de monter seulement un dossier spécifique. Dans l'ensemble, après avoir essayé les Apple
00:07:33Container Machines, je vais probablement m'en tenir à OrbStack car cela semble être l'option la plus polie
00:07:37aujourd'hui avec une meilleure gestion des ressources et plus de fonctionnalités, mais je sais que certaines personnes n'aiment pas que
00:07:40OrbStack soit payant si vous voulez une utilisation professionnelle et commerciale, donc sans OrbStack, je choisirais probablement
00:07:45Apple Containers plutôt que Docker Desktop, et il y a aussi Lima, qui est une autre excellente
00:07:49alternative. Qu'utilisez-vous ? Est-ce OrbStack, Docker Desktop, ou Lima ? Faites-le-moi savoir dans les commentaires ci-dessous
00:07:53pendant que vous y êtes pour vous abonner, et comme toujours, à la prochaine.

Key Takeaway

Apple introduit les Container Machines comme une alternative optimisée pour Apple Silicon permettant d'exécuter des environnements Linux isolés et persistants directement sur macOS sans surcouche complexe.

Highlights

  • Apple propose les Container Machines, un environnement Linux persistant et léger basé sur le framework de virtualisation macOS 26+.

  • La création de machines conteneurisées repose sur des images compatibles OCI, identiques à celles utilisées avec Docker.

  • Le partage automatique des répertoires personnels entre macOS et Linux permet un accès en lecture-écriture immédiat aux fichiers du projet.

  • Chaque conteneur dispose de sa propre machine virtuelle dédiée, offrant une isolation supérieure à celle d'une VM partagée unique.

  • La consommation mémoire par défaut est fixée à 50 % de la RAM totale du Mac, sans mécanisme natif de libération dynamique.

  • Les performances en débit mémoire dépassent celles de Docker Desktop dans les tests de référence, bien que le temps de démarrage soit légèrement supérieur à 0,25 seconde.

Timeline

Configuration et utilisation des Container Machines

  • L'outil s'installe via le dépôt GitHub officiel sous macOS 26 et versions ultérieures.
  • La commande 'container machine create' permet d'initialiser une machine à partir d'une image OCI standard.
  • Le système monte automatiquement le répertoire utilisateur du Mac en lecture-écriture pour faciliter le développement.

Les Container Machines s'appuient sur le projet de conteneurs d'Apple optimisé pour Apple Silicon. Le flux de travail consiste à construire une image, puis à instancier une machine virtuelle légère qui partage le système de fichiers hôte. Cette approche permet de tester des applications sur Linux tout en conservant les outils de développement macOS, bien que le rechargement à chaud nécessite parfois une connexion SSH spécifique.

Architecture et avantages techniques

  • Chaque conteneur bénéficie des propriétés d'isolation d'une machine virtuelle complète via le framework de virtualisation Apple.
  • La gestion des données est plus confidentielle car seuls les volumes nécessaires sont montés dans chaque instance.
  • Les benchmarks montrent un débit mémoire supérieur par rapport à Docker Desktop et OrbStack.

Contrairement à Docker Desktop qui utilise une VM Linux unique pour tous les conteneurs, l'approche d'Apple isole chaque conteneur dans sa propre VM. Cette architecture améliore la sécurité et la granularité des accès aux données. Les tests comparatifs confirment que cette méthode offre des performances processeur et mémoire compétitives pour les environnements de développement.

Limites et alternatives

  • La mémoire allouée est conservée par la machine virtuelle jusqu'à son redémarrage, contrairement à la gestion dynamique d'OrbStack.
  • Le support du GPU et des périphériques USB est actuellement inexistant.
  • Le montage par défaut en lecture-écriture du répertoire personnel présente des risques pour la sécurité des clés SSH et des identifiants cloud.

Bien que performantes, les Container Machines manquent de certaines fonctionnalités avancées comme la gestion dynamique de la RAM. L'absence de support pour les applications graphiques et les périphériques matériels limite également leur usage. OrbStack reste une alternative plus complète pour les besoins professionnels, tandis que Lima constitue une autre option robuste.

Community Posts

View all posts