Artifact Registry – Detailanalyse

1. Übersicht

Artifact Registry ist der vollständig verwaltete Paketmanager für OCI-Container-Images und Sprachpakete (wie Maven und npm). Er bietet ein einheitliches Tool zum Verwalten dieser Elemente.

Artifact Registry ist vollständig in die vielen anderen 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.
Sie stellt Images für die Containerlaufzeiten wie Cloud Run und GKE bereit und ermöglicht erweiterte Funktionen zur Leistungsoptimierung wie Image-Streaming.
Artifact Registry kann als Erkennungspunkt für die Artefaktanalyse dienen, um kontinuierlich nach bekannten Sicherheitslücken zu suchen.
Cloud IAM bietet eine konsistente und detaillierte Kontrolle über den Zugriff auf Artefakte und Berechtigungen.

In diesem Lab werden viele dieser Funktionen in Form einer praktischen Anleitung vorgestellt.

Lerninhalte

Was sind die Lernziele dieses Labs?

Verschiedene Repositories für Container und Sprachpakete erstellen
Container-Images mit Artifact Registry erstellen und verwenden
Sicherheitsstatus und Inhalt Ihrer Artefakte mit Artifact Registry analysieren
Artifact Registry für Java-Maven-Abhängigkeiten konfigurieren und verwenden

2. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

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 eines erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können sie jederzeit aktualisieren.
Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen Namen versuchen und sehen, ob er 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

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300$ teilnehmen.

gcloud einrichten

Legen Sie in Cloud Shell eine Projekt-ID und Projektnummer fest. Speichern Sie diese als die Variablen PROJECT_ID und PROJECT_NUMBER ab.

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 übertragen

Ein 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 weit verbreitete Standards. Es unterscheiden sich beispielsweise die Anfragen nach Maven-Abhängigkeiten von Anfragen nach 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, übergeben Sie das Flag --repository-format, um den Repository-Typ 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"

Wenn die Aufforderung zur Cloud Shell-Autorisierung angezeigt wird, klicken Sie auf „Autorisieren“.

Rufen Sie in der Google Cloud Console „Artifact Registry“ > „Repositories“ auf. Dort sehen Sie das neu erstellte Docker-Repository mit dem Namen container-example. Wenn Sie darauf klicken, sehen Sie, dass es noch leer ist.

Docker-Authentifizierung für Artifact Registry konfigurieren

Die Verbindung zu Artifact Registry erfordert Anmeldedaten, die den Zugriff ermöglichen. 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. Dadurch wird Docker so konfiguriert, 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 aufgefordert werden, die Änderung der Docker-Konfiguration für Cloud Shell zu bestätigen, drücken Sie die Eingabetaste.

Beispielanwendung ansehen

Im geklonten Git-Repository finden Sie eine Beispielanwendung. Wechseln Sie in das Java-Verzeichnis und sehen Sie sich den Anwendungscode an.

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

Der Ordner enthält als Beispiel eine Java-Anwendung, die eine einfache Webseite rendert. Neben verschiedenen Dateien, die für dieses Lab nicht relevant sind, ist im Ordner src der Quellcode enthalten, außerdem ein Dockerfile, mit dem wir ein Container-Image erstellen.

Das Container-Image erstellen

Damit Sie Container-Images in Artifact Registry speichern können, müssen Sie zuerst ein Repository erstellen.

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

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

Das Container-Image per Push an Artifact Registry übertragen

Führen Sie den folgenden Befehl aus, um das Container-Image per Push an das zuvor erstellte Repository zu übertragen:

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

Das 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 sehen Sie nach, ob es mit tag1 gekennzeichnet ist. Da wir das automatische Scannen von Bildern über den containerscanning.googleapis.com-Dienst aktiviert haben, sehen Sie, dass der Scan auf Sicherheitslücken entweder ausgeführt wird oder bereits abgeschlossen ist. Nach Abschluss des Scans sehen Sie die Anzahl der Sicherheitslücken, die für diese Image-Revision erkannt wurden. Im nächsten Abschnitt werden wir uns mit Sicherheitslücken und anderen Artefaktinformationen befassen.

4. Container-Images prüfen

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

