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 même projet et d'y associer régional ou multirégional avec 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 artefact spécifique format : Par exemple, un dépôt Docker pour stocker 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.
Dépôt distant

Un dépôt en lecture seule faisant office de proxy pour stocker les artefacts issus de préréglages Sources externes telles que Docker Hub, Maven Central et l'index de packages Python (PyPI), Debian ou CentOS, ainsi que des sources définies par l'utilisateur pour les . La première fois que vous demandez de l'artefact, le dépôt le télécharge depuis la source externe en cache une copie. Le dépôt 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 builds et déploiements conteneurisés 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.

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 standard, distant ou virtuel.

Les dépôts virtuels simplifient la configuration des clients pour les utilisateurs les artefacts. Vous pouvez également atténuer attaques par confusion de dépendance en configurant votre réseau 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 d'un dépôt

Le schéma suivant illustre l'une des nombreuses façons d'utiliser les dépôts dans différents modes ensemble. Le schéma montre un workflow dans 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 un 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 qui est un proxy de mise en cache pour Maven Central.
    • Cloud Build importe le package dans le dépôt Maven standard dans le 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. La un dépôt virtuel diffuse le package à partir du dépôt standard projet de développement. La compilation peut également télécharger des fichiers les dépendances 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 des images que GKE de Docker Hub.

Dans cet exemple, tous les dépôts, builds et clusters GKE sont dans la même région. Utiliser le même emplacement pour les services Google Cloud présente les 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 un bucket régional ou multirégional . Un bon emplacement de dépôt est équilibré la latence, la disponibilité et les coûts de bande passante pour les utilisateurs de données. Votre organisation peut également avoir des exigences de conformité spécifiques.

Considérations relatives aux emplacements

Créer un dépôt dans la même région que les 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 même région que celle où vous exécutez GKE, Cloud Run Cloud Build et d'autres services Google Cloud qui interagissent avec dans le dépôt. Le trafic de sortie depuis Artifact Registry vers d'autres services Google Cloud dans le même dans la même région.

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

    • Pour l'emplacement multirégional us, sortiez vers une région des États-Unis, telle que us-central n'est pas facturé. Les régions du Canada ou d'Amérique du Sud facturés.
    • Pour l'emplacement multirégional asia, sortie vers des régions d'Asie telles que Les asia-northeast1 ne sont pas facturés, mais les sorties vers des régions d'Australie facturés.

  • Vous ne pouvez utiliser le streaming d'images que dans GKE. et Dataproc sans serveur si vos images de conteneurs sont stockées dans Artifact Registry dans la même région que vos charges de travail ou un emplacement multirégional qui correspond à la région dans laquelle se trouvent vos charges de travail. Le streaming d'images peut réduire considérablement le temps d'initialisation de la charge de travail lorsque vous utilisez des conteneurs car les charges de travail peuvent démarrer avant que l'intégralité de l'image ne soit téléchargée.

  • Tenez compte de l'emplacement des clients en dehors de Google Cloud. Pour Par exemple, si votre équipe de développeurs en Australie a besoin de télécharger des artefacts d'Artifact Registry vers leurs postes de travail locaux, un dépôt dans une région australienne réduira la latence ainsi que les frais de sortie qu'un dépôt situé sur un autre continent.

Restreindre les emplacements de dépôt

Si vous devez respecter des réglementations ou des règles qui vous obligent à stocker dans des régions spécifiques, vous pouvez inclure contrainte d'emplacement des ressources dans votre Google Cloud une 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'une fois que vous l'avez incluse dans votre règle d'administration. Si vous avez des dépôts existants dans emplacements non conformes, vous devez déplacer vos artefacts vers un dépôt vers un emplacement conforme, puis supprimez le dépôt non conforme.

Règles de nettoyage

