1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Davit é um app nativo para macOS que executa e gerencia containers Linux na plataforma de containers da Apple em Macs Apple silicon, podendo ser usado sem Docker Desktop
  • Ele se comunica diretamente via XPC com o daemon container open source da Apple, usando o mesmo caminho da CLI, sem Electron, webviews ou agentes próprios em segundo plano
  • Em um único app, lida com iniciar e parar containers, streaming de logs, acesso ao terminal, navegação por arquivos, build de Dockerfile e importação de Compose
  • É oferecido como app gratuito e open source sob licença MIT, assinado com Apple Developer ID e notarizado, e requer um Mac Apple silicon com macOS 15 ou superior
  • Diferentemente do Docker Desktop, usa uma VM leve por container; quando não há containers em execução, o serviço de plataforma em segundo plano fica ocioso em cerca de 25 MB

Objetivo e ambiente de execução do Davit

  • Davit é um app macOS totalmente nativo para a plataforma de containers da Apple
  • Executa containers Linux em Apple silicon e não precisa do Docker Desktop
  • É gratuito e open source, oferecido sob a licença MIT
  • O app é assinado e notarizado com Apple Developer ID
  • O requisito é um Mac Apple silicon rodando macOS 15 ou superior
  • A instalação pode ser feita pelos releases ou via Homebrew
    • brew install wouterdebie/tap/davit

Comunicação direta com o daemon container da Apple

  • O Davit se comunica diretamente via XPC com o daemon container open source da Apple
  • Esse caminho é o mesmo usado pela CLI container
  • Não usa Electron, webviews nem agentes próprios em segundo plano

Recursos de gerenciamento de containers

  • O painel mostra serviços, uso de disco e CPU em tempo real de todos os containers em execução
  • Na lista de containers, cada linha permite verificar o status e agir diretamente
    • Iniciar, parar, reiniciar, excluir
    • CPU em tempo real
    • Memória
    • IP
  • A tela de cada container também oferece recursos para entender seu estado de execução
    • Logs em streaming com modos follow e boot
    • Gráficos de estado em tempo real
    • Verificação da configuração bruta
  • Em containers em execução, é possível abrir um terminal diretamente via API nativa
    • É possível abrir um shell interativo no Terminal ou no iTerm
    • Não requer CLI

Edição de containers imutáveis e acesso a arquivos

  • Como os containers são imutáveis, o Davit permite pré-preencher um novo container com base na configuração existente e recriá-lo
  • A nova configuração do container reflete a configuração existente, exceto entrypoint e env da imagem
  • O fluxo é ajustado para alterar rapidamente portas, variáveis de ambiente, mounts e recursos
  • Dentro do app, é possível navegar pelo sistema de arquivos de um container em execução
    • Navegar por pastas
    • Baixar arquivos para o Mac
    • Fazer upload de arquivos
    • Excluir arquivos
  • As operações com arquivos são tratadas por API nativa e não exigem o comando docker cp

Importação de Compose e build de Dockerfile

  • O Davit abre um docker-compose.yml e mostra primeiro os recursos que serão criados
    • Serviços em ordem de dependência
    • Volumes
    • Redes
    • Comandos CLI equivalentes por serviço
    • Alertas sobre itens não suportados
  • Como a plataforma da Apple não tem compose nativo, o Davit orquestra a stack diretamente
  • A importação de Compose cobre um subconjunto suportado
    • Suporte: image, ports, environment, volumes nomeados/bind, networks, limites de recursos, command, user, working_dir
    • Exemplos que geram alerta: restart:, healthcheck:, build:
  • O build de Dockerfile está disponível em Images → Build Image
    • Seleciona-se a pasta de contexto e o Dockerfile
    • Configuram-se tag e build args
    • O Davit aciona diretamente o builder da Apple baseado em BuildKit e o inicia se necessário
  • Também há limitações atuais da plataforma

Imagens, volumes, redes e registries

  • O Davit oferece suporte a operações relacionadas a imagens
    • Pull com progresso
    • Executar container a partir de uma imagem
    • Atribuir tags
    • Prune
  • Também oferece operações com volumes e redes
    • Criar volumes com tamanho definido
    • Criar sub-redes personalizadas
    • Verificar itens em uso antes da exclusão
  • O login em registries é tratado em Settings → Registries
    • Docker Hub
    • ghcr.io
    • quay.io
    • Qualquer registry OCI
  • As credenciais são validadas no registry antes de serem salvas
  • Credenciais validadas são armazenadas no chaveiro de login do macOS e compartilhadas com a CLI container
  • O Docker Hub exige o uso de token de acesso em vez de senha

