Helm: reusable чарт – named templates, и общий чарт для нескольких приложений

Автор: | 18/10/2020
Нет комментариев
 

Проект активно развивается, Kubernetes прижился, и всё больше наших сайтов запускается в нём.

И со временем возникла вполне ожидаемая проблема, которая уже озвучивалась в самом начале нашего “путешествия” в Helm: пошаговое создание чарта и деплоймента из Jenkins – как быть с манифестами Kubernetes и шаблонами Helm для нескольких приложений?

Особенно остро она встала сейчас, когда у нас из одного и того же репозитория один и тот же код деплоится в три независимых бекенда трёх независимых приложений.

Сначала было одно, потом появилось второе, сейчас готовится к запуску третье.

В результате чарты сейчас выглядят так:

[simterm]

$ tree -d k8s/
k8s/
├── app1-chart
│   ├── charts
│   ├── env
│   │   ├── dev
│   │   ├── dev-2
│   │   └── prod
│   └── templates
└── app2-chart
    ├── charts
    ├── env
    │   ├── dev
    │   ├── prod
    │   └── stage
    └── templates

[/simterm]

И теперь копировать сюда тот же самый чарт третий раз?

Ну совсем не хочется.

А потому – посмотрим внимательнее на возможности шаблонизатора Helm-а, и попробуем сделать один чарт для трёх похожих приложений.

Со временем его можно будет расширить, и включить сюда все остальные.

Deployment – структура файла

Что бы продумать структуру общего шаблона – посмотрим, какие блоки общие, а какие будут различаться, и как мы их можем максимально гибко подключать.

Будем рассматривать только файл deployment.yaml – остальные шаблоны потом сделаем по его подобию.

Итак:

  • файл deployment.yaml:
    • metadata:
      • name: общий, значение будем брать из файла values.yaml конкретного проекта
      • annotations: общий, тут у нас только reloader.stakater.com/auto, и у всех он будет один и всегда true (хотя возможны варианты – см. Kubernetes: ConfigMap и Secrets — auto-reload данных в подах)
      • labels: общий, и будет использоваться в нескольких местах, например в деплойменте ниже – spec.template.metadata.labels, и в файле с Kubernetes Cronjobs – вынесем лейблы в _helpers.yaml
    • spec:
      • replicas: общий, значение будем брать из файла values.yaml конкретного проекта
      • strategy:
        • type: общий, значение будем брать из файла values.yaml конкретного проекта
      • selector:
        • matchLabels: общий, и будет использоваться в нескольких местах, например в Cronjobs и Services – вынесем в _helpers.yaml
      • template:
        • metadata:
          • labels: берём из _helpers.yaml
      • spec:
        • containers:
          • name: общий, значение будем брать из файла values.yaml конкретного проекта
          • image: общий, значение будем брать из файла values.yaml конкретного проекта
          • env: вот тут самое интересное:
            1. можем вынести целым блоком в values.yaml каждого проекта
              1. плюсы: не надо будет отдельно описывать сами значения – можем их указать прямо тут, в поле value самих переменных
              2. минусы:
                1. практически у всех одинаковые переменные – дублируем код между проектами
                2. раздутый файл values.yaml, т.к. переменных много
                3. не все переменные идут в виде КЛЮЧ:ЗНАЧЕНИЕ – некоторые будут брать значение через valueFrom.secretKeyRef.<KUBE_SECRET_NAME>, значит значение в values.yaml задать не выйдет
            2. можем включить в общий _helpers.yaml, и будет общий набор переменных, каждая заключена в свой if – если в values.yaml значение найдено, то переменная создаётся в общем шаблоне
            3. и на случай, если у проекта совершенно отдельный набор переменных – то в общем шаблоне перед блоком env можно добавить условие типа if {{ .Values.chartSettings.customEnvs == true }} – будем пропускать включение переменных из _helpers.yaml или values.yaml, и подключать файл шаблона через tpl .File.Get project1/envs.yaml
          • volumeMounts: тоже может различаться, посмотрим потом
          • ports:
          • livenessProbe, readinessProbe: в целом тоже будет общий, с httpGet.path и httpGet.port – можно вынести в _helpers.yaml, но добавить тоже условие customProbes, и при необходимости – подключать через .File.Get
          • resources:
          • volumes: – тоже может различаться, посмотрим потом
          • imagePullSecrets: одинаковый у всех
  • hpa.yaml – описываем HPA
  • network.yaml – Service, Ingress
  • secrets.yaml – Kubernetes Secrets
  • rbac.yaml – подключение пользовательских групп к создаваемым неймспейсам
  • cronjobs.yaml – Kubernetes Cronjobs
  • _helpers.tpl – и наш “помошник” – сюда ключим Helm Named Templates