Une règle de nettoyage Artifact Registry définit les critères de suppression automatique 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. Toi peuvent définir des règles de suppression avec des critères de suppression des artefacts. 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 correspondant aux critères obligatoires suivants:

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

    • 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 tag: ne s'applique qu'aux artefacts sans tag.

    Les formats qui ne prennent pas en charge les balises sont traités comme untagged. Artefacts tagués dans des dépôts avec des tags immuables activés.

    Pour plus sur l'état des balises dans le cadre des règles de nettoyage, consultez la Référence TagState.

Vous pouvez définir une règle de suppression de différentes manières:

  • Préfixes de tag: liste de préfixes de tag séparés par une virgule les préfixes de tag. Par exemple, les préfixes test et staging correspondent 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 des versions de l'artefact séparées par une virgule préfixes. 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.
  • 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: il s'agit de la durée maximale écoulée depuis une la version de l'artefact a été importée dans le dépôt, et spécifiée sous forme de durée. Par exemple, 30d correspond à 30 jours.

Conserver les règles

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

Prenons l'exemple d'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 définie pour conserver trois versions des Packages correspondant aux préfixes de package: {release-xyz} uniquement 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 Artifact Registry par projet.

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

Compatibilité avec les domaines gcr.io

Artifact Registry est compatible avec l'hébergement d'images sur le domaine gcr.io. Si vous utilisez de Container Registry à Artifact Registry, vous pouvez configurer gcr.io dépose Artifact Registry pour réduire au maximum les modifications apportées l'automatisation et les workflows. 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 Transition vers des dépôts compatibles avec les domaines gcr.io

Structure du projet

Votre hiérarchie de ressources désigne la façon dont vous organisez vos ressources. de plusieurs 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 organisations multiprojets.

Centraliser les dépôts
Créer tous les dépôts dans un seul projet, puis accorder l'accès à principaux d'autres projets au niveau du dépôt. Cette approche peut sont plus efficaces lorsqu'une seule personne ou équipe gère l'administration et l'accès aux dépôts dans votre organisation.
Cela 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
Dans des projets, créez des dépôts pour stocker et télécharger des artefacts. Ce peut s'avérer nécessaire lorsque vous avez des règles de gouvernance des données des limites de confiance qui nécessitent davantage de séparation et de contrôle au niveau du projet ressources.

Contrôle des accès

Les dépôts ne sont accessibles qu'avec les autorisations appropriées, sauf si vous configurer le dépôt pour l'accès public. Vous pouvez accorder 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 d'un même projet Google Cloud. Toutefois, ces valeurs par défaut peuvent ne pas être adaptées à votre logiciel processus de développement ou de ne pas respecter les exigences de sécurité ou les règles dans votre organisation. L'administrateur de votre dépôt doit accorder explicitement l'accès de ces services aux dépôts si:

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

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. En suivant le principe de sécurité du minimum accordez les autorisations minimales requises. Exemple :

  • Vous déployez des images de conteneurs dans Artifact Registry sur GKE les clusters de plusieurs projets. Le compte de service pour les nœuds de ces clusters ne nécessitent qu'un accès en lecture aux dépôts.
  • Vous disposez d'un référentiel de développement pour les applications en cours de développement. 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 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 uniquement nécessite un accès en lecture seule pour télécharger les démos.

Chiffrement des données

Par défaut, Google Cloud chiffre automatiquement les données lorsqu'elles reste avec Clés appartenant à Google et gérées par Google. Si vous avez des exigences de conformité ou de réglementation spécifiques liées aux 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 liées aux règles d'administration. pouvant nécessiter des CMEK pour protéger les ressources.

Étiquettes et tags

Les étiquettes permettent d'organiser les ressources spécifiques à Google Cloud Google Cloud. Dans Artifact Registry, vous pouvez ajouter des étiquettes aux dépôts pour que vous pouvez les regrouper ou filtrer les listes de dépôts par étiquette. 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 des étiquettes de dépôt, consultez la section Étiqueter des dépôts.

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

Étape suivante