Развертывание с GitHub на сервер
GitHub, равно как и система контроля версий Git, на которой он основан, это фантастические инструменты для организации работы и взаимодействия в проектах, независимо от того, связаны эти проекты с кодом или нет.
В этой статье мы рассмотрим способы, позволяющие улучшить интеграцию Git и GitHub в рабочий процесс разработчиков, облегчая и механизируя процесс развертывания.
Я разделил все эти способы по типам используемых инструментов: отдельно инструменты для автоматического тестирования и отдельно проверяющие развертывание на сервере.
Зачем это нужно
Автоматизация этих процессов позволит вам и вашей команде сфокусироваться на создании, согласовании и объединении кода вместо того, чтобы тратить часы на развертывание и прочие повторяющиеся задачи при каждой новой сборке или изменении.
Недостатки автоматизации
Основная проблема с автоматическим развертыванием изменений это и есть автоматическое развертывание изменений. У вас должна быть уверенность в своей команде и в написанном коде. Именно поэтому автоматическое развертывание обычно совмещается с автоматическим тестированием и это отразилось на представленных ниже инструментах.
Конечно, это также означает, что все небольшие вопросы должны решаться одинаково быстро. Автоматизация должна сочетаться с коммуникацией. Если отправка в репозиторий основной ветки может запускать процесс сборки, то должно быть понятно, когда это происходит и кто может это вызвать.
Первоначальная настройка автоматизации может занять некоторое время. Важно заранее подумать о том, действительно ли это необходимо вашей команде и вашему рабочему процессу. Добавьте количество времени, которое вы тратите на тестирование и развертывание новых сборок — и если это занимает больше нескольких минут каждый раз, то оно того стоит.
Хуки Git
В Git есть набор встроенных хуков (или перехватчиков), которые могут быть использованы для автоматизации и обычно они являются первой остановкой для выполнения каких-либо задач после действий Git. Хуки делятся на серверные и клиентские.
Хуки с серверной стороны предназначены для таких событий, как прослушивание сетевых операций — например, когда репозиторий принимает отправку. Клиентские хуки запускаются при действиях, происходящих на компьютере разработчика, например, коммитах и объединении веток.
Полный список хуков есть в документации Git. Я рассмотрю пару из них для начала. Надеюсь, это поможет вам понять, насколько полезны они могут быть в ваших проектах и в рабочем процессе (не автоматизированном).
Хук pre-commit
Клиентский хук запускается до любого другого хука и до коммита любых изменений. Это лучшее место для добавления тестов и прочих проверок вашего кода.
Добавим простой код JavaScript (в котором мы заранее сделали ошибку) в наш небольшой проект:
Мы будем использовать JSHint для выявления ошибок в JavaScript ( инструкция по установке JSHint).
Переименуем файл hooks/pre-commit.sample (этот файл расположен в скрытом каталоге .git вашего проекта) в hooks/pre-commit` и изменим содержимое этого файла на следующее:
Попытаемся сделать коммит изменений:
И получим следующее сообщение об ошибке:
Добавим недостающую точку с запятой и попытаемся еще раз. Коммит пройдет без каких-либо проблем.
Хук post-receive
Этот серверный хук срабатывает после завершения получения переданных изменений в удаленном Git-репозитории. В нашем примере, мы передаем последнюю версию нашего простого сайта в каталог веб-сервера для развертывания.
У меня есть существующий сайт, состоящий из index.html и нескольких страниц еще, которые мы будем использовать в следующих примерах. Вы можете создать свой сайт или использовать пример из демо-репозитория.
Клонируйте репозиторий, используя флаг —bare , чтобы в репозитории была только информация из системы контроля версий, а не наш код:
Теперь создадим хук:
Добавим в файл с хуком следующие строчки:
Примечание: указаны рабочие каталоги в Ubuntu, в вашей системе они могут отличаться.
Эта команда извлекает текущий репозиторий в указанный рабочий каталог, но без данных системы контроля версий.
Нам надо сделать наш хук выполняемым:
На своей локальной машине, клонируйте репозиторий в обычном режиме, используя инструмент по своему выбору и добавьте новый удаленный сервер (не забудьте добавить настройки своего сервера).
Для развертывания на рабочий сервер вместо репозитория введите:
Если вы посмотрите теперь в каталог var/www/html , то вы найдете там автоматически скопированный файл index.html .
Если вы используете свой собственный репозиторий Git, то он расположен на том же сервере, что и ваше приложение и процесс развертывания теперь автоматизирован. Если вы используете Github или иной сторонний сервис Git, этот хук не будет полностью автоматизировать ваш рабочий процесс, а скорее сократит его на один шаг. В дальнейшем мы это упростим.
Один из вариантов это использование команд rsync или scp в хуке post-receive на GitHub. Другой вариант, особенно, если ваше приложение нуждается в процессе сборки перед запуском (Github ограничивает доступные команды) — это использование хука post-receive для запуска скриптов на сервере приложения, проверяющего код на GitHub (с опцией -f ) и запускающему остальные необходимые команды. Как видите, все стало несколько сложнее, нам пора перейти к следующему набору инструментов.
Автоматическое развертывание непосредственно с GitHub
На GitHub есть документация об автоматизации развертывания на платформы интеграции, некоторые из которых также являются хостинг-провайдерами.
Буду честным, большая часть изученной мной документации оказалась некорректной, неточной или бесполезной, поэтому я добавлю ссылки на документацию нескольких популярных хостинг-провайдеров, а для остальных я предлагаю вам использовать post-receive или методы непрерывной интеграции:
Сервисы непрерывной интеграции
Существует множество сервисов, способных отслеживать ваши репозитории на GitHub и не только производить развертывание с них, но и совершать другие действия, такие как запуск тестов и сборка.
Перейдя к новому и более сложному примеру, мы могли бы использовать сервис непрерывной интеграции для автоматизации процесса сборки проекта. В первую очередь после получения ветки Master из репозитория запускается скрипт bash, выполняющий сборку и развертывание, затем генерируется твит об обновлении. Сервис непрерывной интеграции может физически находится на одном сервере с веб-сервисом или на разных, в зависимости от ваших предпочтений.
Рассмотрим самые популярные из них.
Jenkins
Для использования вам надо настроить свой сервер с Jenkins, это даст вам полный контроль над ним, но заставит тратить время на поддержку. К счастью, Jenkins поддерживает многие платформы, в том числе Docker, если вы хотите для начала поэкспериментировать.
Большая часть функциональности Jenkins достигнута за счет плагинов, а благодаря сложившемуся за долгие годы open-source сообществу этих плагинов много. Например, есть плагины для Git, GitHub и Twitter.
Jenkins требует долгой настройки и временами совмещение всех имеющихся инструкций для создания подходящего рабочего процесса требует изучения.
Travis
Инструкции по интеграции с Travis, имеющиеся на GitHub, на данный момент устарели. Но решается это просто: для этого есть документация на сайте Travis.
Travis не требует какой-либо настройки сервера или хостинга, поэтому он подойдет тем, кто не хочет тратить на это время. Тем не менее, расширение его за пределы дефолтных настроек потребует дополнительного конфигурирования. Например, Tweeting требует доступ к веб-хукам.
Travis имеет привычку медленно замечать обновления в ваших репозиториях, особенно если эти изменения произведены в файле настроек самого Travis. Эти проблемы тяжело решить, если у вас нет доступа к серверу Travis.
Другие коммерческие сервисы
Системы интеграции становятся все популярнее, появляется все больше новых сервисов и приложений — многие из них выпущены разработчиками инструментов, которые вы уже используете, и они будут плавно интегрироваться в существующие рабочие цепочки.
Заключение
Надеюсь, это краткое введение разъяснит вам отдельные вопросы, касающиеся работы развертывания. Мы определенно прошли долгий путь со времен отправки файлов на сервер с помощью FTP.
What Is the Easiest Way to Deploy from Github to a Web Server?
I’ve written before on how to do this the hard way. Now let’s look at the easy way.
I’ll assume you already have a repo setup on Github, and that you are setup to push to it.
Setup on Circleci
I picked circleci but you could re-create this setup with other services such as Codeship, Deployhq, or more.
I like Circleci’s pricing model: it is free. You can pay extra when you want to accelerate your builds — something you may want to do in a company setting.
Create an account
Fairly straight forward. Hit “Sign up” and connect with Github.
Create a project
In the left sidebar, go into “Project”. Then in the upper right corner, click on “Add project”. Find the repository you want to setup.
Once you found it, click “build project”. Let it build. It will tell you at the end that no Circleci setup was found. That’s expected, you’re missing the circle.yml file.
Add a deploy key
You may want to deploy to a simple server like DreamHost, or to an S3 bucket on Amazon. Either way, you’ll need to create a secure access to these places.
Setup ssh keys on your web server (not sure how to do that? Look it up!). And copy your private key.
Next, go into your new project’s settings on circleci. Find the “Permissions” section in the sidebar navigation. Go into the “SSH Permissions” section. Add your private key. This will allow Circleci to deploy to your web server.
# Развёртывание проекта с помощью git-репозитория
Этот способ развёртывания подходит для проектов, которые будут в общем доступе или разрабатываются несколькими специалистами.
В этой инструкции мы опишем размещение проекта на github
(opens new window) и его последующее клонирование на хостинг.
Файл passenger_wsgi.py, который будем добавлять в репозиторий, выглядит так:
# Предварительная настройка github
Для удобства работы с github будем использовать десктопную утилиту GitBash
Для начала работы войдите в свою учётную запись на github
Сначала нужно настроить SSH-подключение с аутентификацией по ключу.
Настройка SSH-подключения с аутентификацией по ключу
Перейдите в папку проекта и запустите GitBash — выберите Git Bash Here в контекстном меню:
В открывшейся консоли введите:
Эта команда сгенерирует новую пару ключей и отправит об этом уведомление на указанную почту.
Далее перейдите к строке:
Здесь укажите имя для файлов с ключами.
После завершения работы алгоритма проверьте наличие файлов с ключами в папке:
Теперь добавьте ключи к SSH-агенту. Для этого запустите агент в фоновом режиме:
Затем выполните команду:
В строке your_file_name укажите имя файла, которое вы задали при генерации пары ключей.
Когда ключи добавлены к SSH-агенту, публичный ключ из файла *./pub нужно разместить в аккаунте на github.
Для этого перейдите в github и в разделе Settings вашего аккаунта выберите пункт SSH and GPG keys:
Здесь нажмите кнопку New SSH key и вставьте содержимое файла your_file_name.pub.
Проверить правильность работы ключей можно такой командой:
# Загрузка проекта на github
Чтобы добавить проект на github, нужно создать для него новый репозиторий. В настройках аккаунта выберите Your Repositories и в открывшемся окне нажмите New :
В окне создания нового репозитория укажите имя репозитория, добавьте его описание и выберите тип доступа, частный или публичный:
После нажатия кнопки Create repository новый репозиторий будет создан. В открывшемся окне появится инструкция по загрузке проекта в только что созданный репозиторий.
В папке с проектом запустите консоль работы с git — Git Bash Here. В открывшейся консоли введите:
Эта команда инициирует текущую папку в качестве источника для git-репозитория. Также в этой папке будет создана папка .git, в которой будет всё необходимое для работы git.
Добавьте файл проекта:
В нашем проекте всего один файл, поэтому можно указать его имя напрямую. Чтобы добавить в репозиторий всё содержимое папки, вместо имени файла или папки поставьте «точку»: git add .
Добавьте первый коммит:
Добавьте адрес репозитория из инструкции — просто скопируйте строку, указанную в инструкции, и вставьте её в консоль:
И последний шаг — загрузите файлы в репозиторий:
В данном случае в команде git push -u origin используется параметр master, а не предложенный в инструкции main.
После успешной загрузки можно перейти на github и удостовериться, что все файлы добавились:
# Клонирование проекта с github
Скопируйте частный ключ репозитория на ваш хостинг. Файл, содержащий частный ключ, можно передать на хостинг по SFTP или загрузить с помощью файлового менеджера, установленного на Джино.
Разместите файл с ключом в папке .ssh и установите права доступа к нему 400.
Подключитесь к хостингу по SSH и добавьте частный ключ к агенту, как это делали раньше:
Хостинг готов к работе с github!
Вернитесь на github и в окне управления репозиторием скопируйте ссылку для его клонирования по SSH:
Деплой сайта с GitHub на хостинг через SSH
Итак, чтобы разобраться со всей этой темой, вам понадобится:
- Базовые навыки работы с Git. Коммиты, пуши, пуллы и все такое.
- Хостинг, поддерживающий подключение по SSH.
- GitHub-репозиторий с поддержкой GitHub Actions (насколько я знаю, они работают везде, но мало ли).
Принцип
Вкратце скажу принцип работы всего этого действа: когда мы будем пушить данные в репозиторий, сработает GitHub Action, которому сказано подключиться к вашему хостингу по SSH и залить туда данные с помощью rsync.
Создание SSH-ключа
Итак, самое первое, что нам стоит сделать, это создать SSH-ключи – приватный и публичный. Лучше всего это делать непосредственно в консоли гита — Git Bash. Если же вы на Mac – подойдет и Терминал.
Открываем Git Bash, вводим следующую команду:
При использовании команды указывать парольную фразу не нужно.
Скриншот из консоли при вводе команды создания ключа
Данная команда создаст ключи и поместит их в папку .ssh на вашем ПК. К сожалению, не знаю, куда именно попадают ключи на Mac, но думаю вы легко найдете это в гугле. А на винде — C:\Users\ИмяПользователя.ssh. Если же вы откроете Bash в этой же папке — ключи попадут прямо в нее. Главное, не забудьте удалить их оттуда, чтобы они не попали в файлы репозитория!
В этой папке вы найдете ключи id_rsa и id_rsa.pub, приватный и публичный ключи соответственно.
Добавление ключей
Итак, когда вы создали ключи, их нужно добавить на хостинг и в репозиторий. Как именно устроено это на разных хостингах, я знать не могу, но покажу на примере cPanel, как это выглядит.
Скриншот из cPanel, доступ по SSH
Добавляем id_rsa.pub в публичные ключи репозитория, если потребуется, авторизуем его (просто нажатием кнопки), и сохраняем.
Теперь идем в репозиторий GitHub, переходим в Settings, оттуда переходим в Secrets. Внутри нужно будет назвать секрет и ввести приватный ключ (сохраните его заранее в буфер обмена). Называйте ключ просто – key, вставляйте ключ и сохраняйте.
Готово, оба ключа введены и должны работать.
Пишем файл для деплоя
Чтобы сделать собственно сам деплой, то есть дать понять гиту, что при изменении кода надо залить его на удаленный сервер, нам нужно написать скрипт на языке Yaml. Ниже я приложу код, вникать в него вовсе необязательно, но ниже я укажу действительно важные моменты.
- Итак, название файла deploy.yml
- Внутри также указан name: Deploy
- А далее указано действие, по которому сработает скрипт — on: push: branches: main . То есть, когда вы будете пушить что-то в ветку main – сработает скрипт. Конечно, если у вас другая ветка – можете поменять ее.
- Далее указана "работа", или же jobs. Там описано, где именно будет запускаться все это и как. А также указан путь к ключам, как — run: echo "$" > "$HOME/.ssh/key" . Как раз тут и указано наше название ключа, key, которое мы писали в секретах.
И самая интересная для нас часть кода — это build и deploy.
Первая строка по факту равноценна привычному npm i , просто через ci установить все это на гите быстрее. Вторая же строка — это строка опциональная. Если у вас в проекте есть npm-скрипт build — используйте. Если у вас вообще нет npm-скриптов — удалите эти строчки.
Ну а здесь происходит буквально деплой данных. Сперва, командой cd app мы переходим в папку app (опять же, абсолютно опциональная вещь, если у вас просто нет папки app и никуда не надо переходить – можно убрать эту команду). Ну и далее для нас важна только строка, указывающая, куда все это деплоить:
Это полный путь к моему серверу, причем в конце еще и указан адрес конкретного сайта, в данном случае blog.maxgraph.ru. Если вдруг вы не знаете этот путь – можете уточнить у поддержки вашего хостинга. И будьте внимательны, чтобы случайно не задеплоить данные не туда, куда надо, ведь подобный деплой полностью затирает то, что было ранее.
Что дальше
Итак, файлик deploy.yml нужно поместить в ваш проект в специальную папку .github, чтобы гитхаб о ней узнал, и затем просто запушить проект.
После пуша вы сразу можете перейти во вкладку actions вашего репозитория и вживую посмотреть, как все команды из yml файла выполняются прямо там.
Скриншот вкладки GitHub Actions с рабочим запуском deploy.yml
Заключение
Надеюсь, данная статья была вам полезна. Если же вам интересна видео-версия – в начале статьи есть видео, переходите и смотрите! До скорого!