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

Часть приложений запускалась на виртуальных машинах, часть — в отдельных Kubernetes-кластерах. Инфраструктурные ресурсы находились в нескольких облачных каталогах. Конфигурации большинства сервисов доставлялись через CI, однако отдельные приложения оставались вне общего процесса.

В системе накопилось несколько классов проблем. Использовались устаревшие операционные системы. У критичных компонентов оставались единые точки отказа. Сбои отдельных вспомогательных сервисов могли замедлять или останавливать основную платформу. Сброс кэша Битрикса создавал резкий рост нагрузки на MySQL.

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

Какие проблемы мы обнаружили

Инфраструктура не воспроизводилась целиком

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

Это усложняло развитие инфраструктуры и повышало риск расхождения между кодом и фактическим состоянием облака.

Критичные компоненты имели единые точки отказа

Базы данных, поисковый движок и некоторые инфраструктурные сервисы не имели полноценного резерва либо работали на отдельных виртуальных машинах.

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

Приложения были связаны с особенностями старой среды

Некоторые контейнеры запускали несколько процессов под управлением supervisord. В одной среде совмещались PHP-FPM, веб-сервер и фоновые процессы. Такой подход работал на виртуальных машинах, но плохо соответствовал модели Kubernetes.

У Битрикса часть пользовательских файлов и статики исторически хранилась локально. Это мешало свободно перезапускать и масштабировать контейнеры: новый экземпляр приложения должен был получать доступ к тем же данным.

Не было единого способа развертывания сервисов

Приложения использовали разные Dockerfile, CI-конфигурации и способы передачи переменных окружения. Некоторые сервисы уже развертывались автоматически, другие сохраняли исключения из общего процесса.

Добавление нового приложения или окружения требовало разбираться в индивидуальной конфигурации. Это увеличивало число ручных действий и вероятность ошибки при выпуске изменений.

Контуры разработки и продакшена управлялись неодинаково

Команда использовала динамические стенды для отдельных веток, но их требовалось перенести в новую инфраструктуру и связать с общим процессом GitOps.

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

Наблюдаемость была распределена между разными системами

Мониторинг и логирование существовали, но были связаны с отдельным инфраструктурным контуром. После миграции приложений требовалось заново связать метрики, логи, алерты и состояние Kubernetes.

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

Архитектурные проблемы проявлялись под нагрузкой

Сброс кэша Битрикса приводил к росту запросов к MySQL. Уже после миграции наблюдение за новой средой показало еще один источник нагрузки: продолжительные пики CPU базы совпадали с работой фоновых задач Битрикса.

Проблема находилась не только на уровне инфраструктуры. Поведение приложения, кэша, фоновых процессов и базы данных нужно было рассматривать как единую систему.

Внешний сетевой контур создавал дополнительные риски

Во время переключения возникли ошибки на стыке CDN, DNS и нового ingress-контура. Часть запросов получала некорректные ответы из-за особенностей SNI и повторного использования соединений.

Это нельзя было исправить только настройкой Kubernetes. Потребовалась совместная диагностика поведения внешнего провайдера и нового шлюза, а также отдельные проверки маршрутизации, заголовков и сертификатов.

Что было сделано

Провели инвентаризацию приложений и зависимостей

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

Отдельно разобрали конфигурацию Битрикса: версию PHP, подключение к MySQL и Redis, работу с RabbitMQ, расположение пользовательских файлов и правила отдачи статики.

Инвентаризация позволила определить порядок миграции и увидеть связи, которые нельзя было разрывать независимо друг от друга.

Спроектировали целевую облачную архитектуру

Основой новой среды стал управляемый Kubernetes. Для приложений, инфраструктурных компонентов, мониторинга, очередей и аналитического контура предусмотрели отдельные группы нод.

Базы данных и поисковый движок вынесли в управляемые сервисы там, где это уменьшало сложность эксплуатации. MySQL был развернут с репликацией, Elasticsearch заменен на управляемый OpenSearch. Для кэша использовался отдельный Redis.

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

Описали инфраструктуру кодом

Для облачных ресурсов подготовили структуру Terraform и Terragrunt с раздельными состояниями и переиспользуемыми модулями.

Кодом были описаны сети, права доступа, Kubernetes, группы нод, объектные хранилища, базы данных, Redis и OpenSearch. Для изменений инфраструктуры настроили CI-пайплайны.

В результате новая среда перестала быть набором вручную созданных ресурсов. Ее конфигурация стала проверяемой и воспроизводимой.

Стандартизировали упаковку приложений

Сервисы подготовили к работе в Kubernetes. Процессы, которые раньше запускались вместе под supervisord, разделили по контейнерам и ролям.

Для сборки приложений настроили базовые образы и CI-процесс с публикацией в registry. Версии системных компонентов и зависимостей были зафиксированы в сборочных конфигурациях.

Пользовательские файлы и статику Битрикса перевели на объектное хранение. Это позволило запускать несколько экземпляров приложения без привязки к локальному диску конкретного контейнера.

Внедрили единый Helm-шаблон

Для приложений подготовили универсальный Helm-чарт, включающий Deployment, Service, Ingress и настройки горизонтального масштабирования.

