Virtuelle Repositories – Übersicht

In diesem Dokument finden Sie eine Übersicht über virtuelle Repositories. 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, 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-Standard-Repository und öffentliche Java-Pakete aus einem Remote-Repository bereitstellen, in dem öffentliche Pakete von 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 Auflösung von Abhängigkeiten

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 Angriff durch Verwechslung von Abhängigkeiten. 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 mindern:

  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 die Verwaltung von Abhängigkeiten finden Sie unter Abhängigkeitsverwaltung.

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

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 es nur das virtuelle Repository durchsucht, 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 Kurzanleitungen 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:

  • 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 Standard-Repositories von Apt und Yum 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 oder veröffentlichen Artefakte wie private Pakete direkt in Standard-Repositories. 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 die gleiche 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