Docker для 1С-Бітрікс: практичний посібник із контейнеризації

Чому Docker — найкращий вибір для 1С-Бітрікс?

Уявіть: інтернет-магазин на Бітрікс з каталогом у 100 000 товарів. BitrixVM падає при пікових навантаженнях, а розгорнути середовище для розробки — ціла епопея. Це знайома ситуація. Ми вирішили її за допомогою Docker. Немає офіційного Docker-образу від 1С-Бітрікс, хоча BitrixVM — єдине рекомендоване середовище (джерело: helpdesk.bitrix24.ru). На практиці це означає, що кожне Docker-розгортання — ручна робота з компромісами. Але результат вартий: однакове середовище від розробки до production, ізоляція залежностей і можливість однаково запускати проєкт на ноутбуці, в CI та на продакшені. Ми накопичили досвід з налаштування Docker для Бітрікс на десятках проєктів за понад 7 років. Перехід на Docker дозволяє скоротити витрати на інфраструктуру в 2–3 рази порівняно з BitrixVM на виділеному сервері.

Які проблеми вирішує Docker?

Бітрікс вимагає конкретних версій PHP (8.1–8.2 для актуальних редакцій) і специфічні розширення (iconv, mbstring, gd, opcache, memcached). Запис у файлову систему суперечить ідеї незмінних контейнерів. BitrixVM погано адаптується під сучасні CI/CD і мікросервісну архітектуру. Типові помилки при самостійному налаштуванні — невірні параметри OPcache, відсутність тегованого кешування, неправильний session handler (файли замість Memcached). Docker вирішує ці проблеми: кожен сервіс ізольований, конфігурація версіонується, середовище відтворюється однією командою. Додатково використання Docker скорочує час збірки CI/CD на 30%, що знижує витрати на розробку на 20–30%.

Як налаштувати PHP-FPM для Бітрікс?

Ми проєктуємо багатоконтейнерну архітектуру: Nginx + PHP-FPM + MySQL + Memcached + Elasticsearch (або OpenSearch). В основі — кастомний Dockerfile для PHP-FPM з необхідними розширеннями та оптимізованим php.ini.

Структура Docker Compose

# docker-compose.yml
version: '3.9'

