Azure Container Registry の geo レプリケーション

Azure Container Registry (ACR) の geo レプリケーションを有効にすると、選択した Azure リージョンに geo レプリカ リソースが作成されます。 geo レプリケートされたレジストリにイメージをプッシュすると、コンテンツはすべての geo レプリカに自動的に同期されます。

ジオレプリケーションでは

• 1 つのレジストリを管理する: すべての geo レプリカにわたって、資格情報、ロールの割り当て、ネットワーク規則、レジストリ構成の 1 つのセットを維持します。
• 1 つのグローバル エンドポイントを使用する: すべてのビルドとデプロイで myregistry.azurecr.io/myimage:tag を参照します。 Azure は、クライアントに最適なネットワーク パフォーマンス プロファイル (通常は最も近い geo レプリカ) を使用して、geo レプリカに要求をルーティングします。 ただし、クライアントが複数の geo レプリカから等距離にある場合、または最も近い geo レプリカが利用できない場合は、リクエストが他の場所にルーティングされる可能性があります。
• 自動同期: タグとダイジェストを 1 回プッシュします。ACR は、コンテンツとメタデータをすべての geo レプリカにレプリケートします。

Geoレプリケーションには Premium SKU が必要です。

高可用性に関する考慮事項

レプリケーション モデル

ACR geo レプリケーションでは、 アクティブ/アクティブ モデルが使用されます。

• すべての geo レプリカはアクティブで書き込み可能です。ホーム リージョンの geo レプリカだけでなく、任意の geo レプリカからイメージをプッシュ、プル、および削除できます。
• これは、書き込みを受け入れるリージョンが 1 つだけで、セカンダリ リージョンがパッシブであるプライマリ/セカンダリ レプリケーション モデルとは異なります。

整合性モデル

ACR は 最終的な整合性を使用します。

• 任意の geo レプリカ内のイメージをプッシュまたは削除すると、ACR は最終的にバックグラウンドですべての geo レプリカに変更をレプリケートします。
• レプリケーション時間はイメージ サイズによって異なります。 大量のイメージがプッシュされた場合、またはイメージ サイズが大きい場合、プッシュされたイメージまたはタグは、他の geo レプリカ上ですぐに pull できない可能性があります。 同様に、削除されたイメージまたはタグでも、削除が反映されるまでの間は、他の geo レプリカから引き続き pull できる場合があります。
• 新しい geo レプリカの作成にかかる時間は、レジストリの合計サイズに合わせてスケーリングされます。 新しい geo レプリカを作成する場合、既存の geo レプリカは引き続きプッシュ、プル、および削除トラフィックを通常どおりに処理します。 新しい geo レプリカがバックグラウンドで同期を進める間は、制限やパフォーマンスが低下することはありません。
• レプリケーションが最終的にバックグラウンドで完了するまで、geo レプリカに最新のコンテンツやメタデータがない可能性があります。 webhook を使用すると、各 geo レプリカで特定のプッシュイメージのレプリケーションが完了したときに通知を受け取ることができます。

データ プレーンの高可用性

geo レプリケーションでは、複数のリージョンにイメージを保持することで、データ プレーンの可用性が向上します。 1 つのリージョンで障害が発生した場合でも、他の geo レプリカからイメージにアクセスできます。つまり、プッシュ、プル、削除は、残りの geo レプリカで引き続き動作します。

ゾーン冗長は常に geo レプリカに対して有効です。ACR は、ゾーンの停止から保護するために、レプリカ データを複数の可用性ゾーンに自動的に分散します。

正常性認識のフェールオーバー

ACR は、各 geo レプリカの正常性を自動的に監視し、要求を確実に処理できない geo レプリカからグローバル エンドポイント トラフィックを再ルーティングします。 これは正常性を考慮したフェールオーバーと呼ばれます。 ACR は、ACR サービスの正常性とAzureリージョンインフラストラクチャの正常性に基づいてグローバル エンドポイント トラフィックをルーティングします。

