Настройка Docker-контейнеров для 1С-Битрикс под ключ

Настройка Docker-контейнеров для 1С-Битрикс: от хаоса к стабильности

Мы часто видим, как запуск Битрикс в Docker делают несложно — достаточно одной команды docker-compose up. Но стабильная работа в production с корректным перезапуском, правами доступа, ротацией логов и бесшовным обновлением — это уже наша специализация. Статистика: 90% обращений за помощью связаны с тем, что Битрикс записывает файлы от одного пользователя, а nginx читает их от другого; OPcache не видит изменений в коде; агенты не запускаются из-за отсутствия cron внутри контейнера. Разберём решения на практических примерах, которые экономят до 40% времени на поддержку.

Проблемы, которые решает правильная настройка Docker для Битрикс

Без грамотной конфигурации контейнеры Битрикс в production превращаются в источник головной боли. Вот с чем мы сталкиваемся чаще всего:

• Права доступа: файлы создаются от разных пользователей, и сайт падает с ошибкой 403 или 500. Наш кейс: клиент потерял 2 дня на поиск причины, пока мы не выставили UID через build-аргумент. UID-маппинг в 10 раз надёжнее ручного chmod после каждого деплоя.
• Простой при обновлении: без стратегии rolling update каждый релиз означает минуты недоступности. Для интернет-магазина с оборотом 1 млн ₽/день это убыток до 50 000 ₽ за 10 минут простоя.
• Переполнение диска: логи контейнеров без ротации за неделю вырастают до 5 ГБ. При цене SSD-диска это не столько финансово, сколько риски сбоя из-за нехватки места.

настроить права доступа в Docker для Битрикс

Классическая проблема: PHP-FPM внутри контейнера работает от пользователя www-data (UID 33), а файлы на томе созданы root или другим пользователем хоста. Битрикс не может записать кэш или сохранить загруженный файл.

Мы решаем это явным указанием UID в Dockerfile:

FROM php:8.1-fpm-alpine

ARG HOST_UID=1000
RUN addgroup -g $HOST_UID bitrix && adduser -u $HOST_UID -G bitrix -D bitrix

RUN sed -i 's/user = www-data/user = bitrix/g' /usr/local/etc/php-fpm.d/www.conf \
    && sed -i 's/group = www-data/group = bitrix/g' /usr/local/etc/php-fpm.d/www.conf

В docker-compose.yml передаём аргумент:

php-fpm:
  build:
    context: ./docker/php
    args:
      HOST_UID: ${HOST_UID:-1000}

«Официальная документация 1С-Битрикс рекомендует использовать UID-маппинг для Docker-контейнеров»

Сравните: при стандартном www-data вы получаете 403 на каждом чихе, а с UID-маппингом — полная совместимость с правами хоста. Для безопасности мы также блокируем доступ к служебным директориям Битрикс через nginx.

Настройка nginx для production

server {
    listen 80;
    server_name _;
    root /var/www/html;
    index index.php;
    charset utf-8;
    client_max_body_size 256m;

    location ~* /\.ht { deny all; }
    location ~* /bitrix/modules { deny all; }
    location ~* /bitrix/php_interface { deny all; }
    location ~* /bitrix/tools { deny all; }

    location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_pass php-fpm:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_read_timeout 300;
        fastcgi_send_timeout 300;
    }

    location = /bitrix/urlrewrite.php {
        fastcgi_pass php-fpm:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$$fastcgi_script_name;
        include fastcgi_params;
    }
}

Healthcheck и политика перезапуска

Для проверки состояния контейнера добавляем healthcheck:

healthcheck:
  test: ["CMD-SHELL", "php-fpm -t && kill -0 1"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 40s

Этот вариант проверяет валидность конфигурации и факт работы процесса. Как указано в Docker, healthcheck — обязательный элемент production-стенда.

Выбор политики перезапуска:

Сравнение типовых проблем и решений

важна ротация логов?

Без ротации логи могут занять десятки гигабайт за неделю. Настраиваем в docker-compose.yml:

services:
  nginx:
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

  php-fpm:
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

Или глобально через /etc/docker/daemon.json описанным выше способом. Экономия дискового пространства — до 80%.

обновить контейнеры Битрикс без простоя?

Используем стратегию обновления только php-fpm, не трогая nginx:

1. docker-compose pull php-fpm
2. docker-compose up -d --no-deps --build php-fpm

Этот способ занимает секунды — nginx продолжает принимать запросы и перенаправлять их на старый контейнер, пока новый не поднимается. Для крупных проектов с репликами обновляем их по одной. Продвинутая конфигурация позволяет достичь 100% uptime даже во время обновлений.

входит в настройку под ключ

• Конфигурация nginx, PHP-FPM, MySQL с учётом специфики платформы.
• Решение проблемы прав доступа через UID-маппинг.
• Healthcheck и политики перезапуска для всех сервисов.
• Ротация логов и резервное копирование (база + файлы).
• Документация по развёртыванию и поддержке.
• 30 дней бесплатной поддержки после запуска.

Резервное копирование

Для надёжности используем скрипт, который дампит БД и архивирует файлы. Скрипт запускается через cron на хосте и хранит бэкапы за последние 7 дней. Оценим ваш проект за один рабочий день — без предоплаты. Свяжитесь с нами, чтобы обсудить детали. Закажите настройку — и забудьте о проблемах с контейнерами.