Docker и Kubernetes для 1С-Битрикс: контейнеры и автомасштабирование

Вокруг Docker и Kubernetes много шума: их подают как обязательный шаг для любого современного проекта. На практике всё тоньше. Контейнеры решают конкретные проблемы — повторяемость окружений, предсказуемость релизов, автоматическое масштабирование, — и там, где этих проблем нет, оркестрация добавляет сложность без отдачи. Наша задача не продать самое модное решение, а понять вашу нагрузку, частоту релизов и боли команды и предложить ровно ту схему, которая окупится. Ниже разбираем, чем контейнеризация Битрикс отличается от привычного сервера, какие проблемы она снимает и где проходит граница между docker-compose и полноценным Kubernetes.

Почему Битрикс на вручную настроенном сервере буксует на релизах

Типовая история: проект живёт на одном сервере, окружение настроено руками, а разработка идёт на машинах разработчиков, где у каждого свой набор версий и расширений php. Пока правок мало, это терпимо. Но как только команда растёт и релизы учащаются, начинается боль. На тесте всё работает, а на проде падает из-за разницы в одной версии библиотеки. Деплой идёт по ssh вручную, его страшно катить в рабочее время и тяжело откатить, если что-то пошло не так. Поднять копию окружения под нового разработчика или отдельный тест занимает дни ручной настройки. И каждый такой инцидент — это потерянное время команды и риск для продакшена.

Корень проблемы — в том, что окружение не зафиксировано. Оно описано в головах и разрозненных инструкциях, а не в коде. Docker меняет это в корне: образ фиксирует окружение целиком, от версии php до настроек веб-сервера, и одна и та же сборка работает одинаково везде. Эта проблема тесно связана с настройкой самого окружения, поэтому контейнеризацию мы часто совмещаем с тонкой настройкой окружения и BitrixVM — внутри контейнера те же параметры пулов, памяти и кеша работают так же, как на отдельном сервере, только теперь они зафиксированы в образе и повторяемы.

Что даёт docker-compose, а что — Kubernetes

Важно различать два уровня. Docker-compose — это про разработку и небольшие развёртывания: он связывает контейнеры в единое окружение, которое поднимается одной командой. Этого часто достаточно, чтобы убрать главную боль — расхождение окружений и сложность разворачивания стендов. Команда получает одинаковые условия, новый разработчик стартует за минуты, а тест идёт на точной копии прода. Для многих проектов это и есть нужный уровень, и навязывать им Kubernetes было бы лишней тратой.

Kubernetes — это следующий уровень, про промышленную эксплуатацию под нагрузкой. Он оркеструет контейнеры в кластере: раскладывает их по подам, следит за состоянием через пробы, перезапускает упавшие, распределяет трафик через ingress и автоматически масштабирует площадку через HPA. Поднять дополнительные реплики php-fpm в пик и погасить их в затишье он умеет сам. Это окупается, когда нагрузка неравномерна, релизы часты, а простой недопустим. Граница между уровнями — не в размере сайта, а в характере нагрузки и темпе изменений, и определять её нужно по фактам, а не по моде. Сам этот выбор мы разбираем в рамках общей серверной и инфраструктурной оптимизации, где контейнеризация — лишь один из слоёв наряду с тюнингом окружения и кластеризацией.

Как мы храним данные и не теряем upload

Главное опасение при переходе в контейнеры — что данные потеряются. Оно обосновано: контейнеры эфемерны, при перезапуске или пересоздании их файловая система сбрасывается к образу. Поэтому изменяемые данные в контейнерах не держат. Загруженные файлы Битрикса, папку upload, кеш и базу данных мы выносим в persistent volumes — постоянные тома, которые живут отдельно от подов и переживают их перезапуск, переезд между узлами и пересоздание. Под нужно пересоздать при релизе — данные на месте. Узел вышел из строя и под переехал на другой — upload и база доступны как прежде.

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

Зачем нужен нагрузочный тест перед переключением

Сам факт переезда в Kubernetes не гарантирует, что площадка выдержит пик — автоскейл нужно настроить и проверить. Поэтому перед переключением прода мы поднимаем staging на тех же образах и манифестах и моделируем реальные сценарии: массовый заход в каталог, всплеск оформлений заказа, наплыв на популярный материал. Постепенно наращиваем нагрузку и смотрим, как HPA добавляет реплики, успевает ли он за ростом трафика, не упирается ли база, корректно ли работает ingress. Это превращает переход в управляемое событие, а не эксперимент на живых клиентах в день распродажи.

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

Как мы ведём переход без простоя

Контейнеризацию мы делаем параллельно с работающим сайтом, не трогая прод до самого конца. Сначала собираем образы и поднимаем окружение в docker-compose, проверяем сборку, миграции и обмен с 1С на копии данных. Затем разворачиваем кластер и staging, прогоняем нагрузочный тест. Прод переключаем в согласованное окно с минимальным простоем, заранее подготовив план отката. Если что-то пойдёт не так, возврат к прежней схеме занимает минуты, потому что старое окружение остаётся нетронутым до подтверждения, что новое работает стабильно. Такой подход исключает ситуацию, когда переезд ломает живые продажи.