Чарт связали с механизмом управления секретами и автоматическим перезапуском приложений при изменении конфигурации. Для него настроили проверки и подготовили примеры использования для разных типов сервисов.

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

Перестроили CI/CD и внедрили GitOps

В кластере развернули Argo CD. Манифесты приложений вынесли в отдельный репозиторий со структурой по сервисам и окружениям.

Пайплайны стали выполнять последовательность проверок, тестирования, сборки и публикации образов, после чего обновлять GitOps-репозиторий. Доставка изменений в кластер выполняется Argo CD на основании состояния Git.

Для разработки сохранили динамические стенды, создаваемые для отдельных веток. Доступ к тестовым окружениям и продакшену разделили по ролям.

Организовали управление секретами

Секреты перестали храниться в манифестах приложений. Для их передачи из CI-системы в Kubernetes внедрили External Secrets Operator.

Изменения конфигурации автоматически вызывают перезапуск нужных приложений. Для критичных значений предусмотрели инъекцию без сохранения секретов в Git.

Это уменьшило число ручных операций и риск попадания чувствительных данных в репозитории.

Перенесли мониторинг и логирование

В новом кластере развернули Prometheus Operator, Grafana, VictoriaLogs, Node Exporter и kube-state-metrics.

Метрики приложений и инфраструктуры были собраны в едином контуре. Настроены базовые дашборды, Alertmanager и маршрутизация уведомлений.

Новый контур помогал не только контролировать состояние Kubernetes, но и расследовать проблемы после переключения: нагрузку на базы, работу фоновых процессов, состояние реплик и ошибки сетевого взаимодействия.

Мигрировали сервисы и данные

В Kubernetes перенесли Битрикс, приложения на Laravel, RabbitMQ и другие сервисы платформы. Аналитический контур разместили на отдельной группе нод того же кластера.

Данные MySQL и PostgreSQL переносились после остановки сервисов, выполняющих запись. После копирования MySQL был запущен основной узел и включена репликация. Elasticsearch был заменен на OpenSearch с переносом индексов и обновлением адресов подключения.

Один из вспомогательных сервисов оставили на отдельной виртуальной машине, чтобы его технический долг и особенности эксплуатации не влияли на основной кластер.

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

Провели диагностику после переключения

После запуска возникли проблемы, которые нельзя было полностью воспроизвести до миграции: ошибки внешнего CDN, высокая нагрузка на MySQL, отдельные сбои фоновых обработчиков и нехватка ресурсов для динамических стендов.

Для сетевой проблемы были проверены DNS, сертификаты, SNI, Host-заголовки и поведение keepalive-соединений. Для базы сопоставили графики CPU с активностью приложений и установили корреляцию между продолжительными пиками нагрузки и фоновыми задачами Битрикса.

Также проверили состояние Redis, очередей, репликации, обработчиков сообщений и доступность сервисов через новые точки входа. Обнаруженные проблемы разбирались уже на уровне конкретных связей между приложением и инфраструктурой, а не как отказ всей платформы.

Результат

Клиент получил единую инфраструктурную платформу вместо набора виртуальных машин, отдельных кластеров и индивидуальных схем развертывания. Основные приложения и инфраструктурные компоненты были перенесены в Kubernetes, базы данных и поисковый движок — в более управляемую и отказоустойчивую конфигурацию.

Материалы проекта не подтверждают, что после миграции были окончательно устранены все прикладные причины высокой нагрузки. Наблюдаемость новой платформы позволила локализовать одну из них до фоновых задач Битрикса и отделить ее от проблем самого Kubernetes или базы данных.

инфраструктура описана кодом и стала воспроизводимой

приложения развертываются через единый Helm-шаблон

доставка изменений переведена на CI/CD и GitOps

динамические стенды сохранены в новой архитектуре

производственные и тестовые доступы разделены

секреты исключены из Git-репозиториев

пользовательские файлы Битрикса вынесены из локальных контейнеров в объектное хранилище

MySQL работает с репликацией

Elasticsearch заменен на управляемый OpenSearch

мониторинг, логирование и алерты собраны в едином контуре

диагностика нагрузки стала опираться на метрики конкретных приложений и процессов

снизилась зависимость платформы от отдельных виртуальных машин и ручных операций

Вывод

Главной задачей проекта был не перенос контейнеров в Kubernetes сам по себе. Требовалось привести к общей модели приложения, облачные ресурсы, базы данных, CI/CD, секреты, мониторинг и процессы разработки.

Пока эти элементы управлялись независимо, исправление одного компонента не устраняло системные риски. После миграции инфраструктура стала описываться едиными правилами, а сбои — локализоваться на уровне конкретного сервиса, зависимости или внешнего провайдера.

Это изменило уровень зрелости платформы: дальнейшее развитие больше не требует воспроизводить исторически сложившийся набор ручных настроек.

Смотрите другие
кейсы по Bitrix

Error get alias

Хотите передать
свою инфраструктуру в надежные руки?

Будем рады проконсультировать вас и обсудить проект.

Миграция крупной веб-платформы в Kubernetes и перестройка инфраструктуры

О клиенте

Исходная ситуация