Control Panel — Documentation

Description

Guide d'utilisation du DigDash Control Panel

Control Panel

Le DigDash Control Panel est le portail de gestion de la plateforme data : il permet de déployer, superviser et administrer des applications (PostgreSQL, Digdash BI, Apache Hop, nginx…) sur le cluster Kubernetes de la plateforme, sans manipuler Kubernetes directement.

Ce que vous pouvez faire

Besoin	Où aller
Déployer une application depuis le catalogue	Déployer une application
Ajuster CPU, mémoire, variables d'environnement	Configurer une application
Sauvegarder et restaurer une base de données	Sauvegarde et restauration
Gérer les volumes persistants et les buckets S3	Volumes · Buckets S3
Donner accès à une application à un collègue	Accès et permissions
Créer des comptes utilisateurs	Utilisateurs
Héberger et partager du code Git en interne	Git
Administrer namespaces, quotas et réglages	Paramètres

Premiers pas

Nouveau sur la plateforme ? Commencez par la prise en main : connexion, tour de l'interface et premier déploiement en cinq minutes.

Recherche

Utilisez la barre de recherche en haut de cette documentation pour trouver directement une page ou une notion (par exemple « quota », « snapshot », « OIDC »).

Prise en main

Se connecter

L'authentification passe par le compte d'entreprise (Keycloak). Sur la page de connexion, cliquez sur Se connecter : vous êtes redirigé vers le formulaire Keycloak de la plateforme, puis renvoyé sur le tableau de bord une fois identifié.

Note

Vos droits dans le Control Panel (namespaces visibles, actions autorisées) dépendent des rôles qui vous ont été accordés — voir Accès et permissions. Un écran vide au premier login signifie généralement qu'aucun rôle ne vous a encore été attribué.

L'interface en un coup d'œil

• Barre latérale (gauche) : navigation principale — Applications, Ressources, Volumes, Buckets, Jobs Spark, Accès Applications, Permissions Internes, puis Cluster (suivi du lien Grafana si la supervision est installée), Utilisateurs, Paramètres. En bas : votre profil, votre compte Git et la déconnexion.
• En-tête : le sélecteur de namespace (l'espace de travail courant — toutes les listes de la page s'y rapportent), la recherche, le rafraîchissement manuel ou automatique (« Auto », toutes les 5 secondes), et les boutons Nouveau namespace / Nouvelle app.
• Précédent : à gauche de l'en-tête, le bouton ramène à l'écran d'où vous venez, avec son namespace, son onglet et sa sélection ; son info-bulle indique la destination. Un écran qui n'existe plus est sauté ; sans écran précédent, le bouton mène aux Applications.
• Jauge de quota : sous l'en-tête, la consommation du namespace courant (CPU, mémoire, pods, stockage) par rapport à ses quotas — voir Namespaces et quotas.
• Cartes d'application : une carte par application déployée, avec son statut (Running, Pending, Stopped, Error), ses jauges CPU/RAM et ses actions.

Votre premier déploiement

1. Choisissez votre namespace dans le sélecteur de l'en-tête.
2. Cliquez sur Nouvelle app et choisissez un modèle — par exemple PostgreSQL, le plus rapide à démarrer.
3. Donnez un nom (lettres minuscules, chiffres et tirets), laissez les valeurs par défaut, puis Déployer l'application.
4. La carte apparaît en Pending puis passe en Running — de quelques secondes à plusieurs minutes selon le modèle (Digdash BI est le plus long).

La configuration propre à chaque application est documentée dans la partie Applications, une page par application ; les champs communs à tous les déploiements sont décrits dans Déployer une application.

Changer la langue de l'interface

Depuis Mon profil (bas de la barre latérale), un sélecteur Langue permet de choisir français, anglais ou espagnol. Un administrateur peut aussi définir la langue de chaque compte depuis la page Utilisateurs.

Cluster

La page Cluster (réservée aux administrateurs de plateforme) donne une vue d'ensemble, en direct, des ressources Kubernetes de toute la plateforme — tous namespaces confondus. Elle se rafraîchit automatiquement toutes les 30 secondes, ou immédiatement via Actualiser.

L'en-tête affiche quatre indicateurs rapides : le nombre de nœuds, le nombre de pods en cours d'exécution, ainsi que le nombre total de volumes et de buckets de la plateforme, tous namespaces confondus.

Résumé global

Trois indicateurs par ressource (CPU et mémoire), rapportés à la capacité totale du cluster :

Indicateur	Signification
Utilisé	Consommation réelle mesurée par le serveur de métriques
Réservé (requests)	Somme des quantités demandées par tous les pods — ce que Kubernetes garantit
Limites	Somme des plafonds configurés — peut dépasser la capacité réelle (sur-allocation), à surveiller

Cliquer sur le libellé d'un indicateur ouvre la répartition par pod : la liste de tous les pods du cluster triée par consommation, avec un lien direct vers l'application correspondante lorsque le pod appartient à une release gérée par le Control Panel.

Stockage

Une carte Stockage Ceph complète le résumé global lorsque l'information est disponible. Elle affiche, selon ce qui a pu être déterminé :

• le quota du pool Ceph RBD applicatif et son occupation, si ce pool a un quota fixé ;
• à défaut, l'occupation du pool rapportée à la capacité totale du cluster Ceph, si le pool n'a pas de quota ;
• en dernier repli, la capacité globale du cluster Ceph (Rook), si le pool applicatif n'a pas pu être déterminé.

La carte est absente si aucune de ces informations n'est disponible (CLI ceph injoignable, par exemple).

Buckets S3

La section Buckets S3 liste tous les buckets de la plateforme, du plus volumineux au plus petit : namespace, nombre d'objets, taille, taille stockée après compression et gain de compression, avec les totaux au-dessus. Cliquer sur un namespace ouvre ses buckets. Si l'API d'administration du stockage objet (RGW) n'est pas joignable, la section l'indique.

Seuls les buckets créés sur cette plateforme sont comptés : lorsque plusieurs plateformes partagent le même stockage Ceph, celles des autres n'apparaissent pas.

Supervision

Lorsque la stack de supervision de la plateforme (Prometheus, Grafana, Alertmanager) est installée, l'en-tête de la page propose trois liens externes Grafana, Prometheus et Alertmanager (authentification via le compte plateforme habituel), et une carte Alertes actives liste les alertes Prometheus en cours (firing), les plus sévères en premier, avec leur namespace et le pod concerné.

La même stack alimente ailleurs dans le Control Panel :

• la colonne Utilisé de la page Volumes ;
• le lien Métriques des cartes d'application (dashboard Grafana du pod ou du namespace) — voir Applications ;
• le bandeau n alertes actives au-dessus du tableau de bord d'un namespace ;
• le lien Grafana de la barre latérale.

Si Prometheus est injoignable depuis le Control Panel, les liens restent affichés mais la carte l'indique et les valeurs dérivées (alertes, consommation des volumes) sont marquées indisponibles (n/d). Les URL publiques (GRAFANA_URL, PROMETHEUS_PUBLIC_URL, ALERTMANAGER_URL) et l'adresse interne de Prometheus (PROMETHEUS_URL) peuvent être surchargées dans Paramètres cluster.

Nœuds

Chaque nœud du cluster est présenté avec son statut (Ready ou non), ses rôles, et les mêmes six jauges (CPU/mémoire × utilisé/réservé/limites) rapportées à sa propre capacité — utile pour repérer un nœud déséquilibré avant que le scheduler Kubernetes n'ait du mal à y placer de nouveaux pods.

Note

Ces jauges donnent une vue plateforme complète, y compris les charges qui ne sont pas des applications du catalogue (composants système, autres services du cluster). Pour le détail des ressources d'un seul namespace, voir la carte d'application correspondante sur le tableau de bord.

Licence

Menu Licence — accès réservé aux administrateurs de la plateforme.

Le Control Panel fonctionne avec une licence délivrée par DigDash pour un cluster donné. Elle fixe un client, une date d'expiration et un plafond CPU. La page Licence affiche son état, permet de préparer une demande de licence et d'installer la licence reçue.

Ce qui est compté

Le plafond porte sur la somme des limites CPU (limits.cpu) des applications déployées, pas sur les cœurs des nœuds ni sur la consommation réelle :

• seuls les pods des namespaces d'applications (ceux listés dans le Control Panel) sont comptés ;
• seulement les pods démarrés ou en attente de démarrage : une application arrêtée (0 réplica) ne compte plus ;
• les pods placés sur les nœuds du plan de contrôle Kubernetes ne sont pas comptés ;
• l'infrastructure (stockage, supervision, passerelle, le Control Panel lui-même) n'est pas comptée.

Exemple : une application de 2 pods limités chacun à 1,5 CPU compte pour 3 CPU, qu'elle consomme 0,1 ou 3 cœurs. La limite CPU d'une application se règle dans sa configuration (voir Configurer une application).

Le total est relevé chaque minute. Un relevé de plus de 10 minutes est considéré comme inconnu et ne bloque jamais rien.

Évolution sur 30 jours

La courbe montre la somme des limites CPU des applications sur les 30 derniers jours, un point par heure (la valeur la plus haute de l'heure, pour que les pics restent visibles). La ligne pointillée est le plafond de la licence. Le survol affiche la valeur à une date donnée.

Avertissements et blocages

Situation	Effet
Expiration dans 15 jours ou moins	Bandeau en haut de toutes les pages, avec le nombre de jours restants.
Plafond CPU dépassé	Bandeau, et les nouveaux déploiements sont refusés tant que le total reste au-dessus du plafond. Les applications existantes continuent de fonctionner.
Aucune licence, licence expirée, invalide ou émise pour un autre cluster	Le Control Panel est bloqué : toutes les pages renvoient vers la page Licence. Les applications déjà déployées continuent de fonctionner.

Sans licence valide, les utilisateurs qui ne sont pas administrateurs de la plateforme voient seulement l'état de la licence et l'invitation à contacter un administrateur.

Obtenir ou renouveler une licence

La section Demande de licence rassemble les informations dont DigDash a besoin :

• l'identifiant du cluster (la licence n'est valable que sur ce cluster) ;
• le nom de la plateforme et la version du Control Panel ;
• la somme actuelle des limites CPU des applications ;
• le nombre de nœuds hors plan de contrôle et leur capacité CPU ;
• la licence actuelle, s'il y en a une.

Télécharger la demande produit un fichier JSON à envoyer à DigDash ; Copier place le même contenu dans le presse-papiers.

Installer une licence

Collez la licence fournie par DigDash dans Installer une licence, puis cliquez sur Installer. Elle est vérifiée immédiatement et refusée si elle a été modifiée ou si elle a été émise pour un autre cluster. Une licence acceptée remplace la précédente et débloque le Control Panel sans redémarrage.

Consulter la licence installée

Afficher la licence montre le texte de la licence installée, par exemple pour la vérifier ou la transmettre à DigDash ; Copier le place dans le presse-papiers. Chaque consultation est tracée dans les logs d'audit.

Mises à jour

Menu Mises à jour — accès réservé aux administrateurs de la plateforme.

La page Mises à jour montre la version installée du Control Panel, les versions plus récentes disponibles avec leurs notes, et installe une nouvelle version en un clic.

Canal suivi

Chaque plateforme suit un canal de publication :

Canal	Pour qui	Contenu
stable (par défaut)	plateformes clientes	versions validées par les tests de bout en bout avant publication
beta	plateformes internes	chaque nouvelle version, dès sa publication

Le canal se règle avec le paramètre UPDATE_CHANNEL dans les paramètres cluster (stable ou beta).

Vérification des nouvelles versions

Le Control Panel vérifie le canal toutes les heures. Vérifier maintenant relance la vérification immédiatement ; la date de la dernière vérification est affichée en haut de la page. Quand une version plus récente existe, un badge vX.Y.Z disponible apparaît en bas du menu, sur toutes les pages.

Chaque version disponible est affichée avec ses notes de version ; la plus récente porte le badge la plus récente.

Mise à jour automatique

La section Mise à jour automatique installe chaque semaine, au créneau choisi, la dernière version disponible sur le canal. Elle est désactivée par défaut ; le créneau proposé est le samedi à 12:00, heure de Paris.

• Cochez Activer la mise à jour automatique, choisissez le jour et l'heure, puis Enregistrer.
• Au créneau, le Control Panel vérifie le canal : s'il est à jour, ou si une mise à jour est déjà en cours, rien ne se passe. Sinon, la mise à jour se déroule exactement comme une mise à jour manuelle (sauvegarde, installation, retour arrière automatique en cas d'échec). Elle apparaît dans l'historique avec l'auteur automatique.
• Le même réglage existe dans Paramètres → Tâches planifiées (tâche auto_update_controlpanel), où l'on peut aussi saisir une expression crontab plus fine. Dans ce cas, la page Mises à jour le signale ; enregistrer depuis la page remplace l'expression par un créneau hebdomadaire.

Chaque changement de réglage est tracé dans les logs d'audit.

Mettre à jour

Mettre à jour vers X.Y.Z demande une confirmation, puis :

1. Sauvegarde : la base de données du Control Panel est sauvegardée (sauvegarde CloudNativePG par snapshot de volume, restaurable). Si la sauvegarde échoue, la mise à jour est abandonnée et rien n'est modifié.
2. Installation : la nouvelle version est installée.
3. Vérification : si la nouvelle version ne démarre pas, la version précédente est rétablie automatiquement.

L'interface est indisponible une à deux minutes pendant l'installation ; la page se met à jour d'elle-même. Les applications déployées ne sont pas touchées. Une fois la nouvelle version en place, un bouton propose de recharger la page pour charger la nouvelle interface.

Les sauvegardes des trois dernières mises à jour sont conservées ; les plus anciennes sont supprimées automatiquement.

Note

La mise à jour n'est possible que depuis le Control Panel déployé dans le cluster, pas depuis une installation de développement.

Historique

L'historique liste les mises à jour passées : date, versions de départ et d'arrivée, auteur et résultat (Réussie ou Échouée, avec la raison). Journal affiche la sortie de l'installation, utile pour comprendre un échec.

Applications

Applications

Le tableau de bord liste les applications du namespace courant, une carte par application.

Le catalogue

Le bouton Nouvelle app ouvre le catalogue des modèles disponibles, par catégorie :

Catégorie	Modèles
Traitement	Apache Hop (GUI), Apache Hop Server, Trino, Spark Connect, Apache NiFi
Stockage	PostgreSQL, Serveur SFTP
Visualisation	Digdash BI
Gouvernance	Apache Iceberg (catalogue Polaris), OpenMetadata
Data science	JupyterHub, MLflow
DevOps	Nginx (site statique)

Les modèles Apache Iceberg, Trino et JupyterHub se combinent en un lakehouse sur les buckets S3 de la plateforme — voir Lakehouse.

Forgejo, un cas à part

Le serveur Git Forgejo n'apparaît pas dans ce catalogue : c'est une application transverse à la plateforme (une seule instance pour tout le cluster), gérée depuis Paramètres → Git — voir Git.

Anatomie d'une carte

Chaque carte affiche :

• le nom (ou le nom d'affichage s'il a été personnalisé), le modèle et l'image déployée ;
• le statut : Running, Pending (démarrage en cours), Stopped, Error ;
• les jauges CPU et RAM : consommation réelle par rapport aux ressources demandées ;
• la version de l'application et celle de son chart (2026R1 · chart 1.8.1), et le badge Mise à jour disponible quand une version plus récente du chart est publiée ;
• la date de création et l'auteur du déploiement.

Comprendre les jauges CPU et RAM

Chaque jauge affiche la consommation réelle du pod (remontée par le serveur de métriques du cluster) rapportée à sa limite si l'application en a une, sinon à sa quantité demandée (requested) — voir Configurer une application pour la différence entre les deux.

• 0,85 / 2,00 cores : 0,85 cœur consommé pour une limite de 2 cœurs.
• 3,2 Gi / 4,0 Gi : 3,2 Gio de RAM consommés pour une limite de 4 Gio.
• n/d : le serveur de métriques du cluster n'a pas encore de mesure pour ce pod (redémarrage récent, par exemple) — la jauge reste grisée.

La couleur de la barre indique le niveau de consommation par rapport à ce plafond :

Couleur	Seuil	Signification
🟢 Teal	< 60 %	Consommation normale
🟠 Ambre	60 % – 79 %	Approche du plafond — surveiller
🔴 Rouge	≥ 80 %	Proche ou au plafond — l'application risque d'être limitée (CPU) ou tuée par le kernel (mémoire, OOMKill)

Sur la capture ci-dessus, le CPU (42,5 % de la limite) reste en teal tandis que la RAM (80 % de la limite) passe au rouge — c'est le signal pour augmenter la limite mémoire de l'application depuis Configurer.

Mettre à jour une application

Quand une version plus récente du chart de l'application est publiée, sa carte affiche le badge Mise à jour disponible : 2026R2 (la version visée de l'application) ; si seul le chart change, le badge indique Mise à jour disponible : chart 1.10.0. La ligne Version de la carte donne la version actuelle.

