Note
Ce type de package peut ne pas être disponible pour votre instance, car les administrateurs de site peuvent activer ou désactiver chaque type de package pris en charge. Pour plus d’informations, consultez « Configuration de la prise en charge de l’écosystème de packages pour votre entreprise ».
À propos de la prise en charge de Docker
Lors de l’installation ou de la publication d’une image Docker, le registre Docker ne prend actuellement pas en charge les couches étrangères, telles que les images Windows.
Le moteur Docker v25 n'est pas compatible avec le Docker Registry sur GitHub Enterprise Server. Nous recommandons d'utiliser Container registry à la place. Pour plus d'informations sur la migration, consultez « Migration vers le registre de conteneurs à partir du registre Docker ».
Authentification auprès de GitHub Packages
Note
GitHub Packages prend uniquement en charge l’authentification à l’aide d’un personal access token (classic). Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».
Vous avez besoin d’un jeton d’accès pour publier, installer et supprimer des packages privés, internes et publics.
Vous pouvez utiliser un personal access token (classic) pour vous authentifier sur GitHub Packages ou l’API GitHub Enterprise Server. Quand vous créez un personal access token (classic), vous pouvez l’attribuer à différentes étendues selon vos besoins. Pour plus d’informations sur les étendues liées aux packages pour un personal access token (classic), consultez « À propos des autorisations pour les packages GitHub ».
Pour vous authentifier sur un registre GitHub Packages dans un workflow GitHub Actions, vous pouvez utiliser :
GITHUB_TOKEN
pour publier des packages associés au dépôt du workflow.- un personal access token (classic) avec au moins l’étendue
read:packages
pour installer des packages associés à d’autres dépôts privés (auxquelsGITHUB_TOKEN
ne peut pas accéder).
Pour plus d’informations sur GITHUB_TOKEN
utilisé dans les workflows GitHub Actions, consultez « Authentification par jeton automatique ».
Authentification avec un personal access token
Vous devez utiliser un personal access token (classic) avec les étendues appropriées pour publier et installer des packages dans GitHub Packages. Pour plus d’informations, consultez « Introduction aux packages GitHub ».
Vous pouvez vous authentifier auprès de GitHub Packages avec Docker à l’aide de la commande de connexion docker
.
Pour que vos informations d’identification restent sécurisées, nous vous recommandons d’enregistrer votre personal access token dans un fichier local sur votre ordinateur et d’utiliser l’indicateur --password-stdin
de Docker, qui lit votre jeton à partir d’un fichier local.
Si l'isolation de sous-domaine est activée pour votre instance :
cat ~/TOKEN.txt | docker login docker.HOSTNAME -u USERNAME --password-stdin
Si l’isolation de sous-domaine est désactivée pour votre instance :
cat ~/TOKEN.txt | docker login HOSTNAME -u USERNAME --password-stdin
Pour utiliser cet exemple de commande de connexion, remplacez USERNAME
par votre nom d'utilisateur GitHub Enterprise Server, HOSTNAME
par l'URL pour votre instance GitHub Enterprise Server, et ~/TOKEN.txt
par le chemin du fichier de votre personal access token pour GitHub Enterprise Server.
Pour plus d’informations, consultez « Connexion Docker ».
Publication d’une image
Note
Le registre Docker GitHub Packages Le registre Docker sera remplacé dans une prochaine version GitHub Enterprise Server par le Container registry, qui offre une meilleure prise en charge des conteneurs.
Note
Les noms d’image doivent utiliser uniquement des lettres minuscules.
GitHub Packages prend en charge plusieurs images Docker de niveau supérieur par dépôt. Un dépôt peut contenir un nombre quelconque de balises d’image. Vous pouvez faire face à une dégradation du service lors de la publication ou de l’installation des images Docker supérieures à 10 Go, les couches étant limitées à 5 Go chacune. Pour plus d’informations, consultez « Balise Docker » dans la documentation Docker.
Après avoir publié un package, vous pouvez l’afficher sur GitHub. Pour plus d'informations, consultez « Affichage de packages ».
-
Déterminez le nom et l’ID de votre image Docker avec
docker images
.$ docker images > < > > REPOSITORY TAG IMAGE ID CREATED SIZE > IMAGE_NAME VERSION IMAGE_ID 4 weeks ago 1.11MB
-
À l'aide de l'ID d'image Docker, étiquetez l'image Docker en remplaçant OWNER par le nom du compte personnel ou de l'organisation propriétaire du dépôt, REPOSITORY par le nom du dépôt contenant votre projet, IMAGE_NAME par le nom du package ou de l'image, HOSTNAME par le nom d'hôte de votre instance GitHub Enterprise Server et VERSION par la version du package au moment de la génération.
Si l’isolation de sous-domaine est activée pour votre instance :
docker tag IMAGE_ID docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Si l’isolation de sous-domaine est désactivée pour votre instance :
docker tag IMAGE_ID HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
- Si vous n'avez pas encore créé d'image Docker pour le package, générez l'image en remplaçant OWNER par le nom du compte personnel ou de l'organisation propriétaire du dépôt, REPOSITORY par le nom du dépôt contenant votre projet, IMAGE_NAME par le nom du package ou de l'image, VERSION par la version du package au moment de la génération, HOSTNAME par le nom d'hôte de votre instance GitHub Enterprise Server et PATH par l'image si elle ne se trouve pas dans le répertoire de travail actif.
Si l’isolation de sous-domaine est activée pour votre instance :
docker build -t docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
Si l’isolation de sous-domaine est désactivée pour votre instance :
docker build -t HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
- Publiez l’image sur GitHub Packages.
Si l’isolation de sous-domaine est activée pour votre instance :
docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Si l’isolation de sous-domaine est désactivée pour votre instance :
docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Note
Vous devez pousser votre image avec IMAGE_NAME:VERSION
et non avec IMAGE_NAME:SHA
.
Exemple de publication d’une image Docker
Ces exemples supposent que l’isolation de sous-domaine est activée pour votre instance.
Vous pouvez publier la version 1.0 de l’image monalisa
sur le dépôt octocat/octo-app
à l’aide d’un ID d’image.
$ docker images
> REPOSITORY TAG IMAGE ID CREATED SIZE
> monalisa 1.0 c75bebcdd211 4 weeks ago 1.11MB
# Tag the image with OWNER/REPO/IMAGE_NAME
$ docker tag c75bebcdd211 docker.HOSTNAME/octocat/octo-app/monalisa:1.0
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
Vous pouvez publier une nouvelle image Docker pour la première fois et la nommer monalisa
.
# Build the image with docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
# Assumes Dockerfile resides in the current working directory (.)
$ docker build -t docker.HOSTNAME/octocat/octo-app/monalisa:1.0 .
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
Téléchargement d’une image
Note
Le registre Docker GitHub Packages Le registre Docker sera remplacé dans une prochaine version GitHub Enterprise Server par le Container registry, qui offre une meilleure prise en charge des conteneurs.
Vous pouvez utiliser la commande docker pull
pour installer une image Docker à partir de GitHub Packages en remplaçant OWNER par le nom du compte personnel ou de l'organisation propriétaire du dépôt, REPOSITORY par le nom du dépôt contenant votre projet, IMAGE_NAME par le nom du package ou de l'image, HOSTNAME par le nom d'hôte de votre instance GitHub Enterprise Server et TAG_NAME par l'étiquette pour l'image que vous souhaitez installer.
Si l’isolation de sous-domaine est activée pour votre instance :
docker pull docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
Si l’isolation de sous-domaine est désactivée pour votre instance :
docker pull HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
Note
Vous devez extraire l’image à l’aide de IMAGE_NAME:VERSION
et ne pas utiliser IMAGE_NAME:SHA
.