Repository-Übersicht

Mit Artifact Registry können Sie verschiedene Artefakttypen speichern, mehrere Repositories in einem einzelnen Projekt erstellen und jedem Repository einen bestimmten regionalen oder multiregionalen Standort zuordnen. Auf dieser Seite werden Überlegungen zum Planen der Speicherorte und der Organisation Ihrer Repositories beschrieben.

Berücksichtigen Sie beim Erstellen Ihrer Repositories sowohl interne Prozesse als auch die Nutzung durch Nutzer Ihrer Artefakte.

Repository-Formate

Jedes Repository ist mit einem bestimmten Artefakt format verknüpft. In einem Docker-Repository werden beispielsweise Docker-Images gespeichert. Sie können mehrere Repositories für jedes Format in demselben Google Cloud Projekt erstellen.

Repository-Modi

Es gibt mehrere Repository-Modi. Jeder Modus dient einem anderen Zweck. Daher können Sie den Repository-Modus nach dem Erstellen eines Repositorys nicht mehr ändern.

Standard-Repository

Standard-Repositories sind reguläre Artifact Registry-Repositories für Ihre privaten Artefakte. Sie können Artefakte direkt in diese Repositories hochladen und daraus herunterladen und mit Artefaktanalyse nach Sicherheitslücken und anderen Metadaten suchen.

Informationen zum Erstellen von Standard-Repositories finden Sie unter Standard-Repositories erstellen.

Remote-Repository

Remote-Repositories sind schreibgeschützte Repositories, die als Proxys fungieren, um Artefakte aus den folgenden Upstream-Quellen zu speichern:

  • Standard-Repositories von Artifact Registry.
  • Externe Quellen wie Docker Hub, Maven Central, Python Package Index (PyPI), Debian oder CentOS.

Wenn Sie eine Artefaktversion zum ersten Mal anfordern, wird sie vom Repository aus der Upstream-Quelle heruntergeladen und eine Kopie davon im Cache gespeichert. Wenn dieselbe Version noch einmal angefordert wird, wird die Kopie aus dem Cache des Remote-Repositorys bereitgestellt.

Remote-Repositories reduzieren die Latenz und verbessern die Verfügbarkeit für Builds und Bereitstellungen in Google Cloud. Sie können auch mit Artefaktanalyse nach Sicherheitslücken und anderen Metadaten in Paketen suchen, die im Cache gespeichert sind.

Weitere Informationen zu Remote-Repositories finden Sie in der Übersicht zu Remote-Repositories . Informationen zum Erstellen von Remote-Repositories finden Sie unter Remote-Repositories erstellen.

Connector-Repository (Vorschau)

Connector-Repositories fungieren als Proxys für Upstream-Quellen und sorgen dafür, dass alle Anfragen von der Upstream-Quelle verarbeitet werden. Im Gegensatz zu Remote-Repositories werden in Connector-Repositories keine Artefakte im Cache gespeichert. Connector-Repositories sind daher nützlich, wenn Sie eine vollständige Prüfbarkeit von Upstream-Quellen benötigen oder wenn Sie Richtlinien von Drittanbietern einhalten müssen, die das Speichern von Artefakten im Cache verhindern.

Weitere Informationen zu Connector-Repositories finden Sie in der Übersicht zu Connector-Repositories. Informationen zum Erstellen von Connector Repositories finden Sie unter Connector-Repositories erstellen.

Virtuelles Repository

Ein schreibgeschütztes Repository, das als einzelner Zugriffspunkt zum Herunterladen, Installieren oder Bereitstellen von Artefakten desselben Formats aus einem oder mehreren Upstream-Repositories dient. Ein Upstream-Repository kann ein Standard-, Remote- oder virtuelles Repository sein.

Virtuelle Repositories vereinfachen die Clientkonfiguration für Nutzer Ihrer Artefakte. Sie können auch Dependency-Confusion-Angriffe verhindern, indem Sie Ihre Upstream- Richtlinie so konfigurieren, dass Repositories mit Ihren privaten Artefakten Vorrang vor Remote- Repositories haben, in denen öffentliche Artefakte im Cache gespeichert werden.

Weitere Informationen zu virtuellen Repositories finden Sie in der Übersicht zu virtuellen Repositories. Informationen zum Erstellen von virtuellen Repositories finden Sie unter Virtuelle Repositories erstellen.

