Présentation des dépôts

Artifact Registry vous permet de stocker différents types d'artefacts, de créer plusieurs dépôts dans un seul projet, et d'associer un emplacement régional ou multirégional spécifique à chaque dépôt. Cette page décrit les éléments à prendre en compte pour vous aider à planifier les emplacements et l'organisation de vos dépôts.

Lorsque vous créez vos dépôts, tenez compte à la fois des processus internes pour créer vos artefacts et de l'usage des artefacts par les clients.

Formats de dépôt

Chaque dépôt est associé à un format d'artefact spécifique . Par exemple, un dépôt Docker stocke des images Docker. Vous pouvez créer plusieurs dépôts pour chaque format dans le même Google Cloud projet.

Modes de dépôt

Il existe plusieurs modes de dépôt. Chaque mode a une finalité différente. Vous ne pouvez donc pas modifier le mode de dépôt après avoir créé un dépôt.

Dépôt standard

Les dépôts standards sont des dépôts Artifact Registry classiques pour vos artefacts privés. Vous importez et téléchargez directement des artefacts avec ces dépôts, et vous utilisez Artifact Analysis pour rechercher des failles et d'autres métadonnées.

Pour créer des dépôts standards, suivez les étapes décrites dans Créer des dépôts standards.

Dépôt distant

Les dépôts distants sont des dépôts en lecture seule qui servent de proxy pour stocker des artefacts à partir des sources en amont suivantes :

  • Dépôts Artifact Registry standards.
  • Sources externes telles que Docker Hub, Maven Central, Python Package Index (PyPI), Debian ou CentOS.

La première fois que vous demandez une version d'artefact, le dépôt la télécharge à partir de la source en amont et met en cache une copie. Le dépôt distant fournit la copie mise en cache lorsque la même version est demandée à nouveau.

Les dépôts distants réduisent la latence et améliorent la disponibilité pour les compilations et les déploiements sur Google Cloud. Vous pouvez également utiliser Artifact Analysis pour rechercher des failles et d'autres métadonnées dans les packages mis en cache.

Pour en savoir plus sur les dépôts distants, consultez Présentation des dépôts distants. Pour créer des dépôts distants, suivez les étapes décrites dans Créer des dépôts distants.

Dépôt virtuel

Dépôt en lecture seule qui sert de point d'accès unique pour télécharger, installer ou déployer des artefacts du même format à partir d'un ou de plusieurs dépôts en amont. Un dépôt en amont peut être un dépôt standard, distant ou virtuel.

Les dépôts virtuels simplifient la configuration du client pour les consommateurs de vos artefacts. Vous pouvez également atténuer les attaques par confusion de dépendances en configurant votre stratégie en amont pour donner la priorité aux dépôts contenant vos artefacts privés plutôt qu'aux dépôts distants qui mettent en cache des artefacts publics.

Pour en savoir plus sur les dépôts virtuels, consultez Présentation des dépôts virtuels. Pour créer des dépôts virtuels, suivez les étapes décrites dans Créer des dépôts virtuels.

Exemple d'utilisation de dépôt

Le schéma suivant montre l'une des nombreuses façons d'utiliser des dépôts dans différents modes ensemble. Le schéma montre un workflow dans deux Google Cloud projets. Dans un projet de développement, les développeurs créent une application Java. Dans un projet d'exécution distinct, une autre compilation crée une image de conteneur avec l'application à déployer sur Google Kubernetes Engine.

Dépôts standards, virtuels et distants utilisés dans deux projets.

  1. Dans le projet de développement, une équipe de développement Java utilise Cloud Build pour créer une application Java.

    • La compilation peut demander des dépendances Java publiques à l'aide du dépôt virtuel. Le dépôt virtuel fournit les dépendances à partir du dépôt distant, qui est un proxy de mise en cache pour Maven Central.
    • Cloud Build importe le package dans le dépôt Maven standard du projet de composant.

  2. Dans le projet d'exécution, Cloud Build conteneurise l'application Java.

    La compilation utilise le dépôt virtuel Maven pour télécharger l'application. Le dépôt virtuel fournit le package à partir du dépôt standard du projet de développement. La compilation peut également télécharger des dépendances Java publiques à partir du même dépôt virtuel.

  3. Dans le projet d'exécution, Cloud Build importe l'image de conteneur créée dans un dépôt Docker standard.

  4. GKE extrait les images du dépôt virtuel Docker.

    • Le dépôt Docker standard en amont fournit des images privées, telles que l'application Java conteneurisée.
    • Le dépôt distant en amont fournit les images que GKE demande à Docker Hub.

