À propos des registres privés et GitHub Codespaces
Un registre est un espace sécurisé pour stocker, gérer et récupérer des images conteneur ou d’autres packages. Il existe de nombreux exemples de registres, tels que :
- GitHub' s Container registry, les Azure Container Registry et DockerHub pour les images conteneur
- Pour npm registry les packages Node.js.
Certains GitHub Packages registres, y compris le Container registry, peuvent être configurés pour permettre aux packages d’être extraits en toute transparence GitHub Codespaces pendant la création de l’espace de code, sans avoir à fournir d’informations d’identification d’authentification.
Pour accéder à d’autres registres d’images conteneur, vous pouvez créer des secrets pour GitHub stocker les détails d’accès, ce qui permet GitHub Codespaces d’accéder aux images stockées dans ce registre.
Accès aux packages stockés dans les registres avec des autorisations granulaires
GitHub Packages les registres qui prennent en charge les autorisations granulaires, y compris le Container registry, fournissent le moyen le plus simple de GitHub Codespaces consommer des packages. Pour obtenir la liste des GitHub Packages registres qui prennent en charge les autorisations granulaires et l’accès transparent GitHub Codespaces , consultez À propos des autorisations pour les packages GitHub.
Accès à un package publié dans le même dépôt que le codespace
Si vous publiez un package dans le même dépôt que celui dans lequel le codespace est lancé, vous pouvez automatiquement récupérer (fetch) ce package lors de la création du codespace. Vous n’avez pas à fournir d’informations d’identification supplémentaires, sauf si l’option Hériter de l’accès du dépôt n’a pas été sélectionnée lors de la publication du package.
Hériter de l'accès depuis le dépôt où un package a été publié
Par défaut, le package hérite du paramètre d’accès du dépôt à partir duquel il a été publié. Par exemple, si le dépôt est public, le package l’est également. Si le dépôt est privé, le package l’est également, mais est accessible à partir du dépôt.
L’option Hériter de l’accès du dépôt contrôle ce comportement. Hériter de l’accès du référentiel est sélectionné par défaut lors de la publication via GitHub Actions, mais pas lors de la publication directement dans un registre à l’aide d’un personal access token.
Si l’option Hériter de l’accès du dépôt n’a pas été sélectionnée lors de la publication du package, vous pouvez ajouter manuellement le dépôt aux contrôles d’accès du package publié. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Accès à un package publié dans l’organisation dans laquelle un codespace sera lancé
Si vous souhaitez qu’un package soit accessible à tous les codespaces d’une organisation, nous vous recommandons de publier ce package avec une visibilité interne. Le package est ainsi visible par tous les codespaces de l’organisation, sauf si le dépôt à partir duquel le codespace est lancé est public.
Si le codespace est lancé à partir d'un dépôt public faisant référence à un package interne ou privé, vous devez autoriser manuellement le dépôt public à accéder au package interne. Cela permet d’éviter que le package interne ne soit accidentellement divulgué publiquement. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Accès à un package privé à partir d’un sous-ensemble de dépôts d’une organisation
Si vous souhaitez autoriser un sous-ensemble de dépôts d’une organisation à accéder à un package, ou autoriser l’accès à un package interne ou privé à partir d’un codespace lancé dans un dépôt public, vous pouvez ajouter manuellement des dépôts aux paramètres d’accès du package. Pour plus d’informations, consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».
Publication d’un package à partir d’un codespace
L’accès transparent d’un codespace à un registre se limite à l’extraction de packages. Si vous souhaitez publier un package à partir d’un espace de code, vous devez utiliser une personal access token (classic)write:packages étendue.
Nous vous recommandons de publier des packages via GitHub Actions. Pour plus d’informations, consultez « Publication des images Docker » et « Publication de packages Node.js ».
Accès aux images stockées dans d’autres registres
Vous pouvez définir des secrets pour autoriser GitHub Codespaces l’accès aux registres d’images conteneur autres que GitHubles registres d’images .Container registry Si vous accédez à une image conteneur à partir d’un registre qui ne prend pas en charge l’accès transparent, GitHub Codespaces vérifie la présence de trois secrets, qui définissent le nom du serveur, le nom d’utilisateur et personal access token un registre. Si ces secrets sont trouvés, GitHub Codespaces le Registre sera disponible dans votre espace de code.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Vous pouvez stocker des secrets au niveau de l’utilisateur, du référentiel ou de l’organisation, ce qui vous permet de les partager en toute sécurité entre différents codespaces. Lorsque vous créez un ensemble de secrets pour un registre d’images privé, vous devez remplacer « <*> » dans le nom par un identificateur cohérent. Pour plus d’informations, consultez « Gestion des secrets spécifiques à votre compte pour GitHub Codespaces » et « Gestion des secrets d’environnement de développement pour votre référentiel ou votre organisation ».
Si vous définissez les secrets au niveau de l’utilisateur ou de l’organisation, veillez à attribuer ces secrets au référentiel dans lequel vous créerez le codespace en choisissant une stratégie d’accès dans la liste déroulante.
Extraction d’une image Docker dans votre codespace
GitHub Codespaces utilise Docker. Pour extraire une image Docker privée à l’intérieur de votre espace de code au moment de l’exécution, vous devez être en mesure d’utiliser Docker-in-Docker. Pour rendre cela possible, les secrets requis pour la connexion à Docker sont automatiquement ajoutés au ~/.docker/config.json fichier dans votre codespace. Cela se produit après le hook du cycle de vie onCreateCommand, mais avant postCreateCommand, postStartCommand et postAttachCommand. Par conséquent, postCreateCommand pourra utiliser Docker-in-Docker pour extraire une image Docker dans le codespace, mais onCreateCommand ne pourra pas. Pour cette raison, Docker-in-Docker n’est pas disponible lors de la création du prébuild.
Une fois que le codespace est en cours d’exécution, vous serez en mesure d’ouvrir un terminal dans le codespace et d’exécuter la commande docker pull PRIVATE-IMAGE-URL.
Exemples de secrets
Pour un registre d’images privées dans Azure, vous pouvez créer les secrets suivants :
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Pour plus d’informations sur les registres d’images courants, consultez Serveurs de registre d’images courants. Notez que l’accès à AWS Elastic Container Registry (ERC) est différent.
Une fois les secrets ajoutés, vous devrez peut-être arrêter, puis démarrer le codespace dans lequel vous vous trouvez pour permettre la transmission des nouvelles variables d’environnement au conteneur. Pour plus d’informations, consultez « Utilisation de la palette de commandes Visual Studio Code dans GitHub Espaces de code ».
Accès à AWS Elastic Container Registry
Pour accéder à AWS Elastic Container Registry (ERC), vous pouvez fournir un ID de clé d’accès AWS et une clé secrète, et GitHub récupérer un jeton d’accès pour vous et vous connecter en votre nom.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
Vous devez également vous assurer que vous disposez des autorisations AWS IAM qui conviennent pour procéder à l’échange d’informations d’identification (par exemplests:GetServiceBearerToken) ainsi que l’opération de lecture ERC (AmazonEC2ContainerRegistryFullAccess ou ReadOnlyAccess).
Sinon, si vous ne souhaitez GitHub pas effectuer l’échange d’informations d’identification en votre nom, vous pouvez fournir un jeton d’autorisation récupéré via les API ou l’interface CLI d’AWS.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
La durée de ces jetons étant courte et ceux-ci devant être régulièrement actualisés, nous vous recommandons de fournir un ID de clé d’accès et un secret.
Bien que ces secrets puissent avoir n’importe quel nom, tant que le *_CONTAINER_REGISTRY_SERVER correspond à une URL ERC, nous vous recommandons d’utiliser ECR_CONTAINER_REGISTRY_*, sauf si vous traitez plusieurs registres ERC.
Pour plus d’informations, consultez la documentation sur l’authentification du registre privé ECR AWS.
Serveurs de registre d’images courants
Voici quelques-uns des serveurs de registre d’images courants :
- 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(US),eu.gcr.io(EU),asia.gcr.io(Asie)
Débogage de l’accès au registre d’images privé
Si vous avez des difficultés à extraire une image d’un registre d’images privé, vérifiez que vous pouvez exécuter docker login -u <user> -p <password> <server>, en utilisant les valeurs des secrets définis ci-dessus. Si la connexion échoue, vérifiez que les informations d’identification de connexion sont valides et que vous disposez des autorisations appropriées sur le serveur pour récupérer une image conteneur. Si la connexion réussit, assurez-vous que ces valeurs sont copiées correctement dans les secrets appropriés GitHub Codespaces , soit au niveau de l’utilisateur, du référentiel ou de l’organisation, puis réessayez.