🤖

LogicAppsStandardをテンプレートから展開する

2024/03/28に公開

前置き

  • 間違っていたら優しくマサカリを手渡しでください。
  • 調べた限りではStandardの情報少なすぎね、と感じたので詰まりポイントを共有しようと考えた次第です。

はじめに

自分のもの以外にも概要紹介しているサイトを紹介します。
Logic Apps をこれから使い始めようという方へ
Standard タイプの Logic Apps について少し触れてみる

LogicAppsとは

Azure Logic Apps は、コンテナー化されたランタイム上に構築された、主要なサービスとしての統合プラットフォーム (iPaaS) です。

Azure Logic Apps

Azure Logic Apps はクラウド プラットフォームであり、コードをほとんど、またはまったく使用せずに、自動化されたワークフローを作成して実行できます。 ビジュアル デザイナーを使用し、事前構築済みの操作から選択することで、アプリ、データ、サービス、システムを統合および管理するワークフローをすばやく構築できます。

Azure Logic Apps とは

つまりシステムを統合するためのプラットフォーム(iPaaS)の一種がLogicAppsといえそうですね。
画像の通りノーコードで記述できるのがメリットだと言えます。

LogicAppsStandardのメリデメ

LogicApps(従量課金)とLogicAppsStandardの選択においての自分なりの考えを記載します。

組み込みコネクタとマネージドコネクタの違い

組み込みコネクタ(内蔵コネクタ)とマネージドコネクタ(Azure コネクタ)の大きな違いはプライベートネットワークで通信できるかどうかです。

built-in (組み込み) タイプのコネクタをご利用いただいた場合のみ、VNet を経由することが可能です。

Standard Logic Apps から VNet 経由で別リソースにアクセスする方法

また、ただし組み込みコネクタはマネージドコネクタよりもアクション/トリガーが少ないことがあります。そもそもない場合もあります。

Standard ロジック アプリのワークフローでは使用できないコネクタを必要とする場合は、Standard ワークフローのサービス プロバイダーベースの組み込みコネクタで使用されるのと同じ拡張性モデルを使用して、独自の組み込みコネクタを作成できます。

Standard ロジック アプリ

Standard ワークフローでは、スライディング ウィンドウ、Azure App Service、Azure API Management などの一部の組み込みトリガーとアクションは現在使用できません。

変更された、制限付き、使用できない、またはサポートされていない機能

ただしほとんどの場合、組み込みコネクタの方がパフォーマンス、機能、価格に優れています。
※組み込みコネクタの利用にコストかかりません。マネージドコネクタの利用は通常通り課金されます。

ほとんどの場合、組み込みのバージョンの方がパフォーマンス、機能、価格などに優れています。

Azure Logic Apps の組み込みコネクタ

標準モデルには、ワークフローで実行できる "無制限の数" の無料の組み込み操作が含まれています。
ワークフローでマネージド コネクタ操作を使用する場合、測定は "各呼び出し" に適用されますが、課金は従量課金プランと同じ Standard または Enterprise のコネクタ価格に従います。

標準 (シングルテナント)

構成

やりたいこと

構成図

デプロイ前

LogicAppsStandardのデプロイ

LogicApps ワークフローのデプロイ

LogicApps ワークフローの実行

やってみよう

ARMテンプレートのTipsとサンプル

サンプル

ちなみに↓のサンプルもありますが更新されてなさそうなので新規で今回作成しました。
LogicApp-deployment-with-Secure-Storage

事前準備

  1. 事前に以下のような環境を作成しておきます。


    ※サブネットのCIDRやリソース名が変わってなければまあとりあえず動くはずです。こっちのARMテンプレート化は、、、要望次第でベストエフォートで対応します。
  2. Self hosted agentをインストールしたWindowsVMを用意します。
    DevOps の Self-hosted エージェントを構築して使ってみよう!
    ※自分はVMイメージを"Windows Server 2022 Datacenter: Azure Edition - Gen 2"を利用しました。

  3. サンプルのテンプレートを展開します。今回はLogicApps用のリソースグループ"rg-logicapps-test-jpe-02"に分けて展開します。
  4. 本来はLogicAppsStandardのワークフロー履歴などを入れるコンテナですが、ワークフローの動作検証用に"testcontainer"を用意してここに"test.txt"を好きな文言を書いて入れてみましょう。設定後、パブリックネットワークアクセスを無効にします。


  5. LogicAppsStandardの"アプリケーションの設定"にARMテンプレートで定義した設定が確認します。
    ARMテンプレート

    アプリケーションの設定
  6. 今回利用するワークフローをAzure Pipelines経由でデプロイします。


    Standard Logic Apps と Azure DevOps で CI/CD 環境を構成する
    ※自分はフォルダ名を"sample"から"Application"にして、PoolをSelf hosted VMを指定しました。