Отдельное внимание — обмену с 1С и фоновым задачам Битрикса. Контейнеризация не должна нарушить интеграции и агенты, поэтому мы заранее раскладываем, как в новой схеме работают обмен, очереди и cron-задачи, и проверяем их на staging. Для проектов с активной разработкой связываем всё это с конвейером CI/CD: сборка образа, прогон проверок и деплой в кластер идут автоматически, а откат — это возврат к предыдущему образу одной командой.

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

«Контейнеры и Kubernetes — это сложно и не для нас». Сложность оркестрации реальна, но она ложится на нас, а не на вас. Мы настраиваем кластер, передаём манифесты и инструкции, а при желании берём эксплуатацию на себя. Кроме того, далеко не всем нужен именно Kubernetes — часто достаточно docker-compose, который проще и решает главную боль с окружениями. Мы предлагаем оркестрацию только там, где она реально окупается.

«Битрикс — монолит, его не контейнеризуешь нормально». Битрикс действительно не микросервис, но это не мешает упаковать его в контейнеры. Мы не дробим монолит, а раскладываем окружение на сервисы: веб-сервер, php, база, кеш. Сам проект остаётся как есть, меняется схема его развёртывания и масштабирования. Десятки Битрикс-проектов прекрасно живут в контейнерах именно по этой схеме.

«Это дорого и долго». Поэтому мы и начинаем с малого: docker-compose для разработки стоит ощутимо дешевле полноценного кластера и уже снимает главную боль с окружениями. Полный Kubernetes с автоскейлом подключаем тогда, когда нагрузка и темп релизов это оправдывают. А умный расчёт на этой странице помогает заранее прикинуть, сколько вы переплачиваете за простаивающее железо и что вернёт автомасштабирование.

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

Нагрузка и темп разработки бывают очень разными, и схема контейнеризации подстраивается под проект, а не наоборот. Для интернет-магазина с сезонными распродажами ядром становится Kubernetes с автоскейлом HPA и нагрузочным тестом перед каждым крупным пиком — реплики подов поднимаются в горячие дни и гасятся в затишье. Для B2B-портала, над которым работает команда, на первый план выходят повторяемые окружения dev, staging и prod на одних образах, чтобы релизы перестали ломать прод и каждый разработчик имел одинаковый стенд. Для медиа-портала с всплесками посещаемости важны быстрый автоскейл и отдача статики через ingress, чтобы массовый заход на популярный материал не клал площадку.

Отдельный сценарий — проект в очень активной разработке с десятками релизов в неделю. Здесь ядром становится конвейер CI/CD поверх контейнеров: сборка образа, автоматические проверки и деплой в кластер идут без ручных шагов, а откат — возврат к предыдущему образу за секунды. Все эти схемы мы собираем из одних и тех же кирпичей — образы, docker-compose, поды, ingress, HPA, persistent volumes, — но комбинируем их под вашу нагрузку и бюджет, а не выдаём самое дорогое решение по умолчанию.

Чем контейнеризация выгоднее альтернатив

У растущего Битрикс-проекта обычно три пути справиться с нагрузкой и релизами: терпеть ручной деплой и докупать всё более мощное железо под пик, собрать кластер без оркестрации с полуавтоматическими релизами или перейти на контейнеры с автомасштабированием. Первый путь дорог незаметно: команда тратит время на разбор окружений и боится релизов, а мощный сервер простаивает большую часть суток. Второй путь лучше, но узлы по-прежнему настраиваются руками, добавление мощностей не автоматизировано, а откат идёт по узлам. Оба варианта оставляют человеческий труд там, где его могла бы делать система.

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

Что входит в эксплуатацию кластера

Контейнеризация — не разовая акция: кластер живёт, образы обновляются, нагрузка меняется. Поэтому мы закладываем эксплуатацию с первого дня. Настроенный мониторинг ресурсов, состояния подов и доступности с алертами показывает, когда площадка подходит к потолку или под ведёт себя нештатно, и даёт время среагировать заранее. Резервное копирование томов и базы с проверенным планом восстановления превращает любой инцидент в управляемую ситуацию. Обновление образов php и системных компонентов мы проводим планово, прогоняя изменения через staging перед продом.

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

С чего начать

Начните с аудита инфраструктуры. Расскажите о вашем проекте, текущем окружении, частоте релизов и целевом трафике — мы разберём, где теряется время команды и какой потолок у площадки, и покажем, что даст контейнеризация в цифрах. По итогам вы получите честную картину: нужен ли вам Kubernetes или достаточно docker-compose, какой запас по нагрузке вы получите и сколько сэкономите на железе. Аудит бесплатный, а смету на работы пришлём в течение рабочего дня. Обсудим вашу инфраструктуру — и сделаем её гибкой, быстрой и предсказуемой.