단일 테넌트 Azure Logic Apps의 표준 논리 앱에 대한 DevOps 배포

아티클
10/23/2024

적용 대상: Azure Logic Apps(표준)

분산 및 네이티브 클라우드 앱을 점점 더 많이 사용하게 되면서 조직은 더 많은 환경에서 더 많은 분산 구성 요소를 처리하게 되었습니다. 제어 및 일관성을 유지하기 위해 DevOps 도구 및 프로세스를 사용하여 환경을 자동화하고 더 많은 구성 요소를 더 빠르고 안정적으로 배포할 수 있습니다.

이 문서에서는 단일 테넌트 Azure Logic Apps의 표준 논리 앱 워크플로에 대한 현재 CI/CD(연속 통합 및 지속적인 배포) 환경에 대한 소개 및 개요를 제공합니다.

단일 테넌트 대 다중 테넌트

다중 테넌트 Azure Logic Apps에서 리소스 배포는 ARM 템플릿(Azure Resource Manager 템플릿)을 기반으로 하며, 소비 논리 앱 리소스와 인프라 모두에 대한 리소스 프로비저닝을 결합하고 처리합니다. 단일 테넌트 Azure Logic Apps에서는 표준 논리 앱 리소스와 인프라 간에 리소스 프로비저닝을 구분할 수 있으므로 배포가 더 쉬워집니다.

표준 논리 앱 리소스를 만들 때 워크플로는 다시 디자인된 단일 테넌트 Azure Logic Apps 런타임에 의해 구동됩니다. 이 런타임은 Azure Functions 확장성 모델 확장성을 사용하며 Azure Functions 런타임에 확장으로 호스트됩니다. 이 디자인은 표준 논리 앱의 이식성, 유연성 및 성능과 Azure Functions 플랫폼 및 Azure 앱 Service 에코시스템에서 상속된 다른 기능 및 이점을 제공합니다.

예를 들어 다시 디자인된 컨테이너화된 런타임과 워크플로를 표준 논리 앱의 일부로 함께 패키지할 수 있습니다. 논리 앱 리소스를 즉시 배포할 수 있는 아티팩트로 빌드, 어셈블 및 압축하는 일반 단계 또는 작업을 사용할 수 있습니다. 표준 논리 앱을 배포하려면 아티팩트 내용을 호스트 환경에 복사한 다음, 앱을 시작하여 워크플로를 실행합니다. 또는 이미 잘 알고 사용하고 있는 도구와 프로세스를 사용하여 아티팩트를 배포 파이프라인에 통합합니다. 예를 들어 시나리오에 컨테이너가 필요한 경우 표준 논리 앱을 컨테이너화하고 기존 파이프라인에 통합할 수 있습니다.

가상 네트워크 및 연결과 같은 인프라 리소스를 설정하고 배포하려면 ARM 템플릿을 계속 사용하고 이러한 리소스를 해당 목적으로 사용하는 다른 프로세스 및 파이프라인과 함께 별도로 프로비저닝할 수 있습니다.

표준 빌드 및 배포 옵션을 사용하면 인프라 배포와는 별도로 앱 개발에 집중할 수 있습니다. 따라서 일반 앱에 사용하는 여러 유사하거나 동일한 배포 옵션을 적용할 수 있는 보다 일반적인 프로젝트 모델을 얻게 됩니다. 또한 앱 프로젝트를 중심으로 배포 파이프라인을 빌드하고 프로덕션에 게시하기 전에 필요한 테스트 및 유효성 검사를 실행하기 위한 보다 일관된 환경을 활용할 수 있습니다. 사용하는 기술 스택에 관계 없이 선택한 도구를 사용하여 논리 앱을 배포할 수 있습니다.

DevOps 배포 기능

단일 테넌트 Azure Logic Apps는 Azure Functions 플랫폼과 Azure App Service 에코시스템의 많은 기능과 이점을 상속합니다. 이러한 업데이트에는 전체 새 배포 모델 및 논리 앱 워크플로에 DevOps를 사용하는 다양한 방법이 포함되어 있습니다.

로컬 개발 및 테스트