ワークフローはLogicAppsへHTTPSリクエストがきたらプライベートなBLOB Storageにあるコンテンツをメールで送るシンプルなモノ

ちなみにワークフローやらの実体はLogicAppsStadardの場合、Kuduから見ることができます。
※ただしAzurePortalからのアクセスするためにはいったんLogicAppsStandardのパブリックアクセスを許可する必要があります。

使用するコネクタは以下の通りです。
Azure Blob Storage # 組み込みコネクタのBlob Storageです。
Outlook.com # マネージドコネクタのOutlook.comです。

動作検証

事前準備7.についてAzurePipelineの利用申請で詰まったため2~3日後改めて行います。

悲しいことにMSから連絡が来ないので更新されないかも、、(ただし、とりあえずの動作検証でやってるようにSelf hosted VMが主体となってパイプラインのジョブを実行するため想定通りワークフローの更新を自動化できるはずです)

とりあえずの動作検証

事前準備7.の代わりに以下を行います。

  1. Self Hosted VMへアクセスしてここからzipデプロイを行います。(パイプライン想定)
    ※AzureCLIやStorageExplorerはChocolateyでインストールしました。他の方法でもOKです。また認証はシステムマネージドIDで行いました。
    az logicapp deployment source config-zip --name lalogicappstestjpe01 --resource-group rg-logicapps-test-jpe-02 --subscription MySubscription --src ./Application.zip
    

    ロジック アプリをデプロイする
  2. API接続はこのままでは利用できません。ログイン中のユーザーの権限で承認する必要があります。
    ※ここで承認したアカウントがそのままメールの送信者になります。またOffice365マネージドコネクタの仕様により組織のアカウントでしか認証できません。個人アカウントを利用する場合はもう一つのOutlook.comコネクタがあるのでそちらを利用しましょう。(なお非推奨ですが)


    その後、システムマネージドIDに対してアクセスポリシーを付与します。

  3. ワークフローのエンドポイントを取得します。
  4. ひとつ前で取得したエンドポイントへSelf Hosted VMからアクセスします。
    ※LogicAppsStandardのパブリックエンドポイントが無効なため
    curl https://lalogicappstestjpe01.azurewebsites.net:443/api/wf_lalogicappstestjpe01-01/triggers/When_a_HTTP_request_is_received/invoke?api-version=2022-05-01`&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun`&sv=1.0`&sig=xxxxxx
    
    ※PowerShellをたたくとき&はバッククオートでエスケープしときましょう。また人によってURLが異なるため、必ず自身のワークフローから取得しましょう。

    ワークフローが実行されてメールが送られてきたことが確認できます。
    "test.txt"のコンテンツが取得できていることからプライベートエンドポイントを経由して取得できていることがわかりますね。

TIPS

ARMテンプレートからワークフローで利用する環境変数を渡してワークフローで利用する

LogicAppsの制約として"アプリケーションの設定"で定義された環境変数を"workflow.json"から参照できません。
つまりARMテンプレートからワークフローで利用する情報を渡すには"アプリケーションの設定"から"parameters.json"を経由して"workflow.json"に渡す必要があります。

アプリ設定にはサイズ制限があり、Azure Logic Apps の特定の領域からは参照できません。

従量課金と Standard のロジック アプリ ワークフローのパラメーター

以下はメールの宛先をARMテンプレートからワークフローまで渡す例です。
ARMテンプレートの入力パラメータ

ARMテンプレートの"アプリケーションの設定"

LogicAppsStandardの"parameters.json"

LogicAppsStandardの"workflow.json"

組み込みコネクタへのシークレットをLogicAppsStandardに渡す

ARMテンプレートのlistkey関数を利用することでBLOBストレージの接続文字列を渡すようにします。
ただし残念ながらlistkey関数はアクセスキーは取れても接続文字列は取得できませんが以下のようにすれば作成できます。

