Présentation des dépôts virtuels

Ce document présente les dépôts virtuels. Pour savoir comment créer un dépôt virtuel, consultez 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.

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ôts de packages linguistiques uniquement) : cache pull-through pour les artefacts dans les dépôts publics tels que Maven Central ou PyPI. Il sert de proxy pour les dépôts publics afin que vous ayez plus de contrôle sur vos dépendances externes.

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 servir 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 servir des packages Python privés provenant 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 aux attaques 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 le 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 Gestion des dépendances.

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

Une priorité doit être configurée pour chaque dépôt en amont. La priorité est un nombre entier qui sert de pondération, et non de classement. Autrement dit, les dépôts ayant une valeur de priorité plus élevée sont prioritaires par rapport à ceux ayant une valeur de priorité plus faible.

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

  • Le dépôt ayant 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, 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 rechercher PyPI et un dépôt virtuel, votre package peut être téléchargé directement depuis 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 n'effectuer des recherches que dans le dépôt virtuel, vous pouvez ensuite 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 :

Modules linguistiques :

Packages de système d'exploitation :

Si vous débutez avec Artifact Registry, vous pouvez utiliser les guides de démarrage rapide pour apprendre à 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 :

  • Les dépôts en amont Artifact Registry standards doivent se trouver dans la même région ou la même multirégion que le dépôt virtuel, mais peuvent se trouver dans différents projets Google Cloud .

  • Les dépôts virtuels Maven ne permettent pas de définir 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.

Étapes suivantes