Azure API Management インスタンスを Azure DevOps で生成する

IaCと呼んでいいのかなんともあれだが、単にAzure Resource Manager(以下、ARM)テンプレートとAzure DevOpsを使ってパイプラインでAPI Managementインスタンスを作成するだけである(本来ならTerraFormを使うとIaCっぽさが出る。もちろんそれでも可能)。ARMテンプレートでインスタンスを作成するのであれば、QuickStart Templateを使うほうが簡単。テンプレートを自作する場合にも参考になる。

Azure Quickstart Templates
https://azure.microsoft.com/resources/templates/
https://github.com/Azure/azure-quickstart-templates

今回は以下のARMテンプレートを使い、Azure DevOpsを使って自動作成してみる。

Azure API Management instance having an MSI Identity with api-version 2017-03-01
https://github.com/Azure/azure-quickstart-templates/tree/master/101-api-management-create-with-msi

なお、このARMテンプレートにはデフォルト値が入っていない箇所があり、このまま実行するとエラーで止まる。そのため、テンプレートパラメータファイル(azuredeploy.parameters.json)に値を設定するか、もしくはデフォルト値が設定されていないパラメータに対してデフォルト値を設定するよう、ARMテンプレートに手を入れる必要がある。

このエントリでは、説明目的のため以下のようにファイル名を変更している。

種類このエントリでのファイル名QUICKSTART
テンプレートinstance.jsonazuredeploy.json
テンプレートパラメータparameter.jsonazuredeploy.parameters.json

実のところ、このエントリの内容は以下の記事のまんまである。原文ではVSTSを使っているため、リブランドされたAzure DevOpsで、YAMLを使った構成を確認する意味で動作確認した。なお、Azure DevOpsでもVSTSと同じUIで設定できてしまうので、原文の内容通りに実施することもできる。

API Management CI/CD using ARM Templates – API Management Instance
https://blog.eldert.net/api-management-ci-cd-using-arm-templates-api-management-instance/

前提としてAzure DevOpsのアカウントは作成済みとする。アカウントを作成していない場合は以下のページから作成する。

Azure DevOps
https://azure.microsoft.com/en-us/services/devops/

1) プロジェクトの作成

プロジェクト名を指定する。今回は apim-ci-cd-arm とする。バージョン管理はGitを選択。Visibilityはどれでも可。設定が終われば、【Create project】をクリック。

2) リポジトリの作成

以下の手順でリポジトリを作成する。なお、リポジトリの作成には複数のルートがあるが、今回は以下のやり方を使う。

  1. Azure DevOpsの左側のメニューでReposを選択
  2. 現れる+をクリック
  3. New Repositoryをクリック
  1. 画面右から”Create a repository”の画面が現れるので、ここにリポジトリ名を指定する。今回はAPI Management Instanceとした。
  2. 入力したら【Create】をクリック。

3) リポジトリのクローン

作成したリポジトリに移動し、リポジトリをクローンしておく。画面右上部の【Clone】をクリックする。

HTTPSもしくはSSHでのクローンが選択できる。IDEでクローンもできる。Git Credentialを生成する必要がある場合には、【Generate Git Credentials】をクリック。

今回はHTTPSでgit cloneを使ってクローンした。

4) ビルド・パイプラインの作成

Pipelines > Pipelinesを選択。

クリックすると、Create Pipelineが現れるので、これをクリック。

利用するリポジトリを選択する(今回はAzure Repos Gitを選択)。ここで旧来のUIを使ってパイプラインを作成したい場合(YAMLベースでない形で作りたい場合)は、Use the classic editorをクリックする。

選択するリポジトリは、先ほど作成したAPI Management Instance。

パイプラインの編集は、今回はYAMLファイルを用意していないので、Starter Pipelineを選択。【Show more】をクリックするといろいろ選択できる。

Review画面で以下のようなYAMLのソースが表示される。これだと当然ながらAPIMのインスタンスを生成できないので、赤枠部分の余分な箇所を削除した。その後【Show assistant】をクリックしてタスクを追加していく。

クリックするとタスクを選択できる。今回はARM Template Deploymentを選択する。これはARMテンプレートやテンプレート・パラメータを使ってリソースを作成するタスク。

デプロイしたいARMテンプレートやそのデプロイ先などを指定する。リソースグループは選択式ではあるが、このフィールドに文字入力できるので、今回はARMテンプレートの検証のためのリソースグループとしてapim-ci-arm-validateというリソースグループを新規作成することにした。今回、ロケーション(リージョン)は東南アジアを選択しているが、これは2020/05/18現在、東西日本でConsumption Tierが使えないからである(さすがにend-to-endテスト完了までに時間がかかりすぎるのはつらいので)。また、テンプレートパラメータを指定することもできる。入力が完了したら、【Add】をクリック。

