Apple hat gerade WSL für den Mac gebaut (Container-Maschinen)
BBetter Stack
Computing/SoftwareInternet Technology
Transcript
00:00:00Versteckt hinter dem ganzen Apple Intelligence-Zeug auf der diesjährigen WWDC
00:00:03hat Apple still und leise eine eigene Version des Windows Subsystem for Linux namens Container
00:00:06Machines veröffentlicht. Diese bieten eine leichtgewichtige, persistente Linux-Umgebung auf dem Mac auf eine wirklich einfache
00:00:10Art und Weise, und sie basieren tatsächlich auf Apples Container-Projekt, das sie
00:00:14letztes Jahr veröffentlicht haben, welches eine Docker-Alternative ist, und alles davon ist natürlich für Apple
00:00:18Silicon optimiert. Schauen wir uns also an, was Container Machines sind, wie sie funktionieren,
00:00:21und machen auch einen kurzen Rückblick auf Apple Containers für alle, die sie verpasst haben.
00:00:29Ich beginne damit, eine Container Machine einzurichten, und werde dann ein bisschen darüber sprechen, wie
00:00:32das alles funktioniert. Die, die ich möchte, wird eine Ubuntu Linux-Umgebung sein. Also habe ich einfach
00:00:37ein Dockerfile mit dem Ubuntu-Image hier, und dann ein paar Dinge darin, um einige gängige Tools
00:00:41zu installieren. Das funktioniert mit jedem OCI-kompatiblen Image, also so ziemlich allen, die ihr
00:00:46mit Docker verwendet. Das Einzige, was es beinhalten muss, um eine VM zu sein, ist das System-Initialisierungs-Programm.
00:00:50Sobald wir das Dockerfile-Image haben, das wir für unsere VM verwenden möchten, müssen wir es nur noch
00:00:54mit Apples Container-Tool bauen. Ihr könnt sehen, das ist der Befehl, den ich für meine verwende,
00:00:58da ich das Dockerfile in diesem Ordner habe, und ich werde das einfach als lokale
00:01:01Ubuntu Machine taggen, und wir können weitermachen und Enter drücken, um zu bauen. Das Container-Tool,
00:01:05übrigens, funktioniert ab macOS 26, und ihr könnt es von GitHub installieren, indem ihr einfach zum
00:01:09Repo geht, zu den Releases navigiert und das neueste Paket herunterladet. Es sieht so aus, als ob der Build meines Images
00:01:13hier fertig ist, und ihr könnt sehen, es ist sehr ähnlich zu Docker. Es baut einfach ein OCI-Image.
00:01:17Das ist alles, was wir für eine Container Machine brauchen, also können wir einfach “container machine create” ausführen,
00:01:21das Image angeben, das wir für unsere Container Machine wollen, ihr einen freundlichen Namen geben,
00:01:24und ich werde das auch als Standard festlegen, sodass jeder Befehl, den ich ausführe, davon ausgeht,
00:01:27dass ich mich auf dieser Container Machine befinde, und ich sie nicht namentlich angeben muss. Damit können wir Enter drücken,
00:01:31und in buchstäblich Sekunden ist alles eingerichtet. Wir können uns ein paar Informationen über die
00:01:35Container Machine, die ich gerade erstellt habe, anzeigen lassen, indem wir “container machine list” eingeben. Hier seht ihr,
00:01:38dass sie die Ubuntu-Maschine hat, die ich gerade erstellt habe, die IP-Adresse, 7 CPUs und 18 Gigabyte Arbeitsspeicher. CPU und Speicher
00:01:44sind übrigens konfigurierbar, aber standardmäßig verwendet sie die Hälfte des Arbeitsspeichers eures Macs. Um sie tatsächlich
00:01:48zu nutzen, müsst ihr nur “container machine run” eingeben,
00:01:51und ihr könnt das leer lassen, wenn ihr in das interaktive Terminal gelangen wollt, oder ihr könnt tatsächlich einfach
00:01:54einen Befehl danach hinzufügen, wenn ihr diesen auf eurer Linux-Maschine ausführen wollt. In diesem Fall seht ihr,
00:01:58ich drücke einfach Enter, und jetzt bin ich in einem interaktiven Terminal in meiner Linux-Umgebung. Wir können das bestätigen,
00:02:02indem wir so etwas wie “uname -a” machen, und ihr seht, das gibt zurück, dass es Linux Ubuntu ist,
00:02:06im Gegensatz dazu, wenn ich das auf meinem Mac ausführe und Darwin zurückbekomme. Nun, eines der coolen Dinge an
00:02:10Container Machines ist, dass sie automatisches Benutzer-Sharing haben, also wurde mein Benutzer bereits von meinem Mac
00:02:14auf meine Linux-Umgebung kopiert, und das Gleiche gilt tatsächlich für euer Home-Verzeichnis. Dies mountet euer
00:02:18gesamtes Home-Verzeichnis als Read-Write, sodass ich in dieser Linux-Umgebung Zugriff auf alle Dateien habe, die ich
00:02:23auf meinem Mac habe. Ihr könnt sehen, wo ich tatsächlich “container run” ausgeführt habe, es hat mich direkt in diese Datei
00:02:27in der Linux-Umgebung gebracht, und wir haben diese Dateien dort bereits drin. Es hat auch ein eigenes Volume,
00:02:31wenn wir also zum Home-Verzeichnis dieser Ubuntu-Maschine navigieren, seht ihr, dass dort derzeit
00:02:35nichts drin ist, auch wenn es auf meinem Mac der Fall ist, und das liegt daran, dass dies die Linux-
00:02:39Umgebung ist, und hier legt ihr eure .files ab, die spezifisch für Linux sind. Die Ordnerfreigabe
00:02:43macht es super einfach, etwas auf eurem Mac mit all euren normalen Tools zu entwickeln, und vielleicht sogar einigen,
00:02:48die nur mit macOS kompatibel sind, und dann einfach zu Linux zu wechseln, wenn ihr etwas testen müsst.
00:02:52Zum Beispiel habe ich hier eine sehr einfache BUN-Anwendung, und ich möchte diese in eine einzelne
00:02:56ausführbare Datei kompilieren, die auf Linux funktioniert, aber ich kann Linux nicht wirklich auf meinem macOS testen, also beim Ausführen,
00:03:01weiß ich nicht, ob es funktioniert hat oder nicht. Wenn wir aber zur Container Machine wechseln,
00:03:04seht ihr, kann ich den Befehl einfach sofort ausführen. Ich muss keine Dateien übertragen oder so,
00:03:08dank der Tatsache, dass sie dasselbe Dateisystem teilen. Wenn ich hier Enter drücke, funktioniert es prima.
00:03:12Diese Anwendung war nur ein sehr einfacher Webserver mit dieser Webseite hier, die ausgibt, worauf sie
00:03:16läuft, sie läuft also derzeit auf Ubuntu 24. Ihr könnt auch sehen, da läuft ein Abonnement,
00:03:20etwas, das ihr definitiv tun solltet. Nun habe ich gerade das Ausführen des BUN
00:03:23Entwicklungsservers auf der Linux-Umgebung getestet, und es funktioniert alles, was wir hier sehen können,
00:03:27er läuft auf BUN dev, und es ist nicht kompiliert. Aber wenn ich eine der Quelldateien von meinem Mac hier ändere,
00:03:31vielleicht “hallo” statt “abonnieren” sage, merke ich, dass das Hot Reloading das Verhalten anscheinend
00:03:35nicht aufgreift, und ich muss den BUN-Entwicklungsserver neu starten, damit die Änderungen übernommen werden.
00:03:39Da haben wir's, jetzt steht da “hallo”. Ich denke, Hot Reloading wird genauso funktionieren wie Breakpoints,
00:03:43wo sie nicht wirklich funktionieren, wenn ihr auf eurer macOS-Codeversion seid, aber was ihr tun könnt, ist euren Editor
00:03:47dazu zu bringen, sich via SSH mit der Container Machine zu verbinden, und dann die Dateien so zu bearbeiten, und auf diese Weise
00:03:52werden Breakpoints und Hot Reloading wahrscheinlich funktionieren. Sie haben tatsächlich ein Tutorial, wie das geht,
00:03:55in ihrer Dokumentation. Das ist im Grunde alles, was es zu zeigen gibt, wenn es darum geht, tatsächlich eine
00:03:59Container Machine zu verwenden. Ich meine, es ist jetzt nur eine Ubuntu-Umgebung, und ehrlich gesagt ist die ganze Erfahrung
00:04:03ziemlich nahtlos. Es ist auch erwähnenswert, dass ihr nicht auf nur eine Maschine beschränkt seid. Ihr könntet
00:04:08eine Alpine-Maschine, eine Ubuntu-Maschine und eine Debian-Maschine nebeneinander haben, sodass ihr eine Distribution
00:04:12pro Ziel habt, und ehrlich gesagt ist es sehr nett, wenn ihr zielübergreifend arbeitet. Außerdem, weil diese Maschinen
00:04:17tatsächlich ein echtes SystemD ausführen können, könnt ihr einen richtigen Service-Stack darin testen, wie zum Beispiel Postgres,
00:04:22das als tatsächlicher Dienst mit eurer App daneben läuft, und das Ganze wird sich wie der
00:04:26Linux-Server verhalten, auf dem ihr bereitstellen werdet. Die Einfachheit ist eines der Kerngestaltungsprinzipien, das
00:04:30Apple bei der Entwicklung von Container Machines vorangetrieben hat. Sie wollten schnelle, leichtgewichtige VMs, die
00:04:34sich in euren bestehenden Workflow integrieren und super einfach bei Bedarf hochzufahren sind, sowie persistent
00:04:39über die Zeit, sodass ihr eine ganze Entwicklungsumgebungs-VM einrichten könnt, die all die Werkzeuge hat, die
00:04:42ihr normalerweise braucht, wenn ihr sie braucht. Auch hier ist es ziemlich ähnlich zu dem, was das Windows Subsystem
00:04:47for Linux zu erreichen versuchte. Was den Bau und den Vergleich mit Docker und
00:04:51OrbStack angeht, müssen wir zuerst das Container-Tool verstehen, das letztes Jahr veröffentlicht wurde. Dieses ist in
00:04:55Swift geschrieben und soll eine Docker-Alternative sein, die Container ausführen kann, und sie führt jedes Standard
00:04:59OCI-Image aus, also alles, was ihr von Docker Hub ziehen könnt, wird weiterhin funktionieren. Das Einzigartige an
00:05:04Apples Ansatz ist jedoch, dass jeder Container seine eigene leichtgewichtige virtuelle Maschine durch ihr
00:05:08Virtualisierungs-Framework bekam, anstatt dass eine Reihe von Containern eine große Linux-VM teilen, was
00:05:13Docker Desktop tut. Einige Vorteile dieses Ansatzes können Sicherheit sein, da jeder Container die
00:05:17Isolierungseigenschaften einer vollständigen VM hat. Dann gibt es auch noch Privatsphäre, da ihr nur die notwendigen
00:05:22Daten in jede VM mountet, wohingegen ihr bei einer geteilten VM tatsächlich alle Daten in diese
00:05:27geteilte VM mountet, sodass sie selektiv in die einzelnen Container gemountet werden können. Schließlich kann es auch einen
00:05:31Leistungsvorteil geben, da Container, die mit Apple Container erstellt wurden, tatsächlich weniger Speicher benötigen als eine
00:05:36vollständige VM, und die Bootzeiten sind ziemlich ähnlich wie bei Docker und anderen Tools. Wenn wir uns tatsächlich einige
00:05:41Benchmarks ansehen, die RepoFlow hier gemacht hat, und Apple Containers mit OrbStack und Docker Desktop vergleichen, können wir sehen, dass die
00:05:46Ergebnisse eigentlich nicht zu schlecht sind. Es ist hier schwer zu sagen, aber Apple Containers erzielt tatsächlich die
00:05:50meisten Single-Threaded-CPU-Ereignisse, aber OrbStack war ziemlich nah dran, es sind Bruchteile, und diese
00:05:55gleiche Geschichte setzt sich fort, wenn wir auch zu Multi-Threaded gehen, sie alle performen sehr gut. Wo Apple jedoch
00:06:00einen kleinen Vorsprung zu haben scheint, ist beim Speicherdurchsatz, wobei OrbStack auf den zweiten Platz kommt und Docker
00:06:04Desktop auf den letzten, aber wenn es um Startzeiten für einen winzigen Container geht, scheint Apple noch
00:06:09etwas Arbeit vor sich zu haben, aber es ist immer noch unter einer Sekunde, nur Docker Desktop und OrbStack tun es in weniger
00:06:14als einer Viertelsekunde. Es gibt noch viele weitere Benchmarks hier, also werde ich einen Link dazu hinterlassen,
00:06:17aber im Grunde zeigen die anderen, dass OrbStack eine außergewöhnliche Dateisystem- und Kleindateien-Performance hat,
00:06:22aber sie zeigen auch, dass Apple Containers so ziemlich gleichauf, wenn nicht besser als Docker Desktop ist.
00:06:27Es gibt ein paar Haken, derer ihr euch bewusst sein solltet, bevor ihr Container Machines verwendet,
00:06:30und der erste ist Speicher. Wie ich vorhin erwähnt habe, verwendet die Maschine standardmäßig die Hälfte eures System-RAMs,
00:06:35es ist also erwähnenswert, dass sie diesen tatsächlich niemals zurückgibt. Wenn ihr also eine speicherintensive
00:06:39Arbeitslast im Container habt, vielleicht während eines großen Builds, wird dieser Speicher tatsächlich gehalten, bis ihr
00:06:43die Maschine neu startet. Dies ist tatsächlich einer der einzigartigen Vorteile von OrbStack, wo es dynamischen
00:06:47Speicher hat, der die Speichernutzung reduziert, indem er diesen ungenutzten Speicher an macOS zurückgibt. Soweit ich weiß,
00:06:53tut das sonst nichts. Zweitens gibt es auch kein GPU- und USB-Passthrough. Ich habe jedoch offene Probleme
00:06:57für beide auf GitHub gesehen, vielleicht wird es also in Zukunft unterstützt. Drittens scheint es auch
00:07:02ein wenig komplex zu sein, GUI-Apps zum Laufen zu bringen, wie vielleicht wenn ihr die Linux-Version von
00:07:06VS Code oder anderen Linux-only-Apps ausführen wolltet. Es ist definitiv keine nahtlose Erfahrung, ich würde wahrscheinlich etwas anderes dafür verwenden.
00:07:11Schließlich gibt es auch einen Sicherheits-Kompromiss, weil, wie ich vorhin erwähnt habe, dieser Home-Verzeichnis-Mount,
00:07:15der alles so bequem macht, standardmäßig Read-Write ist, was bedeutet, dass alles, was ihr
00:07:20innerhalb dieser Linux-Maschine ausführt, auf eure SSH-Schlüssel, eure Cloud-Anmeldeinformationen und alles auf
00:07:25eurem Mac zugreifen kann. Es scheint, als könntet ihr den Mount tatsächlich nur auf Read-Only setzen oder komplett ausschalten. Es
00:07:29scheint keine Möglichkeit zu geben, nur einen bestimmten Ordner zu mounten. Alles in allem, nachdem ich Apple
00:07:33Container Machines ausprobiert habe, werde ich wahrscheinlich bei OrbStack bleiben, da es sich wie die poliertere Option
00:07:37heute anfühlt, mit besserem Ressourcenmanagement und mehr Funktionen, aber ich weiß, dass manche Leute es nicht mögen,
00:07:40dass OrbStack kostenpflichtig ist, wenn ihr geschäftliche und kommerzielle Nutzung wollt, also ohne OrbStack würde ich wahrscheinlich
00:07:45Apple Containers gegenüber Docker Desktop wählen, und es gibt auch noch Lima, was eine weitere großartige
00:07:49Alternative ist. Was verwendet ihr? Ist es OrbStack, Docker Desktop oder Lima? Lasst es mich in den Kommentaren
00:07:53unten wissen, während ihr dort seid, um zu abonnieren, und wie immer, wir sehen uns beim nächsten Mal.