Блог Southbridge

Переносим 1С-Битрикс в кластер Kubernetes

2024-01-25 13:31
Для быстродействия, устойчивости и масштабируемости.
Что даёт перевод 1С-Битрикс в Kubernetes:
— Стабильность под нагрузкой: инфраструктура умеет автоматически масштабироваться
— Инфраструктура сайта на Битрикс (но не сам 1С-Битрикс) разделяется на микросервисы
— Dev, stage и prod среды гарантированно идентичны
— Можно делать деплой без даунтайма
— Уменьшается человеческий фактор
— Достигается отказоустойчивость вплоть до 99,9%: проблемные узлы автоматически выводятся из работы
При этом Kubernetes требует квалификации от разработчиков и администраторов, минимум 3 надежных выделенных сервера и сложную инфраструктуру.
Kubernetes — инструмент для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.

Особенности Kubernetes

  1. Готовые решения — в Kubernetes есть готовые решения, заменяющие самописные скрипты и кастомные разработки.
  2. Легкое масштабирование — переход на микросервисную архитектуру облегчает масштабирование и деплой.
  3. Автоматизация — масштабирование происходит автоматически (в облаке AWS / GCE) или очень просто (на собственных серверах).
  4. Докеризация — докеризация проекта гарантирует, что у нас всегда будет идентичное окружение. Dev, Stage и Prod среды запускаются с одного образа, собранного из Dockerfile.
  5. Легкое обновление — Kubernetes позволяет обновлять сайт без отключения: Rolling Update обновляет по одному инстансу, ожидая завершения обработки клиентских подключений. Кроме RollingUpdate доступны Blue-green Deployments, Shadow testing, A/B Testing и Canary Releases.
  6. Self-healing — Kubernetes — self-healing. Он следит за сервисами и нодами в кластере. Если сервис не отвечает, он будет перезапущен. Если нода вышла из строя или на ней появились сбои, приложения с неё будут разнесены на другие ноды и она будет отмечена как нерабочая. Этот процесс полностью автоматизирован, администратор не устраняет аварию, а разбирается с проблемной нодой, когда она уже выведена из кластера.

Схема работы Kubernetes

Проблемы переноса 1С-Битрикс в Kubernetes

Концептуально 1С-Битрикс не предназначен для CI/CD в целом и для работы в Kubernetes в частности.
CI/CD требует хранить проект в git, а 1С-Битрикс управляется из админ-панели. Это мешает перенести 1С-Битрикс в git. Данная проблема решается и многие уже работают с Битриксом в git.
Docker образ 1С-Битрикс, как и многих монолитных проектов, создается очень неочевидными способами.
При распределенной системе, когда приложение исполняется в нескольких инстансах, требуется хранить файлы, кэш и сессии таким образом, чтобы к ним имели доступ все инстансы.
Отдельно стоит отметить, что проблемы могут возникать и при обновлении ядра Битрикс. Поэтому ещё недавно на рынке не было подрядчиков, готовых переносить 1С-Битрикс в Kubernetes. По крайней, мере с гарантией, за понятную цену и в разумные сроки.

В Southbridge разработали рабочую схему переноса и начали по ней реализовывать проекты наших клиентов.

Схема работы Bitrix в Kubernetes

Чтобы запустить 1C-Bitrix в Kubernetes, нам потребовалось:

1. Вынести общие каталоги приложений на S3 или CephFS. Можно использовать системы хранения данных.

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

Установка модуля для Битрикс

Мы написали модуль для Битрикс, чтобы делать это из админ-панели: одна кнопка устанавливает 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, который обновит код в рабочих подах.
6. После обновления, происходит отправка обновленных файлов в git и обновление подов, так как код изменился, CI/CD произведет деплой автоматически.

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.
Итого, рекомендованное количество серверов для self-hosted решений: 3-4 выделенных сервера и 14 виртуальных.

Как мы обеспечиваем деплой приложения в кластер?

Мы используем репозитории в Gitlab и Helm, с помощью которого упаковываем приложения и создаём темплейты, чтобы разработчики задавали все параметры для работы проекта в одном месте.

Выглядит это так:
В данном примере видно, если пойти с конца, что мы:
— задаём имя нашего домена;
— указываем, выписывать ли сертификат автоматически и работать по HTTPS, или убрать и остаться на HTTP;
— указываем количество и имена серверов с memcache (2 для сессий и один для кэша);
— включаем отдельный под с cron или настраиваем крон средствами Битрикс;
— задаём подключение к базе данных через переменные DB_USER и DB_PASSWORD (секреты хранятся в Kubernetes).

Пример: мы хотим увеличить число инстансов Битрикс в нашем кластере, для этого мы поменяем значение в одном файле (вместо 1 поставим нужное количество):
Дополнительно можно ввести любые переменные.

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

Как обновить 1С-Битрикс в Kubernetes из админки?

Что вы получите после перевода 1С-Битрикс в Kubernetes:

  • Отказоустойчивость (вплоть до 99,9%)
  • Деплой без даунтайма
  • Быстрый/автоматический скейлинг при повышении нагрузки
  • Легкий деплой новых версий
  • Деплой по кнопке (разработчику надо посмотреть, как будет выглядеть приложение с правками из его ветки)
  • Легкий тест новых версий сайта (перенаправляем часть пользователей в под, куда задеплоена новая версия сайта)
  • Возможность покрытия кода тестами (автоматическое тестирование при деплое).
  • Автоматический откат до предыдущей версии в случае ошибок в коде
  • Возможность обслуживания инфраструктуры. Kubernetes позволяет выключить ноду, обновить, поставить новое ядро и вернуть обратно. Все эти действия проходят прозрачно для приложений в кластере

Надёжное, проверенное решение вместо набора скриптов и костылей.
Kubernetes становится промышленным стандартом, его активно поддерживают Google, RedHat и Microsoft
Kubernetes