Les développeurs et admins venus de Windows connaissent bien WSL, ce sous-système qui offre un vrai Linux intégré au système hôte. Si vous désirez avoir Linux sur Mac, l’équivalent le plus proche est arrivé avec la version 1.0 de l’outil Apple Container. Son nom : .

Plutôt que d’empaqueter une application dans un conteneur jetable, ce mode fournit un environnement Linux persistant, dans lequel votre dossier personnel macOS est monté. Vous pouvez installer des paquets, exécuter des services et tester votre application sous plusieurs distributions. Dans cet article, je vous propose de découvrir ce qu’est , en quoi il se rapproche de WSL, puis nous verrons comment le créer et l’utiliser !

Cet article suppose que est déjà installé sur votre Mac. Si ce n’est pas le cas, commencez par notre guide Apple Container, qui couvre l’installation et une prise en main complète. Prêt à disposer d’une alternative à WSL sur Mac ? Lisez la suite de cet article.

Qu’est-ce que container machine ?

est un mode de l’outil open source d’Apple qui fournit un environnement Linux persistant sur un Mac Apple Silicon. À la différence d’un conteneur classique, calqué sur une application et destiné à être lancé puis détruit, une machine conteneurisée est calquée sur un système Linux complet : elle démarre le système d’init de l’image et peut héberger des services qui tournent en continu. C’est l’analogue le plus proche de WSL côté macOS.

Son intérêt principal pour le développement tient à l’intégration avec l’hôte : votre nom d’utilisateur et votre répertoire personnel macOS sont montés dans l’environnement Linux. Vos dépôts et vos fichiers de configuration sont donc disponibles des deux côtés. Vous éditez votre code avec vos outils macOS habituels, et vous le compilez ou l’exécutez à l’intérieur de Linux, sans étape de copie.

La distinction entre un conteneur applicatif ou un environnement Linux est importante pour comprendre le mode machine :

• Un conteneur répond à la question « comment exécuter cette application de façon isolée et reproductible ? ». Il est éphémère par nature.
• Une container machine répond à « comment disposer d’un environnement Linux complet et durable sur mon Mac ? ». On y revient, on y installe des outils, on y lance des services, on y garde un état.

container machine, un équivalent de WSL sur macOS ?

L’analogie avec WSL (Windows Subsystem for Linux) est pertinente, et c’est sans doute le meilleur repère pour ceux qui découvrent ce mode. Il faut avouer qu’il y a plusieurs points communs entre les deux :

• Un vrai noyau Linux s’exécute dans une machine virtuelle légère, et non une simple émulation.
• Le système de fichiers de l’hôte est intégré : sous WSL, vos disques Windows sont accessibles. Ici, votre dossier personnel macOS est monté dans l’environnement Linux.
• On peut faire tourner de vrais services Linux (avec sur une image adaptée) et tester son application sous plusieurs distributions.
• Le principe « j’édite côté hôte, je compile côté Linux » est le même.

Pour autant, l’analogie a ses limites, et il faut être honnête à ce sujet :

Prérequis Linux sur Mac

Le mode machine permettant d’avoir un Linux sur Mac partage les prérequis de l’outil , à savoir :

• Un Mac Apple Silicon (M1 ou plus récent).
• macOS 26 (Tahoe), la version officiellement prise en charge.
• L’outil installé et son service démarré ().

Créer et utiliser une container machine

Créer une machine

La création se fait à partir d’une image Linux, comme pour un conteneur :

Pour lister les machines exécutées, la commande n’est pas la même que pour les conteneurs.

Ouvrir un shell et exécuter des commandes

permet d’obtenir un shell ou d’exécuter une commande unique. Si la machine est arrêtée, elle est démarrée automatiquement. Sans commande, on obtient un shell interactif, sous un utilisateur qui correspond à votre compte macOS. Les valeurs retournées par les commandes ci-dessous sont particulièrement intéressantes.

Voyons comment exécuter une commande unique.

Quel est l’utilisateur utilisé par notre machine devbox ?

