Diese Seite wurde von der Cloud Translation API übersetzt.

Artifact Registry – Detailanalyse

1. Übersicht

Artifact Registry ist ein vollständig verwalteter Paketmanager und bietet ein einheitliches Tool zur Verwaltung Ihrer OCI-Container-Images und Sprachpakete (z. B. Maven und npm).

Artifact Registry ist vollständig in die breite Palette anderer Google Cloud-Dienste eingebunden, wie in den folgenden Beispielen:

Cloud Build kann Image-Artefakte direkt in Artifact Registry hochladen.
Cloud Deploy kann die Artifact Registry-Images direkt in verschiedenen Laufzeitumgebungen bereitstellen.
Es stellt Images für Containerlaufzeiten wie Cloud Run und GKE bereit und ermöglicht erweiterte Funktionen zur Leistungsoptimierung wie Image-Streaming.
Artifact Registry kann als Erkennungspunkt für Artifact Analysis dienen, um kontinuierlich nach bekannten Sicherheitslücken zu suchen.
Cloud IAM bietet eine einheitliche und detaillierte Kontrolle über den Zugriff auf Artefakte und Berechtigungen.

In diesem Lab werden viele dieser Funktionen in Form einer praktischen Anleitung erläutert.

Lerninhalte

Was sind die Lernziele dieses Labs?

Unterschiedliche Repositories für Container und Sprachpakete erstellen
Container-Images mit Artifact Registry erstellen und verwenden
Mit Artifact Registry die Sicherheitslage und den Inhalt Ihrer Artefakte analysieren
Artifact Registry für Java-Maven-Abhängigkeiten konfigurieren und verwenden

2. Einrichtung und Anforderungen

Einrichten der Umgebung im eigenen Tempo

Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. In der Regel spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Konto ausprobieren und prüfen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Durchführung dieses Codelabs ist kostenlos oder kostet nur sehr wenig. Wenn Sie die Ressourcen herunterfahren möchten, um Kosten nach Abschluss dieser Anleitung zu vermeiden, können Sie die von Ihnen erstellten Ressourcen oder das Projekt löschen. Neuen Google Cloud-Nutzern steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

gcloud einrichten

Legen Sie in Cloud Shell eine Projekt-ID und Projektnummer fest. Speichern Sie sie als Variablen vom Typ PROJECT_ID und PROJECT_NUMBER.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

Google-Dienste aktivieren

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  binaryauthorization.googleapis.com \
  cloudbuild.googleapis.com

Quellcode abrufen

Der Quellcode für dieses Lab befindet sich in der GoogleCloudPlatform-Organisation auf GitHub. Klonen Sie es mit dem folgenden Befehl.

git clone https://github.com/GoogleCloudPlatform/java-docs-samples

3. Container-Images pushen

Docker-Repository in Artifact Registry erstellen

Wie bereits erwähnt, unterstützt Artifact Registry verschiedene Repository-Formate, mit denen Sie Container-Images und Sprachpakete verwalten können. Die Interaktionen mit den verschiedenen Arten von Artefakt-Repositories sind in Spezifikationen definiert und entsprechen weithin anerkannten Standards. So unterscheiden sich beispielsweise die Anfragen für Maven-Abhängigkeiten von Anfragen für Node-Abhängigkeiten.

Um bestimmte API-Spezifikationen für Artefakte zu unterstützen, muss Artifact Registry Ihre Artefakte in den entsprechenden Repository-Typen verwalten. Wenn Sie ein neues Repository erstellen, geben Sie das Flag --repository-format an, um den Repositorytyp anzugeben.

Führen Sie in Cloud Shell den folgenden Befehl aus, um ein erstes Repository für Docker-Images zu erstellen:

gcloud artifacts repositories create container-example --repository-format=docker \
--location=us-central1 --description="Example Docker repository"

Klicken Sie auf „Autorisieren“, wenn die Aufforderung zur Autorisierung von Cloud Shell angezeigt wird.

