О частных реестрах и GitHub Codespaces
Реестр — это безопасное пространство для хранения, управления и получения образов контейнеров или других пакетов. Существует множество примеров реестров, таких как:
- GitHubContainer 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/publishing-packages/publishing-nodejs-packages).
Доступ к изображениям, хранящимся в других реестрах
Вы можете определить секреты, чтобы разрешить GitHub Codespaces получать доступ к реестрам образов контейнеров, отличных от GitHubв 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).
Кроме того, если вы не хотите{ % данных variables.product.prodname_dotcom %} выполнять переключение учетных данных от вашего имени, вы можете предоставить маркер авторизации, извлекаемый через 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 на уровне пользователя, репозитория или организации и повторите попытку.