Выпускник курса 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 по его улучшению.
Вместо заключения
Максим поделился о себе и о курсе, который изучал:
«Программированием я увлекаюсь давно, начинал с бесплатных курсов на разных платформах. Но все равно не чувствовал уверенности в том, что могу написать нечто прикладное и реально полезное моей команде. Поэтому я решил пойти на курс Python для инженеров, и он однозначно придал мне уверенности в своих силах.
Я научился работать с модулями / библиотеками для работы с файлами, запросами. Получил неплохой опыт в написании программ больше 100 строк, научился разбивать программу на модули и использовать ООП в работе. Также написал свой Ansible модуль и Prometheus Exporter. Чего давно хотел, но не хватало знаний.
Больше всего мне понравилась сложность курса. Я тратил 8–12 часов на каждую «курсовую» работу, потом приходил грамотный и подробный ревью, и я еще часик-два тратил на исправление замечаний. Первую половину курса было очень сложно, но, пройдя через это, я получил колоссальный опыт».