Rufen Sie die Google Cloud Console auf und gehen Sie zu „Artifact Registry“ - „Repositories“. Sie sehen dort Ihr neu erstelltes Docker-Repository mit dem Namen container-example. Wenn Sie darauf klicken, sehen Sie, dass es derzeit leer ist.

Docker-Authentifizierung für Artifact Registry konfigurieren

Wenn Sie eine Verbindung zu Artifact Registry herstellen, sind Anmeldedaten erforderlich, um Zugriff zu gewähren. Anstatt separate Anmeldedaten einzurichten, können Sie Docker so konfigurieren, dass Ihre gcloud-Anmeldedaten nahtlos verwendet werden.

Führen Sie in Cloud Shell den folgenden Befehl aus, um Docker so zu konfigurieren, dass die Google Cloud CLI zum Authentifizieren von Anfragen an Artifact Registry in der Region us-central1 verwendet wird:

gcloud auth configure-docker us-central1-docker.pkg.dev

Wenn Sie nach dem Ausführen des Befehls aufgefordert werden, die Docker-Konfiguration von Cloud Shell zu bestätigen, drücken Sie die Eingabetaste.

Beispielanwendung ansehen

Eine Beispielanwendung finden Sie im Git-Repository, das Sie in einem früheren Schritt geklont haben. Wechseln Sie in das Verzeichnis „java“ und sehen Sie sich den Anwendungscode an.

cd java-docs-samples/run/helloworld/
ls

Der Ordner enthält eine Beispiel-Java-Anwendung, die eine einfache Webseite rendert. Neben verschiedenen Dateien, die für dieses Lab nicht relevant sind, enthält er den Quellcode im Ordner src und ein Dockerfile, mit dem wir ein Container-Image erstellen.

Container-Image erstellen

Bevor Sie Container-Images in Artifact Registry speichern können, müssen Sie eine erstellen.

Führen Sie den folgenden Befehl aus, um das Container-Image zu erstellen und mit dem vollständigen Pfad zur Artifact Registry zu taggen:

docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1 .

Container-Image per Push an Artifact Registry übertragen

Führen Sie den folgenden Befehl aus, um das Container-Image in das zuvor erstellte Repository zu pushen:

docker push us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:tag1

Image in Artifact Registry prüfen

Rufen Sie die Google Cloud Console – Artifact Registry – Repositories auf.. Öffnen Sie das container-example-Repository und prüfen Sie, ob das java-hello-world-Image vorhanden ist.

Klicken Sie auf das Bild und notieren Sie sich das Bild, das mit tag1 getaggt ist. Da wir das automatische Scannen von Images über den containerscanning.googleapis.com-Dienst aktiviert haben, sehen Sie, dass das Scannen auf Sicherheitslücken entweder läuft oder bereits abgeschlossen ist. Sobald der Vorgang abgeschlossen ist, sehen Sie die Anzahl der Sicherheitslücken, die für diese Image-Version erkannt wurden. Im nächsten Abschnitt gehen wir auf Sicherheitslücken und andere Informationen zu Artefakten ein.

4. Container-Images prüfen

Nachdem Sie Ihr erstes Image in das container-example-Repository gepusht haben, können wir uns das genauer ansehen. Klicken Sie auf dem Tab „Versionen“ auf die Version, die Sie gerade erstellt haben. So zeigen Sie das Bild in größerem Detail an:

Die obere Schaltfläche „Kopieren“ ist besonders nützlich, da sie eine einfache Möglichkeit bietet, auf den vollständig qualifizierten Image-URI für diese Image-Version einschließlich des SHA-Hashs zuzugreifen. Dieser URI kann dann verwendet werden, um eine bestimmte Imageversion abzurufen oder als Imagereferenz in einer Kubernetes-Bereitstellung oder einem Cloud Run-Dienst. Zum Testen des Image-URI können Sie in Cloud Shell den folgenden Befehl ausführen:

docker pull $IMAGE_URI

