Bicep モジュールを作成して使用する
モジュールは、独立した Bicep ファイルです。 通常、一緒にデプロイされるリソースのセットが入っています。 モジュールは、他の Bicep テンプレートから使用できます。
モジュールを使うと、Bicep コードを再利用できるだけでなく、Bicep ファイルが読みやすく、わかりやすくなります。それぞれが特定のジョブを担当するからです。 そして、メイン テンプレートによって、複数のモジュールを組み合わせます。
モジュールの利点
この玩具会社であなたは、多数の個々の Bicep ファイルを使用してクラウド リソースをプロビジョニングしてきました。 時間が経つにつれ、これらのテンプレートは肥大します。 やがて、読み取りや参照が困難で、保守しにくいモノリシック コードができあがります。
また、この方法では、コードの一部を他のテンプレートで再利用する場合に、それを複製しなければなりません。 何かを変更した場合は、複数のファイルを検索して更新する必要があります。
Bicep モジュールを使用すれば、複数のテンプレートから参照できる、管理しやすい小さなファイルにコードを分割することで、前述の課題に対処できます。 モジュールには、いくつかの重要な利点があります。
再利用性
モジュールを作成した後は、それを複数の Bicep ファイルで再利用できます。異なるプロジェクトまたはワークロードのファイルでも可能です。 たとえば、あるソリューションを構築するときに、アプリ コンポーネント、データベース、ネットワーク関連リソースのために別々のモジュールを作成するとします。 その後、同様のネットワーク要件を持つ別のプロジェクトの作業を開始するときに、該当のモジュールを再利用できます。
モジュールをチーム内または組織内で共有したり、Azure コミュニティと共有したりすることもできます。 Bicep モジュールの共有の詳細については、後の Microsoft Learn モジュールで説明します。
カプセル化
モジュールを使用すると、関連するリソース定義をまとめて保持することができます。 たとえば、Azure Functions アプリを定義する場合は通常、アプリ、アプリのホスティング プラン、アプリのメタデータのストレージ アカウントをデプロイします。 これらの 3 つのコンポーネントは、個別に定義されますが、1 つの論理的なリソースのグループに相当します。そのため、これらを 1 つのモジュールとして定義することは合理的でしょう。
そうすれば、メイン テンプレートでは、関数アプリのデプロイ方法の詳細を認識する必要はありません。 モジュールにはこうした役割があります。
構成可能性
一連のモジュールを作成したら、それらを組み合わせることができます。 たとえば、仮想ネットワークをデプロイするモジュールと、仮想マシンをデプロイする別のモジュールを作成するとします。 それぞれのモジュールにパラメーターと出力を定義することで、一方から重要な情報を取得し、もう一方に送信することができます。
ヒント
Bicep モジュールを、デプロイをサポートするためにさまざまな方法で組み合わせ可能な構成要素と見なすことができます。
機能
場合によっては、モジュールを使用して特定の機能にアクセスする必要があります。 たとえば、モジュールとループを一緒に使用して、複数のリソース セットをデプロイできます。 また、モジュールを使用して、1 つのデプロイで複数の異なる範囲にリソースを定義することもできます。
モジュールを作成する
モジュールは通常の Bicep ファイルです。 他の Bicep ファイルと同じ方法で作成します。
通常、デプロイするリソースごとにモジュールを作成するのは適切ではありません。 一般に、適切な Bicep モジュールは、関連した複数のリソースを定義したものです。 ただし、構成が多く、複雑なリソースがある場合は、その複雑さをカプセル化する 1 つのモジュールを作成することをお勧めします。 こうした方法により、メイン テンプレートをシンプルで、整った状態に保てます。
既存の Bicep テンプレートをモジュールに分割する
大規模な Bicep テンプレートが構築されたため、複数のモジュールに分割する必要があると判断したとします。 大規模な Bicep ファイルをどのように分割すればよいか、すぐにわかる場合もあります。 明らかに同じモジュールに属する、一連のリソースがあります。 一方、同じモジュールにグループ化する必要があるリソースを簡単に判断できない場合もあります。
Bicep ビジュアライザーは、Bicep ファイルの全体像を適切に把握するのに役立ちます。 ビジュアライザーは Visual Studio Code の Bicep 拡張機能に含まれています。
ビジュアライザーを表示するには、Visual Studio Code エクスプローラーを開き、Bicep ファイルを長押し (または右クリック) して、[Bicep Visualizer を開く] を選びます。 ビジュアライザーは、Bicep ファイル内のリソースをグラフィカルに表示します。 Bicep で検出された依存関係は、リソース間の線で示されます。
ビジュアライザーを使用すれば、ファイルを分割しやすくなります。 この視覚化で、リソースがかたまりとして示されていないか確認します。 そのようなかたまりをモジュールにまとめるのは、理にかなっているでしょう。
例として、以下に示す Bicep ファイルの視覚化について検討します。 2 つの別個のリソース セットが定義されています。 これらを別個のモジュール "データベース" と "ネットワーク" にグループ化するのは理にかなっています。
モジュールを入れ子にする
モジュールには、他のモジュールを含めることができます。 入れ子にするこの手法を使用すると、小規模なリソース セットをデプロイするモジュールをいくつか作成してから、それらを組み合わせることで、複雑なトポロジのリソースを定義する大規模なモジュールを作成できます。 テンプレートによって、それらの要素が組み合わされて、デプロイ可能な 1 つの成果物となります。
ヒント
何層ものモジュールを入れ子にすることもできますが、複雑になるおそれがあります。 エラーや他の障害が発生した場合、多層の入れ子になっていると、修正の必要な箇所の特定が難しくなります。
複雑なデプロイでは、入れ子を使用してすべてを網羅する単一のテンプレートを作成するのではなく、デプロイ パイプラインを使用して複数のテンプレートをデプロイする方が合理的な場合があります。 デプロイ パイプラインの詳細については、後の Microsoft Learn モジュールで説明します。
適切なファイル名を選択する
各モジュールには、わかりやすいファイル名を使用してください。 ファイル名は事実上、モジュールの識別子になります。 同僚がファイル名を見ればモジュールの目的を理解できるようにすることが重要です。
Bicep テンプレートでモジュールを使用する
Bicep テンプレートで、次のように module キーワードを使用してモジュールを使用します。
module appModule 'modules/app.bicep' = {
name: 'myApp'
params: {
location: location
appServiceAppName: appServiceAppName
environmentType: environmentType
}
}
モジュール定義には、次のコンポーネントが含まれています。
moduleキーワード。- シンボリック名 (
appModuleなど)。 この名前は、この Bicep ファイル内で、モジュールを参照するときに使用されます。 シンボリック名が Azure で表示されることはありません。 - モジュールのパス (
modules/app.bicepなど)。 これは通常、ローカル ファイル システム上の Bicep ファイルへのパスです。 後の Microsoft Learn モジュールでは、独自のモジュール パス形式を持つ、レジストリとテンプレート スペックを使用してモジュールを共有する方法について説明します。ヒント
また、JSON Azure Resource Manager テンプレート (ARM テンプレート) をモジュールとして使用することもできます。 この機能は、まだ Bicep に移行していない一連のテンプレートがある場合に役立ちます。
nameプロパティ。デプロイの名前を指定します。 デプロイについては、次のセクションで詳しく説明します。paramsプロパティ。モジュールが必要とするパラメーターの値を指定できます。 モジュール パラメーターについては、次のユニットで詳しく説明します。
モジュールの仕組み
モジュールの仕組みを理解していることは、モジュールを使用する上で必須ではありませんが、デプロイに関する問題を調査したり、予期しない動作を説明したりする上で役立ちます。
デプロイメント
Azure での "デプロイ" とは、デプロイ操作を表す特別なリソースです。 デプロイは、リソースの種類が Microsoft.Resources/deployments である Azure リソースです。 Bicep デプロイを送信すると、デプロイ リソースが作成または更新されます。 同様に、Azure portal でリソースを作成すると、このポータルによってデプロイ リソースが自動的に作成されます。
ただし、Azure リソースに対する変更によっては、デプロイが作成または使用されない場合があります。 たとえば、Azure portal を使用して既存のリソースを変更する場合は、通常、変更を加えるためのデプロイは作成されません。 Terraform などのサードパーティ製のツールを使用してリソースをデプロイまたは構成する場合は、デプロイが作成されないことがあります。
Azure CLI または Azure PowerShell を使用して Bicep ファイルをデプロイする場合は、必要に応じてデプロイの名前を指定できます。 名前を指定しない場合、Azure CLI または Azure PowerShell によって、テンプレートのファイル名を元にデプロイ名が自動的に作成されます。 たとえば、main.bicep という名前のファイルをデプロイする場合、既定のデプロイ名は main です。
モジュールを使用する場合、Bicep ではモジュールごとに個別のデプロイが作成されます。 モジュールに指定した name プロパティは、デプロイの名前になります。 モジュールを含む Bicep ファイルをデプロイすると、複数のデプロイ リソースが作成されます。親テンプレート用に 1 つ、モジュールごとに 1 つずつ作成されます。
たとえば、main.bicep という名前の Bicep ファイルを作成するとします。 myApp という名前のモジュールが定義されています。 main.bicep ファイルをデプロイすると、2 つのデプロイが作成されます。 最初のものは main という名前です。また、アプリケーション リソースが含まれる myApp という名前のもう 1 つのデプロイも作成されます。
デプロイ リソースの詳細を一覧表示して参照することで、Bicep デプロイの状態を監視したり、デプロイの履歴を確認したりできます。 ただし、デプロイに同じ名前を再使用すると、Azure によって、同じ名前を持つ最後のデプロイが上書きされます。 デプロイの履歴を維持する必要がある場合は、デプロイごとに一意の名前を使用してください。 名前にデプロイの日時を含めると、一意の名前を付けるのに役立ちます。
生成される JSON ARM テンプレート
Bicep ファイルをデプロイすると、Bicep によってそれが JSON ARM テンプレートに変換されます。 この変換は、"トランスパイル" とも呼ばれます。 テンプレートで使用されるモジュールは、JSON ファイルに埋め込まれます。 テンプレートに含めるモジュールの数に関係なく、JSON ファイルが 1 つだけ作成されます。
前のセクションで説明した例では、2 つの Bicep ファイルがありましたが、Bicep によって 1 つの JSON ファイルが生成されます。
