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

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом "Administrator Linux. Professional" в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

Для начала, что такое 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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом "Administrator Linux. Professional" в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:
  • Знание архитектуры Linux.
  • Освоение современных методов и инструментов анализа и обработки данных.
  • Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
  • Владение основными рабочими инструментами системного администратора.
  • Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
  • Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .

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

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

Автор Zerox

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

4 комментария

  1. Аватар
    Аноним

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

    • Zerox

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

      • Аватар

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

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

        • Zerox

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

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

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.