Abhängigkeiten

Auf dem Tab „Abhängigkeiten“ oben sehen Sie alle Abhängigkeiten, die in Ihrem Bild erkannt wurden. Beachten Sie, dass sowohl die Sprachabhängigkeiten als auch die Betriebssystemabhängigkeiten aufgeführt sind. Außerdem sehen Sie die Softwarelizenzen, die mit den einzelnen Abhängigkeiten verknüpft sind.

Wenn Sie genau hinsehen, sehen Sie, dass die SBOM-Informationen noch nicht ausgefüllt sind. Um die SOM für Ihr Artefakt zu füllen, können Sie den folgenden Befehl in Cloud Shell mit dem vollqualifizierten Image-URI ausführen, den Sie oben in der Breadcrumb-Leiste kopieren können.

gcloud artifacts sbom export --uri $IMAGE_URI

Wenn Sie die Seite aktualisieren, enthält sie jetzt einen Link zur automatisch generierten SBOM, die in Cloud Storage gespeichert ist. Wenn Sie SBOMs für Ihre Images verwenden, sollten Sie SBOMs für Ihre Artefakte automatisch generieren und die Generierung in Ihre CI/CD-Pipeline einbinden.

Image-Sicherheitslücken

Wenn Sie oben in der Ansicht auf den Tab „Sicherheitslücken“ klicken, sehen Sie alle Sicherheitslücken, die in Ihrem Bild erkannt wurden. Zusätzlich zur Zusammenfassung der Sicherheitslücken oben finden Sie in der Tabelle unten eine vollständige Liste der Sicherheitslücken. Jede Zeile enthält einen Link zum CVE-Bulletin mit Informationen zur Schwere und zum Paket, aus dem die Sicherheitslücke stammt. Bei Sicherheitslücken, für die ein Fix verfügbar ist, wird auch eine Anleitung zum Aktualisieren der Abhängigkeiten zur Behebung der Sicherheitslücke bereitgestellt.

5. Virtuelle und Remote-Repositories

Im vorherigen Abschnitt haben wir ein einzelnes Image-Repository zum Pushen und Pullen unserer Images verwendet. Das funktioniert gut für kleine Anwendungsfälle, stellt aber vor allem größere Organisationen mit verschiedenen Teams vor Herausforderungen, die Autonomie über ihre Repositories benötigen. Es ist üblich, dass Teams oder Geschäftsbereiche ein eigenes Image-Repository mit eigenen Berechtigungen und Konfigurationen haben. Um die Verwendung der Images in diesen Repositories zu vereinfachen und den Nutzer vor der zugrunde liegenden Organisationsstruktur zu schützen, bietet Artifact Registry virtuelle Repositories, in denen Ressourcen aus mehreren zugrunde liegenden Repositories zusammengefasst werden können. Eine mögliche Architektur könnte so aussehen:

Remote-Repository für Docker Hub

Docker Hub ist eine beliebte öffentliche Image-Registry und beherbergt viele Open-Source-Container-Images. Die direkte Verwendung des öffentlichen Repositorys ist zwar unkompliziert, bringt aber in einer Produktionsumgebung eine Reihe von Herausforderungen mit sich, die wir mit Remote-Repositories in Artifact Registry überwinden können.

Mit Remote-Repositories können Sie die Anfragen an die vorgelagerte Registry weiterleiten und dabei Images im Cache speichern. Dadurch werden nicht nur die Downloadzeiten der Bilder verkürzt, sondern auch die Abhängigkeit von der Uptime des externen Dienstes aufgehoben. Außerdem können Sie dieselben Sicherheits- und Zugriffsrichtlinien anwenden, die Sie auch auf Ihre eigenen Bilder anwenden.

Führen Sie in Cloud Shell den folgenden Befehl aus, um ein Remote-Repository für Docker Hub zu erstellen:

gcloud artifacts repositories create dockerhub \
  --repository-format=docker \
  --mode=remote-repository \
  --remote-docker-repo=docker-hub \
  --location=us-central1 \
  --description="Example Remote Repo for Docker Hub"

