Георепликация в реестре контейнеров Azure

Включение георепликации для реестра контейнеров Azure (ACR) создает ресурсы геореплики в выбранном регионе Azure. При отправке изображений в геореплицированный реестр содержимое автоматически синхронизируется со всеми георепликами.

С георепликацией:

• Управление одним реестром: обслуживание одного набора учетных данных, назначений ролей, правил сети и конфигурации реестра во всех георепликах.
• Используйте одну глобальную конечную точку: ссылка myregistry.azurecr.io/myimage:tag во всех сборках и развертываниях. Azure направляет запросы к геореплике с лучшим профилем производительности сети для клиента, который обычно является ближайшей георепликой. Однако если клиент находится на одинаковом расстоянии от нескольких геореплик или ближайшая геореплика недоступна, запросы могут быть перенаправлены в другое место.
• Автоматическая синхронизация: отправка тегов и дайджестов один раз; ACR реплицирует содержимое и метаданные во все геореплики.

Для георепликации требуется номер SKU класса Premium.

Рекомендации по обеспечению высокого уровня доступности

Модель репликации

Георепликация ACR использует активную-активную модель.

• Все геореплики активны и доступны для записи— вы можете отправлять, извлекать и удалять изображения из любой геореплики, а не только геореплики домашнего региона.
• Это отличается от моделей первичной вторичной репликации, где только один регион принимает записи и вторичные регионы являются пассивными.

Модель согласованности

ACR использует итоговую согласованность.

• После отправки или удаления изображения в любой геореплике ACR в конечном итоге реплицирует изменения во всех георепликах в фоновом режиме.
• Время репликации зависит от размера изображения. Отправленный образ или тег может быть не сразу доступен для извлечения других геореплик, если большие объемы изображений или большие размеры изображений отправляются. Аналогичным образом, удаленный образ или тег может по-прежнему быть доступен для скачивания в других георепликах до тех пор, пока удаление не распространится.
• Время, необходимое для создания новой геореплики, зависит от общего размера реестра. При создании новой геореплики существующие геореплики продолжают в обычном режиме обслуживать операции отправки, извлечения и удаления. Пока новая геореплика синхронизируется в фоновом режиме, ограниченное состояние или окно деградации отсутствуют.
• Пока репликация в конечном итоге не завершится в фоновом режиме, геореплика может не содержать последнее содержимое или метаданные. Вы можете использовать веб-перехватчики для получения уведомлений, когда репликация для определенного залитого образа завершается в каждой географической реплике.

Высокая доступность плоскости данных

Георепликация повышает доступность плоскости данных, сохраняя изображения в нескольких регионах. Если в одном регионе происходит сбой, образы остаются доступными через другие геореплики — отправка, получение и удаление по-прежнему выполняются через оставшиеся геореплики.

Избыточность зоны всегда включена для геореплик— ACR автоматически распределяет данные реплик по нескольким зонам доступности для защиты от зональных сбоев.

Переключение при отказе с учетом состояния работоспособности

ACR автоматически отслеживает работоспособность каждой геореплики и перенаправляет трафик глобальной конечной точки от геореплик, которые не могут надежно обслуживать запросы. Это называется переключением при отказе с учётом состояния работоспособности. ACR направляет глобальный трафик к конечной точке на основе работоспособности службы ACR и состояния региональной инфраструктуры Azure.

• Автоматически и для каждого реестра: Состояние оценивается для каждого реестра отдельно, а не для каждого региона. Если снижение влияет только на подмножество реестров в регионе, перенаправляются только эти реестры— другие реестры в том же регионе продолжают обслуживаться локально без ненужных штрафов за задержку.
• Сроки: сквозное перенаправление занимает порядка нескольких минут — достаточно быстро, чтобы выявить реальное ухудшение работы в регионе, и достаточно медленно, чтобы переждать кратковременные сбои, которые проходят сами собой. Dns TTL может добавить задержку распространения до перехода всех клиентов в новый регион.
• От клиента не требуется никаких действий: триггер, запускаемый клиентом, отсутствует. Аварийное переключение с учетом работоспособности полностью управляется платформой.
• Обратное переключение выполняется автоматически: как только оценка работоспособности геореплики в регионе снова становится положительной, например после восстановления регионального экземпляра ACR или инфраструктуры Azure, глобальная конечная точка может возобновить маршрутизацию трафика на геореплику в восстановленном регионе Azure.
• Не запускается из-за ограничения скорости: автоматическое переключение при сбое с учётом состояния работоспособности выполняется на основе DNS и реагирует на состояние работоспособности региональной службы ACR и инфраструктуры Azure. Он не перенаправляет трафик в ответ на HTTP-ответы 429 (ограничение частоты запросов). Если геореплика ограничивает скорость обработки ваших запросов, но инфраструктура региона работоспособна, глобальная конечная точка доступа продолжает направлять вас в эту геореплику. Чтобы справиться с ограничением пропускной способности, используйте региональные конечные точки доступа, чтобы распределить рабочие нагрузки по нескольким георепликам для более равномерного распределения ресурсов.

