Davit – une interface macOS native pour Apple Containers

 (davit.app)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Davit est une app macOS native permettant d’exécuter et de gérer des conteneurs Linux via la plateforme container d’Apple sur les Mac Apple silicon, sans Docker Desktop
  • Elle communique directement en XPC avec le démon container open source d’Apple, en empruntant le même chemin que la CLI, sans Electron, webview ni agent d’arrière-plan propre
  • Elle gère dans une seule app le démarrage et l’arrêt des conteneurs, le streaming des logs, l’accès au terminal, l’exploration de fichiers, le build de Dockerfile et l’import de Compose
  • Elle est fournie comme app gratuite et open source sous licence MIT, signée et notariée avec Apple Developer ID, et nécessite un Mac Apple silicon sous macOS 15 ou ultérieur
  • Contrairement à Docker Desktop, elle utilise une VM légère par conteneur ; lorsqu’aucun conteneur ne tourne, les services d’arrière-plan de la plateforme restent en veille à environ 25 Mo

Objectif de Davit et environnement d’exécution

  • Davit est une app macOS entièrement native pour la plateforme container d’Apple
  • Elle exécute des conteneurs Linux sur Apple silicon, sans nécessiter Docker Desktop
  • Elle est gratuite, open source et fournie sous licence MIT
  • L’app est signée et notariée avec un Apple Developer ID
  • Elle nécessite un Mac Apple silicon exécutant macOS 15 ou ultérieur
  • L’installation est possible depuis les releases ou via Homebrew
    • brew install wouterdebie/tap/davit

Communication directe avec le démon container d’Apple

  • Davit communique directement en XPC avec le démon container open source d’Apple
  • Ce chemin est le même que celui utilisé par la CLI container
  • Elle n’utilise pas Electron, de webview ni d’agent d’arrière-plan propre

Fonctions de gestion des conteneurs

  • Le tableau de bord affiche les services, l’utilisation disque et le CPU en temps réel de tous les conteneurs en cours d’exécution
  • Dans la liste des conteneurs, chaque ligne permet de consulter l’état et d’agir directement
    • Démarrer, arrêter, redémarrer, supprimer
    • CPU en temps réel
    • Mémoire
    • IP
  • L’écran propre à chaque conteneur fournit aussi des fonctions pour comprendre son état d’exécution
    • Logs en streaming avec modes follow et boot
    • Graphiques d’état en temps réel
    • Consultation de la configuration brute
  • Pour les conteneurs en cours d’exécution, il est possible d’ouvrir directement un terminal via l’API native
    • Un shell interactif peut être ouvert dans Terminal ou iTerm
    • Aucune CLI n’est nécessaire

Édition de conteneurs immuables et accès aux fichiers

  • Les conteneurs étant immuables, Davit permet de recréer un nouveau conteneur prérempli à partir de la configuration existante
  • La nouvelle configuration du conteneur reprend la configuration existante, à l’exception de l’entrypoint et des env de l’image
  • Le flux est adapté aux modifications rapides des ports, variables d’environnement, montages et ressources
  • Le système de fichiers d’un conteneur en cours d’exécution peut être exploré dans l’app
    • Navigation dans les dossiers
    • Téléchargement de fichiers vers le Mac
    • Upload de fichiers
    • Suppression de fichiers
  • Les opérations sur les fichiers passent par l’API native et ne nécessitent pas la commande docker cp

Import de Compose et build de Dockerfile

  • Davit ouvre docker-compose.yml et affiche d’abord les ressources qui seront créées
    • Services dans l’ordre des dépendances
    • Volumes
    • Réseaux
    • Commandes CLI équivalentes par service
    • Avertissements sur les éléments non pris en charge
  • La plateforme Apple ne disposant pas de compose natif, Davit orchestre directement la stack
  • L’import Compose cible un sous-ensemble pris en charge
    • Pris en charge : image, ports, environment, named/bind volumes, networks, resource limits, command, user, working_dir
    • Exemples d’éléments signalés par un avertissement : restart:, healthcheck:, build:
  • Le build de Dockerfile est disponible dans Images → Build Image
    • Sélection du dossier de contexte et du Dockerfile
    • Définition du tag et des build args
    • Davit pilote directement le builder basé sur BuildKit d’Apple et le démarre si nécessaire
  • Il existe aussi des limites actuelles de la plateforme

