Skip to content

📦 Kubernetes Installed Packages

Muppy makes deploying Helm packages into Kubernetes clusters straightforward, through an intuitive graphical interface. Users manage all of their packages directly from the Muppy interface.

🧩 Muppy Meta Package (m2p)

Muppy also offers the Muppy Meta Packages (m2p).
An m2p is a tool that simplifies deploying complex applications on Kubernetes, by grouping several Docker containers and their configuration into a single package, called a metapackage.

That metapackage is made of parts — modular sub-components representing services, their dependencies and their parameters. Thanks to this structure, even users with little Kubernetes experience can deploy advanced applications smoothly and quickly.

🧱 The components of a deployment

Deploying a package relies on the following elements:

  • 📦 K8s Package: the definition of the package to deploy (a Helm chart, or Kubernetes files applied with kubectl)
    → for Helm, it includes the default values (values.yaml)

  • 🧾 K8s Package Profile: for metapackages, the profiles define:

  • the parts the package is made of
  • the default resources (limits, replicas)
  • the dashboards used for configuration

  • the available versions and the upgrade strategies

  • 📍 Installed Package: an instance of a K8s Package deployed in a Kubernetes cluster, with the parameters defined in a K8s Package Profile

  • 📚 Config Journal: the log of the Helm operations performed on a package (deployment history, upgrades, diffs, …)

🔄 A package's life cycle

  • 🆕 Creation (to be documented)
  • 🛠️ Installation / Modification
  • ✏️ Edit (Update)
  • 🚀 Upgrade (version bump)
  • ❌ Deletion (to be documented)

✏️ Modification

Two kinds of modification are possible:

1. Edit / Update

Changes handled directly by Helm:

  • changes to the values
  • part configuration
  • network or dashboard settings

Muppy automatically detects the differences between the current configuration and the desired one, and displays the "Drifted values" indicator.

These changes are applied on the next helm upgrade.

Every helm upgrade is recorded in the Config Journal, with: - the values used - the diff against the previous version

2. 🚀 Package Upgrade

For the cases where an update affects the databases, or requires stopping the application, Muppy offers an advanced version-bump mechanism: Package Release Upgrade.

Available through:

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

Based on SEMVER version management, it can:

  • identify the version profiles
  • run migration scripts
  • apply the changes safely

📘 Version profiles

A profile holds:

  • 🔧 the definition of the parts
  • 📊 the associated dashboards
  • 🧪 a migration script (if needed)
  • 📋 the criteria for applying it

🧙‍♂️ How the Package Release Upgrade works

Unlike a plain helm upgrade, the version upgrade wizard expects:

  • 🎯 the K8s Profile to apply
  • ♻️ Reload Values (boolean): reload the default values from the profile
  • 🧹 Reset Values Overload (boolean): reset, or merge, the customised values

🔁 The upgrade, step by step

If the profile to deploy differs from the one currently in place, the version bump follows these steps:

  1. ✅ Profile change
    The new K8s Package Profile is assigned to the instance.

  2. ⚙️ Execution of onchange__k8s_package_profile_id()
    This method does the following:

    • calls reload_mpy_meta_config_yaml() to reload the parts configuration:

      • from the profile, or
      • failing that, from the package

    • updates the fields:

      • default_path
      • default_path_debug
      • healthcheck_path
      • fqdn_hostname_smart_config_id (if present in the new profile)

  3. 🧩 Applying the dashboards
    The dashboards defined in the new profile are put in place.

    ⚠️ Existing values are preserved
    The values previously entered in the dashboards are preserved by default.

  4. ♻️ Reload Values (if enabled)

    • reloads the dashboard's values from the profile
    • reloads the content of the values file from the package

  5. 🧹 Reset Values Overload (if enabled)

    • if enabled: the Values Overload section is replaced by the new values
    • otherwise: the new values are merged with the existing ones

  6. 🧬 Computing the final values
    The combined result (default values + overloads) is injected into Final Values.

  7. 🚀 Deployment
    The helm upgrade command runs with the Final Values.

❌ Deletion

To be documented later