Автоматический деплой на сервер

Введение, что меня побудило изучать девопс в данном вопросе, почему использую сторонее железо в виде vps

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

Изначально я начинал свой путь в профессии с wordpress и бекенд фреймворка yii2. Они написаны на языке php, и чтобы сайты корректно работали, мне было необходимо настраивать базу данных и сервер nginx у себя локально, вот с этого и началось мое изучение девопса. В то время вышеописанный стек назывался LNMP — расшифровывается как linux nginx mysql php.

Следующим шагом в изучении девопса для меня стало настройка автодеплоя на удаленный сервер в одной из компаний, хотя тогда я уже работал фронтенд разработчиком и не понимал зачем мне это нужно. Лишь спустя время, полученные знания дальше по жизни много раз помогали мне настраивать свою инфраструктуру, при этом, повышая мой труд и удобство работы. Минусом в этом шаге является то, что для деплоя использовалось устаревшая технология, которую после увольнения из вышеупомянутой компании, больше нигде не встречал.

По происшествию времени сейчас могу сказать, что эти знания мне сейчас помогли развернуть и настроить инфраструктуру для деплоя готового кода на мой удаленный сервер. Как видно из примера — программист обязан знать базу девопса, чтобы маломальски настроить проект и потом не отвлекаться на рутинные вопросы: стабильная работа базы данных, деплой готового кода и т. д. т. п.

Теперь давайте обсудим почему сейчас выгоднее арендовать сервера, чем содержать их у себя. Когда я только начинал заниматься программированием, то виртуальные сервера были не дешевыми, а простые хостинги с готовым решением стоили в разы дешевле, соответственно все выбирали второй вариант. Сейчас виртуальные сервера подешевели и стоят относительно недорого, в некоторых вариантах даже дешевле хостингов. Плюс, арендуя железо, я снимаю с себя настройку и доступ сервера в интернете, обслуживание железа и т. п. Если показать на практике, то мне сейчас мой впс обходится в 300-400 рублей в месяц, это по факту содержание моего сайта в месяц, согласитесь, не большая цена, за то имею отдельный сервер, где могу настроить все, что захочу.

Теория ci/cd, как можно запускать скрипты проверки на гитхабе, как настроить автоматический деплой с гитхаба прямо на любой сервер

Ci/cd в моем понимании — это непрерывная разработка и доставка готового кода в продакшн. То есть ведется разработка какого-либо проекта, после разработки код проходит проверку на линтерах, в моем случае это eslint, и прогоняются юнит тесты. После прохождения на локальной машине линтеров и тестов наработки коммитятся и отправляются на гитхаб, либо другой сервер хранения кода, в моем случае это гитхаб.

Здесь далее в силу вступают github actions — это события, которые запускаются по тем или иным событиям. Они представляют собой файлы yaml с написанными внутри инструкциями, далее будет описание таких файлов и разбор кода по моим примерам из репозитория. Github actions можно настроить запуск на события push, merge, pull_request и другие, более подробней можно посмотреть в документации. Запуск также можно точечно настроить, чтобы он выполнялся только на определенной ветке.

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

Настройка локальных хуков гитхаба

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

Давайте теперь разберем разберем некоторые некоторые нюансы работы с вышеупомянутым пакетом:

• пакет устанавливается стандартно как и все остальные через npm i;
• для начала работы с хуками гита пакет husky необходимо инициализировать одним из двух способов: либо во время загрузки всех пакетов, как пример, когда клонируешь репозиторий вызываешь инициализацию пакетов; либо вручную введя команду husky install, например, если пакет был добавлен во время активной разработки.
• Добавить хук для husky возможно через следующую команду: husky add .husky/pre-commit 'npm run lint && npm run test'. В данном пример на событе pre-commit добавляется прогон линтера и запуск тестов;
• при использовании husky нужно держать в голове, что по документации генерированные скрипты не переносятся на удаленный стенд.

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

Настройка собственных гитхаб экшенов и их тестирование

Для работы github actions используется файл с расширением .yml.

На картинке «Пример реализации github action для проверки кода» показана реализация экшена:

