В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части!
Целью всего этого проекта является создание серверной части для моего будущего архива содержимого, который будет размещен на моем сайте. Однако всякий раз, когда я обновляю серверную часть или меняю схему GraphQL, мне придется выполнять полное развертывание службы снова.
Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно?
Вот почему мы будем использовать GitHub Actions
В GitHub, как и у других поставщиков инструментов непрерывной интеграции, таких как Travis или Circle, есть система интеграции и автоматизации репозиториев. Простота этой системы по сравнению с другими заключается в том, что вы уже находитесь в одном и том же репозитории и пользуетесь одним и тем же инструментом.
Возьмем для автоматизации следующий проект: + мой публичный backend-репозиторий:
Как видите, репозиторий очень прост, в нем немного файлов: docker-compose.yml для локального тестирования и файл mongoke.yml, который станет нашей схемой GraphQL.
Наверху страницы, рядом с настройками, есть кнопка «Действия» — именно здесь мы будем настраивать нашу автоматизацию!
В GitHub уже есть ряд готовых рабочих процессов, однако, к сожалению, ни один из них не подходит для решения наших задач. Но что мы хотим сделать? Чтобы было понятнее, перечислим все этапы процесса:
- Мы получили push в главной ветке
- Мы подключаемся к Azure через main service, выполняя действие, которое называется Azure/login
- Затем мы будем использовать действие 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
