シングルテナントの Azure Logic Apps の Standard ロジック アプリ向けの DevOps デプロイ

適用対象: Azure Logic Apps (Standard)

分散型のクラウド ネイティブなアプリへの傾向が強まっており、組織で扱うコンポーネントもより多くの環境に分散されるようになってきました。 制御と一貫性を維持するために、DevOps ツールとプロセスを使用すると、環境を自動化し、より多くのコンポーネントをより迅速かつ確実にデプロイできます。

この記事では、シングルテナントの Azure Logic Apps 内の Standard ロジック アプリ ワークフロー向けの継続的インテグレーションと継続的デプロイ (CI/CD) エクスペリエンスを紹介し、その概要を説明します。

シングルテナントとマルチテナント

"マルチテナント" の Azure Logic Apps でのリソースのデプロイは、Azure Resource Manager テンプレート (ARM テンプレート) に基づいており、従量課金ロジック アプリのリソースとインフラストラクチャの両方のリソース プロビジョニングを組み合わせて処理します。 "シングルテナント" の Azure Logic Apps の場合は、Standard ロジック アプリのリソースとインフラストラクチャの間でリソースのプロビジョニングを分離できるため、デプロイが簡単になります。

Standard ロジック アプリのリソースを作成すると、ワークフローは、再設計されたシングルテナントの Azure Logic Apps ランタイムを利用します。 このランタイムは Azure Functions 機能拡張モデルを使用し、Azure Functions ランタイムの拡張機能としてホストされます。 この設計により、Standard ロジック アプリの移植性、柔軟性、パフォーマンスが向上するだけでなく、Azure Functions プラットフォームと Azure App Service エコシステムから継承されるその他の機能や利点が得られます。

たとえば、再設計されてコンテナー化されたランタイムとワークフローを、Standard ロジック アプリの一部としてまとめてパッケージ化できます。 ロジック アプリのリソースをビルドしてアセンブルし、すぐにデプロイできる成果物に圧縮する一般的な手順またはタスクを使用できます。 Standard ロジック アプリをデプロイするには、成果物をホスト環境にコピーし、アプリを開始してワークフローを実行します。 または、既に知っており、使用しているツールとプロセスを使用して、成果物をデプロイ パイプラインに統合します。 たとえば、コンテナーを必要とするシナリオの場合、Standard ロジック アプリをコンテナー化し、既存のパイプラインに統合できます。

仮想ネットワークや接続などのインフラストラクチャ リソースを設定してデプロイするには、引き続き ARM テンプレートを使用でき、それらのリソースを、その目的で使用する他のプロセスやパイプラインと共に個別にプロビジョニングできます。

ビルドとデプロイの標準オプションを使用することにより、インフラストラクチャのデプロイから切り離して、アプリの開発に集中できます。 その結果、プロジェクト モデルはより汎用的になり、汎用アプリに使用する多くの類似したまたは同じデプロイ オプションを適用できます。 また、アプリ プロジェクト中心のデプロイ パイプラインの構築と、運用環境に発行する前に必要なテストと検証の実行に関して、エクスペリエンスがいっそう一貫したものになるというベネフィットもあります。 使用するテクノロジ スタックに関係なく、独自に選択したツールを使用してロジック アプリをデプロイできます。

DevOps のデプロイ機能

シングルテナントの Azure Logic Apps は、Azure Functions プラットフォームと Azure App Service エコシステムから、多くの機能とベネフィットを受け継いでいます。 これらの更新には、まったく新しいデプロイ モデルと、ロジック アプリのワークフローに DevOps を使用するいっそう多くの方法が含まれています。

ローカルでの開発とテスト

Visual Studio Code と Azure Logic Apps (Standard) 拡張機能を使用すると、Azure にデプロイしなくても、開発環境でローカルに Standard ロジック アプリのワークフローを開発してビルドし、実行することができます。 コンテナーを必要とするシナリオの場合、Azure Arc 対応 Logic Apps を使用して作成し、デプロイできます。

この機能は大幅な改善であり、Azure 内に既にある実行中のリソースに対して開発を行う必要があるマルチテナント モデルと比較して大きな利点をもたらします。

懸念事項を分離する

