Containerization – ein Swift-Paket zum Ausführen von Linux-Containern auf macOS

 (github.com/apple)
6 Punkte von GN⁺ 2025-06-10 | 1 Kommentare | Auf WhatsApp teilen
  • Containerization ist ein Swift-basiertes Open-Source-Tool, mit dem sich Linux-Container auf macOS ausführen lassen
  • Es läuft auf Apple-Silicon-basierten Macs und nutzt Virtualization.framework, um jeden Container isoliert in einer leichtgewichtigen virtuellen Maschine auszuführen
  • Es umfasst verschiedene Funktionen wie OCI-Image-Verwaltung, Anbindung an entfernte Registries, Erstellung von ext4-Dateisystemen und Steuerung der Containerumgebung
  • Mit Rosetta 2 kann auch auf Apple Silicon die Ausführung von x86_64-Prozessen unterstützt werden
  • Extrem kurze Bootzeiten, leichtgewichtige Umgebungen und Kernel-Version-Customizing erhöhen Flexibilität und Performance für Entwickler

Projektüberblick

  • Containerization ist ein Swift-Paket, das Anwendungen bei der Nutzung von Linux-Containern unterstützt
  • Es ist in Swift implementiert und läuft auf Apple-Silicon-basierten Macs mithilfe von Virtualization.framework
  • Über die API werden unter anderem folgende Funktionen bereitgestellt
    • Verwaltung von OCI-Images
    • Anbindung an entfernte Container-Registries
    • Erstellung und Bereitstellung von ext4-Dateisystemen
    • Interaktion mit der Netlink-Socket-Familie
    • Bereitstellung eines optimierten Linux-Kernels für schnelles Booten
    • Erstellen und Verwalten leichtgewichtiger virtueller Maschinen
    • Steuerung der Laufzeitumgebung virtueller Maschinen
    • Erzeugen und Steuern containerisierter Prozesse
    • Ausführung von x86_64-Prozessen auf Apple Silicon mithilfe von Rosetta 2
  • Die API-Dokumentation ist auf einer offiziellen Seite verfügbar

Design und Architektur

  • Jeder Linux-Container läuft in einer eigenen virtuellen Maschine
  • Für jeden Container kann eine dedizierte IP-Adresse vergeben werden, wodurch sich das Netzwerk auch ohne Port Forwarding einfach verwalten lässt
  • Dank optimierter Kernel-Konfiguration und eines leichtgewichtigen Root-Dateisystems sind Container-Bootzeiten von unter einer Sekunde möglich
  • vminitd ist ein Teilprojekt von Containerization und ein leichtgewichtiges Init-System, das in der virtuellen Maschine als Initialprozess läuft
    • Über eine GRPC-API wird die Laufzeitumgebung konfiguriert und der Betrieb containerisierter Prozesse unterstützt
    • Ein-/Ausgabe, Signale und Ereignisverarbeitung werden an den aufrufenden Prozess weitergereicht

Anforderungen

  • Ein Apple-Silicon-Mac ist erforderlich
  • Für den Build des Pakets wird benötigt
    • macOS 15 oder neuer und Xcode 26 Beta
    • oder macOS 26 Beta 1 oder neuer
  • Bei der Nutzung unter macOS 15 sind folgende Funktionen eingeschränkt
    • Nicht isoliertes Container-Networking: Keine Kommunikation zwischen Containern im selben vmnet-Netzwerk möglich

Anwendungsbeispiele

  • Bereitgestellt wird die ausführbare Datei cctl: eine Playground-ähnliche Umgebung, in der sich verschiedene API-Funktionen ausprobieren lassen
    • Wichtige Befehlsbeispiele
      • Bearbeitung von OCI-Images
      • Login bei Container-Registries
      • Erzeugung von Root-Dateisystem-Blöcken
      • Ausführen eines einfachen Linux-Containers

Linux-Kernel-Konfiguration

  • Zum Ausführen leichtgewichtiger virtueller Maschinen für Container wird ein Linux-Kernel benötigt
  • Die von Containerization bereitgestellte optimierte Kernel-Konfiguration befindet sich im Verzeichnis kernel
  • Diese Konfiguration enthält nur die minimal erforderlichen Funktionen und ermöglicht dadurch schnelles Booten und eine leichtgewichtige Umgebung
  • Es gibt eine API, mit der sich je Container unterschiedliche Kernel-Konfigurationen und -Versionen festlegen lassen
    • Dadurch können verschiedene Kernel-Versionen und Konfigurationen getestet werden
  • Vorab kompilierte Kernel wie vmlinux.container aus dem Projekt Kata Containers können verwendet werden
    • Voraussetzung ist allerdings, dass VIRTIO-Treiber direkt in den Kernel einkompiliert sind (compiled-in)

Zusammenfassung des Entwicklungs- und Testprozesses

  • Die Umgebung muss mit Swift, Static Linux SDK und weiteren Komponenten vorbereitet werden
  • Der Source Code kann gebaut und getestet werden (make all, make test integration usw.)
    • Für die Ausführung von Integrationstests wird ein Kernel-Image benötigt
  • Unterstützt wird eine Abhängigkeitskonfiguration mit bestimmten Versionen rund um gRPC/Protobuf
  • Es gibt Funktionen zur automatischen Generierung der API-Dokumentation und zur lokalen Vorschau

