Apple Lança uma Alternativa ao Docker Alimentada por Swift para macOS
A Apple apresentou uma alternativa de código aberto ao Docker, baseada em Swift, para executar contentores Linux no macOS, com foco na segurança e isolamento.
A Apple lançou silenciosamente um novo projeto de código aberto que poderá alterar significativamente a forma como os contentores são executados no macOS. Simplesmente chamado container, ele apresenta um runtime de contentores nativo da Apple, desenvolvido em Swift, concebido especificamente para sistemas macOS, especialmente aqueles que funcionam com Apple Silicon.
No seu núcleo, o container permite aos utilizadores criar, construir, executar e enviar contêineres Linux compatíveis com OCI. No entanto, ao contrário do Docker, que normalmente depende de uma máquina virtual partilhada para todos os contêineres no macOS, a abordagem da Apple executa cada contêiner na sua própria micro-VM leve, completa com um kernel Linux isolado e uma pilha de rede separada. De acordo com a página do projeto no GitHub:
A ferramenta consome e produz imagens de containers compatíveis com OCI, por isso pode puxar e executar imagens de qualquer registo de containers padrão. Também pode enviar imagens que construa para esses registos e executar as imagens em qualquer outra aplicação compatível com OCI.
Este modelo espelha o conceito de microVMs popularizado por ferramentas como o Firecracker, mas foi integrado de forma estreita no macOS através do Virtualization.framework, a interface nativa de hypervisor da Apple.
Embora a Apple não esteja a apresentar isto como um substituto completo do Docker, a ferramenta cobre grande parte das mesmas funcionalidades para casos de uso em desenvolvimento local. A CLI é familiar e acessível: com comandos como container image pull alpine, ou container run -ti alpine sh.
O que distingue esta ferramenta é a sua integração perfeita no próprio sistema operativo macOS. Em vez de emular um ambiente Linux com ferramentas externas, a solução da Apple utiliza Swift para grande parte do seu userland, incluindo um pequeno sistema init chamado vminitd que arranca contêineres em questão de milissegundos.
O projeto também inclui um pacote Swift, “Containerization,” que disponibiliza APIs de baixo nível para gerir imagens, volumes, redes e processos de arranque, oferecendo aos utilizadores avançados e criadores de ferramentas uma base poderosa.
Ok, até agora tudo bem, mas agora deixe-me partilhar alguns pensamentos meus sobre o assunto. Honestamente, estou um pouco confuso com esta decisão da Apple. E vou explicar porquê imediatamente.
Primeiro, vamos esclarecer uma coisa — não existe verdadeira containerização nativa em qualquer sistema operativo que não seja o Linux, e há uma razão simples para isso. O Docker depende de funcionalidades específicas do kernel do Linux, como cgroups, namespaces e sistemas de ficheiros em overlay, que o kernel do macOS não consegue fornecer.
Por essa razão, o novo projeto da Apple utiliza uma máquina virtual Linux leve separada para executar cada contêiner individualmente. Ao mesmo tempo, a abordagem da Docker é executar tudo dentro de uma única máquina virtual (construída com o LinuxKit) que hospeda o Docker Engine e todos os contêineres.
Então, no caso da Apple, cada contentor está numa máquina virtual separada, o que significa muitas máquinas virtuais (não importa o quão leves sejam), o que não parece ser a abordagem mais eficiente.
Por outro lado, as VMs separadas têm algumas vantagens. Por exemplo, uma das principais vantagens do novo projeto da Apple é que ele fornece a cada container o seu próprio kernel Linux dedicado, ao contrário do Docker, que partilha um único kernel entre todos os containers (não é possível misturar versões do kernel por container).
Além disso, também utiliza a stack de rede nativa do macOS, enquanto o Docker normalmente depende de uma máquina virtual com NAT ou rede em ponte. Para ajudar a tornar isto mais claro, preparei uma tabela de comparação rápida:
| Funcionalidade | Docker Desktop | Contentor de Maçãs |
|---|---|---|
| Modelo de VM | VM partilhada para todos os contentores | Micro‑VM por contentor |
| Núcleo | Kernel Linux único para todos | Kernel Linux dedicado por contentor |
| Base | Utiliza o Docker Engine e um hipervisor (por exemplo, qemu ou HyperKit) | Utiliza o próprio Virtualization.framework da Apple |
| Redes | NAT ou ponte via VM | Pilha de rede nativa do macOS (com limitações nas primeiras versões) |
| Tempo de execução | runc/containerd | vminitd, um sistema de inicialização Swift personalizado |
| Integração | Multiplataforma e focado em conteúdos | Profundamente nativo do macOS e centrado no Swift |
Apesar de todas as diferenças, a ideia central é a mesma em ambos os casos — construir, executar e trabalhar com imagens de contêiner compatíveis com OCI. Sob essa perspetiva, o Docker continua a oferecer muito mais flexibilidade e capacidades do que o novo projeto da Apple.
Por exemplo, ainda não existe um equivalente ao docker-compose, e o ecossistema de ferramentas (por exemplo, sem painel de GUI, orquestração limitada) ainda precisa ser desenvolvido e melhorado.
Então, pergunto-me por que a Apple colocou todo este esforço em criar isto. Para além de "Feito pela Apple", parecem querer obter a sua parte deste nicho enorme, quase totalmente dominado pelo Docker, oferecendo melhor integração com o macOS, utilizando APIs nativas do sistema em vez de daemons de terceiros e, eventualmente, uma melhor isolação de segurança, o que reduz a superfície de ataque.
Como o projeto ainda está nos seus primeiros dias, será interessante ver como evolui — e se conseguirá corresponder às expetativas da Apple, acabando por substituir o Docker ou o Podman como a ferramenta de containers preferida pelos programadores no macOS.