Davit – native macOS-UI für Apple Containers

 (davit.app)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Davit ist eine native macOS-App zum Ausführen und Verwalten von Linux-Containern auf Apple-silicon-Macs mit Apples Container-Plattform und kann ohne Docker Desktop genutzt werden
  • Sie kommuniziert direkt per XPC mit Apples Open-Source-container-Daemon und nutzt denselben Pfad wie die CLI; Electron, WebViews oder eigene Hintergrund-Agents gibt es nicht
  • Starten und Stoppen von Containern, Log-Streaming, Terminal-Zugriff, Dateibrowsing, Dockerfile-Builds und Compose-Import werden in einer App erledigt
  • Die App ist als kostenlose Open-Source-App unter MIT-Lizenz verfügbar, mit Apple Developer ID signiert und notarisiert; erforderlich ist ein Apple-silicon-Mac mit macOS 15 oder neuer
  • Anders als Docker Desktop nutzt sie pro Container eine leichtgewichtige VM; wenn keine Container laufen, liegt der Plattform-Hintergrunddienst im Leerlauf bei etwa 25 MB

Ziel und Laufzeitumgebung von Davit

  • Davit ist eine vollständig native macOS-App für Apples Container-Plattform
  • Sie führt Linux-Container auf Apple silicon aus und benötigt kein Docker Desktop
  • Sie ist kostenlos und Open Source und wird unter der MIT-Lizenz bereitgestellt
  • Die App ist mit einer Apple Developer ID signiert und notarisiert
  • Voraussetzung ist ein Apple-silicon-Mac mit macOS 15 oder neuer
  • Die Installation ist über Releases oder Homebrew möglich
    • brew install wouterdebie/tap/davit

Direkte Kommunikation mit Apples container-Daemon

  • Davit kommuniziert direkt per XPC mit Apples Open-Source-container-Daemon
  • Dieser Pfad ist derselbe Kommunikationsweg, den die container-CLI nutzt
  • Electron, WebViews oder eigene Hintergrund-Agents werden nicht verwendet

Funktionen zur Container-Verwaltung

  • Das Dashboard zeigt Dienste, Festplattennutzung und Live-CPU aller laufenden Container
  • In der Container-Liste kann man den Status in jeder Zeile prüfen und direkt Aktionen ausführen
    • Starten, Stoppen, Neustarten, Löschen
    • Live-CPU
    • Arbeitsspeicher
    • IP
  • Die Ansicht pro Container bietet Funktionen, um den Laufzeitstatus zu verstehen
    • Streaming-Logs mit Follow- und Boot-Modus
    • Echtzeit-Statusdiagramme
    • Anzeige der Rohkonfiguration
  • Für laufende Container lässt sich über native APIs direkt ein Terminal öffnen
    • Eine interaktive Shell kann in Terminal oder iTerm geöffnet werden
    • Keine CLI erforderlich

Bearbeitung unveränderlicher Container und Dateizugriff

  • Da Container unveränderlich sind, kann Davit auf Basis der vorhandenen Einstellungen einen neuen Container vorbefüllen und neu erstellen
  • Die neue Container-Konfiguration übernimmt die bisherigen Einstellungen mit Ausnahme von Entrypoint und env des Images
  • Der Ablauf ist auf schnelles Ändern von Ports, Umgebungsvariablen, Mounts und Ressourcen ausgelegt
  • In der App kann das Dateisystem laufender Container durchsucht werden
    • Ordner wechseln
    • Dateien auf den Mac herunterladen
    • Dateien hochladen
    • Dateien löschen
  • Dateioperationen werden über native APIs verarbeitet; ein docker cp-Befehl ist nicht nötig

Compose-Import und Dockerfile-Build

  • Davit öffnet docker-compose.yml und zeigt zuerst die zu erstellenden Ressourcen an
    • Dienste in Abhängigkeitsreihenfolge
    • Volumes
    • Netzwerke
    • Äquivalente CLI-Befehle pro Dienst
    • Warnungen zu nicht unterstützten Einträgen
  • Auf Apples Plattform gibt es kein natives compose, daher orchestriert Davit den Stack direkt
  • Der Compose-Import zielt auf eine unterstützte Teilmenge ab
    • Unterstützt: image, ports, environment, named/bind volumes, networks, resource limits, command, user, working_dir
    • Beispiele für Warnungen: restart:, healthcheck:, build:
  • Dockerfile-Builds sind über Images → Build Image möglich
    • Kontextordner und Dockerfile auswählen
    • Tag und build args setzen
    • Davit steuert Apples BuildKit-basierten Builder direkt an und startet ihn bei Bedarf
  • Es gibt derzeit auch Plattformbeschränkungen
    • Dockerfiles größer als 16 KiB werden abgelehnt
    • Das hängt mit einem Upstream-apple/container-Bug zusammen
    • Der Build-Kontext darf nicht unter /tmp liegen

