Apple lance une alternative à Docker propulsée par Swift pour macOS

Apple a présenté une alternative open source à Docker, propulsée par Swift, pour exécuter des conteneurs Linux sur macOS, axée sur la sécurité et l'isolation.

Apple a discrètement lancé un nouveau projet open source qui pourrait modifier de manière significative la façon dont les conteneurs sont exécutés sur macOS. Simplement nommé container, il introduit un runtime de conteneur natif Apple propulsé par Swift, conçu spécialement pour les systèmes macOS, en particulier ceux fonctionnant sur Apple Silicon.

Au cœur, container permet aux utilisateurs de télécharger, construire, exécuter et pousser des conteneurs Linux conformes à la norme OCI. Cependant, contrairement à Docker, qui repose généralement sur une machine virtuelle partagée pour tous les conteneurs sur macOS, l’approche d’Apple exécute chaque conteneur dans sa propre micro-VM légère, complète avec un noyau Linux isolé et une pile réseau. Selon la page GitHub du projet :

L'outil consomme et produit des images de conteneur conformes à OCI, ce qui vous permet de tirer et d'exécuter des images depuis n'importe quel registre de conteneurs standard. Vous pouvez également pousser les images que vous créez vers ces registres et exécuter les images dans toute autre application conforme à OCI.

Ce modèle reflète le concept des microVMs popularisé par des outils comme Firecracker, mais il a été étroitement intégré à macOS via le Virtualization.framework, l’interface hyperviseur native d’Apple.

Bien qu'Apple ne présente pas cela comme un remplacement complet de Docker, l'outil couvre néanmoins une grande partie des mêmes usages pour le développement local. La ligne de commande est familière et accessible : avec des commandes comme container image pull alpine ou container run -ti alpine sh.

Ce qui distingue cet outil, c’est son intégration transparente dans le système d’exploitation macOS lui-même. Plutôt que d’émuler un environnement Linux avec des outils externes, la solution d’Apple utilise Swift pour une grande partie de son environnement utilisateur, y compris un petit système init nommé vminitd qui démarre les conteneurs en quelques millisecondes.

Le projet comprend également un package Swift, « Containerization », qui expose des API de bas niveau pour gérer les images, les volumes, le réseau et les processus de démarrage, offrant aux utilisateurs avancés et aux créateurs d'outils une base puissante.

D'accord, jusqu'ici tout va bien, mais maintenant, laissez-moi partager quelques réflexions personnelles sur le sujet. Honnêtement, je suis un peu confus par ce geste d'Apple. Et je vais expliquer pourquoi tout de suite.

Tout d'abord, clarifions une chose : il n'existe pas de véritable conteneurisation native sur un système d'exploitation autre que Linux, et il y a une raison simple à cela. Docker repose sur des fonctionnalités du noyau spécifiques à Linux comme les cgroups, les espaces de noms et les systèmes de fichiers superposés, que le noyau de macOS ne peut pas fournir.

Pour cette raison, le nouveau projet d’Apple utilise une machine virtuelle Linux légère séparée pour exécuter chaque conteneur. En même temps, l’approche de Docker consiste à exécuter tout à l’intérieur d’une seule machine virtuelle (construite avec LinuxKit) qui héberge le moteur Docker et tous les conteneurs.

Donc, dans le cas d’Apple, chaque conteneur se trouve dans sa propre machine virtuelle, ce qui signifie beaucoup de machines virtuelles (peu importe leur légèreté), ce qui ne semble pas être l’approche la plus efficiente.

D'un autre côté, les machines virtuelles séparées ont certains avantages. Par exemple, un des principaux avantages du nouveau projet d'Apple est qu'il offre à chaque conteneur son propre noyau Linux dédié, contrairement à Docker, qui partage un seul noyau entre tous les conteneurs (il est impossible de mélanger différentes versions de noyaux par conteneur).

De plus, il utilise également la pile réseau native de macOS, tandis que Docker repose généralement sur une machine virtuelle avec NAT ou un réseau en pont. Pour clarifier cela, j’ai préparé un tableau comparatif rapide :

Malgré toutes les différences, l'idée de base reste la même dans les deux cas : créer, exécuter et travailler avec des images de conteneurs conformes à OCI. De ce point de vue, Docker offre toujours beaucoup plus de flexibilité et de fonctionnalités que le nouveau projet d'Apple.

Par exemple, il n’existe pas encore d’équivalent de docker-compose, et l’écosystème d’outils (par ex. pas de tableau de bord GUI, orchestration limitée) doit encore être développé et amélioré.

Alors, je me demande pourquoi Apple a mis autant d'efforts pour créer ça. À part « Made by Apple », il semble qu'ils veuillent obtenir leur part de ce créneau massif, presque entièrement dominé par Docker, en offrant une meilleure intégration macOS, en utilisant des API natives du système plutôt que des démons tiers, et finalement, une meilleure isolation sécuritaire, ce qui réduit la surface d'attaque.

Comme le projet en est encore à ses débuts, il sera intéressant de voir comment il évolue — et s’il pourra répondre aux attentes d’Apple en finissant par remplacer Docker ou Podman comme l’outil de conteneur incontournable pour les développeurs sur macOS.