Docker Sandboxes com microVMs isolam ambientes de desenvolvimento sem afetar o sistema host
Aprofundamento CEVIU
Aprofundamento
O autor usa um caso simples, compilar um livro em Markdown para PDF com Pandoc e XeLaTeX, para mostrar como os Docker Sandboxes mantêm o host limpo. Os ambientes rodam em microVMs, gerenciadas pela CLI sbx. O teste foi feito com a versão v0.51.0 em 9 de novembro de 2026 e repetido em 10 de novembro de 2026 no macOS com Apple silicon. O build gerou um PDF de 42 páginas em ambos os ambientes.
Há dois caminhos para preservar o ambiente. O primeiro é o snapshot com sbx template save, equivalente ao docker commit: rápido, mas sem documentar como o estado foi criado. O segundo é um Dockerfile, construído com docker build, exportado e importado no sbx, porque os Sandboxes não compartilham o image store do Docker Engine do host. Para TI corporativa, o ponto técnico é que a imagem base precisa ser compatível com sandboxes, e que o kit padrão (Debian 13) e a imagem sbx/shell-image (Ubuntu 26.04) entregam versões diferentes: Pandoc 3.1.11.1 e Node.js 20.19.2 num caso, Pandoc 3.7.0.2 e Node.js 22.22.1 no outro.
Os custos e riscos aparecem no texto. A instalação baixou cerca de 820 MB e ocupou 2,5 GB. A imagem baseada em Dockerfile usou cerca de 7 GB no Docker Desktop, e o tar exportado ficou com 1,9 GB. Na segurança, o autor define política de rede deny-all por padrão, alerta que o diretório do workspace é gravável (o modo --clone cria uma cópia privada), que templates não incluem o workspace nem copiam políticas de rede, e que snapshots podem capturar credenciais. Também recomenda usuário não root e rebuilds periódicos para absorver atualizações de segurança.
O que mudou
O CEVIU já acompanha o tema. Em 20 de fevereiro de 2026, noticiou "Execute NanoClaw em Sandboxes de Shell Docker", sobre o recurso de shell sandbox em microVMs. Em 20 de abril de 2026, o artigo "Por Que MicroVMs: A Arquitetura por Trás dos Sandboxes Docker" explicou o isolamento com kernel próprio e daemon Docker privado. Em 15 de abril de 2026, "Executando agentes de IA com templates customizados usando o sandbox Docker" mostrou toolchains pré-instaladas em imagens OCI customizadas.
Nas matérias anteriores o foco eram agentes de IA isolados. Agora o mesmo mecanismo aparece aplicado a um ambiente de desenvolvimento comum, com comparação explícita entre snapshot e Dockerfile e a menção a Kits como alternativa para combinar agente, ferramentas e permissões.
Por que isso importa
Para quem opera TI corporativa, isso aponta um caminho para padronizar estações de desenvolvimento sem inflar o host. Leitura editorial: o Dockerfile versionado tende a ser a opção mais auditável, enquanto o snapshot serve a prototipação. Vale orçar o armazenamento (imagens de vários GB), fixar digests e versões de pacotes para reprodutibilidade, e tratar política de rede e segredos em snapshots como itens de governança desde o início.
Linha do tempo
CEVIU noticia o recurso de shell sandbox do Docker Sandboxes, com agentes em microVMs.
CEVIU mostra templates customizados com toolchains pré-instaladas no sbx.
CEVIU explica a arquitetura de microVMs por trás dos Docker Sandboxes.
Guia mostra ambiente de build isolado com snapshot e Dockerfile, testado com a v0.51.0 do Docker Sandboxes.
Perguntas frequentes
Qual a diferença entre snapshot e Dockerfile nos Docker Sandboxes?
O snapshot, feito com sbx template save, guarda o estado atual do sandbox, como o docker commit, sem registrar como foi montado. O Dockerfile descreve o ambiente em código, o que facilita atualizar, versionar e compartilhar. Segundo o autor, o Dockerfile é a opção melhor para reprodutibilidade.
O sbx precisa de Docker Engine instalado no host?
Não para usar os sandboxes locais. Mas a etapa do Dockerfile usa docker build e docker image save, então é preciso ter Docker Engine ou Docker Desktop funcionando. Depois, a imagem exportada é importada no sbx, que não compartilha o image store do host.
Quais os requisitos para rodar sandboxes locais?
No Linux, Ubuntu 24.04 ou superior com KVM disponível e usuário no grupo kvm. No macOS, versão 14 ou superior em Apple silicon. No Windows, Windows 11 em processador Intel ou AMD de 64 bits com Windows Hypervisor Platform habilitado.
A microVM protege os arquivos do projeto?
Não por completo. O diretório montado do host é gravável, então um processo ou agente de IA pode alterar ou apagar arquivos nele. Para projetos Git, o modo --clone dá ao sandbox uma cópia privada de trabalho, permitindo revisar mudanças antes de trazê-las ao host.
Fontes
- containersecurity.devfonte original
- Categoria
- CEVIU TI
- Publicado
- 11 de novembro de 2026
- Editoria
- CEVIU TI