COMPOSE_PROJECT_NAME · volumes dédiés et matrice de ports · aligner env_file et les variables dans le conteneur
Lorsque deux piles OpenClaw tournent en parallèle sur le même VPS, les échecs les plus fréquents sont les collisions de ports, les réseaux par défaut et noms de volumes qui se marchent dessus, et les clés API visibles sur l'hôte mais absentes de l'environnement du conteneur. Cet article part d'une baseline mono-instance vs jeu minimal de différences multi-instance pour aligner COMPOSE_PROJECT_NAME, les répertoires de données et une matrice de ports hôte, explique comment env_file et environment sont injectés, et propose une checklist de vérification en six étapes ainsi que les conditions d'un retour à une seule pile. À lire avec la baseline Docker Compose production et l'article Exit 137 et premiers pas.
Dupliquer docker-compose.yml et ajuster quelques ports ne suffit pas : le nom de projet Compose par défaut maintient réseaux et volumes anonymes sur une trajectoire de collision ; les export shell uniquement hôte n'entrent pas automatiquement dans les conteneurs ; un upstream du proxy inverse peut encore pointer vers une ancienne IP de conteneur. Dès que les signaux ci-dessous apparaissent, revenez au tableau et cochez chaque ligne au lieu d'empiler des conteneurs.
Ports modifiés mais pas COMPOSE_PROJECT_NAME : le réseau bridge par défaut et le DNS interne peuvent encore résoudre les noms de services d'une autre pile.
Chemin de données ou liens symboliques qui se recoupent : deux arbres ~/.openclaw ou workspaces partageant le même préfixe disque laissent les scripts de mise à jour s'écraser mutuellement.
Clés API seulement dans le profil shell : le processus enfant de docker compose up ne voit jamais le chemin env_file attendu par Compose.
Healthchecks trop agressifs : la seconde pile démarre à froid plus lentement, est redémarrée à tort et rivalise avec la première pour les verrous.
Proxy inverse encore ciblé sur 127.0.0.1 et un ancien port : lorsque deux passerelles alternent, le bord envoie encore le trafic vers une instance arrêtée. Alignez les upstreams avec l'article proxy inverse et TLS.
Ces champs forment le jeu minimal de différences habituel pour deux piles sur un même hôte. Si vous ne montez qu'une pile d'essai courte, terminez au moins nom de projet, répertoire de données, ports hôte et chemins env_file avant d'automatiser quoi que ce soit. Les plafonds de ressources et la rotation des journaux restent ceux de l'article baseline production.
| Champ | Baseline mono-instance | Scission requise multi-instance | Piège typique |
|---|---|---|---|
COMPOSE_PROJECT_NAME | Nom du répertoire par défaut | Un nom court unique par pile (par ex. oc_a / oc_b) | Renommer le dossier sans changer le nom de projet réutilise les volumes anonymes |
| Chemins des volumes de données | Un chemin hôte lié | Arbres entièrement séparés, par ex. /srv/openclaw-a et /srv/openclaw-b | Liens symboliques enfants qui pointent vers le même parent |
| Ports hôte | Un mapping du type 3000:3000 | Ports hôte distincts consignés dans une matrice d'exploitation | Échec de liaison de la seconde pile pendant que systemd la relance en boucle |
| Injection d'environnement | Un seul .env | Fichiers par pile, par ex. .env.oc-a, avec env_file explicite dans Compose | Exports hôte jamais pris en compte dans la portée de substitution de Compose |
| Healthchecks | Un seul start_period | Augmenter start_period et retries si le démarrage à froid est plus lent | Redémarrage simultané des deux piles et pic CPU |
Le nom de projet et le répertoire de données passent avant la matrice de ports ; inverser l'ordre fait écrire les deux états sous un même préfixe lors du premier script de mise à niveau.
Ces étapes supposent que vous savez déjà lancer l'extrait Compose officiel ou d'équipe sur une machine seule ; l'objectif est que la configuration rendue et l'environnement d'exécution de la seconde pile soient auditablement comparables.
Définir le nom de projet et les répertoires : exporter COMPOSE_PROJECT_NAME, créer un arbre de données dédié et vérifier l'absence de liens symboliques imbriqués vers l'autre pile.
Fixer la matrice de ports : attribuer des ports hôte libres à la passerelle, à l'interface de contrôle et aux canaux additionnels, et les consigner dans le runbook.
Séparer env_file : un chemin de secrets par pile au lieu de partager .env ; utiliser docker compose --project-directory pour fixer le répertoire de travail.
Rendu et diff : exécuter docker compose -f ... config pour les deux piles et vérifier que networks, volumes et ports n'affichent plus de montages en double ni de noms en conflit.
Contrôle à l'exécution : avec docker compose exec, afficher les variables utiles dans le conteneur et confirmer qu'elles concordent avec des contrôles masqués exécutés sur l'hôte.
Santé et journaux : appliquer start_period et les plafonds json-file de l'article baseline pour que deux piles ne remplissent pas le disque en même temps.
export COMPOSE_PROJECT_NAME=oc_b docker compose --env-file ./.env.oc-b -f docker-compose.yml config > /tmp/oc-b.rendered.yml docker compose --env-file ./.env.oc-b -f docker-compose.yml up -d docker compose --env-file ./.env.oc-b exec -T openclaw-gateway sh -lc 'env | grep -E "ANTHROPIC|OPENAI" | sed "s/=.*/=***MASK***/"'
Astuce : la sous-commande config ne fait que fusionner la configuration et ne démarre pas les conteneurs ; enregistrez le diff rendu avant up pour comparer les piles.
Traitez les éléments ci-dessous comme un point de départ astreinte et post-mortem ; remplacez les seuils par ceux de vos vrais fichiers Compose et de la télémétrie hôte, sans les présenter comme un SLA externe. Lorsque le trafic « atteint parfois la mauvaise instance », joignez au même ticket les configurations rendues des deux piles, les segments réseau issus de docker inspect et des instantanés d'upstream du proxy inverse.
up, exécuter ss -lntp ou l'équivalent et joindre la sortie.json-file épuise souvent inœuds et bande passante avant le CPU ; suivez le rythme d'inspection de l'article baseline.| Symptôme | Champs suspects en priorité | Commandes ou preuves |
|---|---|---|
| Pas de clé API dans le conteneur | Chemin env_file, répertoire de travail Compose | docker compose config et variables via exec côte à côte |
| Healthcheck instable et boucles de redémarrage | start_period, vol CPU « steal » | dmesg hôte, stats cgroup et chronologie des journaux conteneur |
| Requêtes sur la mauvaise instance | Upstream du proxy inverse, conteneurs résiduels | docker ps -a et diff des fichiers upstream avant et après reload |
Attention : écraser un même chemin .env avant d'arrêter la première pile mélange l'ordre de rotation des clés entre les deux piles ; copiez toujours un nouveau fichier avant de changer la référence.
Faire tenir deux piles OpenClaw de niveau production sur un petit VPS manque rarement d'abord sur le disque et les journaux plutôt que sur la CPU brute ; sans répertoires de données distincts et matrice de ports, le diagnostic se réduit à deviner quelle passerelle a répondu. Modifier Compose à la main sans conserver les diffs rendus empêche aussi d'attribuer les mises à niveau (« qui a modifié quelle ligne d'environnement ? »).
Les équipes qui ont besoin d'un hôte stable, d'une bande passante prévisible et de répertoires de travail séparables font souvent tourner OpenClaw sur un Mac cloud commandable ou une offre VPS dédiée pour garder cette checklist applicable. Lorsque essais multi-instance et isolation production doivent tenir dans le même récit opérationnel, la location cloud de Mac Mini VpsMesh est en général le meilleur compromis : rôles découpés par nœud, chemins auditable de bout en bout, et le même jeu de différences Compose peut être revu avec la politique de files.
Suivez le tableau du corps de texte et vérifiez que volumes anonymes, noms de réseau par défaut, ports hôte et env_file ne recouvrent pas encore la première pile ; oublier le nom de projet en ne renommant que le dossier est l'erreur la plus fréquente. Pour le healthcheck et la politique de restart, voir l'article baseline Docker Compose production.
Compose n'a probablement pas chargé le bon env_file, le répertoire de travail diffère, ou les variables ne sont définies que sous build ; suivez les six étapes avec docker compose config et exec. Pour le premier démarrage, voir la section variables de l'article Exit 137.
Exécuter docker compose down sur la pile secondaire, confirmer que les ports sont libres, sauvegarder les deux arborescences de données et ne pas supprimer les volumes avant d'exporter les configurations. Pour les tarifs, l'aide et la commande : page tarifs Mac Mini M4, centre d'aide et page commander.