О частных реестрах и GitHub Codespaces
Реестр — это безопасное пространство для хранения, управления и получения образов контейнеров или других пакетов. Существует множество примеров реестров, таких как:
- GitHub—sContainer registry, Реестр контейнеров Azure и DockerHub для образов контейнеров
- Для npm registry пакетов Node.js.
Некоторые GitHub Packages реестры, в том числе Container registryреестры, можно настроить, чтобы пакеты могли быть легко извлечены GitHub Codespaces во время создания пространства кода, не предоставляя учетные данные проверки подлинности.
Чтобы получить доступ к другим реестрам образов контейнеров, можно создать секреты для GitHub хранения сведений о доступе, что позволит GitHub Codespaces получить доступ к образам, хранящимся в этом реестре.
Доступ к пакетам, хранящимся в реестрах с подробными разрешениями
GitHub Packages реестры, поддерживающие детализированные разрешения, включая Container registryте, которые предоставляют самый простой способ GitHub Codespaces использования пакетов. Список GitHub Packages реестров, поддерживающих детализированные права и бесшовный GitHub Codespaces доступ, см. Сведения о разрешениях для пакетов GitHub.
Доступ к пакету, опубликованному в том же репозитории, что и пространство кода
При публикации пакета в том же репозитории, в который запускается пространство кода, вы автоматически сможете получить этот пакет при создании пространства кода. Вам не придется предоставлять дополнительные учетные данные, если только параметр "Наследовать от репозитория " не был выбран при публикации пакета.
Наследование доступа от репозитория, из которого был опубликован пакет
По умолчанию пакет наследует параметр доступа репозитория, из которого он был опубликован. Например, если репозиторий является общедоступным, пакет также является общедоступным. Если репозиторий является частным, пакет также является частным, но доступен из репозитория.
Это поведение определяется параметром Наследовать доступ от репозитория. Наследование доступа от репозитория по умолчанию выбирается при публикации, GitHub Actionsно не при публикации непосредственно в реестре с помощью .personal access token
Если параметр "Наследовать доступ от репозитория" не был выбран при публикации пакета, можно вручную добавить репозиторий в элементы управления доступом опубликованного пакета. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Доступ к пакету, опубликованному в организации, будет запущено в
Если вы хотите, чтобы пакет был доступен для всех пространств кода в организации, рекомендуется опубликовать пакет с внутренней видимостью. Это автоматически сделает пакет видимым для всех пространств кода в организации, если репозиторий, из который не запускается пространство кода, является общедоступным.
Если пространство кода запускается из общедоступный репозиторий ссылки на внутренний или частный пакет, необходимо вручную разрешить общедоступный репозиторий доступ к внутреннему пакету. Это предотвращает случайно утечку внутреннего пакета. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Доступ к частному пакету из подмножества репозиториев в организации
Если вы хотите разрешить подмножество репозиториев организации для доступа к пакету или разрешить доступ к внутреннему или частному пакету из пространства кода, запущенного в общедоступный репозиторий, можно вручную добавить репозитории в параметры доступа пакета. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.
Публикация пакета из пространства кода
Простой доступ из пространства кода в реестр ограничен извлечением пакетов. Если вы хотите опубликовать пакет из пространства кода, необходимо использовать personal access token (classic) ее с областью write:packages .
Мы рекомендуем публиковать пакеты с помощью GitHub Actions. Дополнительные сведения см. в разделе [AUTOTITLE и Публикация образов Docker](/actions/tutorials/publish-packages/publish-nodejs-packages).
Доступ к изображениям, хранящимся в других реестрах
Вы можете определить секреты, чтобы разрешить GitHub Codespaces доступ к реестрам образов контейнеров, отличных от GitHub"s Container registry". Если вы обращаетесь к образу контейнера из реестра, который не поддерживает простой доступ, GitHub Codespaces проверяет наличие трех секретов, определяющих имя сервера, имя пользователя и personal access token реестр. Если эти секреты найдены, GitHub Codespaces вы получите доступ к реестру в вашем пространстве кода.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Секреты можно хранить на уровне пользователя, репозитория или организации, что позволяет безопасно передавать их между различными пространствами кода. При создании набора секретов для частного реестра образов необходимо заменить "<*>" в имени на постоянный идентификатор. Дополнительные сведения см. в разделе [AUTOTITLE и Управление секретами, специфичными для ваших аккаунтов, для GitHub Codespaces](/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization).
Если вы задаете секреты на уровне пользователя или организации, обязательно назначьте эти секреты репозиторию, в котором будет создаваться пространство кода, выбрав политику доступа из раскрывающегося списка.
Извлечение образа Docker в пространство кода
GitHub Codespaces использует Docker, поэтому для извлечения частного образа Docker внутри пространства кода во время выполнения необходимо иметь возможность использовать Docker-in-Docker. Чтобы сделать это возможным, секреты, необходимые для входа в Docker, автоматически добавляются в ~/.docker/config.json файл в пространстве кода. Это происходит после перехватчика жизненного onCreateCommand цикла, но до postCreateCommand, postStartCommandи postAttachCommand. В результате postCreateCommand можно будет использовать Docker-in-Docker для извлечения образа Docker в пространство кода, но onCreateCommand не будет. По этой причине Docker-in-Docker недоступен во время создания предварительной сборки.
После запуска пространства кода вы сможете открыть терминал в пространстве кода и выполнить команду docker pull PRIVATE-IMAGE-URL.
Примеры секретов
Для приватного реестра изображений в 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.
Дополнительные сведения см. в документации по проверке подлинности частного реестра AWS ECR.
Серверы общих реестров образов
Некоторые из серверов общих реестров образов перечислены ниже:
- 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 секреты, на уровне пользователя, репозитория или организации и повторите попытку.