• 1 строка — имя экшена, оно же будет отображаться в панели управления;
• 3 строка — событие и условие при котором будет запущен экшен, в данном примере при любом событии push;
• 5 строка — список джоб, которые будут выполнены;
• 6 строка — название самой джобы, может называться как угодно;
• 7 строка — указывается операционная система, в которой будет выполнена работа скрипта;
• 8 строка — указывается список, который будет выполнен при прохождении скрипта;
• 9 и 11 строки — указываются готовые решения, которые можно применить в скрипте. В моем случае это переход на мою ветку и установка ноды;
• 10 строка — промежуточное сообщение;
• 12 и 13 строки — указываем версию nodejs;
• 14 — 16 строки — указываем скрипты, которые должны быть запущены.

Обратите также внимание, что при запуске github actions в самом гитхабе поднимается отдельная виртуальная машина, которая выполняет то поведение, которое будет прописано в файле yml.

Настройка автоматического деплоя на мой сервер с гитхаба

Настройка автоматического деплоя на удаленный сервер с гитхаба состоит из нескольких частей: добавление публичного ключа сервера на гитхаб; настройка секретов в репозитории; продумывание и написание скрипта, который реализует деплой.

Давайте начнем с добавления публичного ключа для гитхаба. Для этого необходимо зайти на удаленный сервер и создать ssh ключ, который будет работать только с гитом, подчеркиваю — только с гитом. В результате будет создано два ключа: публичный и приватный. Публичную часть ключа необходимо будет добавить в общие настройки профиля на гитхабе. После этого на сервере необходимо будет ввести команду ssh-add и указать местоположение приватного ключа. Когда вышеописанная операция будет выполнена, то можно попробовать склонировать репозиторий через ssh. В результате выполнения клонирования у вас получится склонировать репозиторий, при этом пароль не будет запрашиваться.

Некоторые зададутся вопросом почему клонировать нужно через ssh. Это необходимо для того, чтобы не вводить ключ при клонировании через https, ведь в самом скрипте не будет возможности прописать функционал, который позволит ввести пароль, когда тот выскочит при клонировании через https. При ssh этой проблемы нет, поэтому его и выбираем.

При работе с клонированием через ssh необходимо учитывать, что при каждом деплое неободимо будет выполнять две команды eval `ssh-agent -s` и ssh-add путь к файлу. Я не стал подробно разбираться с чем это связано, но автоматически клонировать получилось только после выполнения этих команд.

Перейдем к настройке секретов для репозитория. Они нужны для работы экшена ssh-action, его работа описана в разборе скрипта. Сами секреты указываются в настройках репозитория. У меня для работы с экшеном ssh-action были созданы следующие секреты: HOST, USERNAME, SSH, PORT. Здесь стоит обратить внимание на SSH. Это приватный ключ для авторизации, для его получения необходимо также сгенерировать приватный и публичный ключ. Приватный вставляется в секрет в репозитории, а публичный добавляется в авторизованные ключи.

На картинке «Скрипт экшена на деплой на удаленный сервер с github» указываются следующие события:

• 1 строка — именование скрипта, имя будет выведено в панель управления слева;
• 3-5 строки — указывается, что скрипт будет срабатывать на событие push в ветку nextjs;
• 7 строка — список джоб, которые будут выполнены;
• 8 строка — название самой джобы, может называться как угодно;
• 9 строка — указывается операционная система, в которой будет выполнена работа скрипта;
• 10 строка — указывается список, который будет выполнен при прохождении скрипта;
• 11 и 13 строки — указываем готовые решения github;
• 14-19 строки — указываем данные для подключения к удаленному стенду;
• 20-31 строки — указываем, что необходимо делать после подключения к стенду.

Описание алгоритма, который выполняется в 20-31 строках:

• Создать пустую папку для нового деплоя;
• Скопировать в нее файл env и другие файлы при наличии;
• Запустить инициализацию зависимостей (npm i);
• Запустить build проекта;
• Удалить старую версию сайта;
• Переименовать новую папку в название старой папки;
• Зайти в нее и перезапустить pm2 с необходимой таской;

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

Выводы

В этой статье я затронул тему почему каждый программист должен знать основы девопса, теорию ci/cd, настройку работы с локальными git хуками, работу с github actions и скриптами, которые для них писались. Надеюсь мой опыт девопса поможет вам понять для чего это все необходимо изучать. От себя же добавлю, что все, что описано в этой статье, мне не раз помогало как в коммерческом опыте, так и в моих личных проектах.

Больше статей в моем блоге. Спасибо, что дочитали и до новых встреч в следующих статьях.