Сообщить об ошибкеКороткий ответ
Выбор зависит от требований к latency pull в разных регионах, ограничений по размещению данных (data residency), бюджета на managed-сервис против операционных затрат на self-hosted реестр и критичности доступности registry для процесса деплоя; единственно верного ответа нет — решение нужно обсуждать с учётом конкретных критериев организации.
Как это работает подробнее
любой вариант реализует одну и ту же базовую функцию (хранение и раздача слоёв образов по тегам/digest), различия — в операционной модели. Managed-реестр облачного провайдера (ECR, GCR, ACR) снимает с команды задачи HA, патчинга и backup самого реестра, но привязывает к конкретному облаку и тарифицирует трафик/хранение по модели провайдера. Self-hosted решение (например, Harbor) даёт полный контроль, мультиоблачность и возможность репликации между регионами на своих условиях, но требует отдельной команды/процесса поддержки его отказоустойчивости, обновлений безопасности и backup'ов хранилища слоёв.
Пример кода
# Harbor replication policy (пример): репликация образов
# из центрального registry в региональный read-only кэш
replication:
name: eu-to-apac
src_registry: harbor-eu.internal
dest_registry: harbor-apac.internal
trigger: event_based
filters:
- type: tag
value: "release-*"Что использовать на практике
- Практика. для глобально распределённых команд часто комбинируют подходы — один "источник правды" (центральный реестр с строгим контролем доступа и сканированием) и региональные read-through кэши/реплики ближе к кластерам, чтобы деплой не зависел от сетевой доступности центрального реестра при каждом
pull.
Подводные камни
- Риск. выбирают единственный централизованный реестр без региональных реплик для глобально распределённой инфраструктуры, из-за чего деплой в дальнем регионе зависит от сетевого пути через весь мир; либо наоборот — разворачивают независимые нерепликруемые реестры в каждом регионе без единого источника правды, из-за чего теряется контроль версий и аудит.