Итак, как наверняка все знают, совсем недавно 1-2 октября в Москве в “Инфопространстве” прошёл DevOpsConfRussia2018. Для тех кто не вкурсе, DevOpsConf — профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации.
Наша компания также приняла участие в этой конференции. Мы являлись её партнерами, представляя компанию на нашем стенде, а также провели небольшой митап. К слову это было первое наше участие в подобном роде деятельности. Первая конференция, первый митап, первый опыт.
О чём мы рассказывали? Митап был на тему “Бэкапы в Kubernetes”.
Скорее всего услышав это название, многие скажут: “А зачем бэкапить в Kubernetes? Его не нужно бэкапить, он же Stateless”.
Введение...
Давайте начнём с небольшой предыстории. Почему вообще возникла необходимость осветить эту тему и для чего это нужно.
В 2016 г. мы познакомились с такой технологией как Kubernetes и начали активно её применять для наших проектов. Конечно, в основном это проекты с микросервисной архитектурой, а это в свою очередь влечёт за собой использование большого количества разнообразного ПО.
С первым же проектом, где мы использовали Kubernetes, у нас встал вопрос о том как осуществлять резервное копирование расположенных там Stateful сервисов, которые иногда по тем или иным причинам попадают в k8s.
Мы начали изучать и искать уже существующие практики для решения данной задачи. Общаться с нашими коллегами и товарищами: "А как этот процесс осуществляется и построен у них?"
Пообщавшись, мы поняли, что у всех это происходит разными методами, средствами и с большим количеством костылей. При этом мы не проследили какого-либо единого подхода даже в рамках одного проекта.
Почему это так важно? Так как наша компания обслуживает проекты, построенные на базе k8s, нам просто необходимо было выработать структурированную методику по решению данной задачи.
Представьте, Вы работаете с одним определенным проектом в Кубере. Он содержит какие-то Stateful сервисы и Вам нужно бэкапить их данные. В принципе здесь можно обойтись парой костылей и забыть об этом. Но что если у Вас уже два проекта на k8s? И второй проект использует в своей работе совершенно другие сервисы. А если проектов уже пять? Десять? Или более двадцати?
Конечно, ставить костыли дальше, уже сложно и неудобно. Нужен какой-то единый подход, который можно было бы использовать при работе с множеством проектов на Кубе и при этом, чтобы команда инженеров могла легко и буквально за считанные минуты вносить необходимые изменения в работу бэкапов этих проектов.
В рамках данной статьи, мы как раз и расскажем о том, каким инструментом и какую практику мы используем для решения этой задачи внутри нашей компании.
Чем мы это делаем?
Nxs-backup что это?
Для бэкапов нами используется наш собственный open source инструмент — nxs-backup. Не будем вдаваться в детали того, что он может. Более подробно с ним можно ознакомиться по следующей ссылке.
Теперь перейдём к самой реализации бэкапов в k8s. Как и что именно нами было сделано.
Что бэкапим?
Давайте рассмотрим пример бэкапа нашего собственного Redmine. В нём мы будем бэкапить базу MySQL и пользовательские файлы проекта.
Как мы это делаем?
1 CronJob == 1 Сервис
На обычных серверах и кластерах на железе, почти все средства резервного копирования в основном запускаются через обычный cron. В k8s для этих целей мы используем CronJob'ы, т.е создаем 1 CronJob на 1 сервис, который мы будем бэкапить. Все эти CronJob’ы размещаются в том же namespace, что и сам сервис.
Начнем с базы данных MySQL. Чтобы осуществлять бэкап MySQL, нам потребуется 4 элемента, как и почти для любого другого сервиса:
- ConfigMap (nxs-backup.conf)
- ConfigMap (mysql.conf для nxs-backup)
- Secret (тут хранятся доступы к сервису, в данном случае MySQL). Обычно, этот элемент уже определён для работы сервиса и его можно переиспользовать.
- CronJob (для каждого сервиса свой)
Пойдём по порядку.
nxs-backup.conf
apiVersion: v1
kind: ConfigMap
metadata:
name: nxs-backup-conf
data:
nxs-backup.conf: |-
main:
server_name: Nixys k8s cluster
admin_mail: admins@nixys.ru
client_mail:
- ''
mail_from: backup@nixys.ru
level_message: error
block_io_read: ''
block_io_write: ''
blkio_weight: ''
general_path_to_all_tmp_dir: /var/nxs-backup
cpu_shares: ''
log_file: /dev/stdout
jobs: !include [conf.d/*.conf]Здесь мы задаем основные параметры, передаваемые нашему инструменту, которые нужны для его работы. Это название сервера, e-mail для нотификаций, ограничение по потреблению ресурсов и другие параметры.
Конфигурации могут задаваться в формате j2, что позволяет использовать переменные окружения.
mysql.conf
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-conf
data:
service.conf.j2: |-
- job: mysql
type: mysql
tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp
sources:
- connect:
db_host: {{ db_host }}
db_port: {{ db_port }}
socket: ''
db_user: {{ db_user }}
db_password: {{ db_password }}
target:
- redmine_db
gzip: yes
is_slave: no
extra_keys: '--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob'
storages:
- storage: local
enable: yes
backup_dir: /var/nxs-backup/databases/mysql/dump
store:
days: 6
weeks: 4
month: 6В этом файле описывается логика бэкапов для соответствующего сервиса, в нашем случае это MySQL.
Тут можно указать:
- Как называется Job (поле: job)
- Тип Job’а (поле: type)
- Временную директорию, необходимую для сбора бэкапов (поле: tmp_dir)
- Параметры подключения к MySQL (поле: connect)
- Базу данных, которую будем бэкапить (поле: target)
- Необходимость останавливать Slave перед сбором (поле: is_slave)
- Дополнительные ключи для mysqldump (поле: extra_keys)
- Storage хранения, т.е в каком хранилище будем хранить копию (поле: storage)
- Директорию, куда мы будем складировать наши копии (поле: backup_dir)
- Схему хранения (поле: store)
В нашем примере тип хранения установлен local, т.е мы собираем и храним резервные копии локально в определённой директории запускаемого pod’а.
Вот прям по аналогии с этим файлом конфигурации можно задать такие же конфигурационные файлы и для Redis, PostgreSQL или любого другого нужного сервиса, если его поддерживает наш инструмент. О том, что он поддерживает можно узнать по ссылке, приведённой ранее.
Secret MySQL
apiVersion: v1
kind: Secret
metadata:
name: app-config
data:
db_name: ""
db_host: ""
db_user: ""
db_password: ""
secret_token: ""
smtp_address: ""
smtp_domain: ""
smtp_ssl: ""
smtp_enable_starttls_auto: ""
smtp_port: ""
smtp_auth_type: ""
smtp_login: ""
smtp_password: ""В секрете мы храним доступы для подключения к самому MySQL и почтовому серверу. Их можно хранить или в отдельном секрете, или воспользоваться существующим, конечно если он есть. Тут ничего интересного. В нашем секрете также хранится secret_token, необходимый для работы нашего Redmine.
CronJob MySQL
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: mysql
spec:
schedule: "00 00 * * *"
jobTemplate:
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- nxs-node5
containers:
- name: mysql-backup
image: nixyslab/nxs-backup:latest
env:
- name: DB_HOST
valueFrom:
secretKeyRef:
name: app-config
key: db_host
- name: DB_PORT
value: '3306'
- name: DB_USER
valueFrom:
secretKeyRef:
name: app-config
key: db_user
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: app-config
key: db_password
- name: SMTP_MAILHUB_ADDR
valueFrom:
secretKeyRef:
name: app-config
key: smtp_address
- name: SMTP_MAILHUB_PORT
valueFrom:
secretKeyRef:
name: app-config
key: smtp_port
- name: SMTP_USE_TLS
value: 'YES'
- name: SMTP_AUTH_USER
valueFrom:
secretKeyRef:
name: app-config
key: smtp_login
- name: SMTP_AUTH_PASS
valueFrom:
secretKeyRef:
name: app-config
key: smtp_password
- name: SMTP_FROM_LINE_OVERRIDE
value: 'NO'
volumeMounts:
- name: mysql-conf
mountPath: /usr/share/nxs-backup/service.conf.j2
subPath: service.conf.j2
- name: nxs-backup-conf
mountPath: /etc/nxs-backup/nxs-backup.conf
subPath: nxs-backup.conf
- name: backup-dir
mountPath: /var/nxs-backup
imagePullPolicy: Always
volumes:
- name: mysql-conf
configMap:
name: mysql-conf
items:
- key: service.conf.j2
path: service.conf.j2
- name: nxs-backup-conf
configMap:
name: nxs-backup-conf
items:
- key: nxs-backup.conf
path: nxs-backup.conf
- name: backup-dir
hostPath:
path: /var/backups/k8s
type: Directory
restartPolicy: OnFailureПожалуй, вот этот элемент самый интересный. Во-первых, для того, чтобы составить правильный CronJob — необходимо определить где будут храниться собранные бэкапы.
У нас для этого выделен отдельный сервер с необходимым количеством ресурсов. В примере под сбор резервных копий отведена отдельная нода кластера — nxs-node5. Ограничение запуска CronJob на нужных нам нодах мы задаём директивой nodeAffinity.
При запуске CronJob к нему через hostPath с хост-системы подключается соответствующий каталог, который как раз и используется для хранения резервных копий.
Далее, к конкретному CronJob подключаются ConfigMap’ы, содержащие конфигурацию для nxs-backup, а именно, файлы nxs-backup.conf и mysql.conf, о которых мы только что говорили выше.
Затем, задаются все нужные переменные окружения, которые определяются непосредственно в манифесте или подтягиваются из Secret’ов.
Итак, переменные передаются в контейнер и через docker-entrypoint.sh подменяются в ConfigMaps в нужных нам местах на нужные значения. Для MySQL это db_host, db_user, db_password. Порт в данном случае мы передаем просто как значение в манифесте CronJob’а, т.к он не несёт какой-либо ценной информации.
Ну, с MySQL вроде всё понятно. А теперь давайте посмотрим, что нужно для бэкапа файлов приложения Redmine.
desc_files.conf
apiVersion: v1
kind: ConfigMap
metadata:
name: desc-files-conf
data:
service.conf.j2: |-
- job: desc-files
type: desc_files
tmp_dir: /var/nxs-backup/files/desc/dump_tmp
sources:
- target:
- /var/www/files
gzip: yes
storages:
- storage: local
enable: yes
backup_dir: /var/nxs-backup/files/desc/dump
store:
days: 6
weeks: 4
month: 6Это конфигурационный файл, описывающий логику бэкапов для файлов. Здесь тоже нет ничего необычного, задаются все те же параметры, что и у MySQL, за исключением данных для авторизации, т.к их попросту нет. Хотя они могут и быть, если будут задействованы протоколы для передачи данных: ssh, ftp, webdav, s3 и другие. Такой вариант мы рассмотрим чуть позже.
CronJob desc_files
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: desc-files
spec:
schedule: "00 00 * * *"
jobTemplate:
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- nxs-node5
containers:
- name: desc-files-backup
image: nixyslab/nxs-backup:latest
env:
- name: SMTP_MAILHUB_ADDR
valueFrom:
secretKeyRef:
name: app-config
key: smtp_address
- name: SMTP_MAILHUB_PORT
valueFrom:
secretKeyRef:
name: app-config
key: smtp_port
- name: SMTP_USE_TLS
value: 'YES'
- name: SMTP_AUTH_USER
valueFrom:
secretKeyRef:
name: app-config
key: smtp_login
- name: SMTP_AUTH_PASS
valueFrom:
secretKeyRef:
name: app-config
key: smtp_password
- name: SMTP_FROM_LINE_OVERRIDE
value: 'NO'
volumeMounts:
- name: desc-files-conf
mountPath: /usr/share/nxs-backup/service.conf.j2
subPath: service.conf.j2
- name: nxs-backup-conf
mountPath: /etc/nxs-backup/nxs-backup.conf
subPath: nxs-backup.conf
- name: target-dir
mountPath: /var/www/files
- name: backup-dir
mountPath: /var/nxs-backup
imagePullPolicy: Always
volumes:
- name: desc-files-conf
configMap:
name: desc-files-conf
items:
- key: service.conf.j2
path: service.conf.j2
- name: nxs-backup-conf
configMap:
name: nxs-backup-conf
items:
- key: nxs-backup.conf
path: nxs-backup.conf
- name: backup-dir
hostPath:
path: /var/backups/k8s
type: Directory
- name: target-dir
persistentVolumeClaim:
claimName: redmine-app-files
restartPolicy: OnFailureТоже ничего нового, относительно MySQL. Но тут монтируется один дополнительный PV (target-dir), как раз который мы и будем бэкапить — /var/www/files. В остальном всё так же, храним копии локально на нужной нам ноде, за которой закреплён CronJob.
Итог
Для каждого сервиса, который мы хотим бэкапить, мы создаём отдельный CronJob со всеми необходимыми сопутствующими элементами: ConfigMaps и Secrets. По аналогии с рассмотренными примерами, мы можем бэкапить любой аналогичный сервис в кластере.
Я думаю, исходя из этих двух примеров у всех сложилось какое-то представление, как именно мы бэкапим Stateful сервисы в Кубе. Думаю, нет смысла разбирать подробно такие же примеры и для других сервисов, т.к в основном они все похожи друг на друга и имеют незначительные различия.
Собственно, этого мы и хотели добиться, а именно — какого-то унифицированного подхода при построении процесса резервного копирования. И чтобы этот подход можно было бы применять на большое число различных проектов на базе k8s.
Где храним?
Во всех рассмотренных выше примерах мы храним копии в локальной директории ноды на которой запущен контейнер. Но никто не мешает подключить Persistent Volume как уже рабочее внешнее хранилище и собирать копии туда. Или можно только синхронизировать их на удаленное хранилище по нужному протоколу, не сохраняя локально. То есть вариаций достаточно много. Сперва собрать локально, потом синхронизировать. Либо собирать и хранить только на удалённом хранилище, и.т.д. Настройка осуществляется достаточно гибко.
mysql.conf + s3
Ниже приведен пример файла конфигурации бэкапа MySQL, где копии хранятся локально на той ноде где выполняется CronJob, а также синхронизируются в s3.
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-conf
data:
service.conf.j2: |-
- job: mysql
type: mysql
tmp_dir: /var/nxs-backup/databases/mysql/dump_tmp
sources:
- connect:
db_host: {{ db_host }}
db_port: {{ db_port }}
socket: ''
db_user: {{ db_user }}
db_password: {{ db_password }}
target:
- redmine_db
gzip: yes
is_slave: no
extra_keys: '
--opt --add-drop-database --routines --comments --create-options --quote-names --order-by-primary --hex-blob'
storages:
- storage: local
enable: yes
backup_dir: /var/nxs-backup/databases/mysql/dump
store:
days: 6
weeks: 4
month: 6
- storage: s3
enable: yes
backup_dir: /nxs-backup/databases/mysql/dump
bucket_name: {{ bucket_name }}
access_key_id: {{ access_key_id }}
secret_access_key: {{ secret_access_key }}
s3fs_opts: {{ s3fs_opts }}
store:
days: 2
weeks: 1
month: 6Т.е, если будет недостаточно хранить копии локально, можно синхронизировать их на любое удаленное хранилище по соответствующему протоколу. Число Storage для хранения может быть любым.
Но в данном случае всё-таки потребуется внести некоторые дополнительные изменения, а именно:
- Подключить соответствующий ConfigMap с содержимым, необходимым для авторизации у AWS S3, в формате j2
- Создать соответствующий Secret для хранения доступов авторизации
- Задать нужные переменные окружения, взятые из Secret’а выше
- Скорректировать docker-entrypoint.sh для замены в ConfigMap соответствующих переменных
- Пересобрать Docker образ, добавив в него утилиты для работы с AWS S3
Пока этот процесс далёк от совершенства, но мы над этим работаем. Поэтому, в ближайшее время мы добавим в nxs-backup возможность определять параметры в конфигурационном файле с помощью переменных окружения, что значительно упростит работу с entrypoint файлом и минимизирует временны́е затраты на добавление поддержки бэкапа новых сервисов.
Заключение
На этом, наверное, всё.
Использование подхода, про который только что было рассказано, в первую очередь позволяет структурировано и по шаблону организовать резервное копирование Stateful сервисов проекта в k8s. Т.е это уже готовое решение, а самое главное практика, которую можно применять в своих проектах, при этом не тратя время и силы на поиск и доработку уже имеющихся open source решений.
