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 Python stocke des packages Python. 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 une fonction 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 standards 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.
Dépôt distant

Dépôt en lecture seule servant de proxy pour stocker des artefacts à partir de sources externes prédéfinies telles que Docker Hub, Maven Central, l'index de packages Python (PyPI), Debian ou CentOS, ainsi que des sources définies par l'utilisateur pour les formats compatibles. La première fois que vous demandez une version d'artefact, le dépôt la télécharge depuis la source externe et met en cache une copie de celle-ci. Le dépôt diffuse 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 builds 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.

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 clients de vos artefacts. Vous pouvez également limiter les attaques de confusion par dépendance 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 les artefacts publics.

Exemple d'utilisation du dépôt

Le schéma suivant présente l'une des nombreuses façons possibles d'utiliser des dépôts dans différents modes. Le schéma montre un workflow entre deux projets Google 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.

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 du 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 diffuse le package 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 compilée dans un dépôt Docker standard.

  4. GKE extrait des 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, builds et clusters GKE se trouvent dans la même région. L'utilisation du même emplacement pour les services Google Cloud présente les avantages décrits dans la section Emplacement du dépôt.

Compatibilité avec les domaines gcr.io

Artifact Registry permet l'hébergement d'images sur le domaine gcr.io. Si vous effectuez une transition de Container Registry vers Artifact Registry, vous pouvez configurer des dépôts gcr.io dans Artifact Registry afin de minimiser les modifications de votre automatisation et de 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 lors du transfert de la première image vers un nom d'hôte gcr.io pour la compatibilité avec le comportement de Container Registry

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

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

La création d'un dépôt dans la même région que d'autres services Google Cloud présente un certain nombre d'avantages:

  • Réduisez la latence et les coûts de sortie réseau en créant des dépôts dans la région où vous exécutez GKE, Cloud Run, Cloud Build et d'autres services Google Cloud qui interagissent avec le dépôt. La sortie d'Artifact Registry vers d'autres services Google Cloud de la même région est gratuite.

    Bien qu'il n'y ait pas de frais pour la sortie d'un emplacement multirégional vers un service Google Cloud dans une région correspondante, ces tarifs ne s'appliquent 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, tandis que la sortie vers une région du Canada ou de l'Amérique du Sud est facturée.
    • Pour l'emplacement multirégional asia, les sorties vers les régions d'Asie telles que asia-northeast1 ne sont pas facturées, tandis que les sorties vers les régions d'Australie sont facturées.
  • Vous ne pouvez utiliser le streaming d'images dans GKE et Dataproc sans serveur 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 dans laquelle vos charges de travail sont associées. Le streaming d'images peut réduire considérablement le temps d'initialisation de la charge 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 situé dans une région australienne réduit la latence et entraîne des frais de sortie inférieurs à ceux d'un dépôt situé sur un autre continent.

Limiter les emplacements de 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 dans vos règles d'administration Google Cloud une contrainte d'emplacement des ressources 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 vos artefacts vers un dépôt dans un emplacement conforme, puis supprimer le dépôt non conforme.

Structure du projet

La hiérarchie des ressources vous permet d'organiser vos ressources dans les projets Google Cloud. 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 comptes 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 au dépôt au sein de votre organisation. Il peut également simplifier la configuration de dépôts virtuels ou de solutions telles que Software Delivery Shield, 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 requise lorsque vous avez mis en place des règles de gouvernance des données ou des limites de confiance qui nécessitent davantage de séparation et de contrôle 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 l'accès public. Vous pouvez accorder des autorisations au niveau du projet ou du dépôt.

Certains services Google Cloud tels que Cloud Build, Cloud Run et GKE utilisent des comptes de service par défaut avec des autorisations par défaut sur les dépôts du même projet Google Cloud. Toutefois, ces valeurs par défaut peuvent ne pas être adaptées à 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 à ces services l'accès aux dépôts dans les cas suivants:

  • 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 du 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.

L'administrateur du dépôt doit accorder l'accès aux autres comptes principaux nécessitant un accès aux dépôts. 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 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 de dépôt de production. Les développeurs ont besoin d'un accès en lecture et en écriture au dépôt de développement, ainsi que d'un accès en lecture seule au dépôt de production.
  • Vous disposez d'un dépôt de démonstration contenant 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.

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. Si vous avez des exigences réglementaires ou de conformité spécifiques liées aux 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ègle d'administration pouvant nécessiter l'utilisation de clés 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 étiquettes 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 étiquettes pour regrouper des 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 étiquettes de dépôt, consultez la section Ajouter des libellés aux dépôts.

Vous pouvez également appliquer des tags aux dépôts. Alors que les libellés servent principalement à organiser et filtrer les ressources spécifiques aux services, ils permettent un contrôle programmatique des règles dans une organisation Google Cloud. Pour en savoir plus, consultez la section Ajouter des tags aux dépôts.

Étape suivante