🏌️ 👨🏼‍⚖️ 📲 Un guide rapide pour la conception de graphiques dans Helm 👨🏻‍🏫 📪 🅱️

Unsplash de Frank Eiffert

Helm est un outil puissant pour appliquer, mettre à jour et gérer des applications dans Kubernetes. La communauté Helm crée de nombreux graphiques open source. Vous pouvez déployer l'opérateur Redis, Nginx ou Prometheus avec une seule commande. Et ils sont livrés avec tout ce dont vous avez besoin, comme Ingress.

L'équipe Mail.ru Cloud Solutions atraduit un article décrivant un moyen rapide de créer un graphique de base, montrant des commandes utiles et partageant les meilleures pratiques. Il ne s'attarde pas sur les aspects du langage de création de modèles Go, car la plupart d'entre eux sont traités dans la documentation Helm. Ce didacticiel fournit des aspects plus abstraits et des idées pour améliorer votre flux de travail.

Créer une structure de graphique de base

Commencez par une commande simple qui créera un exemple de structure de graphique:

$ helm create basic
Creating basic
$ tree basic
basic/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

C'est tout ce qu'il faut pour créer un graphique prêt pour le déploiement. Ce graphique vous permet de déployer une application avec tous les composants nécessaires. Si vous regardez values.yaml, vous pouvez voir que cette application déploiera Nginx.

Développer un graphique est aussi simple que de créer:

$ helm install basic

L'équipe de modèles est votre meilleur ami

Immédiatement avant l'installation et après les modifications du graphique, vous devez vérifier si tout est correctement traité dans les modèles.

Pour vérifier exactement ce qui sera déployé sur le cluster, utilisez la commande:

$ helm template basic

La commande affichera chaque YAML généré par tous les modèles. Si vous ne souhaitez voir que le résultat d'un modèle, utilisez:

$ helm template basic -x templates/service.yaml

Le résultat sera quelque chose comme ceci:

---
# Source: basic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-basic
  labels:
    app.kubernetes.io/name: basic
    helm.sh/chart: basic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: basic
    app.kubernetes.io/instance: release-name

Pour tester un modèle avec des valeurs personnalisées, utilisez:

$ helm template basic -x templates/service.yaml -f \ mypath/tocustomvalues.yaml

Le modèle généré peut être testé sur le cluster à l'aide de la commande:

$ helm install basic --dry-run --debug

PELUCHE!

Avant de soumettre au référentiel, vous pouvez ajouter une étape supplémentaire pour vérifier clairement le code - linting (analyse statistique):

$ helm lint basic/
==> Linting basic/
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures

Helm fonctionne avec des fonctions

Si vous regardez dans le répertoire des modèles de graphiques, vous pouvez voir _helpers.tpl. Ici vous pouvez ajouter vos fonctions, elles seront disponibles tout au long du graphique. Un exemple de fonction pourrait ressembler à ceci:

{{/*
Expand the name of the chart.
*/}}
{{- define "basic.name" -}} 
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} 
{{- end -}}

L'utilisation d'une fonction dans un modèle est indiquée par une fonction include:

app.kubernetes.io/name: {{ include "basic.name" . }}

Étiquettes méta

Une partie importante de Kubernetes est l'utilisation correcte des étiquettes. Ceci est très important si vous utilisez Helm pour déployer plusieurs manifestes. Pour ajouter facilement des balises pour rechercher des ressources gérées par Helm, vous pouvez utiliser vos propres fonctions:

