SyncFailed, HealthDegraded, etc.), un Webhook atteint la passerelle OpenClaw sur un Mac distant, un script exécute un préflight des manifestes sur la révision Git cible, puis un JSON de résumé (extrait d’operationState, codes de préflight, identifiants d’idempotence) est renvoyé vers votre observabilité. La doc officielle onboard, doctor et gateway / doctor décrit les vérifications de santé et de configuration. Pour aller plus loin : sécurisation de la passerelle, échecs et stratégie de retry, matrice registre d’images.
Prérequis
Node : figez Node.js 22 LTS (ou 24) sur le Mac distant ; dans launchd, fixez explicitement NODE_BINARY et, si vous traversez un proxy TLS d’entreprise, NODE_EXTRA_CA_CERTS. Installez OpenClaw selon la doc, puis exécutez openclaw doctor — doctor contrôle l’état de la passerelle, les collisions de ports, et propose des corrections (openclaw doctor --repair ou --non-interactive selon votre politique). Enchaînez avec openclaw onboard --install-daemon lorsque votre version le propose, afin que la passerelle ne dépende pas d’une session utilisateur.
Jetons : séparez au minimum trois secrets — (1) un jeton ou segment d’URL pour authentifier le Webhook vers OpenClaw (Bearer, HMAC ou chemin aléatoire), (2) un compte Argo CD avec droits application en lecture (token API ou session argocd login persistée hors dépôt Git), (3) un jeton pour le POST de callback vers votre SIEM ou file d’incidents. Ne réutilisez pas le jeton Argo comme Bearer pour le webhook.
Sortie réseau (egress) : liste blanche explicite vers l’hôte Argo CD (API REST + éventuellement grpc-web), le dépôt Git (HTTPS/SSH), les registres d’images référencés par les manifests si vous validez des digests avec crane, et l’URL de résumé. Refusez par défaut toute autre destination pour limiter le SSRF si un corps de notification était forgé. Pour un panorama des flux d’images, voir la matrice GHCR déjà publiée.
Argo CD reste la source de vérité opérationnelle (status.operationState, santé, révision déployée). Le Mac distant rejoue la même révision Git dans un répertoire jetable et exécute kustomize build / helm template + kubeconform : vous détectez les YAML invalides ou les schémas incompatibles avant de surcharger le bruit des alertes, tout en gardant une trace corrélée avec l’événement Argo.
Webhook et passerelle : liste d’étapes
Enchaînement recommandé (copiable dans un runbook interne) :
- Terminaison TLS : Caddy ou nginx en frontal ;
proxy_passvers127.0.0.1:PORTuniquement ; conserverAuthorization,X-Request-Idet tout en-tête de signature attendu par votre handler. - Chemin stable : par ex.
/hooks/argocd/<secret_path>— le segment secret compense l’absence de HMAC si vous n’utilisez pas encore de signature sur le corps. - argocd-notifications : modèle de template filtrant sur
sync.status/health.status; corps JSON incluant le nom d’Applicationet un identifiant de notification pour l’idempotence. - Réponse rapide : renvoyez 202 Accepted si le préflight + appels API peuvent dépasser le délai du client HTTP (sinon le contrôleur peut réessayer trop tôt). Traitez le travail lourd dans une tâche asynchrone côté OpenClaw.
- Enrichissement : après validation du secret, parsez le JSON puis appuyez-vous sur l’API Argo pour lire la révision et la phase exactes.
Variante équivalente en REST : curl -H "Authorization: Bearer $ARGOCD_AUTH_TOKEN" "https://$ARGOCD_SERVER/api/v1/applications/$APP_NAME" — ajoutez --grpc-web côté CLI si votre déploiement l’exige (voir FAQ).
| Signal | Côté Argo CD | Action minimale sur le Mac |
|---|---|---|
| SyncFailed | operationState.phase / messages | Checkout revision ciblée + préflight + résumer l’extrait d’erreur |
| HealthDegraded | ressources et états | Préflight + optionnellement comparaison courte avec le manifeste rendu |
| Bruit de retry | réconciliations répétées | Clé d’idempotence = app + révision + uid notification |
Script de préflight et sondes de santé
Dans un répertoire temporaire, clonez la révision exacte signalée par Argo (ou le commit SHA) puis exécutez les outils de rendu. Si kubeconform se plaint de CRDs inconnues, passez des schémas additionnels (-schema-location pointant vers vos CRD OpenAPI ou un bundle interne) : le but n’est pas de valider la politique métier complète, mais d’éliminer les erreurs de syntaxe et les références d’images manifestement invalides avant qu’elles ne polluent votre canal d’astreinte. Lorsque le préflight échoue, joignez au JSON le dernier message d’operationState côté Argo : les deux lectures doivent converger (même révision, même cause probable) ; si elles divergent, suspectez un décalage de branche ou un cache Git intermédiaire.
La commande suivante illustre un flux kustomize + kubeconform ; adaptez le chemin d’overlay à votre dépôt.
Pour Helm : helm template rel "$CHART_DIR" -f values.yaml | kubeconform -strict. Si vos manifests référencent des images privées, alignez votre authentification crane avec la même politique que le cluster (voir matrice registre).
POST de résumé : assemblez un JSON compact (nom d’application, révision, phase, extrait de message, codes de sortie kubeconform, durée) et postez-le vers votre endpoint d’observabilité. Utilisez un backoff 2 s → 4 s → 8 s sur au plus trois tentatives ; incluez une clé d’idempotence pour éviter les doublons.
--connect-timeout 3et--max-time 10pour/health: détecter vite un port mort ou un certificat client refusé.--max-time 25sur le POST de résumé : reste inférieur à la fenêtre acceptable du webhook si vous faites synchrone ; sinon passez en 202 + file asynchrone.- Timeouts nginx
proxy_read_timeout: augmentez siargocd app getsur de gros arbres dépasse 60 s.
FAQ — échec d’authentification, timeout, retry
401 ou 403 sur la passerelle alors que le secret est « correct »
Vérifiez la casse et les retours à la ligne dans le fichier de secret ; assurez-vous que le proxy ne supprime pas Authorization ; comparez avec une comparaison à temps constant côté handler. Testez avec curl -v en local (127.0.0.1) avant de passer par TLS public.
argocd ou curl vers l’API se bloque alors que l’UI web répond
Alignez ARGOCD_SERVER avec l’hôte réellement utilisé par l’UI ; activez le mode grpc-web si votre cluster l’impose ; contrôlez HTTPS_PROXY ; augmentez les timeouts du reverse proxy ; pour le diagnostic, préférez curl --max-time explicite.
Alertes dupliquées après retry
Ne bouclez pas indéfiniment : trois tentatives avec 2/4/8 s suffisent en général. Stockez une clé d’idempotence (application + révision + uid de notification) et arrêtez si le récepteur renvoie conflit ou doublon.
Synthèse et orientation achat
En bref : verrouillez Node et openclaw doctor, exposez la passerelle derrière TLS sans casser les en-têtes, reliez argocd-notifications à un handler qui vérifie puis enrichit via l’API Argo CD, exécutez le préflight manifestes sur la révision Git signalée, et renvoyez un JSON borné avec retry raisonnable. Pour un Mac distant toujours joignable et une sortie réseau prévisible, les pages achat, tarifs, aide, accueil et le blog technique MacPull sont consultables sans connexion.
Louez un Mac cloud comme nœud GitOps / OpenClaw
Pages ouvertes sans login : accueil, centre d’aide, achat, tarifs, blog technique (série OpenClaw 2026).