Введение

Данный Docker-образ позволяет развернуть полноценное веб-окружение Битрикс, при этом предоставляя массу инструментов для комфортной разработки и отладки.

В комплекте идут:

• Node.js, глобально установленный gulp и yarn
• настроенный php-отладчик XDebug (если нужно)
• ssh-сервер
• разные полезные утилиты: htop, nano, mc, zip/unzip, screen и так далее

Образ подходит как для песочниц любой сложности, так и для продакшна.

Система на базе этого образа успешно проходит всю проверку системы через админку Битрикс.

Организация работы

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

Файлы проекта

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

Самым верным способом вносить правки в файлы проекта будет использование ssh от имени bitrix.

Сеть и DNS

Мы не будем пробрасывать какие-либо порты контейнера на localhost (как любят советовать многие образ-мейкеры), а будем обращаться к контейнеру напрямую через внутренний IP.

В этом нам поможет кастомная докер-сеть и наш /etc/hosts.

База данных

Хоть веб-окружение Битрикс и предоставляет для работы mysql-сервер, нам удобнее использовать свой и в отдельном контейнере.

Почему? Стоит перезапустить контейнер с Битрикс-окружением и базой внутри через docker run и вы потеряете данные в базе. Придется их заливать заново. Неприятно.

Дополнительно, мы вынесем директорию с всеми данными mysql в хост-систему. Это позволит сохранить базу между перезапусками mysql-контейнера.

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

В идеале, у вас выйдет так:

C = S + 1

где C - количество контейнеров, S - количество сайтов, единичка указывает на mysql-контейнер со всеми базами к проектам.

Использовать будем официальный образ mysql:

https://hub.docker.com/_/mysql/

Управление контейнерами

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

Постоянно выполнять команды docker run, docker stop, docker rm быстро надоест, поэтому мы вынесем этим команды в отдельные .sh-скрипты.

Отправка почты

Вся исходящая почта складывается в текстовые файлы, в папке /home/bitrix/mail.

Пример почтового файла: mail_2017-06-20_08-47-59. В нём будет лежать всё тело письма, включая заголовки.

Это настроено на уровне php.ini и параметра sendmail_path.

Подготовка образов

Для начала работы нам понадобится корректно установленный Docker.

Мануалов по установке в интернете масса, вот один из них:

https://www.digitalocean.com/community/tutorials/docker-ubuntu-16-04-ru

Использовать мы будем всего 2 образа - для Битрикс-окружения (мой) + официальный mysql

Подготовка Bitrix-образа

Берем мой образ из хаба:

    $ docker pull hybr1dmax/bitrix-env-dev

Внимание! Последняя версия образа собирает окружение с php7. Если вам нужна пятая версия, то берем образ с тегом php5

    $ docker pull hybr1dmax/bitrix-env-dev:php5

Подготовка MySQL-образа

Просто берем официальный образ mysql из хаба:

    $ docker pull mysql

Подготовка контейнеров

Скрипт запуска для Bitrix-контейнера

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

Наш контейнер назовём project.local, айпишник ему выставим 10.10.0.3

Создаем для него скрипт запуска:

    $ mkdir containers
    $ touch containers/project_run.sh

Вставляем в него следующее содержимое:

    #!/bin/sh
    
    docker stop project.local;
    docker rm project.local;
    
    docker run -id \
    -h project.local \
    --name project.local \
    --net=my-docker-network --ip=10.10.0.3 \
    -e XDEBUG=1 \
    -e NOMYSQL=1 \
    -e BITRIX_SSH_PASS="bitrix_passphrase" \
    -e ROOT_SSH_PASS="root_passphrase" \
    -v /etc/localtime:/etc/localtime:ro \
    -v ~/bitrix-env-dev/project.local:/home/bitrix/www \
    hybr1dmax/bitrix-env-dev;

Подробнее о параметрах

docker stop и docker rm уничтожают контейнер, если мы его уже запускали.

Сам docker run содержит в себе множество аргументов; давайте разберемся в них:

• -id - запускаем контейнер как фоновый процесс
• -h project.local, --name project.local - красиво обзываем контейнер + выставляем внутренний хостнейм
• --net=my-docker-network --ip=10.10.0.3 - подключаем контейнер к нашей кастомной докер-сети и выставляем контейнеру айпишник
• -e XDEBUG=1 активация отладчика XDebug
• -e NOMYSQL=1 - если определен этот параметр, то в контейнере не будет конфигурироваться и запускаться встроенный mysql
• -e BITRIX_SSH_PASS="bitrix_passphrase" - определяем пароль для пользователя bitrix
• -e ROOT_SSH_PASS="root_passphrase" - определяем пароль для пользователя root
• -v /etc/localtime:/etc/localtime:ro - пробрасываем из хост-системы текущую временную зону для того, чтобы время в контейнере текло также, как и на рабочей машине
• -v ~/bitrix-env-dev/project.local:/home/bitrix/www - монтируем из хост-системы папку с нашим проектом внутрь контейнера

Также доступны другие опции:

• -e MULTISITE_ID=2 параметр, для корректной работы многосайтовости (см. раздел Многосайтовость).
• -e CYRILLIC_MODE=1 если ваш проект в кодировке windows-1251, то эта опция позволит указать соответствующие mbstring.func_overload и mbstring.internal_encoding в конфигах php

