Containerization - pacote Swift para executar contêineres Linux no macOS

 (github.com/apple)
6 pontos por GN⁺ 2025-06-10 | 1 comentários | Compartilhar no WhatsApp
  • Containerization é uma ferramenta open source baseada em Swift que permite executar contêineres Linux no macOS
  • Funciona em Macs com Apple Silicon e usa o Virtualization.framework para isolar e executar cada contêiner dentro de uma máquina virtual leve
  • Inclui diversos recursos, como gerenciamento de imagens OCI, integração com registros remotos, criação de sistemas de arquivos ext4 e controle do ambiente do contêiner
  • Com Rosetta 2, também é possível executar processos x86_64 no Apple Silicon
  • Recursos como boot ultrarrápido, ambiente leve e customização da versão do kernel aumentam a flexibilidade e o desempenho para desenvolvedores

Visão geral do projeto

  • Containerization é um pacote Swift que ajuda aplicações a usarem contêineres Linux
  • É implementado na linguagem Swift e funciona em Macs com Apple Silicon usando o Virtualization.framework
  • A API oferece os seguintes recursos
    • gerenciamento de imagens OCI
    • integração com registros remotos de contêineres
    • criação e implantação de sistemas de arquivos ext4
    • interação com a família de sockets Netlink
    • fornecimento de um kernel Linux otimizado para boot rápido
    • criação e gerenciamento de máquinas virtuais leves
    • controle do ambiente de execução da máquina virtual
    • criação e controle de processos containerizados
    • execução de processos x86_64 no Apple Silicon com Rosetta 2
  • A documentação da API pode ser consultada em uma página oficial separada

Design e estrutura

  • Cada contêiner Linux é executado dentro de uma máquina virtual independente
  • É possível atribuir um endereço IP dedicado para cada contêiner, facilitando o gerenciamento de rede sem necessidade de port forwarding
  • Graças à configuração otimizada do kernel e ao sistema de arquivos raiz leve, é possível obter boot do contêiner em menos de 1 segundo
  • vminitd é um subprojeto do Containerization e atua como um sistema init leve que roda como processo inicial dentro da máquina virtual
    • Por meio de uma API GRPC, ele configura o ambiente de execução e dá suporte ao gerenciamento operacional dos processos do contêiner
    • Encaminha entrada e saída, sinais e tratamento de eventos para o processo que fez a chamada

Requisitos

  • É necessário um dispositivo Mac com Apple Silicon
  • Para compilar o pacote, é necessário
    • macOS 15 ou superior e Xcode 26 Beta
    • ou macOS 26 Beta 1 ou superior
  • Ao usar no macOS 15, o recurso abaixo é limitado
    • rede de contêineres não isolada: não é possível a comunicação entre contêineres na mesma rede vmnet

Exemplo de uso

  • Inclui o executável cctl: um playground para experimentar vários recursos da API
    • Exemplos de comandos principais
      • manipulação de imagens OCI
      • login em registro de contêineres
      • criação de blocos do sistema de arquivos raiz
      • execução de um contêiner Linux simples

Configuração do kernel Linux

  • Um kernel Linux é necessário para executar máquinas virtuais leves para contêineres
  • A configuração otimizada do kernel fornecida pelo Containerization fica no diretório kernel
  • Essa configuração inclui apenas os recursos mínimos, oferecendo boot rápido e ambiente leve
  • Há uma API para definir, conforme necessário, configurações e versões de kernel diferentes para cada contêiner
    • É possível testar várias versões e configurações de kernel
  • Também é possível usar kernels pré-compilados, como o vmlinux.container fornecido pelo projeto Kata Containers
    • Nesse caso, o driver VIRTIO deve estar embutido no kernel (compiled-in)

Resumo do processo de desenvolvimento e testes

  • É necessário preparar o ambiente com Swift, Static Linux SDK e outros componentes
  • É possível compilar e testar o código-fonte (make all, make test integration e outros comandos)
    • Para executar os testes de integração, é necessária uma imagem de kernel
  • Há suporte para configuração de dependências usando versões específicas relacionadas a gRPC/Protobuf
  • Inclui recursos para geração automática da documentação da API e visualização local

