Деплой (deploy) обычного сайта через Gitlab на примере Bitrix

Хочу поделиться интересным решением, которое подсмотрел у одного заказчика. Я расскажу, как настроить автоматический деплой обычного php сайта на примере bitrix, с помощью gitlab и его webhooks. После коммита разработчика в рабочий репозиторий, код будет автоматически выкатываться на тестовый или рабочий сервер. Решение придумал не я. Делюсь им, потому что показалось полезным, плюс, чтобы самому не забыть и в будущем использовать.

Введение

Для начала, что такое deploy для тех, кто будет читать статью для общего развития, не имея потребности в настройки описанных решений. В общем случае deploy - задача развертывания приложения. Разработчик или команда разработчиков что-то программируют у себя на компьютерах или в тестовых окружениях. В какой-то момент им нужно все то, что они напрограммировали, собрать и где-то развернуть для тестирования или эксплуатации. Можно по старинке все копировать руками на нужные сервера. Но сейчас все стараются как-то ускорить и автоматизировать этот процесс.

Конкретно в моем примере я расскажу, как автоматизировать процесс деплоя сайта на bitrix. После коммита разработчика в git репозиторий, будет запускаться webhook через штатный функционал gitlab. Этот вебхук будет дергать url на сервере. Авторизация через token в заголовке запроса. Запрос по этому url будет инициировать запуск bash скрипта, который делает git pull на сервере.

В общем и целом ничего особенного тут нет. Мне понравилось целостность и законченность решения. Не нужно самому колхозить эти скрипты. Решение, конечно, костыльное, но с bitrix чаще всего все решения такие :) Тут плюс в том, что все настраивается очень просто и быстро. Сможет настроить обычный программист для себя, даже если он работает с проектом один.

Как я уже сказал, автор данного решения мне не известен. Ему кто-то увидит свое решение тут и расстроится, что его просто скопировали и не указали авторство, то сообщите мне, я укажу вас.

Особенность деплоя сайта на bitrix

Настройка деплоя bitrix сайта имеет свои нюансы. Дело в том, что битрикс не простой сайт. Через его панель управления можно не только изменять параметры, которые записываются в базу, но и создавать php файлы. Можно добавить или отредактировать шаблон, скопировать какие-то файлы через встроенный файловый менеджер. В связи с этим, нужно внимательно следить за тем, что было сделано через админку. Если просто деплоить исходники из репозитория, можно потерять эти изменения.

В предложенным мной решении этот случай вообще никак не обрабатывается. Считается, что через админку на сервере никто новые файлы не создает. Нужно как-то отдельно тестировать и склеивать такие изменения, если они будут. Так же bitrix состоит из огромного числа файлов, многие из которых не нужно грузить в репозиторий, чтобы не раздувать его объем. Нужно аккуратно прописывать все исключения в .gitignore.

А в остальном это обычный php сайт, так что предложенное мной решение деплоя может быть применено для любого другого сайта.

Загрузка bitrix в git репозиторий

Для начала создадим пустой репозиторий и загрузим туда свой сайт. Я не буду подробно останавливаться на работе с git и настройке gitlab. В данном примере подойдет и бесплатный аккаунт на публичном сервисе. Идем на наш веб сервер, куда будем выгружать сайт из репозитория. У меня на нем настроен bitrixenv. Я все буду делать под пользователем bitrix. Заходим в консоль под ним.

# su bitrix

Генерируем ключи, чтобы по ним ходить в репозиторий.

# ssh-keygen -t rsa
# cat ~/.ssh/id_rsa.pub

Копируем публичный ключ и добавляем его в gitlab.

Возвращаемся на сервер. Немного настроим git.

# git config --global user.name "Vladimir Zp"
# git config --global user.email "zeroxzed@gmail.com"

Идем в каталог с сайтом и инициируем репозиторий.

# cd /home/bitrix/ext_www/bitrix.zeroxzed.ru
# git init

Создаем файл .gitignore примерно следующего содержания.

*.swp
*.log
.idea/
*tar.gz
*.txt
.tpl
.well-known/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/activities/
/bitrix/managed_cache/
/bitrix/cache/
/bitrix/backup/
/bitrix/catalog_export/
/bitrix/tmp/
/bitrix/stack_cache/
/bitrix/updates/
/bitrix/blocks
/bitrix/catalog_export
/bitrix/html_pages
/bitrix/image_uploader
/bitrix/sounds/
/upload/
/import/
/gitpull/

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

# git remote add origin git@gl.serveradmin.ru:zeroxzed/bitrix.git
# git add .
# git push -u origin master

Наш сайт на битриксе запушился в репозиторий.

Настройка деплоя

Создаем в папке с bitrix директорию gitpull или как вам угодно. Название не принципиально. В нее кладем файл index.php примерно такого содержания.

