Dev Containers e Testcontainers no Mac

Por que o mecanismo importa para os testes

Uma suíte Testcontainers inicia um Postgres, Kafka ou Redis real para uma classe de teste e o descarta depois. Um Dev Container recompila e reinicia toda a cadeia de ferramentas do projeto. Nos dois casos, o tempo vai para chamadas de ciclo de vida: criar, iniciar, parar e remover, repetidamente. É nessas chamadas que o Oxcart é mais rápido.

Oxcart 0.1.2 medido em 2026-10-10 com o cliente docker 29.9 incluído; os outros ambientes foram medidos mais cedo no mesmo dia, no mesmo Mac e com a mesma estrutura de testes, usando docker 29.4. Apple M5 Max, 8 CPUs e 12 GiB para cada um, um ambiente por vez, medianas de cinco amostras. Tabela completa: comparações.

Conecte Dev Containers e Testcontainers ao Oxcart

1. Instale e abra o Oxcart. A configuração cria um contexto Docker chamado oxcart. Ele só se torna atual quando nenhum outro está em uso, então confira com docker context show.
2. Aponte o comando docker para o Oxcart. Execute docker context use oxcart ou ative Use Oxcart for the docker command em Settings › Command line tools. Desativar restaura o contexto anterior.
3. Forneça o socket aos frameworks de teste. Para ferramentas que leem DOCKER_HOST em vez de contextos Docker, exporte a variável a partir do contexto: export DOCKER_HOST=$(docker context inspect oxcart --format '{{.Endpoints.docker.Host}}').
4. Execute os testes. Execute sua suíte normalmente. O Testcontainers cria, inicia e remove os contêineres pela Docker Engine API.
5. Abra o Dev Container. Abra o projeto no seu Dev Container ou execute devcontainer up --workspace-folder . com a CLI Dev Containers.

Testcontainers

As bibliotecas Testcontainers (Java, Go, Node, Python, .NET e outras) se comunicam diretamente com a Docker Engine API, sem passar pela CLI docker. O Oxcart negocia a versão 1.54 da API e aceita de 1.40 a 1.54, então as versões atuais do Testcontainers se conectam sem configurações especiais quando encontram o socket.

Encontrando o socket

O Testcontainers verifica DOCKER_HOST primeiro. O socket do Oxcart fica na sua pasta privada de estado, com modo 0600, e o caminho é armazenado no contexto Docker oxcart. Exporte uma vez por shell ou defina na configuração de testes da IDE:

export DOCKER_HOST=$(docker context inspect oxcart --format '{{.Endpoints.docker.Host}}')
./gradlew test        # or: mvn verify, go test ./..., pytest, npm test

Contêineres auxiliares e o socket dentro dos contêineres

O Testcontainers inicia um pequeno contêiner auxiliar que limpa recursos após testes que falham, e algumas configurações executam testes dentro de um contêiner. Ambos montam o socket Docker. No Oxcart, -v /var/run/docker.sock:/var/run/docker.sock oferece ao contêiner a mesma API Docker pelo lado Linux, então auxiliares, docker-outside-of-docker, Portainer e Traefik funcionam como esperado. Se uma ferramenta tentar montar no contêiner o caminho DOCKER_HOST do Mac, a configuração padrão do Testcontainers TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE indica que deve montar /var/run/docker.sock.

Imagens compiladas de um Dockerfile

O Testcontainers pode compilar uma imagem de um Dockerfile no seu teste (ImageFromDockerfile e equivalentes). Isso usa o endpoint de build da Engine API, que o Oxcart executa no BuildKit, com contextos tar (simples e gzip), argumentos de build, labels e múltiplas tags.

Dev Containers

Um Dev Container descreve a cadeia de ferramentas do projeto como um contêiner, e as ferramentas Dev Containers (extensão do VS Code, CLI devcontainer e editores que a usam) o compilam e executam pela CLI docker. Com o contexto oxcart ativo, quem faz isso é o Oxcart.