Le badge est lui-même le bouton de la montée : un clic dessus ouvre une fenêtre de confirmation. Il est réservé au rôle operator ou supérieur (le badge reste lisible mais grisé sinon, avec l'info-bulle « Droits insuffisants »). La barre d'actions de la carte n'a pas d'icône de mise à jour.

• les versions de départ et d'arrivée de l'application et du chart (1.8.1 → 1.10.0) ;
• un avertissement en cas de changement majeur du chart : lisez ses notes de version avant de continuer ;
• les vulnérabilités (CVE) corrigées, dans un encadré vert : « Cette mise à jour corrige 3 CVE critiques : », avec l'identifiant et le titre de chacune, puis « Et 5 CVE de sévérité élevée. » s'il y en a. Si la version visée contient elle-même des CVE critiques absentes de la version actuelle, un encadré orange le signale : « La nouvelle version contient 1 CVE critique absente de la version actuelle. » ;
• un rappel : l'application redémarre pendant la mise à jour ; elle peut mettre plusieurs minutes à revenir.

Les CVE sont lues dans l'analyse du registre d'images de la plateforme, à l'ouverture de la fenêtre (« Recherche des vulnérabilités corrigées… »). C'est une information : si l'analyse n'est pas disponible, ou n'a rien à signaler, aucun encadré n'apparaît et la mise à jour reste possible.

Si une autre mise à jour de cette application est déjà en cours (lancée par un autre utilisateur ou dans un autre onglet), la fenêtre affiche le message du serveur et rien n'est lancé.

Mettre à jour ferme la fenêtre et lance la montée de version, puis redémarre l'application, comme Réinitialiser. Pendant son déroulement, le badge de la carte devient Mise à jour en cours… et il est grisé. Un bandeau en haut du tableau de bord suit la tâche, puis donne le résultat :

• succès : « tableau-de-bord mise à jour : chart 1.8.1 → 1.10.0. » ;
• succès sans redémarrage, en orange : « tableau-de-bord mise à jour : chart 1.8.1 → 1.10.0, mais le redémarrage a échoué : cliquez sur Réinitialiser. » La nouvelle version est bien déployée ; cliquez sur Réinitialiser sur la carte pour relancer les pods ;
• échec : « Échec de la mise à jour de tableau-de-bord : … », suivi du motif.

La croix du bandeau le ferme à tout moment ; fermer un bandeau encore en cours arrête seulement son suivi. La mise à jour, elle, continue côté serveur : la carte repasse alors à Mise à jour disponible et le badge se réactive pendant que la montée tourne ; un nouveau clic sur Mettre à jour renvoie le message du serveur décrit plus haut (mise à jour déjà en cours).

Une image fixée à une autre version que celle du chart (par exemple un tag choisi dans Configurer) est conservée par la mise à jour, et le bandeau le dit : « Image conservée en 2025R3. »

Mettre à jour redémarre, Réinitialiser ne change pas la version

Réinitialiser relance les pods avec la version déjà déployée : seule Mettre à jour fait passer l'application, et son chart, à la version publiée. La mise à jour redémarre elle-même l'application : inutile de réinitialiser ensuite, sauf si le bandeau orange le demande.

Actions disponibles

Selon le modèle et l'état de l'application :

Action	Effet
Ouvrir (lien externe)	Accéder à l'application déployée dans un nouvel onglet
Métriques (lien externe)	Ouvrir le dashboard Grafana de l'application (pod ou namespace) — présent si la supervision de la plateforme est installée, voir Cluster
Éteindre / Démarrer	Arrêter ou relancer l'application sans la supprimer
Réinitialiser	Redémarrer les pods (rollout), sans changer de version
Configurer	Modifier nom d'affichage, ressources, variables… — voir Configurer
Voir les détails	Pods, services, routes, informations de connexion interne
Gérer les accès	Autoriser d'autres utilisateurs — voir Accès et permissions
Supprimer	Désinstaller la release (confirmation par ressaisie du nom, irréversible)

Actions spécifiques à certains modèles

• Test de compatibilité API (Digdash BI, Apache Hop Server, Forgejo) : vérifie de bout en bout que l'API de l'application répond, avec un résultat détaillé par point de contrôle (badge Sain ou Dégradé).
• Resynchroniser les connexions Hop (Apache Hop GUI) : régénère immédiatement les fichiers de métadonnées du projet Hop (connexions aux bases PostgreSQL, aux serveurs Hop et aux buckets du namespace), sans attendre la synchronisation périodique.
• Resynchroniser les connexions DigDash (Digdash BI) : reprovisionne les connexions internes Audit / Commentaires / Formulaire vers le PostgreSQL intégré.
• Jobs Hop (Apache Hop Server) : suivi et lancement des pipelines et workflows planifiés — voir Apache Hop Server : jobs et planification pour le détail.

Déployer une application

1. Vérifiez le namespace sélectionné dans l'en-tête — l'application y sera déployée.
2. Cliquez sur Nouvelle app, puis sur Déployer sous le modèle voulu.
3. Renseignez le formulaire de configuration, puis Déployer l'application.

Les champs communs

• Nom de l'application (requis) : lettres minuscules, chiffres et tirets uniquement. Il identifie la release et ne peut plus être changé ensuite (le nom d'affichage, lui, reste modifiable — voir Configurer).
• Namespace : prérempli avec le namespace courant.
• Version : le tag de l'image, chargé dynamiquement depuis le registre de la plateforme.
• Capacité (CPU / mémoire / stockage) : chaque modèle a des valeurs par défaut raisonnables ; réduisez-les si le quota du namespace est serré. Mémoire, disque et CPU se saisissent en nombre entier + unité : Mi, Gi ou Ti pour la mémoire et les disques, m (millicœurs) ou cœurs pour le CPU, m ou g pour les tailles JVM (heap NiFi, mémoire Spark).

Les champs varient ensuite selon le modèle : identifiants admin, propriétés applicatives, volumes, source Git (pour Apache Hop), sauvegardes (pour PostgreSQL et Digdash BI)…

Quota insuffisant

Si le déploiement échoue avec un message exceeded quota, le namespace n'a plus assez de CPU, de mémoire ou de stockage disponible. Réduisez la capacité demandée, supprimez des ressources inutilisées, ou demandez une augmentation de quota à un administrateur.

Après le déploiement

La carte apparaît immédiatement en Pending. Le passage en Running prend :

• quelques dizaines de secondes pour nginx ou PostgreSQL ;
• une à deux minutes pour Apache Hop ;
• plusieurs minutes pour Digdash BI (JVM + base PostgreSQL intégrée).

Certains modèles (Apache Hop, Digdash BI) créent aussi automatiquement un client OIDC dans Keycloak : l'accès à l'application déployée passe alors par l'authentification d'entreprise, et les utilisateurs autorisés se gèrent depuis Gérer les accès sur la carte.

Restaurer depuis une sauvegarde à la création

Pour PostgreSQL et Digdash BI, la section Restauration du formulaire permet de créer l'application directement à partir d'une sauvegarde S3 existante — voir Sauvegarde et restauration.

Configurer une application

Le bouton Configurer d'une carte ouvre la configuration du déploiement en cours. Si l'application a plusieurs pods (par exemple Digdash BI et son PostgreSQL intégré), un sélecteur de pod s'affiche d'abord.

Onglet Général

• Nom d'affichage : le libellé montré sur la carte, modifiable à tout moment (contrairement au nom technique).
• Réplicas : nombre d'instances du pod.

Onglet du conteneur

Pour chaque conteneur de l'application :

• Image : le tag est modifiable (liste chargée depuis le registre) — changer de version redéploie l'application.

• Ressources : CPU et mémoire, avec pour chacun deux valeurs distinctes :

  • Requested — la réservation garantie sur le cluster (comptée dans le quota du namespace) ;
  • Limite — le plafond au-delà duquel le conteneur est bridé (CPU) ou redémarré (mémoire).

  Chaque valeur se saisit en nombre entier + unité (m ou cœurs pour le CPU, Mi/Gi/Ti pour la mémoire). La limite doit être supérieure ou égale au requested. Modifier ces valeurs déclenche un redémarrage du pod.

• Variables d'environnement : affichées en lecture seule (nom et valeur des conteneurs standards) — non modifiables depuis cette modale.

Onglet Volumes

Les volumes persistants montés par l'application, avec la possibilité de pointer un montage vers un autre PVC existant (par exemple un clone ou un volume restauré depuis un snapshot — voir Volumes).

Paramètres avancés

Les champs propres au modèle (propriétés Digdash, planification de sauvegarde, source Git Hop…) qui restent modifiables après le déploiement. Les champs marqués d'un cadenas sont figés — leur infobulle explique pourquoi (par exemple : « Changer le moteur de base de données nécessite une réinstallation »).

Tip

Après un Enregistrer, si des ressources ou l'image ont changé, l'application redémarre : la carte repasse brièvement en Pending avant de redevenir Running.

PostgreSQL

PostgreSQL : options de déploiement

Le modèle PostgreSQL déploie une base gérée par l'opérateur CloudNativePG (CNPG) sur le cluster.

Ces réglages se choisissent dans le formulaire Nouvelle app, avant de déployer :

• Nombre d'instances : 1 par défaut (pas de haute disponibilité). À partir de 2, CNPG bascule automatiquement sur une réplique en cas de défaillance du primaire. Modifiable à tout moment depuis Configurer, y compris après déploiement : CNPG ajoute ou retire des répliques en conséquence.
• PostGIS (données géospatiales) : une seule case à cocher. L'image PostgreSQL qui embarque l'extension est choisie automatiquement (paramètre cluster POSTGIS_DEFAULT_IMAGE) et l'extension est créée dans la base au déploiement — rien d'autre à renseigner. Un champ Image PostGIS (avancé), masqué, permet d'imposer une autre version : elle doit alors correspondre à la version majeure PostgreSQL de l'opérateur CNPG.
• Métriques Prometheus : activées par défaut, exposent les métriques CNPG à la Prometheus de la plateforme.
• Pooling de connexions (PgBouncer) : désactivé par défaut ; utile pour les workloads à beaucoup de connexions courtes. Une fois activé, les applications qui veulent en bénéficier se connectent au service <nom-app>-postgres-pooler plutôt qu'au service -rw habituel.

Warning

Comme le nom de la base ou l'utilisateur admin, PostGIS n'est appliqué qu'à la création de l'application (bootstrap CNPG) : l'activer sur une application déjà déployée n'a aucun effet.

Pour aller plus loin

• Administration PostgreSQL — bases, utilisateurs et droits, exécution de SQL, accès externe depuis un poste ou un outil tiers.
• Sauvegarde et restauration — archivage continu des WAL vers S3, restauration dans une nouvelle application, restauration à une date précise.

Administration PostgreSQL

Bouton Administrer d'une carte PostgreSQL (chart/postgres) — visible une fois l'application Running, réservé aux utilisateurs ayant le rôle admin sur le namespace.

La modale se connecte en direct à la base de l'application (pas de copie ni de cache côté Control Panel) avec le compte administrateur créé par le chart au déploiement. Trois onglets :

Bases de données

Liste les bases existantes (hors bases techniques) et permet d'en créer une nouvelle par son nom.

Utilisateurs & droits

