Virtuelle Repositories – Übersicht

Mit virtuellen Repositories in Artifact Registry können Sie über einen einzigen Endpunkt auf Artefakte desselben Formats in mehreren Upstream-Repositories zugreifen. Virtuelle Repositories können die Clientkonfiguration vereinfachen, eine sicherere Abhängigkeitsauflösung ermöglichen und Dependency-Confusion-Angriffe verhindern.

Eine Anleitung zum Erstellen eines virtuellen Repositorys 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 zum Herunterladen, Installieren oder Bereitstellen von Artefakten im selben Format aus einem oder mehreren Upstream-Repositories. Ein Upstream-Repository kann ein Standard- oder Remote-Repository von Artifact Registry sein.

Anwendungsfälle und Vorteile

Einfachere Clientkonfiguration

Für Aufgaben, die nur Lesezugriff auf Repositories erfordern, 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 Standard-Repository von Artifact Registry und öffentliche Java-Pakete aus einem Remote-Repository bereitstellen, in dem öffentliche Pakete aus Maven Central im Cache gespeichert werden.
  • Ein virtuelles Repository kann private Python-Pakete aus mehreren Upstream-Standard-Repositories bereitstellen, die verschiedenen Teams gehören. Jedes Team hat Schreibzugriff auf sein Upstream-Repository, lädt Pakete von anderen Teams aber über das virtuelle Repository herunter.
Sicherere Abhängigkeitsauflösung

Sie können Upstream-Repositories eine Priorität zuweisen, um besser zu steuern, welches Repository von Artifact Registry ausgewählt wird, wenn ein angefordertes Artefakt in mehreren Upstream-Repositories vorhanden ist.

Einige Tools wie das Python-Tool pip 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. Dabei lädt jemand eine neue Version eines Pakets mit schädlichem Code in ein öffentliches Repository hoch, um Clients dazu zu bringen, die schädliche 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 Standard-Repository 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 in die Repository-Auswahl einbezogen wird.

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

Auswahl eines Upstream-Repositorys durch virtuelle Repositories

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

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

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

Wir empfehlen außerdem, die Artefaktversion in Ihre Anfrage aufzunehmen. Auf diese Weise gibt der Client das Upstream-Repository mit der höchsten Priorität zurück, das die angeforderte Artefaktversion enthält. Wenn Sie die Artefaktversion nicht angeben, gibt der Client möglicherweise die neueste Version des Artefakts zurück, unabhängig von der Repository-Priorität.

Wenn Sie einen Client direkt so konfigurieren, dass er ein virtuelles Repository und zusätzliche Repositories durchsucht, kann der Client Artefakte trotzdem aus Repositories außerhalb von Artifact Registry herunterladen.Wenn Sie beispielsweise das Python-Tool pip 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-Repositorys, 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 Schnellstarts erfahren, wie Sie Standard-Repositories für diese Formate einrichten.

Beschränkungen

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

  • Da in virtuellen Repositories keine Daten gespeichert werden, sind sie leer, wenn Sie gcloud artifacts docker images list ausführen und wenn Sie das Repository in der Google Cloud Konsole ansehen.
  • Standard-Upstream-Repositories von Artifact Registry müssen sich in derselben Region oder Multi-Region wie das virtuelle Repository befinden, können aber in anderen Google Cloud Projekten sein.

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

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

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

Andere Repository-Modi

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 Repository-Gruppen mit einem virtuellen Repository vereinfacht die Toolkonfiguration.
  • Remote: Ein Repository, das als Proxy für eine Upstream- Quelle dient, indem Pakete in Artifact Registry im Cache gespeichert werden, nachdem sie zum ersten Mal aus der Upstream-Quelle heruntergeladen wurden. Wenn Sie dieselbe Paketversion das nächste Mal anfordern, stellt Artifact Registry die im Cache gespeicherte Kopie bereit.
  • Connector (Vorschau): Ein Repository, das als Proxy für eine Upstream-Quelle dient, aber keine Artefakte in Artifact Registry im Cache speichert. Stattdessen werden alle Anfragen an die Upstream-Quelle gesendet. Connector-Repositories sind nützlich, wenn Sie eine vollständige Auditierbarkeit Ihrer Upstream-Quelle benötigen oder Richtlinien haben, die das Caching von Artefakten verhindern.

Nächste Schritte