Поддержка Docker и Kubernetes для проектов на 1С-Битрикс

Контейнеры стали стандартом, и желание «завернуть Битрикс в Docker» возникает почти у каждой команды, которая упёрлась в потолок одного сервера. На бумаге всё просто: взять образ с PHP, положить туда код, поднять рядом базу — и готово. На практике именно Битрикс контейнеризируется сложнее многих систем, потому что он хранит много состояния и плотно работает с файловой системой. Ниже разбираем, чем Docker отличается от Kubernetes в контексте Битрикс, когда нужен каждый из них и на какие грабли наступают чаще всего.

Чем Docker отличается от Kubernetes простыми словами

Docker — это технология упаковки приложения в контейнер: вы описываете, какие версии PHP, расширений и зависимостей нужны, и получаете образ, который одинаково запускается где угодно. docker-compose добавляет к этому возможность поднять несколько контейнеров вместе — php-fpm, nginx, базу — одной командой. Этого достаточно для разработки и для небольших проектов на одном сервере. Kubernetes — это оркестратор: он управляет множеством контейнеров на множестве серверов, сам перезапускает упавшие поды, балансирует нагрузку, масштабирует реплики и выкатывает обновления без простоя. Грубо говоря, Docker отвечает на вопрос «как запустить контейнер», а Kubernetes — «как держать сотни контейнеров живыми и под нагрузкой».

Для Битрикс это значит следующее. Если у вас один сайт на одном сервере и редкие релизы, часто достаточно Docker и docker-compose: вы получаете воспроизводимое окружение и избавляетесь от ручной настройки. Если же проект растёт, появляются пиковые нагрузки, несколько окружений и частые деплои, в дело вступает Kubernetes с автомасштабированием, helm-чартами и плавной выкаткой. Мы не навязываем кластер там, где он избыточен, а на бесплатном аудите прямо говорим, какой уровень оркестрации действительно нужен вашему проекту.

Почему Битрикс не контейнеризируется в лоб

Главная ловушка — состояние. Битрикс активно пишет в каталог upload загруженные пользователями и администраторами файлы, ведёт кэш и хранит сессии. Если всё это остаётся внутри контейнера, то при любом пересоздании пода — а в Kubernetes поды пересоздаются постоянно — данные исчезают. Поэтому upload, кэш и сессии обязательно выносятся в постоянное хранилище, общее для всех реплик. Иначе горизонтальное масштабирование ломает сайт: один пользователь загрузил файл на один под, а следующий запрос ушёл на другой под, где этого файла нет.

Вторая ловушка — база данных. mysql в контейнере удобно для разработки, но на проде база требует особого внимания: постоянного хранилища, аккуратных обновлений и резервного копирования. Мы либо выносим базу в statefulset с надёжным томом, либо рекомендуем управляемый кластер базы данных у провайдера, если это надёжнее для вашей нагрузки. Третья ловушка — обмен с 1С и фоновые задачи: агенты и крон Битрикс нельзя запускать на каждом поде, иначе задачи задвоятся. Их выносят в отдельный под, чтобы обмен и обработки шли в одном экземпляре.

Зачем нужны окружения dev, staging и prod из одного чарта

Самая частая причина неожиданных багов на проде — разница окружений. На машине разработчика одна версия PHP, на тесте другая, на бою третья, конфиги правились руками в разное время. helm-чарт решает это радикально: все три окружения собираются из одного шаблона, отличаются только значениями — доменом, ресурсами, числом реплик. Образы те же самые, прошедшие тот же путь сборки. Поэтому если изменение отработало на staging, на проде оно поведёт себя так же. Дрейф конфигураций, на который уходят часы отладки, просто исчезает как класс.

Для команды это меняет ритм работы. Разработчик поднимает окружение одной командой и не тратит день на настройку. Тестировщик получает стенд, идентичный продакшену. Релиз-инженер выкатывает изменения через тот же чарт, что и на тесте. Когда инфраструктура описана кодом, к ней применимы те же практики, что и к самому коду: ревью, история изменений, откат к предыдущей версии. Если вам важна и автоматизация выкаток, мы настраиваем конвейер вместе с коллегами по направлению DevOps и серверной поддержки, чтобы деплой в кластер запускался по кнопке или по событию в репозитории.

Как мы делаем деплой без простоя

Zero-downtime деплой — это не магия, а связка нескольких правильно настроенных механизмов. Сначала задаётся проба готовности: Kubernetes не отправляет трафик на под, пока тот не ответит, что готов обслуживать запросы. При выкатке кластер поднимает новые поды рядом со старыми, ждёт, пока они пройдут healthcheck, и только потом плавно переключает трафик, выводя старые реплики. Если новый под не проходит проверку, развёртывание останавливается и откатывается, а пользователи продолжают работать на прежней версии. Для Битрикс важно правильно настроить проверку готовности так, чтобы она учитывала прогрев кэша и доступность базы, иначе плавная выкатка превратится в фикцию.

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

Persistent volumes, секреты и безопасность

