モジュールを使用して関連リソースをグループ化する

  • 6 分

最近の製品の立ち上げでは Bicep テンプレートの使用を開始しましたが、これは成功しました。 テンプレート ファイルでリソースを宣言したので、Azure portal にリソースを手動で構成することなく、新しい玩具の立ち上げ用のリソースをすばやくデプロイすることができます。

IT 管理者は、Bicep コードがより複雑になり、リソースの数が増加していることを確認できます。そのため、コードをより モジュール化できるかどうかを確認できます。 配置のさまざまな部分に対して、モジュールと呼ばれる個別の Bicep ファイルを作成できます。 メインの Bicep テンプレートは、これらのモジュールを参照できます。 背後では、モジュールはデプロイのために 1 つの JSON テンプレートにファイルされます。

モジュールは、Bicep コードを再利用しやすくする方法でもあります。 他の多くの Bicep テンプレートで使われる 1 つの Bicep モジュールを持つことができます。

また、多くの場合、Bicep モジュールとテンプレートからの出力を行う必要があります。 出力は、Bicep コードが、デプロイを開始したユーザーまたは何らかにデータを送り返すための手段です。 まず、出力を見てみましょう。

注意

このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。

出力

Bicep テンプレートは、人の手により配置することも、何らかの自動化されたリリース プロセスでデプロイすることもできます。 どちらの場合も、テンプレートのデプロイを実行しているユーザーまたは何らかに返信する必要があるデータをテンプレートから取得するのが一般的です。

次に、テンプレートのデプロイから情報を取得する必要があるシナリオの例をいくつか示します。

  • 仮想マシンをデプロイする Bicep テンプレートを作成し、コンピューターに SSH 接続できるようにパブリック IP アドレスを取得する必要があります。
  • 環境名やアプリケーション名などのパラメーターのセットを受け入れる Bicep テンプレートを作成します。 テンプレートでは、式を使用して、デプロイする Azure App Service アプリに名前を付けます。 デプロイ パイプライン内で使用してアプリケーション バイナリを発行できるように、テンプレートによってデプロイされたアプリの名前を出力する必要があります。

これらのシナリオに対して出力を使用できます。 Bicep テンプレートで出力を定義するには、次のように output キーワードを使用します。

output appServiceAppName string = appServiceAppName

出力定義には、いくつかの重要な部分が含まれています。

  • output キーワードは、出力を定義していることを Bicep に指示します。
  • appServiceAppName は出力の名前です。 だれかがテンプレートを正常にデプロイすると、出力値には指定した名前が含まれます。これにより、予期していた値にアクセスできるようになります。
  • string は出力の種類です。 Bicep の出力では、パラメーターと同じ型がサポートされています。
  • 出力ごとに値を指定する必要があります。 パラメーターとは異なり、出力には常に値が必要です。 出力値には、式、パラメーターまたは変数への参照、またはファイル内に配置されるリソースのプロパティを指定できます。

ヒント

出力では、変数およびパラメーターと同じ名前を使用できます。 この規則は、テンプレートのリソース内で使用する複雑な式を変数内に構築して、その変数の値を出力として公開する必要がある場合に役立ちます。

出力のもう 1 つの例を次に示します。 この値は、パブリック IP アドレス リソースの完全修飾ドメイン名 (FQDN) に設定されます。

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

ヒント

リソースの動作を想定するのではなく、出力としてリソース プロパティを使用してみてください。 たとえば、App Service アプリの URL の出力が必要な場合は、URL の文字列を自分で作成するのではなく、アプリの defaultHostName プロパティを使用します。 これらの前提条件は、異なる環境によっては、適切でない場合や、リソースの動作が変化する場合があります。したがって、リソースには独自のプロパティを指定する方が安全です。

注意事項

接続文字列やキーなどのシークレット値の出力は作成しないでください。 リソース グループへのアクセス権を持つすべてのユーザーは、テンプレートからの出力を読み取ることができます。 シークレット リソースのプロパティにアクセスするために使用できる他の方法もあります。これについては、後のモジュールで説明します。

モジュールを定義する

