Gérer une version Helm
Comment utiliser des fonctions dans un modèle Helm
Le langage de gabarit Helm définit les fonctions que vous utilisez pour transformer les valeurs du fichier values.yaml. La syntaxe d’une fonction suit la structure suivante : {{ NomFonction arg1 arg2 ... }}. Pour voir à quoi ressemble cette syntaxe, prenons comme exemple la fonction quote.
La fonction quote place une valeur entre guillemets pour indiquer l’utilisation d’un string. Disons que vous définissiez le fichier values.yaml suivant :
apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
enabled: true
Vous décidez d’utiliser la valeur ingress.enabled comme une valeur booléenne afin de déterminer si un manifeste d’entrée doit être généré. Pour utiliser la valeur enabled comme une valeur booléenne, vous référencez la valeur à l’aide de {{ .Values.ingress.enabled }}.
Plus tard, vous décidez d’afficher le champ sous la forme d’une chaîne dans le fichier templates/Notes.txt. Étant donné que les règles de forçage de type YAML peuvent entraîner des bogues difficiles à trouver dans les modèles, vous décidez de suivre les instructions et d’être explicites quand vous incluez des chaînes dans vos modèles. Par exemple, enabled: false n’est pas égal à enabled: "false".
Pour afficher la valeur sous forme de chaîne, vous utilisez {{ quote .Values.ingress.enabled }} pour référencer la valeur booléenne sous forme de chaîne.
Comment utiliser des pipelines dans un modèle Helm
Vous utilisez des pipelines lorsque plusieurs fonctions doivent agir sur une valeur. Un pipeline vous permet d’envoyer une valeur ou le résultat d’une fonction à une autre fonction. Par exemple, vous pouvez réécrire la fonction quote ci-dessus ainsi : {{ .Values.ingress.enabled | quote }}. Le | indique que la valeur est envoyée à la fonction quote.
Voici un autre exemple. Disons que vous souhaitiez convertir une valeur en majuscules et la mettre entre guillemets. Vous pouvez écrire l’instruction ainsi : {{ .Values.ingress.enabled | upper | quote }}. Notez la manière dont la valeur est traitée par la fonction upper, puis par la fonction quote.
Le langage de gabarit comprend plus de 60 fonctions qui vous permettent d’exposer, de rechercher et de transformer des valeurs et des objets dans des modèles.
Comment utiliser le contrôle de flux conditionnel dans un modèle Helm
Le contrôle de flux conditionnel vous permet de décider de la structure ou des données incluses dans le fichier manifeste généré. Par exemple, vous souhaitez peut-être inclure des valeurs différentes en fonction de la cible de déploiement ou décider si un fichier manifeste doit être généré ou non.
Le bloc if / else est une structure de flux de contrôle qui suit le format suivant :
{{ if | pipeline | }}
# Do something
{{ else if | other pipeline | }}
# Do something else
{{ else }}
# Default case
{{ end }}
Disons que vous décidez que le fichier manifeste d’entrée d’un chart est créé seulement dans certains cas précis. L’exemple suivant montre comment réaliser ceci en utilisant une instruction if :
{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{ end }}
N’oubliez pas que vous pouvez utiliser des espaces réservés pour inclure les métadonnées dans le modèle. Les fichiers de modèle sont analysés et évalués séquentiellement par le langage de gabarit, du haut vers le bas. Dans l’exemple ci-dessus, le moteur de modèle génère uniquement le contenu du fichier manifeste si la valeur .Values.ingress.enabled est égale à true.
Quand le moteur de modèle traite l’instruction, il supprime le contenu déclaré dans la syntaxe {{ }} et conserve l’espace blanc restant. Dans cette syntaxe, le moteur de modèle inclut un saut de ligne pour la ligne de l’instruction if. Si vous laissez le contenu du fichier précédent tel quel, vous verrez que votre code YAML contient des lignes vides et que le fichier manifeste d’entrée est généré.
Le langage YAML donne une signification aux espaces blancs. C’est la raison pour laquelle les tabulations, les espaces et les caractères de nouvelle ligne sont considérés comme importants. Pour résoudre le problème des espaces blancs non souhaités, vous pouvez réécrire le fichier de la façon suivante :
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{- end }}
Notez l’utilisation du caractère - dans le cadre de la séquence de début {{- et de fin -}} de l’instruction. Le caractère - indique à l’analyseur de supprimer les espaces blancs. {{- supprime l’espace blanc au début d’une ligne et -}} à la fin d’une ligne, y compris le caractère de nouvelle ligne.
Comment itérer au sein d’une collection de valeurs dans un modèle Helm
Le langage YAML vous permet de définir des collections d’éléments et d’utiliser des éléments comme des valeurs dans vos modèles. Vous pouvez accéder aux éléments d’une collection par le biais d’un indexeur. Cependant, le langage de gabarit Helm prend en charge l’itération d’une collection de valeurs à l’aide de l’opérateur range.
Disons que vous définissez une liste de valeurs dans votre fichier values.yaml pour indiquer des hôtes d’entrée supplémentaires. Voici un exemple de valeurs :
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Utilisez l’opérateur de plage pour permettre au moteur de modèle d’itérer au sein de .Values.ingress.extraHosts. L’extrait de code suivant montre un exemple condensé qui utilise l’opérateur range :
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
...
spec:
rules:
...
{{- range .Values.ingress.extraHosts }}
- host: {{ .name }}
http:
paths:
- path: {{ .path }}
...
{{- end }}
...
{{- end }}
Comment contrôler l’étendue des valeurs dans un modèle Helm
Si vous définissez des valeurs sur plusieurs couches, votre syntaxe peut devenir très longue et rendre fastidieuse l’inclusion de ces valeurs dans un modèle. L’action with vous permet de limiter l’étendue des variables dans un modèle.
N’oubliez pas que le . utilisé dans un modèle Helm référence l’étendue actuelle. Par exemple, .Values indique au moteur de modèle de rechercher l’objet Values dans l’étendue actuelle. Disons que vous utilisez le fichier values.yaml précédent pour créer un fichier manifeste de mappage de configuration :
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Au lieu d’accéder à la valeur de chemin de chaque élément à l’aide de {{ .Values.ingress.extraHosts.path }}, vous pouvez utiliser l’action with. L’extrait de code suivant montre un exemple qui utilise l’opérateur range pour générer un fichier manifeste de mappage de configuration :
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
{{ end }}
{{- with .Values.ingress.extraHosts }} limite l’étendue des valeurs au tableau .Values.ingress.extraHosts.
L’action with restreint l’étendue. Vous ne pouvez pas accéder aux autres objets à partir de l’étendue parente. Disons que vous souhaitez également accéder au {{ .Release.Name }} du chart dans le bloc de code with. Pour accéder aux objets parents, vous devez indiquer l’étendue racine à l’aide du caractère $, ou sinon, réécrire votre code. Voici le code mis à jour pour vous montrer comment inclure des objets parents à l’aide du caractère $ :
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
release: {{ $.Release.Name}}
{{ end }}
Remarque
Le langage de gabarit Helm comprend plusieurs constructions qui permettent de contrôler le flux. L’unité de synthèse de ce module comprend une section avec des liens permettant de consulter la documentation Helm.
Comment définir des dépendances de chart Helm
Un chart permet à la déclaration des dépendances de prendre en charge l’application principale. Il fait partie intégrante de la version installée.
Vous pouvez soit créer un sous-chart à l’aide de la commande helm create, en spécifiant l’emplacement du nouveau chart dans le dossier /charts, soit utiliser la commande helm dependency. N’oubliez pas que le dossier /charts peut contenir des sous-charts déployés dans le cadre de la version du chart principal.
La commande helm dependency vous permet de gérer les dépendances qui proviennent du référentiel Helm. La commande utilise des métadonnées qui sont définies dans la section dependencies du fichier de valeurs de votre chart. Vous spécifiez le nom, le numéro de version et le référentiel à partir duquel installer le sous-chart. Voici un extrait du fichier values.yaml, dont le chart MongoDB est listé comme une dépendance :
apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
- name: mongodb
version: 10.27.2
repository: https://marketplace.azurecr.io/helm/v1/repo
Une fois les métadonnées de dépendances définies, exécutez la commande helm dependency build pour récupérer le chart empaqueté au format tar. La commande de génération de chart télécharge le chart dans le dossier charts/.
helm dependency build ./app-chart
Les sous-charts sont gérés séparément du chart principal et peuvent nécessiter des mises à jour à mesure que de nouvelles versions sont disponibles. La commande de mise à jour des sous-charts est la suivante : helm dependency update. Cette commande permet de récupérer les nouvelles versions du sous-chart lorsque vous supprimez les packages obsolètes.
helm dependency update ./app-chart
Gardez à l’esprit qu’une dépendance de chart ne se limite pas aux autres applications. Vous pouvez décider de réutiliser la logique du modèle dans vos charts, et de créer une dépendance spécifiquement pour gérer cette logique comme dépendance de chart. Vous verrez un exemple de cette stratégie dans l’exercice qui suit.
Comment mettre à niveau une version Helm
Helm permet la mise à niveau des versions existantes sous la forme d’un delta de toutes les modifications qui s’appliquent au chart et à ses dépendances.
Par exemple, disons que l’équipe de développement de l’exemple webapp de cette unité apporte des modifications de code qui affectent uniquement la fonctionnalité du site web. L’équipe effectue les mises à jour suivantes du fichier Chart.yaml pour refléter la nouvelle version de l’application :
- Met à jour l’image conteneur de l’application web et étiquette l’image avec
webapp: linux-v2lors de l’envoi (push) de celle-ci au registre de conteneurs. - Remplace la valeur
dockerTagparlinux-v2, et la valeur de la version du chart par0.2.0dans le fichier de valeurs du chart.
Voici un exemple du fichier values.yaml mis à jour :
apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
type: application
version: 0.2.0
appVersion: 1.0.0
registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"
Au lieu de désinstaller une version actuelle, vous utilisez la commande helm upgrade pour mettre à niveau la version Helm existante.
helm upgrade my-app ./app-chart
N’oubliez pas que lorsque vous mettez à niveau une version, Helm génère un delta des modifications apportées au chart Helm. Par conséquent, une mise à niveau Helm met à niveau uniquement les composants qui sont identifiés dans le delta. Dans l’exemple, seul le site web est redéployé.
Une fois la mise à niveau terminée, vous pouvez passer en revue l’historique du déploiement de la version à l’aide de la commande helm history avec le nom de la version.
helm history my-app
La commande history retourne plusieurs champs qui décrivent la version, comme le montre l’exemple de sortie suivant :
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 deployed aspnet-core-1.3.18 3.1.19 Install complete
Notez le champ revision dans les résultats. Helm effectue le suivi des informations de version pour toutes les versions d’un chart Helm. Lorsque vous installez une nouvelle version d’un chart Helm, le nombre de révisions augmente d’une unité, et les informations de la nouvelle version sont alignées sur cette révision.
Voici un exemple d’exécution de la même commande d’historique après l’installation d’une nouvelle version de l’application web :
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 superseded aspnet-core-1.3.18 3.1.19 Install complete
2 Mon Oct 11 17:35:13 2021 deployed aspnet-core-1.3.18 3.1.19 Upgrade complete
Comment restaurer une version Helm
Helm permet de restaurer une version Helm existante vers une version précédemment installée. Comme nous l’avons vu précédemment, Helm effectue le suivi des informations de version pour toutes les versions d’un chart Helm.
Utilisez la commande helm rollback pour revenir à une révision de version Helm donnée. Cette commande utilise deux paramètres. Le premier paramètre correspond au nom de la version, et le deuxième au numéro de révision de la version.
helm rollback my-app 2
La commande helm rollback restaure la version de l’application à la révision spécifiée, et met à jour l’historique des versions de l’application. L’exécution de la commande helm history affiche le numéro de la dernière révision active en tant qu’entrée de version la plus récente.
Par exemple, disons que l’équipe de développement de l’exemple de webapp de cette unité découvre un bogue dans l’application web de suivi des drones et doit revenir à une version précédente. Au lieu de désinstaller la version actuelle et d’installer une version antérieure, elle peut revenir à la dernière version opérationnelle.
helm rollback my-app 1
Une fois qu’une restauration est terminée, vous pouvez passer en revue l’historique du déploiement à l’aide de la commande helm history.
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Mon Oct 11 17:25:33 2021 superseded aspnet-core-1.3.18 3.1.19 Install complete
2 Mon Oct 11 17:35:13 2021 superseded aspnet-core-1.3.18 3.1.19 Rolled back to 1
3 Mon Oct 11 17:38:13 2021 deployed aspnet-core-1.3.18 3.1.19 Upgrade complete
Notez que le champ Description affiche le numéro de révision de la restauration pour faciliter le suivi des modifications.