В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части!

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

Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно?

Вот почему мы будем использовать GitHub Actions

В GitHub, как и у других поставщиков инструментов непрерывной интеграции, таких как Travis или Circle, есть система интеграции и автоматизации репозиториев. Простота этой системы по сравнению с другими заключается в том, что вы уже находитесь в одном и том же репозитории и пользуетесь одним и тем же инструментом.

Возьмем для автоматизации следующий проект: + мой публичный backend-репозиторий:

Как видите, репозиторий очень прост, в нем немного файлов: docker-compose.yml для локального тестирования и файл mongoke.yml, который станет нашей схемой GraphQL.

Наверху страницы, рядом с настройками, есть кнопка «Действия» — именно здесь мы будем настраивать нашу автоматизацию!

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

1. Мы получили push в главной ветке
2. Мы подключаемся к Azure через main service, выполняя действие, которое называется Azure/login
3. Затем мы будем использовать действие Azure/cli, чтобы иметь возможность выполнить команду развертывания для нашего контейнера.

Нужно понимать некоторые вещи:

• Кэш страниц GitHub слишком длинный, так что потребуется сгенерировать случайное число или цифровой отпечаток устройства, чтобы разместить его в URL-адресе нашего YAML-файла Mongoke
• У нас есть URI MongoDB, который должен являться секретом

Создание секрета

Во-первых, давайте решим вопрос с зависимостями: простейшая зависимость, которую нам предстоит решить, заключается в создании URL-адреса MongoDB в качестве секрета. Для этого перейдем на вкладку «Настройки» и нажмем «Секреты». Просто добавьте новый секрет, щелкнув ссылку «Добавить новый секрет» и указав его имя и содержимое. Если мы добавляем URI MongoDB, секрет будет называться MONGODB_URI.

Разрешение действий в Azure

Чтобы разрешить GitHub выполнять действия от нашего имени в Azure, потребуется создать Service Principal. Благодаря этой функции мы получаем учетную запись приложения и возможность разрешить другим людям или службам подключаться к нашему порталу и выполнять действия от нашего имени.

Для создания этой функции мы воспользуемся Azure CLI. Выполнив вход в систему с помощью команды az login, просто выполните следующую команду:

az ad sp create-for-rbac --name <SP-name> --role contributor --scopes /subscriptions/<subscriptionID>/resourceGroups/<resourcegroupname> --sdk-auth

Чтобы получить ID подписки, просто выполните команду az account list и найдите ключ идентификатора подписки: ключ isDefault должен иметь значение true. Кроме того, вы можете присвоить основной службе любое имя, сделав его описательным: так все будут знать, кому вы предоставляете разрешения.

Еще один важный момент: следует предоставлять разрешения только необходимым ресурсам, то есть создавать хранимую процедуру не для ВСЕЙ учетной записи, а только для нужной группы Resource Group. В моем случае эта группа ресурсов называется «личный веб-сайт», именно там я группирую все связанные с моим веб-сайтом ресурсы.

Эта команда должна давать ответ в формате JSON типа:

{
  "clientId": "xxxxxxx",
  "clientSecret": "xxxxxxxx",
  "subscriptionId": "xxxxxxxx",
  ...
}

Копируйте весь ответ и создайте новый секрет GitHub с именем AZURE_CREDENTIALS:

Теперь у нас должно быть два секрета:

Создание рабочего процесса

Чтобы создать свой первый рабочий процесс, просто вернитесь на панель «Действия» рядом с разделом «Настройки» и нажмите кнопку «Настроить этот рабочий процесс»:

Выполнив это действие, вы перейдете на новый экран с первоначальной моделью кода:

Помните, что GitHub Actions — это не что иное, как YAML-файл в папке /.Github/workflows. Так будет называться наш рабочий процесс, так что это имя должно быть максимально описательным. Давайте назовем наш файл publish-prod.yml:

У нас есть следующее содержимое:

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

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

Как видите, у нас несколько доступных действий. Для получения дополнительной информации см. the official documentation

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

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

Мы будем выполнять это задание в образе Ubuntu, но есть и другие варианты: in the documentation. После этого мы настроим шаги. Шаг — это последовательность задач, выполняемая в рамках задания. Это место, где будут выполнены вход в систему и развертывание!

Для этого мы изменим ключ шагов и удалим все содержимое, чтобы использовать готовые шаги Azure для входа в систему! В текстовом поле сбоку можно выполнить поиск Azure/входа в систему:

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

Именно здесь будет задан наш первый секрет. Чтобы предоставить учетные данные для входа в систему, нужно использовать созданный ранее секрет AZURE_CREDENTIALS. Чтобы использовать секрет, просто поместите его в двойные фигурные скобки, как показано ниже: $ {{secrets.AZURE_CREDENTIALS}}.

Наш файл выглядит следующим образом:

Мы создадим второй шаг, который назовем «Развертывание ориентированной на приложения инфраструктуры», — здесь мы будем выполнять команду интерфейса командной строки Azure. Для этого мы используем другой шаг с командой run, которая будет содержать строку, выполняемую в нашем интерфейсе командной строки. В нашем случае с замененными переменными это будет иметь следующий вид:

Посмотрим на последнюю часть, где мы создали переменную MONGOKE_CONFIG_URL. Одной этой переменной недостаточно, ее необходимо объединить с SHA-значением фиксации, чтобы нам не мешал кэш. При объединении переменных мы работаем только на уровне шага, так как на уровне задания или рабочего процесса в целом выражения недоступны. Давайте создадим еще один шаг и назовем его «Создание URL-адреса».

В этом шаге мы выполним команду Workflow Command, которая относится к встроенным командам GitHub Actions, доступным с помощью синтаксиса команды ::. В нашем случае мы используем команду set-env, которая служит для создания новой переменной среды. Синтаксис имеет следующий вид: ::set-env name=<name>::<value>, а затем можно использовать выражения объединения:

Как видите, мы объединяем ${{env.MONGOKE_CONFIG_URL}} с ?v= и берем первые шесть цифр native environment variable, которые называются GITHUB_SHA. Давайте добавим этот шаг после входа в систему:

Теперь перейдем к последнему шагу, на котором выполняется наша команда, и внесем небольшие изменения. Вместо того чтобы использовать переменную MONGOKE_CONFIG_URL, воспользуемся нашей новой переменной MONGOKE_URL:

Окончательный файл будет иметь следующий вид:

Теперь можно нажать кнопку «Начать фиксацию» и ждать выполнения действия:

Отслеживание рабочего процесса

Отслеживать рабочий процесс можно на вкладке «Действия»:

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

Теперь на портале Azure видно, что наш контейнер был обновлен:

Кроме того, видно, что наши URL-адреса верны:

Заключение

За 7 минут мы автоматизировали весь процесс развертывания приложения в Azure и, даже не осознавая этого, сэкономили массу времени, выполнив простое и быстрое действие, на которое нужно всего несколько минут!

В других статьях более подробно рассматриваются GitHub Actions для других инструментов и распределенных моделей приложений!

До встречи!

Это статья авторства Лукасом Сантосом. Если у вас есть какие-либо вопросы или комментарии по теме статьи, разместите их под первой статьей на dev.to