続いて、検証が成功した場合に、このARMテンプレート検証用のリソースグループを削除するためのタスクを指定する。【Show assistant】をクリックして、deleteと入力すると、以下のタスクが検索結果に表れるので、Delete Resource Group if it is emptyを選択する。

設定項目は、サブスクリプションと削除対象のリソースグループ。リソースグループは先ほど指定したapim-ci-arm-validateを設定し、【Add】をクリック。

最後に、検証済みのアーティファクトをステージング・ディレクトリにコピーする。Publish build artifactsというタスクを使うのだが、このタスクではワイルドカード指定できないため、複数のファイルをパブリッシュするために、

  • Copy filesというタスクを使ってディレクトリにコピー
  • そのディレクトリをパブリッシュする

という仕組みを取る必要がある。今回はテンプレートとテンプレート・パラメータをパブリッシュするため、Copy filesとPublish build artifactsを並べるこの仕組みを使うことにした。

【Show assistant】をクリックして、検索フィールドにCopy filesを指定すると、以下のような検索結果が現れるので、Copy filesを選択。

開いた画面で、Contentsとして*.json、Target Folderとして、$(Build.ArtifactStagingDirectory)を指定。Source Folderはリポジトリのルートを対象にしたいので、空のままでOK。必要に応じて、Advancedの設定も加える(今回は何もしない)。設定が完了したら、【Add】をクリック。

続いて、Publish build artifactsを構成する。以下のようにpublish buildで検索し、現れた検索結果からPublish build artifactsを選択。

Artifact nameとしてValidatedArtifactを指定する。この中に先ほどコピーしたファイルが格納されている。Artifact publish locationはデフォルトでAzure Pipelines、Path to publishはデフォルトで$(Build.ArtifactStagingDirectory) が設定されているはずなので、そのままでOK。設定終了後、【Add】をクリック。

ここまで出来ると、以下のようなYAMLファイルが出来るはず。できあがったら、保存しておく(保存と実行もできるが、ここでは保存のみ)。なお、以下の点に注意が必要。

  • poolのvmImageはLinuxではなく、Windowsでなければらない。これはリソースグループ削除のタスクがPowerShellを使っているため。
  • 不要な部分(script)は削除済み。
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
trigger:
- master
pool:
  vmImage: 'vs2017-win2016'
steps:
- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: 'Resource Group'
    azureResourceManagerConnection: 'Microsoft Azure .... (8....3)'
    subscriptionId: '8....3'
    action: 'Create Or Update Resource Group'
    resourceGroupName: 'apim-ci-cd-arm-validate'
    location: 'Southeast Asia'
    templateLocation: 'Linked artifact'
    csmFile: 'instance.json'
    csmParametersFile: 'parameter.json'
    deploymentMode: 'Validation'
- task: Delete Resource Group if it is empty@1
  inputs:
    ConnectedServiceNameSelector: 'ConnectedServiceNameARM'
    ConnectedServiceNameARM: 'Microsoft Azure .... (8....3)'
    resourceGroupName: 'apim-ci-cd-arm-validate'
- task: CopyFiles@2
  inputs:
    Contents: '*.json'
    TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'ValidatedArtifact'
    publishLocation: 'Container'

5) リリース・パイプラインの作成

Pipelines > Releasesをクリックすると、New pipelineというボタンが現れるので、これをクリック。

最初にステージのJobを指定するように出てくるが、一旦無視する。まずはリリース・パイプラインの名前を変更する(挙動に影響しないので、もちろんデフォルトのままでもよいが)。鉛筆アイコンをクリックして変更しておく。

続いて、Artifactを追加するため、Artifactの +Add をクリック。

Artifactの追加では、ソースの種類はBuildを選択。プロジェクト、ソースリポジトリ、デフォルトのブランチなどを指定していく。Source Aliasは自動生成されるのでこのまま使う。終了したら、【Add】をクリック。

アーティファクトの右肩にある稲妻アイコンをクリック。ここでContinuous deploymentのトリガーを設定する。

Continuous deployment triggerを有効にする。今回、ビルドブランチフィルターはmasterを選択している。Pull request triggerは無効のままでOK。

続いてステージの追加。+Add > + New stageをクリック、もしくは + Add a stageをクリックしてもよい。

テンプレートの選択では、Empty jobからスタートするので、Empty jobをクリック。

