Развертывание 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.
Например, можно упаковать измененную контейнерную среду выполнения и рабочие процессы вместе в рамках приложения логики "Стандартный". Можно использовать общие шаги или задачи, которые создают, собирают и архивируют ресурсы приложения логики в готовые к развертыванию артефакты. Чтобы развернуть приложения логики уровня "Стандартный", скопируйте артефакты в среду узла, а затем запустите приложения для запуска рабочих процессов. Или интегрируйте артефакты в конвейеры развертывания с помощью уже знакомых и ранее использованных средств и процессов. Например, если для вашего сценария требуются контейнеры, можно контейнеризировать приложения логики "Стандартный" и интегрировать их в существующие конвейеры.
Чтобы настроить и развернуть ресурсы инфраструктуры, такие как виртуальные сети и возможности подключения, можно продолжить использование шаблонов ARM и отдельно подготавливать эти ресурсы с другими процессами и конвейерами, которые используются в этих целях.
Используя стандартные параметры сборки и развертывания, можно сосредоточиться на разработке приложений отдельно от развертывания инфраструктуры. В результате можно получить более общую модель проекта, в которой можно применять множество аналогичных или тех же параметров развертывания, которые используются для общего приложения. Также можно воспользоваться более согласованным взаимодействием для создания конвейеров развертывания для проектов приложений, а также выполнения необходимых тестов и проверок перед публикацией в рабочей среде. Независимо от используемого комплекса технологий можно развертывать приложения логики, используя собственные выбранные инструменты.
Возможности развертывания DevOps
Azure Logic Apps с одним клиентом наследует многие возможности и преимущества платформы Функции Azure и экосистемы Служба приложений Azure. Эти обновления включают в себя совершенно новую модель развертывания и другие способы использования DevOps для рабочих процессов приложения логики.
Локальная разработка и тестирование
При использовании Visual Studio Code с расширением Azure Logic Apps (standard) можно локально разрабатывать, создавать и запускать рабочие процессы приложения логики уровня "Стандартный" в среде разработки без необходимости развертывания в Azure. Если для вашего сценария требуются контейнеры, их можно создать и развернуть с помощью Logic Apps с поддержкой Azure Arc.
Эта возможность предоставляет собой значительное улучшение и обеспечивает существенное преимущество по сравнению с моделью с несколькими клиентами, где требуется разработка на основе существующего и работающего ресурса в Azure.
Отдельные проблемы
Модель с одним клиентом позволяет разделить проблемы между приложением логики и базовой инфраструктурой. Например, можно разрабатывать, собирать, архивировать и развертывать приложения отдельно как неизменяемый артефакт в разных средах. Рабочие процессы приложения логики, как правило, содержат "код приложения", который обновляется чаще, чем базовая инфраструктура. Разделив эти слои, можно сосредоточиться на построении рабочего процесса приложения логики и тратить меньше усилий на развертывание необходимых ресурсов в нескольких средах.
Структура ресурсов приложения логики
В модели Azure Logic Apps с несколькими клиентами структура ресурсов приложения логики потребления может включать только один рабочий процесс. Из-за подобной связи "один к одному" приложение логики и рабочий процесс нередко рассматриваются, как одно и то же. Однако в модели Azure Logic Apps с одним клиентом структура ресурсов приложения логики "Стандартный" может включать несколько рабочих процессов. Связь "один ко многим" означает, что в рамках одного приложения логики рабочие процессы могут сообща использовать одни и те же ресурсы. Кроме того, благодаря общей клиентской модели и близкому расположению друг к другу рабочие процессы в одном приложении логики и у одного клиента отличаются более высокой производительностью. Такая структура ресурсов выглядит и работает так же, как Функции Azure, где приложение-функция может поддерживать сразу множество функций.
Дополнительные сведения и рекомендации по управлению рабочими процессами, оптимизации и масштабированию в приложении логики вы найдете в руководстве по Функциям Azure, которое также актуально и для Azure Logic Apps с одним клиентом.
Структура проекта приложения логики
В Visual Studio Code ваш проект приложения логики может относиться к одному из следующих типов:
- На основе пакета расширений (Node.js) — это тип по умолчанию
- На основе пакета NuGet (.NET) — его можно преобразовать из типа по умолчанию
От этих типов зависит, какие папки и файлы содержатся в вашем проекте. Проект на основе NuGet включает папку .bin, которая содержит пакеты и другие файлы библиотеки. Проект на основе пакета расширений не включает папку. bin и другие файлы. В некоторых сценариях для выполнения вашего приложения требуется проект на основе NuGet, когда вы, к примеру, хотите разрабатывать и выполнять пользовательские встроенные операции. Подробнее о преобразовании своего проекта на использование NuGet см. в разделе Включение создания встроенных соединителей.
В случае с типом по умолчанию на основе пакета расширений ваш проект включает папку и структуру файлов наподобие примера ниже:
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
На корневом уровне проекта вы найдете следующие файлы и папки:
| Имя. | Папка или файл | Description |
|---|---|---|
| .vscode | Папка | Содержит файлы параметров для Visual Studio Code, в том числе файлы extensions.json, launch.json, settings.json и tasks.json files. |
| Артефакты | Папка | Содержит артефакты учетной записи интеграции, которые вы можете определить и использовать в рабочих процессах, поддерживающих сценарии B2B. Например, подобная структура включает карты и схемы для преобразования и проверки XML. |
| <Имя рабочего процесса> | Папка | Для каждого рабочего процесса папка <WorkflowName> включает файл workflow.json, содержащий базовое для этого рабочего процесса определение JSON. |
| workflow-designtime | Папка | Содержит файлы параметров для среды разработки. |
| .funcignore | Файлы | Содержит сведения, касающиеся установленного набора Azure Functions Core Tools. |
| connections.json | Файлы | Содержит метаданные, конечные точки и ключи для всех управляемых подключений и функций Azure, используемых рабочими процессами. Внимание! Чтобы в каждой среде использовать разные подключения и функции, не забудьте параметризовать этот файл connections.json и обновить конечные точки. |
| host.json | Файлы | Содержит параметры конфигурации и значения для среды выполнения, например ограничения по умолчанию для платформы Azure Logic Apps с одним клиентом, приложения логики, рабочие процессы, триггеры и действия. На корневом уровне проекта приложения логики файл метаданных host.json содержит параметры конфигурации и значения по умолчанию, которые используют все рабочие процессы при выполнении, будь то локально или в Azure. Примечание. При создании приложения логики Visual Studio Code создает резервный файл host.snapshot.*.json в контейнере хранилища. Если вы удалите приложение логики, этот файл резервной копии не будет удален. Если создать другое приложение логики с тем же именем, будет создан другой файл моментального снимка. Для одного и того же приложения логики можно использовать до 10 моментальных снимков. Если вы превышаете это ограничение, вы получите следующую ошибку: Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Чтобы устранить эту ошибку, удалите лишние файлы моментальных снимков из контейнера хранилища. |
| local.settings.json | Файлы | Содержит параметры приложения, строки подключения и другие параметры, которые используют ваши рабочие процессы при локальном выполнении. Иными словами, эти параметры и значения применяются только в том случае, когда ваши проекты выполняются в локальной среде разработки. При развертывании в Azure этот файл и параметры игнорируются и не включаются в развертывание. В этом файле параметры и значения хранятся в виде локальных переменных среды, которые используются локальными инструментами разработки в качестве значений appSettings. Вы можете вызывать эти переменные среды и ссылаться на них во время выполнения и развертывания с помощью параметров приложения и других параметров. Внимание! Файл 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 или Центры событий Azure в Azure Logic Apps с одним клиентом, создается подключение поставщика услуг, которое выполняется в том же процессе, что и рабочий процесс. Эта инфраструктура подключения размещается и управляется как часть ресурса приложения логики, а настройки приложения сохраняют строки подключения для любой встроенной операции на основе поставщика услуг, используемой рабочими процессами.
Внимание
Если у вас есть конфиденциальная информация, например строка подключения, включающих имена пользователей и пароли, обязательно используйте самый безопасный поток проверки подлинности. Например, корпорация Майкрософт рекомендует пройти проверку подлинности доступа к ресурсам Azure с управляемым удостоверением при наличии поддержки и назначить роль с минимальными привилегиями.
Если эта возможность недоступна, обязательно защитите строка подключения с помощью других мер, таких как Azure Key Vault, которые можно использовать с параметрами приложения. Потом можно напрямую ссылаться на такие защищенные строки, как строки подключения и ключи. Аналогично шаблонам ARM, где переменные среды определяют в процессе развертывания, настройки приложения можно задать в рамках определения рабочего процесса приложения логики. Затем можно захватывать динамически генерируемые значения инфраструктуры, такие как конечные точки подключения, строки хранения и другие. Дополнительные сведения см. в разделе "Типы приложений" для платформа удостоверений Майкрософт.
В проекте приложения логики "Стандартный" каждый рабочий процесс содержит файл 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}"
},
<...>
}
Проверка подлинности
В Azure Logic Apps с одним клиентом модель размещения для рабочих процессов приложений логики — это один клиент Microsoft Entra, где рабочие нагрузки получают больше изоляции, чем в мультитенантной модели. Кроме того, среда выполнения Azure Logic Apps с одним клиентом является переносимой, что означает возможность запуска рабочих процессов в других средах, например, локально в Visual Studio Code. Тем не менее, эта схема требует, чтобы приложения логики прошли проверку подлинности своих удостоверений для получения доступа к управляемой экосистеме соединителей в Azure. Приложениям также требуются правильные разрешения для выполнения операций при использовании управляемых подключений.
По умолчанию каждое приложение логики на основе одного клиента имеет автоматически включаемое управляемое удостоверение, назначаемое системой. Это удостоверение отличается от учетных данных проверки подлинности или строки подключения, используемой при создании подключения. В среде выполнения приложение логики использует это удостоверение для проверки подлинности подключений с помощью политик доступа Azure. Если отключить это удостоверение, подключения не будут работать в среде выполнения.
В следующих разделах представлены дополнительные сведения о типах проверки подлинности, которые можно использовать для аутентификации управляемых подключений в зависимости от того, где выполняется приложение логики. Для каждого управляемого подключения файл connections.json проекта приложения логики содержит authentication объект, указывающий тип проверки подлинности, который приложение логики может использовать для проверки подлинности этого управляемого подключения.
Управляемое удостоверение
Для приложения логики, размещенного и выполняемого в Azure, управляемое удостоверение является стандартным и рекомендуемым типом проверки подлинности, используемым для проверки подлинности управляемых подключений, которые размещены и выполняются в Azure. В файле connections.json проекта приложения логики у управляемого подключения есть объект, указывающий authentication ManagedServiceIdentity в качестве типа проверки подлинности:
"authentication": {
"type": "ManagedServiceIdentity"
}
Необработанные
Для приложений логики, выполняемых в локальной среде разработки с помощью Visual Studio Code, необработанные ключи проверки подлинности используются для проверки подлинности управляемых подключений, которые размещаются и выполняются в Azure. Эти ключи предназначены только для разработки, а не для рабочей среды и имеют срок действия в течение 7 дней. В файле connections.json проекта приложения логики у управляемого подключения есть authentication объект, указывающий следующие сведения о проверке подлинности:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}