Собственно, основная идея такая:

  • общий чарт с шаблонами, которые лежат в templates
    • в templates храним файлы deployment.yaml, hpa.yaml, _helpers.tpl, etc
  • рядом с templates создадим каталог projects
    • и внутри него – каталоги по имени проектов
      • project1
      • project2
      • project3
        • внутри каждого создадим каталог env
          • внутри которого будет dev, stage, prod
            • внутри которых будут отдельные values.yaml и secrets.yaml

Helm Named templates

Отличный пост на тему именованных шаблонов – How To Reduce Helm Chart Boilerplate With Named Templates (больше ссылок – в конце поста).

Официальная документация – тут>>>.

Первым в нашем шаблоне нам встретится блок labels, который мы хотим вынести в _helpers.yaml, и из него подключать в деплоймент и другие шаблоны.

Идея именованных шаблонов в том, что мы один раз пишем какой-то блок, который потом можем включать везде в нашем чарте. Плюс – они позволяют убрать из основного шаблона лишний код, что бы сделать его более красивым и лаконичным.

Файлы именованных шаблонов начинаются с _, и заканчиваются расширением .tpl.

Самый известный пример – _helpers.tpl, который и будем использовать.

Описание каждого шаблона в файле _helpers.tpl начинается с define, заканчивается end.

Имя именованного шаблона как правило включает в себя имя чарта и блока, который этот шаблон добавляет, но никто не мешает использовать любое другое, например в данном случае общее имя у них будет helpers.

Из неудобства – тут в именах нельзя явно использовать значения типа .Chart.Name – но можно создать переменную. Посмотрим – будем ли это делать, пока просто захардкодим имя helpers.

Общие labels

Какие вообще полезные лейблы можно добавить, которые были бы общими?

  • environment – Dev, Stage, Prod – будет подставляться из values.yaml
  • appversion – задаётся при билде в Jenkins через --set

Дальше моя фантазия иссякла, а потому спросим Google – “kubernetes recommended labels“, и находим первой же ссылкой Recommended Labels.

Плюс, см. Labels and Annotations в документации самого Helm.

Кроме того, можно посмотреть чарты каких-то готовых приложений, например – sonarqube/templates/deployment.yaml.

Значит, нам надо добавить пока четыре наших кастомных лейблы:

  • application: {{ .Values.appConfig.appName }}, будем задавать в values.yaml каждого приложения
  • version: {{ .Chart.Version }}-{{ .Chart.AppVersion }}, задаются из Jenkins
  • environment: {{ .Values.appConfig.appEnv }},будем задавать в values.yaml каждого приложения
  • managed-by: {{ .Release.Service }}

А если захотим добавить ещё – можно будет это сделать в одном месте, а не обновлять все файлы, в которых используются labels.

define

Возвращаемся к _helpers.tpl, и описываем наши лейблы:

{{- define "helpers.labels" -}}
application: {{ .Values.appConfig.appName }}
version: {{ .Chart.Version }}-{{ .Chart.AppVersion }}
environment: {{ .Values.appConfig.appEnv }}
managed-by: {{ .Release.Service }}
{{- end }}

include

Далее, с помощью include – указываем, куда именно мы хотим включить эти лейблы в нашем шаблоне деплоймента:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appConfig.appName }}-deployment
  labels: {{- include "helpers.labels" . | nindent 4 }}
...

indent vs nindent

  • indent – просто задаёт кол-во отступов
  • nindent – начинает новую строку

Т.е. вместо того, что бы писать:

...
  labels: 
    {{- include "helpers.labels" . | indent 4 }}
...

Мы можем сделать всё в одну строку и обойтись без пробелов в самом шаблоне:

...
labels: {{- include "helpers.labels" . | nindent 4 }}
...

Кроме того, играет роль при вставке блоков YAML в общий шаблон – увидим ниже.

Вернёмся к именованным шаблонам – аналогично поступаем со spec.selector.matchLabels – вынесем его в отдельный шаблон, что бы потом переиспользовать в, например, Services.

