Virtuelle Repositories – Übersicht

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

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

Funktionsweise von virtuellen Repositories

Virtuelle Repositories dienen als einzelner Zugangspunkt zum Herunterladen, Installieren oder Bereitstellen von Artefakten im selben Format aus einem oder mehreren vorgelagerten Repositories. Ein Upstream-Repository kann ein Artifact Registry-Standard- oder ein Remote-Repository sein.

Die anderen Repository-Modi sind:

  • Standard: Der standardmäßige Repository-Modus. Sie laden Artefakte wie private Pakete direkt in Standard-Repositories hoch oder veröffentlichen sie. Obwohl Sie Inhalte direkt aus einzelnen Standard-Repositories herunterladen können, vereinfacht der Zugriff auf Gruppen von Repositories über ein virtuelles Repository die Toolkonfiguration.
  • Remote (nur Sprachpaket-Repositories): Ein Pull-Through-Cache für Artefakte in öffentlichen Repositories wie Maven Central oder PyPI. Er 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, die nur Lesezugriff auf Repositories benötigen, müssen Sie nur ein einzelnes Artifact Registry-Repository für den Zugriff auf Artefakte konfigurieren, 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, das öffentliche Pakete von Maven Central im Cache speichert.
  • Ein virtuelles Repository kann private Python-Pakete aus mehreren vorgelagerten Standard-Repositories bereitstellen, die verschiedenen Teams gehören. Jedes Team hat Schreibzugriff auf sein Upstream-Repository, lädt jedoch über das virtuelle Repository Pakete von anderen Teams herunter.
Sicherere Abhängigkeitslösung

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

Einige Tools, z. B. 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 von Konfiguration ist anfällig für einen Abhängigkeitsverwechslungsangriff, bei dem jemand eine neue Version eines Pakets mit fehlerhaftem Code in ein öffentliches Repository hochlädt, um Clients dazu zu bringen, die schlechte 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 in beiden Repositories eine Version desselben Pakets vorhanden ist.
  4. Konfigurieren Sie Paketmanager und andere Tools so, dass sie nur aus dem virtuellen Repository lesen, sodass die Clientlogik nicht mit der Repository-Auswahl spielt.

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

So wählen virtuelle Repositories ein Upstream-Repository aus

Jedes Upstream-Repository muss eine konfigurierte Priorität haben. Die Priorität ist eine Ganzzahl, die als Gewichtung und nicht als Ranking fungiert. Dies bedeutet, dass Repositories mit einem höheren Prioritätswert gegenüber Repositories mit niedrigeren Prioritätswerten 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 wird priorisiert. Der Wert 10 hat beispielsweise eine höhere Priorität als der Wert 1.
  • Wenn mehrere vorgelagerte Repositories die gleiche Priorität haben, kann das Artefakt von einem dieser Repositories bereitgestellt werden.

Wenn Sie einen Client direkt für die Suche in einem virtuellen Repository und zusätzlichen Repositories konfigurieren, lädt der Client möglicherweise trotzdem Artefakte aus Repositories außerhalb von Artifact Registry herunter.

Wenn Sie beispielsweise das pip-Tool von Python so konfigurieren, dass PyPI und ein virtuelles Repository gesucht werden, 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 dann 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 Informationen zum Einrichten von Standard-Repositories für diese Formate lesen.

Beschränkungen

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

  • Upstream-Repositories müssen sich in derselben Region oder mehreren Regionen wie das virtuelle Repository befinden, können sich aber in verschiedenen Google Cloud-Projekten befinden.
  • Virtuelle Maven-Repositories lassen nicht zu, dass die Versionsrichtlinie auf einen Snapshot oder Release festgelegt wird.

Während der Vorabversion gelten für Apt- und Yum-Repositories zusätzliche Einschränkungen:

  • Sie können nur Standard-Repositories als Upstream-Repositories verwenden.

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

Nächste Schritte