Битрикс в Docker: запуск окружения для локальной разработки

Введение

В данной статье будет рассказано с лирическим вступлением, зачем вообще запускать битрикс-окружение в docker на примере неназванной компании, которая занимается разработкой, внедрением и эксплуатацией проектов на битрикс.

При необходимости можно сразу переходить к описанию сборки и запуска.

Существует одна резонная причина, из-за которой возникла идея докеризации битры:

Заточенность bitrix-env под одну операционную систему – Centos

Сам по себе битрикс нацелен не только на корпоративный, но и на гос. сектор, где операционные системы встречаются аналогичные. Это может быть Астра Линукс, Ред ОС, Альт Линукс и т.п. Разумеется, что для таких систем можно воспользоваться официальными инструкциями и подготовить необходимое окружение под битрикс вручную.

Именно с этого момента и начинается “зоопарк” нескольких реализаций при наличии множества заказчиков с различными требованиями, а вместе с этим и дополнительные сложности:

• в одном из ЦОД в качестве ОС используется Red Hat, а если попросить установить иную ОС, то будет отказано в поддержке при решении проблем, т.к. Centos не поддерживается;
• где-то наоборот у заказчиков используются только debian-based дистрибутивы в их инфраструктуре;
• команды эксплуатации должны применять разные решения по подготовке инфраструктуры в зависимости от заказчика;
• для получения различных сертификаций Centos также не всегда и не всем подходит;
• поддержка Centos 7 закончится, а потому нужно думать, какую ОС использовать далее;
• даже если убедить заказчиков использовать Centos (или то, что битрикс будет дальше использовать вместо него), это будет неправильно – сохраняя в своём “зоопарке” исполнителя одно решение по использованию готового bitrix-env, у заказчиков “зоопарк” тем временем будет разрастаться, если они используют у себя иные дистрибутивы.

Вышеперечисленное может не показаться острыми проблемами на первый взгляд, но как минимум такие моменты будут доставлять неудобства при разработке, внедрении и дальнейшей эксплуатации. Здесь-то docker и решает все эти проблемы.

Помимо вышеописанного, с использованием докер будут также следующие преимущества при локальной разработке:

• переносимость и идентичность окружения;
• возможность запуска нескольких копий проекта с минимальными ресурсами.

Подготовка и запуск

Устройство образов

Минимально рабочий проект состоит из PHP-FPM v7.4.24, Nginx v1.21.1 на базе alpine и MySQL 5.7 на базе centos 8. Все образы, взятые за основу, загружены с dockerhub из официальных репозиториев. Каталог с кодом и ядром битрикса должен располагаться в корне проекта с именем “bitrix”.

Структура проекта представлена на скриншоте ниже:

Nginx

• Пользователь, от имени которого запущен процесс внутри контейнера, имеет UID и GUI 101:101;
• Корневая директория с кодом внутри контейнера – /var/www/bitrix
• Всё взаимодействие с контейнером производится через переменные окружения и envsubst;
• Конфигурационный файл-шаблон для основного сайта расположен в директории conf и упаковывается внутрь контейнера;
• В той же директории располагаются файлы-шаблоны dbconn и settings, которые также зашиваются в контейнер.

PHP-FPM

• Пользователь, от имени которого запущен процесс внутри контейнера, имеет UID и GUI 101:101;
• Корневая директория с кодом внутри контейнера – /var/www/bitrix;
• В конфигурационном файле conf/override.ini указываются серверные настройки PHP перед сборкой образа
• В официальный образ внесены изменения для установки дополнительных PHP-расширений, необходимых для минимальной работы битрикс: gd, mysqli, opcache, xml, zip, ldap.

MySQL

• Пользователь, от имени которого запущен процесс внутри контейнера, имеет UID и GUI 1001:1001;
• Каталог “data” с данными БД должен располагаться на хосте с правами пользователя внутри контейнера, т.е. 1001:1001;
• Конфигурационный файл для MySQL используется по умолчанию, за исключением опций, необходимых для корректной работы битрикс (взят из виртуальной машины битрикс) и размещен по пути config/z_bx_custom.cnf;
• Дамп БД должен быть расположен в каталоге docker-entrypoint-initdb.d – при первом запуске контейнера, все sql.gz файлы в алфавитном порядке будут импортированы в БД после её запуска;
• Файл-шаблон docker-entrypoint-initdb.d/init.sql.template содержит в себе SQL-скрипт, который выполняет замену в БД на основе домена сайта (устанавливает домен в главном модуле и активирует галку “Для разработки”);
• При первом запуске контейнера с MySQL, с помощью встроенных скриптов создаётся сама БД, а также пользователь и пароль для подключения к созданной БД. Все эти данные берутся из файла с переменными .env, который расположен в корне проекта (ls -la).

