変換されたテンプレートをテストおよびデプロイする

  • 4 分

リファクター フェーズ中に Bicep ファイルを改善した後、そのファイルをテストして Azure 環境にデプロイする必要があります。 推奨ワークフローの 4 番目と 5 番目のフェーズは、''テスト'' フェーズと ''デプロイ'' フェーズです。

Diagram that shows the test and deploy phases of the recommended workflow for migrating Azure resources to Bicep.

これら 2 つのフェーズの主な焦点は、利用可能なツールを使用して Bicep ファイルをテストし、そのファイルを Azure 環境にデプロイすることです。

テスト フェーズ

Bicep へのリソース移行のテスト フェーズの目標は、移行されたテンプレートの整合性を検証し、テスト配置を行うことです。

テスト フェーズは、この順序で実行する 2 つのステップで構成されます。

  1. ARM テンプレート デプロイの What-If 操作を実行する。
  2. テスト デプロイを行う。

Diagram that shows a Bicep file being tested and deployed to Azure.

What-If 操作では、Bicep ファイルをデプロイするときに行われる変更のプレビューが提供されます。 テスト配置を使用して、元のリソースと新しくデプロイされるリソースを比較します。

ARM テンプレート デプロイの What-If 操作とは

新しいリソースをデプロイしたり、既存のリソースを変更したりすると、環境に破壊的変更が生じる可能性があります。 デプロイでは既存のリソースが変更または削除されたり、正しく構成されていない新しいリソースが作成されたり、アプリケーションの全体的な機能に影響を及ぼす可能性があります。

ARM テンプレート デプロイの What-If 操作は、デプロイ前に変換されたテンプレートを確認するのに役立ちます。 これにより、環境の現在の状態と、テンプレートで定義されている意図される状態が比較されます。 このツールでは、環境に変更を適用 ''せず'' に発生する変更の一覧が出力されます。 このプロセスによりデプロイの信頼度が向上します。 増分および完全モードの両方のデプロイで、What-If を使用できます。 増分モードを使用してテンプレートをデプロイする予定の場合でも、What-If 操作を完全モードで実行することをお勧めします。 What-If 操作を実行すると、誤ってテンプレートから漏れた可能性があるリソースを特定するのに役立ちます。

Note

What-If 操作では、一部のリソース プロパティが削除済みとして一覧表示される場合がありますが、実際には変更されません。 それらの結果は ''ノイズ と見なされます。

テスト デプロイ

変換された Bicep テンプレートを運用環境に導入する前に、複数のテスト デプロイを実行することを検討してください。 複数の環境 (運用、開発、テスト) がある場合は、まず、非運用環境のいずれかにテンプレートをデプロイすることをお勧めします。 デプロイ後に、元のリソースと新しいリソースのデプロイの整合性を比較します。

ヒント

非運用環境でデプロイをテストするためのアクセス権がない場合は、代わりに新しい環境に Bicep テンプレートをデプロイします。

デプロイ フェーズ

Bicep へのリソース移行のデプロイ フェーズの目標は、最終的な Bicep ファイルを運用環境にデプロイすることです。 運用環境にデプロイする前に、考慮すべきことがいくつかあります。

デプロイ フェーズは、この順序で実行する 4 つのステップで構成されます。

  1. ロールバック計画を準備する。
  2. 運用環境に対して What-If 操作を実行する。
  3. Bicep ファイルを手動でデプロイします。
  4. "スモーク テスト" を実行します。

これらの手順は、運用環境のデプロイで発生する可能性のある問題に備えるために役立ちます。

Diagram that shows a Bicep file being deployed to Azure.

ロールバック計画を準備する

デプロイの失敗から回復する機能は非常に重要です。 環境に破壊的変更が加えられた場合に使用するため、時間をかけてロールバック計画を作成します。 計画では、組織の事業継続とディザスター リカバリー (BCDR) 戦略を考慮する必要があります。 仮想マシン、Web アプリ、データベースなど、デプロイされているリソースの種類のインベントリを取得します。 また、各リソースのデータ プレーンも考慮する必要があります。 仮想マシンとそのデータを回復する方法はありますか? 削除された後でデータベースを回復する方法、またはストレージ アカウントからデータを回復する方法はありますか。 適切に開発されたロールバック計画を使用すると、デプロイで問題が発生した場合にダウンタイムを最小限に抑えることができます。

運用環境に対して What-If 操作を実行する

他の環境に対して What-If 操作を既に実行しているため、新しい Bicep ファイルによって破壊的変更が発生しないことが確認されています。 最終的な Bicep ファイルを運用環境にデプロイする前に、運用環境に対して What-If 操作を実行します。 運用環境のパラメーター値を使用し、結果を文書化することを検討してください。

手動でデプロイする

Azure DevOps や GitHub Actions などのパイプラインで変換されたテンプレートを使用する場合は、まずローカル コンピューターからデプロイを実行することを検討します。 テンプレートを運用パイプラインに追加する前に、テンプレートの機能を確認することをお勧めします。 テンプレートがどのように機能するかを確認したら、問題が発生した場合に迅速に対応できます。

スモーク テストを実行する

デプロイが完了したら、一連の "スモーク テスト" を実行することをお勧めします。 スモーク テストとは、アプリケーションまたはワークロードが機能することを検証する簡単なチェックです。 たとえば、パブリック インターネットや企業 VPN などの通常のアクセス チャネルを介して、Web アプリにアクセスできるかどうかをテストします。 データベースの場合は、データベースに接続し、一連のクエリを実行してみます。 仮想マシンでは、仮想マシンにサインインし、すべてのサービスが稼働していることを確認します。