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

[アーティクル]
10/23/2024

適用対象: 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 に配置されて実行されているリソースで開発を行う必要があるマルチテナントモデルと比較すると、大きなベネフィットになります。

懸案事項を分離する

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

アプリとインフラストラクチャで分けられたデプロイパイプラインを示す概念図。

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

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

プロジェクトのルートレベルでは、他の項目を含む次のファイルとフォルダーを確認できます。

Name	フォルダーまたはファイル	Description
.vscode	Folder	Visual Studio Code 関連の設定ファイル (extensions.json、launch.json、settings.json、tasks.json ファイルなど) が含まれています。
アイテム	Folder	企業間 (B2B) シナリオをサポートするワークフローで定義および使用する統合アカウント成果物が含まれています。たとえば、この構造の例には、XML 変換と検証の操作のマップとスキーマが含まれます。
*<WorkflowName>*	フォルダー	ワークフローごとに、<<> フォルダーに、ワークフローの基礎になっている JSON 定義が入った > ファイルが含まれています。
workflow-designtime	Folder	開発環境関連の設定ファイルが含まれています。
.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 テンプレート内のすべては、デプロイ時に定義されます。 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 で使用する場合は、ワークフローと同じプロセスで実行されるサービスプロバイダー接続を作成します。この接続インフラストラクチャは、ロジックアプリリソースの一部としてホストおよび管理されます。ワークフローで使用するサービスプロバイダーベースの組み込み操作のための接続文字列は、アプリの設定で格納します。

重要

ユーザー名やパスワードを含む接続文字列などの機密情報がある場合は必ず、利用可能な最も安全な認証フローを使用してください。たとえば Microsoft では、サポートを利用できる場合はマネージド ID を使って Azure リソースへのアクセスを認証し、必要最小限の特権を持つロールを割り当てることをお勧めします。

この機能を使用できない場合は必ず、Azure Key Vault など、アプリ設定で使用できる他の手段を使用して接続文字列をセキュリティで保護してください。これで、接続文字列やキーなど、セキュリティで保護された文字列を直接参照できます。デプロイ時に環境変数を定義できる ARM テンプレートと同様に、ロジックアプリのワークフロー定義内でアプリ設定を定義できます。その後、動的に生成されたインフラストラクチャ値 (接続エンドポイント、ストレージ文字列など) を取得できます。詳細については、「Microsoft ID プラットフォームのアプリケーションの種類」を参照してください。

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 のデプロイを設定する

次の方法で共有

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

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

DevOps のデプロイ機能

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

懸案事項を分離する

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

ロジックアプリのプロジェクトの構造

コンテナーのデプロイ

アプリの設定とパラメーター

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

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

マネージド接続

Azure Functions 接続

認証

マネージド ID

Raw

次の手順

フィードバック

その他のリソース

次の方法で共有

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

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

DevOps のデプロイ機能

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

懸案事項を分離する

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

ロジック アプリのプロジェクトの構造

コンテナーのデプロイ

アプリの設定とパラメーター

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

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

マネージド接続

Azure Functions 接続

認証

マネージド ID

Raw

次の手順

フィードバック

その他のリソース

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

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

ロジックアプリのプロジェクトの構造

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

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