Область применения переключения при отказе с учетом состояния работоспособности:

Автоматическое переключение при отказе с учетом работоспособности применяется только к операциям, использующим глобальную конечную точку (myregistry.azurecr.io). Он не применяется к:

• Региональные конечные точки — при использовании региональной конечной точки (myregistry.<region>.geo.azurecr.io) вы напрямую разговариваете с одной конкретной георепликой. Если этот регион ухудшается, ACR не перенаправляется автоматически. Реализуйте аварийное переключение на стороне клиента путём переключения на другую региональную конечную точку.
• Выделенные конечные точки данных — после перенаправления конечной точки реестра на выделенную конечную точку данных для скачивания слоя вы остаетесь на конечной точке данных этого региона на протяжении всего скачивания. Регион определяется заранее по тому, какой именно конечный узел реестра обработал запрос blob-location.

Ограничение при аварийном переключении:

Ограничения троттлинга на операции API применяются к каждой реплике. Во время аварийного переключения с учетом работоспособности трафик, распределенный между несколькими георепликами, может в значительной степени переключиться на те геореплики, которые остаются в пуле маршрутизации глобальной конечной точки. Планирование емкости должно предусматривать как минимум две-три геореплики, чтобы при аварийном переключении трафик мог распределяться между несколькими работоспособными георепликами. Реестры только с двумя регионами могут легче достичь лимитов троттлинга для каждой реплики, если один из регионов недоступен. Чтобы устранить проблему, используйте региональные конечные точки для распространения рабочих нагрузок по нескольким георепликам и планированию емкости для каждой реплики.

Как подтвердить переключение на резервный ресурс:

• портал Azure. Перейдите к реестру и выберите Resource health в разделе Help, чтобы просмотреть сигналы снижения на стороне платформы.
• Azure CLI: проверьте состояние репликации с помощью az acr replication list --registry myregistry --output table. Геореплики, в работе которых возникают проблемы, имеют состояние, отличное от online.
• Azure Monitor: метрики платформы собираются автоматически. Включите параметры диагностики для журналов ресурсов для получения подробных данных телеметрии.

Поведение сбоя в домашнем регионе

Домашний регион — это регион, в котором вы создали реестр. Он размещает уровень управления реестра, который управляет конфигурацией реестра. Домашний регион фиксируется во время создания и не может быть изменен впоследствии. Чтобы переместить реестр в другой домашний регион, см. раздел Relocate Реестр контейнеров Azure, описывающий процедуру повторного развертывания (создание нового реестра), а не изменение на месте.

Если основной регион становится недоступным, последствия затрагивают только операции в плоскости управления (управления). Все операции плоскости обработки данных продолжают работать через оставшиеся геореплики.

Что функционирует во время сбоя в домашнем регионе:

• Отправка изображений, извлечение и удаление . Клиенты могут отправлять, извлекать и удалять изображения из любой доступной геореплики с помощью глобальной конечной точки (myregistry.azurecr.io) или любой доступной региональной конечной точки (myregistry.<region>.geo.azurecr.io). ACR автоматически направляет запросы к глобальной конечной точке к работоспособной геореплике.
• Аутентификация — Все методы аутентификации продолжают работать, включая Microsoft Entra ID, субъекты-служб, управляемые удостоверения и токены с областью действия репозитория. Клиенты могут проходить проверку подлинности в любой доступной геореплике без необходимости изменять учетные данные, маркеры или URL-адреса реестра.
• Доставка вебхуков — вебхуки, настроенные для доступных геореплик, продолжают срабатывать. Одна отправка приводит к событиям webhook от принимающей геореплики, а также к событиям от каждой геореплики по мере завершения репликации. Потребителей вебхуков следует проектировать так, чтобы они могли обрабатывать несколько событий для каждого образа, отправленного в реестр, и при необходимости устранять дубликаты.
• Региональные конечные точки — если включены региональные конечные точки, они продолжают работать независимо. Клиенты могут напрямую взаимодействовать с конкретными георепликами с помощью URL-адресов региональной конечной точки.

