Мы используем куки




Безопасное и надежное администрирование Linux-серверов

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

Для быстродействия, устойчивости и масштабируемости.

Что даёт перевод 1С-Битрикс в Kubernetes:
— Стабильность под нагрузкой: инфраструктура умеет автоматически масштабироваться
— Инфраструктура сайта на Битрикс (но не сам 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 есть готовые решения, заменяющие самописные скрипты и кастомные разработки.
  • Легкое масштабирование
    Переход на микросервисную архитектуру облегчает масштабирование и деплой.
  • Автоматизация
    Масштабирование происходит автоматически (в облаке 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 разработали рабочую схему переноса и начали по ней реализовывать проекты наших клиентов.
Схема работы Bitrix в Kubernetes
CephFS
Система хранения данных
S3
Чтобы запустить 1C-Bitrix в Kubernetes, нам потребовалось:
1. Вынести общие каталоги приложений на S3 или CephFS. Можно использовать системы хранения данных.

2. Вынести сессии в Memcache, причём без кластера и лишних усложнений. При этом решение сохраняет отказоустойчивость: мы запускаем на каждой ноде под с memcache, и php-приложение пишет сессии в каждый memcache. Даже если упадет 2 ноды, останется один сервис, и мы не потеряем сессии.

3. Вынести кэш в Memcache, чтобы приложения работали с общим кэшем. Доступен вариант хранения кэша в файлах, когда каждый инстанс приложения будет держать свой локальный кэш.

4. Переписать подключение к базе данных с использованием переменных. Теперь все пароли хранятся в Kubernetes.

5. Разработать собственное решение для обновления 1С-Битрикс штатными средствами, из админки.
Об этом подробнее:
      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.
      • 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 виртуальных.
      Итого, рекомендованное количество серверов для self-hosted решений: 3-4 выделенных сервера и 14 виртуальных.
      Как мы обеспечиваем деплой приложения в кластер?
      Мы используем репозитории в Gitlab и Helm, с помощью которого упаковываем приложения и создаём темплейты, чтобы разработчики задавали все параметры для работы проекта в одном месте.

      Выглядит это так:
      
      env:
        DB_HOST: runner.southbridge.io
        DB_NAME: demo
        SMTP_HOST: bitrix-demo
        SMTP_PORT: 1025
        SMTP_DOMAIN: bitrix-mail.southbridge.io
        MAILER_SENDER_ADDRESS: '"Bitrix Info" <info@bitrix-demo.southbridge.io>'
        HOST: bitrix-demo.southbridge.io
        GIT_REPO: 'git@gitlab.s00.domain.io:sb/bitrix_git_demo.git'
        GIT_BRANCH: ""
        GIT_COMMIT_SHA: "" 
       
      # This variables is taken from secret
      # Value is secret name where variable value can be found
      # Key in secret equals lowercased variable name with "_" replaced by "-"
      # The secret should be created manually
      envSecret:
        DB_USER: bitrixkey
        DB_PASSWORD: bitrixkey
       
      # Resources for app. Limits is the maximum number of resources that app cas use.
      # And requests is resources that will be granted to the app at start time.
      app:
        replicas: 2
       
      bitrix:
        # Enable pod with periodicaly run /app/bitrix/modules/main/tools/cron_events.php
        # Please define ('BX_CRONTAB_SUPPORT', true); in dbconn.php
        cron_events: true
        # List of memcache server to save sessions
        session_memcache_servers:
          - demo-memcache-0.demo-memcache
          - demo-memcache-1.demo-memcache
       
      service:
        port: 80
       
      ingress:
        host: bitrix-demo.southbridge.io
        # Get certificate from letsencrypt by cert-manager issuer
        tls: letsencrypt
      
      В данном примере видно, если пойти с конца, что мы:
      — задаём имя нашего домена;
      — указываем, выписывать ли сертификат автоматически и работать по HTTPS, или убрать и остаться на HTTP;
      — указываем количество и имена серверов с memcache (2 для сессий и один для кэша);
      — включаем отдельный под с cron или настраиваем крон средствами Битрикс;
      — задаём подключение к базе данных через переменные DB_USER и DB_PASSWORD (секреты хранятся в Kubernetes).

      Пример: мы хотим увеличить число инстансов Битрикс в нашем кластере, для этого мы поменяем значение в одном файле (вместо 1 поставим нужное количество):
      
      # Resources for app. Limits is the maximum number of resources that app cas use.
      # And requests is resources that will be granted to the app at start time.
      app:
        replicas: 2
      
      Дополнительно можно ввести любые переменные.

      Теперь вы управляете настройками сайта из одного файла. Это намного удобнее, чем править все руками.
      Как обновить 1С-Битрикс в Kubernetes из админки?
      Что вы получите после перевода 1С-Битрикс в Kubernetes:
      • Отказоустойчивость (вплоть до 99,9%)
      • Деплой без даунтайма
      • Быстрый/автоматический скейлинг при повышении нагрузки
      • Легкий деплой новых версий
      • Деплой по кнопке (разработчику надо посмотреть, как будет выглядеть приложение с правками из его ветки)
      • Легкий тест новых версий сайта (перенаправляем часть пользователей в под, куда задеплоена новая версия сайта)
      • Возможность покрытия кода тестами (автоматическое тестирование при деплое).
      • Автоматический откат до предыдущей версии в случае ошибок в коде
      • Возможность обслуживания инфраструктуры. Kubernetes позволяет выключить ноду, обновить, поставить новое ядро и вернуть обратно. Все эти действия проходят прозрачно для приложений в кластере
      Надёжное, проверенное решение вместо набора скриптов и костылей.
      Kubernetes становится промышленным стандартом, его активно поддерживают Google, RedHat и Microsoft
      Kubernetes становится промышленным стандартом, его активно поддерживают Google, RedHat и Microsoft

      Дополнительные услуги

      Поставленные задачи выполняют быстро...
      Отзывы
      Находят оптимальные решения для сложных задач, всегда стараются помочь. Отличная тех.поддержка, очень удобно, когда можно обращаться к администратору напрямую, а самое главное они работаю круглосуточно!

      Компания, у которой выстроен бизнес-процесс на высшем уровне...
      1. Постоянный и не текучий штат профессионалов. 2. Молниеносное время реакции и при аварии и при плановой профилактике…
      Роман Валухов
      Полный отзыв в Google
      Артём Султанов
      Полный отзыв в Google
      «Над любой задачей работает не один сотрудник, а команда, поэтому сервер всегда работает безупречно. Отличный сервис!»

      Журнал AstroMeridian
      Полный отзыв в Google
      «Поддерживать бесперебойную работу серверов очень важно для нашего бизнеса и эта задача успешно решена, за что спасибо Southbridge!»

      Кирилл Житников
      Полный отзыв в Google
      «Все задачи решаются, предлагаются разные варианты, мнение клиента всегда учитывается»

      РОС РИЭЛТ
      Полный отзыв в Google
      «Отличные ребята, знают свое дело. Настройка и тюнинг серверов любого уровня, рекомендую»

      Тарас Перцович
      Полный отзыв в Google
      «Команда Southbridge сделала все по уму, с Kubernetes, автоскейлом, настроили CI через Гитлаб»

      Сергей Бабочкин
      Полный отзыв в Google
      «Работаем с Southbridge более 7 лет и все проекты, которые ведем, стараемся перевести на поддержку именно к этой команде»

      Егор Рыболовлев
      Полный отзыв в Google
      Заявка на администрирование серверов
      Мы также всегда готовы проконсультировать вас по телефону +7 495 665-50-27 или по электронной почте ask@southbridge.io

      Свяжемся с вами в течение рабочего дня