Helm—Modèles nommés

Aperçu

Nous pouvons créer des modèles partiels ou des sous-modèles dans helm, principalement appelés « modèles nommés ». Un modèle nommé est simplement un modèle défini dans un fichier et doté d'un nom.

Nous pouvons considérer les modèles nommés comme des fonctions. Les modèles nommés nous permettront de réutiliser la syntaxe ou la logique dans l'ensemble du graphique helm.

En règle générale, les fichiers du répertoire des modèles dans un graphique Helm contiennent des modèles qui créent des manifestes Kubernetes. Mais les fichiers dont le nom commence par un trait de soulignement (_) sont supposés ne pas avoir de manifeste à l'intérieur. Ces fichiers ne sont pas rendus dans les définitions d'objets Kubernetes, mais sont disponibles partout dans d'autres modèles de graphiques pour être utilisés.

Ainsi, la convention de nommage des fichiers ressemblera à ceci :

_filename.tpl
e.g.
_helpers.tpl

Déclarer et intégrer des "modèles nommés" dans d'autres modèles :

Nous pouvons définir un modèle nommé dans le fichier de modèle appelé _helpers.tpl créé précédemment. Pour définir un modèle, nous devons utiliser un define mot-clé. Étant donné que les noms de modèles sont globaux, il existe un risque de conflit si deux modèles sont déclarés avec le même nom. Par conséquent, le maintien d'une convention de nommage sera une idée judicieuse pour éviter les doublons. Une convention de dénomination courante consiste à préfixer chaque modèle défini avec le nom du graphique, par exemple —<CHART_NAME>.<things_the_template_will_do>

{{- define "webserver.selectorLabels" -}}
# body of template here
{{- end }}

{{/*
Selector labels
*/}}
{{- define "webserver.selectorLabels" -}}
# body of the template here
{{- end }}

Action de modèle

Définissons un modèle nommé et voyons comment nous pouvons l'utiliser dans un fichier de modèle normal.

# filename:  _helpers.tpl
{{/*
Common labels
*/}}
{{- define "webserver.labels" -}}
    app: nginx
    generator: helm
{{- end }}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver-deployment
  labels:
  {{- template "webserver.labels" }}

# filename:  _helpers.tpl
{{/*
Common labels
*/}}
{{- define "webserver.labels" -}}
    app: nginx
    generator: {{ .Release.Service }}
{{- end }}

{{- template "webserver.labels" }}

{{- template "webserver.labels" . }}

# It will not work
{{- template "webserver.labels" . | nindent 4 }}

{{- include "webserver.labels" . | nindent 4 }}

Pour intégrer des modèles nommés dans des modèles normaux à l'aide de includela fonction, nous devons transmettre deux paramètres.

1. Le nom du modèle nommé.
2. La portée de l'objet.

{{- include "webserver.labels" . }}

{{- include "webserver.labels" . | nindent 4 | qoute }}

{{/*
Common labels
*/}}
{{- define "webserver.labels" }}
{{- include "webserver.selectorLabels" . }}
# body of template here
{{- end }}
{{/*
Selector labels
*/}}
{{- define "webserver.selectorLabels" }}
# body of template here
{{- end }}

Écrivons deux modèles nommés et utilisons-les dans un modèle de déploiement qui générera des manifestes Kubernetes.

Voici l'extrait du fichier _helpers.tpl :

{{/*
Common labels
*/}}
{{- define "webserver.labels" -}}
{{- include "webserver.selectorLabels" . }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}
{{/*
Selector labels
*/}}
{{- define "webserver.selectorLabels" -}}
app: {{ .Chart.Name }}
{{- end }}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Chart.Name }}
  labels:
  {{- include "webserver.labels" . | nindent 4 }}
spec:
  replicas: 3
  selector:
    matchLabels:
    {{- include "webserver.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
      {{- include "webserver.selectorLabels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: nginx:latest
        ports:
        - containerPort: 80

>> helm template ~/webserver
---------------------------------------------
# Source: webserver/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webserver
  labels:
    app: webserver
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - name: webserver
        image: nginx:latest
        ports:
        - containerPort: 80

Fermeture

Les modèles nommés peuvent faciliter la gestion des configurations que nous souhaitons partager entre deux ressources ou plus, et ils nous aident à créer un emplacement centralisé pour modifier les configurations courantes.

Si vous avez trouvé cet article utile, n'oubliez pas d'appuyer sur les boutons Applaudir et Suivre pour m'aider à écrire d'autres articles comme celui-ci.
Merci

Références