Helmfile abil k8s keskkondade juurutamise korraldamine

Helmfile — mähis helm'i jaoks helm, mis võimaldab ühes kohas kirjeldada mitut helm'i väljaannet, neid mitme keskkonna jaoks parametreerida ning määrata nende juurutamise järjekorra.

Helmfile’ist ja selle kasutamise näidetest saab lugeda readme ja parimate praktikate juhendist.

Tutvume vähem ilmsete viisidega, kuidas väljaandeid helmfile’is kirjeldada

Oletame, et meil on hunnik helm-kaarte (näiteks postgres ja mõni backend rakendus) ja mitmed keskkonnad (mitmed kubernetes klastrid, mitmed namespace'id või mõlemad). Võtame helmfile'i, loeme dokumentatsiooni ja hakkame kirjeldama meie keskkondi ja väljaandeid:

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

helmfile.yaml

keskkonnad:
  devel:
  production:

väljaanded:
  - nimi: postgres
    sildid:
      rakendus: postgres
    oota: tõene
    kaart: stable/postgresql
    versioon: 8.4.0
    väärtused:
      - envs/{{ .Environment.Name }}/values/postgres.yaml
  - nimi: backend
    sildid:
      rakendus: backend
    oota: tõene
    kaart: private-helm-repo/backend
    versioon: 1.0.5
    vajab:
      - postgres
    väärtused:
      - envs/{{ .Environment.Name }}/values/backend.yaml

Meil on 2 keskkonda: devel, production — igas on oma väärtused helm'i kaartide väljaannete jaoks. Me hakkame neid juurutama nii:

helmfile -n  -e  apply

Erinevad versioonid helm'i kaartidest erinevates keskkondades

Mis saab siis, kui meil on vaja välja lasta erinevaid backend-versioone erinevates keskkondades? Kuidas parametreerida väljaande versioon? Siin tulevad appi keskkonna väärtused, mis on saadaval läbi {{ .Values }}

helmfile.yaml

keskkonnad:
  devel:
+   väärtused:
+   - kaardid:
+       versioonid:
+         backend: 1.1.0
  production:
+   väärtused:
+   - kaardid:
+       versioonid:
+         backend: 1.0.5
...
  - nimi: backend
    sildid:
      rakendus: backend
    oota: tõene
    kaart: private-helm-repo/backend
-   versioon: 1.0.5
+   versioon: {{ .Values.charts.versions.backend }}
...

Erinev rakenduste komplekt erinevates keskkondades

Suurepärane, kuid mis siis, kui me ei pea production välja laskma postgres, sest me teame, et andmebaasi pole vaja k8s-sse panna ja meil on tootmises suurepärane eraldi postgres klaster? Selle probleemi lahendamiseks on meil sildid (labels)

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

See, but personally I prefer to describe which applications to deploy in the environment not through launch arguments, but in the description of the environments themselves. What to do? You can put the release descriptions in a separate folder, create a list of required releases in the environment description, and 'attach' only the needed releases, ignoring the rest.

    .
    ├── envs
    │   ├── 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

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend

- 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: {{ .Values.charts.versions.backend }}
-     needs:
-       - postgres
-     values:
-       - envs/{{ .Environment.Name }}/values/backend.yaml
+ ---
+ bases:
+ {{- range .Values.apps }}
+   - releases/{{ . }}.yaml
+ {{- end }}

releases/postgres.yaml

releases:
  - name: postgres
    labels:
      app: postgres
    wait: true
    chart: stable/postgresql
    version: 8.4.0
    values:
      - envs/{{ .Environment.Name }}/values/postgres.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/{{ .Environment.Name }}/values/backend.yaml

Note

Kasutades bases: it is necessary to use the YAML separator ---, to allow templating releases (and other parts, such as helmDefaults) with values from environments

In this case, the postgres release won't even be included in the production description. Very convenient!

Overridable global values for releases

Of course, it is great that you can specify values for helm charts for each environment, but what if we have several environments described, and we want to set the same for all, for example affinity, but we do not want to configure it as default in the charts themselves that are stored in the repositories.

In this case, we could specify 2 value files for each release: the first with default values that will determine the chart's values, and the second with values for the environment, which will in turn override the defaults.

    .
    ├── 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"

Määratlege globaalsete väärtuste helmi kaardid kõigi väljalaskete tasemel

Eeldame, et meil luuakse mitmes väljalaskes mitu ingressi — saaksime need iga kaardi jaoks käsitsi määratleda. hosts:, kuid meie juhul on domeen sama, miks mitte viia see globaalsesse muutuja ja lihtsalt sisestada selle väärtus kaartidesse? Selleks peavad need values-failid, mida soovime parametriseerida, olema laiendiga .gotmpl, et helmfile teaks, et see tuleb martid läbi šablonisüsteemi.

    .
    ├── 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

Ilmselt on ingress postgres'i chart'is midagi äärmiselt kahtlast, seetõttu on artikkel selle esitanud lihtsalt kui sfäärilist näidet vaakumis ja selleks, et mitte tuua sisse mingit uut versiooni lihtsalt ingress'i kirjeldamiseks.

Salajaste väärtuste (secrets) sisestamine keskkonna väärtustest.

Sarnaselt eelnevale näiteks on võimalik sisestada ka krüptitud väärtusi, kasutades helm secrets väärtusi. Selle asemel, et iga väljaande jaoks luua oma salajaste (secrets) fail, milles määratleda šifreeritud väärtused chart'i jaoks, saame lihtsalt määrata väljaande default.yaml.gotmpl failis väärtused, mis võetakse keskkonna tasandil määratud muutujatest. Ja väärtused, mida ei pea kellegi eest varjama, võib juba rahulikult üle kirjutada väljaande väärtustes konkreetses keskkonnas.

    .
    ├── 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

  keskkonnad:
    devel:
      väärtused:
      - kaardid:
          versioonid:
            backend: 1.1.0
      - rakendused:
        - postgres
        - backend
      - globaalne:
          ingressDomain: k8s.devel.domain
+     salajased:
+       - envs/devel/secrets.yaml

    production:
      väärtused:
      - kaardid:
          versioonid:
            backend: 1.0.5
      - rakendused:
        - backend
      - globaalne:
          ingressDomain: production.domain
+     salajased:
+       - envs/production/secrets.yaml
  ---
  alused:
  {{- range .Values.apps }}
    - releases/{{ . }}.yaml
  {{- end }}

envs/devel/secrets.yaml

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

envs/production/secrets.yaml

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

envs/default/values/backend.yaml.gotmpl

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

envs/devel/values/backend.yaml

elasticsearch:
  host: elastic-0.devel.domain

envs/production/values/backend.yaml

elasticsearch:
  host: elastic-0.production.domain

Note

Muide, getOrNil — spetsiaalne funktsioon go mallide jaoks helmfile'is, mis isegi juhul, kui .Values.secrets ei eksisteeri, ei tekita viga, vaid võimaldab tulemuseks koos funktsiooniga Seejärel käivitame exec käsu ja ootame 5000 sekundit, et jätkata jälgimist: müüda vaikimisi väärtust.

Kokkuvõte

Kirjeldatud asjad tunduvad üsna ilmsed, kuid teave helmfile abil mitme keskkonna juurutamise mugavast kirjeldusest on väga puudulik. Mulle meeldib IaC (Infrastructure-as-Code) ja soovin omada selget juurutamise oleku kirjeldust.

Kokkuvõtteks tahan lisada, et vaikekeskkonna muutujad saab omakorda parameteriseerida operatsioonisüsteemi keskkonna muutujatega, millega juurutamine toimub, ja seeläbi luua dünaamilisi keskkondi.

helmfile.yaml

keskkonnad:
  vaikimisi:
    väärtused:
    - globaalne:
        klasterDomeen: {{ env "CLUSTER_DOMAIN" | default "cluster.local" }}
        sisenemisDomeen: {{ env "INGRESS_DOMAIN" }}

Allikas: habr.com