arcodangeandClaude Opus 5 4e954a6890
Helm Charts / Detect changed charts (pull_request) Successful in 20s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts alloy (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts loki (pull_request) Successful in 45s
Les sondes de Loki cessent d'exiger une réponse en une seconde d'un Raspberry Pi
Mesuré le 2026-09-07, quelques heures après le premier déploiement : 30 échecs
de la sonde de disponibilité en 25 minutes, tous en `context deadline
exceeded` — pendant que Loki tournait parfaitement. Il finissait de rejouer
son WAL (`checkpoint done time=4m23s`). Le défaut amont est
`timeoutSeconds: 1`, raisonnable sur une machine rapide et intenable ici.

La conséquence n'était pas cosmétique : sans sonde verte, aucun endpoint
derrière le service, donc la source de données Grafana inutilisable — un
magasin de journaux vivant mais injoignable.

Le remède n'assouplit PAS la disponibilité. Il sépare deux questions que le
défaut amont confondait : « Loki a-t-il fini de DÉMARRER ? » (`startupProbe`,
jusqu'à 10 min, c'est le rejeu du WAL qu'on attend) et « répond-il MAL ? »
(`readinessProbe`, stricte, qui ne prend le relais qu'ensuite).

⚠ `initialDelaySeconds: 0` est ÉCRIT, pas omis : le chart FUSIONNE cette table
avec la sienne au lieu de la remplacer. Un premier jet l'omettait, et
`helm template` rendait encore le `15` amont. Le rendu l'a dit, pas moi.

Éprouvé par rendu local, `helm template`, les deux côtés :

  livré              startup={failureThreshold 60, timeout 5s}
                     readiness={timeout 5s, initialDelay 0}     ← conforme
  startupProbe ôté   startup=(aucune)                           ← le sabotage mord

⚠ Le sabotage a mordu, mais ma vérification qu'il était APPLIQUÉ a imprimé un
« False » trompeur (elle cherchait le mot dans un bloc de commentaires qui le
contient). C'est le RENDU qui fait foi, pas ma sonde.

⚠ Ce que ça ne prouve pas : le comportement sous charge réelle. Il faudra
constater que le pod passe `Ready` du premier coup au prochain redémarrage.

Traite un des trois restes de #44.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-08 01:51:37 +02:00
2026-01-03 19:17:04 +01:00
2025-08-27 18:54:16 +02:00
2025-12-09 12:14:57 +01:00

Tools

CICD:
pousser la library helm dans le registre helm de gitea

pour chaque dossier de premier niveau contenant un fichier Chart.yaml (sauf les dossier library et chart)
le pousser dans le registre helm de gitea

Réseau

  • Ce que Traefik voit du client — pourquoi ClientIP() ne voit que le tunnel sur les hôtes .fr, pourquoi localIp@file n'a rien à y faire, et comment obtenir « pas de mot de passe depuis la maison » sans créer un contournement d'authentification.

pgbouncer

prometheus

hashicorp vault

experiment with sops

S
Description
No description provided
Readme
672 KiB
Languages
HCL 56.5%
Python 43.5%