Налаштування Docker-контейнерів для 1С-Бітрікс
Налаштування Docker-контейнерів для 1С-Бітрікс
Запустити Бітрікс у Docker — нескладно. Налаштувати так, щоб контейнери працювали стабільно у production, коректно перезапускалися, не втрачали дані та не створювали проблем із правами доступу — вже потребує знання специфіки платформи. Типові проблеми: Бітрікс записує файли від root, але nginx читає їх від www-data; OPcache не бачить змін у файлах коду; агенти не запускаються, бо cron не налаштований всередині контейнера.
Конфігурація nginx-контейнера
# docker/nginx/conf.d/bitrix.conf
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;
}
# Чисті URL Бітрікс
location / {
try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args;
}
# PHP через FPM
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;
}
# Бітрікс urlrewrite
location = /bitrix/urlrewrite.php {
fastcgi_pass php-fpm:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Права доступу: вирішення проблеми UID
Класична проблема: PHP-FPM всередині контейнера працює від користувача www-data (UID 33), а файли у volume створені root або іншим користувачем хоста. Бітрікс не може записати кеш або зберегти завантажений файл.
У Dockerfile задаємо UID явно:
FROM php:8.1-fpm-alpine
# Створюємо користувача з UID хоста (передається через build arg)
ARG HOST_UID=1000
RUN addgroup -g $HOST_UID bitrix \
&& adduser -u $HOST_UID -G bitrix -D bitrix
# PHP-FPM запускаємо від 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 передаємо UID:
php-fpm:
build:
context: ./docker/php
args:
HOST_UID: ${HOST_UID:-1000}
.env:
HOST_UID=1000 # або результат `id -u` на хості
Healthcheck для PHP-FPM
php-fpm:
healthcheck:
test: ["CMD-SHELL", "SCRIPT_FILENAME=/var/www/html/index.php SCRIPT_NAME=/index.php REQUEST_METHOD=GET cgi-fcgi -bind -connect 127.0.0.1:9000 | grep -q '200 OK'"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
Простіший варіант:
healthcheck:
test: ["CMD-SHELL", "php-fpm -t && kill -0 1"]
interval: 30s
Політики перезапуску
services:
nginx:
restart: unless-stopped # перезапускаємо завжди, крім явної зупинки
php-fpm:
restart: unless-stopped
mysql:
restart: always # MySQL завжди, включно з перезавантаженням хоста
unless-stopped vs always: при always контейнер перезапуститься навіть якщо його явно зупинили командою docker stop. unless-stopped — не перезапускається після явної зупинки, але перезапускається після рестарту Docker daemon.
Ротація логів
За замовчуванням Docker накопичує логи безкінечно. На Бітрікс-сайті з активними користувачами це 1–5 ГБ за тиждень:
# 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:
{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
}
}
Оновлення контейнерів без downtime
# Оновлюємо лише php-fpm без зупинки nginx
docker-compose pull php-fpm
docker-compose up -d --no-deps --build php-fpm
# Перевіряємо, що новий контейнер здоровий
docker-compose ps php-fpm
# Якщо щось пішло не так — відкат
docker-compose up -d --no-deps php-fpm --scale php-fpm=1
При використанні кількох реплік PHP-FPM (через docker-compose scale) оновлюємо по одній, поки інші приймають трафік.
Резервне копіювання
#!/bin/bash
# backup.sh — запускаємо через cron на хості
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups/bitrix"
# Дамп БД через працюючий контейнер
docker-compose exec -T mysql mysqldump \
-u bitrix -p"${DB_PASSWORD}" \
--single-transaction bitrix | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"
# Архів upload/ та конфігів
docker run --rm \
-v bitrix_files:/data:ro \
-v "$BACKUP_DIR":/backup \
alpine tar czf "/backup/files_$DATE.tar.gz" /data/upload /data/bitrix/.settings.php
# Видаляємо бекапи старші 7 днів
find "$BACKUP_DIR" -mtime +7 -delete







