Repository-Übersicht

Mit Artifact Registry können Sie verschiedene Artefakttypen speichern, mehrere Repositories in einem einzelnen Projekt erstellen und mit jedem Repository eine bestimmte Region oder mehrere Regionen verknüpfen. 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. Ein Docker-Repository speichert beispielsweise Docker-Images. 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 aufgrund von Abhängigkeitsverwirrung abmildern. Konfigurieren Sie dazu Ihre Upstream-Richtlinie so, dass Repositories mit Ihren privaten Artefakten gegenüber Remote-Repositories, die öffentliche Artefakte im Cache speichern, priorisiert wird.

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.

Speicherort des Repositories

Sie können ein oder mehrere Repositories in einer unterstützten -Region oder einer unterstützten 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 der 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.

Bereinigungsrichtlinien

Eine Bereinigungsrichtlinie für Artifact Registry definiert Kriterien für das automatische Löschen von Artefaktversionen, die Sie nicht mehr benötigen, oder für die Aufbewahrung von Artefakten, die Sie auf unbestimmte Zeit speichern möchten.

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

Wenn eine Artefaktversion die Kriterien sowohl in einer Lösch- als auch in einer Keep-Richtlinie erfüllt, wendet Artifact Registry die Beibehaltungsrichtlinie an.

Richtlinien löschen

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 per Push oder Pull in ein oder aus einem Repository übertragen wird. Weitere Informationen zu Docker-Tags finden Sie unter Containerkonzepte.

    • Beliebiger Tag-Status: Der Tag-Status wird ignoriert und sowohl auf getaggte als auch auf nicht getaggte Artefakte angewendet.
    • Tagged: Gilt nur für getaggte Artefakte.
    • Nicht getaggt: Gilt nur für Artefakte ohne Tags.

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

    Weitere Informationen zum Tag-Status im Hinblick auf Bereinigungsrichtlinien finden Sie in der TagState-Referenz.

Sie haben folgende Möglichkeiten, Ihre Löschrichtlinie optional zu definieren:

  • Tag-Präfixe: ist eine durch Kommas getrennte Liste von Tag-Präfixen. Die Präfixe test und staging stimmen beispielsweise mit Images mit den Tags testenv und staging-1.5 überein. tagState muss auf TAGGED gesetzt sein, damit Tag-Präfixe verwendet werden können.
    • Versionspräfixe: ist eine durch Kommas getrennte Liste von Artefaktversionspräfixen. Beispiel: v1 und v2 entsprechen den Versionen v1.5, v2.0alpha und v10.2.
  • Paketpräfixe: ist eine Liste von Artefaktnamenpräfixen. Sie können mehrere Präfixe eingeben, indem Sie zwischen den Präfixen Enter oder , drücken. red, blue würde beispielsweise die beiden Präfixe red und blue erstellen und den Artefaktnamen red-team, redis und bluebird entsprechen.
  • Älter als: Die Mindestzeit seit dem Hochladen einer Artefaktversion in das Repository, angegeben als Dauer. Beispiel: 30d entspricht 30 Tagen. Sie können eine Dauer von Sekunden, Minuten, Stunden oder Tagen angeben, indem Sie s, m, h bzw. d anhängen.
  • Neuer als: Die maximale Zeit seit dem Hochladen einer Artefaktversion in das Repository, angegeben als Dauer. Beispiel: 30d entspricht 30 Tagen.

Richtlinien beibehalten

Mit Richtlinien sorgen Sie dafür, dass Artefakte die gleichen Bedingungen wie Löschrichtlinien oder eine bestimmte Anzahl der neuesten Versionen erfüllen.

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 die Richtlinie Neueste Versionen beibehalten so konfiguriert ist, dass drei Versionen von Paketen beibehalten werden, die den Paketpräfixen entsprechen: {release-xyz}, nur release-xyz-v1 und release-xyz-v2 werden beibehalten.

Durch Löschrichtlinien ausgelöste Löschungen werden auf Ihr Kontingent pro Projektlöschungsanfrage in Artifact Registry angerechnet.

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

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.

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 einzige 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 einzige 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 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 inaktive Daten automatisch mit Google-eigenen und von Google verwalteten Schlü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