Битрикс в k8s: оно работает
В этой статье мы расскажем про один интересный кейс миграции, который начался с аудита, а закончился не только полным переносом ИТ-инфраструктуры, но также внедрением ряда новых технологий. Как это произошло, почему для решения задач выбрали Kubernetes и Nova, зачем потребовались Consul и s3fs, как мы решали задачи обеспечения безопасности? Читайте под катом.
Привет, Хабр! Меня зовут Илья Саламатов, я работаю менеджером продукта в K2 Cloud. Начнем эту историю с самого начала. К нам обратился один из лидеров по производству и оптовой дистрибуции канцтоваров в России. У него возникла задача оптимизировать работу интернет-магазина с более чем 10 000 уникальных позиций (SKU). Приложения e-commerce собственной разработки на базе Битрикс были развернуты на своей инфраструктуре в формате on-premise. Доступность сервисов была нестабильной и иногда проваливалась ниже 90%. Разумеется, бизнес хотел обеспечить стабильный SLA для сервисов e-com, потому что проблемы с сервисом негативно сказывались на объеме продаж, так как сайт — основной канал сбыта. Плюс ко всему этому в компании не было обилия ИТ-специалистов, и за все инфраструктурные сервисы отвечал один и тот же человек.
Аудит и подбор инструментов
Тут, конечно, можно сказать: «Переезжайте в облако!» Но фактически простого переноса существующей инфраструктуры «как есть» бывает недостаточно (и очень часто). Работа любой инфраструктуры зависит от среды, в которой она запускается. Например, при использовании физических серверов (bare metal) применяются одни инструменты, тогда как в облаке уместны решения, ориентированные на работу в cloud-native среде. И замена одних на другие не всегда проходит гладко.
Чтобы проанализировать, какие инструменты и как внедрять, мы предложили верхнеуровневый аудит инфраструктуры. В результате был найден ряд вопросов, которые нужно было решать в любом случае:
на некоторых участках инфраструктуры использовались избыточные инструменты. Например ненужная иерархия балансировки нагрузки, которая не влияла на маршрутизацию трафика — трафик без изменения проходил по множеству однотипных балансировщиков;
часть компонентов не обеспечивали должную отказоустойчивость. Так, некоторые инфраструктурные сервисы были запущены в единственном экземпляре, и при выходе их из строя сайт становился недоступным;
ряд инструментов нес дополнительную нагрузку и не мог быть перенесен в облако легко и просто. Поэтому часть из них были переработаны, в частности, решение о файловом хранилище для объединенной директории для ядра Битрикса.
Вместе с миграцией
Цель проекта заключалась в повышении SLA. Но одновременно с этим нам удалось и оптимизировать инфраструктуру, что позволило сделать ее проще и снизить затраты. Чтобы добиться этих целей, были выбраны именно те инструменты, которые работают сегодня.
Контейнеризация
К счастью, нам не потребовалось контейнеризировать Битрикс с нуля, так как заказчик уже в тестовом окружении собирал рабочий образ. Поэтому, взяв его за основу, мы оптимизировали сборку. Такой подход позволил использовать единый образ в продакшен окружении.
Балансировка
Как я уже говорил, у заказчика была развернута достаточно сложная система балансировки из-за многих доработок как со стороны разработки, так и текущего инфраструктурного инженера. Было сразу несколько балансировщиков, которые дублировали работу друг друга. С одного балансировщика трафик шел на второй, а иногда и на третий! Никаких изменений уже не происходило, и эта часть инфраструктуры была избыточной.
Чтобы избавиться от нее, мы проанализировали иерархию балансировщиков, отсеяли старую и ненужную информацию и превратили все полезное в Ingress-правила. В результате практика балансировки была качественно обновлена.
Кластеризация
При реализации кластерной инфраструктуры мы стремились максимально задействовать возможности PaaS (Platform as a Service). Дело в том, что PaaS-системы K2 Cloudпозволяют автоматически создавать кластеры, а также выбирать одну в качестве арбитра. Арбитр помогает уменьшить общие затраты на ресурсы кластера, так как его основная функция заключается в выборе ведущего узла (мастера) и он не обрабатывает основную нагрузку. Тем не менее, благодаря наличию арбитра, обеспечивается автоматическая отказоустойчивость системы за счёт механизма кворума.
В ходе оптимизации инфраструктуры мы кластеризовали Redis (а он не был кластеризован — у каждого сервиса был свой контейнер с Redis). Была проведена работа с RabbitMQ, который, хоть и существовал в кластерном режиме, но очереди не были настроены на работу кластера, и в случае возникновения проблем на нодах очередь точно так же падала.
Кластер СУБД, хоть и существовал, но для активной работы на нем использовалась только одна нода. Мы увеличили эффективность СУБД и ее производительность за счет ProxySQL. Одни ноды были настроены на чтение, другие — на запись. Лучше распределяется нагрузка, а производительность увеличилась кратно.
Для автоматизации развёртывания сервисов, которые еще не доступны в виде готовых PaaS-решений, мы использовали инструменты Terraform с провайдером k2cloud и Ansible.
Оптимизация образов
У заказчика уже был более-менее готовый образ для бэкенда. Но он имел очень большой размер, а некоторые зависимости были установлены неоптимально. Вообще, это нормальная история, когда в подготовке образа не используются классические ноу-хау, которые помогают подобные образы сделать оптимальными. После их применения скорость сборки выросла на 20%, а объем образа сократился вдвое. Это решение мы и оставили для продакшена.
Единая платформа для управления
У заказчика еще шло накопление опыта по Kubernetes, и ресурсов на самостоятельное управление всей экосистемой не хватало. Но им хотелось не просто отдать все на аутсорсинг, но сохранить доступ к приложению, в какой-то мере управлять инфраструктурой, получить возможность чтения логов и определенного уровня администрирования
Поэтому мы решили использовать платформу для управления контейнерами и остановили выбор на новом российском решении Nova Container Platform. Nova предлагает удобную веб-консоль, что значительно упрощает мониторинг и отладку приложений. Кроме того, богатая базовая функциональность данной платформы позволила нам быстро интегрироваться и начать её использование, несмотря на то, что разработчик на стороне заказчика ранее не работал с такими продуктами, как Kubernetes.
Кроме удобных инструментов, управление Nova показывает достаточно богатую функциональность »из коробки» — это базовая безопасность, поддержка со стороны вендора, простота развертывания. Благодаря сотрудничеству компаний K2Cloud и Orion Soft было создано единое окно обслуживания, что помогает заказчику быстрее решать все технические вопросы.
Создание хранилищ данных
Для того чтобы Битрикс работал на базе Kubernetes, мы применили несколько интересных решений для работы с постоянными хранилищами (persistent storage). Наш поставщик облачного хранилища (EBS) поддерживает использование типа хранилищ ReadWriteOnce.
Мы также использовали хранилища с поддержкой режимов доступа ReadWriteMany разных типов, одним из которых является Longhorn. Этот инструмент предоставляет возможности для управления постоянными хранилищами в стиле cloud-native и поддерживает режимы RWX и RWO. Кроме этого, Longhorn позволяет предоставить реальный том RWX с функциями бэкапа и провизионинга.
Благодаря использованию Longhorn, мы смогли обеспечить отказоустойчивость ядра сайта, так как для 1С-Битрикс требовалось общее хранилище для определенных директорий, чтобы Битрикс мог записывать и читать информацию единообразно.
Также мы применили утилиту s3fs, которая даёт возможность использовать облачные хранилища (Bucket) как файловую систему. Драйвер этой системы легко устанавливается в Kubernetes, что позволяет объединить инструменты, работающие как внутри, так и снаружи Kubernetes, в одну общую файловую систему. Через утилиту был налажен обмен данными с площадками заказчика по текущим ценам и товарным остаткам через облачное хранилище S3.
Новая служба каталога
Для служебных задач мы использовали решение FreeIPA, которое позволяет осуществлять аутентификацию и идентификацию пользователей. Это полезно как для службы техподдержки, так и для заказчиков, которым нужно диагностировать возможные проблемы в приложении.
Мы использовали технологию single sign-on (SSO), чтобы обеспечить авторизацию через единого провайдера и удобство использования инфраструктуры. FreeIPA проводит авторизацию пользователей и обеспечивает интеграцию с другими системами, в том числе с Nova Container Platform, удаленное подключение через VPN. Благодаря готовым модулям интеграция с доменом FreeIPA настраивалась легко.
Перенос существующих элементов
Одним из примеров вынужденного переноса сервисов стал Consul. Те сервисы, которые находились в Docker на отдельной виртуальной машине, »общались» друг с другом именно через Consul, это было зашито в код самих сервисов заказчика. После первого же аудита мы поняли, что быстро перейти на Kubernetes Service Discovery не получилось бы.
В Consul лежали (и лежат) значительное количество вспомогательных сервисов, необходимых для интеграции с внутренними системами заказчика. Они работали через Docker Compose на одной виртуальной машине, что не гарантировало их высокую доступность. Наша команда разработала манифесты для надежного размещения этих сервисов на несколько зон доступности, чтобы обеспечить их отказоустойчивость.
Инфраструктура как код
Для настройки Kubernetes-платформы был использован подход GitOps, который подразумевает хранение всей инфраструктуры, включая системные настройки и само приложение, в репозитории Git. FluxCD, являющийся частью платформы Nova Container Platform, позволяет автоматически синхронизировать инфраструктуру с файлами в Git, делая Git основным источником актуальной информации о развернутых ресурсах.
Мы помогли настроить непрерывное развертывание обновлений для нового приложения с использованием FluxCD и его компонента — Image Automation. Этот инструмент постоянно отслеживает обновления образов в реестре (Registry) и автоматически разворачивает новые версии на инфраструктуре как только они становятся доступны.
Внедряя Git, мы следовали уже не только пожеланиям заказчика, а собственным стандартам развития инфраструктуры. Кстати, то, что мы развертывали при помощи Terraform, также хранится в Git, и FluxCD обновляет информацию из этого же репозитория. В результате теперь заказчик сам готовит обновления, запаковывает в образы и загружает в нашу облачную среду. Благодаря этому подходу у нас (и у заказчика) имеется достоверная информация о том, что развернуто. Кроме того, налажено автоматическое обновление образов на базе FluxCD.
Результаты и выводы
Миграция экосистемы Битрикс в К2 Облако с одновременной модернизацией инфраструктурных сервисов позволила достичь гарантированного SLA на уровне 99,95%. В результате была гарантирована стабильная работа сайта и поднято качество предоставляемых электронных коммерческих услуг. Также в рамках проекта была заложена возможность легкого масштабирования всей архитектуры для адаптации к росту объемов продаж в e-commerce сегменте.
По итогам на плечах нашей команды осталась поддержка инфраструктурных компонентов, включая саму среду Kubernetes, облачное пространство на трех зонах доступности, связность, мониторинг, гарантии доступности, регламентные обновления и отработка запросов на обслуживание, а также задачи по DevOps. То есть обновление существующих и внедрение новых компонентов лежит на нашей стороне. Такой аутсорсинг помог решить проблему недостатка ресурсов у заказчика и повысить качество обслуживания микросервисной архитектуры, а также ускорить и улучшить процесс разработки.
Как видите, получился интересный и достаточно объемный проект, из которого можно сделать несколько выводов:
Перенести Битрикс в облако можно с повышением уровня SLA. Для этого есть наработанные схемы, лучшие практики, и данное ПО прекрасно чувствует себя в контейнерах на облачной инфраструктуре. Да, практика показывает, что и такое ПО вполне может быть подвергнуто контейнеризации, и это не что-то сверхъестественное.
Перенос Битрикс поднимает целый ряд дополнительных задач, таких как модернизация связанных инструментов и сервисов, организация хранилищ, настройку кластеров и так далее. То есть решить эту задачу по-простому штатными средствами кластеризации Битрикс можно только в том случае, если вы не разрабатывали ничего дополнительного, да и тут придется все равно шаманить с балансировкой и хранением данных.
Облачная схема работы повышает производительность Битрикс. На этом проекте большую роль играла связность распределенной инфраструктуры. Все дата-центры K2 Cloud находятся в одной части Москвы, поэтому скорость и производительность сети, соединяющей ЦОДы, получается близкой к локальной сети. Поэтому даже требовательные к задержкам и отклику системы могут быть развернуты в трех зонах доступности в режиме катастрофоустойчивости.
Подводя итог, можно сказать, что миграция кастомизированных инструментов в облако — непростая задача. Но за счет уже наработанных практик ее удалось решить в режиме аутсорсинга. А учитывая, что Битрикс на сегодня является одним из наиболее популярных движков для сайтов и порталов, думаю, подобных проектов будет становиться только больше. И я буду рад, если наш опыт поможет вам в выборе стратегии для решения аналогичных задач.
