Битрикс: от модулей к сервисам

Приветствую всех не равнодушных!

Хочу поделиться с вами историей о том, как мы рефакторили код проекта на Битрикс24 под DDD архитектуру. Возможно кому-то это будет полезно, а возможно, и сам подчерпну что-то новое для себя.

Итак, имеется портал написанный давно на Битрикс24 коробочной версии, задача — упростить поддержку, избавиться от кучи портянок в кастомных модулях, привести код к единообразию, чтобы разработчики делали его в едином стиле, добавить возможность быстрого переключения между внешними сервисами одного типа.
Задача два — позволить разработчикам битрикса, развиваться, не оставаясь заложниками одной CRM

Шаг 1: контейнеризация

За основу была взята сборка

Клонируем ее в собственный репозиторий:

mkdir my_project  cd my_project  git clone https://github.com/bitrixdock/bitrixdock ./  git remote set-url origin https://my_gitlab/repo_docker git push

Далее встает вопрос о том, что продуктовая ветка должна быть обезопасена, как минимум — нестандартными портами и на ней не должно быть adminer

Для того, чтобы конфигурировать можно было не через docker-compose.yml и всем его раскидывать, удобнее будет сделать ветки master, stage, developer, на которых уже можно делать конфигурацию для конкретной среды и она будет обновляться путем git pull

Далее будет приводиться пример, будто все в одной ветке на одной сборке, вы же у себя сами решайте, что вам на каких окружениях требуется:

Добавляем сервисы для сбора логов и хранения сессий.

Дабы обойти санкции на поставку ELK, воспользуемся готовой сборкой не от официалов:

    rabbitmq:         image: rabbitmq:3-management         # container_name: rabbitmq         hostname: rabbitmq         volumes_from:             - source         ports:             - '${INTERFACE}:${RABBIT_PORT1:-15672}:15672'             - '${INTERFACE}:${RABBIT_PORT2:-5672}:5672'         restart: always         environment:             RABBITMQ_DEFAULT_USER: ${RABBIT_USER}             RABBITMQ_DEFAULT_PASS: ${RABBIT_PASS}             RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS: -rabbit log_levels [{connection,error},{default,error}] disk_free_limit 2147483648             TZ: Europe/Moscow         stdin_open: true         tty: true         networks:             - bitrixdock      elk:         image: sebp/elk         environment:             node.name: elk             ES_JAVA_OPTS: -Xms512m -Xmx512m             # Bootstrap password.             # Used to initialize the keystore during the initial startup of             # Elasticsearch. Ignored on subsequent runs.             ELASTIC_PASSWORD: ${ELASTIC_PASSWORD:-}             # Use single node discovery in order to disable production mode and avoid bootstrap checks.             # see: https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html             discovery.type: single-node             LS_JAVA_OPTS: -Xms256m -Xmx256m             LOGSTASH_INTERNAL_PASSWORD: ${LOGSTASH_INTERNAL_PASSWORD:-}         #        mem_limit: 4g         volumes:             - ./elk/logstash/20-input.conf:/etc/logstash/conf.d/20-input.conf             - ./elk/logstash/30-output.conf:/etc/logstash/conf.d/30-output.conf         ports:             - "${KIBANA_PORT:-5601}:5601"             - "${ELASTIC_PORT:-9200}:9200"             - "${LOGSTASH_PORT:-5044}:5044"         networks:             - bitrixdock

Как видите container_name: rabbitmq закомментировано, для того, чтобы docker-compose сам назначал имя ${COMPOSE_PROJECT_NAME}_serviceName, таким образом, если у вас будет несколько проектов с таким docker-compose.yml, то сервисы не будут стучаться в чужие сборки по имени контейнера.

Шаг 2: настройка

Для настройки логирования в ЕЛК, выберем схему php monolog -> rabbitMQ -> logStash -> elasticSearch -> kibana

Про то, как настроить монолог и отправить сообщения в очередь, мы поговорим в разделе настройки проекта, а сейчас покажу — как забирать эти сообщения из очереди:
./elk/logstash/20-input.conf

