Dev Containers et Testcontainers sur Mac

Pourquoi le moteur compte pour les tests

Une suite Testcontainers démarre un vrai Postgres, Kafka ou Redis pour une classe de test, puis le supprime. Un Dev Container reconstruit et redémarre toute la chaîne d'outils d'un projet. Dans les deux cas, le temps passe dans les appels du cycle de vie des conteneurs : créer, démarrer, arrêter, supprimer, encore et encore. Ces appels sont ceux où Oxcart est le plus rapide.

Oxcart 0.1.2 mesuré le 2026-10-10 avec son client docker 29.9 inclus ; les autres environnements mesurés plus tôt le même jour sur le même Mac et avec le même dispositif de mesure, avec docker 29.4. Apple M5 Max, 8 CPU et 12 GiB chacun, un environnement à la fois, médianes de cinq échantillons. Tableau complet : comparatifs.

Connecter Dev Containers et Testcontainers à Oxcart

1. Installez et ouvrez Oxcart. La configuration crée un contexte Docker nommé oxcart. Il ne devient courant que si rien d'autre n'est utilisé ; vérifiez donc avec docker context show.
2. Dirigez la commande docker vers Oxcart. Exécutez docker context use oxcart, ou activez Use Oxcart for the docker command dans Settings › Command line tools. La désactivation rétablit votre contexte précédent.
3. Donnez le socket aux frameworks de test. Pour les outils qui lisent DOCKER_HOST plutôt que les contextes Docker, exportez-le depuis le contexte : export DOCKER_HOST=$(docker context inspect oxcart --format '{{.Endpoints.docker.Host}}').
4. Exécutez vos tests. Lancez votre suite comme d'habitude. Testcontainers crée, démarre et supprime ses conteneurs via l'API Docker Engine.
5. Ouvrez le Dev Container. Ouvrez le projet dans son Dev Container, ou exécutez devcontainer up --workspace-folder . avec la CLI Dev Containers.

Testcontainers

Les bibliothèques Testcontainers (Java, Go, Node, Python, .NET et les autres) communiquent directement avec l'API Docker Engine, sans passer par la CLI docker. Oxcart négocie la version 1.54 de l'API et accepte les versions 1.40 à 1.54 : les versions actuelles de Testcontainers se connectent donc sans réglage particulier dès qu'elles trouvent le socket.

Trouver le socket

Testcontainers consulte d'abord DOCKER_HOST. Le socket d'Oxcart se trouve dans son dossier d'état privé, en mode 0600, et son chemin est enregistré dans le contexte Docker oxcart. Exportez-le une fois par shell, ou définissez-le dans la configuration de test de votre IDE :

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

Conteneurs auxiliaires et socket dans les conteneurs

Testcontainers démarre un petit conteneur auxiliaire qui nettoie après les exécutions de tests ayant planté, et certaines configurations exécutent les tests dans un conteneur. Les deux montent le socket Docker. Dans Oxcart, -v /var/run/docker.sock:/var/run/docker.sock donne à un conteneur la même API Docker depuis le côté Linux : les conteneurs auxiliaires, docker-outside-of-docker, Portainer et Traefik fonctionnent donc comme prévu. Si un outil tente plutôt de monter le chemin DOCKER_HOST côté Mac dans un conteneur, le réglage standard TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE de Testcontainers lui indique de monter /var/run/docker.sock.

Images construites à partir d'un Dockerfile

Testcontainers peut construire une image à partir d'un Dockerfile dans votre test (ImageFromDockerfile et ses équivalents). Cela utilise le point d'accès de construction de l'API Engine, qu'Oxcart exécute sur BuildKit, avec des contextes tar (bruts et gzip), arguments de construction, labels et plusieurs tags.

Dev Containers

Un Dev Container décrit la chaîne d'outils d'un projet sous forme de conteneur, et les outils Dev Containers (l'extension VS Code, la CLI devcontainer et les éditeurs qui l'utilisent) le construisent et l'exécutent via la CLI docker. Lorsque oxcart est le contexte courant, c'est Oxcart qui s'en charge.

Ouvrez votre projet avec sa chaîne d'outils et ses services de support réunis. La CLI Dev Containers démarre l'espace de travail avec des services comme Postgres et Redis ; votre utilisateur node non root peut modifier l'espace de travail, et le script de post-création du projet prépare ses dépendances. Les membres de l'équipe obtiennent le même environnement à partir de la même configuration.

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

