Présentation des dépôts virtuels

Les dépôts virtuels Artifact Registry vous permettent d'accéder à des artefacts du même format dans plusieurs dépôts en amont via un seul point de terminaison. Ils peuvent simplifier la configuration du client, permettre une résolution plus sûre des dépendances et aider à prévenir les attaques par confusion de dépendances.

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 du 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 plus sûre des dépendances

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 par confusion de dépendances, où 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 du 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 dont la valeur de priorité numérique est plus élevée sont prioritaires par rapport à ceux dont la valeur de priorité est plus faible.

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 ayant la valeur la plus élevée est prioritaire. Par exemple, la valeur de 10 est considérée comme plus prioritaire que la valeur de 1.
  • Si plusieurs dépôts en amont ont la même priorité, l'artefact peut être diffusé à partir de n'importe lequel de ces dépôts.

Nous vous recommandons également d'inclure la version de l'artefact dans votre requête. De cette façon, le client renvoie le dépôt en amont le plus prioritaire qui contient la version de l'artefact demandée. Si vous ne spécifiez pas la version de l'artefact, le client peut renvoyer la dernière version de l'artefact, quelle que soit la priorité du dépôt.

Lorsque vous configurez directement un client pour qu'il recherche un dépôt virtuel et des dépôts supplémentaires, il 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 alors 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 d'OS :

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

En plus des 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 le même emplacement multirégional que le dépôt virtuel, mais peuvent se trouver dans des Google Cloud projets différents.

  • Les dépôts virtuels Maven n'autorisent pas la définition de la stratégie de version sur "snapshot" ou "release".

  • 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 (preview) : 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 stratégies empêchant la mise en cache des artefacts.

Étape suivante