В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части! Целью всего этого проекта является создание серверной части для моего будущего архива содержимого, который будет размещен на моем сайте. Однако всякий раз, когда я обновляю серверную часть или меняю схему GraphQL, мне придется выполнять полное развертывание службы снова. Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно? Вот почему мы будем использовать GitHub Actions  В GitHub, как и у других поставщиков инструментов непрерывной интеграции, таких как Travis или Circle, есть система интеграции и автоматизации репозиториев. Простота этой системы по сравнению с другими заключается в том, что вы уже находитесь в одном и том же репозитории и пользуетесь одним и тем же инструментом. Возьмем для автоматизации следующий проект: + мой публичный backend-репозиторий:  Как видите, репозиторий очень прост, в нем немного файлов: docker-compose.yml для локального тестирования и файл mongoke.yml, который станет нашей схемой GraphQL. Наверху страницы, рядом с настройками, есть кнопка «Действия» — именно здесь мы будем настраивать нашу автоматизацию!  В GitHub уже есть ряд готовых рабочих процессов, однако, к сожалению, ни один из них не подходит для решения наших задач. Но что мы хотим сделать? Чтобы было понятнее, перечислим все этапы процесса: Нужно понимать некоторые вещи: Во-первых, давайте решим вопрос с зависимостями: простейшая зависимость, которую нам предстоит решить, заключается в создании URL-адреса MongoDB в качестве секрета. Для этого перейдем на вкладку «Настройки» и нажмем «Секреты». Просто добавьте новый секрет, щелкнув ссылку «Добавить новый секрет» и указав его имя и содержимое. Если мы добавляем URI MongoDB, секрет будет называться MONGODB_URI.  Чтобы разрешить GitHub выполнять действия от нашего имени в Azure, потребуется создать Service Principal. Благодаря этой функции мы получаем учетную запись приложения и возможность разрешить другим людям или службам подключаться к нашему порталу и выполнять действия от нашего имени. Для создания этой функции мы воспользуемся Azure CLI. Выполнив вход в систему с помощью команды az login, просто выполните следующую команду: Чтобы получить ID подписки, просто выполните команду az account list и найдите ключ идентификатора подписки: ключ isDefault должен иметь значение true. Кроме того, вы можете присвоить основной службе любое имя, сделав его описательным: так все будут знать, кому вы предоставляете разрешения. Еще один важный момент: следует предоставлять разрешения только необходимым ресурсам, то есть создавать хранимую процедуру не для ВСЕЙ учетной записи, а только для нужной группы Resource Group. В моем случае эта группа ресурсов называется «личный веб-сайт», именно там я группирую все связанные с моим веб-сайтом ресурсы. Эта команда должна давать ответ в формате JSON типа: Копируйте весь ответ и создайте новый секрет GitHub с именем AZURE_CREDENTIALS:  Теперь у нас должно быть два секрета:  Чтобы создать свой первый рабочий процесс, просто вернитесь на панель «Действия» рядом с разделом «Настройки» и нажмите кнопку «Настроить этот рабочий процесс»:  Выполнив это действие, вы перейдете на новый экран с первоначальной моделью кода:  Помните, что GitHub Actions — это не что иное, как YAML-файл в папке /.Github/workflows. Так будет называться наш рабочий процесс, так что это имя должно быть максимально описательным. Давайте назовем наш файл publish-prod.yml:
  У нас есть следующее содержимое:  Сначала давайте присвоим имя нашему рабочему процессу — это имя будет отображаться в пользовательском интерфейсе GitHub, так что сделаем его максимально простым:  А сейчас давайте определим, какие действия он должен выполнять. Так как мы хотим, чтобы рабочий процесс запускался при любом push или запросе на вывод в главной ветке, мы не будем вносить никаких изменений, но если бы нам нужно было изменить это действие, нам пришлось бы изменить переключатель включения. Чтобы проверить доступные действия, просто щелкните редактор и нажмите ВВОД, отобразятся следующие данные intellisense:  Итак, мы создадим раздел для обмена переменными среды и содержимым, которые будут использоваться в клиентской части нашего скрипта, например имя контейнера и имя группы ресурсов. Для этого мы создали блок 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 Developer Advocate