Постоянное хранилище — сердце контейнеризированного Битрикс. Каталог upload подключается как persistent volume с режимом доступа для нескольких подов одновременно, чтобы любая реплика php-fpm видела одни и те же файлы. Кэш и сессии выносятся в общий быстрый слой, чтобы балансировка между подами не разлогинивала пользователей и не сбрасывала корзины. База данных получает отдельный надёжный том и регулярные резервные копии. Все чувствительные данные — пароли базы, ключи интеграций, токены платёжных и логистических сервисов — хранятся в секретах Kubernetes и подключаются к подам в момент запуска, а в репозитории остаются только шаблоны без паролей.

Безопасность мы закладываем с первого дня: доступ к кластеру разграничен по ролям, трафик идёт по HTTPS через ingress с TLS, образы собираются из проверенных базовых слоёв и регулярно обновляются для закрытия уязвимостей. Это особенно важно для проектов, где контейнеры соседствуют с обменом данными и платежами — тему безопасной эксплуатации мы детальнее разбираем в рамках поддержки и развития проектов на Битрикс.

Когда кластер окупается, а когда достаточно Docker

Мы не уговариваем всех подряд строить Kubernetes. Полноценная оркестрация оправдана, когда у вас ощутимый трафик с пиками, несколько окружений, частые релизы и требования к отказоустойчивости, при которых даже короткий простой стоит денег. В этом случае автомасштабирование, плавная выкатка и самовосстановление кластера окупаются быстро. Если же это один сайт со стабильной нагрузкой и редкими обновлениями, иногда честнее и дешевле остановиться на Docker с docker-compose и хорошо настроенном одном сервере. На аудите мы оцениваем нагрузку, частоту релизов и цену простоя и предлагаем уровень, который реально нужен, а не максимальный по прайсу.

Как мы ведём проект по шагам

Чтобы переход был предсказуемым, мы разбиваем его на понятные этапы. Первый — аудит инфраструктуры: разбираем текущий сервер, версии, нагрузку, точки отказа и особенности проекта, фиксируем целевую схему. Второй — сборка образов php-fpm, nginx и mysql под ваш стек и подготовка docker-compose, чтобы разработчики сразу получили воспроизводимое окружение. Третий — описание манифестов и helm-чарта: поды, сервисы, ingress, тома, секреты и автоскейл. Четвёртый — развёртывание staging, перенос данных и upload, нагрузочная обкатка и отработка сценариев деплоя и отката.

Пятый этап — вывод прода на кластер с настройкой zero-downtime деплоя, healthcheck и горизонтального масштабирования. Шестой — сопровождение: мониторинг подов и метрик, обновление образов и чартов, масштабирование под нагрузку, резервное копирование и реакция на инциденты по SLA. На каждом этапе мы показываем результат и передаём документацию, чтобы инфраструктура была прозрачной и управляемой вашей командой.

Возражения, которые мы слышим чаще всего

«Kubernetes — это сложно и дорого, нам столько не нужно». Часто так и есть, поэтому мы и начинаем с аудита: если хватает Docker, предлагаем именно его. А там, где кластер действительно нужен, helm-чарт и автоматизация снижают сложность эксплуатации, а не повышают её. «У нас всё работает на одном сервере, зачем менять». Пока не упёрлись в пик или простой при деплое — возможно, и не нужно. Но как только релизы участились, а распродажи кладут сайт, контейнеризация окупается снятыми простоями и нервами. «Боимся потерять данные при переезде». Перенос мы обкатываем на staging, upload и базу переносим с проверкой целостности, а прод переключаем только после успешной обкатки и с готовым откатом.

Сценарии, под которые мы собираем кластер

Контейнеризация подстраивается под тип проекта, а не наоборот. Для интернет-магазина на первый план выходит автоскейл под распродажи и быстрая отдача каталога: реплики php-fpm и nginx наращиваются по нагрузке, а статика и upload отдаются из общего тома без узких мест. Для B2B-портала и личных кабинетов критична одинаковость окружений и частые релизы без простоя, поэтому ядром становится helm-чарт для dev, staging и prod и плавная выкатка с откатом. Для медиа и контентных проектов с тяжёлой статикой важны кэширующий слой и оптимальная работа с постоянным хранилищем, чтобы пиковый трафик не упирался в диск.

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

Чем контейнеры выгоднее одного сервера в долгую

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

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

Что вы получаете в итоге

По итогам проекта у вас остаётся воспроизводимая инфраструктура, описанная кодом: образы, helm-чарты, манифесты и документация. Окружения dev, staging и prod собираются из одного шаблона и не разъезжаются. Деплой проходит без простоя, кластер сам держит нагрузку и восстанавливается после сбоев, а upload и сессии надёжно живут в постоянном хранилище. Всё это разворачивается на вашем кластере и остаётся вашей собственностью без привязки к подрядчику — развивать инфраструктуру сможет как наша команда, так и любая другая. А мы готовы взять эксплуатацию на себя с мониторингом 24/7 и SLA, чтобы вы занимались продуктом, а не серверами. Начните с разговора: расскажите о вашей инфраструктуре, нагрузке и частоте релизов — мы проведём бесплатный аудит, предложим уровень оркестрации под задачу и пришлём смету в течение рабочего дня.