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:
- El Container registry de GitHub, Azure Container Registry y DockerHub para imágenes de contenedor
- El npm registry para paquetes de Node.js
Algunos registros de GitHub Packages, incluido el Container registry, se pueden configurar para permitir que puedan extraerse paquetes a GitHub Codespaces sin problemas durante la creación del codespace, sin tener que proporcionar credenciales de autenticación.
Para acceder a otros registros de imagen de contenedor, puedes crear secretos en GitHub y almacenar en ellos los detalles de acceso, lo que permitirá a GitHub Codespaces acceder a las imágenes almacenadas en dicho registro.
Acceso a paquetes almacenados en registros con permisos detallados
Los registros de GitHub Packages que admiten permisos detallados, incluido el Container registry, proporcionan la forma más sencilla de que GitHub Codespaces pueda usar paquetes. Para obtener una lista de los registros de GitHub Packages que admiten permisos detallados y un acceso sin problemas a GitHub Codespaces, consulta "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. La opción Heredar acceso del repositorio está seleccionada de forma predeterminada al publicar desde GitHub Actions, pero no cuando se publica directamente en un registro con un 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 obtener más información, vea «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 obtener más información, vea «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 obtener más información, vea «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 quieres publicar un paquete desde dentro de un codespace, tendrás que usar un personal access token (classic) con el ámbito write:packages.
Te recomendamos publicar paquetes a través de GitHub Actions. Para obtener más información, vea «Publicación de imágenes de Docker» y «Publicar paquetes Node.js».
Acceso a las imágenes almacenadas en otros registros
Puedes definir secretos para permitir que GitHub Codespaces acceda a otros registros de imágenes de contenedor aparte del Container registry de GitHub. Si estás accediendo a una imagen de contenedor desde un registro que no admite el acceso sin problemas, GitHub Codespaces comprueba la presencia de los tres secretos que definen respectivamente el nombre del servidor, el nombre de usuario y el personal access token de un registro. Si se encuentran estos secretos, GitHub Codespaces hará que el registro esté disponible dentro de tu codespace.
<*>_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 obtener más información, vea «Administración de secretos específicos de la cuenta para GitHub Codespaces» y «Administración de secretos del entorno de desarrollo para el repositorio o la 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 al codespace
GitHub Codespaces usa Docker, por lo que para extraer una imagen privada de Docker dentro del codespace en runtime, debes 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 creación previa de la compilació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 los registros de imagen privados en Azure, podrías crear los siguientes secretos:
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, vea "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 obtener más información, vea «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), puedes proporcionar una ID de llave de acceso de AWS y una llave secreta y GitHub podrá recuperar un token de acceso para ti e iniciar sesión en tu 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 quieres que GitHub realice el cambio de credenciales en tu nombre, puedes proporcionar un token de autorización que se haya recuperado mediante las API de AWS o la CLI.
*_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, vea 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/ - Registro de contenedores de GitHub -
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 es exitoso, asegúrate de que estos valores se copien adecuadamente en los secretos de GitHub Codespaces correctos, ya sea a nivel de usuario, repositorio u organización, e inténtalo de nuevo.