Conseils pour Dev Containers sur puce Apple

• Architecture : la plupart des images de base Dev Containers proposent arm64. Pour une image exclusivement amd64, Oxcart l'exécute via Rosetta ; voir Docker Compose sur puce Apple.
• Dépendances dans des volumes : placez node_modules, les caches de paquets et les données des bases dans des volumes nommés, et gardez le code source dans l'espace de travail monté par bind mount.
• Surveillance des fichiers : les modifications faites sur le Mac ne produisent pas d'événements inotify dans les conteneurs ; un outil de surveillance exécuté dans le conteneur doit donc utiliser des interrogations périodiques.
• Agents de programmation : un agent exécuté dans un Dev Container garde son shell dans le conteneur du projet ; un agent sur le Mac peut inspecter les services du Dev Container via le serveur MCP d'Oxcart (Docker pour les agents de programmation IA).

Le contexte Docker, sans surprise

Oxcart crée son contexte oxcart à la configuration et ne le rend courant que si cela ne vous enlève rien : lorsque le contexte courant est default et que rien ne répond sur son socket. Sinon, votre contexte courant reste en place. Settings › Command line tools propose Use Oxcart for the docker command, qui bascule vers oxcart et mémorise le contexte remplacé ; le désactiver fait revenir en arrière. Oxcart ne crée ni ne remplace jamais /var/run/docker.sock sur votre Mac, et son API n'est jamais exposée en TCP.

Questions

Testcontainers fonctionne-t-il sur les Mac à puce Apple avec Oxcart ?

Oui. Testcontainers communique avec l'API Docker Engine, qu'Oxcart implémente (versions 1.40 à 1.54), y compris le point d'accès de construction utilisé pour les images issues d'un Dockerfile. Les conteneurs peuvent aussi monter le socket Docker à /var/run/docker.sock, comme l'attendent les conteneurs auxiliaires de Testcontainers.

Comment définir DOCKER_HOST pour Testcontainers ?

Lisez sa valeur dans le contexte Docker oxcart : docker context inspect oxcart --format '{{.Endpoints.docker.Host}}' affiche un chemin unix://. Exportez-le comme DOCKER_HOST dans votre shell ou la configuration d'exécution des tests de votre IDE.

Pourquoi mes tests d'intégration sont-ils plus rapides avec Oxcart ?

Les suites de tests passent une grande partie de leur temps à créer, démarrer, arrêter et supprimer des conteneurs. Sur le même Mac, Oxcart a mesuré 2.5 ms par création via l'API, 18.5 ms par démarrage via l'API, 4.0 ms par arrêt via l'API et 77 ms pour arrêter et supprimer 20 conteneurs : les meilleurs résultats des trois environnements testés pour chaque opération.

VS Code Dev Containers fonctionne-t-il avec Oxcart ?

La CLI Dev Containers 0.89.0 a construit et démarré une vraie configuration multiservice sur Oxcart, avec Postgres et Redis sains et un espace de travail modifiable par l'utilisateur du conteneur. Les outils Dev Containers pilotent la CLI docker : dirigez-la donc vers Oxcart avec le contexte oxcart.

docker-outside-of-docker fonctionne-t-il dans un Dev Container ?

Oui. Montez /var/run/docker.sock dans le conteneur et sa CLI docker communique avec le même moteur. Les points d'accès privés d'Oxcart sont refusés via ce socket : un conteneur peut donc gérer des conteneurs, mais pas accéder au fonctionnement interne d'Oxcart.

Oxcart va-t-il remplacer /var/run/docker.sock sur mon Mac ?

Non. Oxcart ne crée ni ne remplace jamais /var/run/docker.sock sur le Mac. Les clients l'atteignent via le contexte Docker oxcart ou le chemin du socket indiqué par ce contexte.

Sources et méthode

• Compatibilité : intégrations vérifiées d'Oxcart (construction via l'API Engine utilisée par docker-py et Testcontainers, CLI Dev Containers 0.89.0, socket Docker dans les conteneurs) et plage de versions de l'API.
• Sélection du contexte Docker et configuration de la ligne de commande : Oxcart tel que distribué.
• Chiffres de vitesse : Oxcart 0.1.2, 2026-10-10, Apple M5 Max, 8 CPU et 12 GiB ; les autres environnements ont été mesurés plus tôt le même jour sur le même Mac et avec le même dispositif de mesure, avec le client docker 29.4.