Implementering af deployment i flere k8s-miljøer ved hjælp af helmfile

Helmfile — et wrapper til helm, som gør det muligt at beskrive mange helm releases på ét sted, parametrisere deres charts til flere miljøer og også angive rækken for deres deployment.

Om helmfile og eksempler på dets brug kan læses i readme og bedste praksis guide.

Vi vil møde nogle uventede måder at beskrive releases i helmfile på

Lad os sige, at vi har en række helm charts (for eksempel postgres og en backend applikation) og flere miljøer (flere Kubernetes klynger, flere namespaces eller en kombination af begge). Vi tager helmfile, læser dokumentationen og begynder at beskrive vores miljøer og releases:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

environments:
  devel:
  production:

releases:
  - name: postgres
    labels:
      app: postgres
    wait: true
    chart: stable/postgresql
    version: 8.4.0
    values:
      - envs/{{ .Environment.Name }}/values/postgres.yaml
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
    version: 1.0.5
    needs:
      - postgres
    values:
      - envs/{{ .Environment.Name }}/values/backend.yaml

Vi har fået 2 miljøer: devel, production — i hver af dem er der sine værdier for helm charts af releases. Vi vil deploye i dem sådan her:

helmfile -n  -e  apply

Forskellige versioner af helm charts i forskellige miljøer

Hvad skal vi gøre, hvis vi skal rulle forskellige versioner af backend ud i forskellige miljøer? Hvordan kan vi parameterisere versionen af et release? Her kommer miljøværdierne ind, der er tilgængelige via {{ .Values }}

helmfile.yaml

environments:
  devel:
+   values:
+   - charts:
+       versions:
+         backend: 1.1.0
  production:
+   values:
+   - charts:
+       versions:
+         backend: 1.0.5
...
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
-   version: 1.0.5
+   version: {{ .Values.charts.versions.backend }}
...

Forskellige sæt af applikationer i forskellige miljøer

Godt, men hvad hvis vi ikke har brug for at production rulle postgres ud, fordi vi ved, at vi ikke skal have databasen i k8s, og til produktion har vi en fantastisk separat postgres klynge? For at løse dette problem har vi labels

helmfile -n  -e devel apply
helmfile -n  -e production -l app=backend apply

Det er fantastisk, men personligt foretrækker jeg at beskrive, hvilke applikationer der skal implementeres i miljøet, ikke ved hjælp af opstartargumenter, men i selve miljøbeskrivelserne. Hvad gør man? Man kan placere versionbeskrivelserne i en separat mappe, oprette en liste over nødvendige versioner i miljøbeskrivelsen og "tilknytte" kun de nødvendige versioner og ignorere de øvrige.

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
+   ├── releases
+   │   ├── backend.yaml
+   │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  miljøer:
    devel:
      værdier:
      - charts:
          versioner:
            backend: 1.1.0
      - apps:
        - postgres
        - backend

    production:
      værdier:
      - charts:
          versioner:
            backend: 1.0.5
      - apps:
        - backend

- releases:
-    - navn: postgres
-      labels:
-        app: postgres
-      vent: true
-      chart: stable/postgresql
-      version: 8.4.0
-      værdier:
-        - envs/{{ .Environment.Name }}/values/postgres.yaml
-    - navn: backend
-      labels:
-        app: backend
-      vent: true
-      chart: private-helm-repo/backend
-     version: {{ .Values.charts.versions.backend }}
-     behov:
-       - postgres
-     værdier:
-       - envs/{{ .Environment.Name }}/values/backend.yaml
+ ---
+ baser:
+ {{- range .Values.apps }}
+   - releases/{{ . }}.yaml
+ {{- end }}

releases/postgres.yaml

releases:
  - navn: postgres
    labels:
      app: postgres
    vent: true
    chart: stable/postgresql
    version: 8.4.0
    værdier:
      - envs/{{ .Environment.Name }}/values/postgres.yaml

releases/backend.yaml

releases:
  - navn: backend
    labels:
      app: backend
    vent: true
    chart: private-helm-repo/backend
    version: {{ .Values.charts.versions.backend }}
    behov:
      - postgres
    værdier:
      - envs/{{ .Environment.Name }}/values/backend.yaml

Note

Ved brug af baser: det er nødvendigt at bruge yaml-separator. ---, så man kan anvende releases (og andre dele, såsom helmDefaults) med værdier fra miljøerne.

I så fald vil postgres-versionen ikke engang være med i beskrivelsen for produktion. Meget praktisk!

Globale værdier til overskrivning for versioner.

Det er selvfølgelig fantastisk, at man kan angive værdier for helm charts for hvert miljø, men hvad hvis vi har beskrevet flere miljøer, og vi ønsker, for eksempel, at angive en værdi, som skal være den samme for alle. affinity, men ikke ønsker at indstille det som standard i selve charts, der er gemt i repoerne.

I så fald kunne vi for hver version angive 2 filer med værdier: en første med standardværdierne, der vil bestemme chartets værdier, og den anden med værdierne for miljøet, som så vil overskrive standarderne.

    .
    ├── envs
+   │   ├── default
+   │   │   └── values
+   │   │       ├── backend.yaml
+   │   │       └── postgres.yaml
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

releases/backend.yaml

