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 une région ou un emplacement 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 projet Google Cloud .

Modes de dépôt

Il existe plusieurs modes de dépôt. Chaque mode a un objectif différent. 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 standards pour vos artefacts privés. Vous importez et téléchargez des artefacts directement avec ces dépôts, et utilisez Artifact Analysis pour rechercher des failles et d'autres métadonnées.

Pour créer des dépôts standards, suivez la procédure décrite dans la section 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 proxys pour stocker les artefacts des sources en amont suivantes:

  • Dépôts Artifact Registry standards.
  • Sources externes telles que Docker Hub, Maven Central, l'indice des paquets Python (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 en met une copie en cache. Le dépôt distant fournit la copie mise en cache lorsque la même version est à nouveau demandée.

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

Pour en savoir plus sur les dépôts distants, consultez la section Présentation des dépôts distants. Pour créer des dépôts distants, suivez la procédure décrite 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 par rapport aux dépôts distants qui mettent en cache des artefacts publics.

Pour en savoir plus sur les dépôts virtuels, consultez la section Présentation des dépôts virtuels. Pour créer des dépôts virtuels, suivez la procédure décrite dans la section Créer des dépôts virtuels.

Exemple d'utilisation d'un dépôt

Le schéma suivant montre l'une des nombreuses façons d'utiliser des dépôts dans différents modes. Le schéma illustre un workflow dans deux projetsGoogle Cloud . Dans un projet de développement, les développeurs créent une application Java. Dans un projet d'exécution distinct, un autre build 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 diffuse 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 dans le 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, les builds et les clusters GKE se trouvent dans la même région. Utiliser le même emplacement pour les services Google Cloud présente des avantages décrits dans la section Emplacement du dépôt.

Zone 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 services Google Cloud .

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 services Google Cloud qui interagissent avec le dépôt. Aucuns frais ne sont appliqués pour la sortie de l'Artifact Registry vers d'autres services Google Cloud de la même région.

Bien qu'il n'y ait pas de frais de sortie d'un service multirégional vers un serviceGoogle Cloud dans une région correspondante, cette tarification ne s'applique qu'à un nombre limité de régions.

  • Pour la zone multirégionale us, les frais de sortie vers une région des États-Unis, comme us-central, ne sont pas facturés. En revanche, ils le sont pour toute région du Canada ou de l'Amérique du Sud.
  • Pour l'emplacement multirégional asia, les sorties vers les régions d'Asie telles que asia-northeast1 ne sont pas facturées, mais les sorties vers les régions d'Australie le sont.
Vous ne pouvez utiliser le streaming d'images que dans GKE et Dataproc Serverless si vos images de conteneur sont stockées dans des dépôts Artifact Registry dans la même région que vos charges de travail ou dans une région multirégionale correspondant à celle 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 conteneur plus volumineuses, car les charges de travail peuvent démarrer avant que l'image entière ne soit téléchargée.

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 vers ses stations de travail locales, 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 règle d'administration Google Cloudqui 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 situé 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'artefacts dont vous n'avez plus besoin ou 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 ne devez conserver que des versions spécifiques que vous publiez 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 à la fois aux critères d'une règle de suppression et d'une règle de conservation, Artifact Registry applique la règle de conservation.

Supprimer des règles

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. Les artefacts sont tagués lorsque vous transférez une image vers ou depuis un dépôt. Pour en savoir plus sur les tags Docker, consultez la section Concepts de conteneur.

    • N'importe quel état de balise: ignore l'état de la balise et s'applique aux artefacts tagués et non tagués.
    • Tagué: ne s'applique qu'aux artefacts tagués.
    • Sans balise: ne s'applique qu'aux artefacts sans balise.

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

    Pour en savoir plus sur l'état des balises en ce qui concerne les règles de nettoyage, consultez la documentation de référence sur TagState.

Voici des méthodes facultatives pour définir votre règle de suppression:

  • Préfixes de balise: liste de préfixes de balise séparés par une virgule. Par exemple, les préfixes test et staging correspondent aux images avec les balises testenv et staging-1.5. tagState doit être défini sur TAGGED pour utiliser des préfixes de balise.
    • Préfixes de version: - est une liste de préfixes de version d'artefact séparés par une virgule. Par exemple, v1 et v2 correspondent aux versions v1.5, v2.0alpha et v10.2.
  • Préfixes de package: liste des 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éerait deux préfixes, red et blue, et correspondrait aux noms d'artefacts red-team, redis et bluebird.
  • Ancienne que: durée minimale écoulée depuis l'importation d'une version d'artefact dans le dépôt, spécifiée sous la forme d'une 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 écoulée depuis l'importation d'une version d'artefact dans le dépôt, spécifiée sous la forme d'une durée. Par exemple, 30d correspond à 30 jours.

Règles de conservation

Les règles de conservation conservent les artefacts qui répondent 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 la stratégie Conserver les versions les plus récentes est définie pour conserver trois versions de packages correspondant aux préfixes de package: {release-xyz}, seuls release-xyz-v1 et release-xyz-v2 sont conservés.

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

Pour créer et appliquer des règles de nettoyage à votre dépôt, consultez la section 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:

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

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

Structure du projet

Votre hiérarchie de ressources correspond à 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 des 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 une seule équipe gère l'administration et l'accès aux dépôts dans l'ensemble de votre organisation.
Il 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 au 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 respecter les exigences de sécurité ou de conformité de votre organisation. L'administrateur de votre dépôt doit explicitement accorder à ces services l'accès 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 accorder explicitement au compte de service Artifact Registry l'accès aux dépôts en amont.

Pour les autres principaux qui ont besoin d'accéder aux dépôts, votre administrateur de 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 conteneur dans Artifact Registry sur 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.

Restreindre les téléchargements d'artefacts

Vous pouvez restreindre 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 balises ou 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 chiffrementdétenues et gérées par Google . 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 à l'aide de clés de chiffrement gérées par le client (CMEK).

Artifact Registry est également compatible avec les contraintes de règles d'administration qui peuvent exiger CMEK pour protéger les ressources.

Étiquettes et tags

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

Vous pouvez également appliquer des tags aux dépôts. Les libellés servent principalement à organiser et à filtrer les ressources spécifiques au service, tandis que les tags permettent de contrôler de manière programmatique les règles au sein d'une Google Cloud organisation. Pour en savoir plus, consultez la section Baliser des dépôts.

Étape suivante