Images, Volumes, Netzwerke und Registries

  • Davit unterstützt Image-bezogene Aktionen
    • Pull mit Fortschrittsanzeige
    • Container aus einem Image starten
    • Tags vergeben
    • Prune
  • Auch Volume- und Netzwerkaktionen werden angeboten
    • Volumes mit festgelegter Größe erstellen
    • Benutzerdefinierte Subnetze erstellen
    • Vor dem Löschen prüfen, ob Elemente in Benutzung sind
  • Registry-Logins werden unter Settings → Registries verwaltet
    • Docker Hub
    • ghcr.io
    • quay.io
    • Beliebige OCI-Registry
  • Zugangsdaten werden vor dem Speichern bei der Registry validiert
  • Validierte Zugangsdaten werden im macOS-Login-Schlüsselbund gespeichert und mit der container-CLI geteilt
  • Docker Hub verlangt die Verwendung eines Access Tokens statt eines Passworts

Plattform-Einstellungen und automatische Installation

  • Davit kann Plattform-Einstellungen in der App bearbeiten
    • Standard-CPU/-Arbeitsspeicher für neue Container
    • Registries
    • DNS
    • Builder-Ressourcen
  • Einstellungen werden vom plattformeigenen Konfigurations-Loader validiert und als sauberes TOML override gespeichert
  • Wenn Apples Container-Plattform nicht installiert ist, lädt Davit Apples signiertes Installationsprogramm herunter, verifiziert es und installiert es in der Library des Nutzers
  • Für die Installation sind keine Administratorrechte nötig
  • Bei Bedarf kann auch die container-CLI zur Shell hinzugefügt werden

App-Implementierung und Einstieg

  • Davit ist vollständig in SwiftUI umgesetzt
  • Es bietet Schnellaktionen in der Menüleiste
  • Das Dock-Icon kann nur bei Bedarf angezeigt werden
  • Für Echtzeitdiagramme wird kein Browser gestartet
  • Ein beispielhafter Einstieg sieht so aus
    • Über Releases oder Homebrew installieren
    • Falls beim ersten Start keine Plattform vorhanden ist, installiert Davit sie
    • Unter Images → Pull Image nginxdemos/hello pullen
    • Aus dem Image starten oder Containers → Run Container verwenden
    • Host 8088 auf Container 80 mappen
    • In der Ports-Zeile des Containers Open in Browser drücken oder localhost:8088 aufrufen
    • Im laufenden Container CPU, Arbeitsspeicher, Festplatte, Logs, Dateien, Terminal sowie Edit & Recreate erkunden

Unterschiede zu Docker Desktop und OrbStack

  • Davit nutzt Apples Engine
    • Jeder Container läuft in einer eigenen leichtgewichtigen VM auf Basis des Apple Virtualization framework
    • Jeder Container hat eine eigene IP-Adresse
    • Optimiert für Apple silicon
  • Es nutzt OCI-Images
    • Pull von Docker Hub, ghcr.io, quay.io oder beliebigen Registries möglich
    • Private Images können ebenfalls per Registry-Login verwendet werden
  • Es linkt Apples Client-Bibliotheken und kommuniziert direkt per XPC
    • Kein Socket-Shim
    • Kein Lizenzvertrag
    • Kein Account
  • Das App-Bundle ist 17 MB groß
    • Kein Electron
    • Kein gebündeltes VM-Image
    • Kein eigener Hintergrunddienst
  • Gegenüber OrbStack verfolgt es ein anderes Ziel
    • OrbStack ist eine kommerzielle App mit eigener Docker-kompatibler Virtualisierungsschicht
    • Davit ist eine kostenlose Open-Source-UI auf Apples Container-Plattform
    • Davit hat keine dauerhaft laufenden Komponenten, wenn keine Container existieren, nutzt IPs pro Container und Bridge-Netzwerke und bietet stärkere Isolation zwischen Containern
    • OrbStack ist besser bei drop-in-Kompatibilität zur docker-CLI/API und breiterer Tool-Unterstützung
    • Beide führen Standard-OCI-Images aus

