Что такое деплой git
Что такое деплой?
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
Как реализовать деплой с GitHub на продакшн сервер, использовав Webhook
У меня давно вошло в привычку создавать репозитории на GitHub. Это куда эффективнее, чем держать все на Google Drive или, того хуже, на жестком диске. Но здесь сразу появляется вопрос: как выполнить деплой на рабочий сервер?
Большинство поисковых запросов выводили меня на Jenkins и другие средства непрерывного развертывания. Но мне хотелось найти иное решение. Так я вышел на бесплатный сервис Webhook.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Техническая основа Webhook — свежий дроплет Digital Ocean с Ubuntu 16.04 в качестве рабочего сервера. Для снижения количества шагов, необходимых для реализации задуманного, все действия выполняются root-пользователем.
Начнем с GitHub
Если у вас есть репозиторий и вы хотите его использовать, можно пропустить этот шаг — просто воспользуйтесь SSH URI, и все. Если нет, то создайте его и тоже воспользуйтесь SSH URI.
Устанавливаем Go и Webhook (дроплет Digital Ocean).
Прежде чем начать, стоит выполнить быстрый апдейт и апгрейд со свежим установщиком Ubuntu 16.04.
Теперь для установки WebHook нужно установить язык программирования Go. На время написания этой статьи была актуальна версия 1.11.4, так что если у вас иная версия, нужно внести правки.
Пора загрузить последнюю версию Webhook.
В ходе загрузки нет прогресс-бара, так что нужно просто подождать. После завершения процесса выполните
Webhook установлен, но нужно создать структуру директорий и файлов, чтобы все работало как надо.
Файл hooks.json отвечает за конфигурацию и роутинг, а deploy.sh служит инструментом для выполнения команд, необходимых для обновлений с GitHub.
Первым делом стоит настроить hooks.json, открыв его в текстовом редакторе. Файл содержит конфигурацию для эндпоинтов, которые будут созданы после запуска Webhook, и представляет собой массив объектов, каждый из которых — уникальный эндпоинт.
Id — уникальное имя, которое будет использоваться для URL эндпоинта;
execute-command — скрипт, который будет выполняться при активации эндпоинта;
command-working-directory — директория, которая используется во время запуска execute-command;
trigger-rule — опция, которая будет использоваться в целях информационной безопасности, это секретная фраза для эндпоинтов.
Напомню, что все действия я выполняю от root, поэтому начальный адрес /root. Если логиниться под обычным пользователем, нужно прописать /home/username, где username, что логично, — имя этого пользователя. Не нужно использовать
/, путь должен быть абсолютным, в противном случае вы получите ошибку.
Вы могли заметить, что мы настроили рабочую папку, которая пока еще не существует. Перед тем как создать ее, нужно закончить с deploy.sh.
Скрипт всегда должен начинаться с “shebang”. Перед открытием файла стоит выполнить which bash. Ну а дальше выполняются следующие команды в скрипте:
Теперь и Go, и Webhook установлены, так что нужно настроить конфигурацию в hooks.json и написать скрипт, отвечающий за деплой. Он будет изменять каталог назначения, работая с главной веткой репозитория GitHub.
Наконец, пора привести Webhook в активный режим, заменив 000.000.000.000 рабочим IP-адресом Doplet.
В процессе выполнения можно заметить вывод URL с
Настройка Git (Digital Ocean Droplet)
Настройка сервера еще не закончена. Для ее завершения нужно открыть новое окно терминала и снова аутентифицироваться на сервере, в то время как в первом окне идет выполнение Webhook. В самом начале мы задавали URI репозитория, теперь его нужно использовать.
Для этого требуется перейти в рабочую директорию, заданную в hooks.json, и прописать следующее:
При этом нужно заменить URI на свой собственный вместо того, что указал я.
Финальным шагом будет генерация ключей SSH для того, чтобы с их помощью подключаться к GitHub. В окне терминала набираем ssh-keygen и подтверждаем, нажимая Enter, пока генерируются ключи. Затем нужно вывести публичные ключи, набрав cat
/.ssh/id_rsa.pub. Получится нечто вроде этого:
Ну а теперь все, что осталось, — настроить репозиторий GitHub и протестировать деплой.
Настройка ключа деплоя и Webhook (GitHub)
В браузере переходим в настройки для репозитория. Сначала нужно добавить Deployment Key.
Во время добавления ключа нужно задать его название и вставить в вывод ключа выше. GitHub дает возможность работать лишь с публичными ключами, так что в случае необходимости нужно задать несколько ключей. Как только все закончено, наступает очередь раздела Webhook.
Трем полям в этом разделе нужно уделить особенное внимание. Это payload URL, content type и secret. Payload URL — эндпоинт, который прослушивается Webhook, content type — формат данных, secret — кастомная строка из файла hooks.json. В нашем случае это “The Returners”.
После создания Webhook должна появиться соответствующая отметка в настройках, которая показывает, что сервер доступен. Если проверить терминал с работающим Webhook, можно видеть, что репозиторий уже в работе.
Для проверки рабочего процесса копируем репозиторий на локальную машину, если это еще не сделано, и вносим изменения в главную ветку. После этого они должны отобразиться и на сервере. Готово.
Разработчик, который уже выполнял все это несколько раз, тратит на настройку около 10 минут. Но это после того, как на метод проб и ошибок потрачены часы. Помните про эти четыре важных особенности настройки:
Деплой сайта с GitHub на хостинг через SSH
Привет! В этой статье я расскажу, как можно деплоить (или загрузить) сайт на ваш хостинг при пуше на GitHub. Все это будем делать через SSH
Что потребуется
Итак, чтобы разобраться со всей этой темой, вам понадобится:
Принцип
Вкратце скажу принцип работы всего этого действа: когда мы будем пушить данные в репозиторий, сработает GitHub Action, которому сказано подключиться к вашему хостингу по SSH и залить туда данные с помощью rsync.
Создание SSH-ключа
Открываем Git Bash, вводим следующую команду:
При использовании команды указывать парольную фразу не нужно.
Скриншот из консоли при вводе команды создания ключа
В этой папке вы найдете ключи id_rsa и id_rsa.pub, приватный и публичный ключи соответственно.
Добавление ключей
Итак, когда вы создали ключи, их нужно добавить на хостинг и в репозиторий. Как именно устроено это на разных хостингах, я знать не могу, но покажу на примере cPanel, как это выглядит.
Скриншот из cPanel, доступ по SSH
Добавляем id_rsa.pub в публичные ключи репозитория, если потребуется, авторизуем его (просто нажатием кнопки), и сохраняем.
Теперь идем в репозиторий GitHub, переходим в Settings, оттуда переходим в Secrets. Внутри нужно будет назвать секрет и ввести приватный ключ (сохраните его заранее в буфер обмена). Называйте ключ просто – key, вставляйте ключ и сохраняйте.
Готово, оба ключа введены и должны работать.
Пишем файл для деплоя
Чтобы сделать собственно сам деплой, то есть дать понять гиту, что при изменении кода надо залить его на удаленный сервер, нам нужно написать скрипт на языке Yaml. Ниже я приложу код, вникать в него вовсе необязательно, но ниже я укажу действительно важные моменты.
Ну а здесь происходит буквально деплой данных. Сперва, командой cd app мы переходим в папку app (опять же, абсолютно опциональная вещь, если у вас просто нет папки app и никуда не надо переходить – можно убрать эту команду). Ну и далее для нас важна только строка, указывающая, куда все это деплоить:
Это полный путь к моему серверу, причем в конце еще и указан адрес конкретного сайта, в данном случае blog.maxgraph.ru. Если вдруг вы не знаете этот путь – можете уточнить у поддержки вашего хостинга. И будьте внимательны, чтобы случайно не задеплоить данные не туда, куда надо, ведь подобный деплой полностью затирает то, что было ранее.
Что дальше
Итак, файлик deploy.yml нужно поместить в ваш проект в специальную папку .github, чтобы гитхаб о ней узнал, и затем просто запушить проект.
После пуша вы сразу можете перейти во вкладку actions вашего репозитория и вживую посмотреть, как все команды из yml файла выполняются прямо там.
Скриншот вкладки GitHub Actions с рабочим запуском deploy.yml
Заключение
Надеюсь, данная статья была вам полезна. Если же вам интересна видео-версия – в начале статьи есть видео, переходите и смотрите! До скорого!
Деплой (deploy) обычного сайта через Gitlab на примере Bitrix
Хочу поделиться интересным решением, которое подсмотрел у одного заказчика. Я расскажу, как настроить автоматический деплой обычного php сайта на примере bitrix, с помощью gitlab и его webhooks. После коммита разработчика в рабочий репозиторий, код будет автоматически выкатываться на тестовый или рабочий сервер. Решение придумал не я. Делюсь им, потому что показалось полезным, плюс, чтобы самому не забыть и в будущем использовать.
Введение
Конкретно в моем примере я расскажу, как автоматизировать процесс деплоя сайта на bitrix. После коммита разработчика в git репозиторий, будет запускаться webhook через штатный функционал gitlab. Этот вебхук будет дергать url на сервере. Авторизация через token в заголовке запроса. Запрос по этому url будет инициировать запуск bash скрипта, который делает git pull на сервере.
В общем и целом ничего особенного тут нет. Мне понравилось целостность и законченность решения. Не нужно самому колхозить эти скрипты. Решение, конечно, костыльное, но с bitrix чаще всего все решения такие 🙂 Тут плюс в том, что все настраивается очень просто и быстро. Сможет настроить обычный программист для себя, даже если он работает с проектом один.
Как я уже сказал, автор данного решения мне не известен. Ему кто-то увидит свое решение тут и расстроится, что его просто скопировали и не указали авторство, то сообщите мне, я укажу вас.
Особенность деплоя сайта на bitrix
Настройка деплоя bitrix сайта имеет свои нюансы. Дело в том, что битрикс не простой сайт. Через его панель управления можно не только изменять параметры, которые записываются в базу, но и создавать php файлы. Можно добавить или отредактировать шаблон, скопировать какие-то файлы через встроенный файловый менеджер. В связи с этим, нужно внимательно следить за тем, что было сделано через админку. Если просто деплоить исходники из репозитория, можно потерять эти изменения.
А в остальном это обычный php сайт, так что предложенное мной решение деплоя может быть применено для любого другого сайта.
Загрузка bitrix в git репозиторий
Для начала создадим пустой репозиторий и загрузим туда свой сайт. Я не буду подробно останавливаться на работе с git и настройке gitlab. В данном примере подойдет и бесплатный аккаунт на публичном сервисе. Идем на наш веб сервер, куда будем выгружать сайт из репозитория. У меня на нем настроен bitrixenv. Я все буду делать под пользователем bitrix. Заходим в консоль под ним.
Генерируем ключи, чтобы по ним ходить в репозиторий.
Копируем публичный ключ и добавляем его в gitlab.
Возвращаемся на сервер. Немного настроим git.
Идем в каталог с сайтом и инициируем репозиторий.
Создаем файл .gitignore примерно следующего содержания.
Можете его сами изменить под свои требования. Добавляем удаленный репозиторий и делаем первый коммит в него со всеми исходниками сайта.
Наш сайт на битриксе запушился в репозиторий.
Настройка деплоя
Создаем в папке с bitrix директорию gitpull или как вам угодно. Название не принципиально. В нее кладем файл index.php примерно такого содержания.
Данный webhook будет дергать указанный url, а он запускать скрипт /home/bitrix/git/www/git.pull.sh. Создадим директорию и сам скрипт.
Не забудьте изменить адрес директории с исходниками. Скрипт будет писать логи в /home/bitrix/tmp/autopull, так что создаем и его.
В целом, не вижу смысла подробно комментировать скрипты. Они небольшие и в целом понятно, что происходит. PHP файл проверяет токен и если он верный, запускает sh скрипт. Этот скрипт делает git pull, записывает вывод в лог файл. Проверьте внимательно, чтобы все пути у вас были актуальны и команды git соответствовали реальным адресам и названиям репозитория.
После того, как все создали, можно пойти в gitlab, в настройку хука и выполнить тест.
В выпадающем списке выберите Push Events. Если все нормально, в ответ должны получить:
Теперь идите на сервер и посмотрите директорию /home/bitrix/tmp/autopull. Там должна появиться папка с адресом вашего сайта и в ней лог файл с выводом команды в скрипте.
Проверка деплоя (deploy) bitrix
Теперь проверим, как собственно, все будет работать. Для этого можете либо склонировать к себе репозиторий с исходниками, внести изменения, закомиттить их и запушить в репозиторий. Либо можно просто через веб интерфейс gitlab добавить новый файл и сделать commit.
Я просто добавлю файл test.deploy в корень репозитория.
Идем на сервер и ищем этот файл в корне сайта.
Он прилетел сюда автоматически после коммита, который инициировал webhook в gitlab. И дальше все по цепочке выполнилось. В логе появилась соответствующая запись о событии.
Проверьте на всякий случай ответ на запрпос php файла без нужного токена в заголовках. Url с gitpull/index.php должен возвращать ошибку.
Когда будете себе настраивать, поменяйте на всякий случай путь gitpull на свой. Если у вас свой сервер gitlab, можно ограничить к нему доступ по ip сервера, откуда хук будет прилетать.
Заключение
Надеюсь, получилась полезная история на тему деплоя bitrix. С ним очень много нюансов и тонкостей. Программисты, которые первый раз его видят, не понимают, как с ним в принципе работать. Как организовать dev и stage окружение? У битрикса же лицензия на копию сайта. Она иногда слетает, если сайт скопировать и не выполнить некоторые действия с копией.
Так же проблемы возникают при разворачивании сайта для разработки на поддомене. Это не всегда возможно, так как есть шаблоны, в которых зашиты редиректы на основной домен. В итоге поддомен постоянно перекидывает на основной сайт. Ну и много остальных нюансов, описывать которые надо отдельно, не в рамках этой статьи.
У меня есть на примете черновики различных деплоев с помощью gitlab и teamcity, но оформлять их в полноценные статьи не хватает времени. Тема узкая, не очень читаемая. Писать долго, а выхлоп небольшой. Возможно в будущем напишу что-то еще по этой теме.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.
Полуавтоматический деплой приложения из GIT-репозитория
На дворе не 2005 год, и уже давно пора перестать заливать обновления сайта архивами или отдельными файлами через FTP. Как же доставлять обновления?
Но зачем все эти ресурсоёмкие сложности, если у Вас простой сайт на обычном хостинге, на котором поддержка докера не предусмотрена?
В основе предлагаемого метода лежит использование команды git worktree, дающей возможность работать с несколькими ветками git- репозитория в отдельных папках. Также подразумевается, что кодовая база вашего проекта уже давно ютится в git-репозитории.
Почему git worktree?
С git worktree клон репозитория может находится в укромном местечке, а в отделённой ветке будет файл с именем .git, в котором будет указан только путь до клона.
Настройка хостинга и первичная установка приложения
Папка bin
Этот шаг необязательный, но я рекомендую первым делом создать папку bin в корне, куда будут помещены исполняемые файлы, и добавить её в переменную окружения PATH. Вводим в консоль:
В корневой папке вашего профиля следует создать файл с именем .bash_profile с содержимым:
Вы можете сделать это с помощью следующей консольной команды:
Содержимое .bash_profile будет исполняться SSH- клиентом по умолчанию при подключении.
Также разместите в папке bin последнюю версию Composer.
Важно: не забывайте о правах на чтение/запуск исполняемых файлов в папке bin.
Сертификаты
Если ваш проект находится в закрытом git- репозитории, то хосту понадобятся права доступа.
Можно использовать логин и пароль от учётной записи с правами, но мы поступим правильно и сгенерируем Deploy key (ключ, дающий доступ к репозиторию только на чтение).
Для каждого сервера (gitlab, bitbucket, github. ) можно сгенерировать свой ключ, меняя значение id_rsa параметра -f.
В домашней папке появится папка с именем .ssh, в которой будут находиться сгенерированные приватные и публичные ключи. Создадим файл
/.ssh/config со следующим содержимым:
Для gitlab:
Для bitbucket:
Для разных хостов записи с одинаковыми или разными ключами можно совместить в одном файле. Пример:
Публичный ключ (содержимое файла id_rsa.pub) необходимо добавить в список ключей развёртывания (Deploy Keys) репозитория.
Форма для добавления ключа развёртывания в GitLab
На многих хостингах рунета по сей день крутится древний C entos с версией git 1.8.3. Такая старая версия git‘a абсолютно нам не подходит. Команда git worktree появилась ещё в 2015 году в git 2.5, а в git 2.7 значительно расширилась по функционалу.
/git для размещения в ней клонов git-репозиториев и перейдём в неё:
Клонируем репозиторий project-name в папку project-dir:
Перед выполнением команды замените путь до git- репозитория и имена ветки и проекта на свои.
где «master» – имя ветки, на которую будет переключен клон по умолчанию (если не указывать, то будет выбрана «основная ветка»).
ВАЖНО: следует указать ту ветку, которая не будет участвовать в разворачиваемых приложениях, т.к. дерево worktree нельзя создать из активной ветки. Например, если у вас есть ветки master, test, production, то следует выбрать master, а test и production будут вскоре развёрнуты.
Как и на многих хостингах, в T imeweb применяется практика с использованием папки public_html в качестве корневой папки сайта (веб-папки проекта). Если у вас мультисайтовый аккаунт (более одного сайта на хосте), то и папок public_html несколько. Например:
Названия папок берутся из названий сайтов в админской панели и приведены здесь для примера.
Обычно веб-папка проекта не всегда совпадает с корневой папкой приложения: в веб-папке принято размещать только публичные файлы — JS- скрипты, картинки, стили, шрифты; а также файл скрипта для инициализации приложения. Весь рабочий код остаётся вне веб-папки. Эта практика приводит к единственному решению — public_html должна быть ссылкой на веб-папку проекта. Сам проект можно разместить рядом, в папке branch.
Развернём ветку production. На этом этапе уже пора добавить в админской панели свой сайт www-project-name и вместе с тем создадутся папки
/www-project-name/public_html. Папку public_html со страницей-заглушкой нужно сразу удалить. Теперь создаём worktree в папке
Установка приложения
На текущем этапе все файлы нужн ых веток репозитория проекта размещены в соответствующих каталогах:
/www-project-name/branch – production- ветка
/www- test- project-name/branch – test- ветка
Осталось установить и настроить приложение. Переходим в корневую папку приложения:
Настройте конфиг урационные файлы, которые, кстати, должны быть предварительно добавлены в .gitignore.
Если вы используете пакетные менеджеры, то подтяните необходимые пакеты. Применительно к Composer :
Установите само приложение. Например, если это Yii2:
Обновление
Приложение развёрнуто. Осталось настроить обновление приложения — вы ведь будете его поддерживать?
Для этого в папке bin создадим скрипт, который будет подгружать изменения из git-репозитория и применять их. На моём сервере это будет файл
/bin/hi (с правами на запуск):
Содержимое файла в моём случае:
Примечание:
Вы, наверно, заметили, что перед подтягиванием обновлений вызывается команда
Поэтому пользовательские файлы и файлы конфигурации должны быть помещены в .gitignore, чтобы git их не удалил при обновлении.