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.