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

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

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

Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Подробная информация.

Введение

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

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

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

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

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

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

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

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

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

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

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

# su bitrix

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

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

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

Добавление ssh ключа в 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

Создание вебхука в gitlab

Обращаю внимание, что я запускаю webhook через http, так как это тестовый сервер и https я не настраивал на нем. В общем случае использовать http не надо.

Данный 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, в настройку хука и выполнить тест.

Тестирование webhook

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

Hook executed successfully: HTTP 200

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

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

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

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

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

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

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.

Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене.

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

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

9 комментариев

  1. Добрый день!

    Подскажите пожалуйста, почему используются сразу обе команды:
    git reset --hard origin/master
    и
    git pull origin master

    Я плоховато знаю git, и мне кажется что после первой команды наша ветка и так уже будет идентична origin/master. Для чего нужен еще и git pull?

    Спасибо.

  2. Кирилл

    Здравствуйте, а данный токен "$token = "87E73AEDFHKHGG12KJKLKLBBCFAE";" как Вы получили ?

    • Просто придумал :)

      • Кирилл

        ))))

        А где вообще можно получить токен для этой операции ?
        Можно использовать токен от учетной профильной записи gitlab ?
        И не подскажите пожалуйста почему может post не работать при выполнении теста - push events ?

        • Я хз почему post не работает. А токен в данном случае это просто аналог пароля. Его можно написать любой. В данном случае токен как таковой не используется в том смысле, как к нему привыкли все. Просто название похожее используется.

  3. Аноним

    Хорошо, когда есть разные варианты, но имхо, gitlab-runner в разы проще. Запилить CI yaml с тем же git pull в нужную директорию, ранер с токеном и вуаля.

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

      • ИМХО Gitlab + Ansible = более гибкий вариант.

        Спасибо за статьи!

        • Описанный вариант больше для программистов, чтобы сами могли настроить и понять, как работает. Чаще всего они ansible не знают.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar