Развертывание 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 (Стандартный) можно локально разрабатывать, собирать и запускать рабочие процессы приложения логики с одним клиентом в среде разработки без необходимости развертывания в 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 предоставляет сотни управляемых Майкрософт соединителей и встроенных операций в рамках постоянно растущей коллекции, которую можно использовать в Azure Logic Apps с одним клиентом. Способ, которым корпорация Майкрософт поддерживает эти соединители и встроенные операции, остается в основном аналогичным в Azure Logic Apps с одним клиентом.

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

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

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

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

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

Внимание

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

Если эта возможность недоступна, обязательно защитите строка подключения с помощью других мер, таких как Azure Key Vault, которые можно использовать с параметрами приложения. Потом можно напрямую ссылаться на такие защищенные строки, как строки подключения и ключи. Аналогично шаблонам ARM, где переменные среды определяют в процессе развертывания, настройки приложения можно задать в рамках определения рабочего процесса приложения логики. Затем можно захватывать динамически генерируемые значения инфраструктуры, такие как конечные точки подключения, строки хранения и другие. Дополнительные сведения см. в разделе "Типы приложений" для платформа удостоверений Майкрософт.

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

В следующем примере показано, как подключение поставщика услуг для встроенной операции Служебной шины отображается в файле 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, пока продолжается процесс создания и разработки рабочего процесса с помощью конструктора, подсистема Logic Apps автоматически создает необходимые ресурсы в Azure для управляемых соединителей в рабочем процессе. Подсистема автоматически добавляет эти ресурсы подключения в группу ресурсов Azure, которая разработана для хранения приложения логики.

В следующем примере показано, как API-подключение для управляемого соединителя Служебной шины отображается в файле 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 с одним клиентом модель размещения для рабочих процессов приложения логики представляет собой одного клиента, где рабочие нагрузки получают преимущество от большей изоляции, чем в модели с несколькими клиентами. Кроме того, среда выполнения 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')"
 }

Следующие шаги

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