Automatisation IA 8 mai 2026

Déploiement blue-green du gateway OpenClaw avec second port, bascule pilotée par la santé et launchd sur Mac cloud loué (2026-05-08)

Équipe automatisation IA MacLogin 8 mai 2026 ~23 min de lecture

En 2026, l’histoire gateway OpenClaw sur macOS est partagée : l’app desktop orchestre le cycle de vie, tandis que le démon long-cours reste sous launchd avec des installs CLI externes. Cette séparation favorise le blue-green : vous pouvez démarrer un gateway candidat sur 127.0.0.1:18765 pendant que la prod reste sur 127.0.0.1:18764, prouver la préparation avec des sondes synthétiques, puis repointer les consommateurs loopback ou proxys amont — sans second mini MacLogin physique. Ce runbook de mai 2026 encode la matrice que les locataires MacLogin à Hong Kong, au Japon, en Corée, à Singapour et aux États-Unis utilisent pour stabiliser workers webhook, hooks Canvas et automations CLI pendant les mises à jour.

Lecture croisée : app + handoff CLI, monitoring health curl, arrêt gracieux et vidage, et le hub index thématique OpenClaw. Ancres : aide et tarifs.

Pourquoi le blue-green bat les redémarrages sur place pour les gateways chargés

Un launchctl kickstart -k sur place convient aux petits patchs, mais les mises à jour risquées (montées majeures Node, changements de liste de modèles, migrations d’URL webhook) profitent de processus côte à côte. Le blue-green offre un conteneur chaud complet : contextes TLS compilés, caches modèle amorcés et files worker validées avant tout trafic client.

Réalité : deux couleurs sur un hôte partagent CPU, disque et thermique — si le candidat fait grimper l’usage ANE, planifiez les bascules hors pointe même sur Mac mini M4.

Plan de ports et matrice des labels launchd

CouleurAdresse d’écouteLabel launchd (exemple)Rôle
Bleu (stable)127.0.0.1:18764ai.openclaw.gateway.blueTrafic production
Vert (candidat)127.0.0.1:18765ai.openclaw.gateway.greenValidation préprod
ObservabilitéL’un ou l’autreN/ALier la santé au loopback ; n’exposez publiquement que via proxys contrôlés selon durcissement localhost

Contrat de sonde santé avant de basculer le trafic

Définissez des signaux non négociables : HTTP 200 sur /healthz (ou équivalent projet), champ version JSON aligné avec la CLI, ping modèle sous latence budgétée, et écho self-test webhook le cas échéant. Exécutez les sondes pendant au moins deux intervalles de scrape pour attraper les fuites lentes.

Astuce : reflétez la boucle synthétique de l’article monitoring d’hier — port différent, même discipline — pour que l’astreinte réutilise ses réflexes.

Motif LaunchAgent plist secondaire (par utilisateur)

Dupliquez le plist fonctionnel, changez Label, StandardOutPath, StandardErrorPath et les exports d’environnement qui fixent port + racine de config. Gardez un ThrottleInterval raisonnable pour éviter que les boucles de crash ne saturent syslog. Alignez-vous sur les variables d’environnement launchd pour que les deux couleurs héritent du bon coffre secrets.

Runbook de bascule en neuf étapes

  1. Capturer plist actuel, hash binaire et version Node.
  2. Déployer les bits candidats dans un répertoire versionné ; n’écrasez pas les chemins stables.
  3. Installer le plist vert ; launchctl bootstrap en tant qu’utilisateur locataire.
  4. Vérifier les endpoints santé en local avec curl + mTLS si activé.
  5. Rejouer des payloads webhook synthétiques uniquement contre le vert.
  6. Vider le bleu selon la séquence de l’article drain d’avril 2026.
  7. Promouvoir en repointant forwards localhost ou blocs amont du proxy.
  8. Observer les budgets d’erreur pendant 30–60 minutes avant victoire déclarée.
  9. Rétrograder les binaires bleus ou les garder chauds comme rollback instantané.

Exercices de rollback terminés en moins de cinq minutes

Entraînez-vous à inverser la promotion : restaurer le pointeur amont vers le bleu, launchctl bootout du vert seulement après vidage des files, et laisser les logs défiler jusqu’à cessation des rafales 5xx côté fournisseurs webhook. Documentez qui possède DNS vs loopback vs couches reverse-proxy — la confusion là prolonge les incidents au-delà des SLA.

Observabilité : différer les flux JSONL entre couleurs

Lorsque les deux démons émettent des lignes JSON, étiquetez chaque enregistrement avec color=blue|green au niveau logger. Les équipes SIEM sur fuseaux HK, JP, KR, SG et US peuvent alors superposer les taux d’erreur sans deviner quel processus bruyait.

FAQ

Remplace-t-ceci Kubernetes ? Non — les locations mono-hôte utilisent des motifs plus simples ; les tenants K8s doivent faire du blue-green au niveau pod.

Et les webhooks TLS publics ? Associez ce motif au guide proxy inverse TLS pour que le bord bascule l’amont vers le loopback sain.

Où louer des gateways plus isolés ? Commencez par les tarifs pour ajouter de la capacité JP ou US aux charges bruyantes.

Hub OpenClaw, aide et importance des régions

Tenez le hub OpenClaw à jour avec vos labels internes pour que les nouveaux ingénieurs héritent de la même matrice de ports. Quand les automations sensibles à la latence sont plus proches des courtiers Tokyo que de la côte ouest US, épingler les locations par région réduit le risque de bascule car les RTT webhook restent prévisibles.

Livrer OpenClaw sur Apple Silicon dédié

Nœuds HK · JP · KR · SG · US pour gateways toujours actifs.