Ceci retourne : , soit l’utilisateur avec lequel je suis connecté sur mon Mac.

Exécutez maintenant cette commande :

Ceci retourne le répertoire actuel dans lequel vous vous situez dans le terminal du Mac.

Ensuite, pour ouvrir un shell interactif, lancez cette commande :

C’est là que la philosophie “équivalent WSL” prend tout son sens : vous n’êtes pas dans un environnement anonyme, mais vous-même, avec votre et vos dépôts sous la main.

Éditer sur macOS, compiler dans Linux

Comme votre dépôt vit dans votre dossier personnel macOS et qu’il est monté dans la machine, le flux de travail devient fluide : vous écrivez votre code dans votre éditeur macOS, vous l’exécutez dans l’environnement Linux, et les deux côtés voient exactement les mêmes fichiers, sans étape de copie.

Cet aller-retour prend tout son sens lorsque la cible réelle est un serveur Linux. Un cas fréquent : vous préparez un script destiné à tourner sur un serveur Linux (par exemple une tâche planifiée via cron). Le piège, c’est que les outils en ligne de commande de macOS sont des versions BSD, au comportement parfois différent des GNU coreutils d’une distribution Linux serveur (Debian, Ubuntu…). Tester le script directement sur le Mac peut donc induire en erreur : la machine vous offre un vrai Linux pour le valider dans les conditions de sa cible.

Construire une image de machine adaptée

Première étape, et c’est un point à connaître : toutes les images ne conviennent pas à une machine. Une container machine démarre le système d’init de l’image (PID 1) ; il faut donc une image qui embarque . L’image fonctionne, mais Alpine s’appuie sur busybox, ni BSD ni GNU : elle ne reproduirait pas le comportement d’un serveur Debian/Ubuntu. C’est décrit sur cette page.

Pour un véritable environnement GNU, on construit une image Ubuntu avec un init, à partir du Dockerfile fourni par la documentation officielle. On commence par créer un dossier pour ce projet.

Puis on crée un Dockerfile dans ce répertoire avec l’exemple proposé par Apple :

On construit ensuite l’image, puis on crée la machine à partir de celle-ci (la construction nécessite Rosetta 2, comme toute commande ) :

Note : cette image sert de base à une vraie machine Ubuntu. On la réutilisera dans la suite de l’article.

À partir de là, vous disposez d’une machine Ubuntu exécutée via Apple Container. Vous pouvez ouvrir un shell ou exécuter une commande, comme nous l’avons vu précédemment.

L’aller-retour en pratique

Mettons cela en pratique avec un exemple représentatif. Nous allons écrire, côté Mac, un petit script de maintenance destiné à un serveur Linux : il calcule la date de la veille, un grand classique pour nommer une archive ou un rapport quotidien. C’est incomplet dans notre cas, mais c’est pour illustrer la mécanique.

Nous le lancerons d’abord sur le Mac pour constater son échec (la commande y est en version BSD), puis dans la machine Ubuntu où il s’exécutera correctement (version GNU), comme sur le serveur cible. C’est l’intérêt : un seul fichier, partagé, mais deux comportements selon l’environnement.

Sur le Mac, on crée le script dans son dossier personnel (vous l’éditeriez normalement avec VS Code) :

Lancé directement sur le Mac, il échoue : la commande de macOS (BSD) ne connaît pas l’option :

Dans la machine Linux, on retrouve le script sans l’avoir copié ! C’est une particularité de ce mode d’exécution, et surtout, il s’exécute comme il le ferait sur le serveur de production. Plusieurs étapes pour atteindre cet objectif.

Ouvrez un shell dans la machine Ubuntu

À partir d’ici, vous êtes dans l’environnement Linux !

Le dossier personnel macOS est monté : le script est déjà visible par Ubuntu.

L’exécution fonctionne bien ! L’image ci-dessous illustre bien la différence de comportement selon le contexte d’exécution.

