`main` est rouge sur `Application charts grafana` :
tar: grafana/.helmignore: No such file or directory
tar: Error is not recoverable: exiting now
Process completed with exit code 2
L'étape empaquette par `tar -X ${chart}/.helmignore`, et deux charts sur douze
n'avaient pas ce fichier. Le défaut est ANTÉRIEUR à la correction de la
publication (#42) : `tar` échouait déjà de la même façon. Il ne se voyait pas
parce que l'étape ne tourne que sur `main` et que ces deux charts n'avaient pas
été touchés depuis longtemps — c'est le lot Loki, en modifiant
`grafana/values.yaml`, qui l'a réveillé.
Mesuré, avec le modèle du dépôt copié tel quel :
✓ grafana-0.1.0.tgz 24K
✓ redis-0.1.0.tgz 8.0K
✓ loki-0.1.0.tgz 8.0K (témoin, déjà vert)
⚠ Contre-épreuve faite en retirant le fichier : `tar` refuse bien. Mais j'ai
lu son code de sortie à travers un `| head`, donc j'ai mesuré le code de
`head`, pas celui de `tar` — le vrai code (2) vient du journal de la CI, pas
de mon banc.
Le registre est passé de 2 charts à 5 avec #42 (`alloy`, `chart`, `loki`
publiés pour la première fois) ; ces deux-là devraient le porter à 7.
Co-Authored-By: Claude Opus 5 <[email protected]>
Symptôme observé : `kadans.arcodange.fr` et `gitea.arcodange.fr` en 403, corps
vide, depuis n'importe quel client extérieur — pendant que `arcodange.fr` et
`www` répondaient 200. Ça ressemble à un bannissement d'IP. Ça n'en était pas un.
La chaîne, remontée de bout en bout :
1. Le sous-chart fige ses sondes à `timeoutSeconds: 1` sur `redis-cli ping` et
n'expose aucune valeur pour les surcharger.
2. Sans réservation de ressources, le conteneur est en QoS `BestEffort` : sur un
Raspberry Pi chargé, lancer `redis-cli` dépasse la seconde.
3. « Liveness probe failed: command timed out after 1s » 836 fois en 23 jours,
135 redémarrages, SIGTERM après ~90 s de vie à chaque tour.
4. Le plugin crowdsec de Traefik utilise ce Redis comme cache de décisions.
Cache injoignable ⇒ `isCrowdsecStreamHealthy:false` ⇒ refus par défaut de tout
client absent de `clientTrustedIPs` ⇒ le 403.
D'où le motif trompeur : seuls les hôtes portant le middleware crowdsec
tombaient, et depuis le LAN (IP de confiance) tout paraissait sain — l'origine
répondait 401, son défi d'authentification normal. Trois fausses pistes en sont
sorties : Cloudflare, un bannissement crowdsec, une règle de pare-feu. Aucune
n'était la bonne, et `cscli decisions list` disait `isBanned:false` du début à la
fin.
La réservation fait passer le conteneur en `Burstable` et lui garantit sa part.
Les limites restent larges : Redis n'est pas ce qui sature ce nœud.
⚠ Ce commit ne corrige PAS la sonde elle-même — elle reste à 1 s, et elle reste
inatteignable depuis les valeurs. Si le clignotement revient malgré la
réservation, il faudra un patch Kustomize au niveau de l'Application ArgoCD, ou
abandonner ce sous-chart. Une vérification en production a été appliquée à chaud
(`timeoutSeconds: 5`, `failureThreshold: 6`) pour rétablir l'accès immédiatement,
mais `selfHeal: true` la ré-écrasera : elle n'est pas la correction, ce commit
l'est.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GdUCA5Uz8QyMwa2P4Pg2hK
arcodangeandClaude Opus 5