Au-delà de Docker : Apple dévoile discrètement "Container", un framework Swift open source pour faciliter l'exécution de containers Linux sur macOS

Et améliorer la performance et la sécurité

Au-delà de Docker : Apple dévoile discrètement "Container", un framework Swift open source pour faciliter l’exécution de containers Linux sur macOS
et améliorer la performance et la sécurité

Apple a récemment fait un pas significatif vers l'amélioration de l'expérience de développement Linux sur macOS avec le lancement discret d'un nouvel outil baptisé "Container" sur GitHub. Cette initiative marque un tournant pour les développeurs utilisant des machines Mac mais nécessitant un environnement de développement Linux, offrant une alternative native aux solutions existantes comme Docker ou Podman. Malgré ses innovations, "Container" présente certaines limitations. Des problèmes d'accès aux services sur localhost ont été signalés, ainsi que des particularités potentielles dans la gestion de la mémoire, en particulier sur les versions antérieures de macOS. Bien que conçu pour le futur macOS 26 Tahoe, son fonctionnement actuel sous macOS 15 Sequoia peut rencontrer des restrictions, et la prise en charge complète du "memory ballooning" est encore en développement.

Contexte : Linux sur macOS, un défi de longue date

Historiquement, macOS repose sur le noyau XNU, qui ne prend pas nativement en charge les primitives de conteneurisation (cgroups, namespaces) comme le fait Linux. Les développeurs intéressés par les environnements conteneurisés sous macOS ont dû recourir à des machines virtuelles (QEMU, VirtualBox, Docker Desktop, Colima ou Lima) pour faire tourner des conteneurs Linux dans une VM. Bien que ces solutions fonctionnent, elles introduisent une couche de virtualisation supplémentaire, avec un impact sur les performances, l’UX (montage de volumes, accès au réseau…) et parfois des limitations (disks, CPU partagés).

Apple, discrètement, semble vouloir changer la donne.

Container exécute des images OCI standard, mais n'utilise pas une seule VM Linux partagée. Au lieu de cela, il crée une petite machine virtuelle Linux pour chaque conteneur que vous démarrez. Cela semble lourd au premier abord, mais les VM sont légères et démarrent rapidement. Chacune est isolée, ce qui, selon Apple, améliore à la fois la sécurité et la confidentialité. Les développeurs peuvent exécuter localement des charges de travail conteneurisées grâce à la prise en charge native de macOS et sans avoir besoin d'installer des plateformes de conteneurs tierces.

Les conteneurs, pour mémoire, sont des paquets compacts qui contiennent une application et tout ce dont elle a besoin pour fonctionner. Les développeurs les utilisent pour garantir la cohérence entre le développement, les tests et la production. Ils sont largement utilisés dans les pipelines de CI et les environnements de serveur, car ils peuvent être déplacés d'une machine à l'autre sans interruption.

L'approche d'Apple avec Container reprend cette idée, mais remplace le modèle de VM partagée par des machines virtuelles minimales séparées. Elle s'appuie fortement sur les technologies Apple telles que le framework de virtualisation pour le lancement de machines virtuelles Linux, vmnet pour la mise en réseau, XPC pour la communication entre les processus et launchd pour le contrôle des services. L'outil prend même en charge Keychain pour le stockage des informations d'identification et utilise la journalisation macOS pour les diagnostics.

En quoi est-il différent de Docker ?

Alors que Docker s'appuie sur les primitives de conteneurisation intégrées à Linux (comme les espaces de noms et les cgroups), Container d'Apple utilise le cadre Virtulization.framework pour exécuter des conteneurs dans des micro-VM entièrement séparés. Cela signifie des limites de sécurité plus fortes, mais avec un surcoût de démarrage supplémentaire par rapport aux conteneurs Linux natifs.

Docker utilise une architecture basée sur des démons avec des systèmes de fichiers en couches et une configuration réseau complexe. Le conteneur d'Apple se concentre sur des composants plus simples et composables. Il n'y a pas de démon central, pas d'analyse de fichiers Docker ni de systèmes de fichiers superposés. Tout est géré à l'aide des API Swift et des commandes shell de la CLI.

Une approche native de la conteneurisation Linux

Contrairement aux approches traditionnelles qui reposent souvent sur une seule machine virtuelle Linux partagée, "Container" d'Apple propose une méthode plus intégrée et sécurisée. Chaque conteneur est exécuté dans une machine virtuelle Linux légère et dédiée, ce qui garantit une meilleure isolation et une sécurité accrue. Cette architecture minimise la surface d'attaque et simplifie la maintenance en utilisant un système de fichiers minimal.

L'outil tire parti des frameworks existants de macOS, offrant une intégration transparente avec l'écosystème Apple. Il permet aux développeurs de gérer les charges de travail conteneurisées localement avec un support natif, éliminant le besoin d'installer des plateformes de conteneurisation tierces. Des fonctionnalités telles que l'intégration du trousseau pour le stockage des informations d'identification et l'utilisation des journaux macOS pour le diagnostic soulignent cette approche native.

Ce qu’a lancé Apple sur GitHub

Tout commence avec un dépôt GitHub publié par Apple, nommé simplement Container. L’objectif est simple mais ambitieux : permettre l’exécution de conteneurs Linux « natifs » sur macOS, sans recours à une VM complète. Le code est écrit en Swift, spécialement optimisé pour les puces Apple Silicon.
Composants majeurs :