После сборки докер-образов и запуска контейнеров из этих образов присутствует одно неудобство. Из-за того, что пользователи внутри контейнеров с Nginx и PHP-FPM имеют UID 101, то весь каталог с кодом на хосте, монтируемый в контейнер, также должен иметь владельца с UID 101. Как результат – изменение файлов в процессе разработки будет неудобным, т.к. каждый раз придётся корректировать права.

Простым решением вышеописанной проблемы будет назначить права 0775 и владельца 101:$USER на каталог с кодом, т.е. для веб-сервера все права останутся на месте, и для разработчика будет удобно редактировать файлы. Но для вновь создаваемых файлов каждый раз придётся выполнять команды chown, что опять же неудобно.

А потому на каталог с кодом устанавливается дополнительный атрибут SGID, в результате чего все новые файлы, созданные в каталоге /bitrix, будут иметь сразу необходимые права и владельца – $USER:101, т.е. при создании файлов ничего дополнительно делать не нужно.

Все вышеописанные особенности и нюансы могут показаться избыточными, а потому для подготовки запуска в каталоге проекта имеется скрипт инициализации, который выполняет подготовительные действия для инициализации каталогов, прав и т.д., после чего можно просто билдить образы и запускать свой битрикс-проект в докер.

Сборка и запуск

• Каталог с битриксом (ядро + код) разместить в корне проекта по пути ./bitrix/;
• Дамп БД разместить в каталоге mysql/docker-entrypoint-initdb.d/ (можно пожатый через gzip);
• Сделать скрипт инициализации исполняемым и выполнить один раз со следующими аргументами:
  chmod +x init.sh
sudo ./init.sh db – подготовка каталогов MySQL и SQL-файла до первого запуска проекта
  sudo ./init.sh owner $USER – установка владельца
  sudo ./init.sh perm – установка прав (выполняется 3-5 минут)
  sudo ./init.sh clear-cache – очистка управляемого кеша
• Выполнить сборку всех образов командой docker-compose -f docker-compose.build.yaml build
• Задать переменную окружения в .env файле, указав домен, который резолвится в 127.0.0.1 на хост-машине. По умолчанию – default.com. При необходимости тут же можно изменить имя БД и логин\пароль, а также настройки для Nginx;
• В docker-compose.yaml для сервиса php-fpm в extra_hosts указать локальный IP-адрес в сети Docker, по умолчанию 172.17.0.1. Уточнить, какой адрес в сети докер можно командой docker network inspect bridge | grep -i gateway. Данная настройка необходима для прохождения проверки работ сокетов.
• Выполнить запуск docker-compose up -d
• В браузере открывать сайт по адресу http://default.com:80

Заключение

В статье был рассмотрен вариант запуска окружения битры в докере с описанием и решением возникающих нюансов. Проект доступен на гитхабе. Во всех типовых случаях профит от докера очевиден – нет привязке к инфраструктуре заказчика, а конфигурация окружения везде едина и хранится в системе контроля версий.

При необходимости использования Push&Pull модуля, можно воспользоваться решением отсюда, но нужно немного допиливать, чтобы оно работало.

Хочется акцентировать внимание ещё раз, что данный проект нацелен на ведение разработки локально и для выполнения задач по тестированию, т.е. это не production-ready решение. Тем не менее, его можно взять за основу и допилить для запуска на проде при необходимости с минимальными затратами.

Стоит также рассмотреть иные проекты по запуску битры в докер: раз и два. Один из проектов позиционируется как рабочее для продакшена, так что стоит обратить внимание.

P.S. Прежде чем использовать docker, стоит хорошо подумать – а так ли это необходимо?

P.P.S. Сами разработчики битрикса ответили весьма уклончиво, когда им задали вопрос про докеризацию и официальные рекомендации. Поэтому стоит иметь ввиду, что официальная поддержка может не помочь в решении каких-то проблем, если используется кастомное окружение, отличное от рекомендованного.