Refactoring del Chart

Organizzazione

Vogliamo incrementalmente migliorare il chart prodotto, introducendo della parametrizzazione.

Il controllo versioni che usiamo è elementare:

cp -rf wordpress wordpress.1
  • salviamo la versione stabile corrente in wordpress.1
    • poi sarà wordpress.2, wordpress.3, ecc.
  • modifichiamo wordpress
  • rimaniamo sempre posizionati nella directory corrente, dando percorsi relativi

Generiamo anche un chart anvil, quello di esempio standard, da cui trarre spunto:

helm create anvil

Il file di templati viene copiato:

cp anvil/templates/_helpers.tpl wordpress/templates

OIn tale file, ogni occorrenza della stringa anvil deve essere sostituita con wordpress.

Il file wordpress/values.yaml invece lo generiamo passo a passo.

Note

Il chart di esempio presume che il nostro applicativo abbia un solo servizio, invece ne ha due: mysql e wordpress.

Ma possiamo considerare wordpress come servizio primario.

Prima Iterazione: Note per l'Utente

NOTES.txt

Copiamo il file dall'esempio standard e modifichiamolo:

cp anvil/templates/NOTES.txt wordpress/templates

Ogni occorrenza della stringa anvil deve essere sostituita con wordpress.

Per risolvere i riferimenti .Values del file editiamo e inseriamone i valori in values.yaml:

vim wordpress/values.yaml

service:
  type: LoadBalancer
  port: 8080

ingress:
  enabled: false

Occorre anche editare il Manifest del service di wordpress:

vim wordpress/templates/04wpress.yaml

E cambiare la sezione Service in :

apiVersion: v1
kind: Service
metadata:
  name: {{ include "wordpress.fullname" . }}
  labels:
    app: wordpress
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: 80
  selector:
    app: wordpress
    tier: frontend

Installazione e prova:

helm install myword wordpress

Escono i NOTES.

I comandi shell suggeriti funzionano:

export SERVICE_IP=$(kubectl get svc --namespace default myword-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo http://$SERVICE_IP:8080

http://172.18.255.201:8080

Diamo il comando di verifica:

kubectl get services

Notiamo che il servizio si chiama ora myword-wordpress e non semplicemente wordpress.

Apriamo un browser a http://172.18.255.201:8080 per verificare se funziona.

Oggetti Built-in

Helm ha una serie di oggetti predefiniti, come ad esempio {{ .Release.Name }} che abbiamo visto in NOTES.txt.

Sezione Release:

  • Release.Name
  • Release.Namespace
  • Release.IsUpgrade
  • Release.IsInstall
  • Release.Revision
  • Release.Service - sempre Helm

Sezione Values: oggetti definiti in values.yaml secondo la gerarchia Yaml e con notazione punto.

Sezione Chart: oggetti definiti in Chart.yaml secondo la gerarchia Yaml e con notazione punto.

Sezione Capabilities:

  • Capabilities.APIVersions - insieme di versioni
  • Capabilities.APIVersions.Has $version - indica se la versione $version è disponibile
  • Capabilities.KubeVersion - di Kubernetes
  • Capabilities.KubeVersion.Major
  • Capabilities.KubeVersion.Minor
  • Capabilities.HelmVersion
  • Capabilities.HelmVersion.GoVersion - versione del compilatore Go usata

Sezione Template:

  • Template.Name - il nome completo del Template corrente, incluso il percorso
  • Template.BasePath - solo il nome del Template corrente

Ha inoltre una serie di funzioni di gestione dei file:

  • Files.Get - ritorna il contenuto del file specificato come caratteri UTF-8 (rune in Go)
  • Files.GetBytes - ritorna il contenuto del file specificato come array di bytes
  • Files.Glob - ritorna una lista di files specificata da caratteri jolly
  • Files.Lines - ritorna un file linea per linea, utile nelle iterazioni
  • Files.AsSecrets - ritorna il contenuto di un file codificato in Base64
  • Files.AsConfig - ritorna un file codificato come mappa Yaml

NOTA

Una piccola guida all'arte di scrivere templati in Helm si trova a https://helm.sh/docs/chart_template_guide/

La documentazione generale è a https://helm.sh/docs/