В _helpers.tpl создаём:

...
{{- define "helpers.selectorLabels" -}}
application: {{ .Values.appConfig.appName }}
{{- end }}

Пока делаем выборку только по приложению, потом можно будет для каждого отдельного приложения изменить селекторы.

Добавляем в деплоймент:

...
  selector:
    matchLabels:
      {{- include "helpers.selectorLabels" . | nindent 6 }}
  template:
...

Шаблоны в шаблоне

Ну и приступим к самому интересному – вставке блоков шаблонов в шаблон.

Итак, у нас в текущем шаблоне есть блок env:

...
        env:
        - name: APP_SECRET
          valueFrom:
            secretKeyRef:
              name: app-backend-secrets
              key: backend-app-secret
        - name: AUTH_SECRET
          valueFrom:
            secretKeyRef:
              name: app-backend-secrets
              key: backend-auth-secret
        - name: CLIENT_HOST
          value: {{ .Values.appConfig.clientHost }}
        - name: DATABASE_HOST
          value: {{ .Values.appConfig.db.host }}
        - name: DATABASE_SLAVE_HOST
          value: {{ .Values.appConfig.db.slave }}
        - name: DB_USERNAME
          value: {{ .Values.appConfig.db.user }}
        - name: INSTANA_AGENT_HOST
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP
...

Который мы хотим вынести отдельный блок в другом файле, и вставлять оттуда в общий шаблон, который пишем сейчас.

Блок env из values.yaml проекта

Посмотрим, какие варианты у нас есть.

Сначала – набросаем сами переменные в values.yaml.

Создаём дерево каталогов:

[simterm]

$ mkdir -p projects/newapp/env/dev

[/simterm]

И внутри него – файлы values.yaml и secrets.yaml:

[simterm]

$ touch projects/newapp/env/dev/{values.yaml,secrets.yaml}

[/simterm]

Далее, в projects/newapp/env/dev/values.yaml создаём список environments и в него добавим пока одну переменную:

environments:    
  - name: 'DATABASE_HOST'
    value: 'dev.aurora.web.example.com'

Что бы иметь возможно проверить работу шаблона с helm --debug --dry-run – добавляем все остальные значения типа {{ .Values.deployment.replicaCount }}.

Цикл range

Документация – Flow Control.

Хорошие примеры – Helm Template range.

Итак, у нас есть переменная для подов DATABASE_HOST со значением dev.aurora.web.example.com, которая описана в values.yaml в виде элемента списка с двумя парами ключ:значение:

...
  <LIST_NAME>:
    - <VAR_NAME>: <VAR_VALUE>
      <VAR_NAME>: <VAR_VALUE>
...

Которые мы можем вставить в шаблон следующим образом:

...
    spec:
      containers:
      - name: {{ .Values.appConfig.appName }}-pod
        image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
        env:
        {{- range .Values.deployment.environments }}
        - name: {{ .name }}                        
          value: {{ .value }}
        {{- end }}
...

тут:

  • перебираем список environments, разделённый символом – и содержащий строки с ключ:значение
  • перебираем элементы списка, находим VAR_NAME .name – подставляем в name: {{ .name }}
  • перебираем элементы списка, находим VAR_NAME .value – подставляем в value: {{ .value }}

Проверям:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
spec:
  replicas: 2
  strategy:
    type: 
  selector:
    matchLabels:
      application: newapp
  template:
    metadata:
      labels:
        application: newapp
        version: 0.1.0-1.16.0
        environment: dev
        managed-by: Helm
    spec:
      containers:
      - name: newapp-pod
        image: projectname/projectname:latest
        env:
        - name: DATABASE_HOST       
          value: dev.aurora.web.example.com
        ports:
          - containerPort: 3001
...

[/simterm]

Кстати – уже видим и наши лейблы.

А вот и наши переменные:

[simterm]

...
        env:
        - name: DATABASE_HOST       
          value: dev.aurora.web.example.com
...

[/simterm]

Цикл range с переменными

Другой вариант – с использованием переменных, например $key и $value – в таком случае мы не привязываемся к конкретным именам переменных в самом файле values.yaml, а просто переберём их все:

...
        {{- range $key, $value := .Values.deployment.environments }}
        env:
        - name: {{ $key }}
          value: {{ $value }}
        {{- end }}
...

