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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Предлагаемые услуги
Показано 1 из 1 услугВсе 1626 услуг
Настройка Docker-контейнеров для 1С-Битрикс
Простая
~1 рабочий день
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1173
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Разработка веб-сайта для компании ФИКСПЕР
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    745
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    976

Настройка 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