Images, volumes, réseaux et registries

  • Davit prend en charge les opérations liées aux images
    • Pull avec suivi de la progression
    • Lancement d’un conteneur depuis une image
    • Attribution de tags
    • Prune
  • Des opérations sur les volumes et réseaux sont aussi proposées
    • Création de volumes avec taille définie
    • Création de sous-réseaux personnalisés
    • Vérification des éléments utilisés avant suppression
  • La connexion aux registries se fait dans Settings → Registries
    • Docker Hub
    • ghcr.io
    • quay.io
    • Tout registry OCI arbitraire
  • Les identifiants sont validés auprès du registry avant enregistrement
  • Les identifiants validés sont stockés dans le trousseau de session macOS et partagés avec la CLI container
  • Docker Hub exige l’utilisation d’un token d’accès plutôt qu’un mot de passe

Réglages de la plateforme et installation automatique

  • Davit permet de modifier les réglages de la plateforme dans l’app
    • CPU/mémoire par défaut des nouveaux conteneurs
    • Registries
    • DNS
    • Ressources du builder
  • Les réglages sont validés par le chargeur de configuration propre à la plateforme et enregistrés sous forme de TOML override propre
  • Si la plateforme container d’Apple n’est pas installée, Davit télécharge et vérifie l’installateur signé d’Apple, puis l’installe dans la Library de l’utilisateur
  • Le processus d’installation ne nécessite pas de droits administrateur
  • Si besoin, la CLI container peut aussi être ajoutée au shell

Implémentation de l’app et parcours de démarrage

  • Davit est entièrement implémentée en SwiftUI
  • Elle propose des actions rapides dans la barre de menus
  • L’icône du Dock ne peut être affichée que si l’utilisateur le souhaite
  • Aucun navigateur n’est lancé pour rendre les graphiques en temps réel
  • Un parcours de démarrage type est le suivant
    • Installer depuis les Releases ou via Homebrew
    • Au premier lancement, si la plateforme est absente, Davit l’installe
    • Pull de nginxdemos/hello depuis Images → Pull Image
    • Lancer depuis l’image ou utiliser Containers → Run Container
    • Mapper l’hôte 8088 vers le port 80 du conteneur
    • Dans la ligne Ports du conteneur, cliquer sur Open in Browser ou accéder à localhost:8088
    • Explorer CPU, mémoire, disque, logs, fichiers, terminal et la fonction Edit & Recreate sur le conteneur en cours d’exécution

Différences avec Docker Desktop et OrbStack

  • Davit utilise le moteur d’Apple
    • Chaque conteneur s’exécute dans sa propre VM légère basée sur Apple Virtualization framework
    • Il dispose d’une adresse IP par conteneur
    • Il est optimisé pour Apple silicon
  • Elle utilise des images OCI
    • Pull possible depuis Docker Hub, ghcr.io, quay.io ou n’importe quel registry
    • Les images privées sont aussi utilisables via la connexion au registry
  • Elle lie les bibliothèques clientes d’Apple et communique directement en XPC
    • Pas de socket shim
    • Pas de contrat de licence
    • Pas de compte
  • Le bundle de l’app fait 17 Mo
    • Pas d’Electron
    • Pas d’image VM embarquée
    • Pas de service d’arrière-plan propre
  • Son positionnement diffère de celui d’OrbStack
    • OrbStack est une app commerciale avec sa propre couche de virtualisation compatible Docker
    • Davit est une UI gratuite et open source au-dessus de la plateforme container d’Apple
    • Davit n’a pas d’élément résident lorsqu’il n’y a pas de conteneur, utilise des IP par conteneur et des réseaux bridge, et offre une isolation plus forte entre conteneurs
    • OrbStack est meilleur pour la compatibilité drop-in avec la CLI/API docker et pour la prise en charge d’un plus large écosystème d’outils
    • Les deux exécutent des images OCI standard