Azure Logic Apps(표준) 확장과 함께 Visual Studio Code를 사용하는 경우 Azure에 배포하지 않고도 개발 환경에서 표준 논리 앱 워크플로를 로컬로 개발, 빌드 및 실행할 수 있습니다. 시나리오에 컨테이너가 필요한 경우 Azure Arc 지원 Logic Apps를 통해 만들고 배포할 수 있습니다.

이 기능은 주요 개선 사항으로, 다중 테넌트 모델에 비해 상당한 이점을 제공하며, 이를 위해 Azure에서 기존 및 실행 중인 리소스를 토대로 개발을 진행해야 합니다.

관심 영역 분리

단일 테넌트 모델은 논리 앱과 기본 인프라 간의 문제를 구분하는 기능을 제공합니다. 예를 들어 앱을 다른 환경을 위한 변경할 수 없는 아티팩트로서 별도로 개발, 빌드, 압축 및 배포할 수 있습니다. 논리 앱 워크플로에는 일반적으로 기본 인프라보다 더 자주 업데이트하는 "애플리케이션 코드"가 있습니다. 이러한 계층을 분리하여 논리 앱의 워크플로를 빌드하는 데 좀 더 집중하고 여러 환경에 필요한 리소스를 배포하는 데 필요한 업무를 좀 더 줄일 수 있습니다.

앱 및 인프라에 대한 별도의 배포 파이프라인을 보여 주는 개념 다이어그램

논리 앱 리소스 구조

다중 테넌트 Azure Logic Apps 모델에서 소비 논리 앱 리소스 구조에는 단일 워크플로만 포함될 수 있습니다. 이러한 일대일 관계로 인해 논리 앱과 워크플로는 자주 동의어로 간주되고 참조됩니다. 하지만 단일 테넌트 Azure Logic Apps 모델에서는 표준 논리 앱 리소스 구조에 여러 워크플로가 포함될 수 있습니다. 이러한 일대다 관계는 동일한 논리 앱에서 워크플로가 다른 리소스를 공유하고 다시 사용할 수 있음을 의미합니다. 또한 동일한 논리 앱 및 테넌트에 있는 워크플로는 이렇게 공유하는 테넌시와 근접성 덕분에 더 우수한 성능을 제공합니다. 이러한 리소스 구조는 함수 앱이 여러 함수를 호스트할 수 있는 Azure Functions와 유사하게 작동합니다.

논리 앱에서의 워크플로 구성, 성능 및 크기 조정에 관한 자세한 정보와 모범 사례는 단일 테넌트 Azure Logic Apps에 일반적으로 적용할 수 있는 유사한 Azure Functions용 지침을 참조하세요.

논리 앱 프로젝트 구조

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

프로젝트의 루트 수준에서 다른 항목이 있는 다음 파일 및 폴더를 찾을 수 있습니다.

이름	폴더 또는 파일	설명
.vscode	폴더	extensions.json, launch.json, settings.json 및 tasks.json 파일과 같은 Visual Studio Code 관련 설정 파일을 포함합니다.
아티팩트	폴더	B2B(Business-to-Business) 시나리오를 지원하는 워크플로에서 정의하고 사용하는 통합 계정 아티팩트를 포함합니다. 예를 들어 예제 구조에는 XML 변환 및 유효성 검사 작업에 대한 맵과 스키마가 포함됩니다.
*<WorkflowName>*	폴더	각 워크플로에 대한 <WorkflowName> 폴더에는 워크플로의 기본 JSON 정의를 포함하는 workflow.json 파일이 포함됩니다.
workflow-designtime	폴더	개발 환경 관련 설정 파일을 포함합니다.
.funcignore	파일	설치된 Azure Functions Core Tools 관련 정보를 포함합니다.
connections.json	파일	워크플로에서 사용하는 관리형 연결 및 Azure 함수에 대한 메타데이터, 엔드포인트 및 키를 포함합니다. 중요: 각 환경에 대해 서로 다른 연결과 함수를 사용하려면 이 connections.json 파일을 매개 변수화하고 엔드포인트를 업데이트해야 합니다.
host.json	파일	런타임 관련 구성 설정 및 값(예: 단일 테넌트 Azure Logic Apps 플랫폼, 논리 앱, 워크플로, 트리거 및 작업에 대한 기본 제한)이 포함되어 있습니다. 논리 앱 프로젝트의 루트 수준에서 host.json 메타데이터 파일에는 로컬 또는 Azure에 상관없이 동일한 논리 앱의 모든 워크플로가 실행되는 동안 사용하는 구성 설정 및 기본값이 포함됩니다. 참고: 논리 앱을 만들 때 Visual Studio Code는 스토리지 컨테이너에 backup *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에서 사용할 수 있는 지속적으로 증가하는 컬렉션의 일부로 1,000개가 넘는 Microsoft 관리 및 Azure 호스팅 커넥터 및 기본 제공 작업을 제공합니다. Microsoft에서 관리형 커넥터를 유지하는 방식은 다중 테넌트 Azure Logic Apps에서와 마찬가지로 단일 테넌트 Azure Logic Apps에서 거의 동일하게 유지됩니다.

