【徹底解説】Standard Logic Appsの環境変数【シングルテナント】

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

Standard シングルテナント ロジック アプリと従量課金マルチテナント ロジック アプリの違い # Standard ロジック アプリとワークフロー

APP_KIND

Azure リソースの種類について記載されていて、既定値は “workflowApp” です。

シングルテナントの Azure Logic Apps で Standard ロジック アプリのホストとアプリの設定を編集する # アプリ設定のリファレンス – local.settings.json

APPLICATIONINSIGHTS_CONNECTION_STRING

分析に使われる Application Insights の接続文字列になります。

Application Insights の接続文字列。

Azure Functions のアプリケーション設定のリファレンス # APPLICATIONINSIGHTS_CONNECTION_STRING

AzureFunctionsJobHost_extensionBundle_id

Standard Logic Apps が動作する為に必要な機能がまとめられた拡張機能バンドルを指定する ID です。

ちなみに、Standard Logic Apps の場合は “Microsoft.Azure.Functions.ExtensionBundle.Workflows” という拡張機能バンドルが利用されているようです。

Azure portal でサンプル Standard ワークフローを作成する - Azure Logic Apps

Azure portal を使用して、シングルテナント Azure Logic Apps で実行される最初のサンプル S…

AzureFunctionsJobHost_extensionBundle_version

先述した拡張機能バンドルのバージョンを指定するものです。

公式ドキュメントに記載のあったトラブルシューティングなのですが、古い Standard Logic Apps の場合は拡張機能バンドルのバージョンが低くて問題が発生することがあるようです。

上記の引用先では、古い拡張機能バンドルを消して新しいバンドルに置き換える手順まで詳細に記載がされておりますので、問題が生じている方はご参考いただければと。

AzureWebJobsStorage

前提として、Standard Logic Apps のワークフロー情報や実行履歴といった内容については、Logic Apps 作成時に連携した Storage Account に保存されます。

“AzureWebJobsStorage” については、その Storage Account との接続に使う文字列です。

FUNCTIONS_EXTENSION_VERSION

継承元である Azure Functions のバージョンになります。

2024 年 9 月時点では、最新バージョンは 4.0 です。
バージョンについて詳細に確認されたい方は下記を参照してください。

Azure Functions ランタイム バージョンの概要

Azure Functions では、複数のバージョンのランタイムがサポートされます。 バージョン間の違いと、適切なバー…

FUNCTIONS_WORKER_RUNTIME

実際に Standard Logic Apps が動いているプログラミング言語、言語スタックです。

こちらの環境変数については Standard の公式ドキュメント曰く、現在は dotnet が既定値であり、複数言語のサポートが自動的に有効化されているため設定は不要だそうです。

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

イベントの発生に応じて行うスケーリング設定や、リソースのコードと構成が格納された Storage Account への接続に使う文字列です。

“AzureWebJobsStorage” との違いについて簡単にまとめると、”AzureWebJobsStorage” は主にトリガーやログの保存先であり、”WEBSITE_CONTENTAZUREFILECONNECTIONSTRING” はリソースそのもののコードや構成ファイルの保存先となります。

しかしながら、どちらも同じ Storage Account を指定しているので、気にしなくても良いかなと。

動的スケーリングを有効にするために必要なイメージを格納できます。 これらのプランでは、ストレージ アカウントの接続文字列を WEBSITE_CONTENTAZUREFILECONNECTIONSTRING で設定し、ファイル共有の名前を WEBSITE_CONTENTSHARE で設定します。 これは通常、AzureWebJobsStorage に使われるのと同じアカウントです。

Azure Functions のストレージに関する考慮事項 # ストレージ アカウント接続の設定

WEBSITE_CONTENTSHARE

先述した “WEBSITE_CONTENTAZUREFILECONNECTIONSTRING” での指定先となっている Storage Account の名前です。

WEBSITE_NODE_DEFAULT_VERSION

使用されている Node.js のバージョンになります。

“FUNCTIONS_WORKER_RUNTIME” についての説明で既定値が node から dotnet に変わって複数言語のサポートが自動的に有効になっている旨の記載がありましたが、どちらにしろバックエンドで動作しているのは TS なので Node.js のバージョンも重要ということですかね多分。