Abra o projeto com sua cadeia de ferramentas e serviços de apoio juntos. A CLI Dev Containers inicia o workspace junto com serviços como Postgres e Redis; o usuário node sem root pode editar o workspace, e o script pós-criação do projeto prepara as dependências. A equipe obtém o mesmo ambiente a partir da mesma configuração.

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . bash

Dicas para Dev Containers no Apple silicon

• Arquitetura: a maioria das imagens-base de Dev Containers oferece arm64. Para uma imagem exclusiva de amd64, o Oxcart usa Rosetta; consulte Docker Compose no Apple silicon.
• Dependências em volumes: coloque node_modules, caches de pacotes e dados de bancos em volumes nomeados e mantenha o código-fonte no workspace montado por bind mount.
• Monitoramento de arquivos: edições feitas no Mac não geram eventos inotify dentro dos contêineres, então um monitor no contêiner deve usar polling.
• Agentes de programação: um agente dentro de um Dev Container mantém seu shell no contêiner do projeto; um agente no Mac pode inspecionar os serviços do Dev Container pelo servidor MCP do Oxcart (Docker para agentes de programação com IA).

O contexto Docker, sem surpresas

O Oxcart cria o contexto oxcart na configuração e só o torna atual quando isso não interfere no que você usa: se o contexto atual é default e nada responde em seu socket. Caso contrário, mantém o contexto atual. Settings › Command line tools tem Use Oxcart for the docker command, que muda para oxcart e lembra o contexto substituído; desativar volta ao anterior. O Oxcart nunca cria nem substitui /var/run/docker.sock no Mac, e sua API nunca usa TCP.

Perguntas

O Testcontainers funciona em Macs com Apple silicon usando Oxcart?

Sim. O Testcontainers usa a Docker Engine API implementada pelo Oxcart (versões de 1.40 a 1.54), incluindo o endpoint de build usado para imagens compiladas de um Dockerfile. Contêineres também podem montar o socket Docker em /var/run/docker.sock, como os auxiliares do Testcontainers esperam.

Como configuro DOCKER_HOST para o Testcontainers?

Leia o valor do contexto Docker oxcart: docker context inspect oxcart --format '{{.Endpoints.docker.Host}}' imprime um caminho unix://. Exporte-o como DOCKER_HOST no shell ou na configuração de execução de testes da IDE.

Por que meus testes de integração são mais rápidos com Oxcart?

Suítes de testes gastam grande parte do tempo criando, iniciando, parando e removendo contêineres. No mesmo Mac, o Oxcart registrou 2.5 ms por criação via API, 18.5 ms por início, 4.0 ms por parada e 77 ms para parar e remover 20 contêineres: o mais rápido dos três ambientes testados em cada operação.

O Dev Containers do VS Code funciona com Oxcart?

A CLI Dev Containers 0.89.0 compilou e iniciou uma configuração real com múltiplos serviços no Oxcart, com Postgres e Redis saudáveis e workspace gravável pelo usuário do contêiner. As ferramentas Dev Containers usam a CLI docker, então aponte-a para o Oxcart com o contexto oxcart.

docker-outside-of-docker funciona em um Dev Container?

Sim. Monte /var/run/docker.sock no contêiner e a CLI docker interna se comunica com o mesmo mecanismo. Os endpoints privados do Oxcart são recusados por esse socket, então um contêiner pode gerenciar contêineres, mas não acessar os componentes internos do Oxcart.

O Oxcart substitui /var/run/docker.sock no Mac?

Não. O Oxcart nunca cria nem substitui /var/run/docker.sock no Mac. Os clientes o acessam pelo contexto Docker oxcart ou pelo caminho do socket indicado nesse contexto.

Fontes e método

• Compatibilidade: caminhos de integração verificados do Oxcart (build da Engine API usado por docker-py e Testcontainers, CLI Dev Containers 0.89.0, socket Docker dentro de contêineres) e intervalo de versões da API.
• Seleção do contexto Docker e configuração da linha de comando: Oxcart conforme distribuído.
• Dados de velocidade: Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPUs e 12 GiB; os outros ambientes foram medidos mais cedo no mesmo dia, no mesmo Mac e com a mesma estrutura de testes, usando o cliente docker 29.4.