1С-Бітрикс не проєктувався для контейнерної оркестрації. Сесії у файлах, кеш на диску, файли, що завантажуються, в upload/, ядро в bitrix/ — все це stateful артефакти, які в Kubernetes вимагають спеціальної обробки. Тим не менш, задача вирішувана, і в production працюють навантажені Бітрикс-сайти в k8s-кластерах. Ми розгорнули Бітрикс в Kubernetes для 15+ проєктів, і наш досвід показує: за 2-3 тижні можна отримати відмовостійку інфраструктуру з автоматичним масштабуванням.
Правильна контейнеризація Бітрикс дозволяє досягти нульового downtime при деплоях і легко переживати пікові навантаження. Наші клієнти економлять до 30% на інфраструктурних витратах, а проєкт окупається протягом півроку. У цій статті розберемо ключові проблеми та їх вирішення на основі реальних кейсів.
Однак багато команд стикаються з типовими помилками: неправильне налаштування сесій призводить до автоматичних розлогінів при масштабуванні, а зберігання кешу у файлах зводить нанівець переваги контейнеризації. Ми зібрали best practices, які допоможуть уникнути цих граблів.
Чому Kubernetes для Бітрикс — це виклик?
Головна проблема — Бітрикс зберігає стан (сесії, кеш, завантажені файли) локально на диску. В Kubernetes поди ефемерні: при перестворенні pod'а дані губляться. Без спеціальних налаштувань користувач втрачатиме сесію при кожному запиті, а кеш стане марним. Крім того, ліцензія Бітрикс прив'язана до IP або домену — при хмарному деплої потрібно забезпечити стабільний зовнішній IP. Додаткова складність — обробка завантажених файлів: у класичній схемі всі upload-файли лежать у спільній папці, доступній усім веб-серверам. Інтеграція з 1С через CommerceML вимагає тимчасових файлів, які повинні бути доступні всім подам. Бітрікс24 також може бути розгорнутий в Kubernetes, але його архітектура відрізняється — потрібна окрема конфігурація агентів і подій. Документація Kubernetes рекомендує використовувати PersistentVolume для stateful даних. Ми застосовуємо цей підхід вже в 15 проєктах.
Як ми вирішуємо проблему сесій і кешу?
Сесії. Перемикаємо зберігання сесій на Redis. У .settings.php Бітрикс прописуємо:
'session' => [ 'value' => [ 'mode' => 'separated', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => 'redis-service', 'port' => 6379, ], ], ], ], Кеш. Змінюємо CACHE_TYPE=A на Memcached:
'cache' => [ 'value' => [ 'type' => ['memcache' => 'memcache'], 'memcache' => [ 'host' => 'memcached-service', 'port' => 11211, ], ], ], Файли. Директорія upload/ монтується через PersistentVolumeClaim з режимом ReadWriteMany (NFS, CephFS). Код же запікається в Docker-образ — це прискорює деплой і спрощує управління версіями.
Як налаштувати зберігання файлів upload?
Для зберігання файлів upload ми використовуємо PersistentVolumeClaim з режимом доступу ReadWriteMany. Рекомендуємо NFS-сервер в кластері або хмарний файловий сторадж (наприклад, Яндекс Object Storage через FUSE). Важливо: код сайту повинен бути запічений в Docker-образ, а upload-директорія виключена з образу через .dockerignore. Це гарантує, що файли не загубляться при перестворенні подів. На практиці для каталогу з 2 млн товарів upload займає 50 ГБ — PV справляється без проблем.
| Рішення | Продуктивність | Надійність | Вартість |
|---|---|---|---|
| NFS | Середня | Висока | Низька |
| CephFS | Висока | Дуже висока | Середня |
| Хмарний сторадж (S3) | Низька-середня | Висока | Середня |
Типові помилки при контейнеризації Бітрикс
Розгорнути типові помилки
| Помилка | Наслідок | Рішення |
|---|---|---|
| Сесії у файлах | Втрата сесії при масштабуванні | Використовувати Redis |
| Кеш на диску | Низька продуктивність | Memcached або Redis |
| upload в образі | Розмір образу, втрата даних | PersistentVolume |
| Відсутність .dockerignore | Повільна збірка | Виключити upload і bitrix |
Чому базу даних варто винести за межі кластера?
Хоча MySQL можна запустити в Kubernetes через StatefulSet, ми настійно рекомендуємо використовувати managed-рішення (AWS RDS, Yandex Managed Service for MySQL). Це спрощує бекапи, реплікацію та оновлення. Бази даних — найкритичніший компонент, і їх обслуговування в кластері вимагає окремої експертизи. Наприклад, при збої etcd відновлення бази може зайняти години, а managed-рішення гарантує SLA 99.95%.
Структура Kubernetes-маніфестів
namespace: bitrix-prod ├── Deployment: bitrix-app (PHP-FPM + Nginx sidecar) ├── Service: bitrix-app-svc ├── Ingress: bitrix-ingress (з TLS) ├── StatefulSet: redis ├── StatefulSet: memcached ├── PersistentVolumeClaim: bitrix-upload (RWX) ├── ConfigMap: php-fpm-config ├── ConfigMap: nginx-config └── Secret: db-credentials Deployment для PHP-FPM з Nginx sidecar, монтуванням upload і конфігів — стандартний патерн. Базу даних (MySQL) рекомендуємо винести в managed-рішення — це надійніше і простіше в обслуговуванні.
Горизонтальне масштабування
Після налаштування Redis і Memcached масштабування — одна команда: kubectl scale deployment bitrix-app --replicas=5. Можна додати HorizontalPodAutoscaler:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: bitrix-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: bitrix-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 CI/CD-пайплайн
Ми використовуємо GitLab CI/CD: збірка Docker-образу, пуш в registry, rolling update через kubectl. Жодного downtime — поди замінюються по одному.
Терміни
| Етап | Зміст | Термін |
|---|---|---|
| Аналіз і підготовка | Аудит конфігурації Бітрикс, вибір рішень для сесій/кешу | 2–3 дні |
| Dockerfile + образ | Збірка, перевірка працездатності | 2–3 дні |
| k8s-маніфести | Deployment, Service, Ingress, PVC, ConfigMap, Secret | 3–4 дні |
| Redis/Memcached | Розгортання і налаштування session/cache | 1–2 дні |
| CI/CD | Пайплайн збірки і деплою | 2–3 дні |
| Тестування | Навантажувальні тести, перевірка sticky session | 2–3 дні |
Разом: 2-3 тижні для бойового середовища. Для dev/staging — швидше.
Що входить в роботу
- Аудит поточної конфігурації Бітрикс та інфраструктури.
- Розробка Dockerfile та Docker Compose для локальної розробки.
- Написання маніфестів Kubernetes (Deployment, Service, Ingress, PVC, Secret).
- Налаштування Redis та Memcached для сесій і кешу.
- Інтеграція CI/CD (GitLab/GitHub Actions) з rolling update.
- Навантажувальне тестування та оптимізація (до 1000 RPS).
- Документація з розгортання та експлуатації.
- Навчання вашої команди (1-2 сесії).
Наш досвід
Більше 7 років займаємося інфраструктурою на Бітрикс. Розгорнули 15+ проєктів в Kubernetes, включаючи каталоги з мільйонами товарів і високою відвідуваністю. Використовуємо тільки стабільні технології та best practices. Один із клієнтів — інтернет-магазин з 2 млн товарів і 50 000 унікальних відвідувачів на день. Після міграції downtime знизився до нуля, а швидкість завантаження сторінок зросла на 40%.
Замовте аудит вашої інфраструктури — ми оцінимо готовність до контейнеризації та запропонуємо оптимальний план. Зв'яжіться з нами для консультації.