以下のベスト プラクティスに従うことにより、Azure のプライベート レジストリのパフォーマンスを最大限に引き出し、運用のコスト効率を高め、コンテナー イメージとその他の成果物を格納およびデプロイできます。
レジストリの概念の背景については、「 レジストリ、リポジトリ、イメージについて」を参照してください。 レジストリ内 のイメージにタグを付け、バージョンを付ける方法については、コンテナー イメージのタグ付け とバージョン管理に関する推奨事項も参照してください。
ネットワーク的に近接する場所へのデプロイ
コンテナー レジストリは、コンテナーのデプロイ先と同じ Azure リージョンに作成してください。 ご利用のコンテナー ホストとネットワーク的に近接するリージョンにレジストリを配置することで、待ち時間とコストの両方を低減することができます。
ネットワーク的に近接する場所へのデプロイは、プライベート コンテナー レジストリを使用する大きな理由の 1 つです。 Docker イメージには、増分デプロイを可能にする効率的な 階層構造 があります。 ところが、新しいノードは、特定のイメージに必要なすべてのレイヤーをプルする必要があります。 この初回 docker pull で、あっという間に数ギガバイトにまで達することがあります。 プライベート レジストリとデプロイとの距離が短ければ、ネットワーク待ち時間が最小限で済みます。
また、Azure を含むすべてのパブリック クラウドには、ネットワーク送信データ転送料金が導入されています。 異なるデータセンターからイメージを取得すると、待ち時間に加えて、ネットワーク送信データ転送料金が別途発生します。
Geo レプリケーション転送を使用した複数リージョンへのデプロイ
複数のリージョンにコンテナーをデプロイする場合は、Azure Container Registry の geo レプリケーション 機能を使用します。 ローカル データ センターから世界各国の顧客にサービスを提供する場合であれ、開発チームの拠点が分散している場合であれ、レジストリを Geo レプリケーション転送することにより、レジストリの管理を省力化し、待ち時間を最小限に抑えることができます。 イメージがプッシュされたときなど、特定のレプリカのイベントを通知するようにリージョン Webhook を構成することもできます。
ジオレプリケーションは、Premium レジストリで利用可能です。 geo レプリケーションの使用方法については、 Azure Container Registry での geo レプリケーションに関する 3 部構成のチュートリアルを参照してください。
プル パフォーマンスを最大化する
デプロイの近くにイメージを配置する以外に、イメージ自体の特性がプル パフォーマンスに影響を与える可能性があります。
画像サイズ - 不要なレイヤーを削除したり 、レイヤー のサイズを小さくしたりして、画像のサイズを最小限に抑えます。 イメージ サイズを小さくする方法の 1 つは、必要なランタイム コンポーネントのみを含めるために マルチステージ Docker ビルド アプローチを使用することです。
また、より軽量なベース OS イメージを含めることができるかどうかも確認します。 特定のベース イメージをキャッシュする Azure Container Instances などのデプロイ環境を使用する場合は、キャッシュされたイメージの 1 つのイメージ レイヤーをスワップできるかどうかを確認します。
レイヤーの数 - 使用されるレイヤーの数のバランスを取ります。 数が少なすぎると、ホストでのレイヤーの再利用とキャッシュの恩恵を受けられません。 多すぎると、デプロイ環境でのプルと圧縮解除に時間がかかります。 レイヤーの数は、5 ～ 10 が最適です。
また、パフォーマンスのニーズを満たす Azure Container Registry の サービス レベル も選択します。 Premium レベルでは、大規模なデプロイがある場合、最大帯域幅と読み取りと書き込みの同時操作の最高比率が提供されます。
リポジトリの名前空間
リポジトリの名前空間を使用することで、1 つのレジストリを組織内の複数のグループで共有することができます。 デプロイやチームの境界を越えてレジストリを共有することができます。 Azure Container Registry では、名前空間を入れ子にしてグループ分けすることができます。 ただし、レジストリでは、階層としてではなく、すべてのリポジトリが個別に管理されます。
たとえば、以下のようなコンテナー イメージ タグを考えてみましょう。 ルート名前空間には全社的に使用されるイメージ (aspnetcore など) を置き、Products グループと Marketing グループが所有するコンテナー イメージには、それぞれ固有の名前空間を使用します。
- contoso.azurecr.io/aspnetcore:2.0
- contoso.azurecr.io/products/widget/web:1
- contoso.azurecr.io/products/bettermousetrap/refundapi:12.3
- contoso.azurecr.io/marketing/2017-fall/concertpromotions/campaign:218.42
専用のリソース グループ
コンテナー レジストリは、複数のコンテナー ホスト間で使用されるリソースであるため、専用のリソース グループに置くことをお勧めします。
Azure Container Instances などの特定のホストの種類を試しても、完了したらコンテナー インスタンスを削除することをお勧めします。 しかし、Azure Container Registry にプッシュした一連のイメージを保存しておきたいこともあるでしょう。 レジストリを専用のリソース グループに置いておけば、コンテナー インスタンス リソース グループを削除するときに、レジストリ内の一連のイメージを不注意で削除するリスクを極力抑えることができます。
認証と承認
Azure Container Registry に対して認証を行うときのシナリオは、個人の認証とサービス ("ヘッドレス") 認証の 2 つに大別されます。 次の表は、それらのシナリオの概要とそれぞれに推奨される認証方法をまとめたものです。
| タイプ | サンプル シナリオ | 推奨される方法 |
|---|---|---|
| 個人 ID | 開発者が、その開発マシンにイメージをプルしたり、開発マシンからイメージをプッシュしたりする。 | az acr login |
| ヘッドレス/サービス ID | ユーザーの直接介入を伴わないビルドとデプロイのパイプライン。 | サービス プリンシパル |
これらおよびその他の Azure Container Registry 認証シナリオの詳細については、「 Azure コンテナー レジストリを使用した認証」を参照してください。
Azure Container Registry は、組織内のセキュリティのプラクティスをサポートし、さまざまな ID に職務と特権を配布します。 ロールベースのアクセス制御を使用して、さまざまなレジストリ操作を実行するさまざまなユーザー、サービス プリンシパル、またはその他の ID に適切なアクセス許可を割り当てます。 たとえば、ビルド パイプラインで使用されるサービス プリンシパルにプッシュ アクセス許可を割り当て、デプロイに使用されるさまざまな ID にプル アクセス許可を割り当てます。 特定のリポジトリへのきめ細かなアクセスには 、Microsoft Entra ベース のリポジトリのアクセス許可を使用します。 または、 Microsoft Entra 以外のトークン ベースのリポジトリアクセス許可を使用することもできます。
レジストリ サイズの管理
各 コンテナー レジストリ サービス レベル のストレージ制約は、一般的なシナリオ ( Basic for getting started、 Standard for most production applications、 Premium for hyper-scale performance and geo レプリケーション) に合わせて設計されています。 レジストリの有効期間を通して、使用されていないコンテンツを定期的に削除することによって、そのサイズを管理する必要があります。
Azure CLI コマンド az acr show-usage を使用して、レジストリ内のストレージとその他のリソースの現在の消費量を表示します。
az acr show-usage --resource-group myResourceGroup --name myregistry --output table
サンプル出力:
NAME LIMIT CURRENT VALUE UNIT
-------------------------- ------------ --------------- ------
Size 536870912000 215629144 Bytes
Webhooks 500 1 Count
Geo-replications -1 3 Count
IPRules 100 1 Count
VNetRules 100 0 Count
PrivateEndpointConnections 10 0 Count
現在のストレージ使用量は、Azure portal のレジストリの 概要 でも確認できます。
注意
geo レプリケートされたレジストリでは、ホーム リージョンのストレージ使用量が表示されます。 使用済みのレジストリ ストレージの合計については、レプリケーションの数を乗算します。
イメージ データを削除する
Azure Container Registry は、コンテナー レジストリからイメージ データを削除するためのいくつかの方法をサポートしています。 タグまたはマニフェスト ダイジェストによってイメージを削除するか、またはリポジトリ全体を削除することができます。
タグ付けされていない ("ダングリング" または "孤立した" とも呼ばれる) イメージなどのイメージ データをレジストリから削除する方法の詳細については、「Azure Container Registry のコンテナー イメージを削除する」を参照してください。 タグなしマニフェストの アイテム保持ポリシー を設定することもできます。
次のステップ
Azure Container Registry には、異なる機能を提供するレベル (SKU とも呼ばれます) があります。 使用可能なサービス レベルの詳細については、 Azure Container Registry サービス レベルに関するページを参照してください。
コンテナー レジストリのセキュリティ体制を改善するための推奨事項については、「 Azure Container Registry の Azure セキュリティ ベースライン」を参照してください。