Beispiel für die Repository-Nutzung

Das folgende Diagramm zeigt eine von vielen Möglichkeiten, wie Sie Repositories in verschiedenen Modi zusammen verwenden können. Das Diagramm zeigt einen Workflow über zwei Google Cloud Projekte hinweg. In einem Entwicklungsprojekt erstellt ein Entwicklungsteam eine Java-Anwendung. In einem separaten Laufzeitprojekt wird mit einem weiteren Build ein Container-Image mit der Anwendung für die Bereitstellung in der Google Kubernetes Engine erstellt.

Standard-, virtuelle und Remote-Repositories, die in zwei Projekten verwendet werden.

  1. In einem Entwicklungsprojekt erstellt ein Java-Entwicklungsteam mit Cloud Build eine Java-Anwendung.

    • Der Build kann öffentliche Java-Abhängigkeiten über das virtuelle Repository anfordern. Das virtuelle Repository stellt die Abhängigkeiten aus dem Remote-Repository bereit, das als Caching-Proxy für Maven Central dient.
    • Cloud Build lädt das Paket in das Standard-Maven-Repository im Komponentenprojekt hoch.

  2. Im Laufzeitprojekt containerisiert Cloud Build die Java-Anwendung.

    Der Build verwendet das virtuelle Maven-Repository, um die Anwendung herunterzuladen. Das virtuelle Repository stellt das Paket aus dem Standard-Repository im Entwicklungsprojekt bereit. Der Build kann auch öffentliche Java-Abhängigkeiten aus demselben virtuellen Repository herunterladen.

  3. Im Laufzeitprojekt lädt Cloud Build das erstellte Container-Image in ein Standard-Docker-Repository hoch.

  4. GKE ruft Images aus dem virtuellen Docker-Repository ab.

    • Das Upstream-Standard-Docker-Repository enthält private Images wie die containerisierte Java-Anwendung.
    • Das Upstream-Remote-Repository enthält Images, die GKE von Docker Hub anfordert.

In diesem Beispiel befinden sich alle Repositories, Builds und GKE-Cluster in derselben Region. Die Verwendung desselben Standorts für Google Cloud Dienste hat Vorteile, die unter Speicherort des Repositorys beschrieben werden.

Speicherort des Repositorys

Sie können ein oder mehrere Repositories in einer unterstützten Region oder Multi-Region erstellen. Ein guter Speicherort für ein Repository bietet für die Datennutzer den optimalen Ausgleich von Latenz, Verfügbarkeit und Kosten der Bandbreite. Möglicherweise hat Ihre Organisation auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

In diesem Abschnitt wird beschrieben, warum Sie ein Repository in derselben Region wie andere Google Cloud Dienste erstellen sollten.

Sie können die Latenz und die Kosten für ausgehenden Netzwerktraffic reduzieren, indem Sie Repositories in derselben Region erstellen, in der Sie GKE, Cloud Run, Cloud Build und andere Google Cloud Dienste ausführen, die mit dem Repository interagieren. Für ausgehenden Traffic von Artifact Registry zu anderen Google Cloud Diensten in derselben Region fallen keine Kosten an.

Für ausgehenden Traffic von einer Multi-Region zu einem Google Cloud Dienst in einer entsprechenden Region fallen zwar keine Kosten an, diese Preise gelten jedoch nur für eine begrenzte Anzahl von Regionen.

  • Bei der us Multi-Region wird ausgehender Traffic zu einer Region in den USA wie us-central nicht in Rechnung gestellt, zu einer Region in Kanada oder Südamerika jedoch schon.
  • Bei der asia Multi-Region wird ausgehender Traffic zu Regionen in Asien wie asia-northeast1 nicht in Rechnung gestellt, zu Regionen in Australien jedoch schon.
Sie können Image-Streaming in GKE und Managed Service for Apache Spark nur verwenden, wenn Ihre Container-Images in Artifact Registry Repositories in derselben Region wie Ihre Arbeitslasten oder in einer Multi-Region gespeichert sind, die der Region mit Ihren Arbeitslasten entspricht. Image-Streaming kann die Initialisierungszeit von Arbeitslasten erheblich verkürzen, wenn Sie größere Container-Images verwenden, da Arbeitslasten gestartet werden können, bevor das gesamte Image heruntergeladen wurde.