가장 중요한 개선 사항은 단일 테넌트 서비스가 더 인기 있는 관리형 커넥터를 기본 제공 작업으로 사용할 수 있도록 한다는 것입니다. 예를 들어 Azure Service Bus, Azure Event Hubs, SQL 등에 대한 기본 제공 작업을 사용할 수 있습니다. 한편, 관리형 커넥터 버전도 여전히 사용할 수 있으며 계속 작동합니다.

Azure 서비스 기반 기본 제공 작업을 사용하여 만드는 연결을 기본 제공 연결 또는 서비스 공급자 기반 연결이라고 합니다. 기본 제공 작업 및 해당 연결은 워크플로를 실행하는 동일한 프로세스에서 로컬로 실행됩니다. 둘 다 다시 디자인된 Azure Logic Apps 런타임에서 호스트됩니다. 이와 대조적으로 관리형 연결 또는 API 연결은 ARM 템플릿을 사용하여 배포하는 Azure 리소스와는 별도로 만들어지고 실행됩니다. 따라서 기본 제공 작업 및 해당 연결을 통해 워크플로에 근접할 수 있으므로 성능을 향상시킬 수 있습니다. 이 디자인은 서비스 공급자 연결이 동일한 빌드 아티팩트로 패키지되므로 배포 파이프라인에서도 잘 작동합니다.

Visual Studio Code에서 디자이너를 사용하여 워크플로를 개발하거나 변경하는 경우 단일 테넌트 Azure Logic Apps 엔진은 프로젝트의 connections.json 파일에 필요한 모든 연결 메타데이터를 자동으로 생성합니다. 다음 섹션에서는 워크플로에서 만들 수 있는 세 가지 종류의 연결에 대해 설명합니다. 환경 간을 이동할 때 엔드포인트가 변경되기 때문에 연결 형식마다 JSON 구조가 다르다는 사실을 이해하는 것이 중요합니다.

서비스 공급자 연결

단일 테넌트 Azure Logic Apps에서 Azure Service Bus 또는 Azure Event Hubs와 같은 서비스에 대한 기본 제공 작업을 사용하는 경우 워크플로와 동일한 프로세스에서 실행되는 서비스 공급자 연결을 만듭니다. 이 연결 인프라는 논리 앱 리소스의 일부로 호스트되고 관리되며, 앱 설정은 워크플로에서 사용하는 모든 서비스 공급자 기반 기본 제공 작업에 대한 연결 문자열을 저장합니다.

Important

사용자 이름과 암호가 포함된 연결 문자열과 같은 중요한 정보가 있는 경우 사용 가능한 가장 안전한 인증 흐름을 사용해야 합니다. 예를 들어 지원이 제공되는 경우 관리 ID를 사용하여 Azure 리소스에 대한 액세스를 인증하고 필요한 최소한의 권한이 있는 역할을 할당하는 것이 좋습니다.

이 기능을 사용할 수 없는 경우 앱 설정과 함께 사용할 수 있는 Azure Key Vault와 같은 다른 측정값을 통해 연결 문자열을 보호해야 합니다. 그런 다음 연결 문자열 및 키와 같은 보안 문자열을 직접 참조할 수 있습니다. 배포 시 환경 변수를 정의할 수 있는 ARM 템플릿과 마찬가지로 논리 앱 워크플로 정의 내에서 앱 설정을 정의할 수 있습니다. 그런 다음, 연결 엔드포인트, 스토리지 문자열 등 동적으로 생성된 인프라 값을 캡처할 수 있습니다. 자세한 내용은 Microsoft ID 플랫폼을 사용하여 애플리케이션 등록을 참조하세요.

