Блог Southbridge

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

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

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

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

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

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

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

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

Схема работы 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