Repository-Übersicht

Artifact Registry ermöglicht das Speichern verschiedener Artefakttypen, das Erstellen mehrerer Repositories in einem einzelnen Projekt und das Verknüpfen einer bestimmten Region oder Mehrfachregion mit jedem Repository. 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 Artefaktformat verknüpft. In einem Python-Repository werden beispielsweise Python-Pakete gespeichert. Sie können für jedes Format mehrere Repositories im selben Google Cloud-Projekt erstellen.

Repository-Modi

Es gibt mehrere Repository-Modi. Da jeder Modus einem anderen Zweck dient, können Sie den Repository-Modus nicht mehr ändern, nachdem Sie ein Repository erstellt haben.

Standard-Repository
Standard-Repositories sind reguläre Artifact Registry-Repositories für Ihre privaten Artefakte. Sie können Artefakte direkt in diesen Repositories hoch- und herunterladen und mithilfe der Artefaktanalyse auf Sicherheitslücken und andere Metadaten scannen.
Remote-Repository

Ein schreibgeschütztes Repository, das als Proxy zum Speichern von Artefakten aus voreingestellten externen Quellen wie Docker Hub, Maven Central, dem Python Package Index (PyPI), Debian oder CentOS sowie von benutzerdefinierten Quellen für unterstützte Formate dient. Wenn Sie zum ersten Mal eine Artefaktversion anfordern, lädt das Repository sie von der externen Quelle herunter und speichert eine Kopie im Cache. Das Repository stellt die im Cache gespeicherte Kopie bereit, wenn dieselbe Version noch einmal angefordert wird.

Remote-Repositories reduzieren die Latenz und verbessern die Verfügbarkeit für Builds und Bereitstellungen in Google Cloud. Mit der Artefaktanalyse können Sie im Cache gespeicherte Pakete auch auf Sicherheitslücken und andere Metadaten scannen.

Virtuelles Repository

Ein schreibgeschütztes Repository, das als einzelner Zugangspunkt 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 Angriffe durch Abhängigkeitsverwirrungen abschwächen, indem Sie Ihre Upstream-Richtlinie so konfigurieren, dass Repositories mit Ihren privaten Artefakten gegenüber Remote-Repositories, die öffentliche Artefakte im Cache speichern, priorisiert werden.

Beispiel für Repository-Verwendung

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. In einem Entwicklungsprojekt erstellen Entwickler eine Java-Anwendung. In einem separaten Laufzeitprojekt erstellt ein anderer Build ein Container-Image mit der Anwendung zur Bereitstellung in Google Kubernetes Engine.

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

  1. Im Entwicklungsprojekt verwendet ein Java-Entwicklungsteam Cloud Build, um eine Java-Anwendung zu erstellen.

    • Der Build kann über das virtuelle Repository öffentliche Java-Abhängigkeiten anfordern. Das virtuelle Repository stellt die Abhängigkeiten vom Remote-Repository bereit, das ein Caching-Proxy für Maven Central ist.
    • Cloud Build lädt das Paket in das Maven-Standard-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 vorgelagerte Standard-Docker-Repository stellt private Images bereit, z. B. die containerisierte Java-Anwendung.
    • Das Upstream-Remote-Repository stellt Images bereit, 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.

Support für gcr.io-Domains

Artifact Registry unterstützt das Hosten von Images in der Domain gcr.io. Wenn Sie von Container Registry auf Artifact Registry umstellen, können Sie Artifact Registry für gcr.io Repositories 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 an einen gcr.io-Hostnamen übertragen wird, um mit dem Container Registry-Verhalten kompatibel zu sein.

Weitere Informationen finden Sie unter Auf Repositories mit gcr.io-Domainunterstützung umstellen.

Speicherort des Repositories

Sie können ein oder mehrere Repositories in einer unterstützten Region oder mehreren Regionen erstellen. Ein guter Repository-Speicherort bietet ein Gleichgewicht zwischen Latenz, Verfügbarkeit und Bandbreitenkosten für Datennutzer. Ihre Organisation hat möglicherweise auch bestimmte Compliance-Anforderungen.

Überlegungen zum Standort

