macOS Containers permet d’installer macOS dans un conteneur Docker
Docker est probablement la solution la plus utilisée aujourd’hui pour lancer des systèmes virtuels et isolés dans ce que l’on nomme des conteneurs, pour filer la métaphore portuaire. Mais Docker est pensé à la base pour les systèmes d’exploitations basés sur GNU/Linux ou FreeBSD, pas pour macOS qui peut certes être virtualisé, mais qui nécessite une couche de virtualisation plus complexe pour fonctionner normalement. Enfin, qui nécessitait : en effet, macOS Containers est un projet qui permet d’installer le système d’exploitation d’Apple au sein d’un conteneur Docker.
Parvenir à un tel résultat n’est pas simple et il faut noter que le projet est encore loin d’être finalisé et stable. On est plutôt dans le domaine de l’expérimentation intéressante à ce stade et mieux vaut éviter d’utiliser macOS Containers sur des projets importants. Par ailleurs, il faut retirer quelques sécurités importantes du système, en particulier SIP qui doit être désactivé pour pouvoir créer un conteneur avec macOS à l’intérieur. Même quand c’est fait, il ne faut pas s’attendre à un niveau d’isolement aussi bon que dans un conteneur Linux, en raison de restrictions imposées par Apple.
Si cela ne vous effraie pas, la procédure à suivre pour installer macOS Containers est détaillée à cette adresse. Le gestionnaire de paquets Homebrew est nécessaire pour installer toutes les dépendances et si tout va bien, vous pourrez lancer à la fin du processus un conteneur avec macOS Ventura. Seule cette version est proposée pour le moment et côté hôte, il faut un Mac sous macOS Catalina ou plus récent.
macOS Containers est un projet open-source qui repose en son cœur sur rund, une version modifiée de containerd, le standard qui permet de créer et gérer des conteneurs.
A quoi ça peut servir (par curiosité) ?
Je trouve remarquable que certaines personnes s’investissent autant dans des projets demandant autant d’énergie pour une si faible audience.
Ça me semble être une gigantesque perte de temps, mais je me réjoui que tout le monde ne pense pas ainsi.
@fte
Certainement aussi utile que le portage de Doom sur AppleWatch!
Toutefois, là où tu cherches une raison absolument pratique, ce qui est peut-être le cas et est éventuellement l'objectif visé, j'y vois essentiellement une "prouesse" technique intéressante pour des personnes qui veulent s'essayer aux techniques de Docker et relever un défi technique stimulant intellectuellement.
Est-ce que quelqu'un qui connaitrait bien Docker pourrait expliquer la différence entre cette solution et une solution de machines virtuelles comme celles (proposées avec le framework Virtualization d'Apple ou pas d'ailleurs) comme Parallels Desktop, VMware ou encore VirualBox ?
J'ai jamais compris exactement ce qu'était Docker, et ici, quelle est la plus-value de Docker / macOS Containers face à VMware pour virtualiser macOS ?
@skarel
Une machine virtuelle, c’est tout le système d’exploitation : Linux, Windows, etc.
Docker, c’est juste une couche de virtualisation avec le minimum syndical pour faire tourner une application. Et pas le système d’exploitation en entier.
Ça sert à faire tourner énormément d’applications. Je m’en sers un peu sur mon NAS : homebridge, etc. Il y a des tonnes d’applications que tu peux faire tourner avec. L’avantage, c’est que ça prend peu de ressources comparer à une machine virtuelle.
https://datascientest.com/docker-guide-complet
@RonDex
Un peu à la manière de Wine sous MacOS ou Linux, non?
Pour emuler Windows
@fredsoo
On gros oui.
@skarel
Docker, c'est pour créer plein de (si possible) petites machines virtuelles "stateless", servant généralement de serveur. Elles peuvent ainsi être déployées rapidement chez un hébergeur qui accepte les containers, et également de "scaler" rapidement, c'est-à-dire qu'en cas de pic de charge, tu peux multiplier le nombre d'instances du même conteneur, pour absorber la charge en parallèle.
Parallels, Fusion ou VirtualBox te permettent simplement d'installer sur ton poste un système différent en cas de besoin, et donc d'y travailler via une interface graphique. Leur intérêt est donc généralement d'avoir un OS différent.
Les containers, en revanche, n'ont généralement pas d'interface graphique, et font un travail de serveur. Leur intérêt est principalement la flexibilité du déploiement de serveurs, pas d'utiliser un OS différent.
Une image de conteneur est une archive (comme un zip mais au format .tar) qui contient des fichiers. Comme l'image peut contenir de nombreux fichiers, on peut y inclure le programme qui nous intéresse (par exemple un serveur web) et tout un tas de dépendances logicielles nécessaires nécessaire à celui-ci mais qui ne nous intéresse pas, et qu'il faudrait installer à la main.
Une fois une image récupérée on peut s'en servir pour lancer le programme principal qu'il contient. C'est le même principe qu'un .exe qu'on peut utiliser pour lancer un soft. La grande différence avec un exécutable (.exe) c'est que les dépendances logicielles sont déjà incluses, donc pas besoin de s'embêter à les installer, ce qui fait gagner énormément de temps. Ca permet de répliquer des environnements identiques très facilement.
En fait le gros problème pour expliquer les conteneurs c'est qu'ils ont des aspects différents qui intéressent plus ou moins certains utilisateurs : les développeurs (comme moi) vont être intéressé par la possibilité de récupérer un logiciel tiers et de s'en servir facilement (une base de données par exemple) ou de faire coller au plus près l'environnement de développement à celui de déploiement. Du côté des administrateurs systèmes ou des devops c'est plutôt la souplesse par rapport aux machines virtuelles qui va être intéressante. En fonction du point de vue, l'explication peut-être radicalement différente.
@RonDex et @PetrusM et @unixorn: Merci à vous pour ces réponses :-)
Je comprends maintenant un peu qu'il s'agit de machines virtuelles plus légères, moins complètes sur le plan de l'OS mais plus flexibles que celles de hyperviseurs classiques, et directement axées sur le lancement d'une config logicielle bien précise.
Après, un point qui reste encore flou pour moi est qui décide de ce "minimum syndical" auquel fait référence RonDex ? Est-ce que produire un son (donc la couche audio de l'OS) en fait partie ? Lire un film (donc la couche vidéo) ? Faire fonctionner un périphérique (donc la couche drivers) ? Afficher une fenêtre (donc la couche d'interface graphique de l'OS) ? Et en définitive, de quelle partie de l'OS peut-on véritablement se passer (même un service comme iCloud, que beaucoup d'applications savent aujourd'hui utiliser) sans qu'il n'y ait de défaut majeur dans les fonctions de l'OS et des applications lancées dans un Conteneur ?
@skarel
Les conteneurs ne sont pas faits pour l'ensemble des fonctions que tu cites. Ils ne sont pas destinés au grand public, et ne s'exécutent sur un ordinateur "grand public" que pour les développeurs qui les mettent au point... Sinon ils ne tournent que sur des serveurs de virtualisation, pour fournir des services "cloud" pour des sites web, applications, etc. C'est pourquoi ils n'ont généralement besoin ni d'interface graphique, ni de son.
Et, pour répondre à ta question, le "minimum syndical" est très différent selon les utilisations, et donc chaque développeur peut se baser sur un conteneur ayant les fonctionnalités dont il a besoin pour développer le sien. Mais 7,35Go comme ici, c'est très gros pour un container... J'en ai vu sous Alpine Linux, qui font 35 Mo par exemple !
@skarel
Tout dépend de ce qui tu installe et connecte à ton conteneur. Mais, oui, tu peux très bien lancer un Firefox depuis un conteneur. Et avoir une interface graphique, du son,… Même si un flatpack ou snap (uniquement sous Linux) sera plus optimisé pour ce besoin.
En fait, il y a différentes versions minimales des OS. Et certains sont plus optimisés pour certaines tâches et d’autres sont plus génériques.
En fait, les conteneurs « Docker » lance, en gros, une image disque avec le kernel Linux de l’hôte et l’isole du système de base. Et, sur macOS et Windows, tu lance une machine virtuelle Linux optimisé pour Docker. Et tes conteneurs vont fonctionner dedans. Sur Linux, pas besoin de machine virtuelle, le conteneur va se lancer directement grâce à Docker et à la magie du kernel Linux. (Le concept de conteneurs existent aussi sous Windows et macOS, l’un via Docker et les Windows Containers et macOS via le sandboxing)
Le but d’un conteneur est d’isoler au maximum un ou plusieurs programmes sans l’impact de performance d’une machine virtuelle. Et avec une taille de stockage et une empreinte mémoire réduite. Et vu que ceux-ci sont isolés, cela apporte plein d’avantages mais aussi quelques inconvénients. On peut faire tourner plusieurs versions d’un même logiciel en même temps par exemple. Les faire tourner sur de multiples serveurs. Et de façon plus rapide que de multiples machines virtuelles.
Les machines virtuelles et les conteneurs sont beaucoup plus complémentaires que l’un versus l’autre. Les machines virtuelles permettent de faire tourner d’autres OS et sont considérées comme plus sécurisées et les conteneurs sont plus performant tout en offrant une meilleure agilité.
Sinon, une idée de la taille de container résultante ?
@PetrusM
Sur le screenshot, on peut voir 7,35GB 😅
Pas possible de le faire dans un machine virtuelle pour éviter de désactiver SIP sur la machine?
Où vont ces 7,35 GB de la copie d'écran ? Je voudrais faire le ménage.