Развертывание приложений Azure Logic Apps в виде кода

В последнее время я сам играл с приложениями Azure Logic Apps, и мне стало интересно, как ими могут управлять команды в корпоративной среде, особенно как можно автоматизировать инициализацию и развертывание приложений Logic Apps.

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

Представление контекста

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

  • Аккаунт хранилища
  • Таблица в аккаунте хранилища
  • Логическое приложение, запускаемое по HTTP: каждый запрос будет добавлять строку в таблицу хранилища с IP-адресом вызывающей стороны.

Следующая диаграмма показывает, что мы собираемся здесь создать

Репозиторий GitHub

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

Репозиторий содержит полный код IaC в Bicep и Terraform, в этом посте я покажу наиболее важные части в Bicep только для наглядности (а также потому, что в Terraform все немного сложнее, подробнее об этом позже).

Создание базовых ресурсов

Для начала мы создадим все ресурсы, кроме самого Logic App. Если вы не знакомы с Bicep, это поможет понять остальную часть кода, в противном случае вы можете перейти к следующему разделу.

Обратите внимание, что моя концепция именования состоит из одинакового суффикса в именах всех ресурсов (со случайной частью для обеспечения единства имени) и префикса в зависимости от типа ресурса.

Вы можете использовать эту страницу из Cloud Adoption Framework в качестве справочника по сокращениям для типов ресурсов Azure.

Эта периодическая таблица типов ресурсов Azure также довольно интересна.

Я новичок в Bicep, но уже привык создавать модуль main.bicep, содержащий развертывание подписки для создания группы ресурсов, и модуль resources.bicep, содержащий развертывание группы ресурсов.

Здесь я сосредоточусь на модуле resources.bicep, вот начало модуля с созданием учетной записи хранения и таблицы хранения:

@description('The suffix to use in resource naming.')
param suffix string
param location string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: substring('stor${replace(suffix, '-', '')}', 0, 24)
  location: location

  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

resource tableStorageService 'Microsoft.Storage/storageAccounts/tableServices@2021-09-01' = {
  name: 'default'
  parent: storageAccount
}

resource storageTable 'Microsoft.Storage/storageAccounts/tableServices/tables@2021-09-01' = {
  name: 'logicAppCalls'
  parent: tableStorageService
}
Вход в полноэкранный режим Выход из полноэкранного режима

Создание API-соединения

Для взаимодействия с ресурсом или службой приложению Logic App требуется API-соединение, которое, по сути, является оберткой вокруг API, в нашем случае API хранилища таблиц Azure.

Это один из ключевых этапов данной статьи, поскольку подключение к службе содержит способ аутентификации Logic App к учетной записи хранилища. Я мог бы использовать ключ учетной записи, но решил использовать управляемую идентификацию, чтобы следовать лучшим практикам (эта статья очень помогла мне сделать эту часть работы).

Короче говоря, хитрость с управляемой идентификацией заключается в использовании версии API 2018-07-01-preview типа ресурса Microsoft.Web/connections. Из-за этого Bicep выдаст предупреждение, но на данный момент это единственный способ заставить его работать:

resource tableStorageConnection 'Microsoft.Web/connections@2018-07-01-preview' = {
  name: 'tableStorage'
  location: location

  properties: {
    parameterValueSet: {
      name: 'managedIdentityAuth'
      values: {}
    }
    api: {
      id: '${subscription().id}/providers/Microsoft.Web/locations/${location}/managedApis/azuretables'
    }
  }
}
Войти в полноэкранный режим Выйти из полноэкранного режима

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

Почему Logic Apps отличаются?

Прежде чем перейти к более подробному коду IaC, давайте поговорим о том, как команды могут управлять (разрабатывать, версировать и развертывать) Logic Apps и почему они отличаются от других ресурсов Azure, таких как Web Apps или Azure Functions.

