2026 · OpenClaw sur cluster
Passerelles multi-AZ, sondes fusionnées & webhooks

Pourquoi la passerelle monolithique résiste au multi-AZ

Ce pas-à-pas (HowTo) part d’au moins trois Mac dédiés chez clustervps : deux passerelles régionales et un worker ou un nœud « notificateur ». Lorsque chaque chemin d’automatisation pointe vers le même hôte, vous héritez de pannes corrélées, d’astreinte bruyante et de rotations de secrets difficiles à répéter en drill. Les équipes qui mutualisent déjà des artefacts entre nœuds gagneront à aligner la couche réseau : voir aussi notre guide matrice rsync multi-Mac pour synchroniser builds et files d’attente sans contredire vos budgets latence.

• Rafales webhook : les fournisseurs rejouent en parallèle et la passerelle lâche le TLS avant qu’OpenClaw ne vide sa file.
• Dérive des sondes : chaque équilibreur invente son propre script curl, la moitié du parc paraît saine alors que les agents n’atteignent plus les API amont.
• Secrets couplés : un bearer longue durée partagé transforme toute rotation en week-end plutôt qu’en exercice de quinze minutes.

Matrice rapide : une passerelle ou plusieurs ?

Croisez cette matrice avec les forfaits Mac et paliers SSD : chaque AZ doit disposer d’une marge RAM/disque prévisible pour absorber les pics de retry. Ce n’est pas de la redondance décorative, c’est la capacité de vider un nœud pendant que vos collègues poursuivent leurs flux publics depuis l’accueil clustervps, sans friction d’authentification pour consulter les pages marketing.

HowTo : découper les passerelles clustervps par zone de disponibilité

1. Geler le périmètre. Inventoriez chaque hostname entrant, profil mTLS et IP statique qu’OpenClaw termine aujourd’hui. Rien ne bouge tant que l’inventaire n’est pas aligné avec le DNS.
2. Cloner la configuration, pas l’état. Copiez launchd, variables d’environnement et certificats vers le second Mac, mais laissez files SQLite ou files d’attente locales vides jusqu’au basculement.
3. Déplacer les pondérations DNS. Commencez par 10 % du trafic sur la nouvelle passerelle, surveillez les budgets d’erreur pendant trente minutes, puis montez par paliers de 20 %.
4. Documenter les interrupteurs de vidange. Chaque opérateur doit connaître la commande unique qui marque une passerelle en lecture seule sans arrêter les workers.
5. Chaos apparié. Coupez un service passerelle en heures ouvrées pendant que l’autre retient la file webhook : aucune surprise le jour J.

Gardez des chemins bastion SSH identiques entre nœuds pour que les captures d’écran de la base d’aide restent honnêtes. Pour ajouter un siège bare metal, le tunnel achat reste accessible sans imposer d’abord une connexion console.

HowTo : fusionner les sondes de santé en un signal unique

Chaque équilibreur doit interroger une seule route composite par passerelle. Dans le gestionnaire, enchaînez des contrôles légers : pression disque, battements de cœur launchd, TLS sortant vers le partenaire webhook, expiration des certificats. Répondez en JSON avec des booléens séparés afin qu’on voie quel sous-système a cassé sans ouvrir cinq onglets. Les nœuds voisins peuvent réutiliser la même URL pour des tests croisés pendant une maintenance planifiée.

#!/usr/bin/env bash
set -euo pipefail
/usr/bin/curl -fsS --max-time 4 https://hooks.partner.test/ping >/dev/null
/usr/sbin/diskutil apfs list | /usr/bin/grep -q "Container"
/usr/bin/printf '{"disk":true,"webhook":true,"queue_depth":0}\n'

Publiez le même chemin de sonde sur chaque passerelle afin que l’automatisation des autres Mac puisse curl ses pairs. Lorsqu’une sonde échoue, ajoutez l’étiquette AZ dans la charge utile pour que les planificateurs OpenClaw aval migrent les sessions sans ambiguïté.

