Virtuelle Repositories – Übersicht

Dieses Dokument bietet einen Überblick über virtuelle Repositories. Eine Anleitung zum Erstellen eines virtuellen Repositories finden Sie unter Virtuelle Repositories erstellen.

Für virtuelle Repositories gelten die Kontingente und Limits von Artifact Registry.

Funktionsweise virtueller Repositories

Virtuelle Repositories dienen als einzelner Zugriffspunkt, um Artefakte im selben Format aus einem oder mehreren Upstream-Repositories herunterzuladen, zu installieren oder bereitzustellen. Ein Upstream-Repository kann ein Artifact Registry-Standard- oder Remote-Repository sein.

Die anderen Repository-Modi sind:

  • Standard: Der Standard-Repository-Modus. Sie laden Artefakte wie private Pakete direkt in Standard-Repositories hoch oder veröffentlichen sie dort. Sie können zwar direkt aus einzelnen Standard-Repositories herunterladen, aber der Zugriff auf Repositoriegruppen mit einem virtuellen Repository vereinfacht die Toolkonfiguration.
  • Remote (nur Sprachpaket-Repositories): Ein Pull-Through-Cache für Artefakte in öffentlichen Repositories wie Maven Central oder PyPI. Es fungiert als Proxy für die öffentlichen Repositories, sodass Sie mehr Kontrolle über Ihre externen Abhängigkeiten haben.

Anwendungsfälle und Vorteile

Einfachere Clientkonfiguration

Für Aufgaben, für die nur Lesezugriff auf Repositories erforderlich ist, müssen Sie nur ein einziges Artifact Registry-Repository konfigurieren, um auf Artefakte zuzugreifen, die in mehreren Upstream-Repositories gespeichert sind.

Beispiel:

  • Ein virtuelles Repository für Maven-Pakete kann private Java-Pakete aus einem Artifact Registry-Standardrepository und öffentliche Java-Pakete aus einem Remote-Repository bereitstellen, das öffentliche Pakete aus Maven Central im Cache speichert.
  • Ein virtuelles Repository kann private Python-Pakete aus mehreren Upstream-Standard-Repositories bereitstellen, die zu verschiedenen Teams gehören. Jedes Team hat Schreibzugriff auf sein Upstream-Repository, lädt aber Pakete von anderen Teams über das virtuelle Repository herunter.
Sicherere Auflösung von Abhängigkeiten

Sie können Upstream-Repositories eine Priorität zuweisen, um besser steuern zu können, welches Repository von Artifact Registry ausgewählt wird, wenn sich ein angefordertes Artefakt in mehr als einem Upstream-Repository befindet.

Einige Tools wie das Python-pip-Tool bieten keine Möglichkeit, die Suchreihenfolge zu steuern, wenn im Client eine Mischung aus privaten und öffentlichen Repositories konfiguriert ist. Diese Art der Konfiguration ist anfällig für einen Dependency Confusion-Angriff, bei dem jemand eine neue Version eines Pakets mit fehlerhaftem Code in ein öffentliches Repository hochlädt, um Kunden dazu zu bringen, die fehlerhafte Version auszuwählen.

Sie können Remote- und virtuelle Repositories zusammen verwenden, um dieses Risiko zu minimieren:

  1. Erstellen Sie ein Remote-Repository als Proxy für das öffentliche Repository.
  2. Erstellen Sie ein Standard-Repository für Ihre privaten Pakete.
  3. Erstellen Sie ein virtuelles Repository, das so konfiguriert ist, dass Ihr Standardrepository priorisiert wird, wenn eine Version desselben Pakets in beiden Repositories vorhanden ist.
  4. Konfigurieren Sie Paketmanager und andere Tools so, dass sie nur aus dem virtuellen Repository lesen, damit die Clientlogik nicht an der Repositoryauswahl beteiligt ist.

Weitere Best Practices für das Abhängigkeitsmanagement finden Sie unter Abhängigkeitsmanagement.

So wählen virtuelle Repositories ein Upstream-Repository aus

Für jedes Upstream-Repository muss eine Priorität konfiguriert sein. Die Priorität ist eine Ganzzahl, die als Gewichtung, nicht als Rang dient. Das bedeutet, dass Repositories mit einem höheren Prioritätswert vor Repositories mit einem niedrigeren Prioritätswert priorisiert werden.

Wenn Sie ein Artefakt anfordern, das sich in mehreren Upstream-Repositories befindet, verwendet Artifact Registry die folgende Priorisierungslogik:

  • Das Repository mit dem höchsten Wert hat Priorität. Beispielsweise hat ein Wert von 10 eine höhere Priorität als ein Wert von 1.
  • Wenn mehrere Upstream-Repositories dieselbe Priorität haben, kann das Artefakt aus einem beliebigen dieser Repositories bereitgestellt werden.

Wenn Sie einen Client direkt so konfigurieren, dass er ein virtuelles Repository und zusätzliche Repositories durchsucht, lädt der Client möglicherweise weiterhin Artefakte aus Repositories außerhalb von Artifact Registry herunter.

Wenn Sie das Python-Tool pip beispielsweise so konfigurieren, dass es PyPI und ein virtuelles Repository durchsucht, wird Ihr Paket möglicherweise direkt von PyPI heruntergeladen, da pip immer die neueste Version eines Pakets auswählt, unabhängig davon, aus welchem Repository es stammt. Wenn pip so konfiguriert ist, dass nur das virtuelle Repository durchsucht wird, können Sie die Priorität aller Upstream-Repositories steuern, einschließlich eines Upstream-Remote-Repositories, das als Proxy für PyPI dient.

Unterstützte Repository-Formate

Sie können virtuelle Repositories für die folgenden Artifact Registry-Repository-Formate erstellen:

Sprachpakete:

Betriebssystempakete:

Wenn Sie Artifact Registry noch nicht kennen, können Sie in den Kurzanleitungen nachlesen, wie Sie Standard-Repositories für diese Formate einrichten.

Beschränkungen

Zusätzlich zu den Kontingenten und Einschränkungen der Artifact Registry gelten für virtuelle Repositories die folgenden Einschränkungen:

  • Standard-Artifact Registry-Upstream-Repositories müssen sich in derselben Region oder Mehrfachregion wie das virtuelle Repository befinden, können aber in verschiedenen Google Cloud Projekten sein.

  • Bei virtuellen Maven-Repositories kann die Versionsrichtlinie nicht auf „Snapshot“ oder „Release“ festgelegt werden.

  • Apt- und Yum-Upstreams müssen Artifact Registry-Standard-Repositories sein.

  • In Apt- und Yum-Standard-Repositories wird der Paketindex asynchron aktualisiert, nachdem ein Paket importiert, hochgeladen oder gelöscht wurde. Bei kleinen Repositories kann das Regenerieren des Index mehrere Sekunden dauern. Bei größeren Repositories kann das Neuindexieren einige Minuten oder länger dauern. Nach Abschluss der Neuindexierung sind die Änderungen am Repository für Apt- und Yum-Clients sichtbar.

Nächste Schritte