Artifact Registry est le service recommandé pour gérer les images de conteneurs. Container Registry demeure compatible, mais ne recevra que les correctifs de sécurité critiques. En savoir plus sur la transition vers Artifact Registry.

Présentation de Container Registry

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Google Cloud propose deux services pour stocker et gérer les images de conteneurs:

Artifact Registry (recommandé)
Service de stockage et de gestion d'artefacts dans des dépôts privés, y compris des images de conteneurs, des charts Helm et des packages de langages.

Artifact Registry étend les capacités de Container Registry. En plus de prendre en charge plusieurs formats d'artefact, le service offre des avantages supplémentaires, par exemple:

  • Compatibilité régionale et multirégionale
  • Possibilité de créer plusieurs dépôts distincts dans la même région ou un emplacement multirégional avec un contrôle des accès au niveau du dépôt
  • Rôles Identity and Access Management spécifiques au service, avec une séparation claire entre l'administration du dépôt et les autorisations des utilisateurs du dépôt
Container Registry

Un registre d'images de conteneurs privé compatible avec les formats d'images Docker Image Manifest V2 et OCI Il fournit un sous-ensemble de fonctionnalités d'Artifact Registry.

Bien que Container Registry soit toujours disponible et compatible en tant qu'API Google Enterprise, les nouvelles fonctionnalités ne seront disponibles que dans Artifact Registry. Container Registry ne recevra que les correctifs de sécurité critiques.

Pour obtenir une comparaison entre Container Registry et Artifact Registry, ainsi que des informations sur la transition de Container Registry vers Artifact Registry, consultez la page Effectuer la transition depuis Container Registry.

Utiliser vos images

De nombreuses personnes utilisent Docker Hub comme registre central pour stocker des images Docker publiques. Toutefois, pour contrôler l'accès à vos images, vous devez utiliser un registre privé tel que Artifact Registry ou Container Registry.

Vous pouvez accéder au registre via des points de terminaison HTTPS sécurisés, qui vous permettent de transférer, d'extraire et de gérer des images depuis n'importe quel système, aucune instance de VM ou votre propre matériel.

  • Intégrez le registre aux services CI/CD Google Cloud ou à vos outils CI/CD existants.
  • Sécurisez votre chaîne d'approvisionnement logicielle en conteneurs.
  • Protégez le registre dans un périmètre de sécurité VPC Service Controls.

Registres

Vous pouvez créer jusqu'à quatre hôtes multirégionaux dans chaque projet Google Cloud avec Container Registry. Si vous souhaitez créer des dépôts plus discrets avec des règles d'accès distinctes ou stocker des images dans des régions plutôt que des emplacements multirégionaux, utilisez plutôt Artifact Registry.

Dans Container Registry, les registres sont nommés par l'hôte et l'ID du projet. Pour utiliser des images (push, pull, delete, par exemple), identifiez-les à l'aide du format suivant:

HOSTNAME/PROJECT-ID/IMAGE:TAG

ou

HOSTNAME/PROJECT-ID/IMAGE@IMAGE-DIGEST

où :

  • HOSTNAME est l'emplacement où l'image est stockée :

    • gcr.io héberge les images aux États-Unis, mais cet emplacement peut être amené à changer par la suite.
    • us.gcr.io héberge les images aux États-Unis, dans un bucket de stockage distinct de celui utilisé pour les images hébergées par gcr.io.
    • eu.gcr.io héberge les images dans les États membres de l'Union européenne.
    • asia.gcr.io héberge les images en Asie.

    Ces emplacements multirégionaux hébergent les buckets de stockage Cloud Storage. Lorsque vous transférez une image vers un registre avec un nouveau nom d'hôte, Container Registry crée un bucket de stockage dans l'emplacement multirégional spécifié. Ce bucket forme le stockage sous-jacent du registre. Dans un projet, tous les registres portant le même nom d'hôte partagent un bucket de stockage.

  • PROJECT-ID est l'ID du projet dans Google Cloud Console. Si l'ID du projet contient le signe deux-points (:), consultez la section Projets à l'échelle du domaine ci-dessous.

  • IMAGE correspond au nom de l'image. Ce nom peut être différent du nom local de l'image. Dans Google Cloud Console, les registres du projet sont répertoriés par nom d'image. Chaque dépôt peut contenir plusieurs images du même nom. Par exemple, un dépôt peut contenir différentes versions d'une image appelée "my-image".

  • L'ajout des suffixes :TAG ou @IMAGE-DIGEST vous permet de distinguer une version spécifique de l'image (facultatif). Si vous ne spécifiez pas de tag ni de condensé, Container Registry recherche l'image avec le tag par défaut latest. Consultez la section Versions d'images dans un registre ci-dessous.

