Настройка 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-стенда.
Выбор политики перезапуска:
| Политика | Поведение | Рекомендация |
|---|---|---|
restart: always |
Перезапускает контейнер всегда — после сбоя, после перезагрузки Docker, даже после docker stop. |
Для MySQL: чтобы БД поднималась при любом старте демона. |
restart: unless-stopped |
Перезапускает после сбоя и рестарта Docker, но не после docker stop. |
Для nginx и php-fpm: даёт контроль — если остановили вручную, значит, была причина. |
Сравнение типовых проблем и решений
| Проблема | Решение | Эффективность |
|---|---|---|
| Права доступа | UID-маппинг в Dockerfile | 100% устранение 403 ошибок |
| Переполнение диска | Ротация логов (max-size, max-file) | Экономия до 80% дискового пространства |
| Простой при обновлении | Rolling update через --no-deps | Обновление без потери запросов, время простоя 0 секунд |
важна ротация логов?
Без ротации логи могут занять десятки гигабайт за неделю. Настраиваем в 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:
-
docker-compose pull php-fpm -
docker-compose up -d --no-deps --build php-fpm
Этот способ занимает секунды — nginx продолжает принимать запросы и перенаправлять их на старый контейнер, пока новый не поднимается. Для крупных проектов с репликами обновляем их по одной. Продвинутая конфигурация позволяет достичь 100% uptime даже во время обновлений.
входит в настройку под ключ
- Конфигурация nginx, PHP-FPM, MySQL с учётом специфики платформы.
- Решение проблемы прав доступа через UID-маппинг.
- Healthcheck и политики перезапуска для всех сервисов.
- Ротация логов и резервное копирование (база + файлы).
- Документация по развёртыванию и поддержке.
- 30 дней бесплатной поддержки после запуска.
Резервное копирование
Для надёжности используем скрипт, который дампит БД и архивирует файлы. Скрипт запускается через cron на хосте и хранит бэкапы за последние 7 дней. Оценим ваш проект за один рабочий день — без предоплаты. Свяжитесь с нами, чтобы обсудить детали. Закажите настройку — и забудьте о проблемах с контейнерами.