Digdash BI : options de déploiement¶
Le modèle Digdash BI (catégorie Visualisation) expose ses options au déploiement (formulaire) et, pour la plupart, après coup via Configurer → Avancé — voir Configurer une application pour le mécanisme général des onglets par catégorie.
Général¶
| Champ | Rôle |
|---|---|
| Version Digdash | Tag de l'image bi/digdash-tomcat. Par défaut la dernière version stable de la majeure choisie (<majeure>_latest) — un tag "nu" (ex. 2026R1) reste figé sur le tout premier build de cette majeure et devient rapidement obsolète (licence refusée en pratique). |
| Clé de licence | Clé Digdash à utiliser pour cette instance. |
| Limite mémoire, Limite CPU | Ressources du conteneur principal (Tomcat/JVM). |
Authentification et environnement¶
| Champ | Rôle |
|---|---|
| DIGDASH_AUTH_TYPE | Mode d'authentification : OIDC (par défaut) — SSO de la plateforme (Keycloak) et annuaire LDAP — LDAP — annuaire LDAP seul, connexion par identifiant et mot de passe DigDash — ou SAML2 — SSO de la plateforme en SAML 2.0 : un client SAML est créé dans le Keycloak de la plateforme au déploiement, et un fournisseur d'identité externe se branche via l'authentification relais. SAML2 se choisit à la création : on ne peut pas passer d'OIDC ou LDAP à SAML2, ni de SAML2 à un autre mode, sans réinstaller l'application. Dans tous les cas, les utilisateurs et rôles DigDash sont stockés dans l'annuaire OpenLDAP du sidecar dédié, toujours déployé : il est indispensable au fonctionnement de DigDash, ce n'est pas une option. |
| File Browser | Active un gestionnaire de fichiers accessoire (upload/téléchargement), désactivable si non utilisé. |
| JVM CATALINA_OPTS, DIGDASH_SYSTEM, DIGDASH_PROPERTIES | Réglages avancés (options JVM brutes, propriétés système Digdash, Digdash.properties) — un réglage par ligne, # pour commenter. Réservés aux cas où le réglage dédié n'existe pas ailleurs dans ce formulaire. |
Mode debug¶
Interrupteur réservé à l'équipe DigDash (onglet Environnements, en tête de liste), disponible uniquement sur ce modèle — voir la page dédiée Mode debug (Digdash BI) (activation, ports JDWP/LDAP, exposition externe temporaire).
Base de données¶
| Champ | Rôle |
|---|---|
| Type de base de données (onglet Environnements, en tête de liste) | cnpg (PostgreSQL managé, par défaut) ou un moteur externe déjà existant. Fixé à la création : changer de moteur nécessite une réinstallation. |
Sauvegarde et restauration¶
Un interrupteur active l'archivage continu des WAL et une sauvegarde planifiée (S3, moteur cnpg uniquement) ; la restauration se fait au moment de la création d'une nouvelle application, depuis la sauvegarde d'une autre — mécanique et champs communs détaillés dans Sauvegarde et restauration. Champs propres à Digdash BI : compression séparée WAL/données (gzip/bzip2/snappy), owner reference de la sauvegarde planifiée, et sauvegarde immédiate à la création.
Sauvegarde de l'environnement¶
Indépendamment de la base de données, l'environnement DigDash lui-même — utilisateurs, rôles, tableaux de bord, modèles de données, sources de données et annuaire LDAP — se sauvegarde vers un bucket S3 avec l'outil officiel backuptools : voir Sauvegarde de l'environnement.
Profil superadmin¶
Le profil DigDash superadmin, attribué au compte admin et à la personne qui déploie l'instance, reçoit tous les rôles de l'instance, en lecture, écriture et exécution. Un rôle créé ensuite dans DigDash y est ajouté automatiquement :
- juste après le déploiement ;
- par la tâche planifiable Donner au profil superadmin DigDash tous les rôles de son instance (Paramètres → Tâches planifiées), par exemple toutes les heures ;
- à la demande, par le bouton « Donner au profil superadmin DigDash tous les rôles de l'instance » de la carte (rôle admin), par exemple juste après avoir créé un rôle.
Le Test de compatibilité API vérifie que le profil superadmin détient bien tous les rôles, ainsi que les appels d'API qui servent à les lui donner.
Volumes¶
Dans l'onglet Capacité, avec la mémoire et le CPU : tailles des volumes appdata (données applicatives) et openldap (annuaire du sidecar OpenLDAP, toujours présent), plus le rattachement d'un volume existant déjà orphelin à chacun. Fixés à la création : le redimensionnement et le changement de volume après coup se font depuis l'onglet Volumes, pas ce formulaire.
Certificats CA personnalisés¶
Pour une instance qui doit faire confiance à une autorité de certification interne (ex. un service tiers en HTTPS avec un certificat d'entreprise) : active le montage d'un jeu de CA additionnelles dans le truststore du conteneur, au format nom_de_fichier: PEM (YAML), ou depuis un Secret Kubernetes déjà existant.
OpenID¶
SSO_LOGOUT (onglet Environnements, en fin de liste) : URL de redirection après déconnexion — par défaut celle de la plateforme, à ajuster seulement pour un flux de déconnexion personnalisé.