Bicep へ移行する

  • [アーティクル]

Bicep で Azure リソースを定義することには、シンプルな構文、モジュール化、依存関係の自動管理、型の検証と IntelliSense、作成エクスペリエンスの向上など、多くの利点があります。

既存の JSON Azure Resource Manager テンプレート (ARM テンプレート) を Bicep に移行するときは、5 段階のワークフローに従うことをお勧めします。

Azure リソースを Bicep に移行する 5 つのフェーズ (変換、移行、リファクタリング、テスト、デプロイ) を示す図。

プロセスの最初の手順では、Azure リソースの最初の表現をキャプチャします。 必要であれば、JSON ファイルを初期 Bicep ファイルに逆コンパイルして、それをリファクタリングによって改善します。 作業ファイルがある場合は、Azure 環境に破壊的変更を加えるリスクを最小限に抑えるプロセスを使用して、テストとデプロイを行います。

Azure リソースを Bicep に移行するための推奨ワークフローの図。

この記事では、この推奨されるワークフローの概要について説明します。 詳細なガイダンスについては、「Bicep を使用するために Azure リソースと JSON ARM テンプレートを移行する」を参照してください。

フェーズ 1: 変換

リソースを Bicep に移行する "変換" フェーズでの目標は、Azure リソースの初期表現をキャプチャすることです。 このフェーズで作成する Bicep ファイルは完全ではなく、すぐに使用することはできません。 ただし、このファイルを移行の出発点として使用することができます。

変換フェーズは次の 2 つのステップで構成され、これらを順に実行します。

  1. Azure リソースの表現をキャプチャする。 Bicep に変換する既存の JSON テンプレートがある場合、既にソース テンプレートがあるため、最初のステップは簡単です。 ポータルまたは別のツールを使用してデプロイされた Azure リソースを変換する場合、リソース定義をキャプチャする必要があります。 Azure portal、Azure CLI、または Azure PowerShell コマンドレットを使用してリソースの JSON 表現をキャプチャして、ひとつのリソース、複数のリソース、またはリソース グループ全体をエクスポートできます。 Visual Studio Code 内で [リソースの挿入] コマンドを使用して、Azure リソースの Bicep 表現をインポートできます。

  2. 必要に応じて、"逆コンパイル" コマンドを使用し、JSON 表現を Bicep に変換します。Bicep ツールには、テンプレートを変換する decompile コマンドが含まれています。Visual Studio Code と Bicep 拡張機能、Azure CLI、Bicep CLI から decompile コマンドを呼び出すことができます。 逆コンパイル プロセスは、ベストエフォート プロセスであり、JSON から Bicep への完全なマッピングを保証するものではありません。 生成された Bicep ファイルを使用してリソースをデプロイする前に、テンプレートのベスト プラクティスを満たすようにファイルを修正することが必要な場合があります。

注意

リソースをインポートするには、Visual Studio Code コマンド パレットを開きます。 Windows と Linux の場合は Ctrl + Shift + P キー、macOS の場合は ⌘ + Shift + P キーを使います。

Visual Studio Code を使用すると、JSON を Bicep として貼り付けることができます。 詳細については、JSON を Bicep として貼り付けるに関するページを参照してください。

フェーズ 2:移行

リソースを Bicep に移行する "移行" フェーズでの目標は、デプロイ可能な Bicep ファイルの最初のドラフトを作成し、移行のスコープ内にあるすべての Azure リソースを確実に定義することです。

移行フェーズは、3 つのステップで構成され、それらを順に完了します。

  1. 新しい空の Bicep ファイルを作成する。 まったく新しい Bicep ファイルを作成することをお勧めします。 "変換" フェーズで作成したファイルは、参照できる参照点ですが、最終版として扱ったり、そのままデプロイしたりすることはできません。

  2. 逆コンパイルされたテンプレートから各リソースをコピーする。 変換された Bicep ファイルから新しい Bicep ファイルに各リソースを個別にコピーします。 このプロセスは、リソースごとに問題を解決し、テンプレートのサイズが大きくなるとともに生じる混乱を回避するのに役立ちます。

  3. 不足しているリソースを特定して再作成する。 すべての Azure リソースの種類を、Azure portal、Azure CLI、または Azure PowerShell を使用してエクスポートできるわけではありません。 たとえば、DependencyAgentWindows や MMAExtension (Microsoft Monitoring Agent) などの仮想マシン拡張機能は、エクスポート用にサポートされているリソースの種類ではありません。 仮想マシン拡張機能など、エクスポートされていないリソースについては、それらのリソースを新しい Bicep ファイルに再作成する必要があります。 Azure Resource Explorer、Bicep と ARM テンプレート リファレンスのドキュメント、Azure クイックスタート テンプレートのサイトなど、さまざまなツールとアプローチを使用してリソースを再作成できます。

フェーズ 3: リファクタリング

リソースを Bicep に移行する "リファクタリング" フェーズでは、Bicep コードの品質を向上させるのが目標です。 これらの機能強化には、テンプレートとテンプレート標準の足並みを揃えるコード コメントの追加など、変更が含まれることがあります。

