Gestire una versione Helm
Come usare le funzioni in un modello Helm
Il linguaggio del modello Helm definisce le funzioni usate per trasformare i valori del file values.yaml. La sintassi di una funzione segue la struttura {{ functionName arg1 arg2 ... }}. Esaminare la funzione quote per vedere un esempio di questa sintassi.
La funzione quote racchiude un valore tra virgolette per indicare l'uso di un oggetto string. Si supponga di definire il file values.yaml seguente:
apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
enabled: true
Si decide di voler usare il valore ingress.enabled come valore booleano per determinare se è necessario generare un manifesto di ingresso. Per usare il valore enabled come valore booleano, è necessario fare riferimento al valore usando {{ .Values.ingress.enabled }}.
Successivamente si deciderà di visualizzare il campo come stringa nel file templates/Notes.txt. Poiché le regole di coercizione dei tipi YAML possono dare luogo a bug difficili da individuare nei modelli, si decide di seguire le indicazioni ed essere espliciti quando si includono stringhe nei modelli. Ad esempio, enabled: false non equivale a enabled: "false".
Per visualizzare il valore come stringa, usare {{ quote .Values.ingress.enabled }} per fare riferimento al valore booleano come una stringa.
Come usare le pipeline in un modello Helm
Usare le pipeline quando più di una funzione deve agire su un valore. Una pipeline consente di inviare un valore oppure il risultato di una funzione a un'altra funzione. È ad esempio possibile riscrivere la funzione quote precedente come {{ .Values.ingress.enabled | quote }}. Si noti che | indica che il valore viene inviato alla funzione quote.
Di seguito è riportato un altro esempio. Si supponga di voler convertire un valore in lettere maiuscole e racchiuderlo tra virgolette. È possibile scrivere l'istruzione come {{ .Values.ingress.enabled | upper | quote }}. Si noti che il valore viene elaborato dalla funzione upper e quindi dalla funzione quote.
Il linguaggio del modello include più di 60 funzioni che consentono di esporre, cercare e trasformare valori e oggetti nei modelli.
Come usare il controllo del flusso condizionale in un modello Helm
Il controllo del flusso condizionale consente di decidere la struttura o i dati inclusi nel file manifesto generato. Ad esempio, si potrebbe voler includere valori diversi in base alla destinazione della distribuzione o controllare se viene generato un file manifesto.
Il blocco if / else è una struttura di flusso di controllo di questo tipo, conforme al layout seguente:
{{ if | pipeline | }}
# Do something
{{ else if | other pipeline | }}
# Do something else
{{ else }}
# Default case
{{ end }}
Si supponga di decidere che il file manifesto di ingresso per un chart viene creato solo in casi specifici. L'esempio seguente illustra come eseguire questa operazione usando un'istruzione if:
{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{ end }}
Tenere presente che è possibile usare i segnaposto per popolare i metadati nel modello. I file modello vengono analizzati e valutati in sequenza dal linguaggio del modello dall'alto verso il basso. Nell'esempio precedente il motore di modelli genera il contenuto del file manifesto solo se il valore di .Values.ingress.enabled è true.
Quando il motore di modelli elabora l'istruzione, rimuove il contenuto dichiarato all'interno della sintassi {{ }} e lascia lo spazio vuoto rimanente. Questa sintassi fa in modo che il motore di modelli includa una nuova riga per la riga dell'istruzione if. Se si lascia il contenuto del file precedente così com'è, si noterà la presenza di righe vuote nel file YAML e verrà generato il file manifesto di ingresso.
YAML dà un significato allo spazio vuoto. È per questo che le tabulazioni, gli spazi e i caratteri di nuova riga sono considerati importanti. Per risolvere il problema degli spazi vuoti indesiderati, è possibile riscrivere il file nel modo seguente:
{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
name: ...
labels:
...
annotations:
...
spec:
rules:
...
{{- end }}
Si noti l'uso del carattere - come parte della sequenza iniziale {{- e finale -}} dell'istruzione. Il carattere - indica al parser di rimuovere gli spazi vuoti. {{- rimuove lo spazio vuoto all'inizio di una riga e -}} alla fine di una riga, incluso il carattere di nuova riga.
Come scorrere una raccolta di valori in un modello Helm
YAML consente di definire raccolte di elementi e di usare singoli elementi come valori nei modelli. Per accedere agli elementi di una raccolta è possibile usare un indicizzatore. Il linguaggio del modello Helm supporta tuttavia l'iterazione di una raccolta di valori usando l'operatore range.
Si supponga di definire un elenco di valori nel file values.yaml per indicare host in ingresso aggiuntivi. Ecco un esempio dei valori:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Usare l'operatore range per consentire al motore di modelli di scorrere .Values.ingress.extraHosts. Il frammento di codice seguente mostra un esempio condensato che usa l'operatore 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 }}
Come controllare l'ambito de valori in un modello Helm
Quando sono presenti valori definiti con diversi livelli di profondità, la sintassi può diventare lunga e complessa se questi valori vengono inclusi in un modello. L'azione with consente di limitare l'ambito delle variabili in un modello.
Tenere presente che l'oggetto . usato in un modello Helm fa riferimento all'ambito corrente. Ad esempio, .Values indica al motore di modelli di trovare l'oggetto Values nell'ambito corrente. Si supponga di usare il file values.yaml precedente per creare un file manifesto della mappa di configurazione:
ingress:
enabled: true
extraHosts:
- name: host1.local
path: /
- name: host2.local
path: /
- name: host3.local
path: /
Anziché accedere al valore del percorso di ogni elemento usando {{ .Values.ingress.extraHosts.path }}, è possibile usare l'azione with. Il frammento di codice seguente mostra un esempio che usa l'operatore range per generare un file manifesto della mappa di configurazione:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
{{ end }}
{{- with .Values.ingress.extraHosts }} limita l'ambito dei valori alla matrice .Values.ingress.extraHosts.
L'azione with restringe l'ambito. Non è possibile accedere ad altri oggetti dall'ambito padre. Si supponga di voler accedere all'oggetto {{ .Release.Name }} del chart nel blocco di codice with. Per accedere agli oggetti padre, è necessario indicare l'ambito radice usando il carattere $ oppure riscrivere il codice. Ecco il codice aggiornato che mostra come includere gli oggetti padre usando il carattere $:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
{{- with .Values.ingress.extraHosts }}
hostname: {{ .name }}
path: {{ .path }}
release: {{ $.Release.Name}}
{{ end }}
Nota
Nel linguaggio del modello Helm sono disponibili diversi costrutti per il controllo del flusso. L'unità di riepilogo di questo modulo include una sezione con collegamenti alla documentazione di Helm per maggiori informazioni.
Come definire le dipendenze del chart in Helm
Un chart consente di dichiarare le dipendenze per supportare l'applicazione principale e fa parte della versione installata.
È possibile creare un chart secondario usando il comando helm create, specificando la posizione del nuovo chart nella cartella /charts oppure usando il comando helm dependency. Tenere presente che la cartella /charts può contenere chart secondari distribuiti come parte della versione del chart principale.
Il comando helm dependency consente di gestire le dipendenze incluse da un repository Helm. Il comando usa i metadati definiti nella sezione dependencies del file dei valori del chart. Specificare il nome, il numero di versione e il repository da cui installare il chart secondario. Di seguito è riportato un estratto di un file values.yaml con un chart MongoDB elencato come dipendenza:
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
Una volta definiti i metadati delle dipendenze, eseguire il comando helm dependency build per recuperare il chart nel pacchetto tar. Il comando di creazione del chart scarica il chart nella cartella charts/.
helm dependency build ./app-chart
I chart secondari vengono gestiti separatamente dal chart principale e potrebbero richiedere aggiornamenti quando diventano disponibili nuove versioni. Il comando per aggiornare i chart secondari è helm dependency update. Questo comando recupera le nuove versioni del chart secondario eliminando i pacchetti obsoleti.
helm dependency update ./app-chart
Tenere presente che una dipendenza del chart non è limitata ad altre applicazioni. È possibile decidere di riutilizzare la logica del modello nei chart e creare una dipendenza specificamente per gestire questa logica come dipendenza del chart. Nell'esercizio successivo si vedrà un esempio di questa strategia.
Come aggiornare una versione Helm
Helm consente di aggiornare le versioni esistenti come delta di tutte le modifiche che si applicano al chart e alle relative dipendenze.
Si supponga, ad esempio, che il team di sviluppo dell'esempio webapp in questa unità apporti modifiche al codice che influiscono solo sulle funzionalità del sito Web. Il team apporta gli aggiornamenti seguenti al file Chart.yaml per riflettere la nuova versione dell'applicazione:
- Aggiorna l'immagine del contenitore dell'app Web e contrassegna l'immagine come
webapp: linux-v2quando viene eseguito il push dell'immagine nel registro contenitori. - Aggiorna quindi il valore
dockerTaginlinux-v2e il valore della versione del chart in0.2.0nel file dei valori del chart.
Di seguito è riportato un esempio del file values.yaml aggiornato:
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"
Invece di disinstallare una versione corrente, si usa il comando helm upgrade per aggiornare la versione di Helm esistente.
helm upgrade my-app ./app-chart
Tenere presente che Helm genera un delta delle modifiche apportate al chart Helm quando si aggiorna una versione. Di conseguenza, un aggiornamento Helm aggiorna solo i componenti identificati nel delta. In questo esempio viene ridistribuito solo il sito Web.
Dopo il completamento dell'aggiornamento, è possibile esaminare la cronologia di distribuzione della versione usando il comando helm history con il nome della versione.
helm history my-app
Il comando history restituisce diversi campi che descrivono la versione, come illustrato nell'output di esempio seguente:
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
Si noti il campo revision nel risultato. Helm tiene traccia delle informazioni sulla versione per tutte le versioni di un chart Helm. Quando si installa una nuova versione di un chart Helm, il numero di revisione aumenta di uno e le informazioni sulla nuova versione vengono associate a tale revisione.
Di seguito è riportato un esempio dell'esecuzione dello stesso comando history in seguito all'installazione di una nuova versione dell'app 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
Come eseguire il rollback di una versione Helm
Helm consente di eseguire il rollback di una versione Helm esistente a una versione installata in precedenza. Come si è visto in precedenza, Helm tiene traccia delle informazioni sulla versione per tutte le versioni di un chart Helm.
Usare il comando helm rollback per eseguire il rollback a una revisione della versione Helm specifica. Questo comando usa due parametri. Il primo parametro identifica il nome della versione e il secondo identifica il numero di revisione della versione.
helm rollback my-app 2
Il comando helm rollback esegue il rollback della versione dell'app alla revisione specificata e aggiorna la cronologia delle versioni dell'app. Un'esecuzione successiva del comando helm history mostra il numero di revisione attiva più recente come ultima voce della versione.
Si supponga, ad esempio, che il team di sviluppo dell'esempio webapp in questa unità rilevi un bug nell'applicazione Web di rilevamento droni e debba eseguire il rollback a una versione precedente. Invece di disinstallare la versione corrente e installare una versione precedente, il team esegue il rollback alla versione funzionante.
helm rollback my-app 1
Dopo il completamento del rollback, è possibile esaminare la cronologia di distribuzione usando il comando 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
Si noti che il campo description mostra il numero di revisione del rollback per semplificare il rilevamento delle modifiche.