In der Liste der Artifact Registry-Repositories sollte jetzt ein zusätzliches Repository angezeigt werden:

Führen Sie den folgenden Befehl in Cloud Shell aus, um das nginx-Image abzurufen und zu testen, ob Ihr Remote-Repository Proxy-Anfragen an das Remote-Repository weiterleiten kann:

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/dockerhub/nginx:stable-alpine

Sobald der Pull erfolgreich war, können Sie sich das Repository auch in der Cloud Console ansehen. Das im Cache gespeicherte nginx-Image enthält jetzt dieselben Abhängigkeits- und Sicherheitslückenberichte wie das von Ihnen erstellte Image.

Virtuelles Repository erstellen

Wenn Sie die bisher beschriebenen Prozesse befolgen, können Sie für jedes Team oder Unternehmen eine Reihe von Repositories erstellen und für jedes Inhaberschaft und IAM-Berechtigungen klar definieren. Wir können auch Proxys für Remote-Repositories erstellen, um die Verwendung von Drittanbieter-Images zu vereinfachen und sicherer zu machen. Der Nachteil dieser großen Anzahl von Repositories wird deutlich, wenn Sie die Perspektive auf die Nutzer dieser Bilder verlagern. Woher weiß ein Entwickler, welches Image-Repository er bei der Bereitstellung verwenden soll?

Um die Nutzung zu vereinfachen und die zugrunde liegenden Repositories hinter einer Abstraktionsschicht zu verbergen, können Sie mit dem folgenden Befehl in Cloud Shell ein virtuelles Repository in Artifact Registry erstellen:

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-artifactregistry.iam.gserviceaccount.com \
    --role roles/artifactregistry.reader

cat <<EOF > /tmp/upstream.json
[{
"id" : "hello-repo",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/container-example",
"priority" : 100
},{
"id" : "dockerhub",
"repository" : "projects/$PROJECT_ID/locations/us-central1/repositories/dockerhub",
"priority" : 101
}]
EOF

gcloud artifacts repositories create all-images \
    --repository-format=docker \
    --mode=virtual-repository \
    --location=us-central1 \
    --upstream-policy-file=/tmp/upstream.json \
    --description="Example Virtual Repo"

Wir können jetzt die Bilder aus dem virtuellen Repository abrufen, ohne die zugrunde liegende Struktur freizugeben. Sie können die folgenden Befehle in Cloud Shell ausführen, um zu prüfen, ob alles wie erwartet funktioniert:

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1

docker pull us-central1-docker.pkg.dev/$PROJECT_ID/all-images/nginx:stable-alpine

6. In Cloud Run bereitstellen

Nachdem wir die entsprechenden Repositories und Images eingerichtet haben, können wir sie jetzt in einer Bereitstellung verwenden. Um einen Beispielnutzungsfall zu veranschaulichen und die Bereitstellung zusätzlicher Infrastruktur zu vermeiden, stellen wir unseren Container in Cloud Run bereit. In der einfachsten Form kann die Bereitstellung durch Ausführen des folgenden Befehls in Cloud Shell erfolgen:

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1 \
  --allow-unauthenticated

Nach Abschluss der Bereitstellung wird die automatisch generierte URL angezeigt, unter der Sie auf Ihren Dienst zugreifen können.

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...
  OK Setting IAM Policy...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00001-wtc] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

Wenn Sie diese URL in einem neuen Browsertab öffnen, sollte die Meldung „Hello World“ angezeigt werden.

7. Sicherheit der Lieferkette stärken

