{"meta":{"title":"Utilisation du registre de conteneurs","intro":"Vous pouvez stocker et gérer des images Docker et OCI dans le Container registry.","product":"GitHub Packages","breadcrumbs":[{"href":"/fr/packages","title":"GitHub Packages"},{"href":"/fr/packages/working-with-a-github-packages-registry","title":"Utilisation d’un registre GitHub Packages"},{"href":"/fr/packages/working-with-a-github-packages-registry/working-with-the-container-registry","title":"Registre de conteneurs"}],"documentType":"article"},"body":"# Utilisation du registre de conteneurs\n\nVous pouvez stocker et gérer des images Docker et OCI dans le Container registry.\n\n## À propos de Container registry\n\nLe Container registry stocke des images conteneur dans votre organisation ou compte personnel et vous permet d’associer une image à un dépôt. Vous pouvez choisir d’hériter des autorisations d’un dépôt ou de définir des autorisations granulaires indépendamment d’un dépôt. Vous pouvez également accéder aux images conteneur publiques de manière anonyme.\n\n## À propos de la prise en charge de Container registry\n\nActuellement, les Container registry formats d’image conteneur suivants sont pris en charge :\n\n* [Manifeste d’image Docker V2, schéma 2](https://docs.docker.com/registry/spec/manifest-v2-2/)\n* [Spécifications d’Open Container Initiative (OCI)](https://github.com/opencontainers/image-spec)\n\nLors de l’installation ou de la publication d’une image Docker, le Container registry prend en charge les couches étrangères, comme les images Windows.\n\n## Authentification auprès de Container registry\n\n> \\[!NOTE]\n> 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](/fr/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) ».\n\nVous avez besoin d’un jeton d’accès pour publier, installer et supprimer des packages privés, internes et publics.\n\nVous pouvez utiliser un personal access token (classic) pour vous authentifier auprès de GitHub Packages ou de l’API GitHub. 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](/fr/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries).\n\nPour vous authentifier sur un registre GitHub Packages dans un workflow GitHub Actions, vous pouvez utiliser :\n\n* `GITHUB_TOKEN` pour publier des packages associés au dépôt du workflow.\n* Un personal access token (classic) avec au moins `read:packages` la possibilité d'installer des paquets associés à d'autres référentiels privés (`GITHUB_TOKEN` peut être utilisé si le référentiel a un accès en lecture au paquet. Consultez [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility).\n\n### Authentification dans un GitHub Actions flux de travail\n\nCe registre prend en charge les autorisations granulaires. Pour les registres qui prennent en charge les autorisations granulaires, si votre GitHub Actions flux de travail utilise un personal access token pour s’authentifier auprès d’un registre, nous vous recommandons vivement de mettre à jour votre flux de travail pour utiliser le `GITHUB_TOKEN`. Pour obtenir des conseils sur la mise à jour de vos flux de travail qui s’authentifient auprès d’un personal access tokenregistre, consultez [Publication et installation d’un package avec GitHub Actions](/fr/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-personal-access-token).\n\n> \\[!NOTE]\n> La capacité des workflows GitHub Actions de supprimer et de restaurer des packages à l’aide de l’API REST est actuellement en préversion publique publique et susceptible d’être modifiée.\n\nVous pouvez utiliser un `GITHUB_TOKEN` dans un workflow GitHub Actions pour supprimer ou restaurer un package à l’aide de l’API REST, si le jeton dispose de l’autorisation `admin` sur le package. Les référentiels qui publient des packages à l’aide d’un workflow et les référentiels que vous avez explicitement connectés à des packages se voient automatiquement accorder l’autorisation `admin` aux packages dans le référentiel.\n\nPour plus d’informations sur `GITHUB_TOKEN`, consultez [Utiliser GITHUB\\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/tutorials/authenticate-with-github_token#using-the-github_token-in-a-workflow). Pour plus d’informations sur les bonnes pratiques lors de l’utilisation d’un registre dans des actions, consultez [Exécuteurs compromis](/fr/actions/concepts/security/compromised-runners#cross-repository-access).\n\nVous pouvez également choisir d’accorder des autorisations d’accès aux packages indépendamment pourGitHub Codespaces etGitHub Actions. Pour plus d’informations, consultez « [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package) » et « [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package) ».\n\n### Authentification avec un personal access token (classic)\n\n> \\[!NOTE]\n> 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](/fr/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) ».\n\n1. Créez un nouveau personal access token (classic) avec les étendues appropriées pour les tâches que vous souhaitez accomplir. Si votre organisation exige l’authentification unique, vous devez l’activer pour votre nouveau jeton.\n\n   > \\[!NOTE]\n   > Par défaut, lorsque vous sélectionnez la portée `write:packages` pour votre application personal access token (classic) dans l’interface utilisateur, la portée `repo` sera également sélectionnée. L’étendue `repo` offre un accès inutile et étendu, que nous vous recommandons d’éviter d’utiliser pour GitHub Actions les flux de travail en particulier. Pour plus d’informations, consultez « [Exécuteurs compromis](/fr/actions/concepts/security/compromised-runners#cross-repository-access) ». Comme solution de contournement, vous pouvez sélectionner uniquement la portée `write:packages` pour votre personal access token (classic) dans l’interface utilisateur à l’aide de cette URL : `https://github.com/settings/tokens/new?scopes=write:packages`.\n\n   * Sélectionnez l’étendue `read:packages` pour télécharger des images conteneur et lire leurs métadonnées.\n   * Sélectionnez l’étendue `write:packages` pour télécharger et charger des images conteneur et lire et écrire leurs métadonnées.\n   * Sélectionnez la portée `delete:packages` pour supprimer des images de conteneur.\n\n   Pour plus d’informations, consultez « [Gestion de vos jetons d’accès personnels](/fr/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) ».\n\n2. Enregistrez votre personal access token (classic). Nous vous recommandons d’enregistrer votre jeton en tant que variable d’environnement.\n\n   ```shell\n   export CR_PAT=YOUR_TOKEN\n   ```\n\n3. À l’aide de l’interface CLI pour votre type de conteneur, connectez-vous au service à l’adresse Container registry`ghcr.io`.\n\n   ```shell\n   $ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin\n   > Login Succeeded\n   ```\n\n## Envoi (push) d’images de conteneur\n\nCet exemple envoie (push) la dernière version de `IMAGE_NAME`.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nRemplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel vous souhaitez que l’image soit délimitée.\n\nCet exemple transfère la version `2.5` de l’image.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:2.5\n```\n\nLorsque vous publiez un package pour la première fois, la visibilité par défaut est privée. Pour modifier la visibilité ou définir les autorisations d’accès, consultez [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility). Vous pouvez lier un package publié à un référentiel à l’aide de l’interface utilisateur ou de la ligne de commande. Pour plus d’informations, consultez « [Connexion d’un dépôt à un package](/fr/packages/learn-github-packages/connecting-a-repository-to-a-package) ».\n\nLorsque vous poussez une image conteneur à partir de la ligne de commande, l’image n’est pas liée à un dépôt par défaut. C’est le cas même si vous étiquetez l’image avec un espace de noms qui correspond au nom du dépôt, tel que `ghcr.io/octocat/my-repo:latest`.\n\nLe moyen le plus simple de connecter un dépôt à un package de conteneur consiste à publier le package à partir d’un workflow avec `${{secrets.GITHUB_TOKEN}}`, car le dépôt qui contient le workflow est lié automatiquement. Notez que le `GITHUB_TOKEN` n’aura pas l’autorisation de pousser le package si vous avez déjà poussé un package vers le même espace de noms, mais que vous n’avez pas connecté le package au dépôt.\n\nPour connecter un dépôt lors de la publication d’une image à partir de la ligne de commande et pour vous assurer que votre `GITHUB_TOKEN` a les autorisations appropriées lors de l’utilisation d’un workflow GitHub Actions, nous vous recommandons d’ajouter l’étiquette `org.opencontainers.image.source` à votre `Dockerfile`. Pour plus d’informations, consultez « [Étiquetage des images conteneur](#labelling-container-images) » dans cet article et « [Publication et installation d’un package avec GitHub Actions](/fr/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions) ».\n\n## Téléchargement d’images de conteneur\n\n### Extraire par synthèse\n\nPour vous assurer de toujours utiliser la même image, vous pouvez spécifier la version exacte de l’image conteneur que vous souhaitez extraire par la valeur SHA de `digest`.\n\n1. Pour trouver la valeur SHA de synthèse, utilisez `docker inspect` ou `docker pull`, et copiez la valeur SHA après `Digest:`\n\n   ```shell\n   docker inspect ghcr.io/NAMESPACE/IMAGE_NAME\n   ```\n\n   Remplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel l’image est délimitée.\n\n2. Supprimez l’image localement si nécessaire.\n\n   ```shell\n   docker rmi ghcr.io/NAMESPACE/IMAGE_NAME:latest\n   ```\n\n3. Extrayez l’image conteneur avec `@YOUR_SHA_VALUE` après le nom de l’image.\n\n   ```shell\n   docker pull ghcr.io/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs\n   ```\n\n### Extraire par nom\n\n```shell\ndocker pull ghcr.io/NAMESPACE/IMAGE_NAME\n```\n\nRemplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel l’image est délimitée.\n\n### Extraire par nom et version\n\nExemple de CLI Docker montrant une image récupérée par son nom et le tag de version `1.14.1` :\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:1.14.1\n> 5e35bd43cf78: Pull complete\n> 0c48c2209aab: Pull complete\n> fd45dd1aad5a: Pull complete\n> db6eb50c2d36: Pull complete\n> Digest: sha256:ae3b135f133155b3824d8b1f62959ff8a72e9cf9e884d88db7895d8544010d8e\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n> ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n```\n\nRemplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel l’image est délimitée.\n\n### Extraire par nom et dernière version\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> latest: Pulling from NAMESPACE/IMAGE_NAME\n> Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nRemplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel l’image est délimitée.\n\n## Génération d’images conteneur\n\nCet exemple génère l’image `hello_docker` :\n\n```shell\ndocker build -t hello_docker .\n```\n\n## Étiquetage d’images de conteneur\n\n1. Recherchez l’ID de l’image Docker que vous souhaitez étiqueter.\n\n   ```shell\n   $ docker images\n   > REPOSITORY                                            TAG                 IMAGE ID            CREATED             SIZE\n   > ghcr.io/my-org/hello_docker         latest            38f737a91f39        47 hours ago        91.7MB\n   > hello-world                                           latest              fce289e99eb9        16 months ago       1.84kB\n   ```\n\n2. Étiquetez votre image Docker avec l’ID d’image, ainsi le nom et la destination d’hébergement de l’image souhaitée.\n\n   ```shell\n   docker tag 38f737a91f39 ghcr.io/NAMESPACE/NEW_IMAGE_NAME:latest\n   ```\n\nRemplacez `NAMESPACE` par le nom du compte personnel ou de l’organisation auquel vous souhaitez que l’image soit délimitée.\n\n## Étiquetage d'images de conteneur\n\nVous pouvez utiliser des clés d’annotation prédéfinies pour ajouter des métadonnées, notamment une description, une licence et un dépôt source, à votre image conteneur. Les valeurs des clés prises en charge apparaîtront sur la page du package correspondant à l'image.\n\nPour la plupart des images, vous pouvez utiliser des étiquettes Docker pour ajouter les clés d’annotation à une image. Pour plus d’informations, consultez [LABEL](https://docs.docker.com/engine/reference/builder/#label) dans la documentation officielle de Docker et [Clés d’annotation prédéfinies](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys) dans le dépôt `opencontainers/image-spec`.\n\nPour les images multi-arch, vous pouvez ajouter une description à l’image en ajoutant la clé d’annotation appropriée au champ `annotations` dans le manifeste de l’image. Pour plus d’informations, consultez [Ajout d’une description à des images multi-arch](#adding-a-description-to-multi-arch-images).\n\nLes clés d’annotation suivantes sont prises en charge dans le Container registry.\n\n| Clé                                    | Description                                                                                                                                                                                                                                                |\n| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `org.opencontainers.image.source`      | URL du dépôt associé au package. Pour plus d’informations, consultez « [Connexion d’un dépôt à un package](/fr/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line) ». |\n| `org.opencontainers.image.description` | Description en texte uniquement limitée à 512 caractères. Cette description s’affiche sur la page du package, sous le nom du package.                                                                                                                      |\n| `org.opencontainers.image.licenses`    | Un identificateur de licence SPDX tel que « MIT », limité à 256 caractères. La licence apparaît dans la page du package, dans la barre latérale « Détails ». Pour plus d’informations, consultez [Liste des licences SPDX](https://spdx.org/licenses/).    |\n\nPour ajouter une clé en tant qu’étiquette Docker, nous recommandons d’utiliser l’instruction `LABEL` dans votre `Dockerfile`. Par exemple, si vous êtes l’utilisateur `octocat`, que vous possédez `my-repo` et que votre image est distribuée selon les termes de la licence MIT, vous devez ajouter les lignes suivantes à votre `Dockerfile` :\n\n```dockerfile\nLABEL org.opencontainers.image.source=https://github.com/octocat/my-repo\nLABEL org.opencontainers.image.description=\"My container image\"\nLABEL org.opencontainers.image.licenses=MIT\n```\n\n> \\[!NOTE]\n> Si vous publiez un package lié à un dépôt, le package hérite automatiquement des autorisations d’accès du dépôt lié, tandis que les workflows GitHub Actions du dépôt lié accèdent automatiquement au package, sauf si votre organisation a désactivé l’héritage automatique des autorisations d’accès. Pour plus d’informations, consultez « [Configuration du contrôle d’accès et de la visibilité d’un package](/fr/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#about-inheritance-of-access-permissions) ».\n\nVous pouvez également ajouter des étiquettes à une image au moment de la génération avec la commande `docker build`.\n\n```shell\n$ docker build \\\n --label \"org.opencontainers.image.source=https://github.com/octocat/my-repo\" \\\n --label \"org.opencontainers.image.description=My container image\" \\\n --label \"org.opencontainers.image.licenses=MIT\"\n```\n\n### Ajout d’une description à des images multi-arch\n\nUne image multi-arch est une image qui prend en charge plusieurs architectures. Elle fonctionne en référençant une liste d’images, chacune prenant en charge une architecture différente, au sein d’un même manifeste.\n\nLa description qui apparaît dans la page du package d’une image multi-arch s’obtient à partir du champ `annotations` dans le manifeste de l’image. Comme les étiquettes Docker, les annotations offrent un moyen d’associer des métadonnées à une image et prennent en charge les clés d’annotation prédéfinies. Pour plus d’informations, consultez [Annotations](https://github.com/opencontainers/image-spec/blob/main/annotations.md) dans le dépôt `opencontainers/image-spec`.\n\nPour fournir une description d’une image multi-arch, définissez une valeur pour la clé `org.opencontainers.image.description` dans le champ `annotations` du manifeste, comme suit.\n\n```json\n\"annotations\": {\n  \"org.opencontainers.image.description\": \"My multi-arch image\"\n}\n```\n\nPar exemple, l'étape de workflow GitHub Actions suivante génère et publie une image multi-architecture. Le paramètre `outputs` définit la description de l’image.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n- name: Build and push Docker image\n  uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4\n  with:\n    context: .\n    file: ./Dockerfile\n    platforms: ${{ matrix.platforms }}\n    push: true\n    outputs: type=image,name=target,annotation-index.org.opencontainers.image.description=My multi-arch image\n```\n\n## Dépannage\n\n* La Container registry limite de taille est de 10 Go pour chaque couche.\n* Le Container registry délai d’expiration de 10 minutes est limité pour les chargements."}