ステージ名称は適切なものに変更する。今回はQA environmentとした。続いて、ステージ内のタスクを作成するため、”1 job, 0 task”をクリック。

Agent jobの右側にある+をクリックするとAdd tasksが現れる(このあたりはビルド・パイプラインと同じ)。Azure resource group deploymentを選択する。

Azure detailsの部分はビルド・パイプラインと同じなので説明を省略する。Templateの部分は以下のように設定。

  • Template location : Linked artifact
  • Template: $(System.DefaultWorkingDirectory)/_API Management Instance/ValidatedArtifact/instance.json
  • Template parameters: $(System.DefaultWorkingDirectory)/_API Management Instance/ValidatedArtifact/parameter.json
  • Deployment mode: Incremental

なお、テンプレートとテンプレート・パラメータは右側の【…】をクリックし、現れる画面で_API Management Instance (Build) をクリックすると、ビルド・パイプラインでコピー先として指定したValidatedArtifactがあるので、これを選択。この中にファイルがある場合はそれを選択し、ない場合はフォルダのみ選択して【OK】をクリックし、/instance.jsonもしくは/parameter.jsonを補完する。

ここまで出来たら、一旦保存しておく。

6) テスト実行

ビルド・パイプラインは保存していただけなので、テスト実行してみる。Pipelines > Pipelinesを選択すると、以下のような画面が現れるので、API Management Instanceの最も右側のアイコンをクリックして、Run pipelineを選択。

以下のような画面が出るので、【Run】をクリック。ここでは特に設定項目はない。必要であれば、システム診断を有効化してもよい。

あとはAzure DevOpsのジョブ実行を待つのみ。ログを見ることもできるが、このあたりは通常のAzure DevOpsと何も変わりはないので説明を割愛する。ビルド・パイプラインが成功すると、リリース・パイプラインが呼び出されることも確認できる。

首尾良く行けば、指定したリージョン、リソースグループにAPIMのインスタンスができあがっているはず。インスタンス名を変えたい場合には、ARMテンプレート内で定義している変数apiManagementServiceNameの構成方法を変える必要がある。あと、Consumption Tierを選択する場合、テンプレートパラメータもしくはOverride template parametersでConsumptionと指定するとともに、skuCountを0(ゼロ)に指定する必要がある点に注意(instance.jsonで定義されているデフォルト値は1)。変更しないとインスタンス作成に失敗する。

6) リリース・パイプラインを変更して、本番系のインスタンス作成のためのステージを作成する

QA環境はこれでできあがりなので、このステージをクローンして本番系のインスタンスを作成する。なお、作成前にレビューが必要という条件を付け、かつSKUをPremiumにしたい、という要件があった場合を想定する。

リリース・パイプラインを選択し、編集画面に入る。QA environmentの下にあるアイコンをクリックするとクローンできる。

クローンしたら、赤線で囲んだ部分をクリックし、トリガーを変更する。

デプロイ条件として、「QA environmentへのデプロイが完了」を前提とすれば、以下のような設定が必要。

デプロイ前の承認を有効にして、承認者を決める。ユーザーでもグループでもかまわない。今回はリクエストした人間が承認しないように、Approval policiesを指定している。

続いて、赤線で囲んだ “1 job, 1 task”をクリックする。

ステージ名をProduction environmentに変更する。さらに、ARMテンプレートのデプロイタスクの名称もわかりやすく変更しておく。今回は “Azure Deployment: apim-ci-cd-arm-prod” にした。

このままでは、QA環境と同じSKUのインスタンスを作成してしまうため、Override template parametersを使って書き換える。右側のアイコンをクリック。

クリックすると、変更可能な値がリストで表示されるため、適宜設定する。今回はSKUとしてPremiumを指定。

設定完了すると、以下のようにOverride template parametersが設定されるので、これでステージを保存。

できあがるとこんな感じ。

7) End to end test

End to endテストのため、ビルド・パイプラインをマニュアル実行する。これは5) と同じなので詳細は割愛する。QA環境が出来ると、Production環境作成の前に承認依頼がメールで送信されてくる。リリース・パイプラインの状況はPending approvalをクリックして確認できる。

承認・却下はApproveをクリックした上でコメントを入れて決裁するかたち。

デプロイをキャンセルしたい場合、Approveの右にマウスをホバリングすると、Cancel deploymentが選択できるので、これをクリックすればOK。

あとはひたすら待つ。無事にインスタンスが出来ればおしまい。リリース・パイプラインでも正常終了していることを確認しておく。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中