Hantera en Helm-release
Hur man använder funktioner i en Helm-mall
Helm-mallspråket definierar funktioner som du använder för att transformera värden från values.yaml-filen. Syntaxen för en funktion följer {{ functionName arg1 arg2 ... }} struktur. Nu ska vi titta på funktionen quote som ett exempel för att se den här syntaxen som används.
Funktionen quote omsluter ett värde i citattecken för att ange användningen av en string. Anta att du definierar följande values.yaml fil:
apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
enabled: true
Du bestämmer dig för att använda värdet ingress.enabled som booleskt värde när du avgör om ett ingressmanifest ska genereras. Om du vill använda värdet enabled som booleskt värde refererar du till värdet med hjälp av {{ .Values.ingress.enabled }}.
Senare bestämmer du dig för att visa fältet som en sträng i filen templates/Notes.txt. Eftersom regler för YAML-typtvång kan leda till svårsökta buggar i mallar bestämmer du dig för att följa vägledningen och vara tydlig när du lägger till strängar i dina mallar.
enabled: false är till exempel inte lika med enabled: "false".
Om du vill visa värdet som en sträng använder du {{ quote .Values.ingress.enabled }} för att referera till det booleska värdet som en sträng.
Så här använder du pipelines i en Helm-mall
Du använder pipelines när fler än en funktion behöver agera på ett värde. Med en pipeline kan du skicka ett värde, eller resultatet av en funktion, till en annan funktion. Du kan till exempel skriva om funktionen ovan quote som {{ .Values.ingress.enabled | quote }}. Observera hur | anger att värdet skickas till funktionen quote.
Här är ett annat exempel. Anta att du vill konvertera ett värde till versaler och omsluta det med citattecken. Du kan skriva påståendet som {{ .Values.ingress.enabled | upper | quote }}. Observera hur värdet bearbetas av funktionen upper och sedan funktionen quote.
Mallspråket innehåller över 60 funktioner som gör att du kan exponera, slå upp och transformera värden och objekt i mallar.
Så här använder du villkorsstyrd flödeskontroll i en Helm-mall
Med kontroll av villkorsstyrd flöde kan du bestämma strukturen eller data som ingår i den genererade manifestfilen. Du kanske till exempel vill inkludera olika värden baserat på distributionsmålet eller kontrollen om en manifestfil genereras.
Det if / else blocket är en sådan kontrollflödesstruktur och överensstämmer med följande layout:
{{ if | pipeline | }}
# Do something
{{ else if | other pipeline | }}
# Do something else
{{ else }}
# Default case
{{ end }}
Anta att du bestämmer dig för att ingressmanifestfilen för ett diagram endast skapas i specifika fall. I följande exempel visas hur du gör det med hjälp av en if-instruktion:
{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{ end }}
Kom ihåg att du kan använda platshållare för att fylla i metadata i mallen. Mallfiler parsas och utvärderas sekventiellt av mallspråket uppifrån och ned. I föregående exempel genererar mallmotorn bara manifestfilens innehåll om värdet .Values.ingress.enabled är true.
När mallmotorn bearbetar instruktionen tar den bort innehållet som deklarerats i {{ }}-syntaxen och lämnar det återstående mellanrummet. Den här syntaxen gör att mallmotorn innehåller en ny rad för if-instruktionsraden. Om du lämnar föregående fils innehåll as-isser du tomma rader i YAML och ingressmanifestfilen genereras.
YAML tolkar blanksteg. Därför anses flikar, blankstegoch nyradstecken vara viktiga. Du kan åtgärda problemet med oönskat blanksteg genom att skriva om filen på följande sätt:
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{- end }}
Observera användningen av --tecknet som en del av start-{{- och slutet--}}-sekvensen i instruktionen. Tecknet - instruerar parsern att ta bort blankstegstecken.
{{- tar bort blanksteg i början av en rad och -}} i slutet av en rad, inklusive det nya radtecknet.
Iterera genom en samling värden i en Helm-mall
MED YAML kan du definiera samlingar med objekt och använda enskilda objekt som värden i dina mallar. Det går att komma åt objekt i en samling med hjälp av en indexerare. Helm-mallspråket stöder dock iteration av en samling värden med hjälp av operatorn range.
Anta att du definierar en lista med värden i din values.yaml-fil för att ange ytterligare inkommande värdar. Här är ett exempel på värdena:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Du använder intervalloperatorn för att tillåta att mallmotorn itererar via .Values.ingress.extraHosts. Följande kodfragment visar ett komprimerat exempel med operatorn 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 }}
Så här styr du omfånget för värden i en Helm-mall
När du har värden som definierats flera lager djupt kan syntaxen bli lång och besvärlig när du inkluderar dessa värden i en mall. Med åtgärden with kan du begränsa omfånget för variabler i en mall.
Kom ihåg att . som används i en Helm-mall refererar till det aktuella omfånget. Till exempel instruerar .Values mallmotorn att hitta objektet Värden i det aktuella omfånget. Anta att du använder values.yaml-filen från tidigare för att skapa en manifestfil för konfigurationskartan:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
I stället för att komma åt varje objekts sökvägsvärde med hjälp av {{ .Values.ingress.extraHosts.path }}kan du använda åtgärden with. Följande kodfragment visar ett exempel med operatorn range för att generera en manifestfil för konfigurationskarta:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
{{ end }}
{{- with .Values.ingress.extraHosts }} begränsar omfånget för värden till .Values.ingress.extraHosts matris.
Åtgärden with begränsar omfånget. Du kan inte komma åt andra objekt från det överordnade omfånget. Anta att du också vill komma åt diagrammets {{ .Release.Name }} i with kodblocket. För att få åtkomst till överordnade objekt måste du ange rotomfattningen med hjälp av $-tecknet eller skriva om koden. Här är den uppdaterade koden som visar hur du inkluderar överordnade objekt med hjälp av $-tecknet:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
release: {{ $.Release.Name}}
{{ end }}
Not
Det finns flera tillgängliga konstruktioner i Helm-mallspråket för att styra flödet. Den här modulens sammanfattningsenhet innehåller ett avsnitt med länkar till Helm-dokumentationen för mer information.
Så här definierar du diagramberoenden i Helm
Med ett diagram kan deklarationen av beroenden stödja huvudprogrammet och utgör en del av den installerade versionen.
Du kan antingen skapa ett underdiagram med hjälp av kommandot helm create, ange det nya diagrammets plats i mappen /charts eller använda kommandot helm dependency. Kom ihåg att mappen /charts kan innehålla underscheman som distribuerats som en del av huvuddiagrammets version.
Med kommandot helm dependency kan du hantera beroenden som ingår från en Helm-lagringsplats. Kommandot använder metadata som definierats i avsnittet dependencies i diagrammets värdefil. Du anger namn, versionsnummer och lagringsplats varifrån underschemat ska installeras. Här är ett utdrag av en values.yaml fil som har ett MongoDB-diagram listat som ett beroende:
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
När beroendemetadata har definierats kör du kommandot helm dependency build för att hämta det tar-paketerade diagrammet. Kommandot chart build laddar ned diagrammet till mappen charts/.
helm dependency build ./app-chart
Deldiagram hanteras separat från huvuddiagrammet och kan behöva uppdateras när nya versioner blir tillgängliga. Kommandot för att uppdatera underscheman är helm dependency update. Det här kommandot hämtar nya versioner av underschemat när inaktuella paket tas bort.
helm dependency update ./app-chart
Tänk på att ett diagramberoende inte är begränsat till andra program. Du kan välja att återanvända malllogik i dina diagram och skapa ett beroende specifikt för att hantera den här logiken som ett diagramberoende. Du får ett exempel på den här strategin i nästa övning.
Hur man uppgraderar en Helm-utgåva
Helm tillåter uppgradering av befintliga versioner som en delta av alla ändringar som gäller för diagrammet och dess beroenden.
Anta till exempel att utvecklingsteamet i exemplet webapp i den här lektionen gör kodändringar som endast påverkar webbplatsens funktioner. Teamet gör följande uppdateringar av Chart.yaml-filen för att återspegla den nya versionen av programmet:
- Uppdaterar webbappens containeravbildning och taggar avbildningen som
webapp: linux-v2när avbildningen skickas till containerregistret. - Uppdaterar
dockerTag-värdet tilllinux-v2och diagrammets versionsvärde till0.2.0i diagrammets värdefil.
Här är ett exempel på den uppdaterade values.yaml-filen:
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"
I stället för att avinstallera en aktuell version använder du kommandot helm upgrade för att uppgradera den befintliga Helm-versionen.
helm upgrade my-app ./app-chart
Kom ihåg att Helm genererar ett delta av de ändringar som gjorts i Helm-diagrammet när du uppgraderar en version. Därför uppgraderar en Helm-uppgradering endast de komponenter som identifieras i deltat. I exemplet återdistribueras endast webbplatsen.
När uppgraderingen är klar kan du granska distributionshistoriken för versionen med hjälp av kommandot helm history med versionsnamnet.
helm history my-app
Historikkommandot returnerar flera fält som beskriver versionen, enligt följande exempelutdata:
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
Observera fältet revision i resultatet. Helm spårar versionsinformation för alla versioner som släpptes för ett Helm-diagram. När du installerar en ny version av ett Helm-diagram ökar revisionsantalet med en och den nya versionsinformationen matchas med den revisionen.
Här är ett exempel på samma historikkommando som körs efter installation av en ny version av webbappen.
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
Så här återställer du en Helm-version
Helm tillåter återställning av en befintlig Helm-version till en tidigare installerad version. Kom ihåg från tidigare att Helm spårar information om alla releaser av ett Helm chart.
Du använder kommandot helm rollback för att återställa till en specifik Helm-versionsrevision. Det här kommandot använder två parametrar. Den första parametern identifierar namnet på versionen och den andra identifierar versionsrevisionsnumret.
helm rollback my-app 2
Kommandot helm rollback återställer versionsversionen av appen till den angivna revisionen och uppdaterar appens versionshistorik. En uppföljningskörning av kommandot helm history visar det senaste aktiva revisionsnumret som den senaste releaseposten.
Anta till exempel att utvecklingsteamet i exemplet webapp i den här enheten upptäcker en bugg i webbprogrammet för drönarspårning och måste återställas till en tidigare version. I stället för att avinstallera den aktuella versionen och installera en tidigare version återställs de till den fungerande versionen.
helm rollback my-app 1
När en återställning har slutförts kan du granska distributionshistoriken med hjälp av kommandot 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
Observera hur beskrivningsfältet visar återställningens revisionsnummer för att göra det enklare för dig att spåra ändringar.