Contribuição open source e status do projeto

  • Contribuições são bem-vindas
  • A versão 0.1.0 é o primeiro lançamento oficial, e a estabilidade do código-fonte é garantida apenas dentro do escopo da versão minor
  • Essa política pode mudar em futuras releases minor

Resumo

  • Containerization é um pacote Swift inovador que permite a desenvolvedores gerenciar, executar e desenvolver com contêineres Linux no macOS em um ambiente otimizado
  • Ao executar cada contêiner em uma máquina virtual dedicada e leve, ele oferece vantagens em isolamento, desempenho, rede e customização do kernel
  • É uma solução adequada para desenvolvedores que querem expandir ambientes open source de contêineres para uma experiência nativa no macOS

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-10
Comentários no Hacker News

  • Compartilhando o que considero a parte mais surpreendente e interessante

    A mensagem de que contribuições para o projeto "container" são bem-vindas e incentivadas parece uma postura bastante incomum da Apple
    O WebKit foi um fork hostil do KHTML, e o Darwin também passava a sensação de que jogavam peças por cima do muro, uma por uma
    Espero que, nesses projetos que a Apple tem publicado recentemente no GitHub, a colaboração entre usuários e desenvolvedores fique mais ativa
    Tenho uma inclinação para F/OSS (software livre e de código aberto), mas por causa da política da empresa não posso usar Linux e acabo usando Mac todos os dias
    Depois da adoção do Apple Silicon, até troquei meu notebook de casa por um Mac, mas hoje em dia alternativas mais amigáveis ao Linux estão ficando cada vez mais próximas, o que me deixa esperançoso
    Essa mudança é um sinal positivo e, para usuários como eu que tinham esse conflito interno, é uma mudança reconfortante
    Se esse tipo de colaboração em open source acabar entrando num ciclo virtuoso, acho que a cultura de colaboração entre a Apple e a comunidade pode crescer ainda mais
    Imagino um ambiente em que desenvolvedores como eu obtenham benefícios diretos com essa mudança e, ao mesmo tempo, ganhem até respeito pela Apple

    • Opinião de que não há tanto motivo para se surpreender com a participação da Apple na comunidade open source
      Menção ao fato de que o Swift e seus frameworks relacionados também recebem muitas contribuições da comunidade open source

    • Como este projeto lida com Linux, há a visão de que, por causa do copyleft do Linux, a Apple não teria muita escolha além de adotar uma forma de colaboração

  • Recomendação do vídeo relacionado da apresentação da WWDC 2025 (https://developer.apple.com/videos/play/wwdc2025/346/)
    A estrutura isola cada contêiner em uma VM Linux leve
    É possível executar diretamente baixando a ferramenta container (https://github.com/apple/container/releases), requer macOS 26

    • Esta submissão é sobre https://github.com/apple/containerization e não sobre o projeto container
      O containerization é mais interessante porque serve para distribuir apps junto com um sidecar de contêiner
      Já o container é voltado para desenvolvedores usarem um ambiente como docker run ...
      Sobre container, há uma thread separada no HN (https://news.ycombinator.com/item?id=44229239)

    • Também funciona no macOS 15, mas vale notar que alguns recursos de rede podem ser limitados

  • No comunicado à imprensa e na sessão da WWDC, foi mencionado que a ferramenta CLI está em https://github.com/apple/container
    Como alguém com muito interesse nesse tipo de ferramenta, eu esperava que ela já viesse incluída por padrão no Xcode Beta mais recente, mas ainda não está lá
    O pacote prebuilt ainda está sendo preparado, mas o andamento pode ser acompanhado na issue pública (https://github.com/apple/container/issues/54)

  • Fico me perguntando como a Docker se sente em relação a isso
    Imagino que uma parte considerável dos usuários do Docker for Desktop use Mac

    • Opinião de que essa mudança, na verdade, torna o desenvolvimento do Docker Desktop muito mais fácil
      Agora não é mais necessário configurar uma VM Linux própria, então a dificuldade de desenvolvimento diminui
      Ainda assim, a previsão é de que muitos usuários continuem preferindo o Docker Desktop por causa da CLI familiar, do Docker Compose e de vários elementos de UX próprios da Docker
      Explicação de que trocar de runtime de contêiner não é algo simples

    • Suposição de que, do ponto de vista da Docker, o sentimento seria parecido com o que ela tem em relação ao podman

    • Como o Docker Desktop é um software comercial de código fechado e este projeto é software livre, isso parece uma boa notícia para os usuários

  • Fico curioso se essa tecnologia pode ser usada para empacotar contêineres Linux dentro de apps no macOS
    Por exemplo, seria útil para permitir que ferramentas como GPT acessem um ambiente Linux sem comandos CLI com privilégios de root

    • Se funcionar apenas no macOS 26 já servir, então isso pode ser usado exatamente para esse objetivo
      Caso contrário, também é possível usar diretamente o Virtualization.framework, mas isso exige trabalho adicional

    • Convicção de que a tecnologia foi criada justamente para esse tipo de uso

  • É uma estrutura interessante: cada contêiner roda em sua própria VM isolada, com isolamento completo e até IP independente, mas esse tipo de design não é comum em Linux ou Windows
    Se houver ao menos uma pessoa da equipe que não use Mac, o modelo de desenvolvimento local quebra
    Conclusão de que dificilmente isso substituirá Docker/Compose

  • Dois dos três principais sistemas operacionais de desktop agora conseguem oficialmente executar VMs Linux para rodar aplicativos nativos de Linux
    Diante dessa tendência, daria para argumentar que o Linux venceu de fato
    A API de syscalls do Linux agora ocupa praticamente a posição de API universal que roda em quase todo lugar

    • Contra-argumento de que o simples fato de o desenvolvimento de aplicações baseadas em Linux precisar acontecer normalmente sobre dois grandes sistemas não Linux não é exatamente algo que se possa chamar de "vitória do Linux"
      Relato de experiência de que a realidade do Linux no desktop continua instável e difícil de recomendar
      Feedback sincero de que, mesmo instalando Fedora/Ubuntu em PCs ou notebooks recentes todos os anos, ainda não há sensação de boa usabilidade e estabilidade

    • Visão de que, ao oferecerem um jeito de continuar usando Linux sem sair das outras duas plataformas, elas acabam desacelerando o aumento da participação do próprio Linux no mercado desktop

    • Destaque para a desvantagem de que ainda não existe uma solução realmente adequada para gráficos, áudio e GUI

    • Levantamento da dúvida: "se o único jogador participando do jogo é você mesmo, isso é vencer?"
      Brincadeira de que, se você falar disso para um usuário comum de Windows ou Mac, ele provavelmente nem sabe o que é Linux

    • Opinião de que o simples fato de existir um "macOS com Linux" já tem impacto

  • Fico curioso se eles também otimizaram o gerenciamento de memória, para evitar que as VMs usem mais memória do que o necessário

  • Não sei exatamente qual é o processo, mas a sensação é de que a velocidade de build está lenta demais
    Mesmo aumentando mais os recursos de CPU/memória com as opções -c e -m, quase não senti diferença

    • Pergunta sobre em comparação com qual ambiente isso está lento
      Compartilhamento de uma experiência passada com um Mac Silicon + Rancher Desktop, em que parecia estar construindo imagens x86, mas essas imagens não funcionavam corretamente em hardware x86 real

  • Na demo curta (https://developer.apple.com/videos/play/wwdc2025/346), foi impressionante ver que a VM consegue iniciar em escala de centenas de milissegundos
    Isso roda sobre o Virtualization.framework, tecnologia que Docker Desktop/Colima/UTM etc. também já usavam opcionalmente
    Fico curioso sobre o overhead de memória ao rodar vários contêineres em paralelo

    • Explicação de que, graças a uma configuração otimizada do kernel Linux (kernel config, https://github.com/apple/containerization/…), um sistema de arquivos raiz mínimo e um sistema init leve, o tempo de inicialização dos contêineres caiu para menos de 1 segundo