Автоматизируем перевод с деплоя bash-скриптами на helmfile при помощи Python: инструкция по применению

Выпускник курса Python для инженеров Максим Дубакин рассказал о рабочем проекте собственного производства, который заавтоматизировал повторяющиеся задачи по переводу с деплоя bash-скриптами на helmfile при помощи Python и уменьшил затраты времени на ~ 2 часа.

Проблема

Команда использует helm для деплоя приложений в K8s. Ранее helm-чарты деплоились с помощью bash-скриптов, которые в свою очередь запускали еще bash-скрипты. Это крайне неудобно с точки зрения поддержки и дебага: скрипты хоть и имели общую форму, но могли быть произвольно дописаны разработчиками. В итоге это превращалось в большую кашу.

Нашли решение, им оказался [helmfile] (https://github.com/helmfile/helmfile). Очень удобная программа, которая позволяет запускать несколько helm-чартов из одного места, указав при этом их последовательность. Это полезно, если у вас есть несколько окружений (у Максима — production / stage / QA), и каждые окружения имеют свои values файлы.

В компании более 250 сервисов, а переводить на helmfile приходилось вручную — это занимало порядка 6–12 часов на подготовку файлов, тестирование и перекатку каждой среды. В QA-средах используются helm-чарты для инфраструктуры типа баз данных, кешей и очередей, поэтому количество values файлов и длина helmfile могли быть существенными.

Пример типичного helmfile для QA:

```yaml
environments:
 default:
   values:
     - VERSION: {{ requiredEnv "version" | quote }}
     - NAMESPACE: {{ requiredEnv "namespace" | quote }}
     - CLUSTER: {{ requiredEnv "cluster" | quote }}
     - RELEASE: <name_of_service>
---
templates:
 default: &default
   namespace: {{ .Values.NAMESPACE }}
   missingFileHandler: Warn
 
releases:
 - name: "{{ .Values.RELEASE }}"
   chart: artifactory/unified
   <<: *default
   version: "2.5.3"
   values:
     - values/common.yaml.gotmpl
     - values/app.yaml.gotmpl
     - values/override/{{.Values.CLUSTER}}/{{.Values.NAMESPACE}}/common.yaml
     - values/override/{{.Values.CLUSTER}}/{{.Values.NAMESPACE}}/app.yaml
   needs:
     - "{{ .Values.RELEASE }}-migration"
 
 - name: "{{ .Values.RELEASE }}-job"
   ...
   needs:
     - {{ .Values.RELEASE }}
 
 # migration
 - name: "{{ .Values.RELEASE }}-migration"
   ...
   needs:
     - "{{ .Values.RELEASE }}-drop-restore-db"
  - name: "{{ .Values.RELEASE }}-drop-restore-db"
   ...
   needs:
     - "{{ .Values.RELEASE }}-sku-generator"
     - "pgsql-{{ .Values.RELEASE }}"
     - "{{ .Values.RELEASE }}-rabbitmq"
     - "{{ .Values.RELEASE }}-webdav"
     - "{{ .Values.RELEASE }}-wiremock"
     - "{{ .Values.RELEASE }}-mailhog"
 
 # sku-generator
 - name: "{{ .Values.RELEASE }}-sku-generator"
   ...
  # postgres
 - name: "pgsql-{{ .Values.RELEASE }}"
   ...
 
 # rabbitmq
 - name: "{{ .Values.RELEASE }}-rabbitmq"
   ...
  # webdav
 - name: "{{ .Values.RELEASE }}-webdav"
   ...
  # wiremock
 - name: "{{ .Values.RELEASE }}-wiremock"
   ...
 
 # mailhog
 - name: "{{ .Values.RELEASE }}-mailhog"
   ...
bases:
 - "../_helmfile.d/helm.yaml"
 - ../_helmfile.d/repositories.yaml
```

Первым релизом идет основной helm-чарт приложения, затем — все его инфраструктурные зависимости. Под ... скрыты похожие части с указанием чарта, его версии и values файлов.

Здесь явно видна проблема ручного повторяющегося труда.

Решение

Во время перевода сервисов Максим как раз учился на курсе и решил в свободное время написать инструмент, который бы просто создавал файловую структуру проекта на helmfile, а также пустые файлы values и helmfile.yaml. Но со временем его проект начал разрастаться. Вот, что из этого вышло.

Как работает программа:

1. Принимает на вход: название проекта, нужно ли использовать миграции, в какой папке создавать проект, в какой namespace будет деплоиться приложение.

2. Создает структуру проекта в одном из репозиториев с helmfile (для production и QA мы используем разные репозитории).

3. Создает шаблоны файлов helmfile.yaml и пустые values для возможности override с помощью merge шаблонов jinja2 на стороне приложения (values и helmfile.yaml) и общих шаблонов gotmpl (шаблоны отдельных релизов и их values по умолчанию), которые хранятся в репозитории с helmfile.

4. Внутри helmfile будут сразу все возможные инфразависимости, но они будут закоменчены, так что остается только раскоментить нужные и удалить ненужные.

Результат

Таким образом, команда OPS перестала самостоятельно создавать все папки и файлы, указывать вручную кучу values и добавлять в helmfile.yaml те чарты, которые нужны.

Теперь про фичи:

1. Программа helmfile_template использует gotmpl шаблоны внутри репозитория в helmfile. Вот пример шаблона релиза:

```yaml
pgsql: &pgsql
 <<: *default
 name: pgsql-{{ .Values.releaseName }}
 chart: artifactory/postgres-instance
 version: 0.4.2
 values:
   - ../_helmfile.d/templates/values/pgsql.yaml.gotmpl
   - values/pgsql.yaml.gotmpl
   - values/override/{{ .Values.CLUSTER }}/{{ .Values.NAMESPACE }}/pgsql.yaml
```

А вот шаблон values для pgsql:

```yaml
pgsql:
 version: 12
 instances: 1
 limits:
   cpu: 200m
   memory: 512Mi
 requests:
   cpu: 200m
   memory: 512Mi
 storageClass: ceph-block
 
database:
 - name: {{ .Values.releaseName | replace "-" "_" }}
   size: 10
 
service:
 annotations:
   external-dns.alpha.kubernetes.io/hostname: {{ .Release.Name }}{{ .Values.IngressPostfix }}
```

Как вы видите, первым values-файлом используется - ../_helmfile.d/templates/values/pgsql.yaml.gotmpl. Это как раз шаблон с values по умолчанию, о котором писалось выше. Если требуется, они могут быть перезаписаны с помощью файлов в папке с проектом.

2. Используются шаблоны [jinja2] (https://jinja.palletsprojects.com/en/3.1.x/).

3. Программа распространяется как один исполняемый файл. Для этого используется модуль [pyinstaller] (https://pyinstaller.org/en/stable/).

4. Программа может работать как в интерактивном режиме, так и запускаться с аргументами. Для этого используется модуль [argparse] (https://docs.python.org/3/library/argparse.html), который позволяет выводить классный help с помощью ключа -h.

Получение справки:

```bash
helmfile_template -h
usage: helmfile_template [-h] [-v] [-g] [-s PROJECT_NAME] [-p] [--no-production] [-n NAMESPACE] [-u] [--no-unified]
                        [-m] [--no-migration]
 
Get helmfile templates.
 
options:
 -h, --help            show this help message and exit
 -v, --version         show program's version number and exit
 -g, --get-help        get templates
 -s PROJECT_NAME, --name PROJECT_NAME
 -p, --production      use deploy repository
 --no-production       use deploy repository
 -n NAMESPACE, --namespace NAMESPACE
 -u, --unified         use unified helmchart
 --no-unified          don't use unified helmchart
 -m, --migration       use migration
 --no-migration        don't use migration
```

Пример работы в интерактивном режиме:

```bash
$ helmfile_template
******************************
Введите название проекта: slurm
******************************
******************************
1. deploy
2. qa-deploy
Выберите репозиторий (default: 2): 2
******************************
Использовать unified? (y/n) (default: n): y
******************************
Нужны миграции? (y/n) (default: n): n
Проект slurm был создан в папке /Users/<my_user>/<some_path>/qa-deploy.
```

Тот же проект, но созданный с помощью аргументов:

```bash
$ helmfile_template -s slurm --no-production -u --no-migration
Проект slurm был создан в папке /Users/<my_user>/<some_path>/qa-deploy.
```

Результат работы программы

Файловая структура:

```
slurm
├── helmfile.yaml
└── values
   ├── app.yaml.gotmpl
   ├── common.yaml.gotmpl
   ├── job.yaml.gotmpl
   └── override
```

Содержимое helmfile.yaml:

```yaml
{{ tpl (readFile "../_helmfile.d/environments.tmpl") . }}
---
environments:
 default:
   values:
     - releaseName: "slurm"
---
{{ tpl (readFile "../_helmfile.d/templates.tmpl") . }}
{{ tpl (readFile "../_helmfile.d/bases.yaml") . }}
releases:
- <<: *unified
 labels:
   type: app
# - <<: *unified
#   name: {{ .Values.releaseName }}-{{`{{ .Release.Labels.type }}`}}
#   labels:
#     type: job
#   needs:
#     - "pgsql-{{ .Values.releaseName }}"
#     - "{{ .Values.releaseName }}-mysql"
#     - "{{ .Values.releaseName }}-es"
#     - "{{ .Values.releaseName }}-kafka"
#     - "{{ .Values.releaseName }}-rabbitmq"
#     - "{{ .Values.releaseName }}-redis"
#     - "{{ .Values.releaseName }}-webdav"
#     - "{{ .Values.releaseName }}-saml"
# - <<: *pgsql
# - <<: *mysql
# - <<: *elastic
# - <<: *kafka
# - <<: *rabbitmq
# - <<: *redis-standalone
# - <<: *redis-sentinel
# - <<: *webdav
# - <<: *saml
```

Предположим, что сервису slurm нужны pgsql, kafka и saml. В таком случае можно немного отредактировать файл, и сервис готов к деплою:

```yaml
{{ tpl (readFile "../_helmfile.d/environments.tmpl") . }}
---
environments:
 default:
   values:
     - releaseName: "slurm"
---
{{ tpl (readFile "../_helmfile.d/templates.tmpl") . }}
{{ tpl (readFile "../_helmfile.d/bases.yaml") . }}
releases:
- <<: *unified
 labels:
   type: app
 needs:
   - "pgsql-{{ .Values.releaseName }}"
   - "{{ .Values.releaseName }}-kafka"
   - "{{ .Values.releaseName }}-saml"
 
- <<: *pgsql
 
- <<: *kafka
 
- <<: *saml
```

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