Pour l'image my-image du registre gcr.io/PROJECT-ID, utilisez ce format pour transférer ou extraire une image :

gcr.io/PROJECT-ID/my-image:tag1

où PROJECT-ID est l'ID du projet dans Google Cloud Console.

Organiser des images avec des dépôts

Vous pouvez regrouper des images associées dans un dépôt au sein d'un registre. Lorsque vous taguez, transférez ou extrayez une image, vous spécifiez le nom du dépôt sous le projet dans le chemin d'accès de l'image.

Dans Container Registry, les dépôts sont utiles Ils agissent comme des dossiers logiques dans le chemin d'accès de l'image, mais ne reflètent pas la structure réelle du système de fichiers et n'acceptent pas un contrôle d'accès plus précis.

Prenons l'exemple des images suivantes stockées dans l'hôte us.gcr.io dans le projet builds:

us.gcr.io/builds/product1/dev/product1-app:beta-2.0
us.gcr.io/builds/product1/stable/product1:1.0
us.gcr.io/builds/product2/dev/product2:alpha
us.gcr.io/builds/product2/stable/product2:1.0

Si un utilisateur dispose d'un accès en écriture à l'hôte us.gcr.io dans le projet builds, il a accès à n'importe quel chemin d'accès sous us.gcr.io/builds, car toutes les images se trouvent dans le même bucket de stockage. Vous ne pouvez pas limiter l'accès au niveau du dépôt ou de l'image.

Si vous avez besoin d'un contrôle d'accès plus précis, vous pouvez utiliser Artifact Registry à la place. Dans Artifact Registry, les dépôts sont des ressources distinctes. Vous pouvez donc appliquer des stratégies IAM distinctes aux dépôts tels que us-docker.pkg.dev/builds/product1 et us-docker.pkg.dev/builds/product2.

Versions d'images dans un registre

Un registre peut contenir plusieurs images distinctes, ainsi que différentes versions de ces images. Pour identifier une version spécifique de l'image dans un registre, vous pouvez spécifier le tag ou le condensé de l'image.

  • Les tags servent de libellé. Vous pouvez appliquer plusieurs tags à une même image. Par exemple, une image peut comporter le tag v1.5 indiquant un numéro de version et le tag release-candidate indiquant qu'elle est prête pour le test final.
  • Les condensés sont générés automatiquement et sont uniques pour chaque version d'une image. Ils prennent la forme @IMAGE-DIGEST, où IMAGE-DIGEST est la valeur de hachage sha256 du contenu de l'image.

Pour identifier une version spécifique de l'image my-image, procédez comme suit :

  • ajoutez le tag d'image:

    gcr.io/PROJECT-ID/my-image:tag1

  • Ou ajoutez le condensé de l'image :

    gcr.io/PROJECT-ID/my-image@sha256:4d11e24ba8a615cc85a535daa17b47d3c0219f7eeb2b8208896704ad7f88ae2d

où PROJECT-ID est l'ID du projet dans Google Cloud Console. Si l'ID du projet contient le signe deux-points (:), consultez la section Projets à l'échelle du domaine ci-dessous.

Dans l'écran Images de Google Cloud Console, la colonne Tags répertorie les tags de l'image. Cliquez sur la version de l'image pour voir les métadonnées, y compris le Condensé de l'image.

Consultez la section Ajouter des tags à des images pour découvrir comment modifier les tags.

Projets à l'échelle du domaine

Si votre projet est à l'échelle de votre domaine, l'ID de projet comprend le nom du domaine suivi par le signe deux-points (:). En raison de la façon dont Docker traite les deux points, vous devez remplacer ce caractère par une barre oblique lorsque vous spécifiez un condensé d'image dans Container Registry. Identifiez les images dans ces types de projets en utilisant le format suivant :

HOSTNAME/[DOMAIN]/[PROJECT]/IMAGE

Par exemple, le projet portant l'ID example.com:my-project pourrait avoir l'image suivante :

gcr.io/example.com/my-project/image-name

Noms de registre sous forme d'URL

L'URL https://HOSTNAME/PROJECT-ID/IMAGE est l'URL d'une image dans Google Cloud Console. Tout utilisateur authentifié qui est autorisé à accéder à l'hôte du registre peut utiliser des liens pour afficher les images qu'il stocke. Consultez la section Registres pour en savoir plus sur le format du chemin d'accès de l'image.

Par exemple, les URL suivantes redirigent vers des registres publics dans Google Cloud Console:

Formats d'images de conteneurs

Container Registry est compatible avec les formats d'images Docker Image Manifest V2 et OCI. Pour en savoir plus, consultez Formats d'images de conteneurs.

Si vous souhaitez stocker des images et d'autres types d'artefacts de manière centralisée, envisagez d'utiliser Artifact Registry au lieu de Container Registry.