デプロイ フェーズは 8 つのステップで構成され、任意の順序で完了します。

  1. リソース API のバージョンをレビューする。 Azure リソースをエクスポートするとき、エクスポートされたテンプレートに、リソースの種類の最新の API バージョンが含まれていない場合があります。 今後のデプロイに必要な特定のプロパティがある場合は、API を適切なバージョンに更新します。 エクスポートされた各リソースの API バージョンを確認することをお勧めします。

  2. 新しい Bicep ファイルでリンターの修正候補をレビューする。 Visual Studio Code 用の Bicep 拡張機能を使用して Bicep ファイルを作成すると、Bicep リンターが自動的に実行され、コードの修正候補とエラーが強調表示されます。 修正候補やエラーの多くには、問題にクイック修正を適用するオプションが含まれます。 これらの推奨事項を確認し、Bicep ファイルを調整します。

  3. パラメーター、変数、およびシンボリック名を変更する。 逆コンパイルによって生成されるパラメーター名、変数名、シンボリック名が、標準の名前付け規則と一致しない可能性があります。 生成された名前を確認し、必要に応じて調整を行います。

  4. 式を簡略化する。 逆コンパイル プロセスでは、Bicep の一部の機能を常に利用できるとは限りません。 変換で生成された式をすべて確認し、それらを簡略化します。 たとえば、逆コンパイル テンプレートには、文字列補間を使用して簡略化できる concat() または format() 関数が含まれる場合があります。 リンターからの修正候補を確認し、必要に応じて調整を行います。

  5. 子および拡張リソースをレビューする。 Bicep には、リソースの名前を連結したり、parent キーワードを使用したり、入れ子になったリソースを使用したりするなど、子リソースおよび拡張リソースを宣言する方法が複数あります。 逆コンパイル後にこれらのリソースを確認し、構造が標準に合っていることを確認することを検討してください。 たとえば、子リソース名の作成に文字列の連結を使用しないようにするには、parent プロパティまたは入れ子になったリソースを使用する必要があります。 同様に、サブネットは、仮想ネットワークのプロパティとして、または別のリソースとして参照できます。

  6. モジュール化する。 多くのリソースを含むテンプレートを変換する場合は、わかりやすくするために個々のリソースの種類をモジュールに分割することを検討してください。 Bicep モジュールを使用すると、デプロイの複雑さを軽減できるだけでなく、Bicep コードの再利用性を高めることができます。

    Note

    Bicep デプロイでは、JSON テンプレートをモジュールとして使用することができます。 Bicep では、JSON モジュールを認識し、Bicep モジュールを使用する場合と同じように参照することができます。

  7. コメントと説明を追加します。 優れた Bicep コードは、"自己文書化" されています。 Bicep を使用すると、インフラストラクチャの文書化に役立つコメントや @description() 属性をコードに追加することができます。 Bicep では、// 文字シーケンスを使用した単一行コメントと、/* で始まり、*/ で終わる複数行コメントの両方がサポートされています。 コード内の特定の行とコードのセクションにコメントを追加することができます。

  8. Bicep のベスト プラクティスに従う。 Bicep ファイルが標準的な推奨事項に従っていることを確認します。 Bicep のベスト プラクティス リファレンス ドキュメントを参照し、見逃した可能性があるものがないかどうかを確認してください。

フェーズ 4: テスト

Bicep へのリソースの移行の "テスト" フェーズでは、移行されたテンプレートの整合性を検証し、テスト デプロイを実行することを目標としています。

テスト フェーズは次の 2 つのステップで構成され、これらを順に実行します

  1. ARM テンプレート デプロイの What-If 操作を実行する。 デプロイ前に変換されたテンプレートを確認するのに役立つように、Azure Resource Manager テンプレート デプロイの What-If 操作を使用できます。 これにより、環境の現在の状態と、テンプレートに定義されている必要な状態が比較されます。 このツールでは、環境に変更を適用 ''せず'' に発生する変更の一覧が出力されます。 増分および完全モードの両方のデプロイで、What-If を使用できます。 増分モードを使用してテンプレートをデプロイする予定の場合でも、What-If 操作を完全モードで実行することをお勧めします。

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

フェーズ 5: デプロイ

Bicep へのリソースの移行の "デプロイ" フェーズでは、最終的な Bicep ファイルを運用環境にデプロイすることを目標としています。

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

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

  2. 運用環境に対して What-If 操作を実行する。 最終的な Bicep ファイルを運用環境にデプロイする前に、運用環境に対して What-If 操作を実行し、運用パラメーターの値を使用して、結果を文書化することを検討してください。

  3. 手動でデプロイする。 Azure DevOps や GitHub Actions などのパイプラインで変換されたテンプレートを使用する場合は、まずローカル コンピューターからデプロイを実行することを検討してください。 運用パイプラインに組み込む前に、テンプレートの機能をテストすることをお勧めします。 そうすれば、問題が発生した場合に迅速に対応できます。

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

次のステップ

Bicep 逆コンパイルの詳細については、「Bicep への ARM テンプレート JSON の逆コンパイル」を参照してください。