Organisera distribution till flera k8s-miljöer med hjälp av helmfile

Helmfile - omslag för roder, som gör att du kan beskriva många rorsläpp på ett ställe, parametrisera deras diagram för flera miljöer och även ställa in ordningen för deras utplacering.

Du kan läsa om själva helmfile och exempel på dess användning i readme и guide för bästa praxis.

Vi kommer att bekanta oss med icke-uppenbara sätt att beskriva releaser i helmfile

Låt oss säga att vi har ett paket med styrdiagram (till exempel, låt oss säga postgres och någon backend-applikation) och flera miljöer (flera kubernetes-kluster, flera namnområden eller flera av båda). Vi tar rodret, läser dokumentationen och börjar beskriva våra miljöer och releaser:

    .
    ├── 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 slutade med 2 miljöer: devel, produktion — var och en innehåller sina egna värden för rodrets utlösningsdiagram. Vi kommer att distribuera till dem så här:

helmfile -n <namespace> -e <env> apply

Olika versioner av styrdiagram i olika miljöer

Vad händer om vi behöver rulla ut olika versioner av backend till olika miljöer? Hur parametriserar man releaseversionen? De miljövärden som finns tillgängliga genom {{ .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 }}
...

Olika applikationer i olika miljöer

Bra, men tänk om vi inte behöver production rulla ut postgres, eftersom vi vet att vi inte behöver skjuta in databasen i k8s och att vi har ett underbart separat postgres-kluster till salu? För att lösa detta problem har vi etiketter

helmfile -n <namespace> -e devel apply
helmfile -n <namespace> -e production -l app=backend apply

Detta är bra, men personligen föredrar jag att beskriva vilka applikationer som ska distribueras i miljön, inte med hjälp av startargument, utan i beskrivningen av själva miljöerna. Vad ska man göra? Du kan placera utgivningsbeskrivningarna i en separat mapp, skapa en lista över nödvändiga utgåvor i miljöbeskrivningen och "plocka upp" endast de nödvändiga utgåvorna, ignorera resten

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

Anteckningen

När du använder bases: det är nödvändigt att använda yaml separator ---, så att du kan mallsläpp (och andra delar, såsom helmDefaults) med värden från miljöer

I det här fallet kommer postgres-releasen inte ens att ingå i beskrivningen för produktion. Mycket bekvämt!

Åsidosättbara globala värden för releaser

Naturligtvis är det bra att du kan ställa in värden för styrdiagram för varje miljö, men tänk om vi har flera miljöer beskrivna, och vi vill till exempel ställa samma för alla affinity, men vi vill inte konfigurera det som standard i själva diagrammen, som lagras i rovor.

I det här fallet kan vi för varje utgåva specificera 2 filer med värden: den första med standardvärden, som kommer att bestämma värdena för själva diagrammet, och den andra med värden för miljön, som i sin tur kommer att åsidosätta standard.

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

Definierar globala värden för styrdiagram över alla utgåvor på miljönivå

Låt oss säga att vi skapar flera ingångar i flera utgåvor - vi skulle kunna definiera manuellt för varje diagram hosts:, men i vårt fall är domänen densamma, så varför inte lägga den i någon global variabel och helt enkelt ersätta dess värde i diagrammen? För att göra detta måste de filer med värden som vi vill parametrisera ha tillägget .gotmpl, så att helmfile vet att den måste köras genom mallmotorn.

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

Anteckningen

Uppenbarligen är ingress i postgres-diagrammet något extremt tveksamt, så den här artikeln ges helt enkelt som ett sfäriskt exempel i ett vakuum och för att inte introducera någon ny version i artikeln bara för att beskriva ingressen

Ersätter hemligheter från miljövärden

I analogi med exemplet ovan kan du ersätta krypterade med hjälp av rodrets hemligheter betydelser. Istället för att skapa vår egen hemlighetsfil för varje utgåva, där vi kan definiera krypterade värden för diagrammet, kan vi helt enkelt definiera i utgåvan default.yaml.gotmpl värdena som kommer att tas från variablerna som definieras vid miljönivå. Och de värden som vi inte behöver dölja för någon kan enkelt omdefinieras i releasevärdena i en specifik 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

Anteckningen

Förresten, getOrNil - en speciell funktion för go-mallar i helmfile, som även om .Values.secrets kommer inte att existera, kommer inte att ge ett fel, men kommer att tillåta resultatet med funktionen default ersätt standardvärde

Slutsats

De saker som beskrivs verkar ganska självklara, men information om en bekväm beskrivning av utplacering till flera miljöer med hjälp av helmfile är mycket knapphändig, och jag älskar IaC (Infrastructure-as-Code) och vill ha en tydlig beskrivning av driftsättningstillståndet.

Avslutningsvis skulle jag vilja tillägga att variablerna för standardmiljön i sin tur kan parametriseras med miljövariablerna för operativsystemet för en viss löpare från vilken distributionen kommer att startas, och på så sätt erhålla dynamiska miljöer

helmfile.yaml

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

Källa: will.com