Vous pouvez désormais : modifier le script sur le Mac, l’enregistrer et le relancer dans la machine Ubuntu. L’avantage : aucun transfert, le fichier est partagé. Vous développez avec le confort de votre machine macOS, mais vous validez le comportement réel sur Linux.

Note : le cas de n’est qu’un exemple. La même prudence vaut pour (qui exige un argument supplémentaire en BSD : sur macOS contre sous Linux). C’est précisément pour éviter ces écarts qu’on valide un script Linux dans un environnement Linux.

Faire tourner des services persistants

C’est l’un des intérêts majeurs d’une container machine par rapport à un conteneur applicatif : comme elle démarre le système d’init de l’image, elle peut héberger de vrais services, pilotés avec . Pour l’illustrer, installons un petit socle web classique : le serveur Apache et la base de données MariaDB, le tout dans une machine basée sur notre image .

Ouvrez un shell dans la machine, puis installez les deux paquets :

On démarre ensuite les deux services et on les active au démarrage de la machine, exactement comme sur un serveur Linux :

MariaDB propose un script d’initialisation pour durcir l’installation (mot de passe root, suppression des comptes anonymes et de la base de test). Un réflexe d’hygiène informatique à conserver :

Il ne reste qu’à vérifier qu’Apache répond. La machine dispose de sa propre adresse IP sur le réseau de l’hôte : récupérez-la avec la commande , puis ouvrez la page par défaut depuis le Mac (via le terminal ou votre navigateur).

La page d’accueil s’affiche : votre serveur tourne dans la machine, joignable depuis macOS. Et surtout, tout cet état persiste : au prochain , Apache et MariaDB sont toujours installés et configurés, sans rien réinstaller. C’est là toute la différence avec un conteneur applicatif, dont l’état s’évapore avec le processus (à moins de déclarer des volumes persistants).

Plusieurs distributions en parallèle

Rien ne vous empêche de créer autant de machines que de distributions cibles. Chacune partage le même et les mêmes fichiers de configuration personnels (les dotfiles : , …) issus de votre Mac, ce qui est pratique pour valider une application sous plusieurs environnements :

Virtualisation imbriquée (KVM) dans une container machine

La documentation de la branche de développement évoque une prise en charge de la virtualisation imbriquée : exposer à l’intérieur d’une machine (via une option et un noyau Linux compilé avec ), pour les puces M3 et plus récentes.

Cependant, d’après les tests effectués, cette capacité n’est pas encore exposée dans la CLI 1.0.0 stable. Si on tente d’appeler cette option, elle est rejetée par la commande, car elle est inconnue. À surveiller dans les futures versions !

container machine face aux autres “Linux sur Mac”

Je profite de cet article pour indiquer que le mode machine présenté dans cet article n’arrive pas sur un terrain vierge. Plusieurs projets permettent déjà de faire tourner du Linux sur un Mac : Lima (et Colima pour les runtimes de conteneurs), multipass de Canonical pour des VM Ubuntu, UTM pour des machines virtuelles via QEMU, ou encore l’option OrbStack (qui a une très bonne réputation).

Ce qui distingue container machine, c’est son appui sur les frameworks natifs d’Apple, son intégration directe du dossier personnel macOS, et le fait de partager le même outillage que container (vous restez dans le même écosystème pour vos conteneurs et vos environnements Linux). En contrepartie, ces alternatives sont certainement plus matures sur certains points.

Conclusion

Avec , le Mac gagne un véritable “Linux à la demande”, persistant et bien intégré, qui rappellera WSL à beaucoup de développeurs. Il lui manque WSLg pour les environnements graphiques et que l’on a déjà via le Windows Subsystem for Linux (WSL). Reste qu’il s’agit d’une fonctionnalité récente qui en est qu’à ses débuts.

Pour aller plus loin :

• Notre guide Conteneurs sur macOS : utiliser container, l’outil natif d’Apple.
• La documentation officielle du mode machine sur le dépôt .
• La documentation de référence de WSL pour le point de comparaison côté Windows.

FAQ