Azure Logic AppsのWorkflowをPipelineを用いてデプロイしてみた ~~Logic AppへWorkflowのデプロイ~~

Azure Logic Apps(以下：Logic Appsと記載)のワークフローをAzure Pipelinesを用いてデプロイする方法について、複数回に分けてご紹介します。

前回は事前準備としてセルフホステッドエージェントの作成方法についてご説明しました。

前回の記事を見ていない方は以下よりご覧ください。

blog.jbs.co.jp

本記事では、実際にLogic Appsにワークフローをデプロイしていきます。

Azure Pipelinesとは
前提
事前準備
Pipelinesの作成
- YAMLファイルについて
- Pipelinesの作成
ワークフローのデプロイ
- Pipelinesの実行
- デプロイ後のワークフローの確認
最後に

Azure Pipelinesとは

はじめに、Azure Pipelinesについてご説明します。

Azure Pipelinesとは、Azure DevOps上CI/CDの機能を提供するサービスであり、ビルドやデプロイのタスクを定義して、自動化できる機能となります。

Pipelinesを利用することで、これまで手動で実施していたビルド、デプロイ、テストなどを「自動」実施することが可能です。

Pipelinesは、YAML形式の定義ファイルを用いてタスクを定義します。

前提

前提として、本記事では、既に存在している既存のLogic Appsにワークフローをデプロイします。

セキュリティを担保するため、内部からの通信のみを許可するため、プライベートエンドポイントを持っているものとします。

以下に簡単な構成図を記載します。

また、このワークフローのデプロイは災害時、別リージョンにあるLogic Appsに対し切り替えが必要になった場合も、既存のワークフローのデプロイが可能となります。

本記事ではプライベートでの環境を想定しているため、使用するエージェントは前回記事で記載したセルフホステッドエージェントを使用します。

事前準備

事前準備では実際にワークフローをデプロイするための準備について解説します。

ワークフローの準備

はじめに、Pipelinesを用いてデプロイするワークフローの準備します。

ワークフローの作成の手順は以下ドキュメントを参考にしてください。

learn.microsoft.com

本記事では、「毎日9時に出勤のメールを飛ばす」という簡単なワークを作成していきます。

Repos上にフォルダを準備

Repos内のRepositoryにワークフローやPipelines実行のためのYAMLファイルを格納するためのフォルダを準備します。本記事では以下のようなディレクトリ構成とします。

Repository
- Demo
  - .pipeline
    - cicd_pipeline.yml
    - variables
      - pipeline-variables.yml
- workflow
  - host.json
  - connections.json
  - 「対象ワークフロー名」
    - workflow.json

ワークフローとホストの情報を格納

Pipelinesを用いてワークフローをデプロイするためには、事前にDevOps上のReposに格納する必要があります。

格納するファイルはLogic Appsと結びついているストレージアカウントより、取得することが可能です。

取得するファイルは以下になります。

workflow.json
- 実際に作成したワークフローがjson形式で記載されています
host.json
- ランタイム固有の構成設定と値が記載されています
connections.json(API接続がある場合、必須)
- ワークフローで使用されるマネージド接続とAzure関数のメタデータ、エンドポイント、キーの情報が記載されています

本記事で使用する「毎日9時に出勤のメールを飛ばす」ワークフローには、Office 365 Outlookを使用するため、Office 365という名のAPI接続がワークフロー作成時に作成されます。そのため、connections.jsonもReposに格納します。

上記ディレクトリにワークフローを格納するときは、１つのフォルダに１つの「workflow.json」となります。

また、１点注意事項として、「host.json」、「connections.json」、「workflow.json」のファイル名を変更することはできません。

ワークフローの格納ができましたら、Logic Appsからワークフローを削除します。

API接続の事前作成

そもそもAPIとは、「アプリケーション・プログラミング・インターフェース（Application Programming Interface）」の略称でソフトウェアとWebサービス間をつなぐインターフェースのことです。

このAPI接続の準備がワークフローをデプロイするうえで鬼門となります。

デプロイするLogic Appsと同一のリソースグループ内にワークフローと結ぶAPI接続がない場合、ワークフローとWebサービス間で接続が取れないため、ワークフローが正常に動作しません。

そのため、API接続がない場合は事前に作成し、Logic Appsと接続を確立しておく必要があります。

API接続はAzure PoratlよりGUIで作成することができないため、ARMテンプレートからの作成となります。

作成のためのARMテンプレートは以下を使用します。