Das Erstellen eines Repositorys in derselben Region wie andere Google Cloud-Dienste bietet eine Reihe von Vorteilen:

  • Reduzieren Sie Latenz und Kosten für ausgehenden Netzwerktraffic. Erstellen Sie dazu Repositories in derselben Region, 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 Gebühren an.

    Obwohl für ausgehenden Traffic von einem multiregionalen Standort zu einem Google Cloud-Dienst in einer entsprechenden Region keine Gebühr berechnet wird, gelten diese Preise nur für eine begrenzte Anzahl von Regionen.

    • Beim multiregionalen Standort us wird ausgehender Traffic in eine Region in den USA, z. B. us-central, nicht berechnet, aber alle Regionen in Kanada oder Südamerika.
    • Beim multiregionalen Standort asia wird ausgehender Traffic an Regionen in Asien wie asia-northeast1 nicht berechnet, ausgehender Traffic zu Regionen in Australien hingegen.

  • Sie können Image-Streaming in GKE und Dataproc Serverless nur verwenden, wenn Ihre Container-Images in Artifact Registry-Repositories in derselben Region wie Ihre Arbeitslasten oder an einem multiregionalen Standort gespeichert sind, der der Region mit Ihren Arbeitslasten entspricht. Durch Image-Streaming kann die Initialisierungszeit von Arbeitslasten erheblich reduziert werden, wenn Sie größere Container-Images verwenden, da die Arbeitslasten gestartet werden können, bevor das gesamte Image heruntergeladen wurde.

  • Berücksichtigen Sie den Standort der Verbraucher außerhalb von Google Cloud. Wenn Ihre Entwicklerteams in Australien beispielsweise Artefakte aus Artifact Registry auf ihre lokalen Workstations herunterladen müssen, reduziert ein Repository in einer australischen Region die Latenz und verursacht geringere Gebühren für ausgehenden Traffic als ein Repository auf einem anderen Kontinent.

Repository-Standorte einschränken

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

Projektstruktur

Mit der Ressourcenhierarchie organisieren Sie Ihre Ressourcen in Google Cloud-Projekten. Die Struktur, die Sie wählen, hängt von Faktoren wie Data Governance-Anforderungen, Vertrauensgrenzen und Teamstruktur ab.

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

Repositories zentralisieren
Erstellen Sie alle Repositories in einem einzelnen Projekt und gewähren Sie dann Zugriff auf Hauptkonten aus anderen Projekten auf Repository-Ebene. Dieser Ansatz kann effektiver sein, wenn eine einzelne Person oder ein einzelnes Team die Repository-Verwaltung und den Repository-Zugriff in der gesamten Organisation übernimmt. Es kann auch die Einrichtung virtueller Repositories oder Lösungen wie Software Delivery Shield vereinfachen, da Sie nur eine einzelne Instanz von Artifact Registry aktivieren und verwalten müssen.
Projektspezifische Repositories
Repositories in Projekten erstellen, in denen Artefakte gespeichert und heruntergeladen werden Dieser Ansatz kann erforderlich sein, wenn Sie Data-Governance-Richtlinien oder Vertrauensgrenzen haben, die eine stärkere Trennung und Kontrolle von Ressourcen auf Projektebene erfordern.

Zugriffssteuerung

Repositories sind nur mit den entsprechenden Berechtigungen zugänglich, 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 wie Cloud Build, Cloud Run und GKE 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 Ihrer Organisation. Ihr Repository-Administrator muss diesen Diensten in folgenden Fällen explizit Zugriff auf Repositories gewähren:

  • Artifact Registry befindet sich in einem anderen Projekt als der Dienst, der damit interagiert.
  • Sie verwenden benutzerdefinierte IAM-Rollen mit den Standarddienstkonten anstelle der vordefinierten Rolle.
  • Sie verwenden nicht das Standarddienstkonto für den Google Cloud-Dienst.
  • Sie richten virtuelle Repositories ein. 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 unbedingt 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 veröffentlicht werden. Entwickler benötigen Lese- und Schreibzugriff auf das Entwicklungs-Repository und Lesezugriff auf das Produktions-Repository.
  • Sie haben ein Demo-Repository mit Beispielanwendungen. Ihr Vertriebsteam benötigt nur Lesezugriff, um die Demos herunterzuladen.

Datenverschlüsselung

Standardmäßig verschlüsselt Google Cloud Daten im inaktiven Zustand automatisch mit von Google verwalteten Verschlüsselungsschlüsseln. Wenn Sie bestimmte Compliance- oder regulatorische Anforderungen in Bezug auf die Schlüssel zum Schutz Ihrer Daten haben, können Sie Repositories erstellen, die mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt sind.

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

Labels und Tags

Mit Labels können Sie Ressourcen organisieren, die für einen Google Cloud-Dienst spezifisch sind. In Artifact Registry können Sie Repositories Labels hinzufügen, um sie zu gruppieren oder Repository-Listen nach Label zu filtern. Beispielsweise können Sie Labels verwenden, um Repositories zu Automatisierungs- oder Abrechnungszwecken nach Entwicklungsphase oder nach Team 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 hauptsächlich zum Organisieren und Filtern dienstspezifischer Ressourcen. Tags dienen jedoch der programmatischen Kontrolle von Richtlinien in einer Google Cloud-Organisation. Weitere Informationen finden Sie unter Repositories taggen.

Weitere Informationen