Обновляем values.yaml – теперь environments описываем как словарь, и задаём наши переменные просто как ключ:значение, для наглядности – добавим ещё одну переменную, DB_USERNAME:

...
  environments:  
    DATABASE_HOST: 'dev.aurora.web.example.com'
    DB_USERNAME: 'dbuser'
...

Проверяем:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
    spec:
      containers:
      - name: newapp-pod
        image: projectname/projectname:latest
        env:
        - name: DATABASE_HOST
          value: dev.aurora.web.example.com
        - name: DB_USERNAME
         value: dbuser
        ports:
          - containerPort: 3001
...

[/simterm]

toYaml

Но вспомним наши переменные в нынешнем файле деплоймента:

...
        - name: DATABASE_HOST
          value: {{ .Values.backendConfig.db.host }}
        - name: DB_USERNAME
          value: {{ .Values.backendConfig.db.user }}
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: projectname-backend-secrets
              key: backend-db-password
...

Простым циклом тут пройтись уже не получится, а потому третий вариант – описывать в values.yaml весь блок, а потом вставлять его в шаблон, используя toYaml .

Для этого в самом values.yaml описываем весь блок:

environments:
  - name: DATABASE_HOST
    value: 'dev.aurora.web.example.com'
  - name: DB_USERNAME
    value: 'dbuser'
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: projectname-backend-secrets
        key: backend-db-password

А затем вставляем в env деплоймента:

...
      containers:
      - name: {{ .Values.appConfig.appName }}-pod
        image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
        env: 
        {{- toYaml .Values.deployment.environments | nindent 8 }}
...

Пробелы