Что недоступно во время сбоя домашнего региона:

• Маршрутизация глобальной конечной точки в геореплику основного региона — проверка работоспособности ACR автоматически прекращает направлять трафик глобальной конечной точки в геореплику основного региона и перенаправляет его на работоспособные геореплики.
• Региональная конечная точка для домашнего региона — региональная конечная точкаmyregistry.<home-region>.geo.azurecr.io домашнего региона недоступна, пока домашний регион недоступен. Региональные конечные точки для других геореплик продолжают работать независимо.
• Изменения конфигурации реестра — нельзя изменять такие свойства реестра, как правила сети, параметры репликации или конфигурации зоны доступности до восстановления домашнего региона.
• Задачи ACR — задачи привязаны к домашнему региону и не выполняются, пока он недоступен.

Рекомендации по уровню служб и ограничениям

Уровни обслуживания и ограничения Реестр контейнеров Azure применяются к каждой геореплике по отдельности.

Некоторые ограничения уровня служб требуют особого внимания:

• Ограничения хранилища: ограничения хранилища для вашего уровня обслуживания являются общими для всех геореплик. Например, если вы загружаете образ размером 1 ГиБ и он реплицируется в 5 геореплик, в счет максимального объема хранилища, доступного в вашем ценовом уровне, засчитывается только 1 ГиБ.
• Ограничения скорости API: ограничения регулирования операций API, такие как количество операций чтения и записи в минуту, зависят от геореплики. Используйте региональные конечные точки для распространения рабочих нагрузок между несколькими георепликами для улучшения распределения емкости и предотвращения концентрации всего трафика на одной геореплике.

Дополнительные сведения о уровнях служб и ограничениях см. в разделе "Уровни служб ACR".

Рекомендации по ценам

• Тарификация хранилища: Хранилище тарифицируется отдельно для каждой геореплики. Например, образ размером 1 ГиБ, реплицированный в 5 георепликах, тарифицируется как 5 ГиБ хранилища (1 ГиБ × 5 геореплик).
• Передача данных. Георепликация может снизить затраты, включив отправки и вытягивание изображений в регионе, что позволяет избежать расходов на передачу данных между регионами во время этих операций отправки или извлечения. Однако плата за передачу данных между регионами по-прежнему взимается, когда ACR реплицирует отправленный контент в другие геореплики в процессе достижения конечной согласованности.

Дополнительные сведения см. в разделе о ценах ACR.

Добавление или удаление геореплик

Необходимые разрешения

Чтобы управлять георепликами, ваше удостоверение должно иметь следующие разрешения:

Портал Azure

1. Перейдите в реестр на портале Azure.
2. В разделе "Службы" выберите георепликацию.
3. На карте:
   • Синий шестнадцатеричный: домашний регион (где вы создали реестр)
   • Зеленые шестиугольники: доступные регионы
   • Серые шестиугольники: недоступные регионы
4. Выберите зеленый шестнадцатеричник, а затем нажмите кнопку "Создать".

Azure CLI (Интерфейс командной строки для Azure)

# 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.

Глобальная конечная точка геореплицированного реестра

После настройки георепликации вы можете отправить, извлечь или удалить содержимое в реестре через глобальную конечную точку реестра (myregistry.azurecr.io).

Как работают глобальные конечные точки

Когда вы отправляете, скачиваете или удаляете данные через глобальную конечную точку, ACR направляет запрос в геореплику с наилучшими характеристиками сетевой производительности для клиента.

• Геореплика с лучшим профилем производительности сети от клиента обычно является ближайшей георепликой.
• Однако если клиент находится на одинаковом расстоянии от нескольких геореплик или ближайшая геореплика недоступна, запросы могут быть перенаправлены в другое место.
• ACR управляет этой маршрутизацией. Вы не контролируете, какая геореплика обрабатывает конкретный запрос.

Использование глобальной конечной точки

Проверки подлинности:

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

Временно исключить геореплику из глобальной маршрутизации конечных точек

