Présentation des dépôts virtuels

Ce document fournit une présentation des dépôts virtuels. Pour savoir comment créer un dépôt virtuel, consultez la section Créer des dépôts virtuels.

Les quotas et limites d'Artifact Registry s'appliquent aux dépôts virtuels.

Fonctionnement des dépôts virtuels

Les dépôts virtuels servent de point d'accès unique pour télécharger, installer ou déployer des artefacts au 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 ou distant Artifact Registry.

Cas d'utilisation et avantages

Configuration client simplifiée

Pour les tâches qui ne nécessitent qu'un accès en lecture aux dépôts, il vous suffit de configurer un seul dépôt Artifact Registry pour accéder aux artefacts stockés dans plusieurs dépôts en amont.

Exemple :

  • Un dépôt virtuel pour les packages Maven peut diffuser des packages Java privés à partir d'un dépôt standard Artifact Registry et des packages Java publics à partir d'un dépôt distant qui met en cache les packages publics de Maven Central.
  • Un dépôt virtuel peut diffuser des packages Python privés à partir de plusieurs dépôts standards en amont appartenant à différentes équipes. Chaque équipe dispose d'un accès en écriture à son dépôt en amont, mais télécharge les packages d'autres équipes à l'aide du dépôt virtuel.
Résolution des dépendances plus sûre

Vous pouvez attribuer une priorité aux dépôts en amont pour mieux contrôler le dépôt choisi par Artifact Registry lorsqu'un artefact demandé se trouve dans plusieurs dépôts en amont.

Certains outils, tels que l'outil Python pip, ne permettent pas de contrôler l'ordre de recherche lorsqu'un mélange de dépôts privés et publics est configuré dans le client. Ce type de configuration est vulnérable à une attaque de confusion de dépendances, dans laquelle une personne importe une nouvelle version d'un package avec du code malveillant dans un dépôt public pour inciter les clients à choisir la mauvaise version.

Vous pouvez utiliser des dépôts distants et virtuels ensemble pour atténuer ce risque :

  1. Créez un dépôt distant en tant que proxy pour le dépôt public.
  2. Créez un dépôt standard pour vos packages privés.
  3. Créez un dépôt virtuel configuré pour donner la priorité à votre dépôt standard si une version du même package existe dans les deux dépôts.
  4. Configurez les gestionnaires de packages et d'autres outils pour qu'ils lisent uniquement à partir du dépôt virtuel, afin que la logique client ne soit pas impliquée dans la sélection du dépôt.

Pour en savoir plus sur les autres bonnes pratiques de gestion des dépendances, consultez la section Gestion des dépendances.

Comment les dépôts virtuels sélectionnent-ils un dépôt en amont ?

Chaque dépôt en amont doit avoir une priorité configurée. La priorité est un entier qui sert de pondération, et non de classement. Cela signifie que les dépôts avec une valeur de priorité plus élevée sont prioritaires par rapport aux dépôts avec des valeurs de priorité plus faibles.

Lorsque vous demandez un artefact qui se trouve dans plusieurs dépôts en amont, Artifact Registry utilise la logique de priorité suivante :

  • Le dépôt avec la valeur la plus élevée est prioritaire. Par exemple, une valeur de 10 est considérée comme plus prioritaire qu'une valeur de 1.
  • Si plusieurs dépôts en amont ont la même priorité, l'artefact peut être diffusé à partir de l'un de ces dépôts.

Lorsque vous configurez directement un client pour qu'il recherche un dépôt virtuel et des dépôts supplémentaires, le client peut toujours télécharger des artefacts à partir de dépôts en dehors d'Artifact Registry.

Par exemple, si vous configurez l'outil Python pip pour qu'il recherche PyPI et un dépôt virtuel, votre package peut être téléchargé directement à partir de PyPI, car pip choisira toujours la dernière version d'un package, quel que soit le dépôt d'où il provient. Si pip est configuré pour rechercher uniquement dans le dépôt virtuel, vous pouvez contrôler la priorité de tous les dépôts en amont, y compris un dépôt distant en amont qui sert de proxy pour PyPI.

Formats de dépôt compatibles

Vous pouvez créer des dépôts virtuels pour les formats de dépôt Artifact Registry suivants :

Packages de langage :

Packages de système d'exploitation :

Si vous débutez avec Artifact Registry, vous pouvez utiliser les guides de démarrage rapide pour découvrir comment configurer des dépôts standards pour ces formats.

Limites

Outre les quotas et limites d'Artifact Registry, les dépôts virtuels présentent les limites suivantes :

  • Étant donné que les dépôts virtuels ne stockent pas de données, ils apparaissent vides lorsque vous exécutez gcloud artifacts docker images list et lorsque vous affichez le dépôt dans la Google Cloud console.
  • Les dépôts en amont Artifact Registry standards doivent se trouver dans la même région ou multirégion que le dépôt virtuel, mais peuvent se trouver dans des projets différents Google Cloud .

  • Les dépôts virtuels Maven n'autorisent pas la définition de la règle de version sur instantané ou version.

  • Les dépôts en amont Apt et Yum doivent être des dépôts standards Artifact Registry.

  • Les dépôts standards Apt et Yum mettent à jour l'index des packages de manière asynchrone après l'importation, l'importation ou la suppression d'un package. Pour les petits dépôts, la régénération de l'index peut prendre plusieurs secondes. Pour les dépôts plus volumineux, la réindexation peut prendre plusieurs minutes, voire plus. Une fois la réindexation terminée, la modification apportée au dépôt est visible pour les clients Apt et Yum.

Autres modes de dépôt

Les autres modes de dépôt sont les suivants :

  • Standard : mode de dépôt par défaut. Vous importez ou publiez des artefacts tels que des packages privés directement dans des dépôts standards. Bien que vous puissiez télécharger directement à partir de dépôts standards individuels, l'accès à des groupes de dépôts avec un dépôt virtuel simplifie la configuration des outils.
  • Distant : dépôt qui sert de proxy pour une source en amont en mettant en cache les packages dans Artifact Registry après leur premier téléchargement à partir de la source en amont. Lorsque vous demandez la même version de package, Artifact Registry fournit la copie mise en cache.
  • Connecteur (version bêta) : dépôt qui sert de proxy pour une source en amont, mais qui ne met pas en cache les artefacts dans Artifact Registry. Au lieu de cela, toutes les requêtes sont adressées à la source en amont. Les dépôts de connecteurs sont utiles si vous avez besoin d'une auditabilité complète de votre source en amont ou si vous disposez de règles empêchant la mise en cache des artefacts.

Étape suivante