HowTo : diffuser des synthèses d’échecs webhook, pas du bruit

Désignez un nœud notificateur dont le seul rôle est d’agréger les incidents. Les passerelles émettent des événements structurés vers Redis local ou une file journalisée ; le notificateur regroupe des fenêtres de cinq minutes, déduplique les codes HTTP, puis pousse un seul résumé Slack ou e-mail. Les collaborateurs sur d’autres Mac workers s’abonnent à ce canal digest plutôt qu’aux logs bruts. Cette séparation des responsabilités rappelle le fan-out d’artefacts : moins de messages concurrents, plus de signal exploitable pour l’astreinte.

• Métadonnées d’enveloppe : identifiants de corrélation, AZ, compteur de tentatives pour rejouer exactement une livraison ratée.
• Contre-pression : si la publication du digest échoue, basculez sur un compteur persistant disque façon « messagerie vocale » pour éviter toute perte silencieuse.
• Langage humain : des phrases courtes type tableau d’embarquement, sans pile d’appels tant que la gravité n’est pas critique.

HowTo : faire tourner les jetons avec validation progressive

Émettez des identifiants fantômes dans votre coffre-fort, injectez-les à côté des jetons historiques sur une passerelle canari, puis validez les webhooks sortants pendant une journée ouvrée complète. Promouvez le secret fantôme sur toutes les passerelles via une étiquette de révision de configuration, et révoquez l’ancien jeton seulement lorsque les métriques de succès restent plates pendant deux intervalles de scrutation.

Les workers qui appellent la passerelle doivent lire les secrets depuis un fichier éphémère mis à jour de façon atomique par renommage, ce qui évite les demi-écritures pendant la rotation. Journalisez chaque événement avec acteur et numéro de ticket pour simplifier les revues sécurité.

Programmez un rappel calendaire tous les quatre-vingt-dix jours, mais raccourcissez l’intervalle lorsque les webhooks traversent l’Internet public ou lorsqu’un fournisseur annonce un incident multi-locataire. Associez ces rappels à une feuille légère indiquant quel Mac a validé la dernière rotation avec succès : personne ne doit supposer qu’un renouvellement silencieux a réussi.

Enfin, reliez la discipline des secrets à la capacité : si vous doublez le nombre de passerelles, vérifiez que chaque AZ conserve au moins 20 % de marge disque après les files de replay, faute de quoi les rotations déclencheront des faux positifs sur la sonde fusionnée.

Liste de contrôle : collaboration multi-nœuds

• Parité des runbooks : mêmes noms d’unités launchd (ou systemd) sur chaque passerelle.
• Synchronisation temporelle : dérive sntp inférieure à deux secondes sur tous les Mac.
• File de replay webhook : taille bornée sur disque avec alertes hautes-eaux explicites.
• SLO sonde : endpoint composite sous deux cents millisecondes en p95.
• Latence digest : les synthèses d’échec arrivent avant les escalades managériales.
• Chevauchement des jetons : au moins douze heures où ancien et nouveau secret fonctionnent ensemble.
• SSH opérateur : chemins bastion documentés à côté des articles d’aide.
• Revue capacité : revue trimestrielle des forfaits après croissance du trafic.

FAQ : garder OpenClaw « ennuyeux » sur clustervps

Faut-il des certificats TLS distincts par AZ ? Oui, terminez localement pour garder les chemins régionaux courts, mais automatisez l’émission depuis le même profil AC pour que les playbooks de renouvellement restent identiques.

Et si la sonde fusionnée masque une panne partielle ? Exposez un mode dégradé : HTTP 200 avec "status":"degraded" pour jaunir les tableaux de bord tout en laissant passer le trafic.

Les juniors peuvent-ils répéter une rotation ? Oui : jetons fantôme + passerelles canari rendent l’exercice sûr, chaque participant rejoue sans toucher aux files de production.