Acerca de los registros privados y GitHub Codespaces
Un registro es un espacio seguro para almacenar, administrar y recuperar imágenes de contenedor u otros paquetes. Hay muchos ejemplos de registros, como los siguientes:
- GitHubes Container registry, el Azure Container Registry y DockerHub para las imágenes de contenedor
- npm registry para paquetes de Node.js.
Algunos GitHub Packages registros, incluidos , Container registryse pueden configurar para permitir que los paquetes se extraen sin problemas GitHub Codespaces durante la creación del espacio de código, sin tener que proporcionar credenciales de autenticación.
Para acceder a otros registros de imágenes de contenedor, puede crear secretos en GitHub para almacenar los detalles de acceso, lo que permitirá GitHub Codespaces acceder a las imágenes almacenadas en ese registro.
Acceso a paquetes almacenados en registros con permisos detallados
GitHub Packages registros que admiten permisos granulares, incluido , Container registryproporcionan la manera más fácil de GitHub Codespaces consumir paquetes. Para obtener la lista de GitHub Packages registros que admiten permisos granulares y acceso sin problemas GitHub Codespaces , consulte Acerca de los permisos para los Paquetes de GitHub.
Acceso a un paquete publicado en el mismo repositorio que el codespace
Si publicas un paquete en el mismo repositorio en el que se está iniciando el codespace, podrás recuperar automáticamente este paquete cuando crees el codespace. No tendrás que proporcionar ninguna credencial más, a menos que la opción Heredar acceso del repositorio se haya desactivado al publicar el paquete.
Heredar el acceso del repositorio desde el cual se ha publicado un paquete
Un paquete hereda de forma predeterminada la configuración de acceso del repositorio desde el que se publicó. Por ejemplo, si el repositorio es público, el paquete también es público. Si el repositorio es privado, el paquete también es privado, pero es accesible desde el repositorio.
Este comportamiento se controla mediante la opción Heredar acceso del repositorio. Heredar el acceso del repositorio se selecciona de forma predeterminada al publicar a través GitHub Actionsde , pero no al publicar directamente en un registro mediante .personal access token
Si la opción Heredar acceso del repositorio no se seleccionó al publicar el paquete, puedes agregar el repositorio manualmente a los controles de acceso del paquete publicado. Para más información, consulta Configurar la visibilidad y el control de accesos de un paquete.
Acceso a un paquete publicado en la organización en la que se lanzará un codespace
Si quieres que todos los codespaces de una organización puedan acceder a un paquete, te recomendamos que lo publiques con visibilidad interna. Esto hará que el paquete sea automáticamente visible para todos los codespaces dentro de la organización, a menos que el repositorio desde el que se lanzó el codespace sea público.
Si el codespace se está lanzando desde un repositorio público que hace referencia un paquete privado o interno, debes permitir manualmente que el repositorio público acceda al paquete interno. Esto impide que el paquete interno se filtre accidentalmente al público. Para más información, consulta Configurar la visibilidad y el control de accesos de un paquete.
Acceso a un paquete privado desde un subconjunto de repositorios de una organización
Si quieres permitir que un subconjunto de los repositorios de una organización acceda a un paquete, o bien permitir el acceso a un paquete privado o interno desde un codespace iniciado en un repositorio público, puedes agregar repositorios manualmente a la configuración de acceso del paquete. Para más información, consulta Configurar la visibilidad y el control de accesos de un paquete.
Publicación de un paquete desde un codespace
El acceso sin problemas desde un codespace a un registro está limitado a la extracción de paquetes. Si desea publicar un paquete desde dentro de un espacio de código, debe usar con personal access token (classic) el write:packages ámbito .
Se recomienda publicar paquetes a través de GitHub Actions. Para más información, consulta Publicación de imágenes de Docker y Publicar paquetes Node.js.
Acceso a las imágenes almacenadas en otros registros
Puede definir secretos para permitir GitHub Codespaces el acceso a registros de imágenes de contenedor distintos de GitHub.Container registry Si accede a una imagen de contenedor desde un registro que no admite el acceso sin problemas, GitHub Codespaces comprueba si hay tres secretos, que definen el nombre del servidor, el nombre de usuario y personal access token un registro. Si se encuentran estos secretos, GitHub Codespaces hará que el Registro esté disponible dentro del espacio de código.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Puedes almacenar los secretos a nivel de repositorio, organización o usuario, lo cual te permite compartirlos de forma segura entre diferentes codespaces. Cuando creas un conjunto de secretos para un registro de imagen privado, necesitas reemplazar el "<*>” del nombre con un identificador consistente. Para más información, consulta Administración de secretos específicos de la cuenta para GitHub Codespaces y Gestión de configuraciones secretas del entorno de desarrollo para el repositorio u organización.
Si estás configurando secretos a nivel de organización o de usuario, asegúrate de asignarlos al repositorio en el que crearás el codespace eligiendo una política de acceso desde la lista desplegable.
Extracción de una imagen Docker en tu espacio de código
GitHub Codespaces usa Docker, por lo que para extraer una imagen privada de Docker dentro del espacio de código en tiempo de ejecución, debe poder usar Docker-in-Docker. Para que esto sea posible, los secretos necesarios para el inicio de sesión en Docker se agregan automáticamente al archivo ~/.docker/config.json en el codespace. Esto sucede después del enlace del ciclo de vida onCreateCommand, pero antes postCreateCommand, postStartCommand y postAttachCommand. Como resultado, postCreateCommand podrá usar Docker-in-Docker para extraer una imagen de Docker al codespace, pero onCreateCommand, no. Por este motivo, Docker-in-Docker no está disponible durante la precompilación.
Después de ejecutar el codespace, podrás abrir un terminal en el codespace y ejecutar el comando docker pull PRIVATE-IMAGE-URL.
Secretos de ejemplo
Para un registro de imágenes privadas en Azure, puede crear los secretos siguientes:
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Para obtener información sobre los registros de imágenes comunes, consulta Servidores comunes de registro de imágenes. Toma en cuenta que el acceso a AWS Elastic Container Registry (ECR) será diferente.
Una vez que hayas agregado los secretos, podría ser que necesites parar y luego iniciar el codespace en el que estás para que las variables de ambiente nuevas pasen en el contenedor. Para más información, consulta Uso de la paleta de comandos de Visual Studio Code en GitHub Codespaces.
Acceder a AWS Elastic Container Registry
Para acceder a AWS Elastic Container Registry (ECR), puede proporcionar un identificador de clave de acceso de AWS y una clave secreta, y GitHub puede recuperar un token de acceso automáticamente e iniciar sesión en su nombre.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
También debe asegurarse de que tiene los permisos IAM de AWS adecuados para realizar el intercambio de credenciales (por ejemplo, sts:GetServiceBearerToken), así como la operación de lectura de ECR (ya sea AmazonEC2ContainerRegistryFullAccess o ReadOnlyAccess).
Como alternativa, si no desea GitHub realizar el intercambio de credenciales en su nombre, puede proporcionar un token de autorización capturado a través de las API o la CLI de AWS.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
Ya que estos tokens tienen una vida corta y necesitan actualizarse constantemente, te recomendamos proporcionar una ID de llave de acceso y secreto.
Aunque estos secretos pueden tener cualquier nombre, siempre que *_CONTAINER_REGISTRY_SERVER sea una dirección URL de ECR, se recomienda usar ECR_CONTAINER_REGISTRY_*, a menos que trabaje con varios registros ECR.
Para más información, consulta la documentación de autenticación de registros privados de ECR de AWS.
Servidores de registro de imagen comunes
Algunos de los servidores de registro de imagen comunes se listan a continuación:
- DockerHub -
https://index.docker.io/v1/ - GitHub Container Registry -
ghcr.io - Azure Container Registry -
<registry name>.azurecr.io - AWS Elastic Container Registry -
<aws_account_id>.dkr.ecr.<region>.amazonaws.com - Google Cloud Container Registry -
gcr.io(EE. UU.),eu.gcr.io(Europa),asia.gcr.io(Asia)
Depurar el acceso al registro de imágenes privadas
Si tiene problemas para extraer una imagen de un registro de imágenes privadas, asegúrese de que puede ejecutar docker login -u <user> -p <password> <server>, con los valores de los secretos definidos anteriormente. Si el inicio de sesión falla, asegúrate de que las credenciales de inicio de sesión sean válidas y de que tienes los permisos adecuados en el servidor para recuperar una imagen de contenedor. Si el inicio de sesión se realiza correctamente, asegúrese de que estos valores se copian correctamente en los secretos correctos GitHub Codespaces , ya sea en el nivel de usuario, repositorio o organización e inténtelo de nuevo.