• 自動およびレジストリごと: 正常性は、リージョンごとではなく、レジストリごとに評価されます。 低下がリージョン内のレジストリのサブセットにのみ影響する場合、それらのレジストリのみが再ルーティングされます。同じリージョン内の他のレジストリは、不要な待機時間のペナルティなしで引き続きローカルで処理されます。
• タイミング: エンドツーエンドの再ルーティングは数分程度で行われるため、実際のリージョン全体の性能低下を検知するのに十分な速さがあり、一方で自然に解消する一時的なエラーはやり過ごせる程度の遅さもあります。 DNS TTL は、すべてのクライアントが新しいリージョンに切り替える前に伝達遅延を追加する場合があります。
• 顧客のアクションは必要ありません。顧客が使用できるトリガーはありません。 正常性を考慮したフェールオーバーは、プラットフォームによって完全に管理されます。
• フェールバックは自動です: リージョン ACR や Azure インフラストラクチャが復旧した場合など、geo レプリカのリージョン正常性評価で再び正常と評価されると、グローバル エンドポイントは復旧した Azure リージョン内の geo レプリカへのトラフィック ルーティングを再開できます。
• スロットリングではトリガーされません: 正常性を考慮したフェールオーバーは DNS ベースで、リージョンごとの ACR サービスの正常性と Azure インフラストラクチャの正常性に応答します。 HTTP 429（スロットリング）レスポンスに基づいてトラフィックを再ルーティングしません。 geo レプリカが要求をスロットルしていても、そのリージョンのインフラストラクチャが正常であれば、グローバル エンドポイントは引き続きその geo レプリカにルーティングします。 スロットリングを管理するには、リージョン エンドポイントを使用して複数の geo レプリカにワークロードを分散し、容量をより適切に分散できます。

健全性を考慮したフェールオーバーのスコープ:

正常性対応フェールオーバーは、 グローバル エンドポイント (myregistry.azurecr.io) に対する操作にのみ適用されます。 次の場合には適用 されません 。

• リージョン エンドポイント — リージョン エンドポイント (myregistry.<region>.geo.azurecr.io) を使用する場合は、1 つの特定の geo レプリカと直接通信します。 そのリージョンが低下しても、ACR は自動的に再ルーティングされません。 別のリージョン エンドポイントに切り替えて、クライアント側のフェールオーバーを実装します。
• 専用データ エンドポイント — レジストリ エンドポイントがレイヤーダウンロード用の専用データ エンドポイントにリダイレクトされたら、ダウンロードを通じてそのリージョンのデータ エンドポイントを維持します。 リージョンは、BLOB の場所の呼び出しを処理したレジストリ エンドポイントによって事前に決定されます。

フェールオーバー中のスロットリング:

API 操作に対するスロットリング制限は レプリカごとです。 正常性を考慮したフェールオーバー中は、複数の geo レプリカに分散されていたトラフィックが、グローバル エンドポイントのルーティング プールに残っている geo レプリカに大きく集中する可能性があります。 フェールオーバー中にトラフィックが複数の正常な geo レプリカに分散できるように、少なくとも 2 つまたは 3 つの geo レプリカを備える容量計画。 リージョンが 2 つしかないレジストリでは、1 つのリージョンが利用できない場合、レプリカごとのスロットリング制限に達しやすくなります。 軽減するには、 リージョン エンドポイントを 使用して複数の geo レプリカにワークロードを分散させ、レプリカごとの容量を計画します。

フェールオーバーを確認する方法:

• Azure ポータル: レジストリに移動し、Help セクションの下にある Resource health を選択して、プラットフォーム側の低下シグナルを確認します。
• Azure CLI: az acr replication list --registry myregistry --output table でレプリケーションの状態を確認します。 問題が発生している geo レプリカは、online 以外の状態を表示します。
• Azure Monitor: プラットフォーム メトリックが自動的に収集されます。 リソース ログの 診断設定 を有効にして、詳細なテレメトリを取得します。

ホームリージョンの障害時の挙動

ホーム リージョンは、最初にレジストリを作成したリージョンです。 レジストリのコントロール プレーンがホストされ、レジストリの構成が管理されます。 ホーム リージョンは作成時に固定され、後で変更することはできません。 レジストリを別のホーム リージョンに移動する方法については、「Relocate Azure Container Registry」を参照してください。これは、インプレース変更ではなく、再デプロイ手順 (新しいレジストリの作成) について説明しています。

ホーム リージョンが使用できなくなった場合、その効果はコントロール プレーン (管理) 操作に限定されます。 すべてのデータプレーンの操作は、残りの地理的レプリカを通じて引き続き動作します。