Jetzt, da Ihr Container-Image in die Live-Bereitstellung übernommen wurde, ist es an der Zeit, zu überlegen, wie wir unsere End-to-End-Lieferkette stärken können. Im vorherigen Abschnitt haben wir uns angesehen, wie die Containeranalyse von Artifact Registry Einblicke in die Bibliotheken und Lizenzen bietet, die im Image verwendet werden. Es ist jedoch weiterhin möglich, dass böswillige Akteure schädliche Inhalte in Ihre Bilder einschleusen. In diesem Abschnitt erfahren Sie, wie wir mit dem SLSA-Framework eine Attestierung für die Build-Artefakte einführen und sogar kryptografische Signaturen der Artefakte selbst nutzen können, um sicherzustellen, dass nur vertrauenswürdige Artefakte in unserer Cloud Run-Laufzeit bereitgestellt werden können.

SLSA-Attestierung mit Cloud Build

Das SLSA-Framework bietet unterschiedliche Nachweisebenen für Supply-Chain-Artefakte. Die Spezifikation und Implementierung mag auf den ersten Blick entmutigend erscheinen, aber mit Cloud Build ist das Erstellen einer SLSA-Attestierung so einfach wie das Erstellen einer cloudbuild.yaml-Spezifikation mit requestedVerifyOption = VERIFIED.

Für unsere Anwendung können wir den folgenden Befehl in Cloud Shell ausführen, um eine cloudbuild.yaml-Datei im Ordner „helloworld“ zu erstellen.

cat <<EOF > cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', '\$_IMAGE_URI', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', '\$_IMAGE_URI']
images:
- '\$_IMAGE_URI'
options:
  requestedVerifyOption: VERIFIED
substitutions:
  _IMAGE_URI: us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:latest
EOF

Erstellen Sie jetzt einen neuen Cloud Build-Job, mit dem eine neue Version unseres Java-Hello-World-Images erstellt wird. Führen Sie dazu den folgenden Befehl in Cloud Shell aus.

gcloud builds submit --substitutions=_IMAGE_URI=us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build

Sobald der Build abgeschlossen ist, können wir in der Cloud Build-Benutzeroberfläche in der Google Cloud Console die SLSA-Ebene aufrufen, die wir erreicht haben. Öffnen Sie dazu den Build und sehen Sie sich die Build-Artefakte unter „Build-Zusammenfassung“ an. Auf dem Bild ist eine Schaltfläche zu sehen, über die Sie die „Sicherheitsstatistiken“ aufrufen können. Wenn Sie darauf klicken, sehen Sie die SLSA-Attestierung sowie die bekannten Berichte zu Sicherheitslücken, die wir bereits in der Benutzeroberfläche der Artifact Registry gesehen haben, als wir unseren lokalen Build gepusht haben.

Die SLSA-Herkunft für unser Image kann auch durch Ausführen des folgenden Befehls in Cloud Shell abgerufen werden:

gcloud artifacts docker images describe \
"us-central1-docker.pkg.dev/$PROJECT_ID/container-example/java-hello-world:cloud-build" \
 --show-provenance

Cloud Build-Herkunft mit Binärautorisierung erforderlich machen

Wäre es nicht toll, wenn wir mit der Cloud Build-Pipeline dafür sorgen könnten, dass alle Images, die wir in der Produktion bereitstellen, mit dieser programmierbaren und reproduzierbaren Build-Umgebung erstellt wurden?

Hier kommt die Binärautorisierung ins Spiel. Sie können einen Gatekeeper vor Ihre Container-Laufzeiten stellen, der das Container-Image prüft und die Existenz einer vertrauenswürdigen Attestierung bestätigt. Wenn keine Attestierung gefunden wird, werden je nach Konfiguration entweder Prüfprotokolleinträge erstellt oder die Bereitstellung wird vollständig blockiert.

Um die Standardkonfiguration der Binärautorisierung unseres Projekts so zu ändern, dass die von Cloud Run ausgestellte integrierte Attestierung erforderlich ist, führen wir in Cloud Shell den folgenden Befehl aus:

cat << EOF > /tmp/policy.yaml
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
  - projects/$PROJECT_ID/attestors/built-by-cloud-build
name: projects/$PROJECT_ID/policy
EOF