표준 논리 앱 프로젝트에서 각 워크플로에는 워크플로의 기본 JSON 정의가 포함된 workflow.json 파일이 있습니다. 그런 다음 이 워크플로 정의는 프로젝트의 connections.json 파일에서 필요한 연결 문자열 참조합니다.

다음 예제에서는 프로젝트의 connections.json 파일에 Azure Service Bus 기본 제공 작업에 대한 서비스 공급자 연결이 표시되는 방법을 보여 줍니다.

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

관리형 연결

워크플로에서 관리형 커넥터를 처음 사용하는 경우 대상 서비스 또는 시스템에 대한 관리형 API 연결을 만들고 ID를 인증하라는 메시지가 표시됩니다. 이러한 커넥터는 Azure의 공유 커넥터 에코시스템에서 관리됩니다. API 연결이 존재하고 Azure에서 별도의 리소스로 실행됩니다.

Visual Studio Code에서 디자이너를 사용하여 워크플로를 계속 만들고 개발하는 동안 단일 테넌트 Azure Logic Apps 엔진은 워크플로의 관리형 커넥터에 필요한 리소스를 Azure에 자동으로 만듭니다. 이 엔진은 논리 앱을 포함하도록 디자인한 Azure 리소스 그룹에 이러한 연결 리소스를 자동으로 추가합니다.

다음 예제에서는 프로젝트의 connections.json 파일에 Azure Service Bus 관리 커넥터에 대한 API 연결이 표시되는 방법을 보여 줍니다.

"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 Functions 연결

Azure Functions에서 만들어지고 호스트되는 함수를 호출하려면 Azure Functions 기본 제공 작업을 사용합니다. Azure Functions 호출에 대한 연결 메타데이터는 다른 기본 제공 연결과 다릅니다. 이 메타데이터는 논리 앱 프로젝트의 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에서 관리형 커넥터 에코시스템에 액세스할 수 있도록 해당 ID를 인증하는 방법이 필요합니다. 또한 관리형 연결을 사용할 때 작업을 실행하려면 앱에 올바른 권한이 필요합니다.

기본적으로 각 단일 테넌트 기반 논리 앱에는 자동으로 사용하도록 설정된 시스템 할당 관리 ID가 있습니다. 이 ID는 연결을 만들 때 사용하는 인증 자격 증명이나 연결 문자열과는 다릅니다. 런타임에 논리 앱은 이 ID를 사용하여 Azure 액세스 정책을 통해 해당 연결을 인증합니다. 이 ID를 사용하지 않도록 설정하면 런타임에 연결이 작동하지 않습니다.

다음 섹션에서는 논리 앱이 실행되는 위치에 따라 관리형 연결을 인증하는 데 사용할 수 있는 인증 유형에 대한 자세한 정보를 제공합니다. 관리되는 각 연결에 대해 논리 앱 프로젝트의 connections.json 파일에는 authentication 논리 앱이 관리되는 연결을 인증하는 데 사용할 수 있는 인증 유형을 지정하는 개체가 있습니다.

관리 ID

Azure에서 호스트되고 실행되는 논리 앱의 경우 관리 ID는 Azure에서 호스트되고 실행되는 관리형 연결을 인증하는 데 사용할 수 있는 기본 및 권장 인증 유형입니다. 논리 앱 프로젝트의 connections.json 파일에서 관리되는 연결에는 authentication 인증 유형으로 지정 ManagedServiceIdentity 하는 개체가 있습니다.

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

원시

Visual Studio Code를 사용하여 로컬 개발 환경에서 실행되는 논리 앱의 경우 원시 인증 키는 Azure에서 호스트되고 실행되는 관리형 연결을 인증하는 데 사용됩니다. 이러한 키는 프로덕션이 아닌 개발 용도로만 디자인되었으며 7일의 만료 기간이 적용됩니다. 논리 앱 프로젝트의 connections.json 파일에서 관리되는 연결에는 authentication 다음 인증 정보를 지정하는 개체가 있습니다.

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

다음 단계

단일 테넌트 Azure Logic Apps의 DevOps 배포 설정

다음을 통해 공유