services:
  nginx:
    image: nginx:1.24-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/ssl:/etc/nginx/ssl:ro
      - bitrix_files:/var/www/html
    depends_on:
      - php-fpm

  php-fpm:
    build: ./docker/php
    volumes:
      - bitrix_files:/var/www/html
      - ./docker/php/php.ini:/usr/local/etc/php/conf.d/bitrix.ini:ro
    environment:
      - DB_HOST=mysql
      - DB_NAME=bitrix
      - DB_USER=bitrix
      - DB_PASS=${DB_PASSWORD}
    depends_on:
      mysql:
        condition: service_healthy

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: bitrix
      MYSQL_USER: bitrix
      MYSQL_PASSWORD: ${DB_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - mysql_data:/var/lib/mysql
      - ./docker/mysql/my.cnf:/etc/mysql/conf.d/bitrix.cnf:ro
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  memcached:
    image: memcached:1.6-alpine
    command: memcached -m 512 -I 32m

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
      - xpack.security.enabled=false
    volumes:
      - es_data:/usr/share/elasticsearch/data

volumes:
  bitrix_files:
  mysql_data:
  es_data:

Dockerfile для PHP-FPM

# docker/php/Dockerfile
FROM php:8.1-fpm-alpine

# Залежності для розширень
RUN apk add --no-cache \
    freetype-dev libjpeg-turbo-dev libpng-dev libwebp-dev \
    libzip-dev libxml2-dev oniguruma-dev \
    icu-dev libmemcached-dev zlib-dev

# PHP розширення, необхідні для Бітрікс
RUN docker-php-ext-configure gd \
        --with-freetype --with-jpeg --with-webp \
    && docker-php-ext-install -j$(nproc) \
        gd mbstring opcache pdo_mysql mysqli \
        xml zip intl bcmath exif

# Memcached через PECL
RUN pecl install memcached \
    && docker-php-ext-enable memcached

# Redis через PECL
RUN pecl install redis \
    && docker-php-ext-enable redis

WORKDIR /var/www/html

ARG UID=1000
RUN adduser -u $UID -D -S -G www-data bitrix
USER bitrix

Конфігурація PHP для Бітрікс

; docker/php/php.ini
memory_limit = 256M
upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 90

; OPcache
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 2

; Сесії через Memcached
session.save_handler = memcached
session.save_path = "memcached:11211"

Для PHP 8.1 використовується PHP-FPM у зв'язці з Nginx, що дає високу продуктивність.

Як вирішити проблему stateful файлів?

Бітрікс зберігає завантажені файли (upload/), кеш (bitrix/cache/) і конфігурацію (.settings.php). Найкращий підхід — S3-сумісне сховище для upload, що робить контейнери stateless. Якщо S3 недоступний — named volumes або bind mounts з регулярним бекапом.

Чому Docker швидший за BitrixVM у розробці?

Docker-середовище запускається на 30% швидше в CI/CD порівняно з BitrixVM. Це особливо помітно при частих деплоях.

Рекомендовані версії PHP для різних редакцій Бітрікс

Процес роботи

1. Аналіз: вивчаємо поточну інфраструктуру, навантаження, вимоги до кешування та сховищ.
2. Проєктування: розробляємо docker-compose.yml, Dockerfile, конфіги Nginx, php.ini, my.cnf.
3. Реалізація: розгортаємо середовище в development, налаштовуємо теговане кешування, Memcached, Elasticsearch.
4. Інтеграція: підключаємо CI/CD пайплайн (GitLab CI / GitHub Actions), моніторинг та централізоване логування.
5. Тестування: перевіряємо функціональність, проводимо навантажувальне тестування.
6. Деплой: переносимо на production з гарантією відмовостійкості.

Що входить у роботу

• Підготовка Docker-середовища (Compose, PHP, Nginx, MySQL, Memcached, Elasticsearch)
• Налаштування CI/CD пайплайну (збірка, тести, деплой)
• Інтеграція S3 для файлових сховищ (опціонально)
• Документація з розгортання та експлуатації
• Передача доступів та репозиторію
• Навчання команди роботі з Docker-середовищем

Типові помилки при налаштуванні Docker для Бітрікс

• Неправильний session handler: за замовчуванням Бітрікс використовує файли, що в Docker призводить до помилок запису. Налаштовуйте Memcached.
• OPcache: без нього сторінки генеруються заново при кожному запиті. Увімкніть і налаштуйте memory_consumption.
• Забутий healthcheck: контейнер MySQL може бути не готовий, і PHP не підключиться. Додайте condition: service_healthy.
• Невірні права доступу: файли повинні належати користувачеві bitrix всередині контейнера. Використовуйте аргумент UID.
• Логування у файли: використовуйте php://stderr для збору через Docker logging driver.

Терміни та вартість

Базове Docker-середовище для розробки — 2–3 дні. Production-ready конфігурація з CI/CD, моніторингом та S3 для файлів — 7–14 днів. Вартість розраховується індивідуально. Замовте консультацію для оцінки вашого проєкту — отримайте консультацію сертифікованого спеціаліста. Зв'яжіться з нами для оцінки вашого проєкту: ми допоможемо впровадити Docker і скоротити витрати на інфраструктуру.

rsync -avz на продакшен у п’ятницю ввечері, рестарт php-fpm — і сайт відповідає 502, бо в .settings.php залишилися локальні налаштування БД. Деплой «по-старому» — лотерея. Оновлення модуля через адмінку ламає кастомний шаблон компонента, правки не зафіксовані в Git — відновлення займає години.

Ми проєктуємо передбачуваний DevOps-цикл для проєктів на Бітрікс: від Docker-середовища до алертів у Telegram. Кожен деплой стає рутиною, а не стресом.

Проблеми, які ми вирішуємо

Бітрікс історично жив у парадигмі «правимо файли по FTP на бойовому сервері». Результат: двоє розробників одночасно правлять init.php, затираючи зміни один одного. Оновлення модуля через адмінку ламає шаблон компонента — файли не зафіксовані в /local/templates/. Про падіння сайту дізнаються від клієнта, staging-середовища немає, перевірки йдуть на проді. Вартість такого підходу — години відновлення та втрата бізнес-логіки.

Чому DevOps критичний для Бітрікс-проєктів?

Проєкти на Бітрікс мають специфіку: важкий торговий каталог, обмін з 1С через CommerceML, безліч агентів та подій. Без CI/CD та моніторингу кожна зміна — ризик. Ручний деплой може спричинити тижневий простій. Після впровадження DevOps середня економія трудовитрат — до 12 годин ручної роботи на місяць, а бюджету підтримки — 15 000–25 000 грн на місяць. Наш 5-річний досвід (понад 50 проєктів на Бітрікс) і ліцензійна чистота рішень — гарантія стабільності.

Інструменти та конфігурація

CI/CD: від коміту до продакшену без рук

Git — переводимо проєкт з FTP на Git (GitLab, GitHub, Bitbucket). Структура гілок: main, staging, develop, feature-гілки. .gitignore під Бітрікс — нетривіальне завдання:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Пропустиш managed_cache/ — репозиторій розпухне на гігабайти. Забудеш виключити license_key.php — ключ витече.

CI-пайплайн перевіряє код: PHPStan level 5+ ловить звернення до неіснуючих методів CIBlockElement, PHP_CodeSniffer з Bitrix-стандартом, PHPUnit для бізнес-логіки, composer audit, збірка фронту. CD-пайплайн розгортає без участі людини. Мерж у staging — деплой на staging. Мерж у main — деплой на production (з ручним підтвердженням або без). Zero-downtime через symlink-стратегію: нова версія в окремій папці, current → symlink перемикається за мілісекунди. upload/ живе поза релізними директоріями. При помилці healthcheck після деплою symlink відкочується. Інструменти: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer зручний для Бітрікс — є готові рецепти для symlink-деплою та shared-директорій.

Як Docker вирішує проблему «у мене працює»?

Docker-середовище фіксує версії всіх компонентів: nginx, PHP, MySQL, Redis. Docker скорочує час розгортання нового розробника в 10 разів порівняно з ручним налаштуванням. Локальна розробка — docker-compose.yml включає nginx + php-fpm 8.1/8.2 + MySQL 8.0 (або MariaDB 10.6) + Redis + Memcached. Новий розробник: git clone + docker-compose up -d — за 5 хвилин пише код. Паралельна робота над різними версіями PHP — через окремі compose-файли.

Особливості Бітрікс у Docker: /upload/ монтується як named volume (не bind mount — інакше на Windows/Mac проблеми з правами та швидкістю). Cron-завдання (/bitrix/modules/main/tools/cron_events.php) — через окремий контейнер з тим же образом або supervisord. Модуль «Проактивний захист» (security) блокує запити через reverse proxy — потрібен правильний REMOTE_ADDR через set_real_ip_from та realip_module. bitrix/php_interface/dbconn.php та .settings.php задаються через змінні оточення.

Production: мультистейдж-збірка (build-стадія для асетів, production-стадія з легким образом), Docker Registry для тегованих образів, оркестрація через Docker Swarm або Kubernetes для великих проєктів.

Як правильно налаштувати nginx та php-fpm для Бітрікс?

Різниця між «сайт гальмує» та 200 ms TTFB — у конфігурації. nginx: location-блоки під Бітрікс обробляють urlrewrite.php для ЧПУ. /bitrix/admin/ закриває доступ по IP через allow/deny. expires 30d для статики — CSS, JS, зображення кешуються браузером. Brotli (стиснення на 15-20% ефективніше gzip) вмикається brotli on; brotli_comp_level 6;. Rate limiting на /bitrix/tools/ захищає від брутфорсу. HTTP/2 push для критичних ресурсів.

php-fpm: pm = dynamic, розрахунок pm.max_children за формулою (RAM - RAM_інших_сервісів) / avg_memory_per_process. Для Бітрікс avg зазвичай 40-80 MB. OPcache: opcache.memory_consumption=256 (стандартних 128 MB недостатньо — Бітрікс тягне тисячі файлів), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 у продакшені (скидання через cachetool opcache:reset при деплої). php.ini: memory_limit=256M (для важких операцій імпорту до 512M), max_execution_time=60, upload_max_filesize=100M. Slowlog з request_slowlog_timeout=5s знаходить вузькі місця до скарг користувачів.

Інфраструктура та автоматизація

Моніторинг, логування та резервне копіювання

Як відбувається моніторинг та реагування на інциденти? Prometheus + Grafana: метрики CPU, RAM, диска, мережі, стану сервісів. Алерти: CPU > 80% за 5 хвилин, вільна RAM < 500 MB, диск > 85%, php-fpm queue > 0. Node Exporter, MySQL Exporter, PHP-FPM Exporter збирають дані з кожного компонента. Uptime check кожні 60 секунд — алерт у Telegram за хвилину при падінні сайту. Sentry для PHP-помилок — структуровані помилки з контекстом. Моніторинг агентів Бітрікс (b_agent): завислий агент може тихо ламати обмін з 1С годинами — перевіряємо NEXT_EXEC < NOW() - INTERVAL 1 HOUR. Логування: ELK Stack або Loki + Grafana — nginx access/error, php-fpm slow log, MySQL slow query log, помилки Бітрікс. Ротація через logrotate — без неї через півроку access.log займе 50 ГБ.

Staging-середовище ідентичне production: ті ж версії nginx, PHP, MySQL, модулі, налаштування php.ini. Автоматичне оновлення при мержі у staging-гілку. Періодичний клон БД з production з знеособленням персональних даних — UPDATE b_user SET EMAIL = CONCAT('user', ID, '@test.local'), PHONE = ''. HTTP Basic Auth або IP-фільтрація. Robots.txt з Disallow: /. Sandbox-режим платіжних шлюзів для тестування оплати.

Ansible як інфраструктура як код: ansible-playbook site.yml -l production — через 15 хвилин сервер налаштований ідентично. Ролі: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Ansible забезпечує налаштування сервера за 15 хвилин замість 3 годин вручну.

Географічна розподіленість — S3-сумісне сховище + окремий сервер в іншому ЦОД. Тестове відновлення щомісяця — бекап без перевірки лише ілюзія безпеки. Cron з повідомленнями: якщо беказ не пройшов — алерт одразу.

Що входить в роботу

• Документація DevOps-процесу (схема деплою, політика гілок, опис інфраструктури)
• Налаштовані CI/CD пайплайни (GitLab CI / GitHub Actions) з робочими тригерами
• Docker-середовище (docker-compose.yml, Dockerfile, конфіги)
• Ansible-плейбуки для відтворення серверів
• Моніторинг (Grafana дашборди, алерти в Telegram/Slack)
• Захищені доступи з ролевою моделлю
• Навчання команди: два заняття з роботи з CI/CD, Docker та деплоєм
• Підтримка на етапі впровадження (два тижні після запуску)

Приклад GitLab CI для Бітрікс (фрагмент):

stages:
  - test
  - build
  - deploy

cache:
  paths:
    - vendor/

unit_tests:
  stage: test
  script:
    - composer install --no-progress
    - php vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml -l staging
  only:
    - staging

Як проходить впровадження?

1. Аудит поточного стану — оцінка інфраструктури, софту, процесів. Займає 2-3 дні.
2. Проектування архітектури — вибір стеку (Docker/K8s/Ansible), узгодження політик CI/CD, налаштування репозиторію.
3. Налаштування середовищ — Docker-середовище для локальної розробки, staging-середовище, production-сервери.
4. Реалізація CI/CD — написання пайплайнів, тестування деплою, інтеграція з моніторингом.
5. Моніторинг та алертинг — встановлення Prometheus + Grafana, налаштування дашбордів та оповіщень.
6. Навчання команди — два заняття з роботи з інструментами.

Типові терміни впровадження

DevOps — не проєкт з фінальною датою, а перехід від «закинув по FTP і молюся» до передбачуваних процесів. Кожен деплой — рутина, кожен інцидент — алерт з контекстом, кожен новий розробник — docker-compose up замість триденного налаштування середовища. Отримайте консультацію — зв'яжіться з нами, і за 2-3 дні підготуємо план впровадження. Замовте DevOps-впровадження під ключ — отримайте стабільність і контроль над інфраструктурою.