Open-Source-Beiträge und Projektstatus

  • Beiträge sind willkommen
  • Version 0.1.0 ist das erste offizielle Release; Stabilität des Source Codes wird nur innerhalb desselben Minor-Version-Bereichs garantiert
  • In künftigen Minor-Releases sind Änderungen an dieser Richtlinie möglich

Fazit

  • Containerization ist ein innovatives Swift-Paket, mit dem Entwickler Linux-Container auf macOS in einer optimierten Umgebung verwalten, ausführen und entwickeln können
  • Durch den Betrieb jedes Containers in einer eigenen leichtgewichtigen virtuellen Maschine bietet es Vorteile bei Isolation, Performance, Networking und Kernel-Customizing
  • Es ist eine passende Lösung für Entwickler, die Open-Source-Container-Umgebungen zu einer nativen macOS-Erfahrung erweitern möchten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-10
Hacker-News-Kommentare

  • Ich teile den Punkt, den ich am überraschendsten und interessantesten finde

    Dass Beiträge zum Projekt "container" willkommen sind und sogar ausdrücklich gefördert werden, wirkt wie eine ziemlich ungewöhnliche Haltung von Apple.
    WebKit war ein feindseliger Fork von KHTML, und auch bei Darwin fühlte es sich so an, als hätte man nur über die Mauer hinweg hier und da ein paar Teile zugeworfen bekommen.
    Ich hoffe, dass sich bei solchen Projekten, die Apple zuletzt auf GitHub veröffentlicht hat, eine lebendige Zusammenarbeit zwischen Nutzern und Entwicklern entwickelt.
    Ich bin eigentlich eher F/OSS-orientiert, kann Linux wegen Firmenrichtlinien aber nicht nutzen und muss deshalb notgedrungen jeden Tag mit einem Mac arbeiten.
    Seit der Einführung von Apple Silicon habe ich auch meinen privaten Laptop auf einen Mac umgestellt, aber inzwischen kommen Linux-freundliche Alternativen immer näher, was meine Erwartungen steigen lässt.
    Solche Veränderungen sind ein positives Signal und für Nutzer wie mich, die innerlich mit diesem Thema gehadert haben, auch eine beruhigende Entwicklung.
    Falls diese Open-Source-Zusammenarbeit tatsächlich zu einem positiven Kreislauf führt, könnte daraus eine deutlich stärkere Kultur der Zusammenarbeit zwischen Apple und der Community entstehen.
    Ich stelle mir vor, dass Entwickler wie ich von diesem Wandel nicht nur ganz direkt profitieren, sondern dabei auch wieder mehr Respekt für Apple entwickeln könnten.

    • Die Meinung, dass Apples Beteiligung an der Open-Source-Community gar nicht so überraschend sei
      Erwähnt wird, dass es auch bei Swift und den dazugehörigen Frameworks viele Beiträge aus der Open-Source-Community gibt.

    • Da sich dieses Projekt mit Linux befasst, gibt es auch die Sichtweise, dass Apple wegen des Copyleft-Charakters von Linux bzw. der starken Open-Source-Lizenzierung gar nicht anders kann, als auf Zusammenarbeit zu setzen.

  • Als passendes Video wird die WWDC-2025-Session empfohlen (https://developer.apple.com/videos/play/wwdc2025/346/)
    Die Struktur trennt jeden Container als leichtgewichtige Linux-VM.
    Das container-Tool kann man direkt herunterladen und selbst ausführen (https://github.com/apple/container/releases), macOS 26 ist erforderlich.

    • Dieser Eintrag hier betrifft https://github.com/apple/containerization und nicht das Projekt container.
      containerization ist spannender, weil es dafür gedacht ist, Apps zusammen mit einem Container-Sidecar auszuliefern.
      container dagegen ist für Entwickler gedacht, die eine Umgebung wie docker run ... nutzen wollen.
      Für container gibt es einen separaten HN-Thread (https://news.ycombinator.com/item?id=44229239).

    • Es läuft auch unter macOS 15, allerdings können einige Netzwerkfunktionen eingeschränkt sein.

  • In der Pressemitteilung und in der WWDC-Session wird erwähnt, dass das CLI-Tool unter https://github.com/apple/container liegt.
    Aus Sicht von jemandem, der sich sehr für solche Tools interessiert, hatte ich gehofft, dass es im neuesten Xcode Beta bereits standardmäßig enthalten ist, aber das ist noch nicht der Fall.
    Vorgebaute Pakete sind derzeit in Arbeit; den Fortschritt kann man im öffentlichen Issue verfolgen (https://github.com/apple/container/issues/54).

  • Ich frage mich, wie sich das aus Sicht von Docker anfühlen muss.
    Ich vermute, dass ein beträchtlicher Teil der Docker-for-Desktop-Nutzer Macs verwendet.

    • Die Meinung dazu ist, dass diese Änderung die Entwicklung von Docker Desktop eher deutlich erleichtert.
      Man muss nun keine eigene Linux-VM mehr selbst aufsetzen, was die Entwicklung vereinfacht.
      Trotzdem dürften viele Nutzer wegen der vertrauten CLI, Docker Compose und der verschiedenen Docker-spezifischen UX-Elemente weiterhin Docker Desktop bevorzugen.
      Den Container-Runtime auszutauschen ist keine einfache Sache.

    • Vermutlich fühlt es sich für Docker ähnlich an wie im Umgang mit podman.

    • Da Docker Desktop proprietäre kommerzielle Software ist und dieses Projekt freie Software, ist das aus Nutzersicht eine gute Nachricht.

  • Ich frage mich, ob sich diese Technik dafür verwenden lässt, Linux-Container in MacOS-Apps zu bündeln.
    Als Beispiel: wenn ein Tool wie GPT ohne Root-CLI-Befehle Zugriff auf eine Linux-Umgebung bekommen soll.

    • Wenn es auch nur unter MacOS 26 laufen darf, dann lässt es sich sofort genau für diesen Zweck einsetzen.
      Alternativ kann man auch direkt Virtualization.framework verwenden, aber das erfordert zusätzlichen Aufwand.

    • Die Überzeugung, dass diese Technik genau für diesen Zweck entwickelt wurde.

  • Die Architektur ist interessant: Jeder Container läuft in einer eigenen isolierten VM, mit vollständiger Trennung und eigener IP, aber so ein Design ist unter Linux oder Windows eher unüblich.
    Wenn im Entwicklungsteam auch nur eine Person keinen Mac nutzt, bricht das lokale Entwicklungsmodell auseinander.
    Das Fazit lautet daher, dass es Docker/Compose nur schwer ersetzen kann.

  • Von den drei großen Desktop-Betriebssystemen können jetzt zwei offiziell Linux-VMs ausführen und damit Linux-native Anwendungen betreiben.
    Daraus könnte man schließen, dass Linux faktisch gewonnen hat.
    Die Linux-Systemaufruf-API ist damit inzwischen fast überall zu einer universellen API geworden.

    • Dagegen steht der Einwand, dass es schwer als "Sieg von Linux" zu bezeichnen ist, wenn Linux-basierte Anwendungsentwicklung erst auf zwei großen Nicht-Linux-Betriebssystemen vernünftig möglich sein muss.
      Dazu kommt die Erfahrung, dass Desktop-Linux in der Praxis weiterhin instabil und nur schwer empfehlenswert ist.
      Es wird offen gesagt, dass Fedora oder Ubuntu jedes Jahr auf aktueller PC- oder Laptop-Hardware ausprobiert werden, aber Nutzbarkeit und Stabilität noch immer nicht überzeugen.

    • Eine andere Sicht ist, dass die beiden anderen Plattformen damit einen Weg anbieten, Linux zu nutzen, ohne Linux selbst zu verwenden, was das Wachstum des Linux-Anteils auf dem Desktop eher bremst.

    • Als Nachteil wird hervorgehoben, dass es für Grafik, Audio und GUI weiterhin keine wirklich gute Lösung gibt.

    • Es wird die Frage gestellt: "Gewinnt man ein Spiel, wenn man der einzige Spieler darin ist?"
      Dazu der Scherz, dass normale Windows- oder Mac-Nutzer oft nicht einmal wissen, was Linux überhaupt ist.

    • Allein die Tatsache "macOS mit Linux" sei schon ein starkes Signal.

  • Ich frage mich, ob auch das Speichermanagement optimiert wurde, also ob die VMs nicht unnötig viel Speicher verbrauchen.

  • Ich weiß nicht genau, woran es liegt, aber die Builds wirken viel zu langsam.
    Selbst mit den Optionen -c und -m, um CPU- und Speicherressourcen zu erhöhen, spüre ich kaum eine Verbesserung.

    • Die Rückfrage, im Vergleich zu welcher Umgebung es langsam sei.
      Dazu wird eine frühere Erfahrung mit einem Apple-Silicon-Mac und Rancher Desktop geteilt, bei der angeblich x86-Images gebaut wurden, diese auf echter x86-Hardware aber nicht korrekt liefen.

  • In der kurzen Demo (https://developer.apple.com/videos/play/wwdc2025/346/) wirkte es beeindruckend, dass VMs in wenigen hundert Millisekunden starten können.
    Das läuft auf Basis von Virtualization.framework, einer Technik, die auch Docker Desktop/Colima/UTM wahlweise schon eingesetzt haben.
    Interessant wäre, wie hoch der Speicher-Overhead ist, wenn mehrere Container parallel laufen.

    • Es wird erklärt, dass die Startzeit der Container durch eine optimierte Linux-Kernel-Konfiguration (kernel config, https://github.com/apple/containerization/…), ein minimales Root-Dateisystem und ein leichtgewichtiges Init-System auf unter eine Sekunde reduziert wurde.