Présentation des 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 du dépôt après l'avoir créé.

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 des artefacts directement avec ces dépôts, et vous utilisez Artifact Analysis pour rechercher les failles et d'autres métadonnées.

Pour créer des dépôts standards, suivez la procédure décrite 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 proxys pour stocker les artefacts provenant 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 à 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 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 qu'elle donne la priorité aux dépôts contenant vos artefacts privés plutôt qu'aux dépôts distants qui mettent en cache les 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 du dépôt

Le diagramme suivant montre l'une des nombreuses façons possibles d'utiliser des dépôts dans différents modes ensemble. 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, une autre compilation crée une image de conteneur avec l'application à déployer sur Google Kubernetes Engine.

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

   • La compilation peut demander des dépendances Java publiques à l'aide du dépôt virtuel. Le dépôt virtuel sert les dépendances 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, toutes les compilations et tous les clusters GKE se trouvent dans la même région. L'utilisation du même emplacement pour les services Google Cloud présente des avantages décrits dans Emplacement du dépôt.

Zone du dépôt

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 s'appliquent pour le trafic de sortie d'Artifact Registry vers d'autres services Google Cloud dans la même région.

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

• Pour la région multirégionale us, la sortie vers une région aux États-Unis, comme us-central, n'est pas facturée, tandis que la sortie vers une région au Canada ou en Amérique du Sud l'est.
• Pour la région multirégionale 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.

Tenez compte de la localisation 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 postes de travail locaux, un dépôt situé dans une région australienne réduira la latence et entraînera des frais de sortie moins élevés qu'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'une fois que vous l'avez incluse dans votre règle d'administration. Si vous avez des 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'artefacts 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 les versions spécifiques que vous déployez 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.

Supprimer des règles

Les règles de suppression suppriment les artefacts qui répondent aux critères obligatoires suivants :

• État du tag : indique si la règle doit rechercher les artefacts tagués ou non tagués. Les artefacts sont tagués lorsque vous transférez ou extrayez 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é : ne s'applique qu'aux artefacts tagués.
  • Non tagué : ne s'applique qu'aux artefacts non tagués.

  Les formats qui ne sont pas compatibles avec les tags sont traités comme des 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 en ce qui concerne les règles de nettoyage, consultez la documentation de référence sur TagState.

Voici quelques 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 comportant les tags testenv et staging-1.5. tagState doit être défini sur TAGGED pour utiliser les préfixes de tags.
  • Préfixes de version : liste de préfixes de version d'artefact séparés par une virgule. Par exemple, v1, v2 correspondrait 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.
• Plus ancien que : durée minimale écoulée depuis la mise en ligne d'une version d'artefact dans le dépôt. 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 qu'une version d'artefact a été importée dans le dépôt. Par exemple, 30d correspond à 30 jours.

Conserver les règles

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, prenons un dépôt contenant 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 permet d'héberger des images sur le domaine gcr.io. Si vous passez de Container Registry à Artifact Registry, vous pouvez configurer des dépôts gcr.io dans 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 Passer aux dépôts avec prise en charge du domaine gcr.io.

Structure du projet

Votre hiérarchie de ressources vous permet d'organiser vos ressources dans vos projets Google Cloud . La structure que vous choisissez dépend de facteurs tels que les exigences en matière 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 et l'accès aux dépôts dans 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 à 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 services Google Cloud utilisent des comptes de service par défaut avec des autorisations par défaut pour les dépôts du même projet Google Cloud . 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 les 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 service Google Cloud.
• 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 ont besoin d'accéder aux dépôts, votre administrateur de dépôt doit leur accorder l'accès. En suivant le principe de sécurité du moindre privilège, accordez le minimum d'autorisations requises. Exemple :

• Vous déployez des images de conteneurs dans Artifact Registry sur des clusters GKE dans plusieurs projets différents. Le compte de service pour les nœuds de ces clusters n'a besoin que d'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émos.

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 le téléchargement 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 Restreindre 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 avec des 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 l'utilisation de CMEK pour protéger les ressources.

Étiquettes et tags

Les libellés permettent d'organiser les ressources spécifiques à un service Google Cloud. Dans Artifact Registry, vous pouvez ajouter des libellés aux dépôts pour les regrouper ou filtrer les listes de dépôts par libellé. Par exemple, vous pouvez utiliser des libellés 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 des libellés de dépôt, consultez Libellés de dépôt.

Vous pouvez également appliquer des tags aux dépôts. Alors que les libellés 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 organisation Google Cloud . Pour en savoir plus, consultez Taguer des dépôts.

Étape suivante

• Créer des dépôts standards
• En savoir plus sur les dépôts distants
• En savoir plus sur les dépôts virtuels
• Créer des dépôts distants
• Créer des dépôts virtuels