Налаштування Docker для Бітрікс: від хаосу до стабільності

Контейнеризація Бітрікс: як налаштувати Docker правильно

Ми часто бачимо, як запуск Бітрікс у 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-стенду. Ми гарантуємо стабільну роботу завдяки 5-річному досвіду у 30+ проєктах.

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

Порівняння типових проблем і рішень

Чому важлива ротація логів?

Без ротації логи можуть зайняти десятки гігабайт за тиждень. Налаштовуємо в 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 продовжує приймати запити та перенаправляти їх на старий контейнер, поки новий не піднімається. Rolling update дозволяє оновлювати контейнери без втрати запитів — це у 100 разів швидше за повну зупинку сайту. Для великих проєктів з репліками оновлюємо їх по одній. Просунута конфігурація дозволяє досягти 100% uptime навіть під час оновлень.

Що входить у налаштування під ключ

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

Резервне копіювання

Для надійності використовуємо скрипт, який дампить БД та архівує файли. Скрипт запускається через cron на хості та зберігає бекапи за останні 7 днів. Оцінимо ваш проєкт за один робочий день — без передоплати. Зв'яжіться з нами, щоб обговорити деталі. Замовте налаштування — і забудьте про проблеми з контейнерами. Економія на підтримці може сягати 50 000 грн на місяць.