gcloud container binauthz policy import /tmp/policy.yaml

Hier können Sie natürlich auch eigene benutzerdefinierte Attestatoren hinzufügen. Dies fällt jedoch nicht in den Rahmen dieses Codelabs und wird als optionale außerschulische Hausaufgabe zur Verfügung gestellt.

Um die Binärautorisierung für unseren Cloud Run-Dienst zu erzwingen, führen wir in Cloud Shell den folgenden Befehl aus:

gcloud run services update hello-world \
  --region us-central1 \
  --binary-authorization=default

Testen wir, ob die Binärautorisierung richtig angewendet wird, indem wir das lokal erstellte Image noch einmal bereitstellen.

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:tag1 \
  --region us-central1

Wie erwartet sollten Sie eine Fehlermeldung erhalten, in der erklärt wird, warum das Image nicht bereitgestellt werden konnte. Sie sollte in etwa so aussehen:

Image us-central1-docker.pkg.dev/my-project/all-images/java-hello-world@sha256:71eebbf04bf7d1d023e5de5e18f786ea3b8b6411bf64c8def3301c71baca0518 denied by attestor projects/my-project/attestors/built-by-cloud-build: No attestations found that were valid and signed by a key trusted by the attestor

Um eine neue Version in unserem Cloud Run-Dienst bereitzustellen, müssen wir daher ein Image bereitstellen, das mit Cloud Build erstellt wurde.

gcloud run deploy hello-world \
  --image us-central1-docker.pkg.dev/$PROJECT_ID/all-images/java-hello-world:cloud-build \
  --region us-central1

Diesmal sollte die Bereitstellung erfolgreich sein und eine Meldung wie die folgende anzeigen:

Deploying container to Cloud Run service [hello-world] in project [my-project] region [us-central1]
OK Deploying... Done.                                                                      
  OK Creating Revision...                                                                  
  OK Routing traffic...                                                                    
Done.                                                                                      
Service [hello-world] revision [hello-world-00005-mq4] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-world-13746229022.us-central1.run.app

8. Java Maven-Sprachpakete verwalten

In diesem Abschnitt erfahren Sie, wie Sie ein Java-Repository in Artifact Registry einrichten, Pakete hochladen und in verschiedenen Anwendungen verwenden.

Maven-Paket-Repository erstellen

Führen Sie in Cloud Shell den folgenden Befehl aus, um ein Repository für Java-Artefakte zu erstellen:

gcloud artifacts repositories create java-repo \
    --repository-format=maven \
    --location=us-central1 \
    --description="Example Java Maven Repo"

Klicken Sie auf „Autorisieren“, wenn die Aufforderung zur Autorisierung von Cloud Shell angezeigt wird.

Rufen Sie die Google Cloud Console auf und gehen Sie zu Artifact Registry - Repositories (Artifact Registry - Repositories). Sehen Sie sich das neu erstellte Maven-Repository mit dem Namen java-repo an. Wenn Sie darauf klicken, sehen Sie, dass es derzeit leer ist.

Authentifizierung für Artifact Repository einrichten

Aktualisieren Sie mit dem folgenden Befehl den bekannten Speicherort für Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) mit den Anmeldedaten Ihres Nutzerkontos, damit sich der Artifact Registry-Anmeldedaten-Helper damit authentifizieren kann, wenn eine Verbindung zu Repositories hergestellt wird:

gcloud auth login --update-adc

Maven für Artifact Registry konfigurieren

Führen Sie den folgenden Befehl aus, um die Repository-Konfiguration zu drucken und sie dem Java-Projekt hinzuzufügen:

gcloud artifacts print-settings mvn \
    --repository=java-repo \
    --location=us-central1 | tee config.xml

Öffnen Sie die Datei „pom.xml“ im Cloud Shell-Editor. Führen Sie dazu im Verzeichnis „helloworld“ den folgenden Befehl in Cloud Shell aus:

cloudshell edit pom.xml

