- Ein Tool zum Erstellen und Ausführen von Linux-Containern auf dem Mac in Form leichtgewichtiger virtueller Maschinen
- Die auf der WWDC26 neu hinzugefügte Container Machine kann eine schnelle, leichtgewichtige und persistente Linux-Umgebung ausführen, bei der Home-Verzeichnis und Repositories automatisch eingehängt werden
- Anders als herkömmliche anwendungsbezogene Container wird die gesamte Linux-Umgebung modelliert (ähnlich wie WSL2)
- Das Init-System des Images kann ausgeführt werden, sodass sich langlebige Dienste registrieren oder Anwendungen unter einem Prozessmanager testen lassen
- Auf Images mit installiertem
systemd können echte Linux-Dienste wie systemctl start postgresql ausgeführt werden
- Benutzername und Home-Verzeichnis werden automatisch zugeordnet, sodass Repositories und Dotfiles sowohl unter macOS als auch unter Linux gemeinsam genutzt werden
- Repositories liegen im macOS-
$HOME und werden intern unter /Users/<username> eingehängt; Bearbeitung mit macOS-Editoren und -IDEs, während intern gebaut und ausgeführt wird
- macOS-native Werkzeuge wie Profiler, Browser und GUI-Debugger erkennen dieselben Dateien, sodass zwischen Build und Analyse kein Kopierschritt nötig ist
- Container Machines können für jede gewünschte Distribution wie
alpine, ubuntu oder debian erstellt werden; durch gemeinsames $HOME und gemeinsame Dotfiles sind schnelle Tests über mehrere Distributionen hinweg möglich
- Jedes Linux-Image mit
/sbin/init kann direkt als Container-Machine-Image verwendet werden
- Da OCI-kompatible Container-Images konsumiert und erzeugt werden, lassen sich Docker-Images auch aus Standard-Container-Registries pullen und pushen
- Diese Images können auch in anderen OCI-kompatiblen Anwendungen ausgeführt werden
- Das Low-Level-Management von Containern, Images und Prozessen basiert auf dem Containerization Swift Package
- Für die Ausführung ist ein Mac mit Apple silicon erforderlich, unterstützt unter macOS 26
- Nutzt neue Funktionen und Verbesserungen bei Virtualisierung und Networking in macOS 26; ältere macOS-Versionen werden nicht unterstützt
- Apache-2.0-Lizenz
Befehle
container machine create alpine:latest --name dev
container machine run -n dev whoami # your host username, not root
container machine run -n dev pwd # /home/<you> — your Mac home dir, mounted in
container machine run -n dev # interactive shell; cd into your repos in $HOME
container machine ls # list all container machines
container machine inspect dev # JSON detail for one
container machine stop dev # stop the container machine
container machine rm dev # delete, including its persistent storage
container machine set -n dev cpus=4 memory=8G
container machine stop dev
container machine run -n dev -- nproc
- Containerization ist ein auf der WWDC 25 als Open Source veröffentlichtes Swift-Framework und bildet die Grundlage für das Ausführen von Linux-Containern auf macOS
- Es wurde so entworfen, dass jeder Container VM-basierte Isolation erhält; durch die leichtgewichtigen virtuellen Maschinen bietet es hohe Geschwindigkeit und Startzeiten unter einer Sekunde
- Container machine ist eine neue Funktion, die auf Containerization aufbaut und die Nutzbarkeit und Geschwindigkeit von Containern mit der Persistenz virtueller Maschinen kombiniert; durch die Integrationsfunktionen fühlt sich die Linux-Umgebung wie eine Erweiterung von macOS an
-
Designprinzipien
- Container machine muss schnell und leichtgewichtig sein, damit sie sich in bestehende Workflows integrieren lässt
- Der Wechsel zwischen macOS und Linux muss einfach sein
- Nutzer sollen neue Umgebungen schnell erstellen und anpassen können, damit mehrere Projekte dedizierte Umgebungen haben können, ohne sich um Abhängigkeiten oder Toolchain-Konflikte sorgen zu müssen
- Da sich die für den Entwicklungslebenszyklus benötigten Werkzeuge und Abhängigkeiten ändern können, müssen sich Werkzeuge in einer persistenten Umgebung hinzufügen und auch später wiederverwenden lassen
- Bei der Entwicklung für mehrere Plattformen sollte kein großer Kontextwechsel und kein Erlernen neuer Werkzeuge erforderlich sein
3 Kommentare
Wird die Leistung ausreichend sein?
Egal wie ich es mir ansehe, wirkt es wie die Mac-Version von WSL2. Ich frage mich, ob es auch hier keinen starken Einbruch der I/O-Leistung gibt, wenn man Host-Volumes mapped.
Schon jetzt lasse ich mit
limactlContainer auf einer VM laufen, daher fühlt es sich auch nicht wirklich groß anders an.Hacker-News-Kommentare
Um hier ein paar Dinge klarzustellen: Das bezieht sich nicht nur auf OCI-Container
Container Machines unterstützen Persistenz und Dateisystem-Mounts und sind damit für Entwickler auf macOS eine hervorragende leichtgewichtige Linux-Umgebung
Mehr dazu hier: https://developer.apple.com/videos/play/wwdc2026/389
OrbStack passt für mich sehr gut
Ich frage mich, wie es sich leistungsmäßig damit vergleichen würde
Anstelle von Virtualization.framework verwenden wir direkt einen Rust-basierten Virtualisierungs-Stack mit eigenen Geräten und Protokollen für Dinge wie Dateisystem-Freigaben
Das ist ein vertikal integrierter Stack, der speziell für das Ausführen von Linux-Maschinen und Containern hochgradig optimiert ist
Der größte Performance-/Ressourcenvorteil ist dynamischer Speicher, der ungenutzten Speicher an macOS zurückgibt und so den Speicherverbrauch stark reduziert
Andere, einschließlich Containerization, unterstützen das nicht
Nachdem ich Container Machines ausprobiert habe, wirkt es auf mich viel näher an OCI-Containern mit standardmäßig angehängten Bind-Mounts als an OrbStack-Maschinen
Es gibt weniger Integrationsfunktionen, und da weder systemd noch ein übliches init-System läuft, ist es schwierig, Dienste auszuführen
Ich würde jetzt eher Podman oder Colima verwenden
Für mich wirkt das ziemlich ähnlich
Optional kann auch dockerd ausgeführt werden, und https://github.com/cpuguy83/crucible startet buildkitd oder dockerd mit dem Containerization-Framework und verbindet sich dann mit docker/buildx CLI oder den gewünschten Client-Tools
Das Containerization-Framework ist eine Bibliothek auf dem Virtualization-Framework, daher ist jeder Container seine eigene VM
Machine ist ein Tool auf dem Containerization-Framework, das mehrere Aufgaben in Containern innerhalb einer VM ausführt
Teilen sich diese Container einen gemeinsamen Kernel? Oder läuft jeder in einer eigenen VM?
Bearbeitung: Pro Container gibt es eine VM https://github.com/apple/container/blob/main/docs/technical-...
Apple-Container eignen sich gut, um AI-Coding-Agenten eine Sandbox bereitzustellen
Ich habe daraus MCP gemacht, damit es von allen Coding-Agenten leicht entdeckt werden kann
https://github.com/instavm/coderunner
Ich habe mich gefragt, ob man das Container-Volume z. B. auf ein externes Laufwerk umstellen kann
Momentan mache ich das mit QMEU- und qcow2-Images, und das funktioniert einigermaßen gut
Ich frage mich, warum macOS nicht den WSL1-Ansatz versucht
Ich verstehe, warum das unter Windows nicht vollständig erfolgreich war, aber macOS ist ein anderes *nix, daher scheint vieles, was unter Windows schwierig war, auf dem Mac einfacher zu sein
Mit nur ein paar neuen APIs müsste es möglich sein, die meisten Linux-Anwendungen nativ auf macOS auszuführen
Etwas in der Art gibt es auf BSD tatsächlich bereits
Im Vergleich zum Linux-Kernel ist die ABI doch viel einfacher und stabiler
Könnte das Docker-Desktop-ähnliche Lösungen ersetzen und die teure Linux-VM, die daneben läuft, überflüssig machen?
Der Docker-Desktop-Overhead ist ziemlich heftig, und es wäre schön, wenn das nativ in DD landen würde
Wenn man bedenkt, dass Docker historisch versucht hat, die Performance zu verbessern, dann aber schnell die Plattformgrenzen akzeptieren musste, scheint das möglich, und es wirkt natürlich, DD stärker in Richtung Container zu verschieben
Ich habe damit experimentiert, meine Podman-Workloads auf Apple container umzustellen: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
Kurz gesagt sinken RAM- und Speicherverbrauch, und das Ganze fällt kaum auf
Es ist mühsam, um Docker Desktop herumzuarbeiten
Ich habe das Gefühl, alle paar Tage
rm -rf ~/.colimaauszuführenIch bin überrascht, dass Apple genug Interesse daran hatte, das zu machen
Trotzdem möchte ich weiterhin Linux nutzen, aber der Wert eines MacBook ist enorm
Dieses Tool werde ich vielleicht nutzen
Jedes Mal, wenn ich sehe, wie Apple mit Linux-Containern angibt, fällt es mir schwer, das anders als ein Eingeständnis der Niederlage zu sehen
Wenn sie noch die Fähigkeiten dafür hätten, hätten sie das auch vollständig mit Darwin machen können
Warum sollte ein ernsthafter Entwickler geschlossenen Quellcode verwenden, den er nicht debuggen und ändern kann, besonders auf einem Produktionsserver?
Aus demselben Grund verwenden ernsthafte Entwickler oder Hacker kein macOS
Einer der Kerngedanken des Entwicklerseins ist schließlich die Fähigkeit, sich in jede Code-Ebene einzugraben, zu debuggen und Dinge zu reparieren
Apple hat den Servermarkt schon vor 10 Jahren aufgegeben, und auch davor gab es kaum ernsthafte Unterstützung
Selbst wenn sie Darwin-Container unterstützen würden, was würde das bedeuten? Wörtlich niemand würde dafür bauen, Linux hat gewonnen
Ist das eine neue Funktion?
Ich dachte, das gäbe es schon
Als ich es getestet habe, war die Dateisystem-Performance in Node-/Rust-Entwicklungsumgebungen mit vielen kleinen
stat-Aufrufen nicht brauchbarUpdate: Neu ist der Unterbefehl
container machineIch wollte es testen, aber in meiner Umgebung startete container überhaupt nicht: https://github.com/apple/container/issues/1681
Es gibt noch mehr zu tun, aber ich freue mich über Workloads zum Testen
Wir haben viel Arbeit investiert, um in OrbStacks eigenem Protokoll für Dateisystem-Freigaben kleine Dateien und typische Entwickler-Workloads zu optimieren
Es ist nicht das standardmäßige virtiofs
Es verwendet das vorhandene container-Framework, um Maschinen auszuführen
Das geht sowohl mit Root-Rechten als auch rootless