Функции и веб-приложения — это службы, основанные на коде, развертывание которых требует двух шагов:

  1. этап инициализации для создания ресурса в Azure (с помощью IaC, CLI, портала, …).
  2. Шаг развертывания для размещения бизнес-кода на ресурсе (с помощью CD pipeline, VS Code, git push, …).

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

Кроме того, развертывание новой версии бизнес-кода не отражает никаких изменений в инфраструктуре.

Logic apps — это сервис, ориентированный на проектирование, обычно вы проектируете рабочий процесс в графическом интерфейсе (например, на портале Azure), и он сохраняется в «коде» JSON, привязанном к ресурсу Azure.

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

Другими словами, «код» или «логику» Logic Apps нельзя развернуть отдельно от создания самого ресурса.

Давайте теперь разработаем/развернем это Logic App навсегда!

Итак, как мы можем разрабатывать логические приложения с помощью графического интерфейса и автоматизировать их развертывание с помощью IaC?

Вот что у меня получилось на портале Azure после завершения «разработки» моего Logic App:
Аналогичный опыт можно получить, используя расширение VS Code

Переключение на представление Code позволяет мне увидеть мой рабочий процесс в JSON. Оттуда я могу скопировать элемент definition и сохранить его содержимое в файл в моем репозитории.

Почему бы не взять все содержимое представления кода? Потому что элемент parameters содержит идентификатор ресурса API соединения (с идентификатором подписки и именем группы ресурсов) и имя Storage Account, а я не хочу, чтобы такая информация, связанная с окружением, попала в мой git-репозиторий.

Теперь, когда моя логика сохранена (и версионирована) вместе с кодом IaC, я могу использовать ее в свойстве definition рабочего процесса Logic App (используя встроенную функцию loadJsonContent):

resource logicApp 'Microsoft.Logic/workflows@2019-05-01' = {
  name: 'ala-${suffix}'
  location: location

  identity: {
    type: 'SystemAssigned'
  }

  properties: {
    definition: loadJsonContent('../logic_apps/insertIntoTableStorage.json')
    parameters: {
      '$connections': {
        value: {
          '${connectionApiName}': {
            connectionId: tableStorageConnection.id
            connectionName: connectionApiName
            id: '${subscription().id}/providers/Microsoft.Web/locations/${location}/managedApis/${connectionApiName}'
            connectionProperties: {
              authentication: {
                type: 'ManagedServiceIdentity'
              }
            }
          }
        }
      }
      storageAccountName: {
        value: storageAccount.name
      }
    }
  }
}
Вход в полноэкранный режим Выход из полноэкранного режима

Осталось только предоставить Logic App доступ к учетной записи хранилища с помощью назначения встроенной роли Storage Table Data Contributor. Это можно увидеть здесь в репозитории.

Наконец, все можно развернуть с помощью простой команды az deployment sub create.

Что насчет Terraform?

Как упоминалось ранее, этот небольшой демонстрационный проект был сделан в Bicep и Terraform, но в итоге я оставил в блоге только версию Bicep. Это сделано из соображений ясности, а также потому, что работа с Terraform имеет следующие недостатки:

  1. В провайдере AzureRM Terraform нет поддержки API-соединений, поэтому мне пришлось создать шаблон ARM и вызвать его в коде Terraform для создания API-соединения.
  2. Рабочий процесс Logic App можно создать с помощью ресурса logic_app_workflow провайдера AzureRM, но он не предоставляет возможности задать определение рабочего процесса. Решение заключалось в использовании этого ресурса для создания рабочего процесса (с управляемой идентификацией для последующего назначения ролей), а затем другого файла шаблона ARM для развертывания определения Logic App из кода Terraform.

Подведение итогов

В этом посте показан способ сделать первый шаг в управлении Logic Apps в масштабе.

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

Надеюсь, этот пост поможет вам вывести ваши Logic Apps на новый уровень, не стесняйтесь, обращайтесь, если что, и спасибо, что прочитали 🤓.

Оцените статью
devanswers.ru
Добавить комментарий