シングルテナント モデルを使用すると、ロジック アプリと基になるインフラストラクチャの間で懸念事項を分離することができます。 たとえば、アプリの開発とビルドを行い、圧縮し、変更できない成果物として異なる環境に個別にデプロイできます。 ロジック アプリ ワークフローには、通常、基になるインフラストラクチャより頻繁に更新される "アプリケーション コード" があります。 これらのレイヤーを分離することで、ロジック アプリのワークフローの構築にいっそう集中でき、必要なリソースを複数の環境にデプロイする労力が減ります。

ロジック アプリのリソースの構造

マルチテナント Azure Logic Apps モデルでは、従量課金プランのロジック アプリのリソース構造には、1 つのワークフローのみを含めることができます。 この 1 対 1 の関係により、多くの場合、ロジック アプリとワークフローの両方が同義と見なされ、参照されます。 ただし、シングルテナント Azure Logic Apps モデルでは、Standard ロジック アプリのリソース構造に複数のワークフローを含めることができます。 この 1 対多の関係は、同じロジック アプリ内でワークフローが他のリソースを共有し、再利用できることを意味します。 同じロジック アプリおよびテナント内のワークフローでも、この共有テナントと相互の近接性により、パフォーマンスが向上します。 このリソース構造は、1 つの関数アプリが多数の関数をホストできる Azure Functions と、見かけと動作が似ています。

ロジック アプリでのワークフローの整理、パフォーマンス、スケーリングに関する詳細とベスト プラクティスについては、類似する Azure Functions に関するガイダンスを参照してください。これは、シングルテナントの 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 テンプレート内のすべてのものは、デプロイ時に定義されます。 1 つの変数を変更するだけでよい場合も、すべてを再デプロイする必要があります。

シングルテナントの Azure Logic Apps の場合は、アプリの設定とパラメーターを使用することで、実行時に環境変数を呼び出して参照できるので、頻繁に再デプロイする必要はありません。

マネージド コネクタと組み込み操作

Azure Logic Apps のエコシステムには、増加し続けるコレクションの一部として、1,000 を超える Microsoft で管理され、Azure でホストされるコネクタと組み込み操作が用意されており、シングルテナントの Azure Logic Apps で使用できます。 Microsoft がマネージド コネクタをメンテナンスする方法は、シングルテナントとマルチテナントの 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 ファイルに、必要な接続メタデータが自動的に生成されます。 以下のセクションでは、ワークフローで作成できる 3 種類の接続について説明します。 接続の種類ごとに JSON 構造が異なり、環境間を移動するとエンドポイントが変わるため、これを理解しておくことが重要です。

サービス プロバイダーの接続

Azure Service Bus や Azure Event Hubs などのサービス用の組み込み操作をシングルテナントの Azure Logic Apps で使用する場合は、ワークフローと同じプロセスで実行されるサービス プロバイダー接続を作成します。 この接続インフラストラクチャは、ロジック アプリ リソースの一部としてホストおよび管理されます。ワークフローで使用するサービス プロバイダーベースの組み込み操作のための接続文字列は、アプリの設定で格納します。

Standard ロジック アプリのプロジェクトには、ワークフローごとに workflow.json があり、ワークフローの基になる JSON 定義が含まれています。 このワークフロー定義で、プロジェクトの connections.json ファイル内の必要な接続文字列を参照します。

次の例は、Azure Service Bus の組み込み操作のためのサービス プロバイダー接続が、プロジェクトの connections.json ファイルでどのように表されるかを示しています。

"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 リソース グループに、これらの接続リソースが自動的に追加されます。

次の例は、Azure Service Bus のマネージド コネクタのための 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 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"
}

Raw

Visual Studio Code を使用してローカル開発環境で実行されるロジック アプリの場合は、Raw 認証キーが、Azure でホストされて実行されるマネージド接続の認証に使用されます。 これらのキーは、運用環境ではなく開発専用に設計されており、有効期限は 7 日です。 ロジック アプリ プロジェクトの connections.json ファイルには、マネージド接続の authentication オブジェクトがあり、次の認証情報が指定されています。

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

次のステップ

• シングルテナントの Azure Logic Apps 用に DevOps のデプロイを設定する