<?php /* error_reporting(E_ALL); ini_set('display_errors',1);*/ $path = "/home/bitrix/git/www/"; $result = ""; $output = array(); $response = [ "error" => "no auth data",
    "success" => 0
];
$token = "87E73AEDFHKHGG12KJKLKLBBCFAE";
$headers = apache_request_headers();
if (!empty($headers) && isset($headers['X-Gitlab-Token']) && $headers['X-Gitlab-Token'] == $token) {
    $response = [
        "error" => "",
        "success" => 1
    ];
}

ob_end_clean();
ignore_user_abort();
ob_start();
header("Connection: close");
header('Content-type:application/json;charset=utf-8');
echo json_encode($response);
header("Content-Length: " . ob_get_length());
ob_end_flush();
flush();

if (!empty($headers) && isset($headers['X-Gitlab-Token']) && $headers['X-Gitlab-Token'] == $token) {
    $result = exec('/bin/sh '.$path.'git.pull.sh '.$_SERVER['SERVER_NAME'].'  2>&1', $output);
    file_put_contents($path.'logs/'.date('d.m.y').'.log', print_r(array(
        "time" => date("d.m.Y H:i:s"),
        "result" => $result,
        "output" => $output
    ), true), FILE_APPEND);
}
die();

Обращаю внимание на переменную token. Ее нужно будет заменить на свою и далее указать в настройках хука. Для этого идем в gitlab проект. Там в зависимости от версии системы, вебхуки будут либо в разделе Settings -> Webhooks, либо в Integrations.

Указываем там:

• url - http://bitrix.zeroxzed.ru/gitpull/index.php
• token - 87E73AEDFHKHGG12KJKLKLBBCFAE

Данный webhook будет дергать указанный url, а он запускать скрипт /home/bitrix/git/www/git.pull.sh. Создадим директорию и сам скрипт.

# mkdir -p /home/bitrix/git/www
# mcedit /home/bitrix/git/www/git.pull.sh

#!/bin/bash
HOST=$1
NOW=$(date +"%m-%d-%Y")
DIR=/home/bitrix/tmp/autopull/$HOST/
if [ ! -d "$DIR" ]; then
    mkdir -p $DIR
fi
echo " " >> $DIR/git_update_$NOW.log 2>&1
echo `date` $HOST >> $DIR/git_update_$NOW.log 2>&1
HOME=/home/bitrix/ext_www/bitrix.zeroxzed.ru/
export HOME
cd $HOME
git reset --hard origin/master >> $DIR/git_update_$NOW.log 2>&1
echo " " >> $DIR/git_update_$NOW.log 2>&1
git pull origin master >> $DIR/git_update_$NOW.log 2>&1
echo " " >> $DIR/git_update_$NOW.log 2>&1

Не забудьте изменить адрес директории с исходниками. Скрипт будет писать логи в /home/bitrix/tmp/autopull, так что создаем и его.

# mkdir -p /home/bitrix/tmp/autopull

В целом, не вижу смысла подробно комментировать скрипты. Они небольшие и в целом понятно, что происходит. PHP файл проверяет токен и если он верный, запускает sh скрипт. Этот скрипт делает git pull, записывает вывод в лог файл. Проверьте внимательно, чтобы все пути у вас были актуальны и команды git соответствовали реальным адресам и названиям репозитория.

После того, как все создали, можно пойти в gitlab, в настройку хука и выполнить тест.

В выпадающем списке выберите Push Events. Если все нормально, в ответ должны получить:

Hook executed successfully: HTTP 200

Теперь идите на сервер и посмотрите директорию /home/bitrix/tmp/autopull. Там должна появиться папка с адресом вашего сайта и в ней лог файл с выводом команды в скрипте.

Проверка деплоя (deploy) bitrix

Теперь проверим, как собственно, все будет работать. Для этого можете либо склонировать к себе репозиторий с исходниками, внести изменения, закомиттить их и запушить в репозиторий. Либо можно просто через веб интерфейс gitlab добавить новый файл и сделать commit.

Я просто добавлю файл test.deploy в корень репозитория.

Идем на сервер и ищем этот файл в корне сайта.

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

Проверьте на всякий случай ответ на запрпос php файла без нужного токена в заголовках. Url с gitpull/index.php должен возвращать ошибку.

{"error":"no auth data","success":0}

Когда будете себе настраивать, поменяйте на всякий случай путь gitpull на свой. Если у вас свой сервер gitlab, можно ограничить к нему доступ по ip сервера, откуда хук будет прилетать.

Заключение

Надеюсь, получилась полезная история на тему деплоя bitrix. С ним очень много нюансов и тонкостей. Программисты, которые первый раз его видят, не понимают, как с ним в принципе работать. Как организовать dev и stage окружение? У битрикса же лицензия на копию сайта. Она иногда слетает, если сайт скопировать и не выполнить некоторые действия с копией.

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

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

Рекомендую так же мою статью на тему оптимизации сервера под bitrix. Если ищите инструмент для обновления базы данных при деплое, обратите внимание на это решение - bitrix-reduce-migrations.

Помогла статья? Подписывайся на telegram канал автора