Гайд по деплою web-приложений для новичков. Часть 3. Простая автоматизация

Привет, коллеги! 👋

Продолжаем цикл статей, посвященных деплою приложений на сервер.

Вот ссылки на другие части статьи:

Сегодня покажу, как можно автоматизировать деплой. Два варианта, которые отлично подойдут новичкам для ускорения деплоя:

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

Вкратце напомню, что уже изучили, и как мы деплоим вручную:

То есть кучу команд необходимо запустить и на локальном рабочем месте, и на сервере. И это, конечно же, неудобно. Здесь достаточно много ручной работы, это наводит уныние. Да и можно всего одну команду упустить, и деплой будет неудачным!

Давайте автоматизировать это дело!

Автоматизировать мы будем деплой проекта на Laravel, репозиторий с демо-версией админки MoonShine - https://github.com/moonshine-software/demo-project.

В этой статье мы автоматизируем деплой проекта, который уже был развернут и настроен. Если вы делаете деплой проекта в первый раз, выполните настройку по этим статьям: shared-хостинг, VPS.

Самый простой вариант по автоматизации деплоя. Сделаем обычный bash-скрипт, который будем запускать одной командой на сервере, а он будет делать все за нас.

Назовём скрипт easy-deploy.sh.

Приступаем к наполнению скрипта командами. Чтобы интерпретатор понял, что это именно bash-скрипт, мы должны написать вот такую конструкцию в начале файла:

#!/bin/bash

Подстелим себе соломку: добавим инструкцию set –e . Если одна из команд завершится с ошибкой, то скрипт прекратит работу. И дальше пишем команды для деплоя (для Composer и миграций желательно использовать флаги --no-interaction и --force соответственно. Они позволяют выполнять команды без необходимости вмешательства пользователя, что важно для автоматизированного процесса деплоя):

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

Давайте проверять. Делаем коммит и обновляем проект на сервере. Вот появился у нас скрипт, давайте запустим его:

Контролируем процесс.

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

Сейчас процесс деплоя приведен к виду:

Плюсы:

Минусы:

По сравнению к деплоем вручную - намного лучше, давайте посмотрим еще один популярный вариант автоматизации.

GitHub Actions — это инструмент для автоматизации рутинных задач в разработке программного обеспечения. Он позволяет настроить автоматическое тестирование, сборку и деплой приложения. GitHub Actions глубоко интегрирован в экосистему инструментов GitHub.

Итак, у GitHub есть Actions, и можно настроить так, чтобы на событие push в GitHub-репозиторий, GitHub будет запускать необходимые команды на сервере. Что надо сделать:

Велосипед выдумывать не будем, работаем по документации GitHub.

Создаём свой workflow - создаем папку в каталоге .github/workflows, в ней файл deploy.yml.

Оформим инструкцию!

Указываем, что выполняем workflow после события push в ветку main (указываем нужную).

Для выполнения команд на удаленном сервере через SSH мы используем appleboy/ssh-action@master (это GitHub Action, созданный пользователем с именем "appleboy". Позволяет подключиться к удалённому серверу через SSH и

выполнять команды на этом сервере).

Что делает эта Action:

Файл для работы workflow готов. Обратите внимание на ${{ secrets.SSH_HOST }}, ${{ secrets.SSH_USERNAME }} и ${{ secrets.SSH_PRIVATE_KEY }}. Это переменные для настройки подключению к серверу, которые нам нужно будет создать на GitHub.

Хранить информацию по подключению к серверу в файле, который лежит в репозитории, ненадежно.

Для хранения конфиденциальной информации (такой как пароли, ключи API и т.д.) придуманы secrets - это переменные, которые вы можете использовать в вашем репозитории GitHub. Secrets предоставляют безопасный способ хранения данных (GitHub обещает, что всё храниться в зашифрованном виде), которые нужны для настройки GitHub Actions workflows.

Secrets находятся в настройках репозитория GitHub - "Secrets and Variables", раздел "Actions".

Добавляем информацию для настройки SSH подключения:

Переходим к SSH ключам. При настройке SSH-соединения приватный ключ должен храниться на устройстве, с которого вы планируете подключаться к удаленному рабочему месту. А публичный ключ, должен быть скопирован на удаленное рабочее место (к которому мы будем подключаться). Подключаться мы будем с GitHub к серверу. Получается, что мы должны приватный ключ хранить на GitHub, а публичный (.pub) - на сервере.

Сгенерируем на сервере пару ключей для нового SSH-соединения "GitHub-сервер". При генерации придумайте уникальное название, например, "github actions" (чтобы потом проще было найти):

ssh-keygen -t rsa -C "github actions"

- C "github actions": добавляет комментарий к ключу. Это помогает идентифицировать ключ, особенно если у вас их несколько.

Указываем имя для файла с ключами:

Enter file in which to save the key (/home/localadmin/.ssh/id_rsa): /home/localadmin/.ssh/gitHubSSH

Готово!

Копируем значение приватного ключа в секрет SSH_PRIVATE_KEY (начиная от —Begin… до …end ssh private key—).

Сам файл приватного ключа можно удалить (на всякий случай, чтобы никто не смог подключиться к нашему серверу).

Итак, secrets настроены, файл с workflow у нас готов, нужно отправить его на GitHub. Создаем новый коммит с изменением, пушим на GitHub.

Смотрим, появился ли наш workflow в разделе Actions.

Ждём пока выполнился workflow. Проверяем.

Всё отлично. Но есть недостаток: что происходит в workflow не видим. git push выполнили и дальше ждем, когда проект обновится на сервере. Как решить? Надо либо заходить в экшены репозитория и мониторить работу в режиме реального времени, либо настраивать уведомления на email.

Настраиваем уведомления на почту. Чекбокс стоит, что получаем уведомления о неудачных workflow, если же хотите получать и об успешном выполнении, то снимаем чекбокс.

Плюсы:

Минусы:

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

Выбор метода зависит от конкретных потребностей проекта, уровня навыков команды и желаемой степени автоматизации.

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

В следующей статье покажу, как автоматизировать деплой Laravel-приложений с использованием Laravel Envoy.

Ссылки на другие части статьи по деплою:

А какой опыт автоматизации деплоя у вас? Возможно, вы используете другие инструменты или у вас есть свои хитрости в настройке процесса? Поделитесь своими мыслями и опытом в комментариях!

Данил Щуцкий, автор проекта CutCode.