input {     rabbitmq {         host => "rabbitmq" # имя контейнера         port => 5672          queue => "elk" # имя очереди         durable => true         passive => true         exchange => "logs" # имя обмена         user => "rabbit-user"         password => "rabbit-password"     } } 

Форматируем сообщения:

./elk/logstash/30-output.conf

output {   elasticsearch {     hosts => ["localhost"]     manage_template => false     index => "%{[@type]}-%{[@source]}-%{+YYYY.MM.dd}"   } }

Logstash забирает сообщения из очереди logs и передает их в elasticsearch, через kibana мы можем их просматривать и создавать дашборды. Все будет доступно по localhost:SERVICE_PORT из списка

- "${KIBANA_PORT:-5601}:5601" - "${ELASTIC_PORT:-9200}:9200" - "${LOGSTASH_PORT:-5044}:5044"

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

      source:         image: alpine:latest         # container_name: source         volumes:             - ./logs/${WEB_SERVER_TYPE}:/var/log/${WEB_SERVER_TYPE}             - ./logs/php:/var/log/php             - ./logs/db:/var/log/mysql             - ./logs/memcached:/var/log/memcached             - db:/var/lib/mysql             - cache:/var/lib/memcached             - ${SITE_PATH}:/var/www/bitrix             - /etc/localtime:/etc/localtime/:ro             - ./rabbitmq/data:/var/lib/rabbitmq          networks:             - bitrixdock

Запускаем сборку и любуемся:

Не забываем добавить исклчения для нашего проекта в .gitignore, чтобы проект внутри контейнера мог жить на отдельной gitlab площадке от контейнера и их коммиты не пересекались

.idea .vscode .fleet logs .env www/* # Проект rabbitmq/data

Шаг 3: решение проблем

Проблема 1: в контейнеры, директория с проектом ./www пробрасывается по пути: /var/www/bitrix/ и все наши внешние изменения, сразу изменяются и в контейнерах. Но возникает следующее: Пользователь, изменяя файлы снаружи, внутри перезаписывает права на файл с id внешнего пользователя. Таким образом, если мы зайдем внутрь контейнера docker-exec -u www-data php bash, перейдем в директорию проекта cd /var/www/bitrix/ и посмотрим права на файлы, то увидим, что все файлы, которые менялись изнутри, с владельцем www-data:www-data а измененный снаружи — id_user:id_group и это приводит к тому, что на linux системах контейнеры теряют доступ на чтение этих файлов (чего не происходит на windows и macOS), но мы же приверженцы прав на файлы 640 и не хотим все делать 777?

Решение: добавляем в наш .env переменные с id пользователя, который работает снаружи

UDP: На примере выше, настройки mysql оставлены по-умолчанию, тк считаю плохой практикой держать БД с проектом на одной машине, я этот сервис отключаю, но оставил как пример или для локальной разработки.

Далее меняем для сервисов php и web_server запись в docker-compose.yml на подобную, для пробрасывания этих переменных окружения.

      php:         build:             context: ./php/${PHP_VERSION}             args:                 UID: ${UID:-1000}                 GID: ${GID:-1000}         # container_name: php

Меняем пользователей, под которым работают сервисы в их Dockerfile RUN usermod -u ${UID} www-data

FROM phpdockerio/php:8.2-fpm  LABEL org.opencontainers.image.source="https://github.com/bitrixdock/bitrixdock"  RUN apt-get update \     && apt-get -y --no-install-recommends install  \     libc-client-dev libkrb5-dev libssl-dev \     php8.2-gd \     php8.2-imagick \     php8.2-intl \     php8.2-interbase \     php8.2-mbstring \     php8.2-mcrypt \     php8.2-memcache \     php8.2-memcached \     php8.2-mysql \     php8.2-opcache \     php8.2-soap \     php8.2-zip \     php8.2-imap \     php8.2-curl \     && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*  # Получение переменных из docker-compose.yml ARG UID ARG GID  COPY ./php.ini /etc/php/8.2/fpm/conf.d/90-php.ini COPY ./php.ini /etc/php/8.2/cli/conf.d/90-php.ini  # Настройка imagick COPY ./imagick/policy.xml /etc/ImageMagick-6/policy.xml  # Смена пользователя www-data на пользователя извне RUN usermod -u ${UID} www-data RUN echo 'User: ' ${UID};  WORKDIR "/var/www/bitrix"  EXPOSE 9000

Вуаля! В контейнерах изменения пишутся под тем же пользователем, что и снаружи, таким образом 640 нас начинает устраивать.

Проблема 2: при работе с проектом, желательно вынести кеширование и сессии в memcache, чтобы не нагружать файловую систему, внесем соответствующие настройки.

<?php return [     /*****      * Cache в Memcache.      *****/     'cache' => [         'value' => [             'type' => 'memcache',             'memcache' => [                 'host' => 'memcached',                 'port' => '11211',             ],             'sid' => $_SERVER["DOCUMENT_ROOT"] . "#01"         ],     ], ]

<?php const BX_SECURITY_SESSION_MEMCACHE_HOST = 'memcached'; const BX_SECURITY_SESSION_MEMCACHE_PORT = 11211;

Контейнер memcache работает, и работает очень быстро, по сравнению с дисковым кешем, что видно по запросам

Однако! Видим, что на macOS и Linux все прекрасно, но на windows машинах появляются тормоза, вплоть до 6 секунд при загрузке. Это крайне не приятно и сильно мешает разработке.

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

Решение 1: Закупить SSD и перенести проект на него.

Решение 2: Организовать облако и сделать площадки для разработчиков через kubernetes

Решение 3:

Комментатор: У нас бюджет только на одну виртуалку, как нам быть?

Я: Если мы запустим 2 контейнера на 1 виртуалке, то они поругаются за права владения портами 80 и 443

Комментатор: А как же нам быть?

Я: Выход есть, но, возможно не идеальный. Делаю.

1. Подготавливаю виртуалку для работы множества пользователей

   1. создаем каждому сотруднику учетную запись на сервере

   2. заводим пользователя для управления контейнерами, к примеру web-master:web-master и его добавляем в группу docker.

   3. всех пользователей добавляем в одну общую группу, к этому web-master sudo usermod -g web-master anatoliy-pro, причем важно, чтобы первичная группа у всех пользователей была именно web-master, чтобы права на файлы не переписывались.

   4. разворачиваем директории с docker-compose проектами и делаем права на все файлы у докер-сборки 640 и владелец web-master:web-master, таким образом изменения для докера будут делаться под этим пользователем

   5. в контейнерах директории www. делаем с правами пользователя, под которым будет идти работа anatoliy-pro:web-master, на всякий случай после клонирования проекта в папку web, отключаем слежение за правами в git, чтобы они не улетели на прод cd ./www && git config core.fileMode false

   6. Редактируем наш docker-compose.yml на ветке developer, чтобы каждой площадке дать свои собственные порты

#Порты для площадки PORT_80=your_port PORT_443=your_port

          ports:             - '${INTERFACE}:${PORT_80:-80}:80'             - '${INTERFACE}:${PORT_443:-443}:443'

Таким образом, проблема будет решена и по адресу http://server:your_port будет открывать конкретная площадка и никто не будет драться за одинаковые порты.

Часть 4: заключение

Знаю, что тема статьи Битрикс, а мы до него даже не дошли.

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

На эти настройки будет завязана вся работа, которую я опишу во второй части, если будет интерес к теме.