Arbeitsspeicher, DNS und Sicherheit

  • Die Speicherarchitektur vermeidet eine dauerhaft laufende Linux-VM mit mehreren GiB
  • Docker Desktop hält unabhängig davon, ob Container laufen, eine große VM vor, während Apples Plattform pro Container eine leichtgewichtige VM bootet und sie beendet, wenn der Container stoppt
  • Wenn keine Container laufen, ist der Plattform-Hintergrunddienst mit etwa 25 MB im Leerlauf
  • Davit selbst ist keine Electron-App, sondern eine native SwiftUI-App; der Speicherverbrauch besteht größtenteils aus gemeinsam genutztem macOS-Framework-Speicher
  • Um vom Mac aus per Container-Namen zuzugreifen, kann die lokale DNS-Domain der Plattform genutzt werden
    • Einmal sudo container system dns create test ausführen oder eine eigene Domain verwenden
    • Unter Settings → Platform → DNS als Standard-Domain setzen
    • Der Container web antwortet auf dem Mac unter web.test
  • Alle Container haben eine eigene IP; sie wird im Abschnitt Network angezeigt
  • Wenn im Gast Avahi läuft, können .local-mDNS-Aliase per Broadcast bekannt gemacht werden
  • Jedes Release ist mit einer Apple Developer ID signiert und notarisiert und lässt sich ohne Gatekeeper-Warnung öffnen
  • Die App ist Open Source unter MIT-Lizenz und kann selbst gelesen oder gebaut werden
  • Davit kommuniziert nur mit dem lokalen container-Daemon und zur Prüfung auf Updates mit GitHub

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Meine beste Strategie im KI-Zeitalter ist: nichts tun
    Ich hatte eine ähnliche Idee und dachte, man könnte sie per Vibe Coding bauen, ging aber davon aus, dass jemand anderes mehr Interesse daran haben und sie zuerst umsetzen würde – und genau so kam es
    Die App sieht gut aus, und ich freue mich darauf, sie auszuprobieren
    Als kostenlose Idee: Ich würde Agenten gern in einer virtuellen Maschine einsperren und ihnen von außerhalb der VM über ein Harness Anweisungen schicken, um die darin installierten Agenten zu steuern. Idealerweise sollte auf dem Host nichts wie Codex/Claude installiert sein
    Noch besser wäre es, in der virtuellen Maschine mehrere Benutzerkonten anzulegen und pro Benutzer Dateisystem- und Netzwerk-Policies einzuschränken. Dann hätten Entwicklungsagenten, QA-Agenten usw. jeweils eine andere Sicht auf ihre Aufgaben, und das könnte eine starke Basisschicht für weitere Automatisierung werden
    Natürlich müsste man diverse Ressourcen wie DBs, Queues und externe Volumes an die virtuelle Maschine „anhängen“ können, damit Agenten sie rechtebasiert nutzen können

    • Genau das geht mit coderunner
      https://GitHub.com/instavm/coderunner
    • Das nutzt zwar Sandboxes und separate Benutzer statt virtueller Maschinen, aber sandvault passt gut zu diesem Zweck und übernimmt auch die automatische Installation
      Der Transparenz halber: Ich habe dort ein paar PRs eingereicht
      https://github.com/webcoyote/sandvault
    • „Power Move im KI-Zeitalter: nichts tun“ war schon vor KI meine Strategie
      Irgendwann Ende 20 oder Anfang 30 habe ich fast komplett aufgehört, in meiner Freizeit zu entwickeln, weil mir der Spaß am Coden selbst völlig abhandengekommen war. Eigentlich mochte ich es ohnehin nie so sehr; ich war nur wirklich schlecht darin einzuschätzen, ob etwas meine Zeit wert ist oder nicht
      Wenn mir ein Programm oder Skript einfiel, das nett zu haben wäre, war es meistens wie in der xkcd-Tabelle zur Amortisationszeit: Wie lange darf man an einem Programm bauen, um ein paar Minuten pro Woche zu sparen? Meistens „lohnte sich der Aufwand im Verhältnis zur Belohnung nicht“. Oder es war etwas, das nicht wirklich nötig war, aber interessant oder unterhaltsam gewesen wäre – nur hätte die Umsetzung unzählige Stunden gekostet und war es damit überhaupt nicht wert
      Wenn jemand etwas gebaut und veröffentlicht hat, das ich wollte, war das schön; wenn nicht, dann eben nicht
      Die große Veränderung durch LLMs ist, dass man kleine Skripte und Ähnliches jetzt in wenigen Minuten und für ein paar Cent bis ein paar Dollar erzeugen lassen kann. Ich hole gerade extrem nischige Ideen wieder hervor, die lange herumlagen
      Dinge, bei denen früher schon das Durchforsten einer unbekannten API und ihrer Dokumentation mehrere Wochenenden verschlungen hätte, gehen jetzt in 30 Minuten – oder ich kann zumindest in ein paar Minuten statt in ein paar Stunden beurteilen, ob es nicht funktioniert oder so nervig ist, dass ich es für immer verwerfen sollte
    • Ich habe etwas Ähnliches grob als einfache Browser-Frontend-Version zusammengeschustert
      Ich lasse gern mittelgroße bis große offene Modelle laufen, traue ihnen aber nicht zu, dass sie nicht aus dem Ruder laufen; deshalb habe ich es gebaut und werde es demnächst teilen
    • Diesen Gedanken hatte ich auch schon
      Es scheint mir so simpel wie: Claude in einer virtuellen Maschine installieren und per SSH-Terminal darauf zugreifen. Wenn man eine GUI braucht, bekommt man mit der Remote-SSH-Erweiterung von VSCode auch Dinge wie eine Dateibrowser-UI
      Vermutlich kann man auch Claude oder andere Chat-Erweiterungen für VSCode in der virtuellen Maschine installieren

  • Was an diesem Projekt selbst mehr auffällt, ist, dass sich ein Phänomen sichtbar beschleunigt hat, das viele – besonders im letzten Jahr oder so – vorhersehen konnten. Menschen können ihre eigene Version derselben Idee jetzt viel schneller als früher bauen
    Nach etwa 10 Minuten Suche fand ich mehrere ähnliche Swift-Projekte, die meisten davon erst wenige Wochen oder Monate alt
    https://github.com/tdeverx/contained-app
    https://github.com/nico81/iContainer
    https://github.com/wouterdebie/davit
    https://github.com/Augani/dory
    https://github.com/tofa84/berth
    https://github.com/erdaltoprak/ContainerUtility
    https://github.com/andrew-waters/orchard
    Wenn man Projekte mit weniger GitHub-Sternen, reine Kommandozeilen-Tools und Nicht-Swift-Projekte mitzählt, gab es noch mehr, aber der Punkt ist dieser:
    Menschen werden zunehmend in der Lage sein, ihre eigene Version der Software zu bauen, die sie haben wollen. Dadurch sinkt der Wert von Software, die andere gebaut haben. Das Zeitalter hyperpersonalisierter Software kommt

    • Kann man sagen, dass all diese Projekte gleichermaßen erstklassige Qualität haben? Ich bin mir nicht sicher, ob man das wirklich weiß
      Früher konnte man den Aufwand, der in so etwas geflossen ist, anhand der Qualität der Website oder einiger oberflächlicher Faktoren abschätzen. Heute erledigt ein LLM solche Dinge leicht
      Ähnlich war im Rückblick einer der größten Effekte von Kickstarter, dass sich dreiminütige Pitch-Videos aggressiv weiterentwickelt und verfeinert haben
      Ob das tatsächlich zu tief durchdachten Implementierungen, Roadmaps und echter Umsetzungsstärke führt, weiß ich nicht
    • Bei iOS ist das anders. Um etwas in den App Store zu stellen, muss man entweder die jährliche Mitgliedsgebühr zahlen oder Builds mit einem persönlichen Account etwa alle 30 Tage neu bauen und neu installieren

  • Wirkt wie eine wirklich solide App. Sie ist 17 MB groß, und mir gefällt, dass sie die ContainerAPIClient-Bibliothek direkt nutzt
    28 Commits in 3 Tagen, 5.015 Zeilen Swift, und jeder Commit ist mit „Co-Authored-By: Claude Fable 5“ versehen
    Schön ist auch, dass sie signiert und notarisiert ist. Nach der Installation hat sie beim ersten Start die benötigten Container-Plattformkomponenten heruntergeladen
    Als Vorschlag: Fügt der Website ein Einstiegstutorial hinzu, empfiehlt ein Image zum Ausprobieren und zeigt mit Screenshots oder einem stummen Video, wie man dieses Image ausführt und was man damit machen kann
    Der Dialog zum Erstellen von Images schlägt „nginx:latest“ vor, aber als Einstiegsdemo ist das nicht besonders gut

    • Der AI-Maxing-Text auf der Website war bis zu einem gewissen Grad erkennbar. Das heißt aber nicht, dass es keine großartige App ist
    • Guter Vorschlag. Werde ich bald ergänzen
    • Ein Tutorial mit einem etwas realistischeren Beispiel wäre hier vermutlich sehr hilfreich
      nginx:latest zeigt zwar, dass die Verkabelung funktioniert, aber nicht wirklich, wo sich Apple Containers anders anfühlt als Docker Desktop oder OrbStack
      Ein Beispiel mit einer kleinen App, Volumes, Port-Mapping und einer einfachen Rebuild-Schleife würde den Nutzen deutlich leichter sichtbar machen

  • Ha! Wir haben offenbar dasselbe gebaut: https://container-ui.fly.dev/
    Jetzt denke ich, ich hätte die vielen Tokens lieber nicht verbrennen sollen

    • Oh, hallo. Ich habe gerade gesehen, dass es einen Vergleich mit Orchard gibt, das bin ich
      Sieht sauber aus. Am Ende bauen wir wohl alle dasselbe ><

  • Ich nutze OrbStack seit fast zwei Jahren sehr gern
    Die Integration ist gut, es ist schnell und docker-befehls-kompatibel, daher war es mir das Geld wert
    Trotzdem werde ich das hier auch einmal ausprobieren

    • Native macOS-Container scheinen pro Container eine eigene Linux-VM zu starten
      Die Stärke von OrbStack ist, dass alle Container in einer einzigen Linux-VM laufen und auf beiden Seiten der VM-Grenze viele Optimierungen vorgenommen werden. Dazu gehört auch die Nutzung von Sparse-Image-Dateien, die auf der macOS-Seite viel Speicherplatz sparen
      Wenn man unter macOS mehr als 4–5 Container laufen lässt, machen sich die Performance- und Ressourceneinsparungen von OrbStack schnell stark bemerkbar
    • Ich vermute, das OrbStack-Team wird demnächst native macOS-Container unterstützen und seine Verwaltungsfunktionen darüberlegen

  • Wirklich gut. Das Herunterladen der Runtime und das Ausführen von nginx:latest haben perfekt funktioniert
    Wenn man auf GitHub nach unten scrollt und Claude als Contributor sieht, scheint das langsam zu einem Signal dafür zu werden, dass die App gut sein wird. Also im Sinne von nativ wirkend und nicht Electron

  • Ich wünschte, Apple würde Apple Containers docker-API-Kompatibilität hinzufügen

    • Ich bin mir auch nicht sicher. Kann ich das statt Docker Desktop nutzen, um docker-Container auf meinem Mac „nativ“ laufen zu lassen? Oder ist das etwas völlig Eigenständiges gegenüber docker?
    • Das hier ist auf Builds ausgerichtet und führt buildkitd oder dockerd innerhalb von Apple-containerization-Containern aus
      Dinge wie Port-Forwarding oder Host-Volumes gibt es nicht. Tatsächlich liegt der Fokus darauf, buildkit auf dem Mac laufen zu lassen
      Allerdings ist es vollständig mit docker CLI und buildx integriert
      https://github.com/cpuguy83/crucible

  • Die Funktionen gefallen mir, und auch, dass es eine kleine native SwiftUI-App ist
    Ich habe kürzlich einen Artikel [1] über den Einsatz von Apple-Containern für agentenbasiertes Coding geschrieben und ihn gerade aktualisiert, um Davit zu erwähnen. Für persönliche Projekte auf meinen beiden Macs zu Hause bevorzuge ich Apple-Container inzwischen deutlich gegenüber Docker
    [1] https://open.substack.com/pub/marklwatson/p/running-opencode...

  • Wie schlägt sich das im Vergleich zu OrbStack? Bieten Apple Containers etwas, das man in der Developer Experience spürbar merkt? Nach meinem Nutzungsprofil fühlt sich die OrbStack-Implementierung bereits blitzschnell an

  • Ich habe vor ein paar Tagen eine ähnliche Version gepostet, die ich gebaut habe, aber sie hat kaum Resonanz bekommen
    Falls es jemanden interessiert: Es ist eine Menüleisten-App mit Unterstützung für Container, Maschinen und Registries
    https://news.ycombinator.com/item?id=48789503
    https://github.com/erdaltoprak/ContainerUtility