und fügen Sie die zurückgegebenen Einstellungen den entsprechenden Abschnitten in der Datei hinzu.

Aktualisieren Sie den Abschnitt distributionManagement.

<distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
</distributionManagement>

Aktualisieren Sie den Abschnitt Repositories.

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>

Aktualisieren Sie den Abschnitt extensions unter build.

   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.1.0</version>
     </extension>
   </extensions>

Hier ist ein Beispiel für die vollständige Datei. Ersetzen Sie <PROJECT> durch Ihre Projekt-ID.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.example.run</groupId>
 <artifactId>helloworld</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>jar</packaging>

 <parent>
   <groupId>com.google.cloud.samples</groupId>
   <artifactId>shared-configuration</artifactId>
   <version>1.2.0</version>
 </parent>
 <dependencyManagement>
   <dependencies>
     <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-dependencies</artifactId>
       <version>${spring-boot.version}</version>
       <type>pom</type>
       <scope>import</scope>
     </dependency>
   </dependencies>
 </dependencyManagement>
 <properties>
   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
   <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
   <maven.compiler.target>17</maven.compiler.target>
   <maven.compiler.source>17</maven.compiler.source>
   <spring-boot.version>3.2.2</spring-boot.version>
 </properties>
 <dependencies>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-test</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>org.junit.vintage</groupId>
     <artifactId>junit-vintage-engine</artifactId>
     <scope>test</scope>
   </dependency>
   <dependency>
     <groupId>junit</groupId>
     <artifactId>junit</artifactId>
     <scope>test</scope>
   </dependency>
 </dependencies>
 <!-- [START Artifact Registry Config] -->
 <distributionManagement>
   <snapshotRepository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </snapshotRepository>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
   </repository>
 </distributionManagement>

 <repositories>
   <repository>
     <id>artifact-registry</id>
     <url>artifactregistry://us-central1-maven.pkg.dev/<PROJECT>/java-repo</url>
     <releases>
       <enabled>true</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </repository>
 </repositories>
  <build>
   <extensions>
     <extension>
       <groupId>com.google.cloud.artifactregistry</groupId>
       <artifactId>artifactregistry-maven-wagon</artifactId>
       <version>2.2.0</version>
     </extension>
   </extensions>
 <!-- [END Artifact Registry Config] -->

   <plugins>
     <plugin>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-maven-plugin</artifactId>
       <version>${spring-boot.version}</version>
       <executions>
         <execution>
           <goals>
             <goal>repackage</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
     <plugin>
       <groupId>com.google.cloud.tools</groupId>
       <artifactId>jib-maven-plugin</artifactId>
       <version>3.4.0</version>
       <configuration>
         <to>
           <image>gcr.io/PROJECT_ID/helloworld</image>
         </to>
       </configuration>
     </plugin>
   </plugins>
 </build>
 </project>

Java-Paket in Artifact Registry hochladen

Wenn Artifact Registry in Maven konfiguriert ist, können Sie jetzt Java-JARs in Artifact Registry speichern, um sie für andere Projekte in Ihrer Organisation zu verwenden.

Führen Sie den folgenden Befehl aus, um Ihr Java-Paket in Artifact Registry hochzuladen:

mvn deploy

Java-Paket in Artifact Registry prüfen

Rufen Sie Cloud Console - Artifact Registry - Repositories auf. Klicken Sie auf java-repo und prüfen Sie, ob das Binärartefakt helloworld vorhanden ist:

9. Glückwunsch!

Herzlichen Glückwunsch, Sie haben das Codelab abgeschlossen.

Behandelte Themen

Repositories für Container und Sprachpakete erstellt
Verwaltete Container-Images mit Artifact Registry
Artifact Registry in Cloud Code eingebunden
Maven für die Verwendung der Artifact Registry für Java-Abhängigkeiten konfiguriert

Bereinigen

Führen Sie in Cloud Shell den folgenden Befehl aus, um das gesamte Projekt zu löschen:

gcloud projects delete $PROJECT_ID