"[concat('DefaultEndpointsProtocol=https;AccountName=',parameters['logicappsStorageAccountName'],';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters['logicappsStorageAccountName']), '2019-06-01').keys[0].value,';EndpointSuffix=','core.windows.net')]"

Storage Accounts - List Keys

ただし、これについては推奨されておらず可能ならKeyVault経由で渡すのが良いとされています。

Standard ロジック アプリ ワークフローでは、securestring や secureobject などのセキュリティで保護されたデータ型はサポートされていません。 ただし、別のオプションとして、アプリ設定を Azure Key Vault とともに使用できます。 これで、接続文字列やキーなど、セキュリティで保護された文字列を直接参照できます。

従量課金と Standard のロジック アプリ ワークフローのパラメーター

そのほか、マネージドIDによる認証がコネクタで対応しているのであればこちらを利用した方がセキュアです。

マネージド ID には、証明書ベースの認証が使用されます。 各マネージド ID の資格情報は有効期限が 90 日で、45 日後にローテーションされます。

マネージド ID に関連付けられる資格情報は何ですか? その有効期間とローテーションの頻度は?

KeyVault経由だとかマネージドIDによる認証だとかのARMテンプレート化は気が向いたらやります。たぶんきっとめいびー。

API接続に利用する情報をLogicAppsStandardに渡す

マネージドコネクタによって作成される"API 接続"リソースとLogicAppsStandardを紐づけるためには"connection.json"にAPI接続の情報を記載しなければいけないです。
その際にconnectionRuntimeUrlとかいう謎のパラメータの取得方法についてのTipsです。

connections.json ファイルをパラメーター化するには、ConnectionRuntimeUrl などのリテラル値を単一の parameters() 式 (たとえば、@parameters('api-runtimeUrl')) に置き換えます。 connections.json ファイルで、有効な式の型は @parameters と @appsetting だけです。

接続ファイルのパラメーター化

ARMテンプレート上で[reference(<resourceID>, '2016-06-01','full').properties.connectionRuntimeUrl]で取得できます。
今回はARMテンプレートで取得して"アプリケーションの設定"経由で"connection.json"に渡します。

注意:ARMテンプレートに記載する"API 接続"は"kind: V2"で作成する必要があります。でなければこのconnectionRuntimeUrlというプロパティは存在しません。

The property connectionRuntimeUrl is also missing. I suspect this is because the property didn't get introduced until the kind: 'v2' value existed.

API connection needs to support connectionRuntimeUrl as output/property #3494

完全なリソース オブジェクトを返すかどうかを指定する値。 'Full' を指定しない場合、リソースのプロパティ オブジェクトのみが返されます。 完全なオブジェクトには、リソース ID や場所などの値が含まれます。

reference

コネクタのトリガーについて

トリガーの条件式を追加することがあります。
忘れやすいのでこの際に覚えておくとよいかもです。

Trigger conditions is a trigger setting used to specify one or more conditional expressions which must be true for the trigger to fire.

What you need to know about trigger conditions?

エラーについて

Encountered an error (ServiceUnavailable) from host runtime.


上記のようなエラーがLogicAppsStandardで表示された場合はStorageAccountにアクセスできていない可能性があります。
名前解決やFW、"アプリケーションの設定"の接続文字列などを確認してみましょう。
Deploying Standard Logic App to Storage Account behind Firewall using Service or Private Endpoints

ちなみに僕は何度もテンプレートからデプロイしてたら動きました。
今、寝てないので原因もわかりません。寝ます。

注意点

  • VNET作成時にPrivateSubnetは委任先のサブネットではオンにしてはいけません。NAT GWがあろうとPublicPreview のAzure Private Sunetをオンにしたサブネットはサブネット委任できません(1敗)
  • LogicAppsだけ先に消す場合は必ずVNET統合を切断してサブネット委任を"なし"にしましょう。削除できないVNETがゴミとして残ります。
    ※この場合削除にはSRから問い合わせする必要があります(1敗)

終わりに

初めてApp Service属をがっつり触りましたがなかなか面白かったです。
と同時に思った以上に詰まって泣きそうになりました。しばらくLogicApps見たくありません。
次はWebAppsを触ってみようかな。API Managementも興味あるけど。あるいは面白そうなアーキテクチャ思いついたり見つけたらそれやるかも。(テキトウ)

Discussion