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

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Налаштування Docker-контейнерів для 1С-Бітрікс
Проста
~1 робочий день
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • 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
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Налаштування 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