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.