Configuração da plataforma e instalação automática

  • O Davit permite editar a configuração da plataforma dentro do app
    • CPU/memória padrão para novos containers
    • Registries
    • DNS
    • Recursos do builder
  • A configuração é validada pelo próprio carregador de configurações da plataforma e salva como um override TOML limpo
  • Se a plataforma Apple container não estiver instalada, o Davit baixa e verifica o instalador assinado da Apple e o instala na Library do usuário
  • O processo de instalação não exige privilégios de administrador
  • Se necessário, também é possível adicionar a CLI container ao shell

Implementação do app e fluxo inicial de uso

  • O Davit é implementado inteiramente em SwiftUI
  • Oferece ações rápidas na barra de menus
  • O ícone no Dock pode ser exibido apenas quando o usuário quiser
  • Não abre um navegador para renderizar gráficos em tempo real
  • Um fluxo inicial de exemplo é o seguinte
    • Instale a partir de Releases ou via Homebrew
    • Na primeira execução, se a plataforma não existir, o Davit a instala
    • Faça pull de nginxdemos/hello em Images → Pull Image
    • Execute a partir da imagem ou use Containers → Run Container
    • Mapeie o host 8088 para o container 80
    • Clique em Open in Browser na linha Ports do container ou acesse localhost:8088
    • Explore CPU, memória, disco, logs, arquivos, terminal e o recurso Edit & Recreate no container em execução

Diferenças em relação ao Docker Desktop e ao OrbStack

  • O Davit usa o engine da Apple
    • Cada container roda em sua própria VM leve baseada no Apple Virtualization framework
    • Possui endereço IP por container
    • É otimizado para Apple silicon
  • Usa imagens OCI
    • É possível fazer pull do Docker Hub, ghcr.io, quay.io ou de qualquer registry
    • Imagens privadas também podem ser usadas via login no registry
  • Linka as bibliotecas cliente da Apple e se comunica diretamente via XPC
    • Sem socket shim
    • Sem contrato de licença
    • Sem conta
  • O bundle do app tem 17 MB
    • Sem Electron
    • Sem imagem de VM empacotada
    • Sem serviço próprio em segundo plano
  • A proposta é diferente da do OrbStack
    • O OrbStack é um app comercial com sua própria camada de virtualização compatível com Docker
    • O Davit é uma UI gratuita e open source sobre a plataforma Apple container
    • O Davit não mantém itens residentes quando não há containers, usa IP por container e redes bridge, e oferece isolamento mais forte entre containers
    • O OrbStack é melhor em compatibilidade drop-in com a CLI/API docker e em suporte a uma gama maior de ferramentas
    • Ambos executam imagens OCI padrão