ホーム リージョンの停止中に引き続き機能するもの:

• イメージのプッシュ、プル、および削除 — クライアントは、グローバル エンドポイント (myregistry.azurecr.io) または使用可能なリージョン エンドポイント (myregistry.<region>.geo.azurecr.io) を使用して、使用可能な geo レプリカからイメージをプッシュ、プル、および削除できます。 ACR は、グローバル エンドポイント要求を正常な geo レプリカに自動的にルーティングします。
• Authentication — Microsoft Entra ID、サービス プリンシパル、マネージド ID、リポジトリ スコープ トークンなど、すべての認証方法が引き続き機能します。 クライアントは、資格情報、トークン、またはレジストリ URL を変更しなくても、使用可能な geo レプリカに対して認証できます。
• Webhook 配信 — 使用可能な geo レプリカ用に構成された Webhook は引き続き起動します。 1 回のプッシュにより、受信した geo レプリカからの webhook イベントと、レプリケーションの完了時に各 geo レプリカからのイベントが生成されます。 Webhook コンシューマーは、プッシュされたイメージごとに複数のイベントを処理し、必要に応じて重複除去するように設計する必要があります。
• リージョン エンドポイント — リージョン エンドポイントが有効になっている場合は、個別に動作し続けます。 クライアントは、リージョン エンドポイント URL を使用して、特定の geo レプリカと直接通信できます。

ホーム リージョンの停止中に使用できない機能:

• ホーム リージョン geo レプリカへのグローバル エンドポイント ルーティング — ACR の正常性検出により、グローバル エンドポイント トラフィックのホーム リージョン geo レプリカへのルーティングが自動的に停止され、正常な geo レプリカにリダイレクトされます。
• ホーム リージョンのリージョン エンドポイント — ホーム リージョン のリージョン エンドポイント (myregistry.<home-region>.geo.azurecr.io) は、ホーム リージョンがダウンしている間は使用できません。 他の geo レプリカのリージョン エンドポイントは、引き続き独立して動作します。
• レジストリ構成の変更 - ホーム リージョンが復旧するまで、ネットワーク ルール、レプリケーション設定、可用性ゾーンの構成などのレジストリ プロパティを変更することはできません。
• ACR タスク — タスク はホーム リージョンにバインドされ、使用できない間は実行されません。

サービス レベルと制限に関する考慮事項

Azure Container Registryサービス レベルと制限は、各 geo レプリカに個別に適用されます。

特定のサービス レベルの制限には、次の特別な考慮事項があります。

• ストレージの制限: サービス レベルのストレージ制限は、すべての geo レプリカで共有されます。 たとえば、1 GiB イメージをプッシュし、5 つの geo レプリカにレプリケートする場合、階層の最大ストレージ制限に対してカウントされるのは 1 GiB のみです。
• API レートの制限: 1 分あたりの読み取りと書き込みの数など、API 操作の調整制限は geo レプリカ固有です。 リージョン エンドポイントを使用して複数の geo レプリカにワークロードを分散し、容量の分散を向上させ、すべてのトラフィックが単一の geo レプリカに集中しないようにします。

サービス レベルと制限の詳細については、 ACR サービス レベルを参照してください。

価格に関する考慮事項

• ストレージの課金: ストレージは geo レプリカごとに課金されます。 たとえば、5 つの geo レプリカにレプリケートされた 1 GiB イメージは、5 GiB のストレージとして課金されます (1 GiB × 5 geo レプリカ)。
• データ転送: geo レプリケーションでは、リージョン内イメージのプッシュとプルを有効にすることでコストを削減できます。これにより、これらのプッシュ操作またはプル操作中のリージョン間のデータ転送料金を回避できます。 ただし、最終的な整合性の一環として、ACR がプッシュされたコンテンツを他の geo レプリカにレプリケートする場合、リージョン間のデータ転送料金は引き続き適用されます。

詳細については、 ACR の価格を参照してください。

geo レプリカを追加または削除する

要求されるアクセス許可

geo レプリカを管理するには、あなたの利用者 ID に次のアクセス許可が必要です。

Azure portal

1. Azure portal でレジストリに移動します。
2. [ サービス] で、[ Geo レプリケーション] を選択します。
3. マップ上:
   • 青い六角形: ホーム リージョン (レジストリを作成した場所)
   • 緑色の六角形: 使用可能なリージョン
   • 灰色の六角形: 使用できない領域