Contrôle des accès

Container Registry stocke ses tags et ses fichiers de couches pour les images de conteneurs dans un bucket Cloud Storage situé dans le même projet que le registre. L'accès au bucket est configuré à l'aide des paramètres de gestion de l'authentification et des accès (IAM) de Cloud Storage.

Un utilisateur ayant accès à un hôte de registre peut accéder à n'importe quelle image du bucket de stockage de l'hôte. Si vous avez besoin d'un contrôle d'accès plus précis, envisagez d'utiliser Artifact Registry. Artifact Registry fournit un contrôle des accès au niveau du dépôt.

Par défaut, les propriétaires et les éditeurs du projet disposent d'autorisations push et pull pour le bucket Container Registry de ce projet. Les lecteurs du projet disposent uniquement de l'autorisation pull.

Pour en savoir plus sur les autorisations Container Registry, consultez la page Configurer le contrôle des accès.

Consultez les avis d'obsolescence de Container Registry pour en savoir plus sur les projets de déplacement des métadonnées d'image de Cloud Storage vers une base de données backend hautes performances.

Authentification

Avant de pouvoir transférer ou extraire des images, vous devez configurer l'authentification. Vous pouvez configurer Docker pour qu'il utilise Google Cloud CLI pour authentifier les requêtes auprès de Container Registry. Container Registry est également compatible avec les méthodes d'authentification avancées utilisant des jetons d'accès ou des fichiers de clés JSON.

Assistant d'identification Docker

Docker doit avoir accès à Container Registry pour pouvoir transférer et récupérer des images. Vous pouvez utiliser l'outil de ligne de commande de l'assistant d'identification Docker pour configurer les identifiants Container Registry à utiliser avec Docker.

L'assistant d'identification récupère vos identifiants Container Registry, soit automatiquement, soit à partir d'un emplacement spécifié à l'aide de son option --token-source, puis les écrit dans le fichier de configuration de Docker. Ainsi, vous pouvez utiliser l'outil de ligne de commande Docker docker pour interagir directement avec Container Registry.

Pour en savoir plus, consultez la section Authentification avancée.

Compte de service Container Registry

Lorsque vous activez l'API Container Registry, Container Registry ajoute un compte de service à votre projet. Ce compte de service dispose de l'ID suivant:

service-[PROJECT_NUMBER]@containerregistry.iam.gserviceaccount.com

Ce compte de service est spécifiquement conçu pour que Container Registry remplisse ses fonctions de service sur votre projet. Google gère ce compte, mais il est spécifique à votre projet.

Si vous supprimez ce compte de service ou si vous modifiez ses autorisations, certaines fonctionnalités de Container Registry ne fonctionneront plus correctement. Vous ne devez pas modifier les rôles, ni supprimer le compte.

Pour en savoir plus sur ce compte de service et ses autorisations, consultez la page Compte de service Container Registry.

Cache d'extraction

Le registre mirror.gcr.io met en cache les images publiques fréquemment demandées à Docker Hub.

L'utilisation d'images mises en cache peut accélérer les extractions à partir de Docker Hub. Votre client recherche toujours une copie mise en cache d'une image Docker Hub avant d'essayer de l'extraire directement de Docker Hub.

Pour en savoir plus, consultez la page Extraire des images Docker Hub mises en cache.

Notifications

Vous pouvez utiliser Pub/Sub pour obtenir des notifications sur les modifications apportées à vos images de conteneurs.

Pour en savoir plus, consultez la page Configurer les notifications Pub/Sub.

Utiliser Container Registry avec Google Cloud

Les instances Compute Engine et les clusters Google Kubernetes Engine peuvent transférer et extraire des images Container Registry selon les champs d'application Cloud Storage définis sur les instances. Consultez la page Utiliser Container Registry avec Google Cloud.

Les images stockées dans Container Registry peuvent être déployées dans l'environnement flexible App Engine.

Intégrations d'outils de livraison continue

Container Registry fonctionne avec les systèmes d'intégration et de livraison continues populaires, y compris Cloud Build et des outils tiers tels que Jenkins.

Container Registry s'intègre parfaitement aux services Google Cloud. Par exemple, Cloud Build peut transférer des images vers des hôtes Container Registry dans le même projet et les extraire par défaut. Les environnements d'exécution tels que Google Kubernetes Engine et Cloud Run peuvent également extraire des images à partir d'hôtes de registre du même projet.

Vous pouvez également utiliser des outils tiers tels que Jenkins pour créer, extraire et transférer vos images. Si vous utilisez un outil tiers, vous devez configurer les autorisations et l'authentification du compte qui interagira avec Container Registry pour le compte de l'outil.

Pour découvrir des exemples d'intégration, consultez les guides techniques de Google Cloud qui incluent Container Registry.