Bicep モジュールを使用すると、テンプレートに構成できるより小さな単位を作成することで、Bicep コードを整理して再利用することができます。 任意の Bicep テンプレートを別のテンプレートでモジュールとして使用できます。 このラーニング モジュール全体で、Bicep テンプレートを作成しました。 つまり、Bicep モジュールとして使用できるファイルが既に作成されています。

ソリューション A のアプリケーション、データベース、およびネットワーク リソースをデプロイする Bicep テンプレートがあるとします。このテンプレートを 3 つのモジュールに分割することもできます。それぞれのモジュールは独自のリソースセットに焦点を合わせています。 さらに、他のソリューションの他のテンプレートでもモジュールを再利用できるようになりました。そのため、ソリューション A と同様のネットワーク要件を持つソリューション B 用のテンプレート開発する場合は、ネットワーク モジュールを再利用できます。

Diagram that shows a template for solution A referencing three modules: application, database, and networking. The networking module is then reused in another template for solution B.

テンプレートにモジュール ファイルへの参照を含める場合は、module キーワードを使用します。 モジュール定義はリソース宣言に似ていますが、リソースの種類と API バージョンを含めるのではなく、モジュールのファイル名を使用します。

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

このモジュール定義の重要な部分について詳しく見てみましょう。

  • module キーワードは、別の Bicep ファイルをモジュールとして使用することを Bicep に指示します。
  • リソースと同様に、モジュールには myModule のような "シンボル名" が必要です。 テンプレートの他の部分でモジュールの出力を参照するときは、シンボル名を使用します。
  • modules/mymodule.bicep は、テンプレート ファイルに相対的なモジュール ファイルへのパスです。 モジュール ファイルは通常の Bicep ファイルであることに注意してください。
  • リソースと同様に、name プロパティは必須です。 Azure では、テンプレート ファイル内のモジュールごとに個別のデプロイが作成されるため、モジュール名が使用されます。 これらの展開には、それらを識別するために使用できる名前が付いています。
  • params キーワードを使用して、モジュールの任意の パラメーターを指定でき ます。 テンプレート内の各パラメーターの値を設定すると、式、テンプレート パラメーター、変数、テンプレート内にデプロイされたリソースのプロパティ、および他のモジュールからの出力を使用できます。 Bicep は、リソース間の依存関係を自動的に理解します。

モジュールと出力

テンプレートと同様に、Bicep モジュールは出力を定義できます。 テンプレート内にモジュールをまとめるのが一般的です。 その場合、あるモジュールからの出力を別のモジュールのパラメーターにすることができます。 モジュールと出力を一緒に使用することで、強力で再利用可能な Bicep ファイルを作成できます。

モジュールを設計する

優れた Bicep モジュールは、いくつかの重要な原則に従います。

  • モジュールには明確な目的があります。 モジュールを使用して、ソリューションの特定の部分に関連するすべてのリソースを定義することができます。 たとえば、アプリケーションの監視に使用されるすべてのリソースを含むモジュールを作成することができます。 また、モジュールを使用して、すべてのデータベース サーバーやデータベースと同様に、一緒に属する一連のリソースを定義することもできます。

  • すべてのリソースを独自のモジュールに配置しないでください。 デプロイするリソースごとに個別のモジュールを作成しないでください。 多くの複雑なプロパティを持つリソースがある場合は、そのリソースを独自のモジュールに配置することをお勧めしますが、一般に、モジュールでは複数のリソースを組み合わせる方が適しています。

  • モジュールには、意味のある明確なパラメーターと出力が必要です。 モジュールの目的を検討します。 モジュールでパラメーター値を操作する必要があるかどうか、または親テンプレートでそれを処理してから、1 つの値をモジュールに渡す必要があるかどうかについて考えます。 同様に、モジュールから返される出力について考えてみます。また、モジュールを使用するテンプレートに対してこれらの出力が有用であることを確認します。

  • モジュールは、可能な限り自己完結型である必要があります。 モジュールがモジュールの一部を定義するために変数を使用する必要がある場合は、通常、変数を親テンプレートではなくモジュール ファイルに含める必要があります。

  • モジュールでシークレットを出力することはできません。 テンプレートと同様に、接続文字列やキーなどのシークレット値のモジュール出力を作成しないでください。