Azure Pipelines で実現する IaC - 第 3 回 Azure リソーステスト

湯下達郎

2020年08月03日

1. はじめに

皆さん、こんにちは！動物好きの湯下です。
第 3 回となる今回は、Pester による Azure リソースのテストについてご紹介します。

第 1 回：Introduction
第 2 回：Azure リソースプロビジョニング
第 3 回：Azure リソーステスト ← イマココ
第 4 回：OS・MW コンフィグレーション

まず、「Pester」というツールを初めて聞く方に向けて、Pester について簡単に触れておきます。

2. Pester とは

Pester とは、オープンソースソフトウェアとして開発されている PowerShell 向けのテスティングフレームワークです。

Quick Start | Pester

通常、PowerShell スクリプトの自動テストを行う際に使用されますが、ARM Template の中身や ARM Template の実行結果を PowerShell オブジェクトとして扱うことで、Azure リソースに対する自動テストが可能となります。

具体的には、以下のようなテストを自動化できます。

[ プロビジョニング前 ]

パラメーターファイルで指定した値が間違っていないかをチェックする
ARM Template の dry run により、構文の誤りや Azure リソースの競合などが無いかをチェックする

[ プロビジョニング後 ]

ARM Template のプロビジョニングが正常に完了したかをチェックする
Azure リソースの設定値があるべき値であるかどうかをチェックする

特に、最後のケースはセキュリティ設定の包括的なチェックにも活用できます。例えば、NSG (仮想ネットワーク用のファイアウォール機能) の割り当て設定や送受信ルールが意図した通りに設定されているかをチェックする際にとても便利です。

3. 今回のシナリオ

前回の記事では、Azure Repos 上に Push した ARM Template を基に Azure リソースのプロビジョニングを行いましたので、今回はそれらの Azure リソースの設定が意図したものであるかをテストしてみましょう。

具体的には、仮想ネットワークのサブネットに NSG が適切に割り当てられているかをテストするデモになります。

4. Azure Pipelines で Pester を使うには

今回は、Azure Pipelines で標準で利用できる PowerShell Script タスクを使用し、リリースパイプラインに組み込んでみます。

■ 設定手順

4-1. Pester テストファイルを作成し、Azure Repos に Push する

以下は、今回デモ用に作成したテストファイル本体となります。なお、Azure に接続し、設定状態を取得する部分 (az login, az resource show 等) は、Azure CLI コマンドを使用していますが、Azure PowerShell を使っても同様のことが行えます。

Test-NsgSettings.tests.ps1

左右にスクロールしてご覧ください。


param(
    [Parameter(Mandatory)]
    [string]$clientSecret_s
)

# アプリケーション ID の URL を設定
$applicationIdUrl = $env:APPLICATIONIDURL

# シークレットを設定
$clientSecret = $clientSecret_s

# Azure AD テナント ID を設定
$tenantId = $env:TENANTID

# サブスクリプション ID を設定
$subscriptionId = $env:SUBSCRIPTIONID

# テスト対象が含まれるリソース グループを指定
$resourceGroupName = "pester-jpe-test-rg01" # 環境に合わせて変更

Describe "Network Security Group (NSG) 設定値確認" {

    BeforeAll {
        # サブスクリプション認証 & 選択
        az login --service-principal -u $applicationIdUrl -p $clientSecret --tenant $tenantId
        az account set --subscription $subscriptionId
    }

    AfterAll {
        $DebugPreference = "SilentlyContinue"
    }

    Context "NSG 割り当て状態をテストする" {
        It "NSG [nsg01] は、VNet [vnet01] のサブネット [subnet01] に割り当てられているべき" {

            # テスト対象 (プレフィックス : _t)
            $resourceProviderName_t = "Microsoft.Network/networkSecurityGroups"
            $resourceName_t = "nsg01" # 環境に合わせて変更
            $resourceId_t = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/$resourceProviderName_t/$resourceName_t"

            # 期待するテスト結果 (プレフィックス : _e)
            $vnetName_e = "vnet01" # 環境に合わせて変更
            $subnetName_e = "subnet01" # 環境に合わせて変更
            $value_e = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Network/virtualNetworks/$vnetName_e/subnets/$subnetName_e"

            # Azure CLI を使用して現在の設定を取得する
            $rawResponse = az resource show --ids $resourceId_t | ConvertFrom-Json
            $currentStatus = $rawResponse.properties

            # テストを実行する
            $currentStatus.subnets.id | Should -Be $value_e

        }
    }
}