Berücksichtigen Sie den Standort von Nutzern außerhalb von Google Cloud. Wenn beispielsweise Ihr Entwicklungsteam in Australien Artefakte aus Artifact Registry auf seine lokalen Arbeitsstationen herunterladen muss, reduziert ein Repository in einer australischen Region die Latenz und verursacht geringere Kosten für ausgehenden Traffic als ein Repository auf einem anderen Kontinent.

Repository-Standorte einschränken

Wenn Sie Vorschriften oder Richtlinien einhalten müssen, die die Speicherung von Daten in bestimmten Regionen erfordern, können Sie in Ihre Organisationsrichtlinie eine Einschränkung für Ressourcenstandorte aufnehmen, die nur die Erstellung von Repositories in konformen Regionen zulässt. Google Cloud Artifact Registry erzwingt die Einschränkung erst, nachdem Sie sie in Ihre Organisationsrichtlinie aufgenommen haben. Wenn Sie bereits Repositories an nicht konformen Standorten haben, müssen Sie Ihre Artefakte selbst in ein Repository an einem konformen Standort verschieben und dann das nicht konforme Repository löschen.

Bereinigungsrichtlinien

Eine Bereinigungsrichtlinie für Artifact Registry definiert Kriterien zum automatischen Löschen von Artefaktversionen, die Sie nicht mehr benötigen, oder zum Aufbewahren von Artefakten, die Sie unbegrenzt speichern möchten.

Bereinigungsrichtlinien sind nützlich, wenn Sie viele Versionen Ihrer Artefakte speichern, aber nur bestimmte Versionen aufbewahren müssen, die Sie für die Produktion freigeben. Sie können Löschrichtlinien mit Kriterien zum Löschen von Artefakten und Aufbewahrungsrichtlinien mit Kriterien zum Aufbewahren von Artefakten definieren.

Wenn eine Artefaktversion die Kriterien sowohl einer Löschrichtlinie als auch einer Aufbewahrungsrichtlinie erfüllt, wendet Artifact Registry die Aufbewahrungsrichtlinie an.

Löschrichtlinien verwenden

Mit Löschrichtlinien werden Artefakte gelöscht, die die folgenden erforderlichen Kriterien erfüllen:

  • Tag-Status: Gibt an, ob die Richtlinie nach getaggten oder nicht getaggten Artefakten suchen soll. Artefakte werden getaggt, wenn ein Image in ein Repository hochgeladen oder daraus heruntergeladen wird. Weitere Informationen zu Docker-Tags finden Sie unter Containerkonzepte.

    • Beliebiger Tag-Status: Der Tag-Status wird ignoriert und die Richtlinie gilt sowohl für getaggte als auch für nicht getaggte Artefakte.
    • Getaggt: Die Richtlinie gilt nur für getaggte Artefakte.
    • Nicht getaggt: Die Richtlinie gilt nur für nicht getaggte Artefakte.

    Formate, die keine Tags unterstützen, werden als untagged behandelt. Getaggte Artefakte in Repositories, in denen unveränderliche Tags aktiviert sind, können nicht gelöscht werden.

    Weitere Informationen zum Tag-Status in Bezug auf Bereinigungsrichtlinien finden Sie in der Referenz zu TagState.

Sie können die folgenden Einstellungen verwenden, um Ihre Löschrichtlinie zu konfigurieren:

  • Tag-Präfixe: Eine durch Kommas getrennte Liste von Tag-Präfixen. Die Präfixe test und staging würden beispielsweise mit Images mit den Tags testenv und staging-1.5 übereinstimmen. tagState muss auf TAGGED gesetzt sein, um Tag-Präfixe verwenden zu können.
    • Versionspräfixe: Eine durch Kommas getrennte Liste von Präfixen für Artefaktversionen. Beispielsweise würden v1 und v2 mit den Versionen v1.5, v2.0alpha und v10.2 übereinstimmen.
  • Paketpräfixe: Eine Liste von Präfixen für Artefaktnamen. Sie können mehrere Präfixe eingeben, indem Sie zwischen den Präfixen Enter oder , drücken. Beispielsweise würden red, blue zwei Präfixe erstellen, red und blue, und mit den Artefaktnamen red-team, redis, und bluebird übereinstimmen.
  • Älter als: Eine Mindestzeit seit dem Hochladen einer Artefaktversion in das Repository, angegeben als Dauer. Beispielsweise sind 30d 30 Tage. Sie können Dauern in Sekunden, Minuten, Stunden oder Tagen angeben, indem Sie jeweils s, m, h oder d anhängen.
  • Neuer als: Eine maximale Zeit seit dem Hochladen einer Artefaktversion in das Repository, angegeben als Dauer. Beispielsweise sind 30d 30 Tage.

