📦 Kubernetes Installed Packages

Muppy facilite le déploiement de packages Helm dans les clusters Kubernetes via une interface graphique intuitive. Elle permet aux utilisateurs de gérer l’ensemble de leurs packages directement depuis l’interface Muppy.

🧩 Muppy Meta Package (m2p)

Muppy propose également l’utilisation des Muppy Meta Packages (m2p).
Un m2p est un outil qui simplifie le déploiement d'applications complexes sur Kubernetes en regroupant plusieurs conteneurs Docker et leurs configurations dans un seul paquet, appelé metapackage.

Ce metapackage est composé de parts, des sous-composants modulaires représentant des services, leurs dépendances et paramètres. Grâce à cette structure, même les utilisateurs ayant peu d’expérience avec Kubernetes peuvent déployer des applications avancées de manière fluide et rapide.

---

🧱 Composants d’un déploiement

Le déploiement d’un package repose sur les éléments suivants :

• 📦 K8s Package : définition du package à déployer (Helm chart ou fichiers Kubernetes appliqués avec kubectl)
  → Pour Helm, il inclut les valeurs par défaut (values.yaml)

• 🧾 K8s Package Profile : dans le cas des metapackages, les profils définissent :

• Les parts qui composent le package
• Les ressources (limites, réplicas) par défaut
• Les dashboards pour la configuration

• Les versions disponibles et les stratégies de montée en version

• 📍 Installed Package : une instance d’un K8s Package déployée dans un cluster Kubernetes, avec les paramètres définis dans un K8s Package Profile

• 📚 Config Journal : journal des opérations Helm effectuées sur un package (historique des déploiements, upgrades, diffs, etc.)

---

🔄 Cycle de vie d’un package

• 🆕 Création (à documenter)
• 🛠️ Installation / Modification
• ✏️ Édition (Update)
• 🚀 Upgrade (montée de version)
• ❌ Suppression (à documenter)

---

✏️ Modification

Deux types de modifications sont possibles :

1. Édition / Update

Modifications gérées directement par Helm :

• Changements dans les values
• Configurations des parts
• Réglages réseaux ou dashboards

Muppy détecte automatiquement les écarts entre la configuration actuelle et celle souhaitée et affiche l’indicateur "Drifted values".

Ces modifications sont appliquées lors du prochain helm upgrade.

Chaque helm upgrade est historisé dans le Config Journal, avec : - Les valeurs utilisées - Le diff par rapport à la version précédente

---

2. 🚀 Package Upgrade

Pour les cas où une mise à jour impacte les bases de données ou nécessite l’arrêt de l’application, Muppy propose un mécanisme avancé de montée de version : Package Release Upgrade.

Disponible via :

• 🧙 Wizard “Package Release Upgrade”
• ⚙️ API CI/CD

Basé sur la gestion de version SEMVER, il permet :

• D’identifier les profils de version
• D’exécuter des scripts de migration
• D’appliquer les changements en toute sécurité

📘 Profils de version

Un profil contient :

• 🔧 Définition des parts
• 📊 Dashboards associés
• 🧪 Script de migration (si nécessaire)
• 📋 Critères d’application

---

🧙‍♂️ Fonctionnement du Package Release Upgrade

Contrairement à un helm upgrade classique, le wizard d’upgrade de version attend :

• 🎯 K8s Profile à appliquer
• ♻️ Reload Values (booléen) : recharge les valeurs par défaut depuis le profil
• 🧹 Reset Values Overload (booléen) : réinitialise ou fusionne les valeurs personnalisées

🔁 Étapes détaillées de l’upgrade

Si le profil à déployer est différent de celui actuellement en place, le processus de montée de version suit les étapes suivantes :

1. ✅ Changement de profil
   Le nouveau K8s Package Profile est affecté à l’instance.

2. ⚙️ Exécution de onchange__k8s_package_profile_id()
   Cette méthode effectue les actions suivantes :

   • Appel à reload_mpy_meta_config_yaml() pour recharger la configuration des parts :

     • Depuis le profil, ou
     • À défaut, depuis le package

   • Mise à jour des champs :

     • default_path
     • default_path_debug
     • healthcheck_path
     • fqdn_hostname_smart_config_id (si présent dans le nouveau profil)

3. 🧩 Application des dashboards
   Les dashboards définis dans le nouveau profil sont mis en place.

   ⚠️ Préservation des valeurs existantes
   Les valeurs saisies précédemment dans les dashboards sont préservées par défaut.

4. ♻️ Reload Values (si activé)

   • Recharge les valeurs du dashboard depuis le profil
   • Recharge le contenu du fichier values depuis le package

5. 🧹 Reset Values Overload (si activé)

   • Si activé : la section Values Overload est remplacée par les nouvelles valeurs
   • Sinon : les nouvelles valeurs sont fusionnées avec les valeurs existantes

6. 🧬 Calcul des valeurs finales
   Le résultat combiné (valeurs par défaut + overloads) est injecté dans Final Values

7. 🚀 Déploiement
   Exécution de la commande helm upgrade avec les Final Values

---

❌ Suppression

À documenter ultérieurement