Mode debug (Digdash BI)

Le modèle Digdash BI propose un mode debug réservé à l'équipe DigDash, pour investiguer un problème qui ne peut pas l'être autrement : il ouvre un agent de débogage Java distant (JDWP) sur le conteneur principal et expose le port de l'annuaire LDAP interne (sidecar OpenDJ). Les deux restent uniquement accessibles depuis le cluster (Service ClusterIP) tant qu'aucune règle d'exposition externe n'est créée — voir Se connecter plus bas.

Activer

Dans le formulaire de déploiement (onglet Environnements, en tête de liste), ou après coup via Configurer → Avancé → onglet Environnements :

1. Mode debug (JDWP) : active le flag -agentlib:jdwp=… sur le port 5005 (débogueur Java) et expose le port 1389 (annuaire LDAP OpenDJ) sur le Service Kubernetes de l'application.
2. Appliquez : le pod redémarre avec les deux ports actifs.

Aucune authentification côté JDWP

Le protocole de débogage Java (JDWP) n'a aucune authentification intégrée : quiconque atteint le port peut exécuter du code arbitraire dans la JVM. Le port LDAP donne accès à l'annuaire interne (comptes/rôles Digdash). Réservé à l'équipe DigDash pour une investigation ponctuelle — ne laissez pas le mode debug actif en continu ni en production, désactivez-le dès la fin de la session.

Se connecter

Les deux ports (5005 pour JDWP, 1389 pour LDAP) restent internes au cluster par défaut. Pour y accéder depuis un poste de développement, exposez-les temporairement via Ports personnalisés — voir Namespaces et quotas → Isolation réseau :

1. Créez une règle Ports personnalisés ciblant l'app Digdash BI, avec le port interne 5005 (ou 1389 pour LDAP) et un port externe libre de votre choix. Pour limiter les collisions avec les autres règles du cluster (le port externe doit être unique sur tout le cluster) et faciliter le repérage/nettoyage après la session, choisissez de préférence un port externe haut dans la plage 30000-35000 (déjà forwardée par le pare-feu), par exemple 34000 et au-delà : le bas de cette plage est attribué automatiquement à l'accès externe des bases PostgreSQL.

   Le champ Adresses IP autorisées est pré-rempli avec votre adresse actuelle, telle que la voit la plateforme : conservez-la. JDWP n'ayant aucune authentification, le port n'est alors joignable que depuis votre poste (ou la sortie de votre VPN). Ajoutez d'autres adresses si un collègue doit s'y connecter ; l'icône filtre d'un port existant permet de modifier la liste sans le recréer. 2. Le forward vers un éventuel pare-feu en amont reste une étape manuelle côté infrastructure, non automatisée depuis cette interface — voir le rappel affiché à la création de la règle.

1. Connectez ensuite votre IDE (débogueur distant) ou votre client LDAP sur <port externe>, à l'adresse du nom de domaine du Control Panel lui-même (ex. controlpanel.mon-cluster.digdash.com:30500) — pas une IP : le port personnalisé est exposé sur ce même Gateway partagé, dont l'IP publique n'est ni stable ni destinée à être utilisée directement.

Une fois la session terminée

Supprimez la règle Ports personnalisés et désactivez le mode debug (case décochée + Appliquer) : ni l'un ni l'autre ne doit rester actif en dehors d'une investigation en cours.