Dans cet exemple, tous les dépôts, toutes les compilations et tous les clusters GKE se trouvent dans la même région. L'utilisation du même emplacement pour les Google Cloud services présente des avantages décrits dans Emplacement du dépôt.

Emplacement du dépôt

Vous pouvez créer un ou plusieurs dépôts dans une région ou un emplacement multirégional compatible. Un bon emplacement de dépôt permet d'équilibrer les coûts de latence, de disponibilité et de bande passante pour les consommateurs de données. Votre organisation peut également avoir des exigences de conformité spécifiques.

Considérations relatives aux emplacements

Cette section explique pourquoi vous pouvez créer un dépôt dans la même région que d'autres Google Cloud services.

Vous pouvez réduire la latence et les coûts de sortie réseau en créant des dépôts dans la même région que celle où vous exécutez GKE, Cloud Run, Cloud Build et d'autres Google Cloud services qui interagissent avec le dépôt. Aucuns frais ne s'appliquent pour la sortie d' Artifact Registry vers d'autres Google Cloud services dans la même région.

Bien qu'aucuns frais ne s'appliquent pour la sortie d'un emplacement multirégional vers un Google Cloud service dans une région correspondante, cette tarification ne s'applique qu'à un ensemble limité de régions.

  • Pour l'emplacement multirégional us, la sortie vers une région des États-Unis telle que us-central n'est pas facturée, mais la sortie vers une région du Canada ou d'Amérique du Sud est facturée.
  • Pour l'emplacement multirégional asia, la sortie vers des régions d'Asie telles que asia-northeast1 n'est pas facturée, mais la sortie vers des régions d'Australie est facturée.
Vous ne pouvez utiliser le streaming d'images dans GKE et Managed Service for Apache Spark que si vos images de conteneurs sont stockées dans des dépôts Artifact Registry dans la même région que vos charges de travail ou dans un emplacement multirégional correspondant à la région de vos charges de travail. Le streaming d'images peut réduire considérablement le temps d'initialisation des charges de travail lorsque vous utilisez des images de conteneurs plus volumineuses, car les charges de travail peuvent démarrer avant le téléchargement de l'image entière.

Tenez compte de l'emplacement des consommateurs en dehors de Google Cloud. Par exemple, si votre équipe de développeurs en Australie doit télécharger des artefacts depuis Artifact Registry sur ses postes de travail locaux, un dépôt dans une région australienne réduira la latence et entraînera des frais de sortie inférieurs à ceux d'un dépôt situé sur un autre continent.

Limiter les emplacements des dépôts

Si vous devez respecter des réglementations ou des règles qui vous obligent à stocker des données dans des régions spécifiques, vous pouvez inclure une contrainte d'emplacement des ressources dans votre Google Cloud règle d'administration qui n'autorise la création de dépôts que dans les régions conformes. Artifact Registry n'applique la contrainte qu'après l'avoir incluse dans votre règle d'administration. Si vous disposez de dépôts existants dans des emplacements non conformes, vous devez déplacer vous-même vos artefacts vers un dépôt dans un emplacement conforme, puis supprimer le dépôt non conforme.

Règles de nettoyage

Une règle de nettoyage Artifact Registry définit des critères pour supprimer automatiquement les versions d'artefact dont vous n'avez plus besoin ou pour conserver les artefacts que vous souhaitez stocker indéfiniment.

Les règles de nettoyage sont utiles si vous stockez de nombreuses versions de vos artefacts, mais que vous n'avez besoin de conserver que des versions spécifiques que vous mettez en production. Vous pouvez définir des règles de suppression avec des critères de suppression des artefacts et des règles de conservation avec des critères de conservation des artefacts.

Si une version d'artefact correspond aux critères d'une règle de suppression et d'une règle de conservation, Artifact Registry applique la règle de conservation.

Utiliser des règles de suppression