4. 緑色の六角形を選択し、[ 作成] を選択します。

Azure CLI

# Create a replica
az acr replication create --registry myregistry --location eastus

# List replicas
az acr replication list --registry myregistry --output table

# Delete a replica
az acr replication delete --registry myregistry --name eastus

その他のコマンドについては、 az acr replication を参照してください。

geo レプリケーションによるレジストリのグローバル エンドポイント

geo レプリケーションを構成したら、レジストリのグローバル エンドポイント (myregistry.azurecr.io) を使用して、レジストリ内のコンテンツをプッシュ、プル、または削除できます。

グローバル エンドポイントのしくみ

グローバル エンドポイントを介してプッシュ、プル、または削除すると、ACR はクライアントに最適なネットワーク パフォーマンス プロファイルを使用して geo レプリカに要求をルーティングします。

• クライアントから見て最もネットワーク パフォーマンス プロファイルが優れている geo レプリカは、通常、最も近い geo レプリカです。
• ただし、クライアントが複数の geo レプリカから等距離にある場合、または最も近い geo レプリカが利用できない場合は、リクエストが他の場所にルーティングされる可能性があります。
• ACR は、このルーティングを管理します。 特定のリクエストをどの geo レプリカが処理するかを制御することはできません。

グローバル エンドポイントの使用

認証:

az acr login --name myregistry

画像にタグを付けてプッシュする:

docker tag myapp:v1 myregistry.azurecr.io/myapp:v1
docker push myregistry.azurecr.io/myapp:v1

イメージをプルします。

docker pull myregistry.azurecr.io/myapp:v1

イメージをインポートします。

az acr import \
  --name myregistry \
  --source mcr.microsoft.com/hello-world:latest \
  --image hello-world:latest

Kubernetes 配置マニフェスト:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v1

グローバル エンドポイント ルーティングから geo レプリカを一時的に除外する

グローバル エンドポイント ルーティングから geo レプリカを除外するには、特定の geo レプリカの --global-endpoint-routing 設定を無効にします。 これは、メンテナンスやトラブルシューティング、または特定の geo レプリカまたは Azure リージョンで低下が発生していることがわかっている場合に役立ちます。 ホーム リージョンの geo レプリカに対してグローバル エンドポイント ルーティングを無効にすることもできます。ホーム リージョンはコントロール プレーン操作にのみ使用され、そのデータ プレーン トラフィックはグローバル ルーティングから安全に除外できます。 ホーム リージョンが制御する内容の詳細については、「 ホーム リージョンの停止動作」を参照してください。

• 特定の geo レプリカの --global-endpoint-routing 設定が false に設定されている場合、ACR は、グローバル エンドポイントに送信される要求に対して、その特定の geo レプリカへの要求のルーティングを停止します。
• その特定の geo レプリカに対してグローバル エンドポイント ルーティングが無効になっている場合でも、データは geo レプリカと 双方向に 同期し続けます。 geo レプリカがグローバル ルーティングから除外されている間に、任意のリージョンからレジストリにプッシュされたすべてのイメージは、引き続きそのリージョンにレプリケートされます。 geo レプリカを再び有効にすると、すぐにキャッチアップ ウィンドウなしでトラフィックを処理できます。
• そのため、そのジオレプリカのストレージ クォータとコストは引き続き発生します。
• リージョン エンドポイントが有効になっている場合、グローバル エンドポイント ルーティングが無効になっている間でも、geo レプリカのリージョン エンドポイント URL (myregistry.<region-name>.geo.azurecr.io) は引き続き機能します。 --global-endpoint-routing は、 グローバル エンドポイント ルーティングへの geo レプリカの参加のみを制御します。

# Exclude a geo-replica from global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing false

# Re-enable a geo-replica in global endpoint routing
az acr replication update --registry myregistry --name eastus \
  --global-endpoint-routing true

geo レプリケーションで複製されたレジストリのリージョン エンドポイント (プレビュー)

リージョン エンドポイントでは、各レプリカの専用 URL を使用して、プッシュ、プル、または削除の要求を処理するリージョン geo レプリカを正確に指定できます。

