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.
• 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 template — 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 template (Digdash BI est le plus long).

Pour le détail des champs de chaque template : 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).

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.

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 templates disponibles, par catégorie :

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

Les templates 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 template 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 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.

Actions disponibles

Selon le template 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)
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 templates

• 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 template 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 template a des valeurs par défaut raisonnables ; réduisez-les si le quota du namespace est serré.

Les champs varient ensuite selon le template : 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 templates (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).

  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 template (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 revenir Running.

Sauvegarde et restauration

Les bases PostgreSQL — qu'il s'agisse du template 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 template 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 template 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.

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.

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.

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

Lakehouse : Apache Iceberg, Trino et JupyterHub

Six templates 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

Apache Iceberg (catalogue Polaris)

Le template 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.
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 / CPU, Taille du stockage PostgreSQL	Capacité du serveur et de sa base.

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 templates 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).

Trino

Le template 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.

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.
Nombre de workers, Mémoire du coordinateur / par worker	Capacité. La mémoire d'un pod doit rester ≥ 3 Gi (heap JVM fixée à 1,4 Go, plus le hors-heap).

La connexion se fait avec votre compte de la plateforme (OpenID Connect) : l'interface web https://<nom>-<namespace>.<domaine>/ui/ comme les clients SQL (trino --server https://… --external-authentication, JDBC avec externalAuthentication=true). Comme pour Apache Hop, l'accès est accordé depuis Accès aux utilisateurs ou groupes voulus — voir Accès et permissions.

Exemple, une fois connecté :

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

JupyterHub

Le template 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	Image Jupyter des serveurs utilisateurs (ds/jupyter-datastack par défaut : JupyterLab + clients Spark Connect, PyIceberg, Trino, MLflow).
CPU / Mémoire max par utilisateur, Stockage par utilisateur	Capacité de chaque serveur ; le volume est créé au premier démarrage.
Catalogue Apache Iceberg, Trino, Spark Connect, MLflow (onglet Lakehouse, optionnels)	Instances du même namespace à pré-câbler dans les notebooks (variables d'environnement).
Bucket S3 (onglet Stockage, optionnel)	Clés S3 exposées aux notebooks (AWS_*).

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

Spark Connect

Le template 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 ; catalogue Spark par défaut lakehouse. Fixé à la création.
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.
Cœurs Spark, Mémoire Spark (driver), Limite mémoire du pod	Capacité (local[N]) ; 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()

MLflow

Le template 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
Bucket S3 des artefacts (onglet Stockage, requis)	Bucket (et préfixe, mlflow par défaut) des artefacts. Fixé à la création.
Processus serveur	Nombre de workers du serveur.
Limite mémoire / CPU, Taille du stockage PostgreSQL	Capacité.

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.

Apache NiFi

Le template Apache NiFi (catégorie Traitement) déploie un nœud NiFi 2 (sans ZooKeeper) avec connexion par le compte de la plateforme : la personne qui déploie l'instance est l'administrateur initial 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
Heap JVM, Limite mémoire / CPU	Capacité ; garder ~1 Gi de marge entre le heap et la limite.
Taille du volume	Dépôts et flow. Fixé à la création.

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

Jobs Spark batch (Spark Operator)

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

Suppression

Supprimer une instance Trino, JupyterHub, MLflow ou NiFi retire aussi son client OpenID de la plateforme ; supprimer Spark Connect ne touche à rien d'autre. 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.

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

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…

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.

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, les utilisateurs autorisés — individuellement ou en masse.

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

• Profils (la majorité des templates, 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.
• Accorder / révoquer direct (Apache Hop GUI uniquement) : un simple octroi binaire, sans notion de profil — boutons Accorder / Révoquer.

Permissions Internes

Les rôles du Control Panel se donnent par namespace (l'utilisateur agit sur tout le namespace) ou par application (portée limitée à une seule application) :

Rôle	Ce qu'il permet
viewer	Voir les applications, volumes, buckets du périmètre
operator	+ démarrer/arrêter/redémarrer, 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 namespaces et quotas, des paramètres cluster, de l'instance Git et de l'authentification relais.

Groupes

Les groupes permettent d'accorder en une fois un ensemble d'accès applicatifs et de permissions à plusieurs utilisateurs. Un groupe porte ses membres, ses octrois d'accès et ses permissions par namespace ou application.

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.

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.

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

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

Note

Seuls les namespaces créés après l'introduction de cette fonctionnalité peuvent être isolés. Un namespace plus ancien affiche « non isolé » : les règles déclarées n'ont alors aucun effet côté cluster.

Warning

Exposer un port (onglet Ports exposés) nécessite aussi le forward pare-feu correspondant côté infrastructure (OPNsense) — 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
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

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, 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 ;
• Cron : minute, heure, jour du mois, mois, jour de la semaine, avec fuseau horaire.

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.

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.

Exemple courant

Un snapshot quotidien du volume d'une application critique : tâche Snapshot application (avec rétention), planification cron 0 2 * * *, rétention de 7 snapshots.

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.

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.

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.