Virtuelle Repositories – Übersicht

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

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

Funktionsweise virtueller Repositories

Virtuelle Repositories dienen als zentraler Zugriffspunkt zum Herunterladen, Installieren oder Bereitstellen von Artefakten im selben Format aus einem oder mehreren Upstream-Repositories. 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, der Zugriff auf Repository-Gruppen über ein virtuelles Repository vereinfacht jedoch 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, 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 Artifact Registry-Standardrepository und öffentliche Java-Pakete aus einem Remote-Repository bereitstellen, in dem öffentliche Pakete aus Maven Central zwischengespeichert 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 Artifact Registry auswählt, wenn sich ein angefordertes Artefakt in mehreren Upstream-Repositories befindet.

Bei einigen Tools, z. B. dem Python-Tool pip, lässt sich die Suchreihenfolge nicht 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 Verwirrung 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 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 Repositorys 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.

So wird ein Upstream-Repository für virtuelle Repositories ausgewählt

Für jedes Upstream-Repository muss eine Priorität konfiguriert sein. Die Priorität ist eine Ganzzahl, die als Gewichtung und nicht als Ranking dient. Das bedeutet, dass Repositorys mit einem höheren Prioritätswert Vorrang vor Repositorys mit niedrigeren Prioritätswerten haben.

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, kann es sein, dass der Client Artefakte aus Repositories außerhalb von Artifact Registry herunterlädt.

Wenn Sie das Python-Tool pip so konfigurieren, dass PyPI und ein virtuelles Repository durchsucht 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 die Priorität aller Upstream-Repositories steuern, einschließlich eines Upstream-Remote-Repositorys, das als Proxy für PyPI fungiert.

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 anhand der Kurzanleitungen erfahren, wie Sie Standard-Repositories für diese Formate einrichten.

Beschränkungen

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

  • Standardmäßige 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.
  • In virtuellen Maven-Repositories kann die Versionsrichtlinie nicht auf „snapshot“ oder „release“ festgelegt werden.

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

  • Bei Apt- und Yum-Standard-Repositories wird der Paketindex asynchron aktualisiert, nachdem ein Paket importiert, hochgeladen oder gelöscht wurde. Bei kleinen Repositorys kann das Regenerieren 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.

Nächste Schritte