Автоматизировать развертывание DevOps для проектов стандартных приложений логики из Visual Studio Code в Azure Logic Apps

Область применения: Azure Logic Apps (стандартная версия)

В этом руководстве основное внимание уделяется тому, как настроить развертывание для проекта логического приложения типа "Стандартный" из Visual Studio Code в вашу инфраструктуру с помощью средств и процессов DevOps. Если ваше логическое приложение уровня Standard существует в портале Azure, вы можете скачать файлы артефактов вашего приложения для развертывания через DevOps. В зависимости от того, хотите ли вы использовать GitHub или Azure DevOps, выберите путь и средства, которые лучше всего работают в сценарии развертывания.

Если у вас нет стандартного приложения логики, вы по-прежнему можете следовать этому руководству с помощью связанных примеров проектов приложения логики "Стандартный" и примеров развертывания в Azure через GitHub или Azure DevOps. Дополнительные сведения см. в обзоре развертывания DevOps для Azure Logic Apps с одним клиентом.

Предварительные условия

• Учетная запись Azure с активной подпиской. Если у вас еще нет подписки Azure, создайте бесплатную учетную запись.

• Visual Studio Code, который является бесплатным, расширение Azure Logic Apps (standard) для Visual Studio Code и другие связанные предварительные требования.

• Стандартное логическое приложение для использования с вашими инструментами и процессами DevOps.

  Вы можете либо скачать файлы артефактов для ресурса приложения логики уровня "Стандартный" из портала Azure, либо использовать проект приложения логики Уровня "Стандартный", созданный в Visual Studio Code с расширением Azure Logic Apps (Standard) для Visual Studio Code.

  • Портал: Скачанный ZIP-файл содержит файлы артефактов стандартного приложения логики, такие как workflow.json, connections.json, host.json и local.settings.json. См. статью "Скачать файлы артефактов приложения логики «Стандартный» с портала".

  • Visual Studio Code: вам нужен пустой ресурс логического приложения уровня "Стандартный" в портале Azure для назначения развертывания. Чтобы быстро создать пустой ресурс приложения логики уровня "Стандартный", см. статью "Создание рабочих процессов приложения логики на основе одного клиента" на портале.

  Если у вас нет существующего логического приложения или инфраструктуры, вы можете использовать связанный пример проектов Standard logic для развертывания примера логического приложения и инфраструктуры, исходя из того, хотите ли вы использовать GitHub или Azure DevOps. Дополнительные сведения о включенных примерах проектов и ресурсов для запуска примера приложения логики см. в разделе "Развертывание ресурсов инфраструктуры".

Развертывание ресурсов инфраструктуры

Чтобы попробовать внедрение DevOps без предварительной настройки стандартного логического приложения или инфраструктуры, используйте следующие примеры проектов, чтобы настроить развертывание для примера приложения Standard Logic и инфраструктуры, исходя из того, хотите ли вы использовать GitHub или Azure DevOps:

• Пример использования GitHub для службы Azure Logic Apps с одним клиентом

  В этом примере содержится проект логического приложения уровня "Стандартный" и примеры развёртывания для Azure и GitHub Actions.

• Пример использования Azure DevOps для службы Azure Logic Apps с одним клиентом

  В этом примере представлен проект стандартного логического приложения, а также примеры развертывания в Azure и Azure Pipelines.

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

Ресурсы подключения API и политики доступа

В Azure Logic Apps с одним клиентом каждый ресурс подключения к управляемому API в рабочем процессе требует связанной политики доступа. Эта политика требует идентификатора вашего логического приложения для предоставления корректных разрешений доступа к управляемой инфраструктуре соединителя. Прилагаемые образцы проектов включают шаблон ARM, содержащий все необходимые ресурсы инфраструктуры, в том числе эти политики доступа.

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

Скачивание артефактов логического приложения «Стандартный» с портала

Если ваше приложение логики Standard находится в портале Azure, вы можете скачать ZIP-файл, содержащий файлы артефактов вашего приложения логики, включая workflow.json, connections.json, host.json и local.settings.json.

1. В портале Azure найдите и откройте ресурс стандартного логического приложения.

2. В меню приложения логики выберите Overview (Обзор).

3. На панели инструментов "Обзор" выберите "Скачать содержимое приложения". В появившемся поле подтверждения нажмите кнопку "Скачать".

