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

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

  • Standard: mode de dépôt par défaut. Vous mettez en ligne 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 de l'outil.
  • À distance (dépôts de packages de langage uniquement): cache pull through pour les artefacts dans des dépôts publics tels que Maven Central ou PyPI. Il agit comme un 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

Simplifier la configuration du client

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 à 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 des paquets 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épendance, où un pirate informatique importe une nouvelle version d'un paquet contenant du code incorrect 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 paquet existe dans les deux dépôts.
  4. Configurez les gestionnaires de paquets et d'autres outils pour qu'ils ne lisent que le 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 ?

Une priorité doit être configurée pour chaque dépôt en amont. La priorité est un 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 sur ceux ayant des valeurs de priorité inférieures.

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 traitée comme une priorité plus élevée qu'une 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.

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 ne rechercher que 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ôts compatibles

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

Packages de langues:

Packages de l'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 des 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 dans la même zone multirégionale que le dépôt virtuel, mais peuvent se trouver dans différents Google Cloud projets.

  • Les dépôts virtuels Maven ne permettent pas de définir la stratégie de version sur "snapshot" ou "release".

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

  • Les dépôts standards Apt et Yum mettent à jour l'index de paquets de manière asynchrone après l'importation, l'importation ou la suppression d'un paquet. 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 l'indexation terminée, les modifications apportées au dépôt sont visibles par les clients Apt et Yum.

Étape suivante