Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье представлен обзор методов и рабочих процессов для использования локального реестра, например реестра контейнеров Azure для поддержания копий общедоступного содержимого, включая образы контейнеров в Docker Hub.
Риски, связанные с общедоступным содержимым
Ваша среда может зависеть от общедоступного содержимого, например, общедоступных образов контейнеров, Helm charts, политик Open Policy Agent (OPA) или других артефактов. Возможно, например, вы запускаете nginx для маршрутизации службы или docker build FROM alpine путем извлечения образов непосредственно из Docker Hub или другого общедоступного реестра.
Без соответствующих элементов управления наличие зависимостей от общедоступного содержимого реестра может привести к рискам, связанным с рабочими процессами разработки и развертывания образов. Чтобы снизить риски, по возможности сохраняйте локальные копии общедоступного содержимого. Дополнительные сведения см. в блоге Open Container Initiative.
Проверка подлинности с помощью Docker Hub
Если в настоящее время вы извлекаете общедоступные образы из Docker Hub в рамках рабочего процесса сборки или развертывания, рекомендуется пройти проверку подлинности с помощью учетной записи Docker Hub , а не выполнять анонимный запрос на вытягивание.
При выполнении частых анонимных pull запросов могут появиться ошибки Docker, аналогичные ERROR: toomanyrequests: Too Many Requests. или You have reached your pull rate limit.. Войдите в Docker Hub, чтобы предотвратить эти ошибки.
Примечание.
Ограничения скорости загрузки применяются к анонимным и прошедшим проверку подлинности запросам в Docker Hub из учетных записей бесплатного плана Docker. Эти ограничения применяются IP-адресом и идентификатором Docker соответственно.
Чтобы оценить количество запросов на вытягивание, имейте в виду, что при использовании облачных служб поставщика или работе с корпоративным NAT несколько пользователей отображаются в Docker Hub в качестве подмножества IP-адресов. Добавив проверку подлинности платной учетной записи Docker к запросам, сделанным в Docker Hub, можно избежать потенциальных сбоев служб, вызванных регулированием с ограничением скорости.
Дополнительные сведения см. на странице цен и подписок на Docker и в условиях предоставления услуг Docker.
Маркер доступа к Docker Hub
Docker Hub поддерживает личные маркеры доступа в качестве альтернативы паролю Docker при проверке подлинности в Docker Hub. Маркеры рекомендуется использовать для автоматических служб, которые извлекают образы из Docker Hub. Можно создать несколько маркеров для разных пользователей или служб и отозвать их, если они больше не нужны.
Чтобы выполнить проверку подлинности с помощью маркера, используя docker login, не указывайте пароль в командной строке. При запросе пароля введите вместо этого маркер. Если вы включили двухфакторную проверку подлинности для учетной записи Docker Hub, необходимо использовать личный маркер доступа при входе из интерфейса командной строки Docker.
Аутентификация из служб Azure
Несколько служб Azure, включая службу приложений и экземпляры контейнеров Azure, поддерживают извлечение образов из общедоступных реестров, таких как Docker Hub для развертываний контейнеров. Если необходимо развернуть образ из Docker Hub, рекомендуется настроить параметры для проверки подлинности с помощью учетной записи Docker Hub. Примеры:
Служба приложений
- Источник образа: Docker Hub
- Доступ к репозиторию: частный
- Имя входа: <Имя пользователя Docker Hub>
- Пароль: <Токен Docker Hub>
Дополнительные сведения см. на странице Операции извлечения с проверкой подлинности в Docker Hub для Службы приложений.
Экземпляры контейнеров Azure
- Источник образа: Docker Hub или другой реестр
- Тип образа: частный
- Сервер входа для реестра образов: docker.io
- Имя пользователя реестра образа: <Имя пользователя Docker Hub>
- Пароль реестра образа: <Токен Docker Hub>
- Изображение: <имя репозитория docker.io/>:<тег>
Настройка кэша артефактов для использования общедоступного содержимого
Рекомендуется использовать общедоступное содержимое для объединения проверки подлинности реестра и функции кэша артефактов. Используйте кэш артефактов для кэширования артефактов контейнера в реестр контейнеров Azure даже в частных сетях. Использование кэша артефактов не только защищает вас от ограничений скорости реестра, но и значительно повышает надежность извлечения при сочетании с геореплицированным ACR для извлечения артефактов из региона, ближайшего к ресурсу Azure. Можно использовать все функции безопасности, которые предлагает ACR, включая частные сети, конфигурацию брандмауэра, служебные принципалы и другие. Полные сведения об использовании общедоступного содержимого с кэшем артефактов ACR см. в руководстве по кэшу артефактов .
Импорт образов в Реестр контейнеров Azure
Чтобы управлять копиями общедоступных образов, создайте реестр контейнеров Azure, если у вас еще нет. Используйте Azure CLI, портал Azure, Azure PowerShell или другие средства для создания реестра.
Рекомендуется также однократно импортировать базовые образы и другое общедоступное содержимое в Реестр контейнеров Azure. Команда az acr import в Azure CLI поддерживает импорт образов из общедоступных реестров, таких как Docker Hub и Реестр контейнеров Майкрософт, а также из частных реестров контейнеров.
az acr import не требует локальной установки Docker. Эту команду можно использовать с локальной установкой Azure CLI или непосредственно в Azure Cloud Shell. Она поддерживает образы с ОС любых типов, образы с несколькими архитектурами и артефакты OCI, такие как диаграммы Helm.
В зависимости от потребностей организации импорт можно выполнить в выделенный реестр или репозиторий в общем реестре.
az acr import \
--name myregistry \
--source docker.io/library/hello-world:latest \
--image hello-world:latest \
--username <Docker Hub username> \
--password <Docker Hub token>
Обновление ссылок на образы
Разработчики образов приложений должны проследить, чтобы их код ссылался на контролируемое ими локальное содержимое.
- Обновите ссылки на образы, чтобы использовать частный реестр. Например, обновите инструкцию
FROM baseimage:v1в Dockerfile доFROM myregistry.azurecr.io/mybaseimage:v1для реестра, не поддерживающего DNL, илиFROM myregistry-abc123.azurecr.io/mybaseimage:v1для реестра с включенной поддержкой DNL. Дополнительные сведения о параметрах DNL в процессе создания реестра и влиянии DNS-имени см. в Кратком руководстве - создание реестра на портале. - Настройте учетные данные или механизм аутентификации для использования частного реестра. Точный механизм зависит от средств, используемых для доступа к реестру, и способа для управления доступом пользователей.
- Если для доступа к реестру используется кластер Kubernetes или Служба Azure Kubernetes, см. сценарии аутентификации.
- Узнайте больше о способах аутентификации с помощью реестра контейнеров Azure.
Автоматизация обновления образов приложения
Чтобы автоматизировать сборки образов приложения при обновлении базовых образов, настройте задачу реестра контейнеров Azure. Этот подход расширяется при импорте изображений. Автоматизированная задача сборки может отслеживать как обновления базовых образов, так и обновления исходного кода.
Подробный пример см. в статье Использование и обслуживание общедоступного содержимого с помощью Задач Реестра контейнеров Azure.
Примечание.
Одна предварительно настроенная задача может автоматически собирать заново каждый образ приложения, который ссылается на зависимый базовый образ.
Следующие шаги
- Узнайте больше о Задачах Реестра контейнеров Azure для создания, запуска, отправки и исправления образов контейнеров в Azure.
- Сведения об использовании рабочего процесса автоматизированного ограничения для обновления базовых образов в среде см. в статье Использование и обслуживание общедоступного содержимого с помощью Задач Реестра контейнеров Azure.
- Дополнительные примеры по автоматизации сборок и обновлений образа см. в учебниках по Задачам Реестра контейнеров Azure.