Memória, DNS e segurança

  • A arquitetura de memória não mantém uma VM Linux de múltiplos GiB sempre ligada
  • O Docker Desktop mantém uma grande VM independentemente de haver containers em execução, mas a plataforma da Apple inicia uma VM leve por container e a encerra quando o container para
  • Quando não há containers em execução, o serviço de plataforma em segundo plano fica ocioso em cerca de 25 MB
  • O próprio Davit é um app SwiftUI nativo, não Electron, e seu uso de memória é composto em grande parte por memória de frameworks compartilhados do macOS
  • Para acessar a partir do Mac usando o nome do container, é possível usar o domínio DNS local da plataforma
    • Execute sudo container system dns create test uma vez ou use seu próprio domínio
    • Defina-o como domínio padrão em Settings → Platform → DNS
    • O container web responderá no Mac como web.test
  • Todos os containers têm seu próprio IP, exibido na seção Network
  • Ao executar Avahi dentro do guest, é possível transmitir aliases mDNS .local
  • Cada release é assinado e notarizado com Apple Developer ID, abrindo sem alertas do Gatekeeper
  • O app é open source sob licença MIT e pode ser lido ou compilado diretamente
  • O Davit se comunica apenas com o daemon container local e com o GitHub para verificar atualizações

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News
  • Minha melhor estratégia na era da IA é não fazer nada
    Tive uma ideia parecida e pensei que daria para criar com vibe coding, mas achei que alguém se interessaria mais e faria antes, e foi exatamente o que aconteceu
    O app parece bom e estou ansioso para testar
    Como ideia grátis, eu gostaria de trancar agentes dentro de uma máquina virtual e, de fora da máquina virtual, enviar instruções por um harness para controlar os agentes instalados lá dentro. Idealmente, coisas como Codex/Claude não deveriam estar instaladas no host
    Um caminho ainda mais legal seria criar várias contas de usuário dentro da máquina virtual e limitar o sistema de arquivos e as políticas de rede por usuário. Assim, um agente de desenvolvimento, um agente de QA etc. teriam cada um uma visão de trabalho diferente, e isso poderia virar uma camada de base poderosa para automações adicionais
    Naturalmente, também deveria ser possível “anexar” à máquina virtual vários recursos, como DBs, filas e volumes externos, para que os agentes os usem com base em permissões

    • Isso é exatamente possível com o coderunner
      https://GitHub.com/instavm/coderunner
    • Em vez de máquina virtual, ele usa sandbox e usuários separados, mas o sandvault é bom para esse caso de uso e também faz a instalação automática
      Por transparência, já enviei alguns PRs para ele
      https://github.com/webcoyote/sandvault
    • “Power move da era da IA: não fazer nada” já era minha estratégia antes da IA
      Lá pelo fim dos meus 20 ou começo dos 30, parei quase completamente de desenvolver no tempo livre, porque toda a diversão que eu tirava de programar em si tinha desaparecido. Na verdade, eu nem gostava tanto assim; só era péssimo em decidir se algo valia ou não o meu tempo
      Mesmo quando eu pensava em um programa ou script que seria legal ter, na maioria das vezes, como naquela tabela do xkcd que calcula o tempo de retorno de criar um programa para economizar alguns minutos por semana, “a recompensa não compensava o esforço”. Ou era algo não exatamente necessário, mas interessante ou divertido de ter, só que exigiria inúmeras horas para realmente construir, então não valia nada a pena
      Se alguém criasse e publicasse algo que eu queria, ótimo; se não, paciência
      A grande mudança que os LLMs trouxeram é que agora dá para gerar coisas como pequenos scripts em alguns minutos, por alguns centavos até alguns dólares. Estou ressuscitando ideias extremamente de nicho que estavam guardadas havia muito tempo
      Coisas que antes levariam alguns fins de semana só fuçando APIs e documentação desconhecidas agora podem ser feitas em menos de 30 minutos ou, no mínimo, dá para decidir em minutos, em vez de horas, se aquilo não vai funcionar ou é chato demais e deve ser abandonado para sempre
    • Fiz algo parecido meio no improviso, com um frontend simples de navegador
      Gosto de rodar modelos abertos médios/grandes, mas não dá para confiar que eles não vão sair fazendo besteira, então criei isso e pretendo compartilhar em breve
    • Eu também já pensei nisso
      Parece algo simples como instalar o Claude em uma máquina virtual e acessar por um terminal SSH. Se precisar de GUI, dá para usar a extensão Remote SSH do VSCode e obter algo como uma UI de navegador de arquivos
      Imagino que também dê para instalar dentro da máquina virtual o Claude do VSCode ou outras extensões de chat
  • O que chamou mais atenção do que este projeto em si foi que um fenômeno que muita gente conseguia prever, especialmente no último ano mais ou menos, ficou visivelmente mais acelerado. Agora as pessoas conseguem criar suas próprias versões da mesma ideia muito mais rápido do que antes
    Em uns 10 minutos procurando, encontrei vários projetos Swift parecidos, e a maioria existe há apenas algumas semanas ou meses
    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
    Havia ainda mais se incluir os que têm menos estrelas no GitHub, os que são só de linha de comando e os que não são em Swift, mas o ponto é este
    As pessoas terão cada vez mais condições de criar por conta própria suas versões do software que desejam. Quando isso acontecer, o valor do software feito por outras pessoas diminui. A era do software hiperpersonalizado está chegando

    • Será que dá para dizer que todos esses projetos têm qualidade de primeira linha de forma equivalente? Não tenho como saber ao certo
      Antigamente, dava para estimar o esforço investido em algo assim pela qualidade do site ou por alguns elementos superficiais. Agora essas partes são resolvidas facilmente com LLMs
      De modo parecido, depois que a poeira baixou, um dos maiores impactos deixados pelo Kickstarter foi a evolução agressiva e o refinamento dos vídeos de pitch de 3 minutos
      Não sei se isso realmente se traduz em uma implementação e um roadmap bem pensados, nem em tração real
    • No iOS é diferente. Para publicar na App Store, você precisa pagar a assinatura anual, ou então recompilar e reinstalar builds de conta pessoal a cada 30 dias, mais ou menos
  • Parece um app realmente sólido. Tem 17 MB, e gostei do fato de ele usar diretamente a biblioteca ContainerAPIClient
    28 commits em 3 dias, 5.015 linhas de Swift, e todos os commits têm “Co-Authored-By: Claude Fable 5”
    Também é bom ver que ele é assinado e notarizado. Instalei, e na primeira execução ele baixou os componentes necessários da plataforma de contêineres
    Como sugestão, seria bom adicionar ao site um tutorial de início, recomendando uma imagem para testar e mostrando, com capturas de tela ou um vídeo sem áudio, como executar essa imagem e o que dá para fazer com ela
    A caixa de diálogo de criação de imagem sugere “nginx:latest”, mas ela não é tão boa como demo inicial

    • O texto de AI-Maxing no site deixou isso um pouco evidente. Isso não quer dizer que não seja um ótimo app
    • Boa sugestão. Vou adicionar em breve
    • Acho que um tutorial com um exemplo um pouco mais realista ajudaria bastante aqui
      nginx:latest mostra que o encanamento funciona, mas não mostra muito bem onde o Apple Containers parece diferente do Docker Desktop ou do OrbStack
      Um exemplo com um app pequeno, volumes, mapeamento de portas e um loop simples de rebuild provavelmente deixaria o valor muito mais fácil de perceber
  • Ha! Parece que nós também criamos a mesma coisa: https://container-ui.fly.dev/
    Agora fico pensando que talvez não devesse ter queimado tantos tokens

    • Oi. Acabei de ver que há uma comparação com o Orchard, e sou eu
      Parece bem limpo. No fim, estamos todos criando a mesma coisa ><
  • Tenho usado e gostado do OrbStack há quase 2 anos
    Ele é bem integrado, rápido e tem compatibilidade com comandos docker, então para mim valeu pagar
    Ainda assim, vou testar este também

    • Os contêineres nativos do macOS parecem iniciar uma máquina virtual Linux separada para cada contêiner
      O ponto forte do OrbStack é que todos os contêineres rodam dentro de uma única máquina virtual Linux, com muitas otimizações dos dois lados da fronteira da VM. Isso inclui o uso de arquivos de imagem esparsos, que economizam bastante espaço em disco no lado do macOS
      Quando você roda mais de 4 ou 5 contêineres no macOS, os ganhos de desempenho e de redução de uso de recursos do OrbStack crescem rapidamente
    • Acho que a equipe do OrbStack vai adicionar suporte a contêineres nativos do macOS em breve e colocar os recursos de gerenciamento deles por cima
  • Muito bom. Baixar o runtime e executar nginx:latest funcionou perfeitamente
    Quando você rola para baixo no GitHub e vê o Claude como contribuidor, isso está começando a virar um sinal de que o app será bom. No sentido de parecer nativo e não ser Electron

  • Gostaria que a Apple adicionasse compatibilidade com a API do docker ao Apple Containers

    • Também não sei bem. Dá para usar isso no lugar do Docker Desktop para rodar contêineres docker de forma “nativa” no meu Mac? Ou é algo totalmente separado do docker?
    • Isto é focado em builds, rodando buildkitd ou dockerd dentro de um contêiner do Apple containerization
      Não há coisas como encaminhamento de portas ou volumes do host. Na prática, o foco é rodar buildkit no Mac
      Dito isso, ele se integra totalmente com o docker CLI e o buildx
      https://github.com/cpuguy83/crucible
  • As funcionalidades são boas, e também gosto do fato de ser um pequeno app nativo em SwiftUI
    Escrevi recentemente um texto [1] sobre usar contêineres da Apple para codificação agentic e acabei de atualizá-lo para mencionar o Davit. Para projetos pessoais, nos meus dois Macs de casa, prefiro muito mais usar contêineres da Apple do que Docker
    [1] https://open.substack.com/pub/marklwatson/p/running-opencode...

  • Como ele se compara ao OrbStack? O Apple Containers oferece algo perceptível na experiência de desenvolvimento? Pelo meu uso, a implementação do OrbStack já parece absurdamente rápida

  • Alguns dias atrás eu publiquei uma versão parecida que criei, mas quase não teve reação
    Para quem se interessar, é um app de barra de menus com suporte a contêineres, máquinas e registries
    https://news.ycombinator.com/item?id=48789503
    https://github.com/erdaltoprak/ContainerUtility