Aufbewahrungsrichtlinien verwenden

Mit Aufbewahrungsrichtlinien werden Artefakte beibehalten, die dieselben Bedingungen wie Löschrichtlinien erfüllen, oder eine bestimmte Anzahl der neuesten Versionen.

Angenommen, ein Repository enthält die folgenden Artefakte:

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v1
DIGEST: sha256:1b0a26bd07a3d17473d8d8468bea84015e27f87124b2831234581bce13f61370
TAGS:
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:10

IMAGE: us-west1-docker.pkg.dev/my-project/release-xyz-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

IMAGE: us-west1-docker.pkg.dev/my-project/release-v2
DIGEST: sha256:6e494387c901caf429c1bf77bd92fb82b33a68c0e19f123456a3ac8d27a7049d
TAGS: latest
CREATE_TIME: 2023-06-19T18:59:09
UPDATE_TIME: 2023-06-19T18:59:09

Wenn Ihre Richtlinie Neueste Versionen beibehalten so festgelegt ist, dass drei Versionen von Paketen beibehalten werden, die mit den Paketpräfixen: {release-xyz} übereinstimmen, werden nur release-xyz-v1 und release-xyz-v2 beibehalten.

Löschvorgänge, die durch Löschrichtlinien ausgelöst werden, werden auf Ihr Kontingent für Löschvorgänge pro Projekt in Artifact Registry angerechnet.

Informationen zum Erstellen und Anwenden von Bereinigungsrichtlinien auf Ihr Repository finden Sie unter Bereinigungsrichtlinien konfigurieren.

Unterstützung für gcr.io-Domains

Artifact Registry unterstützt das Hosten von Images in der Domain gcr.io. Wenn Sie von Container Registry zu Artifact Registry wechseln, können Sie gcr.io-Repositories in Artifact Registry einrichten, um Änderungen an Ihrer vorhandenen Automatisierung und Ihren Workflows zu minimieren. Diese Repositories bieten:

  • Weiterleitung von Anfragen an die Domain gcr.io.
  • Erstellung von gcr.io-Repositories, wenn das erste Image in einen gcr.io-Hostnamen übertragen wird, um die Kompatibilität mit dem Verhalten von Container Registry zu gewährleisten.

Weitere Informationen finden Sie unter Zu Repositories mit Unterstützung von gcr.io-Domains wechseln.

Projektstruktur

Mit Ihrer Ressourcenhierarchie organisieren Sie Ihre Ressourcen in verschiedenen Google Cloud Projekten. Die von Ihnen gewählte Struktur hängt von Faktoren wie Anforderungen an die Data Governance, Vertrauensgrenzen und der Teamstruktur ab.

Es gibt zwei allgemeine Ansätze zum Einrichten Ihrer Repositories in Organisationen mit mehreren Projekten.

Repositories zentralisieren

Erstellen Sie alle Repositories in einem einzelnen Projekt und gewähren Sie dann Hauptkonten aus anderen Projekten Zugriff auf Repository-Ebene. Dieser Ansatz kann effektiver sein, wenn eine einzelne Person oder ein einzelnes Team die Repository-Verwaltung und den Repository-Zugriff in Ihrer Organisation übernimmt.

Außerdem kann die Einrichtung virtueller Repositories vereinfacht werden, da Sie nur eine einzelne Instanz von Artifact Registry aktivieren und verwalten müssen.

Projektspezifische Repositories

Erstellen Sie Repositories in Projekten, in denen Artefakte gespeichert und heruntergeladen werden. Dieser Ansatz ist möglicherweise erforderlich, wenn Sie Data Governance-Richtlinien oder Vertrauensgrenzen haben, die eine stärkere Trennung und Kontrolle von Ressourcen auf Projektebene erfordern.

Zugriffssteuerung

