Розгортання 1С-Бітрікс у Kubernetes

Розгортання 1С-Бітрікс у Kubernetes

1С-Бітрікс не проектувався для контейнерної оркестрації. Сесії у файлах, кеш на диску, завантажені файли в upload/, ядро в bitrix/ — усе це «stateful» артефакти, які у Kubernetes потребують спеціальної обробки. Тим не менше завдання розв'язуване, і в production працюють навантажені Бітрікс-сайти в k8s-кластерах.

Основні проблеми при контейнеризації Бітрікс

Сесії. За замовчуванням PHP зберігає сесії у /tmp контейнера. При кількох репліках pod'ів різні запити одного користувача потрапляють на різні pod'и — сесія втрачається. Рішення: перемикаємо сховище сесій на Redis.

У .settings.php Бітрікс:

'session' => [
    'value' => [
        'mode' => 'separated',
        'handlers' => [
            'general' => [
                'type' => 'redis',
                'host' => 'redis-service',
                'port' => 6379,
            ],
        ],
    ],
],

Кеш. CACHE_TYPE=A у компонентах за замовчуванням пише в bitrix/cache/. При кількох репліках кеш не синхронізується. Перемикаємо на Memcached або Redis:

'cache' => [
    'value' => [
        'type' => ['memcache' => 'memcache'],
        'memcache' => [
            'host' => 'memcached-service',
            'port' => 11211,
        ],
    ],
],

Файли. Директорія upload/ повинна бути доступна всім pod'ам. Використовуємо PersistentVolumeClaim з режимом ReadWriteMany (NFS, CephFS, Longhorn у режимі RWX).

Ліцензія. Бітрікс прив'язує ліцензію до IP-адреси або домену, не до MAC-адреси контейнера. При хмарному деплої переконайтеся, що зовнішній IP стабільний або ліцензія оформлена на домен.

Структура Kubernetes-маніфестів

namespace: bitrix-prod
├── Deployment: bitrix-app (PHP-FPM + Nginx sidecar)
├── Service: bitrix-app-svc
├── Ingress: bitrix-ingress (з TLS)
├── StatefulSet: redis (або Redis Operator)
├── StatefulSet: memcached
├── PersistentVolumeClaim: bitrix-upload (RWX)
├── ConfigMap: php-fpm-config
├── ConfigMap: nginx-config
└── Secret: db-credentials

Deployment для PHP-FPM:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: bitrix-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: bitrix-app
  template:
    spec:
      containers:
        - name: php-fpm
          image: registry.example.com/bitrix-app:1.2.3
          volumeMounts:
            - name: upload
              mountPath: /var/www/html/upload
            - name: php-fpm-config
              mountPath: /usr/local/etc/php-fpm.d/www.conf
              subPath: www.conf
          env:
            - name: DB_HOST
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: host
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          volumeMounts:
            - name: upload
              mountPath: /var/www/html/upload
            - name: nginx-config
              mountPath: /etc/nginx/conf.d/default.conf
              subPath: default.conf
      volumes:
        - name: upload
          persistentVolumeClaim:
            claimName: bitrix-upload
        - name: php-fpm-config
          configMap:
            name: php-fpm-config
        - name: nginx-config
          configMap:
            name: nginx-config

Dockerfile для образу Бітрікс

FROM php:8.2-fpm-bullseye

RUN apt-get update && apt-get install -y \
    libzip-dev libpng-dev libjpeg-dev libwebp-dev \
    && docker-php-ext-install pdo_mysql zip gd opcache

RUN pecl install redis && docker-php-ext-enable redis
RUN pecl install memcached && docker-php-ext-enable memcached

COPY php.ini /usr/local/etc/php/conf.d/99-bitrix.ini
COPY --chown=www-data:www-data . /var/www/html

# upload/ монтується як PVC, тому виключаємо з образу
RUN rm -rf /var/www/html/upload

WORKDIR /var/www/html

Важливо: код Бітрікс (bitrix/, local/, публічні php-файли) запікається в образ. upload/ монтується зовні через PVC. Оновлення сайту = сборка нового образу + rolling update Deployment'а.

База даних поза Kubernetes

Базу даних MySQL/PostgreSQL не рекомендується запускати в k8s без спеціалізованих операторів (Percona Operator, CloudNativePG). Простіше використовувати managed-рішення: AWS RDS, Yandex Cloud Managed MySQL, або виділений сервер поза кластером. Бітрікс підключається за стандартним хостом і портом через Secret.

Горизонтальне масштабування

Після вирішення проблем з сесіями та кешем Deployment масштабується командою:

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-пайплайн

git push → GitLab CI/CD:
  1. docker build -t registry/bitrix-app:${CI_COMMIT_SHA} .
  2. docker push registry/bitrix-app:${CI_COMMIT_SHA}
  3. kubectl set image deployment/bitrix-app php-fpm=registry/bitrix-app:${CI_COMMIT_SHA}
  4. kubectl rollout status deployment/bitrix-app

Rolling update замінює pod'и по одному — нульовий downtime при деплоях.

Строки

Разом: 2–3 тижні для production-окружения. Для dev/staging — швидше.