Die obere Schaltfläche „Kopieren“ ist besonders nützlich, da sie einen einfachen Zugriff auf den vollständig qualifizierten Image-URI für diese Image-Version einschließlich des SHA-Hashs bietet. Dieser URI kann dann verwendet werden, um eine bestimmte Image-Version abzurufen oder als Image-Referenz in einem Kubernetes-Deployment oder einem Cloud Run-Dienst. Sie können den folgenden Befehl in Cloud Shell ausführen, um den Bild-URI zu testen:

docker pull $IMAGE_URI

Abhängigkeiten verstehen

Wenn Sie oben zum Tab „Abhängigkeiten“ wechseln, sehen Sie alle Abhängigkeiten, die im Bild erkannt wurden. Beachten Sie, dass sowohl die Abhängigkeiten auf Sprachebene als auch auf Betriebssystemebene aufgeführt sind. Sie können auch die Softwarelizenzen sehen, die an jede der Abhängigkeiten angehängt sind.

Wenn Sie genau hinsehen, können Sie erkennen, dass die SBOM-Informationen noch nicht ausgefüllt sind. Um die SOM für Ihr Artefakt zu erstellen, können Sie den folgenden Befehl in Cloud Shell ausführen. Verwenden Sie dazu den vollständig qualifizierten Image-URI, den Sie aus der Breadcrumb-Leiste oben kopieren können.

gcloud artifacts sbom export --uri $IMAGE_URI

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

Image-Sicherheitslücken untersuchen

Wenn Sie oben in der Ansicht auf den Tab „Sicherheitslücken“ klicken, sehen Sie alle Sicherheitslücken, die in Ihrem Image erkannt wurden. Zusätzlich zur Zusammenfassung der Sicherheitslücken oben finden Sie in der Tabelle unten die vollständige Liste der Sicherheitslücken. Jede Zeile enthält einen Link zum CVE-Bulletin, in dem der Schweregrad und das Paket angegeben sind, aus dem die CVE stammt. Für Sicherheitslücken, für die eine Korrektur 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 Bild-Repository verwendet, um unsere Bilder per Push- und Pull-Funktion zu übertragen. Dies funktioniert gut für kleine Anwendungsfälle, stellt aber insbesondere für größere Organisationen mit verschiedenen Teams, die Autonomie über ihre Repositorys benötigen, eine Herausforderung dar. Es ist üblich, dass Teams oder Geschäftsbereiche ihr 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 Imageregistry, in der viele Open-Source-Container-Images gehostet werden. Die direkte Verwendung des öffentlichen Repositorys ist zwar einfach, birgt aber in einer Produktionsumgebung eine Reihe von Herausforderungen, die wir mit Remote-Repositories in Artifact Registry bewältigen können.

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

Führen Sie den folgenden Befehl in Cloud Shell 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"

Sie sollten nun ein zusätzliches Repository in der Liste Ihrer Artifact Registry-Repositories sehen:

nginx

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

Nachdem das Pullen erfolgreich war, können Sie sich das Repository auch in der Cloud Console ansehen. Das im Cache gespeicherte Nginx-Image bietet jetzt dieselben Abhängigkeits- und Sicherheitslückenberichte wie das selbst erstellte Image.

Virtuelles Repository erstellen

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

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 die Bilder jetzt aus dem virtuellen Repository abrufen, ohne die zugrunde liegende Struktur offenzulegen. Führen Sie die folgenden Befehle in Cloud Shell aus, 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 die entsprechenden Repositories und Images vorhanden sind, können wir sie jetzt in einer Bereitstellung verwenden. Um einen Anwendungsfall zu veranschaulichen und die Bereitstellung zusätzlicher Infrastruktur zu vermeiden, stellen wir unseren Container in Cloud Run bereit. Die Bereitstellung kann in ihrer einfachsten Form 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, über die 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 erhöhen

Nachdem Ihr Container-Image in einer Live-Bereitstellung angekommen ist, ist es vielleicht an der Zeit, sich anzusehen, 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 im Image verwendeten Bibliotheken und Lizenzen bietet. Es ist jedoch weiterhin möglich, dass böswillige Akteure schädliche Inhalte in Ihr Image einschleusen. In diesem Abschnitt wird beschrieben, wie wir das SLSA-Framework verwenden können, um Attestierungen für die Build-Artefakte einzuführen und sogar kryptografische Signaturen der Artefakte selbst zu nutzen, um sicherzustellen, dass nur vertrauenswürdige Artefakte in unserer Cloud Run-Laufzeitumgebung bereitgestellt werden können.

SLSA-Attestierung mit Cloud Build