Auf Repositories kann nur mit den entsprechenden Berechtigungen zugegriffen werden, es sei denn, Sie konfigurieren das Repository für öffentlichen Zugriff. Sie können Berechtigungen auf Projekt- oder Repository-Ebene erteilen.

Einige Google Cloud Dienste verwenden Standarddienstkonten mit Standardberechtigungen für Repositories im selben Google Cloud Projekt. Diese Standardeinstellungen sind jedoch möglicherweise nicht für Ihren Softwareentwicklungsprozess geeignet oder entsprechen nicht den Sicherheits- oder Richtlinienanforderungen in Ihrer Organisation. Ihr Repository-Administrator muss diesen Diensten explizit Zugriff auf Repositories gewähren, wenn:

  • Artifact Registry sich in einem anderen Projekt befindet als der Dienst, der mit ihr interagiert.
  • Sie benutzerdefinierte IAM-Rollen mit den Standarddienstkonten anstelle der vordefinierten Rolle verwenden.
  • Sie nicht das Standarddienstkonto für den Google Cloud Dienst verwenden.
  • Sie virtuelle Repositories einrichten. Sie müssen dem Artifact Registry-Dienstkonto explizit Zugriff auf Upstream-Repositories gewähren.

Für andere Hauptkonten, die Zugriff auf Repositories benötigen, muss Ihr Repository-Administrator Zugriff gewähren. Gewähren Sie gemäß dem Sicherheitsprinzip der geringsten Berechtigung nur die minimal erforderlichen Berechtigungen. Beispiel:

  • Sie stellen Container-Images in Artifact Registry für GKE-Cluster in mehreren verschiedenen Projekten bereit. Das Dienstkonto für Knoten in diesen Clustern benötigt nur Lesezugriff auf Repositories.
  • Sie haben ein Entwicklungs-Repository für Anwendungen, die sich in der Entwicklung befinden, und ein Produktions-Repository für Anwendungen, die freigegeben wurden. Entwickler benötigen Lese- und Schreibzugriff auf das Entwicklungs-Repository und schreibgeschützten Zugriff auf das Produktions-Repository.
  • Sie haben ein Demo-Repository mit Beispielanwendungen. Ihr Vertriebsteam benötigt nur schreibgeschützten Zugriff, um die Demos herunterzuladen.

Artefakt-Downloads einschränken

Sie können Artefakt-Downloads mit Downloadregeln einschränken. Mit Downloadregeln können Sie Artefakt-Downloads aus Ihren Repositories und Paketen zulassen oder ablehnen. Sie können auch Bedingungen festlegen, damit die Regel auf bestimmte Tags oder Versionen angewendet wird.

Weitere Informationen zur Funktionsweise von Downloadregeln finden Sie im Abschnitt Artefakt-Downloads einschränken in der Übersicht Zugriff steuern und Artefakte schützen.

Datenverschlüsselung

Standardmäßig Google Cloud verschlüsselt Daten im inaktiven Zustand automatisch mit von Google entwickelten und von Google verwalteten Verschlüsselungsschlüsseln. Wenn Sie bestimmte Compliance- oder gesetzliche Anforderungen für die Schlüssel zum Schutz Ihrer Daten erfüllen müssen, können Sie Repositories erstellen, die mit kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt sind.

Artifact Registry unterstützt auch Einschränkungen für Organisationsrichtlinien die CMEK zum Schutz von Ressourcen erfordern können.

Labels und Tags

Mit Labels können Sie dienstspezifische Ressourcen organisieren. Google Cloud In Artifact Registry können Sie Repositories Labels hinzufügen, um sie zu gruppieren oder Repository-Listen nach Label zu filtern. Sie können beispielsweise Labels verwenden, um Repositories nach Entwicklungsphase oder Team für Automatisierungs- oder Abrechnungszwecke zu gruppieren. Weitere Informationen zum Erstellen und Verwenden von Repository-Labels finden Sie unter Repositories mit Labels versehen.

Sie können auch Tags auf Repositories anwenden. Labels dienen in erster Linie zum Organisieren und Filtern dienstspezifischer Ressourcen, während Tags zur programmatischen Steuerung von Richtlinien in einer Google Cloud Organisation verwendet werden. Weitere Informationen finden Sie unter Repositories taggen.

Weitere Informationen