デプロイ後にリソースをテストする

  • 6 分

Bicep のデプロイを検証してプレビューすることで、Bicep ファイルが正常にデプロイされるという確信が得られました。 しかし、デプロイがすべてではありません。 デプロイの終了後、デプロイが期待通りに実行されたことを確認することも役に立ちます。

このユニットでは、デプロイの終了後に実行できるテストについて学習します。 また、期待どおりになっていない場合に行うデプロイのロールバックについても学習します。

スモーク テストとネガティブ テストを実行する

Bicep ファイルでリソースを定義する場合、Azure でリソースを作成することだけが目的ではありません。 組織の要件を満たしながら、組織の価値を高めることです。 Bicep ファイルを検証してプレビューすると、リソース定義が有効であるという確信が得られますが、必要な処理をリソースで実際に実行できるかどうかがわかるとは限りません。

たとえば、Bicep デプロイ パイプラインを使用して新しい Azure SQL 論理サーバーをデプロイするとします。 サーバーの Bicep 定義は有効で、リンターおよびプレフライト検証のステージを通過します。 what-if コマンドで、サーバーが作成されることが示されます。これは期待どおりです。 デプロイも正常に終了します。 しかし、それでもデプロイ プロセスの最後に、使用準備が整った稼働するデータベース サーバーが得られない場合があります。 次のような理由が考えられます。

  • ネットワーク トラフィックがサーバーに到達できるようにファイアウォール規則を構成していません。
  • サーバーで Microsoft Entra 認証を有効にすべきでない場合に有効にした、またはその逆。

基本的な Bicep ファイルをデプロイするだけの場合であっても、デプロイしたリソースが実際に機能し、要件を満たしていることをどのように検証するかは、検討に値します。 この原則を適用する方法の例を次に示します。

  • Web サイトをデプロイするときは、パイプラインから Web アプリケーションに接続を試みます。 パイプラインから Web サイトに正常に接続でき、有効な応答コードが返されることを確認します。
  • コンテンツ配信ネットワーク (CDN) をデプロイする場合は、CDN を介してリソースに接続を試みます。 パイプラインから CDN に正常に接続でき、有効な応答コードが返されることを確認します。

これらのテストは、"インフラストラクチャ スモーク テスト" と呼ばれることもあります。 スモーク テストは、デプロイの主要な問題を発見するために設計された単純な形式のテストです。

注意

Microsoft ホステッド パイプライン エージェントからは、一部の Azure リソースに容易にアクセスできません。 プライベート ネットワークを介したリソースへのアクセスが必要な場合は、スモークテスト ステージを実行するためにセルフホステッド エージェントの使用を検討する必要がある場合があります。

また、"ネガティブ テスト" を実行することもお勧めします。 ネガティブ テストは、リソースが望ましくない動作をしないことを確認するのに役立ちます。 たとえば、仮想マシンをデプロイするときには、Azure Bastion を使用して仮想マシンに安全に接続するのが推奨される方法です。 パイプラインにネガティブ テストを追加して、リモート デスクトップ接続や SSH を使用して仮想マシンに直接接続できないことを確認することができます。

重要

これらのテストの目的は、Bicep によってリソースが正しくデプロイされたかどうかを確認することではありません。 Bicep を使用する場合、Bicep ファイルに指定したリソースがデプロイされると仮定することになります。 本当の目的は、定義したリソースが状況に応じて動作し、要件を満たすかどうかを検証することです。

Azure Pipelines からテストを実行する

パイプラインでテストを実行する方法はたくさんあります。 このモジュールでは、Pester を使います。これは、PowerShell を使用して書かれたテストを実行するオープンソースのツールです。 他のテスト フレームワークを使用することや、テスト ツールを使用せずにテストを実行することもできます。 たとえば、考慮すべきもう 1 つのテスト ツールとして PSRule for Azure があります。これには、Azure 用に事前に構築された規則とテストが含まれています。 テンプレートの検証や、デプロイされた Azure リソースに対するテストも実行できます。 PSRule のリンクについては「まとめ」を参照してください。

サポートされているテスト フレームワークを使用する場合、Azure Pipelines によって各テストの結果が認識されます。 パイプラインの実行情報と共にテスト結果が表示され、各テストの履歴が長期にわたって追跡されます。 次の演習では、インフラストラクチャ スモーク テストで Azure Pipelines を使用する方法について確認します。

ステップとステージ間でデータを渡す