Обратите внимание, что перед toYaml после {{ имеется символ тире “-“:

{{- toYaml .Values.deployment.environments | nindent 8 }}

Который используется для удаления символов пробела перед вставляемым блоком, при этом новая строка также считается пробелом.

Если его убрать – то в результате мы получим лишнюю новую строку:

[simterm]

...
        env:

        - name: DATABASE_HOST
          value: dev.aurora.web.example.com
        - name: DB_USERNAME
...

[/simterm]

См. Controlling Whitespace во Flow Control и примеры на странице Directives and Whitespace Handling.

Кроме того – мы тут снова используем nindent, что бы добавить символ новой строки для каждой строки, полученной из .Values.deployment.environments.

Helm tpl

И ещё один вариант – использование tpl функции.

В отличии от других способов – тут мы можем в values.yaml использовать директивы типа {{ .Release.Name }}, т.к. подставляемый блок будет обработан шаблонизатором, как часть самого шаблона.

Обновим values.yaml:

environments: |-
  - name: RELEASE_NAME
    value: {{ .Release.Name }}
  - name: DATABASE_HOST
    value: 'dev.aurora.web.example.com'
  - name: DB_USERNAME
    value: 'dbuser'
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: projectname-backend-secrets
        key: backend-db-password

Обратите внимание на |- – описываем блок с переменными как string, и убираем newline в конце.

Теперь добавляем в шаблон:

...
      containers:
      - name: {{ .Values.appConfig.appName }}-pod
        image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
        env: 
        {{- tpl .Values.deployment.environments . | nindent 8 }}
...

Тут мы в функцию tml передаём содержимое .Values.deployment.environments, и указываем включить его в текущий шаблон.

Проверяем:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
    spec:
      containers:
      - name: newapp-pod
        image: projectname/projectname:latest
        env:
        - name: RELEASE_NAME
          value: eks-dev-1-newapp-backend
        - name: DATABASE_HOST
          value: 'dev.aurora.web.example.com'
        - name: DB_USERNAME
          value: 'dbuser'
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: projectname-backend-secrets
              key: backend-db-password
        ports:
          - containerPort: 3001
...

[/simterm]

Блок env из _helpers.tpl

Тут всё более-менее нам уже известно, но добавим проверку – есть ли значение для переменной в values.yaml.

if/else — flow control

В _helpers.yaml описываем шаблон:

{{- define "helpers.environments" -}}
- name: RELEASE_NAME
  value: {{ .Release.Name }}
{{- if .Values.appConfig.db.host }}
- name: DATABASE_HOST
  value: 'dev.aurora.web.example.com'
{{- end }}
{{- if .Values.appConfig.db.user }}
- name: DB_USERNAME
  value: 'dbuser'
{{- end }}
{{- if .Values.appConfig.db.password }}
- name: DB_PASSWORD
  valueFrom: 
    secretKeyRef:
      name: projectname-backend-secrets
      key: backend-db-password
{{- end }}
{{- end }}

Тут с помощью if для каждой переменной мы проверяем – имеется ли значение, и если оно будет найдено – то переменная и значение будут добавлены в общий шаблон.

Таким образом – можем спокойно расширять список переменных в helpers.environments, не волнуясь о том, что в каком-то проекте не будет значения для новой переменной из подключаемого шаблона, и изменение этого общего шаблона поломает деплой этого приложения.

Включаем его в шаблон:

...
      containers:
      - name: {{ .Values.appConfig.appName }}-pod
        image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
        env: {{- include "helpers.environments" . | nindent 8 }}
...

Проверяем:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
    spec:
      containers:
      - name: newapp-pod
        image: projectname/projectname:latest
        env:
        - name: RELEASE_NAME
          value: eks-dev-1-newapp-backend
        - name: DATABASE_HOST
          value: 'dev.aurora.web.example.com'
        - name: DB_USERNAME
          value: 'dbuser'
        ports:
          - containerPort: 3001
...

[/simterm]

Обратите внимание, что DB_PASSWORD не создана, т.к. {{ .Release.Name }} есть по-умолчанию, .Values.appConfig.db.host и .Values.appConfig.db.user – есть в values.yaml, а .Values.appConfig.db.password у нас хранится в Helm Secrets и файле secrets.yaml, который мы сейчас не используем вообще.

Соответсвенно, при генерации манифеста – Helm пропускает создание этой переменной.

Блок env из файла

Ну и третий вариант, который придумался – подключать содержимое блока env в общий шаблон из файла проекта.

Добавим в values.yaml параметр, который будет отключать include шаблона из _helpers.tpl, назовём его customEnvs, и заодно параметр, который позволит передавать путь к файлу с переменными – customEnvsFile:

...
deployment:

  customEnvs: true
  customEnvsFile: 'projects/newapp/templates/environments.yaml'
....

Теперь в деплоймент добавляем проверку условия, если оно не срабатывает – то через {{ else }} выполняем подстановку из _helpers.yaml:

...
        env:
        {{- if .Values.deployment.customEnvs  }}
          {{- .Files.Get .Values.deployment.customEnvsFile | nindent 8 }}
        {{- else }}
          {{- include "helpers.environments" . | nindent 8 }}
        {{ end -}}
        ports:
...

И всё хорошо, но только потому, что сейчас из projects/newapp/templates/environments.yaml убран вызов .Release.Name:

- name: DATABASE_HOST
  value: 'dev.aurora.web.example.com'
- name: DB_USERNAME
  value: 'dbuser'
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: projectname-backend-secrets
      key: backend-db-password

Решаем с помощью той жу функции tpl, которую уже использовали.

Возвращаемся к projects/newapp/templates/environments.yaml – добавляем .Release.Name:

- name: RELEASE_NAME
  value: {{ .Release.Name }}
- name: DATABASE_HOST
  value: 'dev.aurora.web.example.com'
...

В деплойменте меняем вставку – добавляем tpl,  а сам .Files.Get и его аргумент заворачиваем в скобки:

...
        {{- if .Values.deployment.customEnvs  }}
          {{- tpl ( .Files.Get .Values.deployment.customEnvsFile ) . | nindent 8 }}
        {{- else }} 
          {{- include "helpers.environments" . | nindent 8 }}
        {{ end -}}
...

Проверяем:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
    spec:
      containers:
      - name: newapp-pod
        image: projectname/projectname:latest
        env:
        - name: RELEASE_NAME
          value: eks-dev-1-newapp-backend
        - name: DATABASE_HOST
          value: 'dev.aurora.web.example.com'
        - name: DB_USERNAME
          value: 'dbuser'
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: projectname-backend-secrets
              key: backend-db-password
        ports:
          - containerPort: 3001
...

[/simterm]

С volumes, volumesMounts постуаем аналогично.

В целом схема с использованием _helpers.yaml выглядит вполне рабочей – попробуем применить на одном проекте, и будем посмотреть.

Поностью шаблон деплоймента теперь выглядит так:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appConfig.appName }}-deployment
  labels: {{- include "helpers.labels" . | nindent 4 }}
  annotations:
    {{- if .Values.deployment.deploymentAnnotations }}
      {{- toYaml .Values.deployment.deploymentAnnotations | nindent 6 }}
    {{- end }}
    reloader.stakater.com/auto: "true"
