Развертывание DevOps для приложений логики уровня "Стандартный" в Azure Logic Apps с одиночным клиентом

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

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

В этой статье приведены вводные и общие сведения о текущих возможностях непрерывной интеграции и непрерывного развертывания (CI/CD) для рабочих процессов стандартных логических приложений в однопользовательской среде Azure Logic Apps.

Одноарендное против многоарендного

В мультиарендной среде Azure Logic Apps развертывание ресурсов основано на шаблонах Azure Resource Manager (шаблоны ARM), которые объединяют и обрабатывают обеспечение ресурсами как для ресурсов логического приложения на основе потребления, так и для инфраструктуры. В однопользовательских Azure Logic Apps развертывание становится проще, так как можно разделить подготовку ресурсов между ресурсами логических приложений стандартного уровня и инфраструктурой.

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

Например, можно упаковать переработанную контейнеризованную среду выполнения и рабочие процессы вместе в рамках приложения Standard Logic Apps. Можно использовать общие шаги или задачи, которые создают, собирают и архивируют ресурсы приложения логики в готовые к развертыванию артефакты. Чтобы развернуть приложения логики уровня "Стандартный", скопируйте артефакты в хост-среду, а затем запустите их для выполнения рабочих потоков. Или интегрируйте артефакты в конвейеры развертывания с помощью уже знакомых и ранее использованных средств и процессов. Например, если для вашего сценария требуются контейнеры, можно контейнеризировать логические приложения стандарта и интегрировать их в существующие конвейеры.

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

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

Возможности развертывания DevOps

Azure Logic Apps с одним клиентом наследует множество возможностей и преимуществ от платформы Функций Azure и экосистемы Службы приложений Azure. Эти обновления включают в себя совершенно новую модель развертывания и другие способы использования DevOps для рабочих процессов приложения логики.

Локальная разработка и тестирование

При использовании Visual Studio Code с расширением Azure Logic Apps (standard) можно локально разрабатывать, создавать и запускать рабочие процессы приложения логики уровня "Стандартный" в среде разработки без необходимости развертывания в Azure. Если для вашего сценария требуется локальное развертывание с помощью инфраструктуры, которую вы управляете, см. статью "Создание рабочих процессов приложения логики уровня "Стандартный" для гибридного развертывания в собственной инфраструктуре.

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

Отдельные проблемы

Модель с одним клиентом позволяет разделить проблемы между приложением логики и базовой инфраструктурой. Например, вы можете разрабатывать, создавать, архивировать и развертывать ваше приложение отдельно как неизменный артефакт в разных средах. Рабочие процессы приложения логики обычно имеют "код приложения", который часто обновляется, чем базовая инфраструктура. Разделив эти уровни, вы можете сосредоточиться на создании рабочего процесса приложения логики и тратить меньше усилий на развертывание необходимых ресурсов в нескольких средах.

Структура ресурсов приложения логики

В модели Azure Logic Apps с несколькими клиентами структура ресурсов приложения логики потребления может включать только один рабочий процесс. Из-за этой связи "один к одному" приложение логики и рабочий процесс часто рассматриваются и упоминаются как синонимы. Однако в модели однопользовательских Azure Logic Apps структура ресурса логического приложения Standard может включать несколько рабочих процессов. Эта связь "один ко многим" означает, что в одном приложении логики рабочие процессы могут совместно использовать и повторно использовать другие ресурсы. Рабочие процессы в одном Logic App и тенанте также обеспечивают повышенную производительность благодаря общей инфраструктуре и их близости. Эта структура ресурсов выглядит и работает аналогично функциям Azure, где приложение-функция может размещать множество функций.

Дополнительные сведения и рекомендации по организации рабочих процессов, производительности и масштабирования в приложении логики см. в аналогичном руководстве по функциям Azure , которые обычно можно применять к Azure Logic Apps с одним клиентом.

Структура проекта приложения логики

В Visual Studio Code ваш проект приложения логики может относиться к одному из следующих типов:

• На основе пакета расширений (Node.js) — это тип по умолчанию
• На основе пакета NuGet (.NET) — его можно преобразовать из типа по умолчанию

На основе этих типов проект может включать несколько разных папок или файлов. Например, проект на основе пакетов Nuget содержит папку .bin , содержащую пакеты и другие файлы библиотеки. Проект на основе пакета расширений не включает эту папку .bin .

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

Проект пакета расширений по умолчанию имеет папку и структуру файлов, аналогичную следующему примеру:

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

На корневом уровне проекта можно найти следующие папки и файлы вместе с другими элементами:

Контейнерное развертывание

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

Для примеров с использованием Azure DevOps просмотрите CI/CD для контейнеров.

Настройки и параметры приложения

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

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

Управляемые соединители и встроенные операции

Экосистема Azure Logic Apps предоставляет более 1000 управляемых корпорацией Майкрософт и размещенных в Azure соединителей ивстроенных операций в рамках постоянно растущей коллекции, которую можно использовать в Azure Logic Apps с одним клиентом. Таким образом, корпорация Майкрософт поддерживает управляемые соединители примерно одинаково как в одном клиенте Azure Logic Apps, так и в мультитенантных Azure Logic Apps.

Самое значительное улучшение заключается в том, что служба с одним клиентом делает более популярными управляемые соединители доступными как встроенные операции. Например, можно использовать встроенные операции для служебной шины Azure, Центров событий Azure, SQL и многих других. В то же время версии управляемых соединителей по-прежнему доступны и продолжают работать.

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

В Visual Studio Code при разработке или внесении изменений в рабочие процессы подсистема Azure Logic Apps с одним клиентом автоматически создает все необходимые метаданные подключения в файлеconnections.json проекта. В следующих разделах описаны три типа подключений, которые можно создать в рабочих процессах. Каждый тип подключения имеет другую структуру JSON, что важно понимать, так как конечные точки изменяются при перемещении между средами.

Подключения поставщика услуг

При использовании встроенной операции для сервисов, таких как Azure Service Bus или Azure Event Hubs, в средах однотенантных приложений Azure Logic, вы создаёте подключение к поставщику услуг, которое выполняется в том же процессе, что и ваш рабочий процесс. Эта инфраструктура подключения размещается и управляется как часть ресурса приложения логики, а параметры приложения хранят строки подключения для любой встроенной операции поставщика услуг, используемой рабочими процессами.

В проекте логического приложения "Стандартный" каждый из рабочих процессов имеет файлworkflow.json, содержащий базовое определение JSON рабочего процесса. Затем это определение рабочего процесса ссылается на необходимые строки подключения в connections.json файле проекта.

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

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

Управляемые подключения

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

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

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

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

Подключения к функциям Azure

Для вызова функций, созданных и размещенных в Функциях Azure, используйте встроенную операцию Функций Azure. Метаданные подключения для вызовов Функций Azure отличаются от других встроенных подключений. Эти метаданные хранятся в файле connections.json проекта приложения логики, но выглядят иначе:

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

Authentication

В Azure Logic Apps с одним клиентом модель размещения для рабочих процессов приложений логики — это один клиент Microsoft Entra, где рабочие нагрузки получают больше изоляции, чем в мультитенантной модели. Кроме того, среда выполнения Azure Logic Apps с одним клиентом переносима, что означает, что рабочие процессы можно запускать в других средах, например локально в Visual Studio Code. Тем не менее, эта конструкция требует способа проверки подлинности приложений логики, чтобы они могли получить доступ к экосистеме управляемых соединителей в Azure. Приложения также нуждаются в правильных разрешениях для выполнения операций при использовании управляемых подключений.

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

В следующих разделах содержатся дополнительные сведения о типах проверки подлинности, которые можно использовать для проверки подлинности управляемых подключений в зависимости от того, где выполняется приложение логики. Для каждого управляемого подключения файлconnections.json проекта приложения логики имеет authentication объект, указывающий тип проверки подлинности, который приложение логики может использовать для проверки подлинности этого управляемого подключения.

Манажируемая идентичность

Для приложения логики, размещенного и запускаемого в Azure, управляемое удостоверение — это стандартный и рекомендуемый тип проверки подлинности для проверки подлинности управляемых подключений, размещенных и работающих в Azure. В файле connections.json проекта приложения логики объект управляемого подключения указывает authenticationManagedServiceIdentity как тип проверки подлинности.

"authentication": {
   "type": "ManagedServiceIdentity"
}

Raw

Для приложений логики, работающих в локальной среде разработки с помощью Visual Studio Code, для проверки подлинности управляемых подключений, размещенных и работающих в Azure, используются необработанные ключи проверки подлинности. Эти ключи предназначены только для разработки и не подходят для производственной среды; срок действия составляет 7 дней. В файле connections.json проекта приложения логики управляемое подключение имеет объект authentication, который указывает следующую информацию для проверки подлинности:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

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

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