{{/*
Common labels
*/}}
{{- define "basic.labels" -}} 
app.kubernetes.io/name: {{ include "basic.name" . }}
helm.sh/chart: {{ include "basic.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

Et maintenant, il est facile d'ajouter quelques balises au graphique:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "basic.fullname" . }}
  labels:
{{ include "basic.labels" . | indent 4 }}
...

Si vous souhaitez rechercher des services créés à l'aide de ce graphique, utilisez la commande:

$ kubectl get svc -l helm.sh/chart=basic-0.1.0

Les commentaires vous sauveront

Il existe deux types de commentaires:

# Est un simple commentaire qui reste dans le YML résultant après le traitement.
{{- / * ... * / -}} est un commentaire qui est ignoré par le moteur de création de modèles.

# app files volume
        {{- /*
          App files are configmaps created by cloud-app-play-files chart.
          App files contains files specific for app and environment.
          App name should be same as in deployment of cloud-app-play-files chart.
        */ -}} 
        {{- if .Values.include.appDir }}
        - name: {{ $appName }}-files
          configMap:
            name: {{ $appName }}-files

La sortie du modèle sera comme ceci:

       # app files volume
       - name: app-notification-files
         configMap:
           name: app-notification-files

Comme vous pouvez le voir, le manifeste généré ne contient qu'un simple commentaire de type. Le type à utiliser dépend de vous. Mais les commentaires de modèle sont utiles si vous définissez des pipelines ou des dépendances plus complexes dans YAML.

Il est également important de se rappeler que les commentaires commençant par # sont également analysés. Si vous mettez un modèle Go dans un commentaire, il sera évalué. Les commentaires peuvent donc aussi être des modèles.

Assurez-vous de conserver la documentation

La documentation des graphiques est indispensable, surtout si vous souhaitez publier un graphique. Le moyen le plus simple de créer et de gérer des documents est d'utiliser le package Golang nommé helm-docs . Avec lui, vous pouvez générer un README.md contenant des tables de valeurs, des versions et des descriptions de values.yaml et chart.yaml, ou utiliser d'autres fichiers personnalisés.

^{Exemple tiré de https://github.com/norwoodj/helm-docs}

Comme vous pouvez le voir, l'ajout du nom avec - dans les commentaires donne une ligne dans le tableau. En outre, le tableau contient des informations supplémentaires telles que la description, le nom et la version du graphique. Helm-docs peut être intégré dans un pré-commit avec linting. C'est facile à faire:

$ helm-docs
INFO[2020-07-23T15:30:38+02:00] Found Chart directories [.]                 
INFO[2020-07-23T15:30:38+02:00] Generating README Documentation for chart .

La magie des sous-graphiques

Lorsque votre graphique devient le monstre de l'architecture, il est préférable de diviser certains des composants du graphique en plus petits. Ils sont appelés sous-graphiques ou graphiques enfants.

Les sous-graphiques sont déployés en même temps que le graphique principal. Les valeurs des sous-graphiques peuvent être fournies dans le même fichier values.yaml que pour le graphique principal. Vous pouvez également les connecter à partir de GitHub, mais pour l'article, je vais créer un sous-diagramme localement.

Pour démarrer avec un nouveau sous-graphique dont dépend le graphique principal, créez un répertoire de graphiques dans le dossier de graphique principal. Créez ensuite un graphique de base:

$ mkdir charts
$ cd charts
$ helm create subbasic

Pour connecter un sous-graphique, modifiez la définition du graphique principal:

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: basic
version: 0.1.0
dependencies:
  - name: subbasic

Désormais, à chaque fois que la commande est lancée helm install, non seulement le graphique principal est développé, mais également le sous-graphique. Pour remplacer le nom de référence du sous-graphique lors du déploiement sur le service, ajoutez les commandes suivantes au values.yaml du graphique principal:

subbasic:
 service:
   type: NodePort
 nameOverride: "jojo"

Exécutez maintenant la commande templateet voyez la sortie modifiée du service de sous-diagramme. Le type de service changera avec le nom:

---
# Source: basic/charts/subbasic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-jojo
  labels:
    app.kubernetes.io/name: jojo
    helm.sh/chart: subbasic-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: jojo
    app.kubernetes.io/instance: release-name

Remarque importante: les sous- graphiques ne peuvent pas accepter les valeurs des graphiques parents.

Des moments souvent oubliés

Encore quelques points:

Noms des ressources - 63 caractères maximum.
Les noms de ressources ne peuvent être que des chiffres, des lettres minuscules, "-" ou ".".
Taille du graphique - pas plus de 1 MB . Ceci est particulièrement important si vous utilisez des pièces jointes.
Le graphique a une fonction d'analyse .tpl.
Vous pouvez spécifier les ressources qui resteront une fois que la commande aura supprimé le déploiement du graphique helm delete.

Eh bien voilà tout!

Vous pouvez maintenant rédiger votre premier graphique. Il vaut la peine de mentionner l'attachement de fichiers - les graphiques ne conviennent pas pour ajouter des fichiers et enregistrer leur structure dans des répertoires. Mais sur la page de recommandation, vous ne trouverez pas d'informations sur ce qu'il faut tracer ou non.

Helm est un outil assez jeune, mais avec beaucoup de potentiel. N'oubliez pas que le peluchage, la génération de documentation et même les modèles à sec sur un cluster peuvent faire partie du CI. Helm Workflow est déjà disponible pour GitHub .

Bonne chance!

Quoi d'autre à lire:

Un guide rapide pour la conception de graphiques dans Helm