• myregistry.eastus.geo.azurecr.io
• myregistry.westeurope.geo.azurecr.io

必要に応じ、リージョン エンドポイントを使用します。

リージョン エンドポイントとグローバル エンドポイントの共存

リージョン エンドポイントを有効にしても、グローバル エンドポイントを無効にしたり、置き換えたりすることはありません。 両方を同時に使用できます。

• geo レプリカ全体で Azure が管理する自動ルーティングを利用する場合は、グローバル エンドポイント (myregistry.azurecr.io) を使用します。
• グローバル エンドポイントのAzureマネージド ルーティングを完全にバイパスして、クライアント側のルーティング制御をきめ細かく制御する場合は、地域的なエンドポイント (myregistry.<region-name>.geo.azurecr.io) を使用します。

リージョン エンドポイントのしくみ

リージョン エンドポイントは、特定の geo レプリカの ログイン サーバー として機能します。 レジストリのグローバル エンドポイントではなくリージョン エンドポイントを認証して操作すると、すべてのレジストリ操作 (認証、アーティファクトのアップロード/ダウンロード、リポジトリ操作、およびメタデータ アクション) は、その特定のリージョン レプリカに直接移動し、Azureマネージド ルーティングを完全にバイパスします。

レイヤー BLOB のダウンロード (実際のコンテナー イメージ レイヤー) は、レジストリの既存の構成に従います。

• プライベート エンドポイントまたは専用データ エンドポイントのない登録: 特定の geo レプリカからイメージ レイヤーをダウンロードすると、レイヤー BLOB はAzureストレージ アカウント (*.blob.core.windows.net) にリダイレクトされます。
• プライベート エンドポイントまたは専用データ エンドポイントが有効なレジストリ: 特定の geo レプリカからイメージ レイヤーをダウンロードすると、レイヤー BLOB は対応するリージョンの専用データ エンドポイント (myregistry.<region-name>.data.azurecr.io) にリダイレクトされます。

次の図は、リージョンエンドポイント要求フローを示しています。

リージョン エンドポイントの前提条件

• Premium SKU — リージョン エンドポイントは、 Premium レベルのレジストリでのみ使用できます。
• Azure CLI - バージョン 2.86.0 以降。 すべてのリージョン エンドポイント コマンド (--regional-endpoints、az acr show-endpoints、az acr login --endpoint) は、Azure CLI 2.86.0 以降でネイティブに使用できます。

az extension remove --name acrregionalendpoint

az extension list --query "[?name=='acrregionalendpoint']" -o table

リージョン エンドポイントを有効にする

新しいレジストリを作成するとき、または既存のレジストリを更新するときに、リージョン エンドポイントを有効にすることができます。

リージョン エンドポイントが有効になっている新しいレジストリを作成します。

az acr create \
  -n myregistry \
  -g myrg \
  -l regionname \
  --sku Premium \
  --regional-endpoints enabled

既存のレジストリでリージョン エンドポイントを有効にします。

az acr update \
  -n myregistry \
  -g myrg \
  --regional-endpoints enabled

リージョン エンドポイントはレジストリ レベルで有効になり、すべての geo レプリカに適用されます。 個々のレプリカに対してリージョン エンドポイントを有効にすることはできません。 リージョン エンドポイントを有効にすると、Azure Container Registryによって、各 geo レプリカのログイン サーバー URL が自動的に作成されます。

リージョン エンドポイントを操作する

リージョン エンドポイントを認証して使用する

リージョン エンドポイントでは、グローバル エンドポイントと同じ認証方法 (Microsoft Entra ID、サービス プリンシパル、マネージド ID、管理者資格情報) がサポートされます。

特定のリージョン エンドポイントにサインインします。

az acr login --name myregistry --endpoint eastus

リージョン エンドポイントにイメージをタグ付けしてプッシュします。 リージョン エンドポイントを介して geo レプリカにプッシュされたイメージとタグは、最終的な一貫性の下で、引き続き他のすべての geo レプリカに反映されます。

docker tag myapp:v1 myregistry.eastus.geo.azurecr.io/myapp:v1
docker push myregistry.eastus.geo.azurecr.io/myapp:v1

リージョン エンドポイントからイメージをプルします。

docker pull myregistry.eastus.geo.azurecr.io/myapp:v1

AKS マネージド ID 認証でリージョン エンドポイントを使用する