以下、API接続作成 ARMテンプレート ※サンプル

    {
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "azureSubscription": {
            "defaultValue": "<サブスクリプションID>",
            "type": "String"
        },
        "resourceGroupName": {
            "defaultValue": "<ワークフローデプロイ先リソースグループ>",
            "type": "String"
        },
        "connections_api_name_1": {
            "defaultValue": "<APIの種類>",
            "type": "String"
        },
        "connections_api_display_name_1": {
            "defaultValue": "<API表示名>",
            "type": "String"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Web/connections",
            "apiVersion": "2016-06-01",
            "name": "[parameters('connections_api_name_1')]",
            "location": "japaneast",
            "kind": "V2",
            "properties": {
                "displayName": "",
                "statuses": [
                    {
                        "status": "Connected"
                    }
                ],
                "api": {
                    "name": "[parameters('connections_api_name_1')]",
                    "displayName": "[parameters('connections_api_display_name_1')]",
                    "id": "[concat('/subscriptions/', parameters('azureSubscription'), '/providers/Microsoft.Web/locations/japaneast/managedApis/', parameters('connections_api_name_1'))]",
                    "type": "Microsoft.Web/locations/managedApis"
                },
                "testLinks": [
                    {
                        "requestUri": "[concat('https://management.azure.com:443/subscriptions/', parameters('azureSubscription'), '/resourceGroups/', parameters('resourceGroupName'), '/providers/Microsoft.Web/connections/', parameters('connections_api_name_1'), '/extensions/proxy/testconnection?api-version=2016-06-01')]",
                        "method": "get"
                    }
                ]
            }
        }
    ]
}

作成後、Azure Portalより、作成されていることを確認します。

作成したAPI接続を選択し、認証のエラーが出ているため、[API接続の編集]より認証の実施を行います。

この認証方法はAPIの種類によって異なりますが、主に「アカウント認証」、「マネージドID認証」、「OAuth2.0認証」等があります。

認証後、エラーが消えたことを確認し、左ペインの「アクセスポリシー」より、対象Logic Appsを選択します。

これで、API接続の事前準備は終了です。

Pipelinesの作成

準備が整ったところで、実際にAzure DevOpsからPipelinesを作成していきましょう。

YAMLファイルについて

本記事でワークフローをデプロイするのに使用するYAMLファイルは2つあります。

1つ目は、[pipeline-variables.yml]です。

ワークフローのデプロイ先である「Azure サブスクリプション」や「リソースグループ」、「Logic Apps」等、必要情報を記載しています。

以下、Pipeline-variables.ymlを記載 ※サンプル

## Azure Resouce定義
variables:
# Project
  projectName: 'Demo_LogicApps' #プロジェクト名 任意の命名

# Azure TenantID
  azuretenantID: '<AzureテナントID>'

# Azure Service Connection 
  devServiceConnection: '<サービスコネクション名>'

# Resource Group
  resourceGroupName: '<デプロイ先リソースグループ名>'
  location: '<リージョン>'

# Logic App
  logicAppName: '<ワークフローデプロイ先Logic Apps名>'

# Project Artifacts
  logicAppCIArtifactName: 'logicapp_publish_artifact' #アーティファクト名 任意の命名

2つ目は、[cid-pipeline.yml]です。

実際にワークフローをデプロイするためにPipelinesでビルドとデプロイを実行するためのYAMLファイルです。デプロイに必要な情報を[pipeline-variables.yml]より参照する形式となっております。

trigger:
- none

pr: none

pool: '<作成したAgent Pool>'

variables:
- template: variables/pipeline-variables.yml # variables.ymlのディレクトリを指定

stages:
- stage: build
  jobs:
  - job: bulid_logic_app
    displayName: 'Build and publish logic app' # 任意のディスプレイ名
    steps:
    - task: CopyFiles@2
      displayName: 'Create project folder' # 任意のディスプレイ名
      inputs:
        SourceFolder: '$(System.DefaultWorkingDirectory)/Demo' #トップディレクトリを指定($(System.DefaultWorkingDirectory)はデフォルト)
        Contents: | # コピーするファイルの指定(ワークフロー格納先を指定)
          workflow/**
        TargetFolder: 'project_output'

    - task: ArchiveFiles@2
      displayName: 'Create project zip' # 任意のディスプレイ名
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)/project_output/workflow' #ルートフォルダーのパスを指定
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: 'C:/Agent/$(Build.BuildId).zip' 
        replaceExistingArchive: true # 既存のアーカイブがある場合、上書きする設定

    - task: PublishPipelineArtifact@1
      displayName: 'Publish project zip artifact' # 任意のディスプレイ名
      inputs:
        targetPath: 'C:/Agent/$(Build.BuildId).zip' # 発行するファイルのパスを指定
        artifact: '$(logicAppCIArtifactName)' # 発行するアーティファクトの名前を指定
        publishLocation: 'pipeline'

- stage: deploy_workflow
  jobs:
  - job: workflow_deploy
    displayName: Deploy Logic App
    variables:
      deploymentMode: 'Incremental'
    steps:
    - task: AzureFunctionApp@1
      displayName: 'Deploy logic app workflows'
      inputs:
        azureSubscription: '$(devServiceConnection)'
        appType: 'functionapp,workflowapp'
        appName: '$(logicAppName)'
        package: 'C:/Agent/$(Build.BuildId).zip'
        deploymentMethod: 'zipDeploy'

Pipelines実行YAMLファイルはビルドステージとデプロイステージに分かれています。

ビルドステージではRepos上に格納したワークフローをzip化し、デプロイをするための準備を行います。
デプロイステージで実際にLogic Appsにワークフローのデプロイを実行します。