• container : outil en Swift pour créer et exécuter des conteneurs Linux sous macOS.
• container-builder-shim : interface entre le système hôte (Swift) et BuildKit, pour construire des images conteneurs.
• Émulation légère de conteneurs OCI (Docker) avec appui sur des services internes comme containerd, runc/buildkit adaptés.

Le dépôt Apple rejoint un effort déjà amorcé par la communauté open source (organisation macOScontainers), qui visait à forker containerd/buildkit/runc pour supporter macOS (à travers des projets comme darwin containers, rund, etc.)


Optimisation et avantages

Le nouveau framework de conteneurisation d'Apple est optimisé pour les puces Apple Silicon, promettant des performances améliorées et des temps de démarrage de sous-seconde pour chaque conteneur. Cette efficacité est cruciale pour les développeurs qui jonglent avec plusieurs environnements de développement. Chaque machine virtuelle légère reçoit une adresse IP dédiée, ce qui facilite la gestion des réseaux au sein des environnements conteneurisés.

L'outil de ligne de commande des conteneurs permet aux utilisateurs de créer des images, de démarrer des conteneurs et d'interagir avec les registres OCI. Il fonctionne avec un service d'arrière-plan appelé container-apiserver. Lorsque vous exécutez le démarrage du système de conteneurs, cet agent lance et gère tous les processus de support. Il s'agit notamment de container-core-images pour le stockage des images et de container-network-vmnet pour la gestion des fonctions réseau. Chaque conteneur en cours d'exécution obtient sa propre instance de container-runtime-linux, qui gère la communication avec la VM.

En termes de sécurité et de confidentialité, la création d'une machine virtuelle Linux distincte pour chaque conteneur est un avantage majeur. Cela améliore l'isolation des processus et offre un contrôle plus précis sur le partage de fichiers. Pour les entreprises et les développeurs soucieux de la sécurité, cette caractéristique est particulièrement attrayante.

Comme chaque conteneur possède sa propre VM, cette configuration permet une meilleure isolation. Cela signifie également que vous n'avez pas à surexposer les ressources de l'hôte lorsque vous montez des fichiers. Vous pouvez monter uniquement ce qui est nécessaire dans le conteneur, en évitant les configurations de partage de fichiers fourre-tout que certains autres outils requièrent.

Limitations et perspectives d'avenir

Si un conteneur tente d'accéder à un service sur 127.0.0.1, il n'atteindra pas votre machine hôte. Vous pouvez contourner ce problème en faisant pointer votre conteneur sur 192.168.64.1 et en utilisant socat pour transférer le trafic de cette adresse vers localhost. Ce n'est pas très élégant, mais cela fonctionne.

macOS ne prend pas actuellement en charge le ballonnement complet de la mémoire, de sorte que la mémoire libérée dans la VM Linux du conteneur peut ne pas être renvoyée à l'hôte. L'exécution de quelques grands conteneurs peut amener macOS à conserver plus de mémoire que nécessaire. Le redémarrage des conteneurs permet de récupérer cette mémoire.

Sur des versions plus anciennes comme macOS 15, l'expérience est pire. Les conteneurs ont été conçus pour macOS 26. Sur les systèmes plus anciens, le réseau entre les conteneurs ne fonctionne pas, l'attribution d'adresses IP peut échouer et la pile réseau peut se comporter de manière incorrecte. Apple ne prévoit pas de corriger les problèmes qui n'affectent que macOS 15.

Apple a publié un outil de développement sous une licence permissive et encourage les contributions de la communauté. Container et le paquetage de conteneurisation de niveau inférieur sont tous deux open source.

Le fait qu'Apple ait rendu "Container" open source sur GitHub est un signe positif. Cela encourage les contributions de la communauté et promet des améliorations continues et l'ajout de nouvelles fonctionnalités. Cette initiative démontre l'engagement d'Apple à soutenir les développeurs travaillant dans des environnements basés sur Linux tout en préférant le confort et l'efficacité de macOS.

Il ne remplace pas encore Docker, mais il s'agit d'une initiative intéressante de la part d'une entreprise qui traite généralement le terminal comme un passe-temps secondaire. Container ressemble à un véritable effort pour apporter le développement de conteneurs Linux natifs à macOS... avec la saveur propre à Apple.

Conclusion

Le lancement de "Container" par Apple est une étape significative pour les développeurs Linux sur macOS. En offrant une solution native, sécurisée et performante pour l'exécution de conteneurs Linux, Apple cherche à simplifier et à enrichir le flux de travail de développement. Bien que l'outil en soit encore à ses débuts avec quelques limitations, son statut open source et l'engagement d'Apple à l'améliorer suggèrent un avenir prometteur pour l'intégration du développement Linux sur la plateforme macOS.

Source : GitHub (1, 2)

Et vous ?

Selon vous, quel impact "Container" aura-t-il sur l'adoption de macOS par les développeurs Linux qui utilisaient auparavant d'autres systèmes d'exploitation pour leurs besoins de conteneurisation ?

Quels sont, à votre avis, les principaux défis techniques ou d'adoption que "Container" pourrait rencontrer, et comment Apple pourrait-il les surmonter ?

Pensez-vous que cette initiative d'Apple pourrait encourager d'autres géants technologiques à développer des solutions de conteneurisation plus natives pour leurs propres écosystèmes ?

Compte tenu des limitations actuelles et du statut open source, quelles fonctionnalités ou améliorations prioritaires souhaiteriez-vous voir ajoutées à "Container" dans les prochaines versions ?