パイプラインを複数のステージに分割し、それぞれに独自の責任がある場合、これらのステージ間でデータを渡す必要がある場合があります。 たとえば、あるステージで Azure リソースを作成し、別のステージでそれを操作する必要がある場合です。 データを渡すためには、作成されたリソースの名前を第 2 ステージが認識している必要があります。 たとえば、スモーク テスト ステージでは、デプロイ ステージでデプロイされたリソースにアクセスする必要があります。

Bicep ファイルによってリソースがデプロイされるので、そこからリソースのプロパティにアクセスし、デプロイの出力として発行することができます。 パイプラインでデプロイの出力にアクセスすることができます。 Azure Pipelines には、変数を発行してステージ間で使用できるようにするための特別な構文があります。

まず、パイプライン ステージの出力変数を発行する必要があります。 変数を出力するには、パイプライン ログに、Azure Pipelines によって認識できる特別な形式の文字列を書き込みます。 次の例では、myVariable という名前の変数に値 myValue が設定されています。

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines により、パイプライン ログから文字列が読み取られ、解釈され、変数の値が出力として使用できるように処理されます。 この値を他のスクリプトと組み合わせて、Bicep のデプロイ出力の値をパイプライン ステージの出力変数として発行することができます。 このスクリプトを実行する方法については、次の演習で説明します。

次に、この変数をスモーク テスト ステージのジョブに使用できるようにする必要があります。 ジョブの変数を定義し、別の特別な形式の YAML 文字列を使用します。

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

これで、他の変数と同様に、スモーク テスト ジョブ内のすべてのステップから構文 $(myVariable) を使用して myVariable 値にアクセスできるようになります。 この変数は次の演習で使用します。

その他のテストの種類

機能テストと統合テストは、多くの場合、デプロイされたリソースが期待した通り動作していることを確認するために使用されます。 たとえば、統合テストの場合、Web サイトに接続し、テスト トランザクションを送信し、トランザクションが正常に終了するのを確認するために待機する場合があります。 統合テストを使用すると、チームが構築したソリューションだけでなく、それが実行されているインフラストラクチャもテストすることができます。 今後のモジュールでは、これらの種類のテストをパイプラインに追加する方法について説明します。

また、パフォーマンス テストやセキュリティ侵入テストなど、他の種類のテストをデプロイ パイプラインから実行することもできます。 これらのテストについてはこのモジュールで説明しませんが、自動デプロイ プロセスの価値を高めることができます。

ロールバックまたはロールフォワード

パイプラインによるリソースのデプロイは成功しても、テストが失敗したとします。 この場合、何をする必要がありますか。

このモジュールの前半で、Azure Pipelines を使用すると、前のステージが失敗したときに実行される "ロールバック ステージ" を作成できることを学習しました。 このアプローチを使用して、テスト ステージで予期しない結果が報告されたときにロールバック ステージを作成することができます。 また、手動で変更をロールバックすることや、失敗が一時的な問題によるもので、その後解決されたと思われる場合は、パイプライン全体を再実行することができます。

注意

Azure Resource Manager にデプロイを送信するときに、最後に成功したデプロイが失敗した場合は Resource Manager によって自動的に再実行されるように要求することができます。 これを行うには、Azure CLI の手順を使用してファイルをデプロイし、az deployment group create コマンドを使用してデプロイを送信するときに --rollback-on-error パラメーターを追加する必要があります。

多くの場合、ロールバック ステージで実行すべきステップを実行するのは困難です。 一般的に、Bicep のデプロイは複雑であり、変更をロールバックするのは容易ではありません。 特に、デプロイに他のコンポーネントが含まれている場合は、ロールバックが困難になります。

たとえば、Azure SQL データベースを定義する Bicep ファイルがパイプラインによってデプロイされた後、そのデータベースに何らかのデータが追加されたとします。 このデプロイをロールバックする場合、データを削除する必要はありますか。 データベースも削除する必要はありますか。 すべての失敗とすべてのロールバックが実行中の環境にどのように影響するかを予測するのは困難です。

そのため、多くの企業は "ロールフォワード" を好んでいます。つまり、失敗の理由をすぐに修正してから再度デプロイする処理です。 高品質の自動デプロイ プロセスを構築し、これらのラーニング パスで学んだすべてのベスト プラクティスに従うことで、高品質を維持しながら問題を迅速に修正し、Bicep ファイルを再デプロイできるようになります。

ヒント

DevOps の考え方の原則の 1 つは、間違いから学ぶことです。 デプロイをロールバックする必要がある場合は、エラーが発生した理由を慎重に検討し、今後同じ問題が発生しても検出できるように、デプロイを開始する前に自動テストを追加します。