Как развернуть CRM в Kubernetes: веб-часть, база данных и файлы

Развернуть CRM в Kubernetes помогает взгляд на систему как на три части: веб-приложение, базу данных и хранилище файлов. Кластер Kubernetes это группа серверов под общим управлением. Веб-часть работает в нём как Deployment, объект Kubernetes, который держит заданное число копий приложения. Базу данных удобнее взять управляемую, под файлы выделяется постоянный том, диск, который переживает пересоздание контейнера. Такая раскладка повторяется у CRM-систем, которые ставятся на свой сервер и состоят из веб-приложения, базы и каталога с файлами, от открытых продуктов до коробочного Битрикс24, с поправкой на требования конкретной системы к файлам, фоновым задачам и обновлениям.

У EspoCRM есть официальный контейнерный образ (шаблон с приложением и зависимостями, из которого запускаются контейнеры) и раздел документации про запуск в Docker с перечнем переменных окружения и каталогов для постоянного хранения, поэтому разбирать буду на ней. На этой системе хорошо видно устройство CRM, которая ставится на свой сервер: веб-контейнер, рядом контейнер фоновых задач, база MySQL или PostgreSQL и каталоги с загруженными документами и настройками. Те же части вы найдёте в CRM, которые ставятся на свой сервер, различаются только названия.

Перенос CRM в кластер Kubernetes снимает зависимость системы продаж от одного сервера: веб-часть после недоступности узла (сервера кластера) пересоздаётся на соседнем. База работает отдельно, со своими резервными копиями, а в кластерной конфигурации ещё и с репликами, копиями базы на других серверах. Обновление версии проходит по отрепетированной процедуре, а не в ночь на пятницу. Если CRM у вас уже останавливалась вместе с продажами, этот аргумент объяснять не нужно.

Пять шагов до работающей CRM

1. Готовим кластер и доступ. Создаём кластер в личном кабинете VK Cloud по инструкции создание кластера и подключаемся к нему через kubectl (консольную утилиту управления кластером) по инструкции подключение через kubectl.

2. Создаём базу данных. По официальной документации EspoCRM система работает с MySQL или PostgreSQL. Кластер СУБД создаётся в сервисе управляемых баз данных Cloud Databases: выбираете тип базы, версию, диски и резервное копирование, обслуживание остаётся на стороне облака (инструкция). Приложению передаёте адрес, имя базы и учётные данные через переменные окружения.

3. Запускаем веб-часть. Официальный образ espocrm/espocrm и переменные подключения к базе перечислены в той же документации EspoCRM, там же описаны отдельные контейнеры для фоновых задач и для WebSocket (протокола живых уведомлений в браузере). В Kubernetes веб-часть описывается объектом Deployment (документация Kubernetes), который пересоздаёт копию после сбоя и заменяет её при обновлении. Контейнер фоновых задач кладём в тот же под (группу контейнеров, которые запускаются вместе на одном узле) вторым контейнером и монтируем в оба один и тот же том, тогда они работают с одними файлами. На старте веб-часть запускаем в одной копии со стратегией обновления Recreate, причина в следующем шаге.

4. Сохраняем файлы. Постоянного хранения у EspoCRM требует не только каталог data с загруженными документами. Официальный Docker-пример EspoCRM выносит в постоянное хранилище ещё каталоги custom и client/custom с настройками и доработками. Опишите PersistentVolumeClaim (запрос на постоянный том, под который облако выдаёт диск) с явным storageClassName и примонтируйте том в эти каталоги. storageClassName это имя класса хранения, то есть типа диска для тома, а класс по умолчанию в кластере не задан. У другой CRM список каталогов берите из её документации. Без тома файлы пропадут при первом же пересоздании пода, а клиентские договоры к таким сюрпризам относятся плохо. Том с режимом ReadWriteOnce монтируется только на один узел, поэтому при обновлении по умолчанию новый под может уйти на другой узел и не получить занятый том, а стратегия Recreate сначала останавливает старый под. В Managed Containers (сервисе управляемого Kubernetes в VK Cloud) режим ReadWriteMany для PersistentVolumeClaim не реализован (хранилище в кластере). Чтобы развести копии веб-части по нескольким узлам, нужна общая файловая система, например NFS-сервер на отдельной виртуальной машине. Отдельно проверяется, что сама CRM корректно работает с общим каталогом из нескольких копий, а контейнер фоновых задач при этом выносится в отдельный Deployment с одной копией, иначе cron будет выполняться в каждой копии веб-части.

5. Открываем доступ сотрудникам. Аддон это дополнительный компонент кластера, который ставится из личного кабинета. Аддон Ingress NGINX выдаст внешний адрес, Ingress это правила входа HTTP-трафика в кластер (установка). Аддон cert-manager с объектом ClusterIssuer (настройками удостоверяющего центра вроде Let’s Encrypt) закроет адрес сертификатом HTTPS (установка). Подробный порядок выпуска сертификата разобран в статье цикла про сайт. Отдел продаж заходит по тому же доменному имени, что и до переезда, и не знает, что под капотом кластер.

На схеме ниже три части CRM в кластере: Ingress с HTTPS сверху, под ним Deployment веб-части и контейнер фоновых задач, рядом управляемая база в Cloud Databases и постоянный том с файлами клиентов.

Что подготовить до переноса

1. Образ нужной версии. Зафиксируйте версию CRM, с которой переезжаете, и соберите или возьмите официальный образ ровно этой версии. Обновление версии и переезд в кластер разводятся по разным дням, иначе причину любой странности будет не найти.

2. Дамп рабочей базы и прогон восстановления. До переключения разверните дамп на кластере Cloud Databases и проверьте, что CRM с ним запускается. Перенос данных репетируется заранее, а не в ночь переключения.

3. Список каталогов и фоновых задач. Выпишите, где конкретная установка хранит загруженные файлы, доработки и настройки. Туда же впишите фоновые задачи, которые у неё крутятся: рассылки, синхронизации, очереди. Каждому каталогу нужен том, каждой фоновой задаче своё место в поде.

4. Список интеграций. Почта, телефония, формы на сайте, обмен с 1С: каждой из них после переезда понадобится новый адрес или проверка старого. Составьте список до переноса, после он соберётся только по жалобам.

5. Окно переключения. Финальный дамп базы и перенос файлов в постоянный том делаются при остановленной старой системе. Длина окна зависит от объёма файлов, поэтому замерьте копирование заранее на репетиции.

Короче говоря для заметки:

1. CRM раскладывается на три части: Deployment для веба, управляемая база в Cloud Databases, постоянный том для файлов, настроек и доработок.

2. Адрес базы и пароли передаём через переменные окружения, в образ не зашиваем.

3. Веб-часть стартует в одной копии, потому что общий том на несколько узлов требует общей файловой системы и проверки самой CRM.

4. Доступ сотрудников идёт через Ingress с сертификатом от cert-manager, резервные копии базы лежат в объектном хранилище отдельно от кластера.