releases:
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
    version: {{ .Values.charts.versions.backend }}
    needs:
      - postgres
    values:
+     - envs/default/values/backend.yaml
      - envs/{{ .Environment.Name }}/values/backend.yaml

envs/default/values/backend.yaml

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - backend
        topologyKey: "kubernetes.io/hostname"

Definition of global values for helm charts of all releases at the environment level

Suppose we create several ingress in multiple releases — we could manually define this for each chart hosts:, but in our case the domain is the same, so why not pull it out into a global variable and just substitute its value into the charts? For this, the files with values that we want to parameterize should have the extension .gotmpl, so that helmfile knows to process them through the templater.

    .
    ├── envs
    │   ├── default
    │   │   └── values
-   │   │       ├── backend.yaml
-   │   │       ├── postgres.yaml
+   │   │       ├── backend.yaml.gotmpl
+   │   │       └── postgres.yaml.gotmpl
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  environments:
    devel:
      values:
      - charts:
          versions:
            backend: 1.1.0
      - apps:
        - postgres
        - backend
+     - global:
+         ingressDomain: k8s.devel.domain

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend
+     - global:
+         ingressDomain: production.domain
  ---
  bases:
  {{- range .Values.apps }}
    - releases/{{ . }}.yaml
  {{- end }}

envs/default/values/backend.yaml.gotmpl

ingress:
  enabled: true
  paths:
    - /api
  hosts:
    - {{ .Values.global.ingressDomain }}

envs/default/values/postgres.yaml.gotmpl

ingress:
  enabled: true
  paths:
    - /
  hosts:
    - postgres.{{ .Values.global.ingressDomain }}

Note

Det er åbenlyst, at ingress i Postgres-chartet er noget ekstremt tvivlsomt, så det nævnes i artiklen blot som et sfærisk eksempel i et vakuum og for at undgå at introducere en ny version kun for at beskrive ingress.

Indsættelse af hemmeligheder (secrets) fra miljøvariabler.

På samme måde som det ovenfor nævnte eksempel kan man indsætte værdier, der er krypteret med helm secrets . I stedet for at oprette en unik secrets-fil for hver version, hvor der bestemmes krypterede værdier for chartet, kan vi blot definere værdier i releases default.yaml.gotmpl, som vil blive hentet fra variabler angivet på miljøniveau. Og værdier, som vi ikke behøver at skjule fra nogen, kan vi trygt overskrive i release-værdierne i det specifikke miljø.

    .
    ├── envs
    │   ├── default
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   ├── devel
    │   │   ├── values
    │   │   │   ├── backend.yaml
    │   │   │   └── postgres.yaml
+   │   │   └── secrets.yaml
    │   └── production
    │       ├── values
    │       │   ├── backend.yaml
    │       │   └── postgres.yaml
+   │       └── secrets.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  environments:
    devel:
      values:
      - charts:
          versions:
            backend: 1.1.0
      - apps:
        - postgres
        - backend
      - global:
          ingressDomain: k8s.devel.domain
+     secrets:
+       - envs/devel/secrets.yaml

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend
      - global:
          ingressDomain: production.domain
+     secrets:
+       - envs/production/secrets.yaml
  ---
  bases:
  {{- range .Values.apps }}
    - releases/{{ . }}.yaml
  {{- end }}

envs/devel/secrets.yaml

secrets:
    elastic:
        password: ENC[AES256_GCM,data:hjCB,iv:Z1P6/6xBJgJoKLJ0UUVfqZ80o4L84jvZfM+uH9gBelc=,tag:dGqQlCZnLdRAGoJSj63rBQ==,type:int]
...

envs/production/secrets.yaml

secrets:
    elastic:
        password: ENC[AES256_GCM,data:ZB/VpTFk8f0=,iv:EA//oT1Cb5wNFigTDOz3nA80qD9UwTjK5cpUwLnEXjs=,tag:hMdIUaqLRA8zuFBd82bz6A==,type:str]
...

envs/default/values/backend.yaml.gotmpl

elasticsearch:
  host: elasticsearch
  port: 9200
  password: {{ .Values | getOrNil "secrets.elastic.password" | default "password" }}

envs/devel/values/backend.yaml

elasticsearch:
  host: elastic-0.devel.domain

envs/production/values/backend.yaml

elasticsearch:
  host: elastic-0.production.domain

Note

Forresten, getOrNil — en speciel funktion til go-skabeloner i helmfile, som, selv hvis .Values.secrets ikke eksisterer, ikke kaster en fejl, men muliggør at bruge funktionen default til at indsætte en standardværdi.

Konklusion

De beskrevne ting virker ret åbenlyse, men informationen om praktisk beskrivelse af deployment i flere miljøer med helmfile er meget begrænset, og jeg elsker IaC (Infrastructure-as-Code) og ønsker en klar beskrivelse af deployment state.

Afslutningsvis vil jeg tilføje, at variablerne for standardmiljøet kan parametriseres med miljøvariablerne fra et givet runner, som deploymenten vil blive kørt fra, og dermed skabe dynamiske miljøer.

helmfile.yaml

environments:
  default:
    values:
    - global:
        clusterDomain: {{ env "CLUSTER_DOMAIN" | default "cluster.local" }}
        ingressDomain: {{ env "INGRESS_DOMAIN" }}

Kilde: habr.com