Das SLSA-Framework bietet verschiedene Beweisebenen für Supply-Chain-Artefakte. Die Spezifikation und Implementierung mögen auf den ersten Blick entmutigend erscheinen, aber mit Cloud Build ist das Erstellen von SLSA-Attestierungen so einfach wie das Hinzufügen einer cloudbuild.yaml-Spezifikation, bei der requestedVerifyOption auf VERIFIED gesetzt ist.

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

Wir erstellen jetzt einen neuen Cloud Build-Job, der eine neue Version unseres Java Hello World-Images erstellt. 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

Nachdem der Build abgeschlossen ist, können wir in der Google Cloud Console die Cloud Build-UI aufrufen und den erreichten SLSA-Level ansehen. Dazu öffnen wir den Build und sehen uns dann unter „Build Summary“ (Build-Zusammenfassung) die Build-Artefakte an. Das dort angezeigte Bild enthält eine Schaltfläche, über die Sie die „Sicherheitsstatistiken“ aufrufen können. Wenn Sie darauf klicken, sehen Sie die SLSA-Bestätigung sowie die bekannten Berichte zu Sicherheitslücken, die wir zuvor in der Artifact Registry-Benutzeroberfläche gesehen haben, als wir unseren lokalen Build übertragen haben.

Die SLSA-Herkunft für unser Image kann auch abgerufen werden, indem Sie den folgenden Befehl in Cloud Shell ausführen:

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

Cloud Build-Herkunftsnachweis mit Binärautorisierung erforderlich machen

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

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

Um die Standardkonfiguration der Binärautorisierung unseres Projekts so zu ändern, dass die integrierte Attestierung von Cloud Run erforderlich ist, führen wir den folgenden Befehl in Cloud Shell 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

Sie können hier natürlich auch eigene benutzerdefinierte Attestoren hinzufügen. Dies geht jedoch über den Rahmen dieses Codelabs hinaus und wird als optionale zusätzliche Übung betrachtet.

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

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

Wir testen, ob die Binärautorisierung richtig angewendet wird, indem wir das lokal erstellte Image zuerst 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

Sie sollten eine Fehlermeldung erhalten, in der erklärt wird, warum das Image nicht bereitgestellt werden konnte. Sie sieht in etwa so aus:

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

Wenn wir eine neue Version in unserem Cloud Run-Dienst bereitstellen möchten, 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

Die Bereitstellung sollte diesmal 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 Artifact Registry-Java-Repository einrichten und Pakete hochladen, die Sie in verschiedenen Anwendungen verwenden.

Maven-Package 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"

Wenn die Aufforderung zur Cloud Shell-Autorisierung angezeigt wird, klicken Sie auf „Autorisieren“.

Rufen Sie in der Google Cloud Console Artifact Registry > Repositories auf. Dort sehen Sie das neu erstellte Maven-Repository mit dem Namen java-repo. Wenn Sie darauf klicken, sehen Sie, dass es noch leer ist.

Authentifizierung für Artifact Repository einrichten

Verwenden Sie den folgenden Befehl, um den bekannten Speicherort für Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) mit den Anmeldedaten Ihres Nutzerkontos zu aktualisieren. Auf diese Weise kann sich der Credential Helper für Artifact Registry damit authentifizieren, wenn er eine Verbindung zu Repositories herstellt:

gcloud auth login --update-adc

Maven für Artifact Registry konfigurieren

Führen Sie den folgenden Befehl aus, um die Repository-Konfiguration auszugeben, die dem Java-Projekt hinzugefügt werden soll:

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

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

cloudshell edit pom.xml

Fügen Sie die zurückgegebenen Einstellungen in die entsprechenden Abschnitte der Datei ein.

Abschnitt distributionManagement aktualisieren

<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>

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>

Das Java-Paket in Artifact Registry hochladen

Nachdem Sie Artifact Registry in Maven konfiguriert haben, können Sie es verwenden, um von anderen Projekten in Ihrer Organisation verwendete Java-JARs zu speichern.

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

mvn deploy

Das Java-Paket in Artifact Registry prüfen

Rufen Sie die Cloud Console – Artifact Registry – Repositories auf. Klicken Sie auf java-repo und prüfen Sie, ob das binäre Artefakt 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 einbinden
Maven so konfiguriert, dass Artifact Registry für Java-Abhängigkeiten verwendet wird

Bereinigen

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

gcloud projects delete $PROJECT_ID