4. Когда появится запрос, выберите "Сохранить как", перейдите к нужной локальной папке и нажмите кнопку "Сохранить ", чтобы сохранить ZIP-файл.

5. Извлеките ZIP-файл.

6. В Visual Studio Code откройте папку, содержащую распакуированные файлы.

   При открытии папки Visual Studio Code автоматически создает рабочую область.

7. Измените содержимое папки, чтобы включить только папки и файлы, необходимые для развертывания с помощью DevOps.

8. По завершении сохраните изменения.

Создание и развертывание логического приложения (zip-развертывание)

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

Создайте ваш проект

1. Отправьте проект приложения логики уровня "Стандартный" и файлы артефактов в исходный репозиторий, например GitHub или Azure DevOps.

2. Настройте конвейер сборки на основе типа проекта приложения логики, выполнив следующие соответствующие действия:

   Тип проекта	Описание и действия
   На основе NuGet	Структура проекта с использованием NuGet основана на платформе .NET Framework. Для сборки этих проектов обязательно выполните этапы сборки .NET Standard. Дополнительные сведения см. в статье "Создание пакета NuGet с помощью MSBuild".
   На основе комплекта	Проект на основе набора расширений не зависит от языка и не требует каких-либо действий по сборке, зависящих от языка.

3. Запакуйте файлы проекта с помощью любого нужного метода.

   Внимание

   Убедитесь, что ZIP-файл содержит фактические артефакты сборки проекта на корневом уровне, включая все папки рабочего процесса, файлы конфигурации, такие как host.json, connections.json, local.settings.json и другие связанные файлы. Не добавляйте дополнительные папки и не помещайте артефакты в папки, которые до этого отсутствовали в структуре проекта.

   Например, в следующем списке показан пример структуры файлов MyBuildArtifacts.zip :

   MyStatefulWorkflow1-Folder
   MyStatefulWorkflow2-Folder
   connections.json
   host.json
   local.settings.json
   

Перед выпуском в Azure

Управляемые подключения API в файле connections.json проекта приложения логики создаются непосредственно для локального использования в Visual Studio Code. Прежде чем вы сможете освободить артефакты проекта из Visual Studio Code в Azure, необходимо обновить эти артефакты. Для использования управляемых подключений API в Azure необходимо обновить их методы проверки подлинности, чтобы они имели правильный формат для использования в Azure.

Обновление типа проверки подлинности

Для каждого управляемого подключения API, использующего проверку подлинности, необходимо обновить authentication объект из локального формата в Visual Studio Code в формате портал Azure, как показано в первом и втором примерах кода соответственно:

Формат Visual Studio Code

{
   "managedApiConnections": {
      "sql": {
         "api": {
            "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/westus/managedApis/sql"
         },
         "connection": {
            "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ase/providers/Microsoft.Web/connections/sql-2"
         },
         "connectionRuntimeUrl": "https://xxxxxxxxxxxxxx.01.common.logic-westus.azure-apihub.net/apim/sql/xxxxxxxxxxxxxxxxxxxxxxxxx/",
         "authentication": {
            "type": "Raw",
            "scheme": "Key",
            "parameter": "@appsetting('sql-connectionKey')"
         }
      }
   }
}

Формат портала Azure

{
   "managedApiConnections": {
      "sql": {
         "api": {
            "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/westus/managedApis/sql"
         },
         "connection": {
            "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ase/providers/Microsoft.Web/connections/sql-2"
         },
         "connectionRuntimeUrl": "https://xxxxxxxxxxxxxx.01.common.logic-westus.azure-apihub.net/apim/sql/xxxxxxxxxxxxxxxxxxxxxxxxx/",
         "authentication": {
            "type": "ManagedServiceIdentity"
         }
      }
   }
}

Создание подключений API по мере необходимости

Если вы развертываете приложение логики уровня "Стандартный" в регионе Azure или подписке, отличной от локальной среды разработки, перед развертыванием необходимо также создать эти управляемые подключения API. Самый простой способ создания управляемых подключений API — развертывание шаблона Azure Resource Manager (шаблона ARM).

В следующем примере показано определение ресурса подключения API, управляемого SQL, в шаблоне ARM:

{
   "type": "Microsoft.Web/connections",
   "apiVersion": "2016–06–01",
   "location": "[parameters('location')]",
   "name": "[parameters('connectionName')]",
   "properties": {
      "displayName": "sqltestconnector",
      "api": {
         "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/sql"
      },
      "parameterValues": {
         "authType": "windows", 
         "database": "TestDB",
         "password": "TestPassword",
         "server": "TestServer",
         "username": "TestUserName"
      }
   }
}

Чтобы найти необходимые значения для properties объекта, чтобы завершить определение ресурса подключения, используйте следующий API для определенного соединителя:

GET https://management.azure.com/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/{connector-name}?api-version=2016-06-01

В ответе найдите connectionParameters объект, содержащий необходимые сведения для завершения определения ресурса для этого конкретного соединителя. Далее приведен пример определения ресурса для управляемого подключения SQL:

{
   "type": "Microsoft.Web/connections",
   "apiVersion": "2016–06–01",
   "location": "[parameters('location')]",
   "name": "[parameters('connectionName')]",
   "properties": {
      "displayName": "sqltestconnector",
      "api": {
         "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/sql"
      },
      "parameterValues": {
         "authType": "windows",
         "database": "TestDB",
         "password": "TestPassword",
         "server": "TestServer",
         "username": "TestUserName"
      }
   }
}

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

Определение ресурсов локального шлюза данных

Если подключение использует локальный ресурс шлюза данных, это определение ресурса существует отдельно от определения ресурса соединителя. Сведения об определении ресурсов шлюза данных см. в статье "Автоматизация развертывания для Azure Logic Apps" с помощью шаблонов Azure Resource Manager и Microsoft.Web connectionGateways.

Выпуск в Azure

Чтобы настроить конвейер выпуска, развертываемого в Azure, выполните соответствующие шаги для GitHub, Azure DevOps или Azure CLI.

- name: 'Run Azure Functions Action'
  uses: Azure/functions-action@v1
  id: fa
  with:
   app-name: 'MyLogicAppName'
   package: 'MyBuildArtifact.zip'
   publish-profile: 'MyLogicAppPublishProfile'

- task: AzureFunctionApp@2
  displayName: 'Deploy logic app workflows'
  inputs:
     azureSubscription: 'MyServiceConnection'
     appType: 'functionAppLinux' ## Default: functionApp 
     appName: 'MyLogicAppName'
     package: 'MyBuildArtifact.zip'
     deploymentMethod: 'zipDeploy'
     appSettings: '-SettingName1 SettingValue1 -SettingName2 SettingValue2'

appSettings: '-AzureWebJobsStorage $(StorageConnectionString) -WORKFLOWS_SUBSCRIPTION_ID $(SubscriptionId)'

az extension add --yes --source "https://aka.ms/logicapp-latest-py2.py3-none-any.whl"

az extension remove --name logicapp
az extension add --yes --source "https://aka.ms/logicapp-latest-py2.py3-none-any.whl"

az group create --name MyResourceGroupName 
   --subscription MySubscription 
   --location eastus

<...>
   "name": "testResourceGroup",
   "properties": {
      "provisioningState": "Succeeded"
    },
<...>

az logicapp deployment source config-zip --name MyLogicAppName 
   --resource-group MyResourceGroupName --subscription MySubscription 
   --src MyBuildArtifact.zip

После развертывания в Azure

У каждого подключения API есть политики доступа. После завершения развертывания ZIP необходимо открыть ресурс приложения логики стандартного уровня в портале Azure и создать политики доступа для каждого подключения API, чтобы настроить разрешения для развернутой логической программы.

Для параметров приложения есть два варианта:

• Развертывание пайплайна (рекомендуется): используйте параметр appSettings в задаче Azure Function App Deploy для Azure DevOps или эквивалентную конфигурацию в GitHub Actions, чтобы автоматически создавать настройки приложения во время развертывания. Дополнительные сведения см. в примерах развертывания в предыдущих разделах.

• Настройка вручную. Создайте параметры приложения вручную на портале Azure после развертывания на основе файла local.settings.json в проекте приложения логики.

Связанный контент

• Развертывание DevOps для службы Azure Logic Apps с одним клиентом

Мы хотели бы узнать о вашем опыте работы со службой Azure Logic Apps с одним клиентом!

• При возникновении ошибок или проблем опубликуйте свою проблему на портале GitHub.
• Для вопросов, запросов, комментариев и других отзывов используйте эту форму обратной связи.