🐛 [BUG] - Healthcheck keycloak CI sur le mauvais port (8080 au lieu de 9000)

[shikanime]

Description

Le healthcheck du conteneur keycloak dans docker/docker-compose.ci.yml interroge la mauvaise URL : http://localhost:8080/health/ready alors que Keycloak 26 expose l'interface de management (health) sur le port 9000. Le endpoint renvoie 404, le conteneur passe en unhealthy après 10 essais et tous les services dépendants (condition: service_healthy) ne démarrent pas — les 4 shards Playwright échouent systématiquement dans la merge queue.

Régression introduite par la montée à bitnamilegacy/keycloak:26.1.3-debian-12-r0 (commit 0fa7af440e, 2025-09-18) : Keycloak 26 a déplacé l'interface de management sur le port 9000.

Etapes de reproduction

1. Lancer docker compose -f docker/docker-compose.ci.yml up keycloak
2. Observer les healthchecks : curl: (22) ... 404 Not Found
3. Après ~50s : dependency failed to start: container dso-console_keycloak is unhealthy

Captures d'écran

Logs

dso-console_keycloak  | Management interface listening on http://0.0.0.0:9000.
{"Health":{"Status":"unhealthy","FailingStreak":10,"Log":[{"ExitCode":22,"Output":"curl: (22) The requested URL returned error: 404"}]}}

Exemple de run : https://github.com/cloud-pi-native/console/actions/runs/32480198543/job/96765556853

Navigateurs

OS

CI (ubuntu-latest)

Version de la console impactée

main depuis v9.x (régression latente depuis 2025-09-18)

Définition du fini

• Le healthcheck interroge http://localhost:9000/health/ready et le conteneur devient healthy
• Les shards Playwright passent dans la merge queue

References

• Keycloak 26 : interface de management déplacée sur le port 9000 (https://www.keycloak.org/docs/latest/upgrading/#_management_interface_changes)
• Commit régression : 0fa7af4

[shikanime]

Analyse de cause racine

• docker/docker-compose.ci.yml:19 : test: [CMD, curl, --head, fsS, "http://localhost:8080/health/ready"] — deux défauts :
  1. Port 8080 au lieu de 9000 (Keycloak 26 a déplacé l'interface management/health sur le port 9000 ; visible dans les logs du conteneur : Management interface listening on http://0.0.0.0:9000).
  2. fsS sans tirets — interprété comme une seconde URL nommée « fsS ».
• Régression introduite par 0fa7af440e (2025-09-18, montée vers keycloak 26.1.3) ; latente jusqu'à la merge queue du 2026-08-21.
• Correctif proposé : test: [CMD, curl, -fsS, "http://localhost:9000/health/ready"].
• Remarque annexe : l'image bitnamilegacy/keycloak est un miroir legacy Bitnami à durée de vie limitée — migration à prévoir séparément.

Correctif en cours sur #2542 (fix/playwright-keycloak-flake).

[shikanime]

Synthèse — pourquoi ça n'a jamais cassé avant

Le healthcheck de keycloak dans docker-compose.ci.yml n'a jamais fonctionné depuis sa création :

1. 2025-07-31 (843d081209) : healthcheck créé sur http://localhost:8080/health/ready avec la typo fsS (au lieu de -fsS). Sans -f, curl sort 0 même sur 404 → le check passe instantanément, quoi qu'il arrive.
2. 2025-09-18 (0fa7af440e) : montée Keycloak 23 → 26.1.3. Keycloak 26 déplace l'interface health sur le port 9000. Le check devient un 404 garanti… mais reste aveugle (pas de -f) → toujours « healthy ».
3. Conséquence cachée : depends_on: service_healthy libère les conteneurs dépendants ~5 s après le démarrage, alors que la JVM + import du realm prennent 15-20 s. Le serveur démarre avant son IdP → c'est la source réelle du flake intermittent Playwright.
4. 2026-08-21 (PR fix(ci): dump docker compose state on failure and fix keycloak healthcheck #2542) : correction de la typo fsS → -fsS. Le check devient réel… mais vise toujours le 404 → échec déterministe des 4 shards en merge queue.

En résumé : typo = check aveugle (flake par course) ; typo corrigée = check voyant mais mauvais port (échec dur). Le correctif complet est une ligne : viser http://localhost:9000/health/ready. Le throttle max-parallel: 2 de #2542 traite le symptôme ; le port corrige la course à la racine.