プライベート レジストリにモジュールを発行する

完了

これで、Bicep レジストリとは何か、および組織内でモジュールを共有するときにどのように役立つかを理解しました。 このユニットでは、プライベート レジストリにモジュールを発行する方法について説明します。

モジュール パス

過去にモジュールを使用したことがある場合は、テンプレート内でモジュールを参照するのにおそらくモジュールのファイル パスを使用しました。 モジュールとプライベート レジストリを使用する場合は、レジストリ内でモジュールを検索する方法が Bicep で認識されるように、別々のモジュール パスを使用する必要があります。

プライベート Azure コンテナー レジストリ内のモジュールのパスの例を次に示します。

Diagram that shows the syntax for a module path.

パスには、次の 4 つのセグメントが含まれます。

  • スキーム: Bicep では、"スキーム" と呼ばれている種類のモジュールがいくつかサポートされています。 Bicep レジストリを使用する場合、スキームは br です。
  • レジストリ: 使用するモジュールが入っているレジストリの名前。 上の例では、レジストリ名は toycompany.azurecr.io です。これはコンテナー レジストリの名前です。
  • モジュール識別子: レジストリ内のモジュールへの完全なパス。
  • タグ: タグは通常、モジュールのバージョンを表します。これは、1 つのモジュールで複数のバージョンが発行されている可能性があるからです。 タグとバージョンの詳細は次のセクションで学習します。

独自のモジュール識別子を発行する場合、モジュールの目的を示す分かりやすい識別子を使用します。 必要に応じて、名前の各部分を区別するためにスラッシュ (/) を使用する "名前空間" を使用できます。 ただし、Azure Container Registry と Bicep では階層が理解されません。 モジュール識別子は 1 つの値として扱われます。

タグとバージョン

タグは、モジュールのバージョンを表します。 レジストリ内の 1 つのモジュールに複数のバージョンがある可能性があります。 すべてのバージョンで 1 つのモジュール識別子が共有されますが、タグは異なります。 モジュールを使用する場合、Bicep でどのモジュール ファイルを取得するかが認識されるように、タグを使用して使用したいバージョンを指定する必要があります。

モジュールのバージョンをどう管理するかは、慎重に計画することをお勧めします。 使用する "バージョン管理スキーム" と "バージョン管理ポリシー" の 2 点が、決定すべき重要な事項となります。

バージョン管理スキーム

バージョン番号の生成方法は、バージョン管理スキームによって決まります。 一般的なバージョン管理スキームの例を次に示します。

  • "基本的な整数" は、バージョン番号として使用できます。 たとえば最初のバージョンを 1、2 番目のバージョンを 2、のようにします。 または、v1v2 などのプレフィックスを各バージョン番号に追加できます。
  • "日付" もバージョン番号に適しています。 たとえば、モジュールの最初のバージョンを 2022 年 1 月 16 日に発行した場合、そのバージョンには 2022-01-16 という名前を付けることが考えられます (yyyy-mm-dd 形式を使用)。 3 月 3 日に別のバージョンを発行した場合は、2022-03-03 という名前にすることができます。
  • "セマンティック バージョン管理" は、ソフトウェアでよく使用されるバージョン管理システムであり、1 つのバージョン番号が複数の要素で構成されます。 変更の性質に関するさまざまな情報が、それぞれの構成要素によって表されます。

任意のバージョン管理スキームを使用できますが、並べ替えたときに意味のある順序になるスキームを選択するのが得策です。 多くの場合、数字と日付が適しています。

注意

Azure Container Registry には、各タグが作成された日付が格納されます。 日付ベースのバージョン管理を使用しなくても、この情報は確認できます。

バージョン管理ポリシー

モジュールでは、どのようなときに新しいバージョンを作成するか、既存のバージョンを更新するか、柔軟に選択できます。 たとえば、latest という名前のバージョンを 1 つ作成して発行すれば、実質的にバージョン管理の不使用を選択できます。 モジュールに変更を加える必要が生じるたびに、そのバージョンを単に更新します。 このポリシーでも正しく機能しますが、よい方法ではありません。

逆に、使い方に影響が生じないような小さな変更を既存のモジュールに加えた場合に、新しくバージョンを作成するのも得策とは言えないでしょう。 そのモジュールを使用するすべてのユーザーに新しいバージョン番号を伝えなければなりません。

多くの場合に適切な結果が得られるバージョン管理ポリシーを次に示します。

  • 重大な変更をモジュールに加えるたびに、新しいバージョンを作成します。 重大な変更には、モジュールを使用するユーザーに影響を与える可能性があるものが含まれます。 たとえば、モジュールに別のリソースを追加したり、リソースのプロパティを変更したりする場合です。
  • モジュールに小さな変更 (場合によっては "修正プログラム" と呼ばれます) を加えるたびに、既存のモジュール バージョンを更新します。
  • 古くなって妥当性を失ったバージョンやだれにも使って欲しくないバージョンは削除します。

ヒント

期待される動作をモジュールのユーザーの立場で考えるようにしてください。 モジュールを複数回使用して 1 つの結果が得られるとします。その後、修正プログラム適用後に再び使用した結果が異なると、ユーザーは驚いてしまうでしょう。 ユーザーを驚かさないようにしてください。

モジュールを発行する

共有する Bicep モジュールを作成する場合は、通常通り Bicep ファイルを作成します。 次に、bicep publish コマンドを使用して、レジストリにファイルを "発行" します。 発行するときに、モジュールを保存するモジュール パスを指定する必要があります。

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'
bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

発行操作では、Bicep ファイルをビルドまたはデプロイするときに行うのと同じ検証手順が実行されます。 その手順は次のとおりです。

  • コードに構文エラーがないことを確認します。
  • 有効なリソース定義を指定していることを確認します。
  • Bicep リンターを実行して、コードが一連の品質チェックに合格したことを確認します。

検証手順に合格すると、モジュールはレジストリに発行されます。