• Créer / réinitialiser un utilisateur : s'il n'existe pas encore, il est créé ; s'il existe déjà, son mot de passe est régénéré. Le mot de passe généré n'est affiché qu'une seule fois, juste après l'opération — Postgres ne le stocke jamais en clair, il ne peut donc pas être relu ensuite. Notez-le ou copiez-le immédiatement.
• Les rôles marqués Système (streaming_replica, cnpg_metrics_exporter, et le compte administrateur créé par le chart lui-même) sont des rôles techniques de la plateforme : ils n'apparaissent pas dans le champ Accorder des droits, et leur mot de passe ne peut pas être réinitialisé depuis cette interface.
• Cliquer sur un utilisateur déplie ses droits actuels, base par base (capture ci-dessus). Le niveau affiché est déduit des privilèges réellement présents sur les tables du schéma public — pas d'un historique des accords : Accès à la base signifie CONNECT accordé mais aucune table pour l'instant (un ALTER DEFAULT PRIVILEGES en attente d'une future table ne laisse aucune trace avant qu'elle existe), et Droits personnalisés signifie un jeu de privilèges qui ne correspond à aucun des trois niveaux ci-dessous (modifiés à la main via l'onglet Exécuter SQL).
• Accorder des droits applique un niveau — Lecture seule, Lecture-écriture ou Tous les droits — à un utilisateur sur une base, y compris pour les objets créés ultérieurement (ALTER DEFAULT PRIVILEGES).

Exécuter SQL

Une commande SQL libre contre la base choisie, avec coloration syntaxique. Un SELECT retourne un tableau de résultats ; toute autre commande (DDL/DML) affiche le statut renvoyé par Postgres (ex. CREATE TABLE, nombre de lignes affectées).

Warning

Cet onglet exécute n'importe quelle commande SQL, y compris destructrice (DROP TABLE, DELETE sans WHERE…). Il n'y a pas de confirmation intermédiaire : vérifiez la commande et la base sélectionnée avant d'exécuter.

Tip

Il n'y a pas de bouton de suppression dédié pour une base ou un utilisateur : passez par l'onglet Exécuter SQL (DROP DATABASE, ou DROP OWNED BY suivi de DROP ROLE pour un utilisateur ayant reçu des droits). Une base ne peut pas être supprimée en étant connecté dessus — sélectionnez une autre base avant d'exécuter le DROP DATABASE.

Accès externe

Bouton Accès externe d'une carte PostgreSQL — visible une fois l'application Running, réservé aux utilisateurs ayant le rôle admin sur le namespace.

Par défaut, une base n'est joignable que depuis le cluster (<nom-app>-rw.<namespace>.svc.cluster.local). Exposer la base lui attribue un port TCP sur le Gateway partagé, choisi automatiquement dans une plage réservée (paramètre cluster CUSTOM_PORT_AUTO_RANGE, défaut 30000-35000) : aucun numéro de port à saisir, et aucun risque de reprendre un port déjà utilisé par la plateforme. Le nom public de la base est <nom-app>-<namespace>.pg.<domaine> quand la plateforme dispose d'un certificat public pour les bases (voir plus bas), <nom-app>-<namespace>.<domaine> sinon.

L'exposition exige TLS par défaut :

• les connexions non chiffrées sont refusées sur cette base, y compris depuis le cluster (règle hostnossl … reject ajoutée au pg_hba) ;
• la base sert un certificat qui couvre son nom public, ce qui rend sslmode=verify-full possible ;
• la modale affiche l'URI de connexion et l'URL JDBC correspondantes.

Certificat reconnu publiquement (cas normal). Quand un certificat wildcard Let's Encrypt est configuré pour les bases (paramètre cluster POSTGRES_PUBLIC_TLS_SECRET), la base le sert à la place du certificat de CNPG. Le client vérifie le serveur avec son propre magasin de certificats : aucun fichier à lui fournir, et le renouvellement est automatique et sans coupure. Les URL affichées en tiennent compte : sslrootcert=system pour psql et libpq 16 ou plus (avec une version plus ancienne, pointez sslrootcert vers le bundle système, par exemple /etc/ssl/certs/ca-certificates.crt), sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory en JDBC pour utiliser le truststore Java.

Sans certificat public configuré, le nom public est ajouté au certificat généré par CNPG, signé par une CA propre à la base. La modale permet alors de télécharger le certificat de la CA — à passer au client (sslrootcert) pour vérifier le serveur. CNPG renouvelle cette CA périodiquement (date d'expiration affichée) : le fichier téléchargé devra être remplacé à ce moment-là. Pour verify-full, l'URI référence ce fichier sous son nom de téléchargement (sslrootcert=<nom-app>-ca.crt) : placez-le dans le répertoire de travail du client, ou adaptez le chemin.

Ce que change « Exiger TLS » pour les clients existants

La plupart des clients négocient TLS d'eux-mêmes dès que le serveur le propose — ce que fait CNPG en permanence — et ne voient donc aucune différence : psql, psycopg, et le driver JDBC embarqué par DigDash (pgjdbc 42.7, sslmode=prefer par défaut depuis 42.2.9). Les connexions DigDash créées automatiquement vers une base du même namespace sont dans ce cas : elles sont déjà chiffrées et continuent de fonctionner.

Seul un client qui désactive explicitement le chiffrement (sslmode=disable) est refusé. Pour imposer le chiffrement côté client sans dépendre de la négociation, utilisez ?sslmode=require ; en JDBC, n'utilisez pas ssl=true seul, qui équivaut à verify-full et échoue faute de certificat de CA.

Warning

Comme pour tout port exposé, le forward pare-feu externe n'est pas automatisé : faites pointer le port affiché vers le Load Balancer du cluster, dont les adresses sont rappelées dans la modale.

Restreindre les adresses sources

Le champ Adresses IP autorisées limite les connexions externes à une liste d'adresses IP ou de plages CIDR, une par ligne (203.0.113.7, 198.51.100.0/24, IPv6 acceptée). Il se renseigne à l'exposition ou plus tard, base exposée, avec Enregistrer. Laissé vide, toute adresse que le pare-feu externe laisse passer est acceptée.

Le filtrage est appliqué par le proxy du Gateway partagé, avant que la connexion n'atteigne la base : une source refusée voit sa connexion coupée sans échange avec PostgreSQL. Il porte sur l'adresse publique du client telle qu'elle arrive au cluster (adresse de sortie d'un VPN ou d'un NAT d'entreprise, par exemple).

Note

Une modification s'applique aux nouvelles connexions ; une session déjà ouverte depuis une adresse retirée n'est pas coupée. Les applications du cluster (DigDash…) doivent utiliser l'accès interne, qui ne passe pas par ce filtrage — par le nom public, elles apparaîtraient avec l'adresse du pare-feu.

Retirer l'exposition supprime le port et la route. L'exigence de TLS, elle, reste en place — des clients ont pu s'y adapter entre-temps — et se modifie depuis Configurer, catégorie Sécurité.

Les volumes d'une base PostgreSQL ne se redimensionnent ni ne se copient depuis la page Volumes : voir Volumes.

Sauvegarde et restauration

Les bases PostgreSQL — qu'il s'agisse du modèle PostgreSQL autonome ou du PostgreSQL intégré à Digdash BI — peuvent être sauvegardées en continu vers un stockage S3, puis restaurées dans une nouvelle application.

Activer les sauvegardes

Dans le formulaire de déploiement (section Sauvegarde), ou après coup via Configurer → Paramètres avancés :

1. Activer les sauvegardes planifiées : active à la fois l'archivage continu des journaux (WAL) et la sauvegarde de base planifiée — les deux sont nécessaires pour pouvoir restaurer.
2. Politique de rétention : durée de conservation, par exemple 7d, 4w.
3. Chemin S3 (destinationPath) : le bucket cible. Choisissez Bucket existant pour sélectionner un bucket de la plateforme — le chemin s3://… et l'endpoint se remplissent automatiquement.
4. Access Key / Secret Key : les identifiants du bucket (fournis par la page Buckets).

Sauvegarde immédiate

La planification par défaut est quotidienne. Pour produire une première sauvegarde sans attendre, une option de sauvegarde immédiate est disponible dans les paramètres de sauvegarde.

Restaurer

La restauration crée une nouvelle application dont la base démarre depuis la sauvegarde — l'application d'origine n'est pas modifiée.

1. Nouvelle app → même modèle que la source (PostgreSQL ou Digdash BI).
2. Dans la section Restauration :
   • activez la restauration ;
   • Nom de l'app source : le nom exact de l'application dont la sauvegarde a été écrite (tel qu'affiché sur sa carte) ;
   • Chemin S3 de la sauvegarde à restaurer : le même bucket que celui de la sauvegarde ;
   • les identifiants S3 du bucket.
3. Déployez : la nouvelle application démarre en rejouant la sauvegarde, puis passe en Running.

Warning

Si la source S3 est vide, inaccessible ou corrompue, la nouvelle application ne démarrera pas (redémarrages en boucle). Vérifiez le contenu du bucket depuis la page Buckets avant de lancer la restauration.

Restaurer à une date précise

Par défaut, la restauration rejoue la sauvegarde jusqu'au point le plus récent disponible (fin du flux des journaux WAL). Il est aussi possible de restaurer la base telle qu'elle était exactement à un instant donné dans le passé — utile par exemple pour annuler les effets d'une suppression ou d'une migration ratée survenue après la dernière sauvegarde valable.

Exemple : sauvegardes quotidiennes, restauration à l'état de la veille à 23h59

Une application source a les sauvegardes planifiées activées avec une planification quotidienne (0 0 0 * * *, soit minuit chaque jour) et une rétention de 7 jours. Une erreur est constatée aujourd'hui ; on souhaite retrouver l'état de la base tel qu'il était hier à 23h59, juste avant la sauvegarde de minuit :

1. Nouvelle app → même modèle que la source.
2. Section Restauration : activez-la, renseignez le Nom de l'app source et le Chemin S3 de la sauvegarde à restaurer comme pour une restauration classique.
3. Restaurer à une date précise (optionnel) : saisissez 2024-06-24 23:59:00+02 (adapter la date et le fuseau horaire).
4. Déployez : CNPG restaure la sauvegarde puis rejoue les journaux WAL archivés jusqu'à l'instant indiqué, sans aller plus loin.

Tip

Le fuseau horaire fait partie de la valeur (+02, +00…) — sans lui, l'heure est interprétée dans le fuseau du serveur PostgreSQL. La continuité des journaux WAL entre la sauvegarde et l'instant cible doit être intacte : une rétention trop courte ou une sauvegarde manquante entre les deux empêche la restauration d'atteindre la date demandée.

Snapshots de volumes

Indépendamment des sauvegardes S3, tout volume persistant peut faire l'objet de snapshots ponctuels et de clones — voir Volumes.

Digdash BI

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é.

Sauvegarde de l'environnement DigDash

Voir aussi les options de déploiement de Digdash BI.

Indépendamment de la base de données, la catégorie Sauvegarde de l'environnement sauvegarde l'environnement DigDash lui-même — utilisateurs, rôles, tableaux de bord, modèles de données, sources de données et annuaire LDAP — avec l'outil officiel backuptools de DigDash, vers un bucket S3. Elle fonctionne quel que soit le type de base de données.

Champ	Rôle
Activer la sauvegarde de l'environnement DigDash	Ajoute au pod un conteneur dédié à la sauvegarde et à la restauration — nécessaire aussi pour sauvegarder et restaurer à la demande depuis la carte.
Bucket S3	Bucket de destination. Un bucket de ce namespace est utilisé avec ses propres identifiants ; pour un autre S3, passez en saisie manuelle et renseignez endpoint et clés.
Préfixe S3	Dossier des sauvegardes dans le bucket. Vide = nom de l'application.
Sauvegarde à restaurer au démarrage	Liste des sauvegardes du bucket choisi (toutes applications du namespace). La sauvegarde choisie est importée au premier démarrage d'une nouvelle instance, une seule fois : un redémarrage ne la réimporte pas. Permet de créer une instance à partir de la sauvegarde d'une autre.
Sauvegarde automatique quotidienne (heure UTC)	Une sauvegarde par jour à l'heure indiquée (02:00 par défaut). Vide = pas de sauvegarde automatique, seulement à la demande depuis la carte.
Nombre de sauvegardes conservées	Les plus anciennes sont supprimées de S3 après chaque sauvegarde (0 = toutes).
Inclure l'annuaire LDAP / Inclure les sources de données	Contenu des sauvegardes et des restaurations.

Une fois l'application démarrée, la carte affiche Sauvegarde · Environnement DigDash. La fenêtre liste par défaut les sauvegardes de cette instance (son préfixe) ; la case Afficher toutes les sauvegardes du bucket montre aussi celles des autres instances, pour en restaurer une (bucket de ce namespace uniquement). Elle permet de :

• Sauvegarder maintenant (rôle opérateur) ;
• Restaurer une sauvegarde sur l'instance en service, sans redémarrage (rôle admin). Les éléments sauvegardés remplacent leur version actuelle ; ce qui a été créé depuis est conservé.

Une seule sauvegarde ou restauration à la fois ; la fenêtre suit l'opération en cours et affiche son résultat.

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.

Apache Hop GUI : options de déploiement

Le modèle Apache Hop (GUI) (catégorie Traitement) déploie Hop Web, l'interface de conception des pipelines et des workflows Apache Hop. Le projet Hop vient d'un dépôt Git, cloné au premier démarrage puis mis à jour par git pull --ff-only aux démarrages suivants. Le travail, les favoris du sélecteur de fichiers et l'historique de chaque utilisateur sont conservés sur le volume data de l'application.

Général

Champ	Rôle
Version Hop	Tag de l'image ds/hop-web.
Limite mémoire, Limite CPU	Ressources du conteneur (catégorie Capacité).
File Browser	Gestionnaire de fichiers accessoire (upload/téléchargement), désactivable si inutile.
Nom du projet Hop	Nom affiché du projet dans Hop Web. Vide : le nom du dépôt Git choisi à la création. Le dossier du projet sur disque, lui, ne change pas.

Source Git

Le projet ouvert dans Hop Web vient d'un dépôt Git, choisi dans la catégorie Source Git :

Champ	Rôle
Source du projet Git	Aucune (projet vide), Instance Forgejo gérée ou Saisie manuelle.
Instance Forgejo, Dépôt, Branche	Mode Forgejo : une instance de la plateforme, un dépôt visible par son compte admin, puis la branche (vide = branche par défaut du dépôt) — voir Git.
URL du dépôt, Branche, Utilisateur git, Token / mot de passe git	Saisie manuelle : dépôt externe. Utilisateur et jeton uniquement pour un dépôt privé ; ils sont conservés dans un Secret du namespace, jamais réaffichés.

Accès

Apache Hop GUI est le seul modèle à octroi direct : depuis Accès, un utilisateur est autorisé ou non, sans notion de profil — voir Accès et permissions.

Connexions du projet

La plateforme écrit dans le projet Hop les métadonnées de connexion du namespace : bases PostgreSQL, serveurs Hop et buckets S3. Elles sont régénérées périodiquement, et immédiatement avec l'action Resynchroniser les connexions Hop de la carte. Les mots de passe y sont chiffrés avec une clé AES commune à la plateforme, donc déchiffrables aussi par les instances Apache Hop Server.

Pour aller plus loin

• Apache Hop Server : options de déploiement — exécuter les pipelines conçus ici.
• Exemple : chaîne de traitement datawarehouse — dépôt Git, base, pipeline et job planifié, de bout en bout.

Apache Hop Server

Apache Hop Server : options de déploiement

Le modèle Apache Hop Server (catégorie Traitement) déploie un serveur d'exécution Apache Hop : il exécute les pipelines et workflows du projet Git synchronisé sur l'instance, à la demande ou sur planification — voir Jobs et planification.

Général

Champ	Rôle
Version Hop	Tag de l'image ds/hop-server.
Limite mémoire, Limite CPU	Ressources du conteneur (catégorie Capacité) : 4Gi et 2000m par défaut.
File Browser	Gestionnaire de fichiers accessoire (upload/téléchargement), activé par défaut.
Nom de l'environnement Hop	HOP_ENVIRONMENT_NAME : environnement du projet activé au démarrage.

Source Git

La source du projet est obligatoire ici, et se renseigne comme pour Apache Hop GUI : instance Forgejo gérée (instance, dépôt, branche) ou saisie manuelle (URL, branche, utilisateur et jeton pour un dépôt privé).

Champ	Rôle
Intervalle de synchronisation	Fréquence de scrutation du dépôt par le sidecar git-sync (30s, 1m, 5m…), 60s par défaut.

Contrairement à Hop GUI, le projet est synchronisé en continu : un commit poussé sur la branche suivie est pris en compte à la synchronisation suivante, sans redémarrer l'application.

Pour aller plus loin

• Jobs et planification — file d'attente, lancement d'un job, planification périodique.
• Test de compatibilité API, action de la carte : vérifie que l'API du serveur répond, point de contrôle par point de contrôle.

Apache Hop Server : jobs et planification

La carte Apache Hop Server ouvre, via le bouton Jobs Hop, une page dédiée au lancement et au suivi des pipelines et workflows du projet Hop synchronisé sur cette instance (voir Git pour la configuration de la source du projet).

File d'attente

Un bandeau en haut de page indique le nombre de jobs en cours et en attente, ainsi que la consommation CPU/RAM réelle de l'instance Hop Server. Le nombre maximal de jobs exécutés en parallèle se règle ici (Max en parallèle) — une file est créée automatiquement (limite à 1) au premier job lancé si aucune n'existe encore.

Lancer un job standard

Lancer un job ouvre une sélection parmi les pipelines (.hpl) et workflows (.hwf) du dépôt git synchronisé :

Champ	Rôle
Pipeline / Workflow	Fichier à exécuter, listé depuis le dépôt git de l'instance
Run configuration	Nom d'une configuration d'exécution existante dans les métadonnées du projet (metadata/pipeline-run-configuration ou workflow-run-configuration)
Paramètres d'exécution	Paires clé/valeur transmises au pipeline/workflow
Niveau de log	De Nothing à Rowlevel — par défaut, celui configuré côté Hop Server

Le job apparaît aussitôt dans l'historique, avec son statut (En attente, En cours, Terminé, Échoué, Annulé) mis à jour en direct. Chaque ligne permet de :

• voir le détail : aperçu graphique du pipeline/workflow, statut de chaque transform/action, et logs complets ;
• relancer avec les mêmes paramètres ;
• annuler (job actif) ou supprimer (job terminé).

Les jobs se sélectionnent aussi en masse (relancer / annuler / supprimer plusieurs à la fois).

Planifier un job périodique

La section Jobs récurrents planifiés définit des exécutions automatiques du même fichier, selon deux modes de planification :

• Intervalle : toutes les N minutes/heures/jours ;
• Cron : expression classique (minute, heure, jour du mois, mois, jour de la semaine).

Chaque planification garde son propre nom, ses paramètres et sa run configuration — indépendants du lancement manuel. Une fois créée, elle peut être activée/désactivée, modifiée, lancée immédiatement (sans attendre sa prochaine échéance) ou supprimée. La colonne Dernière exécution permet de vérifier qu'une planification tourne bien comme prévu.

Note

Contrairement au bouton Tâches planifiées de la carte d'application (voir Applications) — qui gère les tâches internes du Control Panel (nettoyage, synchronisations...) — cette planification-ci déclenche de vrais jobs Hop, exécutés par l'instance Hop Server elle-même.

Apache Iceberg (catalogue Polaris)

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle Apache Iceberg (catégorie Gouvernance) déploie un catalogue Iceberg REST — Apache Polaris — adossé à une base PostgreSQL (CloudNativePG) créée avec lui.

Champ	Rôle
Bucket S3 du warehouse (onglet Stockage, requis)	Bucket qui contiendra tables et métadonnées. Choisir un bucket du namespace remplit automatiquement endpoint, région et clés d'accès. Fixé à la création.
Endpoint S3, Région S3 (onglet Stockage)	Remplis par le sélecteur de bucket, à saisir à la main pour un S3 externe. us-east-1 par défaut pour la région. Fixés à la création.
Access Key ID, Secret Access Key (onglet Stockage)	Identifiants du bucket, eux modifiables après coup — par exemple après rotation des clés.
Nom du catalogue Iceberg	lakehouse par défaut : c'est le warehouse que Trino, Spark ou PyIceberg désignent. Fixé à la création.
Realm Polaris	POLARIS par défaut, un realm par instance. Fixé à la création.
Limite mémoire, Limite CPU (onglet Capacité)	2Gi et 1000m par défaut.
Taille du stockage PostgreSQL (onglet Capacité)	5Gi par défaut. Agrandissement seulement : un volume ne se réduit pas.

Au déploiement, deux tâches s'exécutent automatiquement : l'initialisation du realm (identifiants du principal root) puis la création du catalogue sur le bucket, avec les droits nécessaires. La carte passe en Running avant leur fin — comptez une à deux minutes de plus avant que le catalogue soit utilisable.

Identifiants du catalogue

Les moteurs s'authentifient auprès du catalogue avec le principal root, conservé dans le secret <nom>-root-principal du namespace (clés clientId, clientSecret, catalogUri, catalogName) — voir Secrets. Le catalogue ne distribue pas d'identifiants S3 temporaires (pas de STS sur le stockage objet de la plateforme) : chaque moteur utilise ses propres clés du bucket, d'où les champs S3 répétés dans les modèles Trino et JupyterHub.

L'API REST est exposée sur https://<nom>-<namespace>.<domaine>/api/catalog (réservée aux appels authentifiés — pas d'interface web).

Suppression

Supprimer le catalogue Apache Iceberg supprime sa base PostgreSQL et ses secrets, mais pas les fichiers du bucket : les tables restent lisibles par un nouveau catalogue pointant sur le même emplacement, ou se nettoient depuis la page Buckets.

Trino

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle Trino (catégorie Traitement) déploie un coordinateur et des workers Trino avec un catalogue lakehouse pré-câblé sur l'instance Apache Iceberg choisie.

Trino n'est pas une base de données : c'est un moteur SQL sans stockage. Trois rôles se partagent le travail — le catalogue Apache Iceberg sait quelles tables existent et quels fichiers les composent, le bucket S3 contient les données en Parquet, et Trino exécute le SQL en mémoire, réparti sur ses workers. D'où l'ordre de déploiement : le catalogue d'abord, Trino ensuite, dans le même namespace et sur le même bucket.

Options de déploiement

Champ	Rôle
Catalogue Apache Iceberg (Polaris) (requis)	Instance Apache Iceberg du même namespace. Fixé à la création.
Catalogue Iceberg (warehouse)	Nom du catalogue côté Polaris (lakehouse par défaut).
Bucket S3 du warehouse (onglet Stockage)	Le même bucket que celui du catalogue : sélectionnez-le pour remplir endpoint, région et clés.
Endpoint S3, Région S3, Access Key ID, Secret Access Key (onglet Stockage)	Remplis par le sélecteur de bucket, modifiables après coup — saisie manuelle pour un S3 externe. us-east-1 par défaut pour la région.
Nombre de workers (onglet Capacité)	1 par défaut.
Mémoire du coordinateur, Mémoire par worker (onglet Capacité)	3Gi chacune par défaut. Rester ≥ 3 Gi : le heap JVM est fixé à 1400M, le reste est du hors-heap — un OOM a été observé à 2 Gi sous charge.

Se connecter

La connexion se fait avec votre compte de la plateforme (OpenID Connect), et l'accès est accordé depuis Accès aux utilisateurs ou groupes voulus — voir Accès et permissions. Trois portes d'entrée :

• L'interface web, https://<nom>-<namespace>.<domaine>/ui/ : une console de supervision — requêtes en cours et passées, état du cluster. Ce n'est pas un éditeur SQL, elle ne sert pas à écrire des requêtes ;
• Un client SQL : trino --server https://… --external-authentication, qui ouvre le navigateur pour la connexion ; en JDBC avec externalAuthentication=true, pour DBeaver ou un outil de restitution tiers ;
• Un notebook JupyterHub du même namespace : la variable TRINO_HOST y est déjà renseignée (nom:8080, accès interne au namespace), de quoi brancher trino-python-client sans sortir du cluster.

Interroger le lakehouse

CREATE SCHEMA lakehouse.ventes;
CREATE TABLE lakehouse.ventes.commandes AS SELECT 1 AS id, 'test' AS libelle;
SELECT * FROM lakehouse.ventes.commandes;

Les fichiers Parquet et les métadonnées Iceberg apparaissent dans le bucket sous <schéma>/<table>-<uuid>/.

C'est le même catalogue que Spark Connect, PyIceberg et les jobs Spark : une table écrite par un traitement Spark est lisible par Trino dans la foulée, et inversement. Une seule copie des données, plusieurs moteurs — c'est tout l'intérêt du lakehouse.

Ce que Trino ne fait pas ici

• Pas de fédération de sources : un seul catalogue est configuré, lakehouse, sur l'instance Apache Iceberg choisie. Les catalogues de démonstration du chart amont (tpch, tpcds) sont retirés, et aucun connecteur vers une base applicative (PostgreSQL, MySQL…) n'est exposé dans le formulaire. Interroger une telle base depuis Trino demanderait d'ajouter un catalogue dans les valeurs du chart.
• Pas de transformation lourde et longue : pour les traitements distribués coûteux, Spark Connect pour l'interactif et les jobs Spark pour le batch.

Premier démarrage

Comptez 3 à 4 minutes avant la première requête, le temps de démarrer la JVM et de charger les plugins. La carte passe en Running avant que Trino réponde.

Suppression

Supprimer une instance Trino retire aussi son client OpenID de la plateforme.

JupyterHub

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle JupyterHub (catégorie Data science) donne à chaque utilisateur son propre serveur JupyterLab, avec un volume persistant personnel et la connexion via le compte de la plateforme. La personne qui déploie l'instance en est administratrice (/hub/admin).

Champ	Rôle
Image des notebooks, Version de l'image	Image Jupyter des serveurs utilisateurs (ds/jupyter-datastack par défaut : JupyterLab + clients Spark Connect, PyIceberg, Trino, MLflow).
CPU max par utilisateur, Mémoire max par utilisateur (onglet Capacité)	2 cœurs et 4 Gi par défaut, par serveur utilisateur.
Stockage par utilisateur (onglet Capacité)	10Gi par défaut. Volume personnel créé au premier démarrage de chaque utilisateur. Fixé à la création : le redimensionnement des volumes utilisateurs existants ne se fait pas depuis cette interface.
Catalogue Apache Iceberg, Trino, Spark Connect, MLflow (onglet Lakehouse, optionnels)	Instances du même namespace à pré-câbler dans les notebooks (variables d'environnement).
Catalogue Iceberg (warehouse) (onglet Lakehouse)	Nom du catalogue côté Polaris, lakehouse par défaut (POLARIS_WAREHOUSE).
Bucket S3 (onglet Stockage, optionnel)	Clés S3 exposées aux notebooks (AWS_*).
Endpoint S3, Région S3, Access Key ID, Secret Access Key (onglet Stockage)	Remplis par le sélecteur de bucket, modifiables après coup — saisie manuelle pour un S3 externe.

Variables disponibles dans chaque notebook quand le service correspondant est renseigné :

Variable	Contenu
POLARIS_URI, POLARIS_WAREHOUSE, POLARIS_CREDENTIAL, POLARIS_SCOPE	Catalogue Iceberg REST et identifiants clientId:clientSecret
TRINO_HOST	Coordinateur Trino (nom:8080, accès interne au namespace)
SPARK_REMOTE, MLFLOW_TRACKING_URI	Spark Connect et MLflow (si déployés)
AWS_ENDPOINT_URL, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY	Accès S3 au warehouse

Exemple avec PyIceberg :

import os
from pyiceberg.catalog.rest import RestCatalog

catalog = RestCatalog(
    "lakehouse",
    uri=os.environ["POLARIS_URI"],
    warehouse=os.environ["POLARIS_WAREHOUSE"],
    credential=os.environ["POLARIS_CREDENTIAL"],
    scope=os.environ["POLARIS_SCOPE"],
    **{"s3.endpoint": os.environ["AWS_ENDPOINT_URL"],
       "s3.access-key-id": os.environ["AWS_ACCESS_KEY_ID"],
       "s3.secret-access-key": os.environ["AWS_SECRET_ACCESS_KEY"]},
)
print(catalog.list_namespaces())

Une instance JupyterHub par namespace

Le chart ne supporte qu'un JupyterHub par namespace ; un second déploiement est refusé avec un message explicite. Les serveurs utilisateurs inactifs depuis une heure sont arrêtés automatiquement (le volume personnel est conservé).

Suppression

Supprimer une instance JupyterHub retire aussi son client OpenID de la plateforme.

Spark Connect

Spark Connect

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle Spark Connect (catégorie Traitement) déploie un serveur Apache Spark en mode local (exécuteurs dans le pod) exposé par le protocole Spark Connect : les notebooks et clients PySpark du namespace partagent une seule installation Spark, déjà configurée sur le catalogue Apache Iceberg choisi. Pas de route publique (protocole gRPC interne au namespace).

Champ	Rôle
Catalogue Apache Iceberg (Polaris) (requis)	Instance du même namespace. Fixé à la création.
Catalogue Iceberg (warehouse)	Nom du catalogue côté Polaris, lakehouse par défaut.
Version de Spark	Tag de l'image ds/spark-connect. Vide = version du chart.
Bucket S3 du warehouse (onglet Stockage)	Le même bucket que celui du catalogue : sélectionnez-le pour remplir endpoint, région et clés.
Endpoint S3, Région S3, Access Key ID, Secret Access Key (onglet Stockage)	Remplis par le sélecteur de bucket, modifiables après coup — saisie manuelle pour un S3 externe.
Cœurs Spark (local[N]) (onglet Capacité)	Nombre de threads d'exécution dans le pod, 2 par défaut ; la limite CPU du pod suit.
Mémoire Spark (driver), Limite mémoire du pod (onglet Capacité)	2g et 3Gi par défaut : garder ~1 Gi de marge entre la mémoire Spark et la limite du pod.
Exiger un jeton de connexion	Jeton partagé (spark.connect.authenticate.token), conservé dans le secret <nom>-platform. Désactivé par défaut.

Depuis un notebook JupyterHub rattaché (SPARK_REMOTE pré-rempli) ou tout client pyspark-client de la même version mineure que le serveur :

from pyspark.sql import SparkSession
spark = SparkSession.builder.remote(os.environ["SPARK_REMOTE"]).getOrCreate()
spark.sql("CREATE TABLE lakehouse.demo.t (x INT) USING iceberg")
spark.sql("SELECT * FROM lakehouse.demo.t").show()

Suppression

Supprimer une instance Spark Connect ne touche à rien d'autre ; les jobs Spark qui l'utilisent comme profil ne pourront plus être relancés tels quels.

Jobs Spark batch (Spark Operator)

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Pour les traitements Spark autonomes ou planifiés (hors session interactive Spark Connect), la page Jobs Spark de la barre latérale lance et suit des jobs batch dans le namespace courant, via le Kubeflow Spark Operator installé sur la plateforme : chaque job est une ressource Kubernetes SparkApplication du namespace (ou ScheduledSparkApplication pour une planification cron), dont l'opérateur lance le driver puis les exécuteurs en pods et nettoie à la fin. Le bouton Jobs Spark d'une carte Spark Connect ouvre la même page, filtrée sur cette instance comme profil.

Lancer un job

Nouveau job ouvre le formulaire :

Champ	Rôle
Profil	Une instance Spark Connect du namespace : le job reprend son image Spark (jars Iceberg inclus), son secret de registre et la configuration de son catalogue Apache Iceberg / S3 (catalogue par défaut de la session). Sans profil, indiquez une image Spark explicite (et son secret de registre).
Source	Le fichier principal du job : un script PySpark saisi directement, un fichier S3 (bucket du namespace + chemin de l'objet ; endpoint et clés remplis par le sélecteur de bucket), ou un fichier d'un dépôt Git Forgejo (instance, dépôt, branche, chemin — cloné avec votre jeton personnel, voir Git). Une classe principale (options avancées) bascule en job Scala/Java sur un .jar.
Nom	Identifiant Kubernetes du job (minuscules, chiffres, tirets) — proposé à partir du fichier.
Dimensionnement	Cœurs et mémoire du driver, nombre d'exécuteurs, cœurs et mémoire par exécuteur.
Options avancées	Arguments, propriétés Spark supplémentaires (spark.*), rétention de la ressource après la fin — en heures, 168 (7 jours) par défaut.

Le driver tourne avec le compte de service spark du namespace (limites CPU/mémoire posées sur chaque conteneur, comme l'exige le quota du namespace) ; les sources S3 et Git sont récupérées par un initContainer (aws s3 cp / git clone) dans un volume monté sur /opt/job, le script saisi via un ConfigMap sparkjob-<nom>. Les identifiants (catalogue, S3, Git) restent dans des Secrets du namespace, jamais dans le formulaire annoté sur la ressource.

Suivi

L'historique liste les jobs du namespace avec leur état (SUBMITTED, RUNNING, COMPLETED, FAILED…), leur source, leur profil et leur durée ; il se rafraîchit seul tant qu'un job est actif. Pour chaque job :

• Détail et logs : pods driver/exécuteurs et dernières lignes du driver, en direct tant que le job tourne ;
• Relancer à l'identique : nouvelle ressource <nom>-<suffixe> à partir du formulaire d'origine (profil ré-résolu, donc image et configuration à jour) ; Relancer avec modifications rouvre le formulaire pré-rempli ;
• Annuler (job actif) arrête driver et exécuteurs ; Supprimer (job terminé) retire la ressource et ses logs.

Les rôles habituels s'appliquent : lecture pour un viewer, lancement/annulation/suppression pour un operator, planification pour un admin du namespace.

Jobs planifiés

Planifier un job reprend le formulaire de lancement avec une expression cron (5 champs), un fuseau horaire, une politique de concurrence (interdire le chevauchement, autoriser, remplacer) et le nombre de runs conservés. Chaque planification peut être lancée immédiatement, suspendue puis réactivée, ou supprimée ; ses runs apparaissent dans l'historique avec le marqueur ⏱ du nom de la planification.

Sans l'interface

Les ressources restent manipulables avec kubectl -n <namespace> get sparkapplications : un job créé à la main apparaît dans l'historique (annulation/suppression possibles, mais pas de relance faute de formulaire d'origine). Sur un cluster sans accès à Docker Hub, les images des initContainers se surchargent dans Paramètres cluster : SPARK_JOB_GIT_IMAGE (défaut alpine/git) et SPARK_JOB_S3_IMAGE (défaut amazon/aws-cli).

Namespaces créés avant l'opérateur

Le compte de service spark est posé à la création de chaque namespace et vérifié à chaque lancement ; pour les namespaces antérieurs à l'installation de l'opérateur, l'installation le crée aussi (ou python manage.py ensure_spark_rbac côté ControlPanel).

MLflow

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle MLflow (catégorie Data science) déploie un serveur de tracking MLflow : expériences, runs et registre de modèles dans une base PostgreSQL (CloudNativePG) créée avec lui, artefacts servis par le serveur sur un bucket S3. L'accès web est protégé par le login de la plateforme (le serveur MLflow n'a pas d'authentification propre) : comme pour Apache Hop, les utilisateurs et groupes autorisés se gèrent depuis Accès.

Champ	Rôle
Version de MLflow	Tag de l'image ds/mlflow. Vide = version du chart.
Bucket S3 des artefacts, Préfixe dans le bucket (onglet Stockage, bucket requis)	Emplacement des artefacts, préfixe mlflow par défaut. Fixés à la création : les runs existants pointent dessus.
Endpoint S3, Région S3, Access Key ID, Secret Access Key (onglet Stockage)	Remplis par le sélecteur de bucket, modifiables après coup — saisie manuelle pour un S3 externe.
Processus serveur	Nombre de workers du serveur, 2 par défaut.
Limite mémoire, Limite CPU (onglet Capacité)	2Gi et 1000m par défaut.
Taille du stockage PostgreSQL (onglet Capacité)	5Gi par défaut. Agrandissement seulement : un volume ne se réduit pas.

Depuis un notebook rattaché (MLFLOW_TRACKING_URI pré-rempli, accès interne sans login) : import mlflow; mlflow.set_tracking_uri(os.environ["MLFLOW_TRACKING_URI"]); mlflow.log_metric("accuracy", 0.99). Les artefacts transitent par le serveur : les notebooks n'ont pas besoin des clés S3.

Suppression

Supprimer une instance MLflow retire aussi son client OpenID de la plateforme.

Apache NiFi

Fait partie du lakehouse (vue d'ensemble et schéma des interactions).

Le modèle Apache NiFi (catégorie Traitement) déploie NiFi 2 avec connexion par le compte de la plateforme : la personne qui déploie l'instance obtient automatiquement le droit de modifier le flow (l'administrateur initial est un compte technique de la plateforme, invisible dans NiFi) et autorise les autres comptes depuis l'interface NiFi (menu Users / Policies). Le flow et les dépôts (FlowFiles, contenu, provenance, état) sont sur un volume persistant.

Champ	Rôle
Version de NiFi	Tag de l'image apache/nifi. Vide = version du chart.
Nombre de nœuds (onglet Cluster)	1 par défaut. NiFi tourne toujours en cluster (élection de leader et état partagé nativement sur Kubernetes, Leases/ConfigMap, sans ZooKeeper), un pod et un volume par nœud. Modifiable à tout moment (voir ci-dessous).
Heap JVM, Limite mémoire, Limite CPU (onglet Capacité)	2g, 3Gi et 2 cœurs par défaut ; garder ~1 Gi de marge entre le heap et la limite mémoire.
Taille du volume (dépôts et flow) (onglet Capacité)	20Gi par défaut, par nœud. Fixé à la création : le redimensionnement d'un volume existant ne se fait pas depuis cette interface.
Catalogue Apache Iceberg (Polaris) (onglet Lakehouse, optionnel)	Pose POLARIS_URI, POLARIS_CREDENTIAL et les variables S3_* dans le pod, à référencer soi-même dans un flow : NiFi n'a pas de processeur Iceberg natif, rien n'est câblé automatiquement.

Changer le nombre de nœuds

Depuis la fenêtre de configuration de l'application (champ Nombre de nœuds, ou Réplicas) :

• Ajouter des nœuds : les nœuds en place continuent de tourner ; chaque nouveau nœud rejoint le cluster et en reçoit le flow.
• Retirer des nœuds : les nœuds à numéro le plus élevé s'arrêtent, puis le Control Panel les retire du cluster NiFi (sans quoi NiFi refuserait toute modification du flow tant qu'un nœud reste « déconnecté »). Un nœud retiré garde son volume : les données encore en file d'attente sur ce nœud reviennent si on le rajoute.
• Éteindre / Démarrer : arrête tous les nœuds, puis les redémarre au même nombre.

Après un changement du nombre de nœuds ou un redémarrage, NiFi peut demander de se reconnecter : chaque nœud signe ses propres sessions, une session ouverte sur un autre nœud n'est plus reconnue. Le flow et les données ne sont pas concernés. Juste après un démarrage, l'interface peut aussi afficher une erreur le temps que les nœuds forment le cluster (moins d'une minute en général) : rafraîchir la page.

Applications NiFi créées avant la version 2.8.70

Une application mono-nœud plus ancienne est migrée automatiquement à sa mise à jour vers un chart 0.5.0 ou plus récent (voir Mettre à jour une application), et non plus à une modification de configuration ni à un redémarrage : elle est arrêtée, son volume est cloné sous le nom attendu par le nouveau mode, puis elle redémarre avec son flow et ses données. L'ancien volume est ensuite supprimé.

TLS de bout en bout

NiFi 2 n'écoute qu'en HTTPS : un certificat interne est généré au déploiement et vérifié par la passerelle de la plateforme. Le premier démarrage prend 1 à 3 minutes (chargement des extensions).

Suppression

Supprimer une instance Apache NiFi retire aussi son client OpenID de la plateforme.

Nginx : site statique

Le modèle Nginx (catégorie DevOps) sert un site statique depuis un volume persistant, derrière une route HTTPS de la plateforme.

Champ	Rôle
Version de l'image nginx	Tag de l'image officielle, stable-alpine par défaut.
Limite mémoire, Limite CPU	Ressources du conteneur : 128Mi et 200m par défaut.
Taille du stockage, Rattacher un volume existant (onglet Capacité)	Volume des fichiers du site. Fixés à la création : le redimensionnement et le changement de volume après coup se font depuis l'onglet Volumes.
File Browser, Utilisateur admin File Browser, Mot de passe admin File Browser	Gestionnaire de fichiers web pour déposer le contenu du site sur le volume, et les identifiants pour s'y connecter. Désactivé par défaut.

Serveur SFTP

Le modèle SFTP (catégorie Storage) déploie un serveur SFTP (SFTPGo) avec son propre volume persistant. Il sert à recevoir ou à mettre à disposition des fichiers pour des partenaires, des clients ou des scripts, depuis le réseau interne ou depuis Internet.

Champ	Rôle
Taille du stockage (onglet Capacité)	Volume des fichiers déposés et de la base des comptes, 10Gi par défaut.
Rattacher un volume existant (onglet Capacité)	Réutilise le volume d'un serveur SFTP supprimé : fichiers et comptes sont retrouvés.
Limite mémoire, Limite CPU (onglet Capacité)	256Mi et 500m par défaut.
Déconnexion après inactivité	En minutes, 15 par défaut (0 = jamais).
Connexions simultanées max. par IP	20 par défaut (0 = illimité).
Protection contre la force brute	Bannit temporairement une adresse IP qui accumule les échecs de connexion. Activée par défaut.
File Browser	Consultation des fichiers déposés depuis le navigateur, derrière le login de la plateforme. Activé par défaut.

Une fois l'application démarrée, le bouton SFTP — Comptes et accès de sa carte ouvre l'administration du serveur.

Comptes SFTP

Les comptes SFTP sont propres au serveur : ce ne sont pas des utilisateurs de la plateforme, et ils n'ont pas accès au Control Panel. Les rôles de la plateforme décident seulement qui peut les gérer :

Rôle sur le namespace ou l'application	Droits
viewer	Voir les comptes, les dossiers partagés et les informations de connexion.
operator	Créer, modifier, suspendre, supprimer des comptes ; changer leurs mots de passe ; gérer les dossiers partagés.
admin	Ouvrir ou fermer l'accès depuis Internet, filtrer les adresses IP autorisées.

Chaque création, modification ou suppression est tracée dans les logs d'audit, avec l'utilisateur de la plateforme qui l'a faite — jamais les mots de passe.

Un compte comprend :

• un identifiant (2 à 32 caractères : minuscules, chiffres, ., _, -), non modifiable ;
• un mode d'authentification :
  • Clé SSH uniquement (par défaut, recommandé depuis Internet) ;
  • Mot de passe uniquement, pour les clients qui ne savent pas utiliser de clé ;
  • Clé SSH ou mot de passe ;
  • Clé SSH et mot de passe, les deux exigés à chaque connexion ;
• ses clés publiques SSH (plusieurs possibles, avec un libellé) ;
• un dossier personnel, racine de ce que le compte voit ;
• les dossiers partagés qui lui sont attribués, chacun en lecture seule ou en écriture ;
• des restrictions optionnelles : lecture seule, quota (taille, nombre de fichiers), date d'expiration, compte suspendu.

Supprimer un compte ne supprime pas ses fichiers : ils restent sur le volume, consultables dans le File Browser.

Mots de passe

Un mot de passe généré par la plateforme n'est affiché qu'une seule fois, juste après l'enregistrement : copiez-le avant de fermer le message. Il n'est stocké que sous forme hachée et ne peut pas être relu ; en cas de perte, utilisez Nouveau mot de passe sur la ligne du compte. Un mot de passe saisi doit faire au moins 12 caractères.

Clés SSH

L'utilisateur génère sa paire de clés sur son poste et ne transmet que la clé publique — la clé privée ne doit jamais quitter son poste :

ssh-keygen -t ed25519 -C "partenaire-x"
# transmettre le contenu de ~/.ssh/id_ed25519.pub

Sous Windows, ssh-keygen est fourni avec OpenSSH (PowerShell) ; avec PuTTYgen, copier la ligne « Public key for pasting into OpenSSH authorized_keys file ».

Dans la fiche du compte, collez la clé ou chargez le fichier .pub, puis Ajouter. Types acceptés : ssh-ed25519, ecdsa-sha2-nistp256/384/521, ssh-rsa (2048 bits minimum) et les clés matérielles sk-*. Une clé privée collée par erreur est refusée. L'empreinte SHA256:… affichée est celle que donne ssh-keygen -lf id_ed25519.pub : l'utilisateur peut vérifier que c'est bien sa clé.

Pour remplacer une clé sans coupure, ajoutez la nouvelle, laissez l'utilisateur la tester, puis retirez l'ancienne.

Dossiers partagés

Un dossier partagé apparaît sous /partage/<nom> chez chaque compte qui le reçoit. L'accès se règle compte par compte : un partenaire peut y déposer pendant qu'un autre compte ne fait que lire. Supprimer un dossier partagé le retire de tous les comptes ; ses fichiers restent sur le volume.

Connexion et accès depuis Internet

L'onglet Connexion donne l'hôte, le port, la commande sftp prête à copier et les empreintes du serveur. Communiquez ces empreintes aux utilisateurs : leur client les affiche à la première connexion, pour vérifier qu'il s'agit bien de ce serveur.

Par défaut, le serveur n'est joignable que depuis le cluster. Ouvrir l'accès depuis Internet (admin) lui attribue un port TCP sur la Gateway, choisi automatiquement. Les adresses IP autorisées (une IP ou plage CIDR par ligne) restreignent les sources ; vide, toute adresse que le pare-feu externe laisse passer est acceptée. Comme pour les bases PostgreSQL, le forward du pare-feu externe vers le Load Balancer du cluster reste à configurer à la main.

sftp -P <port> <identifiant>@<hôte>
sftp -i ~/.ssh/id_ed25519 -P <port> <identifiant>@<hôte>

Fichiers et File Browser

Sur le volume, les fichiers sont rangés dans files/home/<identifiant>/ (dossiers personnels) et files/shared/<nom>/ (dossiers partagés). Le File Browser de l'application montre l'ensemble à qui a accès à l'application sur la plateforme ; la base des comptes n'y apparaît pas.

Suppression

Supprimer l'application ferme l'accès depuis Internet, libère son port et retire son client OpenID. Le volume suit la règle habituelle des volumes.

Helm générique : n'importe quel chart Helm

Le modèle Helm générique déploie un chart Helm quelconque, avec ses propres values, pour essayer un logiciel avant qu'il ait un modèle dédié. Il n'apparaît au catalogue que si le réglage de cluster GENERIC_HELM_ENABLED vaut true, et il est réservé aux administrateurs du namespace.

Contrairement aux autres modèles, il ne câble ni route HTTPS, ni certificat, ni authentification : le chart est installé tel quel.

Déployer un chart

Champ	Rôle
Référence du chart	Nom du chart dans son dépôt (nginx), ou référence OCI complète (oci://registre/chemin/chart).
URL du dépôt Helm	Dépôt classique du chart (https://charts.exemple.com). Ignorée pour une référence oci://.
Version du chart	Version à installer ; la plus récente si vide.
Values Helm (YAML)	Values passées au chart, dans un éditeur YAML.

Une fois la référence (et éventuellement la version) saisie, Charger les values par défaut du chart remplit l'éditeur avec le values.yaml du chart, commentaires compris : il suffit ensuite de modifier ce qui doit l'être. Si des values sont déjà saisies, le Control Panel demande avant de les remplacer. Voir le README affiche la documentation du chart.

Si le chart fournit un schéma de values (values.schema.json, signalé par Schéma de values fourni), Helm vérifie les values au déploiement et refuse celles qui ne le respectent pas, avec le message d'erreur du chart.

Mettre à jour la release

Sur la carte de l'application, Version, values et historique ouvre la release Helm.

L'onglet Version et values affiche la version du chart et les values actuellement déployées. Les labels et annotations que le Control Panel pose pour suivre l'application n'y figurent pas : ils sont remis automatiquement à chaque mise à jour.

• Vérifier soumet la mise à jour à Helm sans rien appliquer (helm upgrade --dry-run) : schéma de values, rendu des manifestes, existence de la version.
• Mettre à jour applique la nouvelle version du chart et les nouvelles values.
• Values par défaut de cette version et README affichent, à côté de l'éditeur, ceux de la version saisie, pour comparer avant une montée de version.

Application déployée avant cette fonctionnalité

La source du chart (référence et dépôt) n'était pas enregistrée. L'onglet la demande une fois ; elle est conservée après la première mise à jour.

Historique et retour arrière

L'onglet Historique liste les révisions de la release, de la plus récente à la plus ancienne : statut, chart et version, version de l'application, date et description Helm. Values affiche celles d'une révision.

Revenir à cette révision (après confirmation) rétablit la version du chart et les values de cette révision (helm rollback). Le retour crée une nouvelle révision : l'historique est conservé, et on peut revenir à nouveau en avant de la même façon.

Lakehouse : vue d'ensemble

Six modèles du catalogue forment ensemble un lakehouse sur les buckets S3 de la plateforme : un catalogue de tables Apache Iceberg (implémenté par Apache Polaris), le moteur SQL distribué Trino, des notebooks JupyterHub, un serveur Spark Connect, un serveur de tracking MLflow et Apache NiFi pour l'ingestion. Le catalogue se déploie en premier, le reste dans l'ordre voulu, dans le même namespace.

flowchart LR
    B[(Bucket S3<br/>warehouse)]
    P[Apache Iceberg<br/>catalogue Polaris]
    T[Trino]
    J[JupyterHub]
    S[Spark Connect]
    M[MLflow]
    N[Apache NiFi]
    T -- métadonnées --> P
    J -- métadonnées --> P
    P -- fichiers metadata --> B
    T -- données Parquet --> B
    J -- données --> B
    J -- Spark Connect --> S
    S -- métadonnées --> P
    S -- données --> B
    J -- runs --> M
    M -- artefacts --> B
    N -- ingestion --> B

Applications

• Apache Iceberg (catalogue Polaris) — catalogue de tables Iceberg REST (Apache Polaris), à déployer en premier
• Trino — moteur SQL distribué
• JupyterHub — notebooks JupyterLab par utilisateur
• Spark Connect — serveur Spark partagé pour les notebooks et clients PySpark
• MLflow — tracking d'expériences et registre de modèles
• Apache NiFi — ingestion de données
• Jobs Spark batch (Spark Operator) — traitements Spark batch et planifiés (page Jobs Spark)

Exemple : chaîne de traitement datawarehouse

Cet exemple présente le flux de travail standard pour construire une chaîne de traitement de données de bout en bout sur la plateforme : un dépôt Git pour versionner le projet Apache Hop, une base PostgreSQL comme cible, Apache Hop GUI pour concevoir le pipeline, un Apache Hop Server pour l'exécuter, et une planification récurrente pour l'automatiser.

Vue d'ensemble

1. Créer un dépôt Git.
2. Créer une base de données.
3. Lancer Apache Hop GUI, avec le dépôt en paramètre.
4. Créer un pipeline dans Hop GUI.
5. Lancer un Apache Hop Server sur le même dépôt et la même branche.
6. Créer un job récurrent sur ce pipeline.
7. Surveiller le résultat.

1. Créer un dépôt Git

Depuis la page Git, section Mon compte Git, Créer un dépôt — personnel ou dans une organisation. Ce dépôt versionnera le projet Apache Hop (pipelines .hpl, workflows .hwf, connexions et métadonnées).

2. Créer une base de données

Depuis le catalogue (Nouvelle app), déployez le modèle PostgreSQL — voir Déployer une application. C'est la base cible dans laquelle le pipeline écrira les données. Notez le nom de l'application : c'est lui qui identifie la connexion PostgreSQL exposée automatiquement à Apache Hop (voir étape suivante).

3. Lancer Hop GUI avec le dépôt en paramètre

Déployez le modèle Apache Hop (GUI). Dans la section Source Git du formulaire :

• Instance Forgejo : l'instance gérée par la plateforme ;
• Dépôt : le dépôt créé à l'étape 1 ;
• Branche : laissez vide pour la branche par défaut.

Une fois l'application Running, ouvrez-la (Ouvrir) : le projet Hop est synchronisé sur ce dépôt/branche, et les connexions vers les bases PostgreSQL, serveurs Hop et buckets S3 du namespace sont provisionnées automatiquement dans les métadonnées du projet.

Tip

Si la base créée à l'étape 2 n'apparaît pas tout de suite comme connexion dans Hop, utilisez Resynchroniser les connexions Hop sur la carte de l'application (voir Applications) plutôt que d'attendre la synchronisation périodique.

4. Créer un pipeline

Dans Hop GUI, créez un nouveau pipeline (.hpl) utilisant la connexion PostgreSQL provisionnée à l'étape précédente comme cible, puis commitez-le sur le dépôt (Hop GUI intègre un client Git). Ce fichier est ce que le Hop Server exécutera aux étapes suivantes.

5. Lancer un Hop Server sur le même dépôt/branche

Déployez le modèle Apache Hop Server, avec la même configuration Source Git qu'à l'étape 3 (même instance Forgejo, même dépôt, même branche) — le Hop Server doit voir exactement le même projet, pipeline compris, que celui utilisé dans Hop GUI.

6. Créer un job récurrent sur le pipeline

Ouvrez Jobs Hop depuis la carte du Hop Server, puis, dans Jobs récurrents planifiés, créez une planification pointant vers le pipeline créé à l'étape 4 (intervalle ou expression cron) — voir Apache Hop Server : jobs et planification pour le détail des champs.

7. Surveiller le résultat

Depuis la même page Jobs Hop :

• la colonne Dernière exécution de la planification confirme qu'elle se déclenche comme prévu ;
• l'historique liste chaque exécution avec son statut (Terminé, Échoué…) — cliquez une ligne pour le détail graphique du pipeline et les logs complets ;
• le bandeau en haut de page donne une vue instantanée des jobs en cours/en attente et de la charge de l'instance.

Stockage

Volumes

La page Volumes liste les volumes persistants (PVC) du namespace courant : nom, capacité, espace utilisé, classe de stockage, statut, et les pods qui les utilisent.

La colonne Utilisé (jauge + pourcentage) vient de la supervision de la plateforme (Prometheus, métriques du kubelet) : elle n'est renseignée que pour un volume monté par un pod ; sinon, ou si la supervision est indisponible, elle affiche n/d.

Actions sur un volume

Le menu ⋮ à droite de chaque ligne regroupe toutes les actions disponibles pour ce volume :

Action	Effet
Redimensionner	Augmente la capacité (jamais de réduction — limitation Kubernetes)
Snapshot	Fige un instantané du volume à un instant T
Cloner	Crée un nouveau volume, copie indépendante de l'original
Restaurer un snapshot	Crée un nouveau volume à partir d'un snapshot existant
Supprimer	Supprime le volume — impossible s'il est encore attaché à un pod

Volumes des bases de données PostgreSQL

Les volumes d'une base PostgreSQL (application PostgreSQL, ou base embarquée dans une autre application) sont pilotés par l'opérateur CloudNativePG : Redimensionner, Cloner et Snapshot y sont grisés, et refusés par l'API même en contournant l'interface.

• Agrandir la base : passez par Configurer → Taille du stockage de l'application. L'opérateur agrandit lui-même les volumes de ses instances ; un redimensionnement fait directement ici serait réconcilié (donc annulé) par l'opérateur. La réduction reste impossible.
• Copier la base : utilisez ses sauvegardes. Un snapshot ou un clone pris sur une base en fonctionnement n'est pas garanti cohérent.

Cas d'usage : revenir en arrière après une fausse manipulation

1. Avant l'opération risquée, faites un snapshot du volume concerné.
2. En cas de problème, restaurez le snapshot vers un nouveau volume.
3. Dans Configurer → Volumes de l'application, pointez le montage vers ce nouveau volume — l'application redémarre sur les données restaurées.

Note

Les snapshots vivent dans le cluster (pas dans S3) : ils protègent contre les erreurs de manipulation, pas contre la perte du cluster. Pour une vraie sauvegarde externalisée des bases de données, voir Sauvegarde et restauration.

Buckets S3

La page Buckets gère le stockage objet S3 du namespace (servi par le cluster lui-même) : dépôts de fichiers, cibles de sauvegarde, sources de données pour Apache Hop…

Taille et compression

Chaque bucket affiche sa taille (somme des tailles de ses objets), la taille réellement stockée dans Ceph après compression, le gain de compression lorsqu'il y en a un, et son nombre d'objets. Ces valeurs viennent de l'API d'administration du stockage objet (RGW) et sont actualisées au plus toutes les minutes ; elles n'apparaissent pas si cette API n'est pas joignable. Sans compression activée côté Ceph, taille et taille stockée sont identiques.

Créer un bucket

Nouveau bucket → un nom court (lettres minuscules et chiffres). Le bucket passe par une phase de provisionnement puis devient Bound — il est alors utilisable.

Identifiants d'accès

Chaque bucket expose ses identifiants S3 (endpoint, access key, secret key) depuis sa ligne dans la liste. Ce sont ces valeurs qu'attendent :

• la section Sauvegarde de PostgreSQL et Digdash BI ;
• tout client S3 externe (rclone, AWS CLI, DBeaver…).

Clés d'accès par application

L'onglet Clés d'accès permet de créer des identités S3 supplémentaires à portée réduite (lecture seule ou lecture/écriture) à confier à une application, plutôt que de partager les identifiants principaux du bucket.

Parcourir les objets

Le contenu d'un bucket (fichiers et dossiers) se consulte directement depuis la page — utile pour vérifier qu'une sauvegarde a bien été écrite avant de lancer une restauration.

Nouveau dossier crée un dossier à l'emplacement affiché. S3 n'ayant pas de vrais dossiers (un dossier n'existe que s'il contient un objet), le Control Panel y dépose un fichier texte vide .keep ; le dossier reste visible tant que ce fichier ou un autre objet s'y trouve.

Accès et permissions

Deux notions distinctes coexistent :

• Accès Applications — qui peut utiliser une application déployée (se connecter à Digdash BI, à Hop…) ;
• Permissions Internes — qui peut administrer quoi dans le Control Panel lui-même.

Accès Applications

La page Accès Applications (ou le bouton Gérer les accès d'une carte, non disponible pour PostgreSQL) liste, pour chaque application à authentification OIDC, tous les utilisateurs de la plateforme séparés en deux sections Avec accès / Sans accès, avec recherche et sélection multiple pour agir en masse sur plusieurs utilisateurs à la fois.

Deux mécanismes selon le modèle, affichés automatiquement par la page :

• Profils (la majorité des modèles, ex. Digdash BI) : octroyer l'accès consiste à attribuer un ou plusieurs profils (rôles applicatifs) à l'utilisateur — un utilisateur sans profil n'a pas accès. Le bouton Ajouter profils ouvre la sélection, individuellement ou en masse sur la sélection courante.
• Accorder / révoquer direct (Apache Hop GUI uniquement) : un simple octroi binaire, sans notion de profil — boutons Accorder / Révoquer, également disponibles en masse.

Permissions Internes

Les rôles du Control Panel se donnent par namespace (l'utilisateur agit sur tout le namespace, depuis l'onglet Namespaces) ou par application (portée limitée à une seule application, depuis cette page). La page Permissions Internes reprend la même interface que Accès Applications (recherche, sections Avec/Sans permission, sélection multiple pour les actions en masse), mais n'affiche et ne modifie que les permissions posées directement sur l'application : les rôles hérités du namespace n'y apparaissent pas — un rappel que l'écran affiche lui-même, avec le tableau des droits ci-dessous. Toutes les applications du namespace y figurent, y compris celles sans connexion Keycloak (PostgreSQL, Apache Iceberg, Nginx, Spark Connect…), absentes de la page Accès Applications faute d'accès à y octroyer.

Rôle	Ce qu'il permet
viewer	Voir les applications, volumes, buckets du périmètre
operator	+ démarrer/arrêter/redémarrer, mettre à jour une application, configurer, resynchroniser
admin	+ déployer et supprimer, gérer les accès et permissions du périmètre

S'y ajoute le statut administrateur de plateforme, transversal : gestion des utilisateurs, des groupes, des namespaces et quotas, des paramètres cluster, de l'instance Git et de l'authentification relais.

Droit de création de namespaces

Créer un namespace ne demande plus d'être administrateur de plateforme. Le droit Création de namespaces peut être accordé :

• à un utilisateur, dans sa fiche (Utilisateurs → Modifier l'utilisateur), à sa création, ou par la colonne creation_namespaces de l'import en masse ;
• à un groupe : tous ses membres le reçoivent, tant qu'ils en font partie.

La personne qui crée un namespace en devient administrateur (admin) — de celui-là seulement. Le droit ne donne rien d'autre : ni la suppression d'un namespace, qui reste réservée à l'administrateur de plateforme, ni la gestion des groupes ou des paramètres cluster. Comme tout administrateur de namespace, elle peut créer des comptes utilisateurs, mais pas les modifier ni les supprimer. Seul un administrateur de plateforme peut l'accorder.

Dans la liste des Utilisateurs, un badge signale les titulaires du droit ; au survol, il indique s'il vient d'un groupe. Un administrateur de plateforme le possède d'office.

Groupes

Réservé aux administrateurs de plateforme.

Un groupe est un ensemble d'utilisateurs. Tout ce qui est accordé au groupe s'applique à chacun de ses membres, tant qu'il en est membre : quitter le groupe retire ce que le groupe apportait, et seulement cela.

Ce qu'un groupe peut porter

Élément	Ce que reçoivent les membres	Application
Accès à une application (et ses profils, pour Digdash BI et NiFi)	Le droit de se connecter à l'application, avec ces profils	Poussé dans Keycloak
Rôle sur un namespace	viewer, operator ou admin sur tout le namespace	Immédiat
Rôle sur une application	Un rôle limité à cette application	Immédiat
Création de namespaces	Le droit de créer des namespaces	Immédiat

Les rôles et le droit de création sont calculés à chaque action : un changement est effectif aussitôt. L'accès aux applications, lui, doit être inscrit dans Keycloak (voir Quand les changements s'appliquent).

Comment les droits se combinent

Un utilisateur peut recevoir des droits de plusieurs sources : en direct et par un ou plusieurs groupes. Rien ne s'écrase :

• Rôles : le plus élevé l'emporte. Un rôle posé sur une application prime sur le rôle du namespace qui la contient.
• Accès et profils : ils s'additionnent. Un membre de deux groupes reçoit l'union de leurs profils, plus ceux qui lui sont attribués directement. Un accès reste en place tant qu'au moins une source le justifie : retirer quelqu'un d'un groupe ne lui enlève pas un accès qu'il tient aussi en direct ou par un autre groupe.

Quand les changements s'appliquent

• Ajouter ou retirer un membre : ses accès sont mis à jour immédiatement.
• Associer ou dissocier une application, changer ses profils, supprimer le groupe : le changement est enregistré aussitôt puis appliqué à tous les membres par une tâche de fond, dont la progression s'affiche sur la page. Sur un groupe de plusieurs milliers de membres, cela prend quelques minutes. En cas d'échec partiel, le bouton Resynchroniser repousse l'accès et les profils à tous les membres.
• Réconciliation périodique : la tâche système de réconciliation rétablit dans Keycloak les accès que les groupes justifient mais qui manqueraient. Elle ne retire jamais rien — plusieurs Control Panel peuvent partager le même Keycloak, et un accès sans justification ici peut en avoir une ailleurs.

Accès applicatifs et profils

Seules les applications démarrées sont proposées à l'association : rien ne pourrait être appliqué à une application arrêtée. Pour Digdash BI et Apache NiFi, le bouton Profils d'une application associée permet de choisir les profils que le groupe confère ; les autres applications restent en accès simple.

Ce qui vient d'un groupe apparaît grisé

Sur la page Accès Applications, les profils hérités d'un groupe sont affichés grisés, avec le nom du groupe au survol, et un badge « via groupe » signale les utilisateurs concernés. Dans Modifier les profils, ils sont cochés mais non décochables : les retirer à cet endroit n'aurait aucun effet, le groupe les réattribuerait. De même, Révoquer est désactivé pour un utilisateur qui ne tient son accès que d'un groupe. Ces accès se retirent depuis la page Groupes.

Noms de groupe

Un nom de groupe est unique sans tenir compte des majuscules : « Metier » et « metier » désignent le même groupe. L'import en masse rattache donc un utilisateur au groupe existant quelle que soit la casse, et ne crée un groupe que s'il n'existe vraiment pas.

Note

Les permissions du Control Panel sont indépendantes des rôles internes de chaque application : donner operator sur un namespace n'accorde pas, par exemple, des droits d'administration dans Digdash BI lui-même.

Utilisateurs

Réservé aux administrateurs de plateforme. Un administrateur de namespace y accède aussi, pour consulter la liste, créer ou importer des comptes : sans pouvoir les rendre administrateurs de plateforme ni leur donner le droit de créer des namespaces, et sans modifier ni supprimer un compte existant.

La page Utilisateurs gère les comptes de la plateforme (créés dans Keycloak, le fournisseur d'identité d'entreprise).

Créer un utilisateur

Nouvel utilisateur → identifiant, e-mail, nom, mot de passe initial (temporaire par défaut : l'utilisateur devra le changer à sa première connexion), langue de l'interface, et éventuellement le statut administrateur de plateforme.

À la création, le compte Git personnel de l'utilisateur est provisionné automatiquement sur l'instance Forgejo de la plateforme (voir Git) — il peut donc être ajouté immédiatement comme collaborateur d'un dépôt, sans attendre sa première connexion.

Importer plusieurs utilisateurs

Importer crée un lot de comptes d'un coup, à partir d'un fichier CSV ou d'un texte saisi directement — un utilisateur par ligne. Le fichier est lu par le navigateur et versé dans la zone de texte : vous voyez et pouvez corriger ce que vous allez créer avant de valider.

Le bouton Télécharger un exemple fournit un fichier modèle prêt à remplir.

Colonnes reconnues, dans cet ordre si le fichier n'a pas de ligne d'en-tête :

Colonne	Contenu	Obligatoire
identifiant	Identifiant de connexion	oui
email	Adresse e-mail	non
prenom, nom	Nom de la personne	non
langue	fr, en ou es	non
admin	oui/non — administrateur de plateforme	non
actif	oui/non — compte activé	non
droits	namespace:role, séparés par des virgules (compta:admin,rh:viewer)	non
groupes	Noms de groupes séparés par des virgules	non
creation_namespaces	oui/non — droit de créer des namespaces, réservé à l'administrateur de plateforme	non

Un groupe cité mais inexistant est créé automatiquement et signalé comme tel dans le compte rendu — relisez-le, une faute de frappe dans cette colonne crée un groupe au lieu d'en rejoindre un.

Le séparateur (;, tabulation, , ou |) est détecté automatiquement. Si une ligne d'en-tête est présente, l'ordre des colonnes est libre et vous pouvez n'en mettre qu'une partie. Les lignes vides et celles commençant par # sont ignorées.

Comptes déjà existants

Un identifiant qui existe déjà n'est ni recréé ni modifié : mot de passe, e-mail, nom, langue, statut actif et statut administrateur restent ceux du compte. La ligne sert uniquement à compléter ses accès :

• les groupes cités sont rejoints (et créés s'ils n'existent pas) ;
• les droits namespace sont ajoutés, ou relevés si le rôle demandé est plus élevé — jamais abaissés ;
• le droit de création de namespaces est accordé s'il est demandé — jamais retiré.

La ligne apparaît alors au statut Mis à jour. Réimporter un fichier pour ajouter des personnes à un groupe est donc sans risque : aucun accès n'est retiré.

Mot de passe

Un choix unique s'applique à tout l'import :

• Généré automatiquement : un mot de passe aléatoire par compte, à changer à la première connexion. Il est affiché dans le compte rendu — la plateforme n'envoyant aucun e-mail, c'est à vous de le transmettre.
• Non défini : aucun identifiant de connexion. Réservé aux comptes qui se connecteront par un fournisseur d'identité externe.

Compte rendu

Chaque ligne du fichier a son propre statut, y compris celles qui n'ont jamais été tentées — syntaxe invalide, identifiant en double dans le fichier, autorisation refusée. Le décompte distingue les comptes créés, les comptes existants mis à jour et les échecs. Le compte rendu peut être téléchargé en CSV, et les mots de passe générés copiés en un clic.

Warning

Les mots de passe ne sont affichés qu'une fois. Copiez-les ou téléchargez le compte rendu avant de fermer la fenêtre.

Note

Une ligne dont les autorisations ne passent pas est refusée sans rien créer : jamais de compte à moitié provisionné. Affecter un groupe ou créer un administrateur demande d'être administrateur de plateforme ; accorder un droit demande d'être administrateur du namespace visé.

Modifier / désactiver / supprimer

Depuis la ligne de chaque utilisateur : édition des champs, changement de mot de passe, activation/désactivation du compte, suppression (qui retire aussi son compte Git personnel).

Actions en masse

En sélectionnant plusieurs utilisateurs :

• Activer / Désactiver les comptes sélectionnés ;
• Changer la langue de tous les comptes sélectionnés ;
• Supprimer en masse.

Le résultat détaille les succès et les échecs utilisateur par utilisateur.

Note

La langue définie ici pilote la langue des messages renvoyés par la plateforme pour cet utilisateur. Chacun peut aussi la modifier lui-même depuis Mon profil.

Git

La plateforme héberge un serveur Git interne (Forgejo), utilisé notamment comme source de projets pour Apache Hop. Deux points d'entrée :

• Git (bas de la barre latérale) : votre compte Git personnel — accessible à tous ;
• Paramètres → Git : l'administration de l'instance Forgejo elle-même — administrateurs de plateforme uniquement.

Mon compte Git

À la première visite, votre identité Forgejo est provisionnée automatiquement. La page affiche :

• le lien vers votre profil Forgejo ;
• votre jeton d'accès personnel : affichez-le pour l'utiliser dans un git clone https://utilisateur:jeton@… ou un gestionnaire d'identifiants. Régénérer ma clé en crée un nouveau si l'ancien est perdu ou compromis ;
• vos organisations et vos dépôts.

Dépôts et organisations

• Créer une organisation : un espace de regroupement de dépôts, dont vous devenez propriétaire.
• Créer un dépôt : personnel ou dans une de vos organisations, privé par défaut, initialisé avec une branche principale — immédiatement utilisable comme source Git d'une application, notamment Apache Hop.
• Collaborateurs (sur un dépôt) : ajoutez un utilisateur de la plateforme avec un niveau read, write ou admin — l'autocomplétion cherche par nom ou identifiant.
• Membres (sur une organisation) : ajoutez des membres, qui obtiennent les pleins droits sur les dépôts de l'organisation.
• Supprimer un dépôt : possible uniquement si vous l'administrez ; irréversible.

Administration de l'instance (Paramètres → Git)

L'instance Forgejo est unique pour toute la plateforme. Depuis cet onglet, un administrateur peut :

• la déployer si elle n'existe pas encore (le catalogue générique refuse toute seconde instance) ;
• la superviser et la configurer comme une application standard (ressources, redémarrage, détails).

Instance partagée

Modifier les ressources de l'instance Forgejo redémarre le service Git pour tous les utilisateurs de la plateforme — à faire en connaissance de cause.

Paramètres

Namespaces et quotas

Onglet Paramètres → Namespaces — création et suppression réservées aux administrateurs de plateforme.

Un namespace est un espace de travail isolé : ses applications, volumes et buckets sont séparés de ceux des autres namespaces, et il porte ses propres quotas et permissions.

Créer un namespace

Nouveau namespace (depuis l'en-tête du tableau de bord ou l'onglet Namespaces) → nom (lettres minuscules et chiffres), description, et quotas :

Quota	Ce qu'il plafonne
CPU requests / limits	La somme des réservations et des plafonds CPU des pods
Mémoire requests / limits	Idem pour la mémoire
Pods	Le nombre de pods simultanés
Stockage	La somme des capacités des volumes persistants

Les valeurs par défaut de la plateforme sont préremplies et ajustables à la création. CPU, mémoire et stockage se saisissent en nombre entier + unité (m/cœurs, Mi/Gi/Ti), le nombre de pods en entier.

Une case Isoler le namespace au réseau (cochée par défaut) applique immédiatement la policy réseau deny-all décrite plus bas — décochez-la pour créer un namespace ouvert ; l'isolation reste activable à tout moment par la suite depuis l'onglet Namespaces.

Suivre et ajuster les quotas

• La jauge de quota du tableau de bord montre en continu la consommation du namespace courant.
• Dans l'onglet Namespaces, le bouton quotas de chaque ligne permet d'ajuster les plafonds d'un namespace existant.
• En sélectionnant plusieurs namespaces, l'édition s'applique en masse à toute la sélection.

Tip

Un déploiement refusé pour exceeded quota indique le quota en cause et les valeurs demandées/utilisées/plafond — de quoi décider entre libérer des ressources et relever le quota.

Permissions d'un namespace

Le bouton Permissions d'une ligne accorde à un utilisateur un rôle (viewer, operator, admin) sur ce namespace — voir Accès et permissions.

Isolation réseau

Le bouton Réseau d'une ligne ouvre l'isolation réseau du namespace — deny-all par défaut une fois activée : plus aucun trafic entrant ou sortant n'est autorisé sauf les règles déclarées ci-dessous (et quelques flux techniques toujours nécessaires : DNS, accès au Gateway pour les HTTPRoute, etc.).

• Activer / désactiver l'isolation : bascule le namespace entre ouvert (comportement historique) et isolé. Les règles déclarées restent visibles et modifiables même désactivées, simplement sans effet tant que l'isolation n'est pas réactivée.
• Connexions sortantes (internet) : case cochée par défaut, qui laisse les applications du namespace joindre l'extérieur du cluster — téléchargement de paquets, appel d'API tierces. Décochée, il ne reste que les flux techniques (DNS, API Kubernetes, Forgejo, Keycloak) et les règles déclarées. L'isolation porte donc sur le trafic entre namespaces, pas sur l'accès à internet.
• Édition en masse : cochez plusieurs namespaces dans la liste puis cliquez sur Réseau dans la barre d'outils pour activer ou désactiver l'isolation, ou autoriser ou couper les connexions sortantes, sur toute la sélection d'un coup. Les namespaces pour lesquels il n'y a rien à faire (déjà dans l'état demandé, ou non isolés pour les connexions sortantes) sont ignorés et listés à la fin.
• Règles d'accès : autorise un namespace (et éventuellement une app précise de ce namespace) à joindre ce namespace sur un port donné — utile par exemple pour une réplication inter-namespace ou un accès applicatif cross-namespace légitime.
• Ports exposés : expose un Service de ce namespace sur un port TCP public via le Gateway partagé, pour un accès depuis l'extérieur du cluster. Chaque port peut être restreint à une liste d'adresses IP autorisées (IP ou plages CIDR, pré-remplie avec votre adresse actuelle à la création, modifiable ensuite via l'icône filtre) : une source hors liste est refusée par le proxy avant d'atteindre l'application. Laissée vide, toute adresse que le pare-feu externe laisse passer est acceptée. Une base PostgreSQL s'expose plutôt depuis sa propre carte (bouton Accès externe), qui choisit le port et exige TLS — voir Administration PostgreSQL.

Note

Seuls les namespaces créés après l'introduction de cette fonctionnalité peuvent être isolés — et parmi eux, l'isolation n'est effective dès la création que si la case correspondante était cochée (voir ci-dessus). Un namespace non isolé (plus ancien, ou créé sans cocher la case) affiche « non isolé » : les règles déclarées n'ont alors aucun effet côté cluster tant que l'isolation n'est pas activée.

Warning

Exposer un port (onglet Ports exposés) nécessite aussi le forward correspondant côté infrastructure, sur un éventuel pare-feu en amont — non automatisé depuis cette interface.

Supprimer un namespace

Suppression avec confirmation — détruit tout le contenu du namespace (applications, volumes, buckets). Irréversible.

Paramètres cluster

Onglet Paramètres → Paramètres cluster.

Les paramètres cluster sont des réglages textuels typés qui pilotent le comportement de la plateforme. Chaque paramètre a :

• un type (réglage cluster, licence Digdash, jeton d'API…) ;
• un nom (sa clé) et une valeur ;
• une portée : globale (namespace vide — s'applique partout, gestion réservée aux administrateurs de plateforme) ou scopée à un namespace (gérée par les admins de ce namespace, prioritaire sur la valeur globale).

Exemples de réglages reconnus

Nom	Effet
USE_DIGDASH_BETA	true pour proposer les versions BETA de Digdash dans le choix de version
DIGDASH_QA_DATABASE_TYPES	true pour afficher les moteurs de base réservés à la QA interne (MariaDB, PostgreSQL side-car) dans le formulaire Digdash BI
DIGDASH_FILEBROWSER	Valeur par défaut de l'option File Browser des déploiements Digdash
DEFAULT_DIGDASH_RAM	Mémoire par défaut proposée pour un déploiement Digdash BI
CPU_REQUEST_RATIO_<APPLICATION>	Part de la limite CPU réservée (requests), en pourcentage — ex. 20 : un Hop Web limité à 2 cœurs n'en réserve que 0,4. Un paramètre par type d'application : POSTGRES, DIGDASH_BI, HOP_WEB (ou APACHE_HOP_WEB), HOP_SERVER, FORGEJO, NGINX, ICEBERG. Appliqué au déploiement (ensuite, la réservation se règle directement dans Configurer → ressources du conteneur) ; 100 (défaut) = réservation égale à la limite.
GRAFANA_URL, PROMETHEUS_PUBLIC_URL, ALERTMANAGER_URL	URL publiques des outils de supervision (liens de la page Cluster, de la barre latérale et des cartes) — par défaut https://grafana|prometheus|alertmanager.<domaine>
PROMETHEUS_URL	Adresse du Prometheus interne interrogé pour la consommation des volumes et les alertes (par défaut le service du namespace monitoring)
SPARK_JOB_GIT_IMAGE, SPARK_JOB_S3_IMAGE	Images des initContainers qui récupèrent la source d'un job Spark (dépôt Git / objet S3) — à surcharger sur un cluster sans accès à Docker Hub
POSTGIS_DEFAULT_IMAGE	Image PostgreSQL embarquant PostGIS, utilisée quand l'option PostGIS est cochée (doit correspondre à la version majeure de l'opérateur CNPG)
CUSTOM_PORT_AUTO_RANGE	Plage (début-fin) dans laquelle un port est attribué automatiquement, notamment pour l'accès externe d'une base PostgreSQL — par défaut 30000-35000
CUSTOM_PORT_RESERVED_PORTS	Ports refusés d'office à une exposition TCP, en plus des ports réellement portés par les Gateways — par défaut 80,443,222
POSTGRES_PUBLIC_TLS_SECRET	Secret (namespace/nom) du certificat wildcard Let's Encrypt servi par les bases PostgreSQL exposées, par exemple default/pg-wildcard-tls : le client vérifie alors le serveur sans fichier de CA. Recopié dans chaque base exposée et resynchronisé chaque nuit. Vide ou none : certificat CNPG et fichier de CA à télécharger
POSTGRES_PUBLIC_DOMAIN	Domaine couvert par ce wildcard (*.<domaine>) : les bases exposées s'appellent <nom-app>-<namespace>.<domaine> — par défaut pg.<domaine de la plateforme>

Valeurs sensibles

La valeur d'un paramètre est affichée en clair à quiconque a accès à son périmètre. N'y placez un secret que si le périmètre est approprié.

Utilisation

La liste se filtre par namespace et par type ; création, édition et suppression se font directement dans le tableau. Un paramètre créé en doublon (même namespace, type et nom) est refusé.

Tâches planifiées

Onglet Paramètres → Tâches planifiées.

Les tâches planifiées exécutent automatiquement des opérations récurrentes sur la plateforme.

Types de tâches

• Tâches d'application : ciblent une application d'un namespace — redémarrer, démarrer, arrêter une application, prendre un snapshot avec rétention, mettre un job Hop en file…
• Tâches système : maintenance de la plateforme (nettoyage de base, réconciliation des applications…), réservées aux administrateurs.

Créer une tâche

Nouvelle tâche → nom, description, tâche à exécuter (choisie dans le catalogue), cible (application/namespace pour une tâche d'application), et planification :

• Intervalle : toutes les n secondes/minutes/heures/jours, avec une Heure de démarrage facultative : la tâche ne s'exécute pas avant cette date. Elle se saisit à l'heure de votre navigateur (le fuseau est affiché à côté du champ, « Fuseau : … ») et est enregistrée en UTC. Laissée vide, la première exécution a lieu un intervalle après l'enregistrement, et la liste affiche cette date (« dès le … ») ;
• Cron : minute, heure, jour du mois, mois, jour de la semaine, avec un Fuseau horaire choisi dans une liste avec recherche (celui de votre navigateur par défaut) ; sans fuseau, c'est UTC.

Une tâche peut être désactivée sans être supprimée, et exécutée immédiatement (bouton dédié) indépendamment de sa planification.

Créer ou modifier une tâche d'application nécessite le rôle admin sur le namespace de l'application ciblée.

Tâches d'application

Une tâche d'application cible une application précise — sauf Arrêter toutes les applications d'un namespace, qui cible directement un namespace entier (le champ application est alors masqué au profit d'un champ namespace).

Le nom et le namespace de l'application ciblée sont toujours déduits de l'application sélectionnée : ne jamais les saisir dans les arguments nommés.

Redémarrer / Démarrer / Arrêter l'application

Aucun argument à saisir : il suffit de choisir l'application.

Pour Démarrer l'application uniquement, le nombre de replicas peut être précisé dans Options avancées → Arguments nommés (1 par défaut) :

{ "replicas": 2 }

Warning

Ne pas ajouter release_name dans les arguments nommés : il est déjà transmis automatiquement, et le doublon fait échouer l'exécution.

Arrêter toutes les applications d'un namespace

Pas de tâche/application à choisir dans le formulaire principal : un champ Namespace dédié apparaît à la place du champ Application. Aucun argument nommé à saisir — {"namespace": "..."} est injecté automatiquement depuis ce champ.

Snapshot application (avec rétention)

Formulaire simplifié (visible sans "Options avancées") : un seul champ, Nombre de sauvegardes à conserver (entier ≥ 1, 7 par défaut). release_name/namespace sont déduits automatiquement de l'application sélectionnée — ne pas les saisir en argument nommé.

Exemple : sauvegarde automatique d'un volume

Un snapshot quotidien du volume d'une application critique : planification cron 0 2 * * *, rétention de 7 snapshots. Pour restaurer un snapshot ainsi créé, voir Volumes.

Appeler une API REST

{
  "url": "https://exemple.com/api/hook",
  "method": "POST",
  "json_body": { "clé": "valeur" },
  "headers": { "X-Custom": "valeur" },
  "auth_param": "nom_du_parametre_namespace",
  "timeout": 30
}

• url (obligatoire).
• method : GET, POST… (POST par défaut).
• json_body : corps JSON envoyé tel quel (optionnel).
• headers : en-têtes HTTP additionnels (optionnel).
• auth_param : nom d'un paramètre du namespace de l'application sélectionnée — sa valeur est lue et injectée telle quelle dans l'en-tête Authorization (ex. Bearer xxx). C'est le nom du paramètre, pas le jeton lui-même. Le namespace est imposé par l'application choisie : un namespace saisi dans les arguments est ignoré.
• timeout : secondes (30 par défaut).

Mettre un job Hop en file

{
  "queue_name": "ma-hopqueue",
  "kind": "pipeline",
  "path": "/files/projects/current/monpipeline.hpl",
  "name": "MonPipeline",
  "parameters": {},
  "run_config": "local"
}

• queue_name : nom d'une HopQueue existante de l'application Hop Server (à ne pas confondre avec le champ File d'attente/queue Celery décrit ci-dessous — deux notions distinctes).
• kind : pipeline ou workflow.
• path : chemin du fichier .hpl/.hwf, tel que renvoyé par la liste des fichiers de l'application Hop Server (préfixé /files/projects/current/).
• name : nom interne du pipeline/workflow (attribut name du fichier Hop — pas le nom de la tâche planifiée saisi en haut du formulaire).
• parameters : paramètres du pipeline/workflow (objet, optionnel).
• run_config : run configuration Hop (ex. local) — en pratique requise, l'exécution échoue sans elle côté Hop Server.

Note

Cette entrée reste un accès bas niveau. Pour planifier de vrais jobs Hop récurrents, la section dédiée Jobs récurrents planifiés de l'application Hop Server elle-même (formulaire guidé, historique par job) est le chemin recommandé — voir Apache Hop Server : jobs et planification.

Options avancées

Le bouton Options avancées du formulaire révèle des champs normalement masqués :

• Arguments nommés : paramètres de la tâche au format JSON libre — voir le détail par tâche ci-dessus. Snapshot application et Arrêter toutes les applications d'un namespace ont leur propre formulaire simplifié et n'en ont pas besoin.
• File d'attente : la queue Celery qui exécute la tâche (réglage avancé, rarement nécessaire — sans rapport avec une HopQueue).
• Arguments positionnels : équivalent des arguments nommés en liste positionnelle, pour un besoin ponctuel.

Suivi

Chaque tâche affiche sa dernière exécution et son compteur total ; son historique liste les exécutions passées avec leur statut et leur résultat, filtrable par statut.

Authentification relais

Onglet Paramètres → Authentification relais — administrateurs de plateforme uniquement.

L'authentification relais permet aux utilisateurs de se connecter à la plateforme via un fournisseur d'identité externe (le SSO de l'entreprise, un annuaire tiers…) : le Keycloak de la plateforme délègue alors l'authentification à ce fournisseur amont, en OpenID Connect ou en SAML 2.0.

Ajouter un identity provider

Ajouter un identity provider :

1. Alias : identifiant technique unique (il apparaît dans les URLs — non modifiable ensuite).
2. Protocole : OpenID Connect ou SAML 2.0 — le formulaire s'adapte.
3. Nom affiché : le libellé du bouton de connexion présenté aux utilisateurs.
4. Import depuis une URL : collez l'URL de découverte du fournisseur (…/.well-known/openid-configuration en OIDC, l'URL de métadonnées en SAML) et cliquez sur Importer — les URLs d'autorisation, de jeton, JWKS… se remplissent automatiquement.
5. Complétez le Client ID et le Client secret fournis par l'administrateur du fournisseur amont, puis Enregistrer.

Le fournisseur apparaît dans la liste ; il peut être désactivé temporairement, modifié ou supprimé à tout moment. La configuration vit directement dans Keycloak — aucune copie locale, ce que vous voyez est toujours l'état réel.

Comptes existants : liaison automatique

L'option Lier automatiquement aux comptes existants, cochée par défaut, règle le cas d'un utilisateur déjà créé dans le Control Panel (page Utilisateurs) qui se connecte pour la première fois via le SSO :

• cochée : son identité SSO est rattachée directement au compte de même email ou identifiant, sans lui demander de mot de passe. Les comptes destinés au SSO peuvent donc être créés sans mot de passe ;
• décochée : comportement Keycloak par défaut, l'écran « Un compte existe déjà » demande le mot de passe du compte existant avant de le rattacher.

Un utilisateur SSO sans compte existant voit son compte créé à sa première connexion, dans les deux cas.

Fournisseur de confiance uniquement

Avec la liaison automatique, la plateforme croit le fournisseur amont sur parole : un utilisateur capable d'y choisir librement son email ou son identifiant pourrait se connecter au compte correspondant de la plateforme. Ne la laissez active que pour un fournisseur qui garantit ces informations (annuaire d'entreprise, Entra ID, Google…).

Les fournisseurs créés avant l'arrivée de cette option restent sur le comportement Keycloak par défaut : cochez l'option en les modifiant, ou lancez python manage.py enable_idp_auto_link sur le backend pour tous les basculer.

Mappers

En dépliant la ligne d'un fournisseur, la section Mappers projette les informations reçues du fournisseur amont vers la plateforme :

• Attribut : copie une claim OIDC (ou un attribut SAML) vers un attribut du compte utilisateur — par exemple department → attribut department.
• Rôle : accorde un rôle du realm quand une claim vaut une valeur donnée — par exemple groups = "admins" → rôle platform_admin.

Côté fournisseur amont

L'administrateur du fournisseur d'identité doit enregistrer la plateforme comme client et autoriser l'URL de redirection Keycloak (https://<keycloak>/realms/<realm>/broker/<alias>/endpoint), visible dans la console Keycloak.

Exemple : se connecter avec un compte Google

Google expose un fournisseur OpenID Connect standard — pas de configuration particulière côté plateforme au-delà du flux décrit plus haut.

1. Créer les identifiants côté Google

Dans la Google Cloud Console (projet dédié ou existant) :

1. API et services → Écran de consentement OAuth : configurez-le si ce n'est pas déjà fait (nom de l'application, domaines autorisés).
2. API et services → Identifiants → Créer des identifiants → ID client OAuth, type Application Web.
3. URI de redirection autorisés : ajoutez https://<keycloak>/realms/<realm>/broker/google/endpoint (l'alias choisi à l'étape suivante — google ici — doit correspondre).
4. Notez le ID client et le code secret du client générés.

2. Configurer l'identity provider côté plateforme

Depuis Ajouter un identity provider :

1. Alias : google (doit correspondre à l'URI de redirection autorisé côté Google).
2. Protocole : OpenID Connect.
3. Nom affiché : par exemple Google.
4. Import depuis une URL : https://accounts.google.com/.well-known/openid-configuration, puis Importer — les endpoints Google (autorisation, jeton, JWKS, userinfo) se remplissent automatiquement.
5. Client ID / Client secret : les valeurs notées à l'étape précédente.
6. Enregistrer.

Le bouton Google apparaît alors sur l'écran de connexion de la plateforme.

Restreindre à un domaine Google Workspace

Pour n'autoriser que les comptes d'une organisation Google Workspace plutôt que n'importe quel compte Google, publiez l'écran de consentement OAuth en interne à l'organisation (plutôt qu'en externe) côté Google Cloud Console — la restriction se fait alors du côté de Google, avant même que l'utilisateur n'atteigne la plateforme.

Redirections d'URL

Onglet Paramètres → Redirections — administrateurs de plateforme uniquement.

Une redirection répond 301 (redirection permanente) à toute requête adressée à un nom d'hôte, vers l'URL de votre choix. Elle sert aux migrations de services, dans les deux sens :

• de l'extérieur vers le cluster : l'ancien domaine d'un service (www.client.com, par exemple) est redirigé vers l'application qui le remplace dans le cluster ;
• du cluster vers l'extérieur, ou vers une autre application : l'ancienne adresse d'une application du cluster (ancienne-app.<domaine du cluster>) est redirigée vers son nouveau service, interne ou externe.

Les navigateurs et les moteurs de recherche retiennent une redirection permanente : les liens et favoris existants continuent de fonctionner.

Créer une redirection

Nouvelle redirection :

1. Nom d'hôte redirigé : le nom seul, sans https:// ni chemin. Il ne peut plus changer ensuite : pour en changer, supprimez la redirection puis recréez-la.
2. Cible :
   • Application du cluster : choisissez le namespace, puis l'application ; l'URL cible devient la racine de l'application ;
   • URL : n'importe quelle adresse http:// ou https://, sans paramètres (?…) ni ancre (#…).
3. Conserver le chemin de la requête (coché par défaut) : https://ancienne-adresse/docs/a.pdf mène à <cible>/docs/a.pdf. Décoché, toute requête mène à l'URL cible elle-même. Les paramètres de la requête sont conservés dans les deux cas.
4. Créer.

Les adresses http:// du nom redirigé sont redirigées elles aussi.

Certificat du nom d'hôte

• Nom couvert par le certificat global de la plateforme (ancienne-app.<domaine du cluster>, le domaine du cluster lui-même ou tout autre nom de ce certificat) : aucun certificat dédié, la redirection est active en quelques secondes.
• Domaine externe : un certificat dédié est demandé à Let's Encrypt. Faites d'abord pointer le DNS du domaine vers l'adresse publique du cluster, indiquée dans la fenêtre de création : Let's Encrypt vérifie le domaine en le joignant. Le certificat est en général émis en une à deux minutes.

• Certificat fourni (option de la fenêtre, pour tout nom d'hôte) : utilisez un certificat généré hors de la plateforme (autorité interne, certificat acheté, etc.). Collez ou chargez depuis un fichier :

  • le certificat au format PEM : celui du serveur en premier, suivi des certificats intermédiaires ;
  • la clé privée au format PEM, non chiffrée.

  Le Control Panel vérifie que la clé correspond au certificat, que le certificat couvre le nom d'hôte (nom exact ou wildcard *.domaine) et qu'il n'est pas expiré. La clé n'est conservée que dans le cluster (Secret TLS), jamais dans la base du Control Panel. Le DNS du domaine doit toujours pointer vers le cluster, mais aucune vérification par Let's Encrypt n'a lieu.

Pas de renouvellement automatique

Un certificat fourni n'est pas renouvelé par la plateforme : la ligne affiche son échéance (en orange à moins de 30 jours). Avant l'échéance, ouvrez Modifier et déposez le nouveau certificat et sa clé ; laissés vides, le certificat en place est conservé.

Suivre une redirection

Chaque ligne indique :

• Domaine du cluster ou Domaine externe ;
• Chemin conservé ou Chemin remplacé ;
• Route : prêt quand la passerelle du cluster sert la redirection ; en attente juste après une création ou une modification ;
• Certificat (domaine externe) : en attente tant que Let's Encrypt n'a pas émis le certificat. Survolez le badge pour lire le détail, par exemple un DNS qui ne pointe pas encore vers le cluster. Pour un certificat fourni : prêt, ou erreur une fois expiré, avec son émetteur et son échéance.

Actualiser relit l'état depuis le cluster.

Modifier, supprimer

• Modifier : changez la cible, l'option de chemin, la description ou le certificat (passage au certificat fourni ou retour au certificat automatique, dépôt d'un nouveau certificat). La nouvelle cible s'applique en quelques secondes.
• Supprimer : le nom d'hôte cesse d'être redirigé ; son certificat dédié (émis ou fourni) est supprimé aussi.

Nom d'hôte encore utilisé

Une redirection ne peut pas être créée pour un nom d'hôte qu'une application ou une route sert encore : le message nomme l'objet concerné. Pour rediriger l'ancienne adresse d'une application, supprimez d'abord l'application.

Secrets

Onglet Paramètres → Secrets — accès réservé aux administrateurs du namespace (ou de l'application) concerné.

L'onglet Secrets liste les Secrets Kubernetes de type Opaque ou basic-auth d'un namespace (ou d'une seule application, via le filtre). Les secrets OIDC gérés par la plateforme (clients Keycloak des applications) sont exclus de la liste — ils ne sont ni listés ni consultables ici.

Consultation à la demande

La liste n'affiche que les noms des clés de chaque secret, jamais leur valeur. Cliquer sur Afficher récupère et révèle la valeur en clair d'une seule clé, à la demande — la valeur reste masquée pour toutes les autres clés tant qu'on ne clique pas dessus individuellement.

Traçabilité

Chaque consultation (Afficher) et chaque copie (Copier) déclenche son propre appel, tracé distinctement dans le journal d'audit (onglet Paramètres → Audit) — qui a vu ou copié quelle clé, et quand.

Copier une valeur

Le bouton Copier place la valeur dans le presse-papiers sans nécessairement l'afficher au préalable — utile pour coller un mot de passe ou une clé API directement dans un autre outil sans l'exposer à l'écran.

Filtrer

Un sélecteur de namespace et un sélecteur d'application permettent de restreindre la liste — un administrateur d'application (sans droit sur tout le namespace) ne voit que les secrets de ses propres applications.

Logs d'audit

L'onglet Logs d'audit (Paramètres, réservé aux administrateurs de plateforme) trace les actions mutantes effectuées par les utilisateurs — création, modification, suppression — sur les ressources gérées par le Control Panel : applications, comptes, permissions, volumes, namespaces, secrets Git, fournisseurs d'identité…

Ce qui n'est pas tracé ici

Seules les actions qui réussissent sont journalisées — une tentative refusée par une permission ou une erreur technique n'apparaît pas dans ce journal (elle reste visible dans les logs techniques généraux). La simple consultation de données (lecture) n'est en général pas tracée, à l'exception des lectures jugées sensibles : la consultation d'une clé Git personnelle (git_token.view) et la consultation ou la copie de la valeur d'un secret Kubernetes (secret.view, secret.copy — voir Secrets).

Colonnes du tableau

Colonne	Contenu
Horodatage	Date et heure de l'action, au fuseau du navigateur.
Utilisateur	Le nom d'utilisateur ayant effectué l'action — anonymous pour une action non authentifiée (normalement inexistante, ces actions nécessitant une session).
Action	Un identifiant court et stable au format ressource.verbe, par exemple app.create, user.delete, pvc.resize, git_token.regenerate — voir exemples ci-dessous.
Namespace	Le namespace concerné, quand l'action en dépend (une application, un PVC…) — vide pour les actions transverses (gestion des utilisateurs, des fournisseurs d'identité…).
Détails	Les identifiants propres à la cible de l'action (nom de l'application, du pod, du volume, du groupe…), sous forme clé=valeur, spécifiques à chaque type d'action.

Exemples d'actions

Action	Domaine
app.create, release.delete, release.scale, deployment.restart, workload.update	Cycle de vie des applications
pvc.create, pvc.resize, pvc.delete, pvc.clone, pvc.snapshot, snapshot.restore, snapshot.delete	Volumes et snapshots
app_access.grant, app_access.revoke, app_access.set_profiles, application_permission.delete	Accès aux applications
user.create, user.update, user.delete, user.bulk_update, user.bulk_delete	Comptes utilisateurs
group.member_add, group.member_remove, group.namespace_permission_add, group.namespace_permission_remove, group.delete	Groupes et permissions
namespace.create, namespace.quota_update, namespace.quota_bulk_update, namespace_permission.delete	Namespaces et quotas
git_token.view, git_token.regenerate	Clé d'accès Git personnelle
identity_provider.create, identity_provider.update, identity_provider.delete, identity_provider.mapper.create, identity_provider.mapper.update, identity_provider.mapper.delete	Authentification relais (voir Authentification relais)
secret.view, secret.copy	Consultation ou copie de la valeur d'un secret Kubernetes (voir Secrets)

Aucune valeur secrète journalisée

Un mot de passe, un token ou une clé secrète n'apparaît jamais en clair dans les détails d'une action — seul le fait qu'il ait été changé est tracé (ex. password_changed=True).

Filtrer et suivre le journal

• Utilisateur, Action, Namespace : listes déroulantes alimentées dynamiquement par les valeurs déjà vues.
• Recherche : filtre plein texte sur la colonne Détails.
• Plage de dates : restreint aux entrées dont l'horodatage est dans l'intervalle choisi.
• Nombre de lignes : volume de logs rapatriés depuis le serveur (100 à 5000).
• Live : rafraîchit automatiquement toutes les 5 secondes ; Pause fige l'affichage sans arrêter la collecte.

Bundle de logs

Le bundle de logs est un fichier unique qui rassemble les logs et l'état de la plateforme, destiné à l'équipe support DigDash : quand elle doit comprendre un incident, c'est ce fichier qu'elle demande. Il se produit depuis l'onglet Logs (Paramètres, réservé aux administrateurs de plateforme), avec le bouton Exporter le bundle de logs — sans ligne de commande ni accès au cluster.

Un fichier pour l'équipe support DigDash, et pour elle seule

Le fichier est chiffré : seule l'équipe support DigDash peut l'ouvrir. Personne d'autre ne peut en lire le contenu, pas même un administrateur de la plateforme. Il n'est donc pas exploitable autrement, et ne s'envoie qu'à elle.

Lancer un export

Exporter le bundle de logs ouvre la fenêtre Exporter un bundle de logs. Elle demande deux choses — ce que le bundle doit contenir, et sur quelle période — puis Exporter lance la collecte. Exporter reste grisé tant que rien n'est coché.

À l'ouverture, la fenêtre peut afficher Lecture du cluster : namespaces, applications et leur état… : elle interroge la plateforme pour savoir ce qui peut être coché. Sur une grande plateforme, cela peut prendre jusqu'à une minute. Si un export est déjà en cours ou prêt, son suivi s'affiche sans attendre.

Périmètre

Bloc	Ce qu'il apporte au bundle
DigDash DataStack System	L'état du cluster, le Control Panel et les namespaces système : tout ce que DigDash a livré avec la plateforme. Coché à l'ouverture ; se prend ou se laisse en entier. Le lien N namespaces système liste les namespaces concernés.
Namespaces et applications	Les namespaces gérés dans le Control Panel et leurs applications. Cocher un namespace le prend en entier ; le chevron à sa gauche déplie ses applications, pour n'en cocher que certaines. Tout sélectionner et Tout désélectionner agissent sur tous les namespaces.

Le support indique en général quoi cocher. À défaut, garder DigDash DataStack System et ajouter l'application ou le namespace touché par l'incident donne un bundle utile sans être inutilement gros.

Replié, un namespace indique combien d'applications il contient, combien sont cochées, et combien sont à l'arrêt. Déplié, chaque application porte son état :

État	Signification
En marche	Tout ce que l'application doit faire tourner est prêt.
Dégradée	Une partie de l'application n'est pas prête : démarrage en cours, pod en erreur…
À l'arrêt	L'application est arrêtée. Elle n'a aucun pod, donc aucun log : cochée, elle n'apporte au bundle que son état.

Applications ou états non affichés

Quand la liste des applications d'un namespace ne peut pas être lue, le namespace reste proposé, à prendre en entier (Applications non listées). Quand c'est leur état qui ne peut pas l'être, les applications s'affichent sans état.

Fenêtre temporelle

La Fenêtre temporelle borne ce qui est collecté : Dernière heure, 24 dernières heures (proposé à l'ouverture), 2 derniers jours, 3 derniers jours ou 7 derniers jours.

C'est un maximum. Chaque nœud ne conserve qu'un volume limité de logs par conteneur : un conteneur qui écrit beaucoup ne couvre parfois que quelques heures, quelle que soit la période demandée. Et les logs d'un pod disparaissent avec lui : après une mise à jour ou un redéploiement, ils ne remontent pas au-delà de la création du nouveau pod.

Suivre la collecte

La fenêtre affiche Collecte en cours… et l'avancement, en cibles traitées. La collecte dure de quelques secondes à une quinzaine de minutes, selon le périmètre.

• La fenêtre peut être fermée : la collecte continue sur la plateforme, et le bouton Exporter le bundle de logs en retrouve le suivi.
• Annuler l'export arrête la collecte ; rien n'est conservé.
• Un seul export à la fois sur la plateforme. Si un autre administrateur en a lancé un, la fenêtre en affiche le suivi à la place du formulaire.

Télécharger le bundle

La collecte terminée, la fenêtre affiche Le bundle est prêt. avec :

Élément	Contenu
Fichier	Le nom du fichier, de la forme ds-bundle-<plateforme>-<date>-k<clé>.zip.age : la plateforme d'origine, le début de la collecte (heure UTC) et la clé de chiffrement utilisée, celle que la fenêtre affiche avant l'export (Clé de chiffrement).
Taille	La taille du fichier chiffré.
Empreinte SHA-256	L'empreinte du fichier, qui permet de vérifier qu'il n'a pas été altéré.
N fichiers · N valeurs masquées	Le nombre de fichiers du bundle et le nombre de valeurs sensibles masquées (voir Ce que contient le bundle).
Disponible jusqu'au…	L'heure à laquelle le bundle sera supprimé de la plateforme : une heure après sa production.

Télécharger remet le fichier au navigateur, qui le contrôle d'après son empreinte avant de l'enregistrer dans les téléchargements.

Message	Ce qu'il s'est passé	Que faire
Bundle téléchargé et vérifié.	Le fichier est intact, et il a été supprimé de la plateforme.	S'il n'apparaît pas dans les téléchargements du navigateur, Enregistrer à nouveau avant de fermer la fenêtre : une fois fermée, il faut relancer un export.
Bundle téléchargé. Ce navigateur n'a pas pu vérifier son intégrité…	Le fichier est enregistré, mais le navigateur n'a pas pu le contrôler — c'est le cas quand le Control Panel est ouvert en HTTP et non en HTTPS. Le bundle reste sur la plateforme, une heure au plus.	Comparer l'empreinte affichée à celle du fichier reçu (sha256sum sous Linux, shasum -a 256 sous macOS, Get-FileHash sous Windows), puis Supprimer de la plateforme.
Le fichier reçu ne correspond pas à l'empreinte annoncée et n'a pas été enregistré…	Le fichier reçu n'est pas celui que la plateforme a produit : le transfert l'a altéré. Le bundle est toujours sur la plateforme.	Relancer Télécharger.

Rien ne reste sur la plateforme

Le bundle est supprimé dès qu'il a été téléchargé et vérifié, et dans tous les cas une heure après sa production. Tant qu'il est là, la fenêtre l'affiche à tout administrateur de plateforme ; pour lancer un autre export, il faut d'abord le télécharger ou l'effacer avec Supprimer ce bundle.

Transmettre le fichier au support

Le fichier .zip.age s'envoie tel quel à l'équipe support DigDash, par le canal de support habituel. Mieux vaut ne pas le renommer : son nom dit au support de quelle plateforme il vient et quelle clé l'ouvre.

Ce que contient le bundle

Périmètre	Contenu
DigDash DataStack System	État des nœuds, journal de leur kubelet et de leur moteur de conteneurs ; événements du cluster ; alertes actives, alertes qui ont sonné pendant la période et règles d'alerte en erreur ; versions installées ; version, canal de mise à jour et état de la licence du Control Panel, son journal d'audit, le résultat de ses tâches sur la période (une ligne par résultat distinct, avec son nombre d'occurrences), ses dernières mises à jour ; événements, description et logs des pods des namespaces système.
Un namespace ou une application	Événements et alertes du namespace ; pour chaque application, sa release Helm (nom, chart, version, statut), l'état de ses composants (réplicas, bases de données, dernier arrêt ou démarrage demandé), la description et les logs de ses pods — y compris ceux du conteneur précédent après un redémarrage — et les requêtes que la passerelle a reçues pour elle, y compris celles qu'elle n'a pu transmettre à aucune route.

N'entrent jamais dans le bundle : les secrets Kubernetes, les valeurs de configuration des applications (values Helm, contenu des ConfigMap, valeurs des variables d'environnement — seul le nom des variables est gardé), le kubeconfig, le contenu de la licence.

Dans tout le bundle, les valeurs reconnues comme sensibles sont remplacées par [REDACTED] : mots de passe, jetons, clés d'accès, en-têtes d'authentification et cookies, identifiants d'une URL, clés privées. Leur nombre est affiché avec le bundle prêt (valeurs masquées).

Le masquage est une précaution, pas une garantie

Les logs sont repris tels que les applications les ont écrits : ils peuvent contenir des données métier (noms, identifiants, requêtes). C'est la raison pour laquelle le fichier est chiffré et destiné à la seule équipe support DigDash.

Si l'export n'aboutit pas

Ce qui s'affiche	Cause	Que faire
Bouton grisé et Export indisponible : aucune clé de chiffrement n'est configurée sur cette plateforme…	La clé de chiffrement du support n'a pas été installée avec la plateforme.	Contacter le support DigDash : la clé se pose à l'installation de l'infrastructure, pas depuis le Control Panel.
Impossible de lire le périmètre exportable.	La plateforme n'a pas pu interroger le cluster.	Réessayer.
L'export a échoué.	La collecte s'est interrompue — le message technique est affiché — ou elle est restée cinq minutes sans avancer.	Nouvel export. Si l'échec se répète, réduire le périmètre et transmettre le message au support.
Cet export n'existe plus : il a été abandonné ou a expiré.	L'export a été annulé pendant la collecte, depuis une autre fenêtre ou par un autre administrateur.	Relancer un export.

Traçabilité

Chaque export et chaque téléchargement sont inscrits dans les logs d'audit, avec leur auteur : actions log_bundle.export et log_bundle.download.