Page Comparison

För att man i varje ny mikrostjänst ska slippa skapa en pipeline från grunden och har en Helm chart tagits fram, som innebär kompletta manifest för varje tjänst används Helm chart. Detta medför att man genom att sätta ett fåtal parametrar kan generera en ett komplett pipelinemanifest. Det innebär också att uppdateringar kan göras centralt och pushas ut till många pipelinestjänster.

...

Gemensamma charts

Pipeline chart

Repository: https://gitlab.sundsvall.se/argocd/helm/spring-boot-pipeline
Namn: spring-boot-pipeline
producerar: Tekton pipeline

Service chart

Repository: https://gitlab.sundsvall.se/argocd/helm/spring-boot-chart
Namn: spring-boot-chart
producerar: Deployment manifest för tjänst

Användning

För att använda spring-boot-pipeline en gemensam chart skapas en ny chart som pekar ut spring-boot-pipeline den gemensamma charten som ett dependency. Mikrotjänstens nya chart använder spring-boot-pipeline chart den gemensamma charten som en subchart. Detta innebär att mikrotjänstens chart inte behöver ha några egna templates utan använder bara det som finns i subcharten.

...

Dependency pekar man ut i mikrotjänstens Chart.yaml

...

Mikrotjänstens chart behöver inte pushas till det Helm repository som finns i nexus. Om man i Argo cd CD pekar ut en katalog som innehåller en Chart.yaml används den direkt.

Generera kubernetes objekt

För att generera k8 objekt lokalt används Helm CLI. Innan man kan generera behöver man lägga till http://nexus.sundsvall.se/repository/sundsvall-helm/ som repo, se Helm Repo Add.

...

För att uppdatera dependency:

$ helm dependency update

Uppdatera spring-boot-pipeline chart

Beroende på vad man vill kunna göra override på och vad som ska vara default i charten finns olika sätt att utöka den.

Ny config i template fil

Om man utökar template fil direkt och “hård kodar” in något nytt blir det inte möjligt att ändra från service charten.

Exempel template/somefile.yaml:

metadata:
  myMetadata: "fixed value"

Här blir myMetadata alltid satt till samma värde och går inte att ändra.

Beroende på vad man lägger till får man tänka på hur man ska stega version.

Parametrisera värde från template fil

Om vi vill kunna göra override på värdet i förra exemplet behöver vi lyfta ut “fixed value” till values.yaml

Exempel template/somefile.yaml:

metadata:
  myMetadata: {{ .Values.parameterName }}

Exempel values.yaml:

parameterName: "fixed value"

Denna ändring blir bakåt kompatibel då myMetadata kommer att sättas till “fixed value” i alla fall. Men nu har man möjlighet i service charten att göra en override på detta värde.

Exempel på override från service chart value.yaml:

spring-boot-pipeline:
  parameterName: "new value"

Väljer man att inte sätta parameterName faller man tillbaka på spring-boot-pipeline value fil och har då den den som default.

Gör parameter mandatory

Vill man tvinga att ett värde måste sättas i service charten kan man nyttja “required” och utelämna värdet ur values.yaml.

Exempel template/somefile.yaml:

metadata:
  myMetadata: {{ required "parametername must be set!" .Values.parameterName }}

Exempel values.yaml:

# parameterName: ""

Här sätts aldrig något värde eftersom parameterName är bort kommenterad. När en service chart försöker genereras kommer “parameterName must be set!” skrivas ut om man inte sätter värdet.

Denna typ av ändring resulterar i en ny major version.

Skapa optional generering

Vill man lägga något som inte ska genereras som default utan bara när något är specificerat i service charten kan man använde if-block.

Exempel template/somefile.yaml:

...