Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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 att man genom att sätta ett fåtal parametrar kan generera en komplett pipeline. Det innebär också att uppdateringar kan göras centralt och pushas ut till många pipelines.

Gemensam pipeline chart

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

Användning

För att använda spring-boot-pipeline chart skapas en ny chart som pekar ut spring-boot-pipeline som ett dependency. Mikrotjänstens nya chart använder spring-boot-pipeline chart 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

dependencies:
  - name: spring-boot-pipeline
    version: ^0.2.*
    repository: http://nexus.sundsvall.se/repository/sundsvall-helm/

Mikrotjänstens chart behöver inte pushas till det Helm repository som finns i nexus. Om man i Argo 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 generera chart i current working directory:

$ helm template .

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:

metadata:
{{- if .Values.parameterName }}
  myMetadata: {{ .Values.parameterName }}
{{- end}}

  • No labels