Вы можете исключить геореплику из глобальной маршрутизации конечных точек, отключив --global-endpoint-routing параметр для конкретной геореплики. Это полезно во время обслуживания или устранения неполадок, а также когда вам известно, что в конкретной геореплике или регионе Azure наблюдается снижение производительности. Вы даже можете отключить маршрутизацию глобальной конечной точки для геореплики исходного региона — исходный регион используется только для операций в плоскости управления, а трафик его плоскости данных можно безопасно исключить из глобальной маршрутизации. Дополнительные сведения о том, что контролирует домашний регион, см. в разделе Поведение при сбое домашнего региона.

• --global-endpoint-routing Если для конкретной геореплики задано falseзначение, ACR останавливает маршрутизацию запросов на ту конкретную геореплику для запросов, которые отправляются в глобальную конечную точку.
• Данные продолжают синхронизироваться двунаправленно с георепликой, даже если глобальная маршрутизация конечных точек отключена для конкретной геореплики. Каждый образ, отправленный в реестр из любого региона, даже если геореплика исключена из глобальной маршрутизации, всё равно реплицируется в неё. После повторного включения геореплика сразу готова принимать трафик без периода догоняющей синхронизации.
• Таким образом, квота хранилища и затраты продолжают увеличиваться для этой геореплики.
• Если включены региональные конечные точки, URL-адресmyregistry.<region-name>.geo.azurecr.io региональной конечной точки геореплики продолжает работать, даже если глобальная маршрутизация конечных точек отключена. --global-endpoint-routing управляет только участием геореплики в глобальной маршрутизации конечных точек.

# 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

Региональные конечные точки геореплицированного реестра (предварительная версия)

Региональные конечные точки предоставляют выделенные URL-адреса для каждой реплики, что позволяет точно указать, какая региональная геореплика будет обрабатывать ваш запрос на отправку, получение или удаление:

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

Используйте региональные конечные точки при необходимости:

Региональные конечные точки сосуществуют с глобальными конечными точками

Включение региональных конечных точек не отключает или не заменяет глобальную конечную точку. Вы можете использовать оба одновременно:

• Используйте глобальную конечную точку (myregistry.azurecr.io), если вы предпочитаете автоматическую маршрутизацию между георепликами под управлением Azure.
• Используйте региональные конечные точки (myregistry.<region-name>.geo.azurecr.io), если требуется более точное управление маршрутизацией на стороне клиента, обходя полностью управляемую Azure маршрутизацию глобальной конечной точки.

Как работают региональные конечные точки

Региональные конечные точки работают как серверы входа для определенных геореплик. При проверке подлинности и взаимодействии с региональной конечной точкой вместо глобальной конечной точки реестра все операции реестра (проверка подлинности, отправка артефактов и загрузки, операции репозитория и действия метаданных) переходят непосредственно к определенной региональной реплике, обходя полностью управляемую Azure маршрутизацию.

Загрузка blob-объектов слоёв (то есть самих слоёв образа контейнера) по-прежнему выполняется в соответствии с текущей конфигурацией вашего реестра:

• Реестры без приватных конечных точек или выделенных конечных точек данных: при скачивании слоев образа из определенной геореплики загрузка BLOB-объектов слоев перенаправляется в учетные записи хранения Azure (*.blob.core.windows.net).
• Реестры с включёнными частными конечными точками или выделенными конечными точками данных: при скачивании слоёв образа из определённой геореплики скачивание BLOB-объектов слоёв перенаправляется на выделенную конечную точку данных соответствующего региона (myregistry.<region-name>.data.azurecr.io).

На приведённой ниже схеме показан поток запросов к региональной конечной точке:

Предварительные требования для региональных конечных точек

• SKU уровня "Премиум" — региональные конечные точки доступны исключительно в реестрах уровня "Премиум".
• 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

Региональные конечные точки включены на уровне реестра и применяются к каждой геореплике. Не удается включить региональные конечные точки для отдельных реплик. При включении региональных конечных точек Реестр контейнеров Azure автоматически создает URL-адреса сервера входа для каждой геореплики.

Работа с региональными конечными точками

Проверка подлинности и использование региональных конечных точек

Региональные конечные точки поддерживают те же способы аутентификации, что и глобальная конечная точка: Microsoft Entra ID, субъекты-служб, управляемые удостоверения и учетные данные администратора.

Войдите в определенную региональную конечную точку:

az acr login --name myregistry --endpoint eastus

Пометьте и отправьте изображение в региональную конечную точку. Изображения и теги, отправленные в геореплику через региональную конечную точку, по-прежнему будут распространяться на все остальные геореплики при конечной согласованности.

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

Использование региональных конечных точек, внедренных в манифесты развертывания