Скрипт запуска для MySQL-контейнера

Создаем для него скрипт запуска:

    $ touch containers/mysql_run.sh

Вставляем в него следующее содержимое:

    #!/bin/sh
    
    docker stop mysql.local;
    docker rm mysql.local;
    
    docker run -id \
    -h mysql.local \
    --name mysql.local \
    --net=my-docker-network --ip=10.10.0.2 \
    -e MYSQL_ROOT_PASSWORD='db-root-password' \
    -e MYSQL_USER='bitrix' \
    -e MYSQL_PASSWORD='db-bitrix-password' \
    -v ~/bitrix-env-dev/mysqlDB:/var/lib/mysql \
    -v /etc/localtime:/etc/localtime:ro \
    mysql:5.5;

Путь ~/bitrix-env-dev/mysqlDB указывает на ту директорию, которую mysql наполнит своими данными и будет их использовать между перезапусками контейнера.

DNS

Чтобы с нашей рабочей машины обращаться к нашему контейнеру через доменное имя, а не через айпишник, добавим в свой /etc/hosts запись о хостнейме project.local:

    $ sudo su
    # echo "10.10.0.2 project.local" >> /etc/hosts

Создадим свою docker-сеть:

    $ docker network create my-docker-network --subnet=10.10.0.0/16

Доступы ssh

Если вы не укажете явно доступы к ssh, будут применены стандартные значения:

• root / 4EyahtMj
• bitrix / XW7ur3TB

Многосайтовость

Если вы хотите запустить проект с несколькими сайтами на одной лицензии, то укажите параметр для запуска MULTISITE_ID.

Допустимые значения - от 2 до бесконечности.

Примеры:

• для сайта №2 укажите MULTISITE_ID равный 2; в настройках сайта поменяйте путь с /home/bitrix/www на /home/bitrix/www2
• для сайта №5 укажите MULTISITE_ID равный 5; в настройках сайта поменяйте путь с /home/bitrix/www на /home/bitrix/www5

Дальше остается решить вопрос с монтированием. Для неосновного сайта необходимо подключить ядро базового сайта.

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

Сейчас будет наглядный пример параметров MULTISITE_ID и монтирования (связка сайтов №1 и №2).

Смотрите очень внимательно.

Параметры сайта №2:

    docker run -id \
    -e MULTISITE_ID=2 \
    -v /path/to/project2:/home/bitrix/www2 \
    -v /path/to/project1/bitrix:/home/bitrix/www2/bitrix \
    -v /path/to/project1:/home/bitrix/www \
    hybr1dmax/bitrix-env-dev;

Тогда для сайта №1 опции следующие:

    docker run -id \
    -v /path/to/project1:/home/bitrix/www \
    -v /path/to/project2:/home/bitrix/www2 \
    hybr1dmax/bitrix-env-dev;

Хитро, не так ли?

А теперь объясню как это работает под капотом.

В настройках сайта мы прописываем путь в параметре Путь к корневой папке веб-сервера для этого сайта.

Это наиважнейший параметр для корректной работы многосайтовости. В нем хранится абсолютный путь до файлового корня сайта. И еще он должен быть уникальным по всему проекту. То есть нельзя для двух сайтов указать /home/bitrix/www.

Мы будем на 1 сайт запускать 1 контейнер, поэтому мы дадим Битриксу то, что он хочет: разные пути до проекта.

Вы можете спросить "Почему бы не развернуть все сайты в одном контейнере?". Ответ: запуск каждого сайта в отдельной среде дает гибкость и простоту настройки.

Захотели поработать с одним единственным сайтом? Запустили только 1 контейнер. Плюс, можно разделить серверные настройки между сайтами (иногда полезно для экспериментов).

Запуск всего в одном контейнере потребует слишком много ручных действий и в целом свяжет вам руки.

Возьмём пример сайтов №1 и №2.

В контейнере сайта №1 мы будем хранить файлы по старинке, в /home/bitrix/www.

В контейнер сайта №2 мы примонтируем файлы проекта в /home/bitrix/www2.

С помощью find и sed мы заменим строку /home/bitrix/www на /home/bitrix/www2 во всех конфигах второго контейнера.

Данный процесс уже автоматизирован в скрипте run.sh, который стартует вместе с контейнером.

Вот и всё.

Запуск контейнеров

    $ bash containers/mysql_run.sh
    $ bash containers/project_run.sh

После этого можно подключаться к нашему проекту через доменное имя project.local, а к базе - через mysql.local

Дальше дело за малым:

• вливаем дамп базы в mysql.local
• меняем настройки базы в конфигах /bitrix/.settings.php и /bitrix/php_interface/dbconn.php проекта
• заходим через админку в Главный модуль и Список сайтов, меняем урлы и доменные имена на project.local; если этого не сделать, то вы можете столкнуться с парой проблем, одна из которых - постоянная разавторизация

Теперь можно работать.

Настройки XDebug предельно стандартные.

Пример для project.local:

• порт 9000
• хостнейм project.local
• папка на сервере /home/bitrix/www

Файлы проекта правим через ssh/sftp:

    $ ssh bitrix@project.local