2026 OpenClaw : mode conteneur, transparence CLI Docker et Podman, montages et dépannage avec doctor

Faire tourner OpenClaw avec une chaîne d’outils adossée aux conteneurs impose que la passerelle et l’hôte s’entendent sur quel moteur OCI répond aux appels docker ou podman, où vivent dépôts et caches, et comment les skills tirent leurs dépendances. Le commutateur --container et la variable OPENCLAW_CONTAINER doivent raconter la même histoire dans chaque shell, service Compose et ligne de matrice CI ; dès qu’ils divergent, réapparaissent les échecs « chez moi ça marche ». Ce runbook ordonne mode → socket → montages → installation des skills → doctor, puis esquisse une passerelle sur Mac distant très doté en RAM, isolée des rafales de PR. Pour les dispositions natives versus Compose en premier lieu, voir OpenClaw 2026 : déploiement sur Mac distant ; pour dimensionner files, parallélisme et disque à côté d’une passerelle, 2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ?.

1. Une seule source de vérité pour --container et OPENCLAW_CONTAINER

Choisissez une autorité par environnement : figez OPENCLAW_CONTAINER=true dans Compose et traitez le drapeau CLI comme optionnel, ou standardisez des drapeaux explicites en CI et interdisez les exports silencieux dans le shell. Documentez le choix pour que l’astreinte ne fasse pas varier les deux indépendamment. Dans GitHub Actions ou Buildkite, imprimez la paire résolue au démarrage du job et faites échouer vite si elle est incohérente. Cette visibilité évite les bugs subtils où un poste développeur active le mode conteneur alors qu’une unité systemd ne le fait pas, laissant la moitié de la chaîne sur le PATH hôte.

Règle : ne changez jamais le mode conteneur dans le même lot que des identifiants ou des chemins de montage — séparez les PR pour que les retours arrière restent lisibles.

2. Docker ou Podman : sockets, contextes et transparence CLI

Montez le bon socket de contrôle et fixez DOCKER_HOST (ou l’équivalent Podman) en cohérence. Docker Desktop sur macOS expose souvent /var/run/docker.sock via une VM ; Podman rootless utilise un socket par utilisateur qui varie selon la distribution. Vérifiez que le CLI dans l’image parle bien à ce socket — mélanger un client Podman avec un démon Docker produit des « connection refused » trompeuses. Préférez deux profils Compose plutôt que des sockets symboliquement liés. Après tout déplacement de socket, lancez info ou version depuis le même espace de noms réseau que la passerelle.

3. Montages bind : espace de travail, configuration, caches et politique lecture seule

Liez le workspace et l’état avec des chemins hôte explicites qui existent avant up. Gardez les fichiers de politique en lecture seule lorsque c’est possible pour qu’un plugin ne réécrive pas openclaw.json. Séparez caches éphémères et files durables afin qu’un job de purge ne supprime pas un travail en cours. Alignez UID et GID avec l’utilisateur du conteneur ; les bind mounts macOS diffèrent d’une CI Linux, documentez les identifiants numériques validés. Quand les checkouts tournent, mettez à jour les chemins Compose ensemble — les binds obsolètes dominent la liste ENOENT pendant l’exécution des skills.

4. Dépendances des skills : d’abord l’image, puis un setupCommand idempotent

Cuisez les dépendances lourdes dans l’image pour que les démarrages à froid restent en secondes. Réservez setupCommand aux étapes semver figées et idempotentes — somme de contrôle ou déballage d’archive — sans invites interactives ni enchaînements cd liés à une disposition de home. Journalisez les versions d’outillage après setup pour des diffs rapides. Placez compilateurs natifs et en-têtes dans la même couche d’image ; mélanger des paquets entre redémarrages crée des erreurs de liaison qu’on attribue à tort à OpenClaw. Centralisez les installations de runtime partagées pour dédupliquer les téléchargements.

5. doctor comme recoupement, pas comme bouton au hasard

N’exécutez doctor qu’après stabilisation des montages et des sockets. Comparez la sortie aux journaux launchd ou Compose, aux écouteurs et aux routes dans l’ordre : droits, joignabilité du moteur, liens de la passerelle, plugins, puis proxys d’entreprise. Archivez la sortie dans le ticket. Corrigez routes dupliquées ou incohérences de mode conteneur avant d’augmenter la verbosité des journaux Gateway. Pour la stabilité longue durée de la passerelle sous macOS, lire aussi OpenClaw 2026 : passerelle launchd, stabilité et dépannage.

  • OPENCLAW_CONTAINER correspond-il au drapeau CLI dans chaque fichier d’unité ?
  • Le socket monté est-il le même que celui utilisé par votre test de fumée ?
  • Les scripts d’installation des skills sont-ils idempotents à chaque redémarrage de conteneur ?

6. Exemple : Mac distant haute mémoire comme passerelle isolée

Provisionnez un Mac dédié riche en RAM via SSH ou un tailnet ; installez-y Compose, supervision et expédition des journaux uniquement — étiquetez ailleurs les runners auto-hébergés pour que les rafales de PR n’affament pas la passerelle. Excluez explicitement ce nœud des matrices qui nettoient agressivement node_modules ou DerivedData entre jobs, sinon les symptômes OpenClaw deviennent aléatoires. Utilisez un NVMe rapide pour les couches d’image et les caches des skills, épinglez Node et les moteurs sur les versions de production, prenez un instantané après des exécutions doctor vertes, restreignez l’entrée aux ports au maillage ou au bastion, faites tourner les clés de déploiement avec les secrets CI et redémarrez chaque semaine dans une fenêtre pour libérer des descripteurs fuités. Vous échangez la colocalisation avec la ferme de build contre une latence prévisible vers canaux et backends MCP.

Pourquoi une passerelle de classe Mac mini reste pertinente pour ce schéma

La transparence conteneur n’est que la moitié du récit — il faut encore un hôte qui consomme peu au repos, reste silencieux et tient des mois sans intervention. Les Mac mini Apple Silicon associent bande passante mémoire et pile Unix de macOS avec Gatekeeper, SIP et FileVault, ce qui devance une tour générique sous un bureau pour des passerelles sans clavier. La consommation au repos reste faible pendant que SSH et les sockets moteur restent ouverts ; GPU et Neural Engine restent disponibles si vous ajoutez de l’inférence locale. Éviter les portables sujets au sommeil réduit le bruit support et le coût total de possession. Si vous voulez cette empreinte haute RAM isolée sans baie serveur, ouvrez la page d’accueil Macstripe, choisissez une région proche et optez pour un Mac mini M4 avec la RAM dont votre passerelle a besoin — du matériel fiable est le moyen le plus rapide de garder doctor au vert après chaque redémarrage.