Для быстродействия, устойчивости и масштабируемости.
Что даёт перевод 1С-Битрикс в Kubernetes:
— Стабильность под нагрузкой: инфраструктура умеет автоматически масштабироваться
— Инфраструктура сайта на Битрикс (но не сам 1С-Битрикс) разделяется на микросервисы
— Dev, stage и prod среды гарантированно идентичны
— Можно делать деплой без даунтайма
— Уменьшается человеческий фактор
— Достигается отказоустойчивость вплоть до 99,9%: проблемные узлы автоматически выводятся из работы
— Стабильность под нагрузкой: инфраструктура умеет автоматически масштабироваться
— Инфраструктура сайта на Битрикс (но не сам 1С-Битрикс) разделяется на микросервисы
— Dev, stage и prod среды гарантированно идентичны
— Можно делать деплой без даунтайма
— Уменьшается человеческий фактор
— Достигается отказоустойчивость вплоть до 99,9%: проблемные узлы автоматически выводятся из работы
При этом Kubernetes требует квалификации от разработчиков и администраторов, минимум 3 надежных выделенных сервера и сложную инфраструктуру.
Kubernetes — инструмент для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.
Особенности Kubernetes
- Готовые решения — в Kubernetes есть готовые решения, заменяющие самописные скрипты и кастомные разработки.
- Легкое масштабирование — переход на микросервисную архитектуру облегчает масштабирование и деплой.
- Автоматизация — масштабирование происходит автоматически (в облаке AWS / GCE) или очень просто (на собственных серверах).
- Докеризация — докеризация проекта гарантирует, что у нас всегда будет идентичное окружение. Dev, Stage и Prod среды запускаются с одного образа, собранного из Dockerfile.
- Легкое обновление — Kubernetes позволяет обновлять сайт без отключения: Rolling Update обновляет по одному инстансу, ожидая завершения обработки клиентских подключений. Кроме RollingUpdate доступны Blue-green Deployments, Shadow testing, A/B Testing и Canary Releases.
- Self-healing — Kubernetes — self-healing. Он следит за сервисами и нодами в кластере. Если сервис не отвечает, он будет перезапущен. Если нода вышла из строя или на ней появились сбои, приложения с неё будут разнесены на другие ноды и она будет отмечена как нерабочая. Этот процесс полностью автоматизирован, администратор не устраняет аварию, а разбирается с проблемной нодой, когда она уже выведена из кластера.
Схема работы Kubernetes
Проблемы переноса 1С-Битрикс в Kubernetes
Концептуально 1С-Битрикс не предназначен для CI/CD в целом и для работы в Kubernetes в частности.
CI/CD требует хранить проект в git, а 1С-Битрикс управляется из админ-панели. Это мешает перенести 1С-Битрикс в git. Данная проблема решается и многие уже работают с Битриксом в git.
Docker образ 1С-Битрикс, как и многих монолитных проектов, создается очень неочевидными способами.
При распределенной системе, когда приложение исполняется в нескольких инстансах, требуется хранить файлы, кэш и сессии таким образом, чтобы к ним имели доступ все инстансы.
Отдельно стоит отметить, что проблемы могут возникать и при обновлении ядра Битрикс. Поэтому ещё недавно на рынке не было подрядчиков, готовых переносить 1С-Битрикс в Kubernetes. По крайней, мере с гарантией, за понятную цену и в разумные сроки.
В Southbridge разработали рабочую схему переноса и начали по ней реализовывать проекты наших клиентов.
В Southbridge разработали рабочую схему переноса и начали по ней реализовывать проекты наших клиентов.
Схема работы Bitrix в Kubernetes
Чтобы запустить 1C-Bitrix в Kubernetes, нам потребовалось:
1. Вынести общие каталоги приложений на S3 или CephFS. Можно использовать системы хранения данных.
2. Вынести сессии в Memcache, причём без кластера и лишних усложнений. При этом решение сохраняет отказоустойчивость: мы запускаем на каждой ноде под с memcache, и php-приложение пишет сессии в каждый memcache. Даже если упадет 2 ноды, останется один сервис, и мы не потеряем сессии.
3. Вынести кэш в Memcache, чтобы приложения работали с общим кэшем. Доступен вариант хранения кэша в файлах, когда каждый инстанс приложения будет держать свой локальный кэш.
4. Переписать подключение к базе данных с использованием переменных. Теперь все пароли хранятся в Kubernetes.
5. Разработать собственное решение для обновления 1С-Битрикс штатными средствами, из админки.
Об этом подробнее:
2. Вынести сессии в Memcache, причём без кластера и лишних усложнений. При этом решение сохраняет отказоустойчивость: мы запускаем на каждой ноде под с memcache, и php-приложение пишет сессии в каждый memcache. Даже если упадет 2 ноды, останется один сервис, и мы не потеряем сессии.
3. Вынести кэш в Memcache, чтобы приложения работали с общим кэшем. Доступен вариант хранения кэша в файлах, когда каждый инстанс приложения будет держать свой локальный кэш.
4. Переписать подключение к базе данных с использованием переменных. Теперь все пароли хранятся в Kubernetes.
5. Разработать собственное решение для обновления 1С-Битрикс штатными средствами, из админки.
Об этом подробнее:
Под для обновления
При деплое проекта мы задаём количество реплик веб-приложения (обычно равно числу нод в кластере или на 1 меньше) и деплоим специальный под с префиксом "-upgrade", в котором возможно обновление кода, но в работу его не включаем, скейлим в 0 (то есть он всегда выключен). Перед обновлением мы включаем его:
scale deployment.apps/sb-bitrix-git-demo-upgrade --replicas=1
scale deployment.apps/sb-bitrix-git-demo-upgrade --replicas=1
Установка модуля для Битрикс
Мы написали модуль для Битрикс, чтобы делать это из админ-панели: одна кнопка устанавливает cookie, другая отправляет изменения в git.
Модуль устанавливается штатными средствами Битрикс.
Модуль устанавливается штатными средствами Битрикс.
Модуль для Битрикс
Вот так он выглядит.
Обновление: шаг 1
Переходим в Настройки, выбираем Обновление в Kubernetes и нажимаем «Войти в режим обновления». Модуль установит cookie, чтобы попасть в специальный под. Нажимаем "set deploy cookie". После установки cookie у вас изменится фон админки с серого на красный: это означает, вы в нужном поде.
Обновление: шаг 2
Переходим на страницу обновлений 1C-Битрикс: https://domain/bitrix/admin/sysupdate.php и выполняем обновление штатными средствами. Обратите внимание, цвет фона админки все еще красный, так как у нас установлен cookie и система направила нас в специальный под для обновления.
Обновление: шаг 3
После обновления переходим в Настройки / Обновление в Kubernetes. Нажимаем «Войти в режим обновления», затем «Выполнить "git commit"», а после «Выполнить "git push"».
Обновление: шаг 4
Нажимаем «Выйти из режима обновления».
Всё, обновление прошло и изменения попали в git, далее автоматически запустится процесс CI/CD, который обновит код в рабочих подах.
Всё, обновление прошло и изменения попали в git, далее автоматически запустится процесс CI/CD, который обновит код в рабочих подах.
6. После обновления, происходит отправка обновленных файлов в git и обновление подов, так как код изменился, CI/CD произведет деплой автоматически.
7. Далее мы скейлим в 0 специальный под:
scale deployment.apps/sb-bitrix-git-demo-upgrade --replicas=0
Пока идёт обновление, проект работает и обрабатывает клиентские запросы. При передеплое поды ждут, пока текущие соединения завершатся, тем временем новые соединения направляются к обновленным подам.
7. Далее мы скейлим в 0 специальный под:
scale deployment.apps/sb-bitrix-git-demo-upgrade --replicas=0
Пока идёт обновление, проект работает и обрабатывает клиентские запросы. При передеплое поды ждут, пока текущие соединения завершатся, тем временем новые соединения направляются к обновленным подам.
Сколько серверов нужно для кластера Kubernetes?
1 Сервер
— Gitlab (Git, CI/CD, Docker Registry)1 Сервер— Сборка и управление (Docker build, Kubectl к серверам кластера, VPN)
2 Сервера
— Ingress (балансировщик входящего трафика)
3 Сервера
— Master (обеспечивают работу кластера Kubernetes)
3 Сервера
— Node (обеспечивают работу клиентских приложений, Ceph кластер отвечает за хранение данных)
3 Сервера
— БД MySQL (рекомендуем кластер из 3-х серверов, в минимальном варианте 2 сервера Master-Slave / Master-Master)
1 Сервер
— EFK (сбор логов)Мы рекомендуем использовать облачные решения, которые позволяют нам использовать ПО как услугу (SaaS), в частности сервис Amazon S3.
— Gitlab (Git, CI/CD, Docker Registry)1 Сервер— Сборка и управление (Docker build, Kubectl к серверам кластера, VPN)
2 Сервера
— Ingress (балансировщик входящего трафика)
3 Сервера
— Master (обеспечивают работу кластера Kubernetes)
3 Сервера
— Node (обеспечивают работу клиентских приложений, Ceph кластер отвечает за хранение данных)
3 Сервера
— БД MySQL (рекомендуем кластер из 3-х серверов, в минимальном варианте 2 сервера Master-Slave / Master-Master)
1 Сервер
— EFK (сбор логов)Мы рекомендуем использовать облачные решения, которые позволяют нам использовать ПО как услугу (SaaS), в частности сервис Amazon S3.
Итого, рекомендованное количество серверов для self-hosted решений: 3-4 выделенных сервера и 14 виртуальных.
Как мы обеспечиваем деплой приложения в кластер?
Мы используем репозитории в Gitlab и Helm, с помощью которого упаковываем приложения и создаём темплейты, чтобы разработчики задавали все параметры для работы проекта в одном месте.
Выглядит это так:
Выглядит это так:
В данном примере видно, если пойти с конца, что мы:
— задаём имя нашего домена;
— указываем, выписывать ли сертификат автоматически и работать по HTTPS, или убрать и остаться на HTTP;
— указываем количество и имена серверов с memcache (2 для сессий и один для кэша);
— включаем отдельный под с cron или настраиваем крон средствами Битрикс;
— задаём подключение к базе данных через переменные DB_USER и DB_PASSWORD (секреты хранятся в Kubernetes).
Пример: мы хотим увеличить число инстансов Битрикс в нашем кластере, для этого мы поменяем значение в одном файле (вместо 1 поставим нужное количество):
— задаём имя нашего домена;
— указываем, выписывать ли сертификат автоматически и работать по HTTPS, или убрать и остаться на HTTP;
— указываем количество и имена серверов с memcache (2 для сессий и один для кэша);
— включаем отдельный под с cron или настраиваем крон средствами Битрикс;
— задаём подключение к базе данных через переменные DB_USER и DB_PASSWORD (секреты хранятся в Kubernetes).
Пример: мы хотим увеличить число инстансов Битрикс в нашем кластере, для этого мы поменяем значение в одном файле (вместо 1 поставим нужное количество):
Дополнительно можно ввести любые переменные.
Теперь вы управляете настройками сайта из одного файла. Это намного удобнее, чем править все руками.
Теперь вы управляете настройками сайта из одного файла. Это намного удобнее, чем править все руками.
Как обновить 1С-Битрикс в Kubernetes из админки?
Что вы получите после перевода 1С-Битрикс в Kubernetes:
- Отказоустойчивость (вплоть до 99,9%)
- Деплой без даунтайма
- Быстрый/автоматический скейлинг при повышении нагрузки
- Легкий деплой новых версий
- Деплой по кнопке (разработчику надо посмотреть, как будет выглядеть приложение с правками из его ветки)
- Легкий тест новых версий сайта (перенаправляем часть пользователей в под, куда задеплоена новая версия сайта)
- Возможность покрытия кода тестами (автоматическое тестирование при деплое).
- Автоматический откат до предыдущей версии в случае ошибок в коде
- Возможность обслуживания инфраструктуры. Kubernetes позволяет выключить ноду, обновить, поставить новое ядро и вернуть обратно. Все эти действия проходят прозрачно для приложений в кластере
Надёжное, проверенное решение вместо набора скриптов и костылей.
Kubernetes становится промышленным стандартом, его активно поддерживают Google, RedHat и Microsoft