Mémoire, DNS et sécurité

  • L’architecture mémoire évite de conserver une grosse VM Linux de plusieurs Gio toujours active
  • Docker Desktop maintient une grande VM indépendamment de l’exécution de conteneurs, tandis que la plateforme Apple démarre une VM légère par conteneur et l’arrête lorsque le conteneur s’arrête
  • Lorsqu’aucun conteneur ne tourne, les services d’arrière-plan de la plateforme restent en veille à environ 25 Mo
  • Davit elle-même est une app SwiftUI native, et non Electron ; sa consommation mémoire correspond surtout à de la mémoire de frameworks macOS partagés
  • Pour accéder depuis le Mac aux conteneurs par leur nom, il est possible d’utiliser le domaine DNS local de la plateforme
    • Exécuter une fois sudo container system dns create test ou utiliser son propre domaine
    • Le définir comme domaine par défaut dans Settings → Platform → DNS
    • Le conteneur web répond alors depuis le Mac sur web.test
  • Tous les conteneurs disposent de leur propre IP, affichée dans la section Network
  • En exécutant Avahi dans le guest, il est possible de diffuser un alias mDNS en .local
  • Chaque release est signée et notariée avec Apple Developer ID, et s’ouvre sans avertissement Gatekeeper
  • L’app est open source sous licence MIT, et peut être lue ou buildée directement
  • Davit ne communique qu’avec le démon container local et avec GitHub pour vérifier les mises à jour

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires Hacker News

  • Ma meilleure stratégie à l’ère de l’IA, c’est de ne rien faire
    J’avais eu une idée similaire et je pensais pouvoir la réaliser en vibe coding, mais je me suis dit que quelqu’un d’autre s’y intéresserait davantage et la ferait avant moi, et c’est effectivement ce qui s’est passé
    L’app a l’air sympa et j’ai hâte de l’essayer
    Comme idée gratuite, j’aimerais enfermer les agents dans une machine virtuelle, puis leur envoyer des instructions depuis l’extérieur via un harnais afin de contrôler les agents installés à l’intérieur. Dans l’idéal, il ne devrait même pas y avoir quelque chose comme Codex/Claude installé sur l’hôte
    Une direction encore plus intéressante serait de créer plusieurs comptes utilisateur dans la machine virtuelle et de limiter, pour chaque utilisateur, le système de fichiers et les politiques réseau. Ainsi, un agent de développement, un agent QA, etc. auraient chacun une vue différente de leur environnement de travail, ce qui pourrait devenir une couche de base très puissante pour davantage d’automatisation
    Bien sûr, il faudrait aussi pouvoir “attacher” à la machine virtuelle diverses ressources comme des DB, des files de messages, des volumes externes, afin que les agents puissent les utiliser selon leurs autorisations

    • C’est exactement possible avec coderunner
      https://GitHub.com/instavm/coderunner
    • Au lieu d’une machine virtuelle, ça utilise des sandboxes et des utilisateurs séparés, mais sandvault convient bien à cet usage et gère aussi l’installation automatique
      Par souci de transparence, j’y ai déjà envoyé quelques PR
      https://github.com/webcoyote/sandvault
    • Le “power move de l’ère de l’IA : ne rien faire”, c’était déjà ma stratégie avant l’IA
      Vers la fin de ma vingtaine ou le début de ma trentaine, j’ai quasiment arrêté de développer sur mon temps libre, parce que tout le plaisir que j’en tirais avait disparu. En réalité, je n’avais jamais tant aimé ça que ça ; j’étais surtout très mauvais pour juger si cela valait ou non le temps investi
      Même quand je pensais à un programme ou un script qu’il serait utile d’avoir, c’était le plus souvent comme dans le tableau xkcd sur le temps de retour sur investissement pour créer un programme juste pour économiser quelques minutes par semaine : dans la plupart des cas, “l’effort n’en valait pas la récompense”. Ou alors ce n’était pas vraiment nécessaire, juste potentiellement intéressant ou amusant à avoir, mais le temps requis pour le faire en vrai était tellement énorme que ça ne valait absolument pas le coup
      Si quelqu’un publiait ce que je voulais, tant mieux ; sinon, tant pis
      Le grand changement apporté par les LLM, c’est qu’ils permettent maintenant de sortir de petits scripts en quelques minutes, pour quelques centimes ou quelques dollars. Je recommence donc à ressortir de très vieilles idées extrêmement niche
      Ce qui, avant, m’aurait pris plusieurs week-ends juste à fouiller une API peu familière et sa doc peut désormais être fait en 30 minutes, ou au moins je peux savoir en quelques minutes au lieu de quelques heures si c’est impossible, ou trop pénible, et donc à abandonner pour toujours
    • J’ai bricolé quelque chose de similaire avec un simple frontend navigateur
      J’aime faire tourner des modèles open source de taille moyenne à grande, mais je ne peux pas leur faire confiance au point de croire qu’ils ne partiront jamais totalement en roue libre, donc j’ai fait ça et je le partagerai bientôt
    • J’y ai pensé aussi
      Je me dis que ça pourrait être aussi simple que d’installer Claude dans une machine virtuelle puis d’y accéder via un terminal SSH. Si on a besoin d’une GUI, on peut utiliser l’extension Remote SSH de VSCode pour récupérer aussi une UI de navigateur de fichiers, par exemple
      On peut probablement aussi installer l’extension Claude ou d’autres extensions de chat de VSCode dans la machine virtuelle

  • Plus que ce projet lui-même, ce qui m’a frappé, c’est à quel point un phénomène que beaucoup de gens pouvaient prévoir, surtout depuis environ un an, s’accélère désormais de façon visible. Les gens peuvent maintenant créer leur propre version d’une même idée bien plus vite qu’avant
    J’ai cherché une dizaine de minutes et j’ai trouvé plusieurs projets Swift similaires, dont la plupart n’ont que quelques semaines ou quelques mois
    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
    Il y en avait encore plus si l’on compte ceux avec moins d’étoiles GitHub, ceux uniquement en ligne de commande, ou ceux qui ne sont pas en Swift, mais l’idée est là
    Les gens vont de plus en plus pouvoir créer eux-mêmes leur propre version du logiciel qu’ils veulent. Et, dans ce cas, la valeur des logiciels faits par d’autres diminue. L’ère du logiciel hyperpersonnalisé arrive

    • Peut-on vraiment dire que tous ces projets sont d’une qualité de tout premier ordre à égalité ? Je ne pourrais pas l’affirmer avec certitude
      Avant, on pouvait estimer l’effort investi dans ce genre de choses à partir de la finition d’un site web ou de quelques éléments de surface. Maintenant, ce genre de détail se règle facilement avec des LLM
      De manière similaire, une fois la poussière retombée, l’un des plus grands effets laissés par Kickstarter a été que la vidéo de pitch de 3 minutes est devenue beaucoup plus agressivement optimisée et raffinée
      Mais je ne sais pas si cela se traduit réellement par une implémentation mûrement réfléchie, une roadmap solide et un véritable élan
    • Sur iOS, c’est différent. Pour publier sur l’App Store, il faut payer des frais d’adhésion annuels, ou alors recompiler et réinstaller les builds de compte personnel tous les 30 jours environ

  • L’app a l’air vraiment solide. Elle fait 17 Mo et j’aime le fait qu’elle utilise directement la bibliothèque ContainerAPIClient
    28 commits en 3 jours, 5 015 lignes de Swift, avec « Co-Authored-By: Claude Fable 5 » sur tous les commits
    C’est aussi appréciable qu’elle soit signée et notarée. En l’installant, le premier lancement a téléchargé les composants de la plateforme de conteneurs nécessaires
    Comme suggestion, ce serait bien d’ajouter un tutoriel de démarrage sur le site, en recommandant une image à tester, puis en montrant avec des captures d’écran ou une vidéo muette comment la lancer et ce qu’on peut faire avec
    La boîte de dialogue de création d’image propose « nginx:latest », mais ce n’est pas un très bon choix pour une démo de départ

    • Le discours AI-Maxing sur le site sautait un peu aux yeux. Cela ne veut pas dire que ce n’est pas une excellente app
    • Bonne suggestion. Je vais l’ajouter bientôt
    • Un tutoriel avec un exemple un peu plus réaliste aiderait beaucoup ici
      nginx:latest montre bien que la plomberie fonctionne, mais pas vraiment en quoi Apple Containers se distingue, dans le ressenti, de Docker Desktop ou OrbStack
      Un exemple avec une petite app, des volumes, du port mapping et une boucle simple de rebuild rendrait sans doute la valeur bien plus évidente

  • Ha ! On dirait qu’on a construit la même chose : https://container-ui.fly.dev/
    Maintenant je me dis que je n’aurais peut-être pas dû brûler autant de tokens

    • Oh, salut. Je viens justement de voir le passage où tu compares avec Orchard, c’est moi
      Ça a l’air propre. Au final, on construit tous la même chose ><

  • Ça fait presque 2 ans que j’utilise OrbStack avec plaisir
    L’intégration est bonne, c’est rapide, et la compatibilité avec les commandes docker justifiait le coût pour moi
    Cela dit, je vais aussi essayer ça

    • Les conteneurs natifs macOS semblent lancer une machine virtuelle Linux séparée pour chaque conteneur
      Le point fort d’OrbStack, c’est que tous les conteneurs tournent dans une seule machine virtuelle Linux, avec beaucoup d’optimisations de part et d’autre de la frontière de la VM. Cela inclut l’usage de fichiers image creux qui économisent beaucoup d’espace disque côté macOS
      Dès qu’on fait tourner plus de 4 ou 5 conteneurs sur macOS, les gains d’OrbStack en performance et en consommation de ressources deviennent rapidement importants
    • Je pense que l’équipe d’OrbStack prendra bientôt en charge les conteneurs natifs macOS et superposera ses propres fonctions de gestion par-dessus

  • Vraiment très bien. Le téléchargement du runtime et l’exécution de nginx:latest ont fonctionné parfaitement
    Quand on descend sur GitHub et qu’on voit Claude listé comme contributeur, ça devient presque un signe que l’app sera bonne. Dans le sens natif, pas Electron

  • J’aimerais qu’Apple ajoute la compatibilité avec l’API docker à Apple Containers

    • Je ne suis pas sûr de bien comprendre. Est-ce qu’on peut utiliser ça à la place de Docker Desktop pour faire tourner des conteneurs docker de manière « native » sur mon Mac ? Ou est-ce quelque chose de complètement séparé de docker ?
    • C’est orienté build, et ça consiste à exécuter buildkitd ou dockerd à l’intérieur des conteneurs Apple containerization
      Il n’y a pas de port forwarding ni de volumes hôte. En pratique, l’objectif est surtout de faire tourner buildkit sur Mac
      En revanche, c’est entièrement intégré avec le CLI docker et buildx
      https://github.com/cpuguy83/crucible

  • Les fonctionnalités sont bonnes, et j’apprécie aussi le fait que ce soit une petite app native SwiftUI
    J’ai récemment écrit un billet [1] sur l’usage des conteneurs Apple pour le codage agentique, et je viens de le mettre à jour pour mentionner Davit. Pour mes projets perso, je préfère largement utiliser les conteneurs Apple plutôt que Docker sur mes deux Mac à la maison
    [1] https://open.substack.com/pub/marklwatson/p/running-opencode...

  • Par rapport à OrbStack, ça donne quoi ? Est-ce qu’Apple Containers apporte quelque chose de perceptible en expérience développeur ? À mon échelle d’usage, l’implémentation d’OrbStack me semble déjà ultra-rapide

  • J’ai posté il y a quelques jours une version similaire que j’ai faite, mais elle n’a presque suscité aucune réaction
    Pour ceux que ça intéresse, c’est une app de barre de menus qui prend en charge les conteneurs, machines et registres
    https://news.ycombinator.com/item?id=48789503
    https://github.com/erdaltoprak/ContainerUtility