※ # 環境に合わせて変更の部分は、ご自身の Azure 環境に合わせて変更してください。

また、以下はパイプラインで使用する PowerShell Script タスクで実行するラッパーファイルになります。つまり、このファイルを通じて、上記の Pester テストファイルを実行します。

Run-Pester.ps1

左右にスクロールしてご覧ください。


param(
    [Parameter(Mandatory)]
    [string]$clientSecret
)

# Pester のインストール
Install-Module -Name Pester -Force -SkipPublisherCheck

# Pester の実行
Invoke-Pester -Script @{ Path = "$env:System_DefaultWorkingDirectory\$env:RELEASE_PRIMARYARTIFACTSOURCEALIAS\<テスト ファイルのディレクトリ パス>\Test-NsgSettings.tests.ps1"; Parameters = @{clientSecret_s = $clientSecret} } -EnableExit

※ テストファイルをリポジトリのルートディレクトリに配置した場合は <テストファイルのディレクトリパス>\ の部分は不要です。サブディレクトリ (例 : pester\src\) にテストファイルを配置した場合は、<テストファイルのディレクトリパス>\ の部分は pester\src\ となります。

ちなみに、このラッパーファイルは、サービスプリンシパルのシークレットを secure タイプのパイプライン変数 (後述) から読み出して Pester テストファイル内で利用するために作成しました。パイプライン設定を工夫したり他のタスクを利用することで、もっとシンプルに記述できるかもしれません (^_-)☆

4-2. サービスコネクションを構成する

前述の Pester テストファイルでは Azure CLI で Azure に接続し、現在の NSG 設定を取得する実装になっています。そのため、Azure に認証するためにサービスプリンシパルを作成し、それを Azure DevOps の「サービスコネクション」として登録する必要があります。サービスプリンシパルの作成方法については、以下のようなドキュメントを参考にして頂ければと思います。

方法: リソースにアクセスできる Azure AD アプリケーションとサービスプリンシパルをポータルで作成する

サービスプリンシパルの作成後、画面左下部の [Project settings] から [Service connections] - [New service connection] の順にクリックします。

[Azure Resource Manager] を選択し、[Next] をクリックします。

[Service principal (manual)] を選択し、[Next] をクリックします。

必要な情報を入力し、[Verify and save] をクリックします。

4-3. リリースパイプラインを作成する

[Pipelines] の [Releases] で、[+ New] - [New release pipeline] の順にクリックします。

[Empty job] をクリックします。

ボタンをクリックします。

なお、リリースパイプライン名については、[New release pipeline] 付近をマウスオーバーすると鉛筆マークが表示されるので、これをクリックすると変更できます。

[Artifacts] の [+ Add an artifact] をクリックします。

[Source type] で [Azure Repos Git] を選択し、プロジェクトとリポジトリを指定して [Add] をクリックします。

先程のステージ内の [1 job, 0 task] をクリックして、タスクを設定していきます。

パイプライン処理時にバックエンドで実行されるマシンの種類やバージョンは [Agent Job] 設定の [Agent Specification] から選択できます。

今回は最新の Windows Server である [windows-2019] を設定してみます。

[Agent Job] の [+] をクリックします。

[Add tasks] 内の検索フォームで [PowerShell] と検索し、表示されたタスク [PowerShell] で [Add] をクリックします。

[Script Path] に、事前に Push しておいたラッパーファイルを選択します。(右の [...] ボタンから選択すると簡単です)

また、[Arguments] には -clientSecret "$(CLIENTSECRET)" と指定します。

[Variables] タブの [Pipeline variables] で [+ Add] をクリックし、Azure CLI での Azure サブスクリプション認証に必要な情報 (アプリケーション ID の URL、シークレット、テナント ID、サブスクリプション ID) を変数として登録します。

※ 変数 CLIENTSECRET にはサービスプリンシパルのシークレットを格納することから、Value を登録する際に表示される鍵アイコンをクリックして secure な値として登録します。