マネージド ID を使用して ACR に対して認証を行う AKS イメージ プルは、 202607.29 以降の AKS ノード イメージ上のリージョン エンドポイントをサポートします。 各ノード プールの現在のイメージを確認します。

az aks nodepool show \
  --resource-group <resource-group> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --query nodeImageVersion \
  --output tsv

互換性のあるノード イメージ VHD がリージョンとクラウドで使用可能になった後に自動的に受信するには、 NodeImage ノード OS 自動アップグレード チャネルを使用します。 AKS Automatic では NodeImage を使用します。AKS Standard の場合は、NodeImage を選択します。

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --node-os-upgrade-channel NodeImage

以前のイメージを実行している AKS ノードの場合は、リージョン エンドポイントからイメージをプルするときに Kubernetes イメージプル シークレット を使用するか、代わりにグローバル エンドポイント (<registry-name>.azurecr.io) を参照します。

配置マニフェストに埋め込まれたリージョン エンドポイントを使用する

特定のリージョンにワークロードをピン留めする必要がある場合は、Kubernetes 配置マニフェストでリージョン エンドポイントを直接指定できます。 これにより、特定のリージョン内のクラスターが常に併置されたレプリカからプルされ、予測可能なルーティングと待機時間の短縮が実現されます。

米国東部クラスターのデプロイ:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-eastus
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.eastus.geo.azurecr.io/myapp:v1

西ヨーロッパ クラスターのデプロイ:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-westeurope
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: myregistry.westeurope.geo.azurecr.io/myapp:v1

各クラスターのマニフェストで異なるリージョン エンドポイントを使用することで、Azureマネージド ルーティングに依存するのではなく、各クラスターがそのローカル レプリカからプルすることを保証できます。

Azure Kubernetes Service (AKS) から Azure Container Registry (ACR) への認証に関する情報については、Azure Kubernetes Service から Azure Container Registry を使用して認証する を参照してください。

デプロイ マニフェストを変更せずに DNS ベースのルーティングでリージョン エンドポイントを使用する

リージョンごとに異なる配置マニフェストを維持しない場合は、すべてのマニフェストがグローバル エンドポイント (myregistry.azurecr.io) を指し続け、ソフトウェア定義ネットワークまたはリージョン トラフィック マネージャーを使用して、発信元リージョンのトラフィックに基づいてグローバル エンドポイントを適切なリージョン エンドポイントに解決できます。 これにより、リージョン固有の URL を配置マニフェストに埋め込むことなく、リージョン エンドポイントと同じコロケーション目標 (予測可能なルーティングと待機時間の短縮) が実現されます。

Azure Kubernetes Service (AKS) から Azure Container Registry (ACR) への認証に関する情報については、Azure Kubernetes Service から Azure Container Registry を使用して認証する を参照してください。

リージョン エンドポイントを使用して特定の geo レプリカからインポートする

Azure Container Registryでは、クラウド プロバイダー間でさまざまなソース レジストリからイメージをインポートできます。 インポート ソースが ACR の場合は、ソース ACR のホーム リージョンからのみインポートできます。 ソース ACR のリージョン エンドポイントは、インポート ソースとしてサポートされていません。 ソース ACR からインポートするときに、ソース ACR のグローバル エンドポイントを指定します。 さらに、インポートでは常にダウンストリーム ACR のホーム リージョンにコンテンツが書き込まれます。 エンドポイントリファレンスAzure Container Registry参照してください。

リージョン エンドポイントネットワークに関する考慮事項

ファイアウォール規則

リージョン エンドポイントで ACR ファイアウォール規則 またはカスタム ファイアウォールを使用している場合は、次へのアクセスを許可するようにファイアウォール規則を構成します。

プライベート エンドポイント

仮想ネットワーク内のレジストリに対して プライベート エンドポイント が作成されると、プライベート エンドポイント リソースは、レジストリ のすべての エンドポイント サーフェス (グローバル エンドポイント、すべてのリージョン エンドポイント (リージョン エンドポイントが有効な場合))、すべての専用データ エンドポイント (プライベート エンドポイントが構成されると自動的に有効) をカバーするいくつかの仮想ネットワーク プライベート IP を公開します。