Можно указать региональные конечные точки непосредственно в манифестах развертывания 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) в ACR см. в разделе Аутентификация в Реестр контейнеров Azure из Служба Azure Kubernetes.

Использование региональных конечных точек с маршрутизацией на основе DNS без изменения манифестов развертывания

Если вы не хотите поддерживать различные манифесты развертывания в каждом регионе, можно сохранить все манифесты, указывающие на глобальную конечную точку (myregistry.azurecr.io) и использовать программно-определяемую сеть или региональный диспетчер трафика, чтобы разрешить глобальную конечную точку соответствующей региональной конечной точке на основе трафика исходного региона. Это обеспечивает те же цели совместного размещения, что и региональные конечные точки (прогнозируемая маршрутизация и снижение задержки), не внедряя URL-адреса конкретного региона в манифесты развертывания.

Сведения об аутентификации Azure Kubernetes Service (AKS) в ACR см. в разделе Аутентификация в Реестр контейнеров Azure из Служба Azure Kubernetes.

Импорт из определенных геореплик с помощью региональных конечных точек

При импорте образов между реестрами можно использовать региональные конечные точки для импорта из определенной геореплики исходного реестра. Это полезно для сценариев, когда требуется прогнозируемые сетевые пути или требуется импортировать из реплики в определенном регионе.

az acr import \
  --name mydownstreamregistry \
  --source myupstreamregistry.westeurope.geo.azurecr.io/myapp:v1 \
  --image myapp:v1

Рекомендации по сети для региональных конечных точек

Правила брандмауэра

Если вы используете правила брандмауэра ACR или настраиваемые брандмауэры с региональными конечными точками, настройте правила брандмауэра, чтобы разрешить доступ:

Приватные конечные точки

При создании частной конечной точки для реестра в виртуальной сети ресурс частной конечной точки предоставляет несколько частных IP-адресов виртуальной сети, охватывающих все области конечных точек реестра — глобальную конечную точку, каждую региональную конечную точку (если включены региональные конечные точки), а также каждую выделенную конечную точку данных (автоматически включена при настройке частной конечной точки).

Каждая конечная точка использует один частный IP-адрес из подсети виртуальной сети. Запланируйте размер подсети соответствующим образом:

• 1 IP-адрес для глобальной конечной точки (myregistry.azurecr.io)
• 1 IP-адрес для каждой геореплики для выделенных конечных точек данных (myregistry.<region>.data.azurecr.io) — всегда включено в реестрах как минимум с одной частной конечной точкой
• Один IP-адрес на геореплику для региональных конечных точек (myregistry.<region>.geo.azurecr.io) — только если включены региональные конечные точки

Пример. Для реестра с 3 георепликами и региональными конечными точками требуется 1 (глобальный) + 3 (данные) + 3 (региональные) = 7 частных IP-адресов на ресурс частной конечной точки. Без региональных конечных точек для одного реестра требуется 1 + 3 = 4 частных IP-адресов.

При наличии множества географических реплик создание частной конечной точки может завершиться ошибкой, если в подсети закончатся доступные IP-адреса. Дополнительные сведения см. в статье "Частное подключение к реестру из виртуальной сети с помощью частных конечных точек".

Выделенные конечные точки данных

Если региональные конечные точки включены вместе с выделенными конечными точками данных — либо включёнными явно, либо включающимися автоматически при настройке хотя бы одной частной конечной точки, — загрузка BLOB-объектов слоя из региональных конечных точек автоматически перенаправляется на выделенную конечную точку данных геореплики (myregistry.<region-name>.data.azurecr.io). Перенаправление всегда остается в том же регионе, что и региональная конечная точка: запрос к myregistry.eastus.geo.azurecr.io всегда перенаправляется на myregistry.eastus.data.azurecr.io, а не на конечную точку данных в другом регионе.

Эта гарантия размещения в том же регионе также действует при получении данных через глобальную конечную точку доступа. ACR направляет запрос в геореплику с наилучшими сетевыми характеристиками для клиента, а обслуживающая его геореплика возвращает перенаправление 307 на собственную выделенную конечную точку доступа к данным — и никогда не в другой регион.

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

Дополнительные сведения см. в разделе Выделенные конечные точки данных в Реестр контейнеров Azure.

Ссылка на конечную точку

Полный справочник по всем типам конечных точек реестра, форматам URL-адресов и флагам CLI, которые управляют ими, см. в справочнике по конечным точкам Реестр контейнеров Azure.