Les règles de suppression suppriment les artefacts correspondant aux critères obligatoires suivants :

  • État du tag : indique si la règle doit rechercher des artefacts tagués ou non tagués. Les artefacts sont tagués lors de l'importation ou de l'extraction d'une image vers ou depuis un dépôt. Pour en savoir plus sur les tags Docker, consultez Concepts liés aux conteneurs.

    • N'importe quel état de tag : ignore l'état du tag et s'applique aux artefacts tagués et non tagués.
    • Tagué : s'applique uniquement aux artefacts tagués.
    • Non tagué : s'applique uniquement aux artefacts non tagués.

    Les formats qui ne sont pas compatibles avec les tags sont traités comme untagged. Les artefacts tagués dans les dépôts pour lesquels les tags immuables sont activés ne peuvent pas être supprimés.

    Pour en savoir plus sur l'état des tags tel qu'il s'applique aux règles de nettoyage, consultez la référence TagState.

Vous pouvez utiliser l'un des paramètres suivants pour configurer votre règle de suppression :

  • Préfixes de tag : liste de préfixes de tag séparés par une virgule. Par exemple, les préfixes test et staging correspondent aux images avec les tags testenv et staging-1.5. tagState doit être défini sur TAGGED pour utiliser les préfixes de tag.
    • Préfixes de version : liste de préfixes de version d'artefact séparés par une virgule. Par exemple v1, v2 correspond aux versions v1.5, v2.0alpha, et v10.2.
  • Préfixes de package : liste de préfixes de nom d'artefact. Vous pouvez saisir plusieurs préfixes en appuyant sur Enter ou , entre les préfixes. Par exemple red, blue crée deux préfixes, red et blue, et correspond aux noms d'artefact red-team, redis, et bluebird.
  • Plus ancien que : durée minimale depuis qu'une version d'artefact a été importée dans le dépôt, spécifiée sous forme de durée. Par exemple, 30d correspond à 30 jours. Vous pouvez spécifier des durées en secondes, minutes, heures ou jours en ajoutant respectivement s, m, h ou d.
  • Plus récent que : durée maximale depuis qu'une version d'artefact a été importée dans le dépôt, spécifiée sous forme de durée. Par exemple, 30d correspond à 30 jours.

Utiliser des règles de conservation

Les règles de conservation conservent les artefacts correspondant aux mêmes conditions que les règles de suppression, ou un nombre défini de versions les plus récentes.

Par exemple, supposons qu'un dépôt contienne les artefacts suivants :

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Si votre règle Conserver les versions les plus récentes est configurée pour conserver trois versions des packages correspondant aux préfixes de package : {release-xyz}, seules release-xyz-v1 et release-xyz-v2 sont conservées.

Les suppressions déclenchées par des règles de suppression sont comptabilisées dans votre quota de demandes de suppression par projet Artifact Registry .

Pour créer et appliquer des règles de nettoyage à votre dépôt, consultez Configurer des règles de nettoyage.

Prise en charge du domaine gcr.io

Artifact Registry est compatible avec l'hébergement d'images sur le domaine gcr.io. Si vous passez de Container Registry à Artifact Registry, vous pouvez configurer des dépôts gcr.io Artifact Registry pour minimiser les modifications apportées à votre automatisation et à vos workflows existants. Ces dépôts fournissent les éléments suivants :

  • Redirection des requêtes vers le domaine gcr.io.
  • Création de dépôts gcr.io lorsque la première image est importée dans un nom d'hôte gcr.io pour assurer la compatibilité avec le comportement de Container Registry.

Pour en savoir plus, consultez Passer aux dépôts avec prise en charge du domaine gcr.io

Structure du projet

Votre hiérarchie de ressources est la façon dont vous organisez vos ressources dans les Google Cloud projets. La structure que vous choisissez dépend de facteurs tels que les exigences de gouvernance des données, les limites de confiance et la structure de l'équipe.

Il existe deux approches générales pour configurer vos dépôts dans les organisations multiprojets.

Centraliser les dépôts

Créez tous les dépôts dans un seul projet, puis accordez l'accès aux principaux d'autres projets au niveau du dépôt. Cette approche peut être plus efficace lorsqu'une seule personne ou équipe gère l'administration des dépôts et l'accès aux dépôts dans votre organisation.

Elle peut également simplifier la configuration des dépôts virtuels, car vous n'avez besoin d'activer et de gérer qu'une seule instance d'Artifact Registry.