各エンドポイント サーフェスは、仮想ネットワーク サブネットから 1 つのプライベート IP アドレスを使用します。 それに応じてサブネットのサイズ設定を計画します。

• グローバル エンドポイントの 1 つの IP (myregistry.azurecr.io)
• 専用データ エンドポイント () の myregistry.<region>.data.azurecr.io - 少なくとも 1 つのプライベート エンドポイントを持つレジストリで常に有効
• リージョン エンドポイント () の myregistry.<region>.geo.azurecr.io - リージョン エンドポイントが有効になっている場合のみ

例: 3 つの geo レプリカとリージョン エンドポイントが有効になっているレジストリでは、プライベート エンドポイント リソースあたり 1 (グローバル) + 3 (データ) + 3 (リージョン) = 7 個のプライベート IP アドレス が必要です。 リージョン エンドポイントがない場合、同じレジストリには 1 + 3 = 4 個のプライベート IP アドレスが必要です。

多くの geo レプリカでは、サブネットが使用可能な IP を使い切った場合、プライベート エンドポイントの作成が失敗する可能性があります。 詳細については、「 プライベート エンドポイントを使用して仮想ネットワークからレジストリにプライベートに接続する」を参照してください。

専用データ エンドポイント

リージョン エンドポイントが 専用データ エンドポイント と共に有効になっている場合 (明示的に有効にするか、少なくとも 1 つのプライベート エンドポイントを構成して自動有効にする) 場合、リージョン エンドポイントからのレイヤー BLOB ダウンロードは geo レプリカの専用データ エンドポイント (myregistry.<region-name>.data.azurecr.io) に自動的にリダイレクトされます。 リダイレクトは常にリージョン エンドポイントと 同じリージョン 内にとどまります。 myregistry.eastus.geo.azurecr.io からのプルは常に myregistry.eastus.data.azurecr.ioにリダイレクトされ、別のリージョンのデータ エンドポイントにはリダイレクトされません。

この同じリージョンの保証は、グローバル エンドポイントからプルする場合にも適用されます。 ACR は、クライアントに最適なネットワーク パフォーマンス プロファイルを使用して geo レプリカに要求をルーティングし、サービス geo レプリカは、リージョンをまたがることはなく、独自の専用データ エンドポイントへの 307 リダイレクトを発行します。

az acr update -n <registry-name> --data-endpoint-enabled true

詳細については、Azure Container Registry の専用データ エンドポイント を参照してください。

エンドポイント参照

すべてのレジストリ エンドポイントの種類、URL 形式、およびそれらを制御する CLI フラグの完全なリファレンスについては、Azure Container Registry エンドポイントリファレンスを参照してください。

トラブルシューティング

プッシュ操作がマニフェストエラーのために失敗する

docker push とは、一連のHTTPリクエストです。各レイヤーのBLOBアップロードを行い、続いてそれらのレイヤーをダイジェストで参照するマニフェストをアップロードします。 一部の Linux DNS リゾルバーは、応答を一貫してキャッシュしません。 近くのリージョンに複数の geo レプリカがある場合、DNS が 1 回のプッシュ (DNS バウンス) 中に異なるレプリカに解決され、プッシュされたマニフェストが別の geo レプリカにプッシュされたレイヤーを参照する可能性があります。 レプリケーションは最終的に一貫性があるため、参照するレイヤーがまだないレプリカにマニフェストを設定でき、マニフェストの検証は失敗します。

ソリューション (優先順):

1. リージョン エンドポイントを使用して、プッシュをエンドツーエンドで単一の geo レプリカに固定します。 すべてのサブ要求 (サインイン、BLOB のアップロード、マニフェストのアップロード) は、同じ geo レプリカに送信されます。 これは最もクリーンな修正であり、プッシュ/プルの整合性が重要なパイプラインに推奨されるアプローチです。
2. dnsmasqなどの有効期間の短い DNS キャッシュを使用するスコープは、1 回のプッシュの期間に設定されます。 Azure の Linux VM については、 DNS の名前解決オプションに関するページを参照してください。 ピン留めはプッシュの間だけ維持し、それ以上長く保持しないでください。グローバル エンドポイントに対して長時間保持される DNS キャッシュを使用すると、--global-endpoint-routing false と正常性を考慮したフェールオーバー ルーティングの両方に干渉するためです。
3. 公開手順を冪等になるように設計し、プッシュ途中の障害によってトリガーされる再試行を安全にします。

