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

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

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

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    943
  • 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
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1074

Почему 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 BitrixVM
Воспроизводимость среды Полная (через compose и Dockerfile) Только одна среда
Масштабирование сервисов По отдельности Только всё вместе
CI/CD интеграция Естественная Требует доработок
Изоляция зависимостей Полная (контейнеры) Частичная (виртуализация)
Скорость развёртывания для разработки 2–3 дня 1–2 часа
Скорость развёртывания для production 7–14 дней 1–2 часа
Гибкость конфигурации Высокая Низкая

Docker-окружение запускается на 30% быстрее в CI/CD по сравнению с BitrixVM. Это особенно заметно при частых деплоях.

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

Редакция Битрикс PHP версия Статус
Старт / Малый бизнес 8.1 Поддерживается
Бизнес / Энтерпрайз 8.2 Рекомендуется
Устаревшие проекты 7.4 Только миграция

Процесс работы

  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 остались локальные настройки подключения к БД. Классическая ситуация: деплой «по старинке» превращается в лотерею. Другой пример: обновление модуля через админку ломает кастомный шаблон компонента — правки не зафиксированы в системе контроля версий, и восстановление занимает часы.

Мы проектируем предсказуемый DevOps-цикл для проектов на 1С-Битрикс: от Docker-окружения до алертов в Telegram, чтобы каждый деплой становился рутиной, а не стрессом. Ниже — как именно мы решаем реальные проблемы Битрикс-команд.

Проблемы, которые решаем

Битрикс исторически жил в парадигме «правим файлы по FTP на боевом сервере». Сегодня так работают десятки команд. Результат — двое разработчиков одновременно правят init.php, затирая изменения друг друга. Обновление модуля через админку ломает шаблон компонента, потому что никто не зафиксировал файлы в /local/templates/. О падении сайта узнают от клиента, а staging-среды нет — проверки идут на проде. Стоимость такого подхода — часы восстановления и потеря бизнес-логики. Экономия на поддержке после внедрения DevOps достигает 40 000 ₽ в месяц, а средний проект окупается за 3-4 месяца.

Почему DevOps критичен для Битрикс-проектов?

Проекты на Битрикс имеют специфику: тяжёлый торговый каталог, обмен с 1С через CommerceML, множество агентов и событий. Без CI/CD и мониторинга каждое изменение становится риском. Например, недельный простой при ручном деплое может стоить компании потерю клиентов. Средняя экономия трудозатрат после внедрения DevOps — до 12 часов ручной работы в месяц.

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

Git — переводим проект с FTP на Git (GitLab, GitHub, Bitbucket). Структура веток: main (production), 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. Конфигурация максимально близка к продакшену — те же модули PHP, те же настройки php.ini.

Локальная разработка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 задаются через переменные окружения, а не через volume с продакшен-конфигами.

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

Как правильно настроить 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 за минуту при падении сайта. Время отклика ключевых URL: /, /catalog/, /personal/order/make/. 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-среда

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

Ansible: инфраструктура как код

Новый сервер? ansible-playbook site.yml -l production — через 15 минут всё настроено идентично текущему. Плейбуки покрывают nginx, php-fpm, MySQL, Redis, certbot, firewall. Роли переиспользуемые: common (users, SSH, NTP), web (nginx + php-fpm), db (MySQL + backup), monitoring (Prometheus + exporters). Идемпотентность — повторный запуск ничего не ломает. Inventory: [production], [staging], [development] для групп серверов. Подробнее — Ansible Documentation.

Резервное копирование

Компонент Частота Хранение Метод
БД MySQL Каждые 6 часов 30 дней mysqldump --single-transaction + gzip
Файлы (upload/) Ежедневно 14 дней rsync инкрементальный
Полный бекап Еженедельно 60 дней tar + gpg шифрование
Конфиги серверов При изменении В Git Ansible playbooks

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

Что входит в работу

Наш 5-летний опыт (более 50 проектов на Битрикс) позволяет предоставить полный набор результатов для услуги DevOps для 1С-Битрикс:

  • Документация 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. Обучение команды — два занятия по работе с инструментами.

Типичные сроки внедрения

Задача Сроки
Docker-окружение для локальной разработки 2-3 дня
CI/CD пайплайн (GitLab CI / GitHub Actions) 1-2 недели
Staging-среда 3-5 дней
Мониторинг + алертинг (Prometheus + Grafana) 1-2 недели
Централизованное логирование (ELK/Loki) 1-2 недели
Ansible-автоматизация серверов 2-3 недели
Комплексное DevOps-внедрение 4-8 недель

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