Устранение неполадок

Сбой принудительной отправки с ошибками манифеста

docker push — это последовательность HTTP-запросов: загрузка BLOB-объектов для каждого слоя, а затем загрузка манифеста, который ссылается на эти слои по дайджесту. Некоторые сопоставители DNS Linux не кэшируют ответы последовательно. Если в близлежащих регионах есть несколько геореплик, DNS может разрешаться в разные реплики в ходе одной отправки (переключение DNS), из-за чего отправленный манифест будет ссылаться на слои, отправленные в другую геореплику. Поскольку репликация обеспечивает согласованность лишь со временем, манифест может попасть на реплику, которая ещё не содержит слоёв, на которые он ссылается, и проверка манифеста завершается ошибкой.

Решения (в порядке предпочтения):

1. Используйте региональные эндпоинты, чтобы привязать отправку к одной геореплике на всём пути. Каждый подзапрос (вход в систему, отправка BLOB-объектов, отправка манифеста) направляется в одну и ту же геореплику. Это самое чистое решение и рекомендуемый подход для любого пайплайна, где важна согласованность push/pull.
2. Используйте кратковременный кэш DNS, например dnsmasq на время одной отправки. Сведения о виртуальных машинах Linux в Azure см. в параметрах разрешения DNS-имен. Закрепление должно сохраняться только на время отправки и не дольше — не используйте долгоживущий DNS-кеш для глобальной конечной точки, поскольку это мешает --global-endpoint-routing false и маршрутизации аварийного переключения с учетом состояния работоспособности.
3. Спроектируйте этапы публикации так, чтобы они были идемпотентными, чтобы повторные попытки после сбоев в середине отправки были безопасны.

Создание геореплики зависло для реестров с поддержкой частных конечных точек

Эта проблема обычно возникает, когда субъект, создающий геореплику для реестра с включенной приватной конечной точкой, не имеет достаточных разрешений на создание сетевых ресурсов для приватной конечной точки.

Решение.

• Чтобы устранить проблему, удалите геореплику, которая зависла в состоянии подготовки.
• После этого убедитесь, что идентификатор имеет разрешение Microsoft.Network/privateEndpoints/privateLinkServiceProxies/write перед созданием геореплики.
• Кроме того, убедитесь, что каждая подсеть частной конечной точки, подключенная к реестру, имеет свободный IP-адрес. Если любая подсеть в любой подключенной виртуальной сети не имеет достаточно свободных IP-адресов, подготовка репликации завершается сбоем и откатом. Реплика отображается кратковременно в Creating состоянии, а затем удаляется. Результирующая ошибка не определяет, какая подсеть или виртуальная сеть исчерпана. Рекомендации по размеру подсети см. в статье "Подключение к реестру с помощью частных конечных точек".

Не удается создать геореплику в реестрах с частной конечной точкой со статическим IP-адресом

Добавление геореплики завершается ошибкой, если закрытая конечная точка реестра настроена со статическим назначением частного IP-адреса.

Каждая геореплика имеет собственную выделенную конечную точку данных, которая представлена в частной конечной точке как член с идентификатором группы registry и именем члена registry_data_<region>. При добавлении новой геореплики 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.

Чтобы проверить метод выделения частной конечной точки реестра, проверьте PrivateIPAllocationMethod конфигурации IP-адресов в сетевом интерфейсе частной конечной точки. Частная конечная точка ссылается на сетевой интерфейс, содержащий эти IP-конфигурации, поэтому сначала получите идентификатор сетевого интерфейса, а затем проверьте его 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

Решения:

• Используйте динамическое выделение IP-адресов для частной конечной точки, если вы планируете добавить геореплики позже. При динамическом выделении ACR автоматически создает элемент конечной точки данных для каждого нового региона. Это рекомендуемый подход.
• Создайте частную конечную точку после создания всех геореплик, если требуется назначение статических IP-адресов. Сначала добавьте каждую геореплику, а затем создайте частную конечную точку статического IP-адреса, чтобы ее IP-конфигурация включает в себя член для каждой существующей конечной точки данных региона. После создания таким способом частной конечной точки со статическим IP-адресом нельзя добавить другие геореплики, если не перенастроить частную конечную точку и не добавить нового участника.

Связанный контент

• Номера SKU ACR и уровни служб
• Справочник по конечной точке
• Вебхуки
• Приватные конечные точки
• Выделенные конечные точки данных
• Настройка правил доступа к брандмауэру