プライベートエンドポイントが有効なレジストリの地理的レプリカ作成が停止している

この問題は通常、プライベート エンドポイントが有効なレジストリの geo レプリカを作成する ID に、プライベート エンドポイント ネットワーク リソースを作成するための十分なアクセス許可がない場合に発生します。

解決策:

• 解決するには、プロビジョニング状態でスタックした geo レプリカを手動で削除します。
• その後、geo レプリカを作成する前に、ID に Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write アクセス許可があることを確認します。
• また、レジストリに接続されているすべてのプライベート エンドポイント サブネットに空き IP 容量があることを確認します。 接続 されている 仮想ネットワーク全体のサブネットに十分な空き IP がない場合、レプリケーションのプロビジョニングは失敗し、ロールバックされます。 レプリカは一時的に Creating 状態で表示され、削除されます。 結果として発生するエラーでは、どのサブネットまたは仮想ネットワークが使い果たされているかは識別されません。 サブネットのサイズ設定のガイダンスについては、「 プライベート エンドポイントを使用してレジストリにプライベートに接続する」を参照してください。

静的 IP プライベート エンドポイントを持つレジストリで geo レプリカの作成が失敗する

レジストリのプライベート エンドポイントが 静的 プライベート IP 割り当てで構成されている場合、geo レプリカの追加は失敗します。

各 geo レプリカにはそれぞれ専用のデータ エンドポイントがあり、プライベート エンドポイント上では、グループ ID が registry、メンバー名が registry_data_<region> のメンバーとして公開されます。 新しい geo レプリカを追加すると、ACR は、新しいリージョンのデータ エンドポイントのメンバーを追加するプライベート エンドポイントを要求します。 動的 IP 割り当てで構成されたプライベート エンドポイントは、新しいメンバーの IP を自動的にプロビジョニングします。 静的 IP 割り当てで構成されたプライベート エンドポイントには、作成時に定義された IP 構成の固定セットがあり、新しいメンバーは自動的に追加されないため、レプリカの作成は次のようなエラーで失敗します。

Failed to replicate private endpoint. Private Endpoint <id> contains static ipconfigurations:
[... GroupId: registry, MemberName: registry_data_<existing-region> ...] and it's missing these
membernames/groupids requested by Private Link service [GroupId: registry, MemberName:
registry_data_<new-region>, IpVersion: IPv4]. Private Endpoint needs to be reconfigured with
missing memberNames.

レジストリのプライベート エンドポイントの割り当て方法を確認するには、プライベート エンドポイントのネットワーク インターフェイス上の IP 構成の PrivateIPAllocationMethod を調べます。 プライベート エンドポイントは、これらの IP 構成を保持するネットワーク インターフェイスを参照するため、最初にネットワーク インターフェイス ID を取得してから、その IP 構成を調べます。

nicId=$(az network private-endpoint show \
  --name <private-endpoint-name> \
  --resource-group <resource-group-name> \
  --query "networkInterfaces[0].id" --output tsv)

az network nic show --ids "$nicId" \
  --query "ipConfigurations[].{Name:name, PrivateIPAddress:privateIPAddress, PrivateIPAllocationMethod:privateIPAllocationMethod}" \
  --output table

ソリューション:

• 後で geo レプリカを追加する予定の場合は、プライベート エンドポイントに動的 IP 割り当てを使用します。 動的割り当てでは、ACR は新しいリージョンごとにデータ エンドポイント メンバーを自動的にプロビジョニングします。 これは推奨されるアプローチです。
• 静的 IP 割り当てが必要な場合は、すべての geo レプリカが存在した後にプライベート エンドポイントを作成します。 最初にすべての geo レプリカを追加してから、静的 IP プライベート エンドポイントを作成し、その IP 構成に既存のリージョンのすべてのデータ エンドポイントのメンバーが含まれるようにします。 このように静的 IP プライベート エンドポイントを作成した後は、プライベート エンドポイントを再構成して新しいメンバーを追加しないと、さらに geo レプリカを追加することはできません。

関連するコンテンツ

• ACR SKU とサービス レベル
• エンドポイントリファレンス
• Webhook
• プライベート エンドポイント
• 専用データ エンドポイント
• ファイアウォール アクセス規則を構成する