Dépôts spécifiques à un projet

Créez des dépôts dans des projets qui stockent et téléchargent des artefacts. Cette approche peut être nécessaire lorsque vous disposez de règles de gouvernance des données ou de limites de confiance qui nécessitent une séparation et un contrôle plus importants des ressources au niveau du projet.

Contrôle des accès

Les dépôts ne sont accessibles qu'avec les autorisations appropriées, sauf si vous configurez le dépôt pour un accès public. Vous pouvez accorder des autorisations au niveau du projet ou du dépôt.

Certains Google Cloud services utilisent des comptes de service par défaut avec des autorisations par défaut pour les dépôts du même Google Cloud projet. Toutefois, ces valeurs par défaut peuvent ne pas convenir à votre processus de développement logiciel ou ne pas être conformes aux exigences de sécurité ou de règles de votre organisation. L'administrateur de votre dépôt doit explicitement accorder l'accès à ces services aux dépôts si :

  • Artifact Registry se trouve dans un projet différent de celui du service qui interagit avec lui.
  • Vous utilisez des rôles IAM personnalisés avec les comptes de service par défaut au lieu du rôle prédéfini.
  • Vous n'utilisez pas le compte de service par défaut pour le Google Cloud service.
  • Vous configurez des dépôts virtuels. Vous devez explicitement accorder au compte de service Artifact Registry l'accès aux dépôts en amont.

Pour les autres principaux qui nécessitent un accès aux dépôts, l'administrateur de votre dépôt doit accorder l'accès. Conformément au principe de sécurité du moindre privilège, accordez les autorisations minimales requises. Exemple :

  • Vous déployez des images de conteneurs dans Artifact Registry vers des clusters GKE dans plusieurs projets différents. Le compte de service des nœuds de ces clusters ne nécessite qu'un accès en lecture aux dépôts.
  • Vous disposez d'un dépôt de développement pour les applications en cours de développement et d'un dépôt de production pour les applications publiées. Les développeurs ont besoin d'un accès en lecture et en écriture au dépôt de développement et d'un accès en lecture seule au dépôt de production.
  • Vous disposez d'un dépôt de démonstration avec des exemples d'applications. Votre équipe commerciale n'a besoin que d'un accès en lecture seule pour télécharger les démonstrations.

Limiter les téléchargements d'artefacts

Vous pouvez limiter les téléchargements d'artefacts à l'aide de règles de téléchargement. Les règles de téléchargement vous permettent d'autoriser ou de refuser les téléchargements d'artefacts à partir de vos dépôts et packages. Vous pouvez également définir des conditions pour que la règle s'applique à des tags ou des versions spécifiques.

Pour en savoir plus sur le fonctionnement des règles de téléchargement, consultez la section Limiter les téléchargements d'artefacts de la présentation Contrôler l'accès et protéger les artefacts.

Chiffrement des données

Par défaut, Google Cloud chiffre automatiquement les données au repos à l'aide de clés de chiffrement gérées par Google et détenues par Google, Google Cloud . Si vous avez des exigences réglementaires ou de conformité spécifiques concernant les clés qui protègent vos données, vous pouvez créer des dépôts chiffrés avec des clés de chiffrement gérées par le client (CMEK).

Artifact Registry est également compatible avec les contraintes liées aux règles d'administration qui peuvent nécessiter l'utilisation de CMEK pour protéger les ressources.

Étiquettes et tags

Les étiquettes permettent d'organiser les ressources spécifiques à un Google Cloud service. Dans Artifact Registry, vous pouvez ajouter des étiquettes aux dépôts afin de les regrouper ou de filtrer les listes de dépôts par étiquette. Par exemple, vous pouvez utiliser des étiquettes pour regrouper les dépôts par étape de développement ou par équipe à des fins d'automatisation ou de facturation. Pour en savoir plus sur la création et l'utilisation d' étiquettes de dépôt, consultez Attribuer des étiquettes aux dépôts.

Vous pouvez également appliquer des tags aux dépôts. Alors que les étiquettes servent principalement à organiser et à filtrer les ressources spécifiques à un service, les tags permettent de contrôler les règles de manière programmatique dans une Google Cloud organisation. Pour en savoir plus, consultez Ajouter des tags aux dépôts.

Étape suivante