spec:
  replicas: {{ .Values.deployment.replicaCount }}
  strategy:
    type: {{ .Values.deployment.delpoyStrategy }}
  selector:
    matchLabels:
      {{- include "helpers.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels: {{- include "helpers.labels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Values.appConfig.appName }}-pod
        image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
        env: 
        {{- if .Values.deployment.customEnvs  }}
          {{- tpl ( .Files.Get .Values.deployment.customEnvsFile ) . | nindent 8 }}
        {{- else }}
          {{- include "helpers.environments" . | nindent 8 }}
        {{ end -}}
        ports:
          - containerPort: {{ .Values.appConfig.port }}
        {{- with .Values.deployment.livenessProbe }}
        livenessProbe:
          httpGet:
            path: {{ .path }}
            port: {{ .port }}
          initialDelaySeconds: {{ .initDelay }}
        {{- end }}
        {{- with .Values.deployment.readinessProbe }}
        readinessProbe:
          httpGet:
            path: {{ .path }}
            port: {{ .port }}
          initialDelaySeconds: {{ .initDelay }}
        {{- end }}
        resources:
          requests:
            cpu: {{ .Values.deployment.resources.requests.cpu | quote }}
      imagePullSecrets:
        - name: bttrm-docker-secret

Исключение шаблона из чарта

И напоследок – пример того, как можно исключить шаблон из чарта вообще.

Например, возьмём файл cronjobs.yaml:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: {{ .Values.appConfig.appName }}-cron
  labels: {{- include "helpers.labels" . | nindent 4 }}
spec: 
  schedule: {{ .Values.cronjobs.schedule | quote }}
  startingDeadlineSeconds:  {{ .Values.cronjobs.startingDeadline }}
  concurrencyPolicy: {{ .Values.cronjobs.concurrencyPolicy }}
  jobTemplate:
    spec:
      template:
        metadata:
          labels: {{- include "helpers.labels" . | nindent 12 }}
        spec:
          containers:
            - name: {{ .Values.appConfig.appName }}-cron
              image: {{ .Values.deployment.image.repository }}/{{ .Values.deployment.image.name }}:{{ .Values.deployment.image.tag }}
              env:
              {{- if .Values.deployment.customEnvs  }}
                {{- tpl ( .Files.Get .Values.deployment.customEnvsFile ) . | nindent 14 }}
              {{- else }}
                {{- include "helpers.environments" . | nindent 14 }}
              {{ end -}}
             command: ["npm"]
              args: ["run", "cron:app"]
          restartPolicy: Never
          imagePullSecrets:
              - name: bttrm-docker-secret

Обратите внимание, что мы тут используем наш _helpers.yaml, что облечает жизнь – те же лейблы, те же переменные.

Но – не каждый проект использует кроны. Как исключить из чарта?

В values.yaml добавляем параметр cronjobs.enabled:

...
################
### Cronjobs ###
################ 
             
cronjobs:     
          
  enabled: false
  schedule: '*/15 * * * *'
  startingDeadline: 10
  concurrencyPolicy: 'Forbid'
...

А затем – оборачиваем весь шаблон в единый блок if:

{{- if .Values.cronjobs.enabled }}
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: {{ .Values.appConfig.appName }}-cron
  labels: {{- include "helpers.labels" . | nindent 4 }}
...
          imagePullSecrets:
              - name: bttrm-docker-secret
{{- end }}

Проверяем:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run .
...
---
# Source: project-backend/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: newapp-deployment
...
      imagePullSecrets:
        - name: bttrm-docker-secret

[/simterm]

Кронов нет.

Добавляем --set cronjobs.enabled=true – и они будут добавлены в релиз:

[simterm]

$ helm upgrade --install eks-dev-1-newapp-backend --namespace eks-dev-1-newapp-backend-ns --create-namespace -f projects/newapp/env/dev/values.yaml --debug --dry-run . --set cronjobs.enabled=true
...
      imagePullSecrets:
        - name: bttrm-docker-secret
---
# Source: project-backend/templates/cronjobs.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: newapp-cron
...
          imagePullSecrets:
              - name: bttrm-docker-secret

[/simterm]

Готово.

Ссылки по теме