Dépendances et bibliothèques

Pourquoi

Un chart seul suffit tant qu'il décrit une seule application. Dès qu'il en faut deux qui vont ensemble, ou que plusieurs applications partagent les mêmes conventions, la question de la composition se pose. Helm y répond par les dépendances : un chart en déclare d'autres, qui sont récupérées, empaquetées avec lui, et rendues dans la même release.

Deux usages très différents se cachent derrière ce mot, et les confondre est la source de la plupart des mauvaises surprises.

Le premier est l'assemblage d'un produit : un chart parent regroupe quelques composants qui se déploient toujours ensemble (une application et son exporteur de métriques, par exemple). Le sous-chart est un morceau d'application, rendu dans la même release, et son cycle de vie suit celui du parent.

Le second est le partage de code : plusieurs charts de Lyneko ont les mêmes étiquettes, les mêmes noms, la même forme de bloc image ou de resources. Recopier ces modèles dans chaque chart, c'est les voir diverger. Un chart de bibliothèque les porte en un seul endroit, et les autres charts s'en servent sans rien en déployer.

Il existe un troisième usage, tentant et presque toujours mauvais : embarquer une base de données comme sous-chart de l'application. Cette leçon explique pourquoi, et ce que Lyneko fait à la place.

Les démonstrations utilisent des charts locaux (dépendances file://), qui se rendent sans cluster ni registre. Le mécanisme est le même pour une dépendance distante, hébergée dans un registre OCI ; la leçon 9 montre comment un chart s'y publie.

Les concepts

Déclarer une dépendance

Les dépendances se déclarent dans la section dependencies du Chart.yaml (chart d'API v2, le format de Helm 3 et 4) :

dependencies:
  - name: lyneko-commons
    version: 0.2.x
    repository: file://../lyneko-commons
  - name: metriques
    version: ~1.4.0
    repository: file://../metriques
    condition: metriques.enabled
    alias: metriques
    import-values:
      - child: exporte
        parent: imports

Chaque entrée comporte :

• name : le nom du chart dépendant, tel qu'il est dans son propre Chart.yaml ;
• version : une contrainte de version sémantique, pas une version exacte. 0.2.x, ~1.4.0 (de 1.4.0 inclus à 1.5.0 exclu), ^1.2.0 (de 1.2.0 inclus à 2.0.0 exclu), >=1.2.0 <2.0.0 sont acceptés. La résolution choisit la plus récente version qui satisfait la contrainte ;
• repository : où trouver le chart. C'est l'adresse d'un dépôt HTTP (https://...), un registre OCI (oci://rg.fr-par.scw.cloud/<espace>/charts, sans le nom du chart), un chemin file:// relatif au chart, ou un alias @nom défini dans votre configuration locale. Un chart déjà placé à la main dans charts/ peut omettre le champ ;
• condition : un chemin YAML vers un booléen dans les valeurs. S'il vaut false, le sous-chart n'est pas rendu ;
• tags : une liste d'étiquettes, activées ou désactivées en groupe par la table tags des valeurs ;
• alias : un nom de remplacement pour l'instance. Il permet d'inclure plusieurs fois le même chart, sous des noms différents, avec des valeurs différentes ;
• import-values : remonte des valeurs du sous-chart dans celles du parent.

Condition et tags

Une dépendance désactivée ne produit aucun objet. condition est précis : un chemin vers un booléen, et c'est tout. tags est collectif : une dépendance qui porte tags: [observabilite] est activée si tags.observabilite est true dans les valeurs. Les règles de priorité, d'après la documentation de Helm, sont strictes : une condition présente dans les valeurs l'emporte toujours sur les tags ; si plusieurs chemins sont listés dans une condition (séparés par des virgules), seul le premier qui existe dans les valeurs compte ; et pour les tags, l'activation est un OU (une seule étiquette vraie suffit). Si ni condition ni tag n'est renseigné dans les valeurs, le sous-chart est activé.

Chart.lock

Les contraintes de version laissent de la liberté : ~1.4.0 accepte 1.4.0, 1.4.1, 1.4.7. Sans rien d'autre, deux personnes qui récupèrent les dépendances à une semaine d'écart n'obtiennent pas le même résultat. Le fichier Chart.lock résout ce problème : il enregistre la version exacte retenue pour chaque dépendance, et une empreinte de la section dependencies du Chart.yaml. Il se versionne dans Git, avec le chart.

update et build

Deux commandes alimentent le répertoire charts/ :

• helm dependency update (alias helm dep up) lit Chart.yaml, résout les contraintes, télécharge les archives .tgz dans charts/, et réécrit Chart.lock. C'est la commande « je choisis de nouvelles versions ».
• helm dependency build lit Chart.lock et télécharge exactement ce qu'il enregistre, sans résoudre de nouveau. C'est la commande « je reproduis ». Si Chart.lock ne correspond plus à Chart.yaml, elle échoue.

En CI, c'est build qu'on lance : on veut le même résultat que sur le poste de la personne qui a validé le chart.

Sous-charts et valeurs

Un sous-chart est un chart complet : il a ses propres valeurs par défaut, et ses propres modèles. Mais il ne voit pas les valeurs de son parent. Trois canaux les relient :

1. Les valeurs du parent sous la clé du sous-chart. Si le sous-chart s'appelle metriques (ou porte l'alias metriques), tout ce que le parent écrit sous metriques: devient les valeurs du sous-chart, qui y lit .Values.port, pas .Values.metriques.port. Les valeurs du parent écrasent celles du sous-chart.
2. La table global. Elle est visible partout sous .Values.global, parent et enfants. C'est le seul canal qui descend sans porter le nom du sous-chart.
3. import-values. Dans l'autre sens : le sous-chart exporte des valeurs que le parent importe, par exemple un port, un nom de service ou un préfixe, pour que le parent n'ait pas à les redéclarer.

Le sous-chart ne peut jamais lire une valeur du parent hors de ces canaux. C'est une qualité : sa dépendance est explicite.

Les charts de bibliothèque

Un chart de bibliothèque est un chart dont le Chart.yaml déclare type: library. Il ne produit aucun objet : on ne peut pas l'installer, et ses fichiers de templates/ ne sont censés contenir que des modèles nommés (par convention dans des fichiers commençant par _). Il sert uniquement à fournir des fonctions d'aide à d'autres charts, qui le déclarent comme une dépendance et appellent ses modèles avec include.

Chez Lyneko, la bibliothèque lyneko-commons porte ce qui est commun à toutes les applications : les étiquettes de la leçon 6, la forme du bloc resources, le nom complet, le securityContext par défaut, les annotations de facturation. Chaque chart applicatif les appelle et se concentre sur ce qui lui est propre.

Quand ne pas utiliser un sous-chart

La règle qui se dégage : un sous-chart doit avoir le même cycle de vie que son parent. Il est installé avec lui, mis à jour avec lui, supprimé avec lui. Une base de données n'a presque jamais ce cycle de vie : elle survit à l'application, ses données valent plus que ses manifestes, et sa mise à jour demande un soin (sauvegarde, compatibilité de version, fenêtre de maintenance) que l'on ne veut pas lier au déploiement de l'application. On y revient en détail dans « Pièges courants » et « En production ».

En pratique

Le dépôt d'essai contient trois charts voisins : une bibliothèque lyneko-commons, un chart metriques, et un chart applicatif app qui dépend des deux. Ils sont minimalistes à dessein : l'objet de la leçon est la composition.

La bibliothèque

# lyneko-commons/Chart.yaml
apiVersion: v2
name: lyneko-commons
description: Modèles partagés des charts Lyneko
type: library
version: 0.2.0

{{- /* lyneko-commons/templates/_labels.tpl */ -}}
{{- define "lyneko-commons.labels" -}}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/part-of: lyneko
{{- end -}}

Le sous-chart et le chart applicatif

Le chart metriques a deux valeurs, et lit une valeur globale :

# metriques/values.yaml
port: 9100
exporte:
  prefixe: demo

# metriques/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
data:
  port: {{ .Values.port | quote }}
  global-env: {{ .Values.global.environnement | default "?" | quote }}

Le chart app déclare les deux dépendances (le Chart.yaml donné plus haut), des valeurs, et un modèle qui utilise la bibliothèque et la valeur importée :

# app/values.yaml
global:
  environnement: recette
metriques:
  enabled: true
  port: 9200

# app/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-app
  labels:
    {{- include "lyneko-commons.labels" . | nindent 4 }}
data:
  prefixe: {{ .Values.imports.prefixe | quote }}

Avant de récupérer les dépendances

Tout de suite après la création, le rendu échoue, et le message dit quoi faire :

$ helm template r app
Error: An error occurred while checking for chart dependencies. You may need to run `helm dependency build` to fetch missing dependencies: found in Chart.yaml, but missing in charts/ directory: lyneko-commons, metriques

helm dependency update

$ cd app
$ helm dependency update
Saving 2 charts
Deleting outdated charts
$ ls charts
lyneko-commons-0.2.0.tgz
metriques-1.4.1.tgz
$ cat Chart.lock
dependencies:
- name: lyneko-commons
  repository: file://../lyneko-commons
  version: 0.2.0
- name: metriques
  repository: file://../metriques
  version: 1.4.1
digest: sha256:747d8ac2d5da025976b5964006c7999e3b0b400edefaf400ad1042cf0f9ce7cd
generated: "2026-10-05T17:16:19.038120378+02:00"

Les contraintes 0.2.x et ~1.4.0 ont été résolues en 0.2.0 et 1.4.1, les seules versions disponibles. Le répertoire charts/ contient les archives. Le digest est l'empreinte de la section dependencies de Chart.yaml : si vous modifiez une contrainte, il ne correspond plus.

Le rendu

$ helm template r .
---
# Source: app/charts/metriques/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: r-metriques
data:
  port: "9200"
  global-env: "recette"
---
# Source: app/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: r-app
  labels:
    app.kubernetes.io/name: app
    app.kubernetes.io/instance: r
    app.kubernetes.io/part-of: lyneko
data:
  prefixe: "demo"

Quatre choses à lire dans cette sortie :

1. Le port vaut "9200" : la valeur du parent sous metriques: a écrasé le défaut 9100 du sous-chart.
2. global-env vaut "recette" : le sous-chart lit .Values.global.environnement, que le parent a posé dans global.
3. Les étiquettes de app viennent de la bibliothèque, mais app.kubernetes.io/name vaut app, pas lyneko-commons : le modèle de la bibliothèque s'exécute dans le contexte du chart appelant.
4. prefixe: "demo" est la valeur importée : exporte.prefixe du sous-chart est devenu imports.prefixe chez le parent, sans que le parent l'écrive.

L'objet de la bibliothèque (lyneko-commons) n'apparaît pas dans la sortie : elle ne rend rien.

Désactiver une dépendance

$ helm template r . --set metriques.enabled=false --set imports.prefixe=x | head -12
---
# Source: app/templates/cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: r-app
  labels:
    app.kubernetes.io/name: app
    app.kubernetes.io/instance: r
    app.kubernetes.io/part-of: lyneko
data:
  prefixe: "x"

Le ConfigMap r-metriques a disparu. Notez le --set imports.prefixe=x : quand le sous-chart est désactivé, ses valeurs ne sont plus importées, donc le parent doit fournir lui-même la valeur dont son modèle a besoin. C'est un piège classique des import-values combinés à une condition : prévoyez un défaut dans les valeurs du parent, ou un test default dans le modèle.

build, et le verrou désynchronisé

helm dependency build retélécharge ce que Chart.lock enregistre :

$ helm dependency build
Saving 2 charts
Deleting outdated charts

Modifiez maintenant une contrainte dans Chart.yaml (~1.4.0 en ~1.5.0) sans mettre le verrou à jour :

$ helm dependency build
Error: the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Please update the dependencies

C'est le comportement voulu : build refuse de deviner. En CI, cette erreur signale que quelqu'un a modifié Chart.yaml sans relancer helm dependency update et sans valider le nouveau Chart.lock. On corrige en lançant update et en validant les deux fichiers ensemble.

Une dépendance distante

Pour un chart publié, le Chart.yaml change à peine. Dans un registre OCI, repository donne l'adresse sans le nom du chart, que name fournit :

dependencies:
  - name: lyneko-commons
    version: 0.2.x
    repository: oci://rg.fr-par.scw.cloud/lyneko-charts/charts

Il faut alors être connecté (helm registry login) avant helm dependency update. Cette commande demande un accès réseau et des identifiants : elle n'est pas exécutée dans ce cours, mais elle suit la forme documentée dans la page « Using OCI-based registries » de Helm. Pour un dépôt HTTP classique, on déclare d'abord le dépôt (helm repo add) ou on met l'URL directement dans repository.

Sous le capot

Ce que helm package embarque. Le paquet d'un chart qui a des dépendances contient le répertoire charts/ avec leurs archives : le destinataire n'a rien à télécharger, et helm template sur le .tgz fonctionne hors ligne. C'est pourquoi helm dependency update ou build doit précéder helm package, sans quoi le paquet est incomplet. Un fichier .helmignore peut exclure ce qu'on ne veut pas empaqueter.

Comment le rendu les assemble. Helm charge le chart parent et, récursivement, chaque sous-chart de charts/. Il calcule pour chacun sa table de valeurs (la sienne, surchargée par celle que porte le parent sous son nom, plus global), puis rend tous les modèles dans un seul passage. Les sorties portent un commentaire # Source: qui indique le chemin, comme app/charts/metriques/templates/cm.yaml. Les condition et tags sont évalués au chargement : un sous-chart désactivé est retiré avant le rendu, et ses valeurs ne comptent plus.

Les modèles nommés sont globaux. Tous les modèles définis par tous les charts de la release (parent, sous-charts, bibliothèques) vivent dans un même espace de noms. Deux charts qui définissent labels : le dernier chargé l'emporte, sans erreur. D'où la convention de préfixer par le nom du chart (lyneko-commons.labels), et l'importance de ne pas laisser un sous-chart tiers définir un nom trop générique.

Ce que contient une bibliothèque. Un chart de bibliothèque est chargé comme un autre, mais Helm n'en rend pas les fichiers qui ne commencent pas par _. Ses modèles nommés sont enregistrés dans l'espace de noms global, et le contexte passé à include fait le reste.

Alias. Avec alias: metriques-externe, le même chart peut figurer deux fois, sous son nom et sous l'alias, chacun avec ses valeurs (metriques: et metriques-externe:). Les deux instances rendent les mêmes modèles : si ceux-ci nomment leurs objets à partir de .Release.Name et de .Chart.Name seulement, les noms se heurtent. Un sous-chart conçu pour être répété doit donc inclure dans ses noms une valeur qui distingue les instances (une clé nom dans ses valeurs, par exemple).

Les contraintes de version. Helm utilise les mêmes règles de comparaison que le versionnement sémantique, avec les opérateurs ~, ^, >=, les jokers x et *, et les intervalles. Les versions de préversion (1.4.0-rc.1) ne satisfont une contrainte que si celle-ci en nomme une explicitement.

Pièges courants

found in Chart.yaml, but missing in charts/ directory. On a oublié de récupérer les dépendances après avoir cloné ou modifié Chart.yaml. Lancez helm dependency build.

the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Vu plus haut. helm dependency update, puis versionner Chart.lock ET Chart.yaml dans le même commit.

charts/ ou Chart.lock ignorés par Git. Beaucoup de .gitignore excluent charts/*.tgz. C'est légitime si la CI lance helm dependency build avant tout rendu, mais ne pas versionner Chart.lock est une erreur : sans lui, build n'a rien à reproduire. Argo CD, de son côté, récupère les dépendances lui-même au rendu à partir de Chart.yaml ; un Chart.lock à jour y rend le résultat prévisible.

Un sous-chart qui ne reçoit pas ses valeurs. Les valeurs du parent doivent porter le nom ou l'alias du sous-chart. Écrire port: 9200 à la racine du parent n'atteint pas metriques. Et le nom est celui du name de la dépendance, pas celui du répertoire.

La condition oubliée dans les valeurs. condition: metriques.enabled est évalué dans les valeurs du parent. Si la clé metriques.enabled n'y existe pas, le sous-chart reste activé. Définissez-la dans values.yaml, avec le défaut voulu.

import-values et condition. Vu plus haut : désactiver le sous-chart supprime ce qu'il exportait. Prévoyez un défaut.

Les noms d'objets en collision. Deux sous-charts, ou un parent et son sous-chart, qui nomment un objet avec le seul nom de release : Helm refuse l'installation si l'objet existe déjà sans lui appartenir, ou, dans le même rendu, un des deux manifestes masque l'autre. Préfixez toujours par le nom du chart.

Une bibliothèque qui suppose le contexte de ses valeurs. Un modèle de bibliothèque qui lit .Values.image fonctionne dans un chart qui a cette clé, et échoue ailleurs avec nil pointer. Documentez dans la bibliothèque ce que chaque modèle attend, en commentaire au-dessus du define. Un modèle de bibliothèque doit dépendre de peu, et ce peu est connu.

Mettre à jour la bibliothèque d'un coup partout. Un changement de lyneko-commons change le rendu de tous les charts qui s'en servent à leur prochain dependency update. Le moindre changement d'étiquette de sélection fait échouer des mises à jour de Deployments existants. Traitez une bibliothèque comme une API publique : versions sémantiques, changements visibles, tests de rendu sur chaque chart consommateur avant de publier (voir la leçon Hooks et tests).

Sécurité

Une dépendance est du code que vous exécutez. Les modèles d'un sous-chart rendent des objets Kubernetes dans votre cluster : un ClusterRole, un hostPath, un conteneur privilégié. Lisez le rendu (helm template) d'un chart tiers avant de l'ajouter en dépendance, et à chaque changement de version : une mise à jour de ~1.4.0 à 1.4.7 est automatique dans la contrainte, mais pas anodine.

Épingler. Chart.lock fige les versions : versionnez-le, et lancez build (pas update) en CI, pour qu'une nouvelle version publiée sur un dépôt ne passe pas en production sans qu'une personne ait relu la mise à jour du verrou. L'empreinte du verrou porte sur la liste des dépendances, pas sur le contenu des archives : d'après la documentation de Helm, la protection d'intégrité d'un chart passe par les mécanismes de provenance (leçon 9), pas par Chart.lock.

Un dépôt de dépendances est une chaîne d'approvisionnement. Préférez des registres que vous maîtrisez : copiez (miroir) les charts tiers dans votre registre OCI interne, et déclarez ce miroir. Vous évitez qu'une suppression ou un remplacement côté amont casse le build, ou injecte du contenu. La leçon 9 montre comment signer et vérifier ces artefacts.

Les valeurs globales traversent les frontières. Tout ce qui est dans global est lisible par tous les sous-charts, y compris un chart tiers. N'y mettez jamais un secret.

Un chart de bibliothèque centralise aussi la sécurité. Si lyneko-commons pose par défaut runAsNonRoot, readOnlyRootFilesystem et allowPrivilegeEscalation: false, tous les charts qui s'en servent en héritent. À l'inverse, une faute dans la bibliothèque est une faute partout : relisez-la avec soin.

En production

Ne pas mettre la base de données en sous-chart. La tentation est forte : un chart communautaire de PostgreSQL, une ligne dans dependencies, et l'application a sa base. Les raisons de s'abstenir sont de cycle de vie.

• La suppression. helm uninstall supprime les objets de la release, volumes compris selon la politique de rétention : l'application et ses données partent d'un seul geste.
• Les mises à jour. Monter la version du sous-chart fait potentiellement monter la version majeure de PostgreSQL, avec les migrations de données que cela suppose, au rythme du déploiement de l'application plutôt qu'à celui d'une décision d'exploitation.
• Les sauvegardes, la haute disponibilité, la supervision. C'est un métier. Un service géré le fait mieux.
• Les valeurs. Le sous-chart porte ses propres réglages (mots de passe générés, tailles de volumes) qui se retrouvent dans les valeurs et les secrets de release.

Chez Lyneko, la base de Signalements est une instance PostgreSQL gérée par Scaleway (voir le cours sur PostgreSQL managé), créée par Terraform. Le chart ne reçoit que DATABASE_URL, lue dans Secret Manager via l'ExternalSecret. La démonstration du cours GitOps déploie bien PostgreSQL dans le cluster, mais comme un exercice, avec ses manifestes propres et non comme une dépendance de l'application. Quand une base en cluster est nécessaire (environnement jetable, aperçu de demande de fusion), elle est un chart séparé, avec sa propre release et son propre cycle de vie, que l'application consomme par une URL.

Garder les dépendances rares. Chaque dépendance ajoute un couplage de versions, un nom de modèle global potentiel, et une surface de mise à jour. Posez-vous la question : ce chart aurait-il pu être une release à part ? Si oui, il le sera plus facilement à gérer.

La bibliothèque : versionnement et déploiement progressif. Publiez lyneko-commons dans le registre OCI avec une version sémantique, et laissez chaque chart choisir quand monter, par une contrainte volontairement étroite (~0.2.0). Un changement qui modifie le rendu d'un objet existant est une version majeure. Une CI qui rend chaque chart consommateur avec la nouvelle bibliothèque, et compare avec la sortie précédente, détecte les écarts avant publication.

Argo CD et les dépendances. Pour une application Argo CD dont la source est un chart Git, le repo-server récupère lui-même les dépendances au rendu, ce qui demande un accès réseau et, pour un registre privé, des identifiants déclarés dans Argo CD. Une autre approche, plus stricte, publie le chart déjà assemblé (dépendances dans le paquet) dans un registre OCI, et Argo CD le consomme sans rien résoudre (leçon 10).

Charts de la communauté en dépendance : quand oui ? Pour un composant qui a vraiment le même cycle de vie que votre application, et dont vous relisez le rendu. Un exporteur de métriques, un petit cache sans état, un composant de test. Pour un opérateur, un contrôleur (cert-manager, External Secrets) ou tout ce qui installe des CRD : jamais en sous-chart d'une application, mais comme une application à part, déployée par la plateforme (voir GitOps avec Argo CD). Les CRD ont leur propre cycle de vie, que Helm gère mal (il installe celles du répertoire crds/ à la première installation, et ne les met pas à jour).

Exercices

Exercice 1 : lire un rendu

Avec le chart app ci-dessus, vous lancez helm template r . --set metriques.port=9300 --set global.environnement=prod. Quelles valeurs prennent port et global-env dans le ConfigMap r-metriques ? Et quelle étiquette app.kubernetes.io/name porte le ConfigMap r-app ?

Exercice 2 : le verrou

Un collègue change ~1.4.0 en ~1.5.0 dans Chart.yaml et pousse. La CI lance helm dependency build et échoue. Pourquoi, et quelle séquence de commandes corrige le problème ? Pourquoi la CI utilise-t-elle build plutôt que update ?

Exercice 3 : sous-chart ou pas ?

Pour chaque cas, dites s'il faut une dépendance, un chart séparé ou un chart de bibliothèque : (a) les étiquettes et le bloc securityContext communs à quinze applications Lyneko ; (b) un conteneur annexe d'export de métriques toujours déployé avec Signalements ; (c) PostgreSQL pour un environnement d'aperçu éphémère ; (d) cert-manager.

Récapitulatif

• Les dépendances se déclarent dans Chart.yaml : name, version (contrainte), repository (file://, HTTP ou oci://), condition, tags, alias, import-values.
• helm dependency update résout les contraintes et réécrit Chart.lock ; helm dependency build reproduit exactement le verrou et échoue s'il est désynchronisé. On versionne Chart.lock, et la CI lance build.
• Un sous-chart ne voit que ses propres valeurs (celles que le parent met sous son nom), plus global ; le parent peut importer des valeurs du sous-chart. Désactivé par condition, le sous-chart disparaît du rendu et de ses imports.
• Un chart de bibliothèque (type: library) ne rend rien et partage des modèles nommés, qui s'exécutent dans le contexte du chart appelant. Les noms de modèles sont globaux : on les préfixe.
• Un sous-chart doit avoir le même cycle de vie que son parent. Une base de données, un opérateur ou tout ce qui installe des CRD ne le doit pas : chez Lyneko, PostgreSQL est un service géré, et les opérateurs sont des applications à part.
• Une dépendance est du code exécuté dans votre cluster : relisez son rendu, épinglez-la, et hébergez-la dans un registre que vous maîtrisez.

Pour aller plus loin

• Helm, Chart Dependencies et Library Charts, pour le détail des champs et les cas limites.
• Helm, Subcharts and Global Values, pour les règles de portée des valeurs.
• Dans ce cours : Valeurs, schéma et fonctions d'aide, Hooks et tests (tester le rendu de chaque chart consommateur) et Publier et signer un chart.
• GitOps avec Argo CD, leçon 3 : une Application dont la source est un chart Helm.