Сведения о частных реестрах и GitHub Codespaces
Реестр — это безопасное пространство для хранения, управления и получения образов контейнеров или других пакетов. Существует множество примеров реестров, например:
- GitHub Container registry, Реестр контейнеров Azure и DockerHub для образов контейнеров
- npm registry для пакетов Node.js.
Некоторые реестры GitHub Packages, включая Container registry, можно настроить таким образом, чтобы пакеты могли легко извлекаться в GitHub Codespaces во время создания codespace без необходимости предоставлять учетные данные для проверки подлинности.
Чтобы получить доступ к другим реестрам образов контейнеров, можно создать секреты в GitHub для хранения сведений о доступе, что позволит GitHub Codespaces получать доступ к образам, хранящимся в этом реестре.
Доступ к пакетам, хранящимся в реестрах, с детализированными разрешениями
Реестры GitHub Packages, поддерживающие детализированные разрешения, включая Container registry, предоставляют самый простой способ использования пакетов для GitHub Codespaces. Список реестров GitHub Packages, которые поддерживают детализированные разрешения и простой доступ к GitHub Codespaces, см. в разделе Сведения о разрешениях для пакетов GitHub.
Доступ к пакету, опубликованному в том же репозитории, что и codespace
При публикации пакета в том же репозитории, в который запускается codespace, вы сможете автоматически получить этот пакет при создании codespace. Вам не нужно будет предоставлять дополнительные учетные данные, если при публикации пакета не был выбран параметр Наследовать доступ из репозитория .
Наследование доступа из репозитория, из которого был опубликован пакет
По умолчанию пакет наследует параметр доступа репозитория, из которого он был опубликован. Например, если репозиторий является общедоступным, пакет также является общедоступным. Если репозиторий является частным, пакет также является частным, но доступен из репозитория.
Это поведение определяется параметром Наследовать доступ от репозитория. Наследовать доступ из репозитория выбирается по умолчанию при публикации через GitHub Actions, но не при публикации непосредственно в реестре с помощью personal access token.
Если при публикации пакета не был выбран параметр Наследовать доступ из репозитория , вы можете вручную добавить репозиторий в элементы управления доступом к опубликованному пакету. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Доступ к пакету, опубликованному в организации, в котором будет запущено codespace
Если вы хотите, чтобы пакет был доступен для всех кодовых пространств в организации, рекомендуется опубликовать пакет с внутренней видимостью. Это автоматически сделает пакет видимым для всех codespace в организации, если только репозиторий, из который запускается codespace, не является общедоступным.
Если codespace запускается из общедоступного репозитория, ссылающегося на внутренний или частный пакет, необходимо вручную разрешить общедоступному репозиторию доступ к внутреннему пакету. Это предотвращает случайную утечку внутреннего пакета. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Доступ к частному пакету из подмножества репозиториев в организации
Если вы хотите разрешить подмножеству репозиториев организации доступ к пакету или разрешить доступ к внутреннему или частному пакету из codespace, запущенного в общедоступном репозитории, можно вручную добавить репозитории в параметры доступа к пакету. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Публикация пакета из codespace
Простой доступ из codespace к реестру ограничен извлечением пакетов. Если вы хотите опубликовать пакет из пространства кода, необходимо использовать personal access token (classic) с областью write:packages .
Рекомендуется публиковать пакеты через GitHub Actions. Дополнительные сведения см. в разделах Публикация образов Docker и Публикация пакетов Node.js.
Доступ к образам, хранящимся в других реестрах
Вы можете определить секреты, чтобы разрешить GitHub Codespaces доступ к реестрам образов контейнеров, отличных от GitHub Container registry. Если вы обращаетесь к образу контейнера из реестра, который не поддерживает простой доступ, GitHub Codespaces проверяет наличие трех секретов, которые определяют имя сервера, имя пользователя и personal access token для реестра. Если эти секреты найдены, GitHub Codespaces сделает реестр доступным в пространстве кода.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Секреты можно хранить на уровне пользователя, репозитория или организации, что позволяет безопасно передавать их между различными пространствами кода. При создании набора секретов для частного реестра образов необходимо заменить "<*>" в имени на постоянный идентификатор. Дополнительные сведения см. в разделах Управление зашифрованными секретами для codespace и Управление зашифрованными секретами для репозитория и организации в GitHub Codespaces.
Если вы задаете секреты на уровне пользователя или организации, обязательно назначьте эти секреты репозиторию, в котором будет создаваться пространство кода, выбрав политику доступа из раскрывающегося списка.
Примеры секретов
Для частного реестра образов в Azure можно создать следующие секреты:
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Дополнительные сведения об общих реестрах образов см. в разделе Серверы общих реестров образов. Обратите внимание, что доступ к реестру эластичных контейнеров AWS (ECR) осуществляется другим способом.
После добавления секретов может потребоваться остановить и запустить пространство кода, в котором вы находитесь, чтобы новые переменные среды были переданы в контейнер. Дополнительные сведения см. в разделе Использование палитры команд Visual Studio Code в GitHub Codespaces.
Доступ к реестру эластичных контейнеров AWS
Чтобы получить доступ к реестру эластичных контейнеров AWS (ECR), можно предоставить идентификатор ключа доступа AWS и секретный ключ, и GitHub может получить маркер доступа и выполнить вход от вашего имени.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
Кроме того, необходимо убедиться в том, что у вас есть соответствующие разрешения IAM AWS для переключения учетных данных (например, sts:GetServiceBearerToken) и операции чтения ECR (AmazonEC2ContainerRegistryFullAccess или ReadOnlyAccess).
Кроме того, если вы не хотите, чтобы GitHub выполнял переключение учетных данных от вашего имени, вы можете предоставить маркер авторизации, для получения которого используются API-интерфейсы или CLI AWS.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
Так как эти токены являются короткими и должны периодически обновляться, рекомендуется указать идентификатор ключа доступа и секрет.
Хотя эти секреты могут иметь любое имя, при условии, что *_CONTAINER_REGISTRY_SERVER входит в URL-адрес ECR, мы рекомендуем использовать ECR_CONTAINER_REGISTRY_*, если вы не работаете с несколькими реестрами ECR.
Дополнительные сведения см. в разделе Документация по проверке подлинности частного реестра для ECR AWS.
Серверы общих реестров образов
Некоторые из серверов общих реестров образов перечислены ниже:
- DockerHub -
https://index.docker.io/v1/; - Реестр контейнеров GitHub -
ghcr.io; - Реестр контейнеров Azure -
<registry name>.azurecr.io; - Реестр эластичных контейнеров AWS -
<aws_account_id>.dkr.ecr.<region>.amazonaws.com; - Реестр контейнеров Google Cloud -
gcr.io(США),eu.gcr.io(Европа),asia.gcr.io(Азия).
Отладка доступа к частному реестру образов
Если у вас возникли проблемы с извлечением образа из частного реестра образов, убедитесь, что вы можете успешно выполнить команду docker login -u <user> -p <password> <server> со значениями секретов, которые были определены выше. Если вход не удается, убедитесь, что учетные данные для входа действительны и у вас есть соответствующие разрешения на сервере для получения образа контейнера. Если вход выполнен успешно, убедитесь, что эти значения правильно скопированы в правильные секреты GitHub Codespaces на уровне пользователя, репозитория или организации, и повторите попытку.