Les équipes qui souhaitent isoler les conteneurs pour OpenClaw Gateway, mais qui redoutent les chemins d'édition manuelle les nuits de mise à niveau, font généralement un compromis entre Compose, les volumes nommés et les résumés d'images. Cet article présente un chemin de production Docker reproductible, avec une séparation claire du guide sur site Ubuntu 24.04 + systemd + Tunnel bare metal : lignes de base, forme docker-compose.yml, volumes persistants, mises à niveau d'images et vérifications de l'état, ainsi qu'un tableau des symptômes des pannes courantes de conteneurs.
Le chemin nu minimise l'abstraction : processus sur l'hôte, systemd pour les redémarrages, tunnel pour l'entrée publique. Le chemin Docker permute l'artefact de « répertoires + fichiers d'unité » vers « images + Compose » : les mises à niveau consistent principalement à extraire un nouveau résumé, à recréer des conteneurs et à vérifier que les montages sont toujours alignés. Les deux peuvent maintenir Gateway en bouclage avec TLS en périphérie ; la question est de savoir si vous acceptez la chaîne d’approvisionnement d’images et la gouvernance des volumes en échange d’une reproductibilité et de restaurations plus fines.
Si vous standardisez déjà les registres, l’analyse et les SBOM, Compose est souvent la forme de production la plus simple. Un seul VPS à faible taux de désabonnement peut encore être moins cher sur papier avec systemd seul. Les six points faibles ci-dessous proviennent de véritables fils de tri : ils vous indiquent si vous êtes prêt pour les conteneurs.
Traiterlatestcomme versionnement :épingler le résumé ou les balises de construction immuables en production ; sinon, « ça a fonctionné la nuit dernière » ne correspond à aucune couche du système de fichiers.
Intégration de la configuration en images :utilisez des montages env, secrets ou en lecture seule ; sinon, chaque rotation de jeton force une reconstruction et annule la livraison du conteneur.
Volumes anonymes remplissant les disques :les volumes de cache sans nom issus des expériences consomment silencieusement/var/lib/docker; préférez les volumes nommés ou le stockage d’objets externes.
Contrôles de santé qui renvoient toujours 200 :tester uniquement le port HTTP sans préparation du modèle/configuration provoque des 502 en masse après les changements de trafic.
Configurations de composition et de tunnel divergentes :l'entrée pointant toujours vers un ancien port publié rend les symptômes externes sans rapport avec les journaux du conteneur.
Forcer les charges de travail macOS dans des conteneurs Linux :comme pour l'article sur le matériel nu : les tâches Xcode/simulateur appartiennent aux exécuteurs Mac distants, et non au « bac à sable magique » Linux.
Si vous pouvez répondre « d'où viennent les images, quels volumes stockent, à qui appartiennent les mises à niveau », passez aux références et aux modèles. Sinon, rédigez une page d’une page en mise en scène avant de toucher à la production.
Lors de l'exécution des deux chemins, partagez un contrat de topologie d'écoute + tunnel : mappez les conteneurs sur 127.0.0.1 sur le bouclage de l'hôte et terminez TLS sur cloudflared ou équivalent. La migration de systemd → Compose échange ensuite uniquement le superviseur de processus, pas la limite de sécurité.
Si vous gérez à la fois des scripts d'installation et un dépôt de composition, déclarez une seule source de vérité : soit la composition est canonique et CI restitue des extraits de code système pour les cas rares sans système d'exploitation, soit l'inverse. La dérive à double piste apparaît généralement lorsque les ports, les noms de volumes et les chemins d'environnement sont modifiés d'un seul côté.
Les conteneurs facilitent l'enfer des dépendances mais ne suppriment pas les besoins de rotation secrète ou d'audit. Traiter env_file comme un coffre-fort sans autorisations ni rotation équivaut moralement à valider des jetons, juste avec une date d'incident retardée.
Examinez les « minutes d'installation » à côté du « coût par mise à niveau trimestrielle » : les conteneurs coûtent plus cher au départ, mais se répètent mieux. Remplacez les noms/ports d'espace réservé par vos valeurs réelles.
| Dimension | Passerelle sur IP publique | systemd + bouclage + Tunnel (bare metal) | Production Docker Compose |
|---|---|---|---|
| Unité de livraison | Répertoires/scripts roulés à la main | Unité + fichiers de configuration | Résumé d'image + fichier de composition |
| Chemin de mise à niveau | Dérive élevée | Remplacez binaire/config, lancez systemctl | Extraire l'image, recréer des conteneurs, vérifier les volumes |
| Isolement | Faible | Moyen (utilisateurs/autorisations) | Plus puissant (espaces de noms/groupes de contrôle, pas de VM complètes) |
| Observabilité | BRICOLAGE | journald est clair | Unifiez les journaux Docker ou les agents side-car |
| Coût typique | Risque de sécurité le plus élevé | Script modéré | Chaîne d'approvisionnement d'images + opérations de volume |
Compose déclare l'exécution + la persistance + les bords de dépendance ; si vous refusez de nommer les volumes et les balises, vous ne faites que reporter le chaos jusqu'à ce que l'alerte disque se déclenche.
Sur Ubuntu 24.04 LTS ou similaire, installez Docker Engine pris en charge et le plugin Compose v2 ( docker compose ), en évitant l'ancien binaire docker-compose autonome qui diverge de CI de prod. Budget RAM au-delà de la passerelle pour les journaux, le déballage temporaire et les connexions simultanées ; regardez la croissance de /var/lib/docker séparément.
La sécurité correspond à l'article sur le matériel nu : pas d'écouteurs publics pour les ports d'application, clés SSH uniquement, pare-feu de refus par défaut. Les conteneurs ajoutent des espaces de noms : ils n'implémentent pas comme par magie TLS ou une politique d'accès.
Versions de broches :capturerdocker versionetdocker compose versiondans le runbook ; aligner les mineurs de mise en scène/prod.
Draveur + rotation :avec l'ensemble de fichiers json par défautmax-size/max-filedonc un conteneur bavard ne peut pas remplir le disque.
Réseau dédié :déclarez un pont personnalisé dans compose afin que seuls la passerelle et le side-car du tunnel parlent par défaut.
Discipline du registre :registre des documents, nom de l'image, résumé ; Les extractions de production doivent utiliser le même registre que celui que vous avez testé : évitez docker.io en développement et le registre privé en production sans suivi.
Stratégie de volume/liaison :Montages de configuration en lecture seule, volumes inscriptibles uniquement pour l'exécution/le cache, secrets sous forme de fichiers mode 400 ou secrets Docker.
Répétez vers le bas/vers le haut :en phase de préparationdocker compose downalorsup -d; confirmez que les volumes survivent et que le tunnel en amont cible toujours le bon port de bouclage.
Note:les vrais noms d'images OpenClaw, les clés d'environnement et les indicateurs CLI suivent la documentation en amont – le YAML ci-dessous est illustratif ; remplacez les espaces réservés et supprimez les clés inutilisées avant la production.
Publiez avec 127.0.0.1:host:container pour que le bouclage de l'hôte alimente le tunnel (même contrat que « lier le bouclage uniquement » dans le guide bare metal). Les contrôles de santé doivent prouver la disponibilité HTTP ; si l'amont envoie une commande config validate, élargissez start_period afin que les nouveaux conteneurs ne soient pas tués au milieu du démarrage.
services:
openclaw-gateway:
image: ghcr.io/example/openclaw-gateway@sha256:<DIGEST>
restart: unless-stopped
env_file:
- ./gateway.env
volumes:
- openclaw_data:/var/lib/openclaw
- ./gateway.yaml:/etc/openclaw/gateway.yaml:ro
ports:
- "127.0.0.1:8787:8787"
healthcheck:
test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8787/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 40s
volumes:
openclaw_data:
Ordre de mise à niveau : ① docker compose pull in staging pour vérifier le résumé ; ② sauvegardez les données du volume nommé ou exportez la configuration ; ③ prod docker compose -d --no-deps --build (drop --build s'il n'est pas utilisé) et surveille l'état de santé ; ④ boucle depuis l'hôte et à travers le tunnel ; ⑤ alors seulement, envisagez l'élagage de l'image Docker (dangereux si vous avez encore besoin de couches de restauration).
Pile de tri : journaux de conteneur pour la configuration/autorisations ; hôte ss -tlnp pour la liaison de bouclage ; entrée du tunnel pour le port droit. Si Internet voit 502 mais que curl 127.0.0.1 fonctionne, suspectez le routage, pas l'image en premier.
Pour le bleu/vert, exécutez brièvement deux projets de composition (noms de projet et ports de bouclage différents) et déplacez les poids au niveau du tunnel ou du LB interne ; puis docker compose -p old_project down ou les anciens conteneurs conservent les verrous de volume et le travail en arrière-plan.
Si la passerelle doit atteindre un socket Unix hôte ou un side-car de modèle local, examinez network_mode: host - il contourne une partie de l'isolation de la carte de port et doit faire l'objet d'un changement examiné par deux personnes.
Avertissement:ne jamais s'engagergateway.envavec des clés API ; CI ne doit pas imprimer le rendu compose env. Un UID/GID de volume erroné apparaît souvent sous la forme de contrôles de santé irréguliers plutôt que de plantages instantanés.
Utilisez-les pour vous aligner sur la plateforme sur « les conteneurs ne sont pas un repas gratuit » ; remplacez-les par vos métriques P95 et vos courbes de disque.
Alerte sur le nombre de redémarrages, la durée anormale et l'utilisation du volume, et pas uniquement sur le processeur. Les services de type passerelle n'avalanchent souvent qu'après l'épuisement des descripteurs de disque ou de fichier.
/var/lib/docker; pair alerts with volume backup policy.start_period is a common starting point.Les conteneurs Linux s'adaptent aux passerelles, aux files d'attente et à l'orchestration légère d'OpenClaw, mais Xcode, les simulateurs et les fonctionnalités d'Apple Silicon se heurtent à des obstacles : payez éternellement pour les cales de compatibilité ou déplacez l'exécution vers des Mac dédiés. Par rapport aux passerelles exécutées sur des ordinateurs portables ou des hôtes « temporaires » où la veille, les mises à jour et les invites interrompent l'automatisation, les Mac distants dédiés sous contrat alignent les charges de travail Apple de longue durée tandis que Linux conserve Docker ou systemd pour le plan de contrôle : les domaines de défaillance restent propres. Pour les agents stables et les pipelines de construction, la location de Mac Mini dans le cloud NodeMini est généralement la meilleure réponse : conservez la passerelle dans un conteneur VPS et envoyez le travail lourd aux nœuds d'exécution commandables au lieu de corriger la mauvaise couche.
Oui : réparti par environnement (staging Compose, prod systemd) ou par service. Partagez le contrat Listen+Tunnel afin que deux passerelles ne se battent jamais pour le même port de bouclage. Plus de messages OpenClaw :filtre de catégorie.
Vérifierdocker logset si la commande de santé correspond toujours aux nouveaux chemins d'image ; vérifier les autorisations de volume et l'environnement. Pour plus de calcul, consultezprix de locationpour les nœuds Mac distants.
Rechercher lecentre d'aidepour SSH/VNC et réseau. Pour la mise en réseau de conteneurs, vérifiez également les règles de pare-feu de l'hôte etdocker network.