Auf dieser Seite wird beschrieben, wie Sie Cloud Build so konfigurieren, dass erstellte Artefakte in einem Artifact Registry-Repository gespeichert werden.
Hinweise
- Wenn das Ziel-Repository nicht in Artifact Registry vorhanden ist, erstellen Sie ein neues Repository.
Wenn sich Cloud Build und Ihr Repository in verschiedenen Projekten befinden oder Sie ein benutzerdefiniertes Dienstkonto zum Ausführen von Builds verwenden, weisen Sie dem Build-Dienstkonto im Projekt mit den Repositories die Rolle „Artifact Registry-Autor“ zu.
Das standardmäßige Cloud Build-Dienstkonto hat Zugriff zum Ausführen der folgenden Aktionen mit einem Repository im selben Google Cloud-Projekt:
- Artefakte hochladen und herunterladen
- gcr.io-Repositories in Artifact Registry erstellen
Docker-Build konfigurieren
Nachdem Sie dem Ziel-Repository Berechtigungen gewährt haben, können Sie Ihren Build konfigurieren.
So konfigurieren Sie den Build:
Fügen Sie der Build-Konfigurationsdatei den Schritt zum Erstellen und Taggen des Images hinzu.
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}', '.' ] images: - '${_LOCATION}-docker.pkg.dev/$PROJECT_ID/${_REPOSITORY}/${_IMAGE}'
In diesem Snippet werden Cloud Build-Substitutionen verwendet. Dieser Ansatz ist nützlich, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Images in Repositories für verschiedene Umgebungen wie Tests, Staging oder Produktion zu übertragen.
${_LOCATION}
,${_REPOSITORY}
und${_IMAGE}
sind benutzerdefinierte Ersatz für den Repository-Speicherort, den Repository-Namen und das Image. Die Werte für diese Variablen geben Sie bei der Erstellung an.$PROJECT_ID
ist eine Standardersetzung, die Cloud Build mit der Google Cloud-Projekt-ID für den Build auflöst.- Wenn Sie den Befehl
gcloud builds submit
ausführen, verwendet Cloud Build die aktive Projekt-ID in der gcloud-Sitzung. - Wenn Sie einen Build-Trigger verwenden, verwendet Cloud Build die ID des Projekts, in dem Cloud Build ausgeführt wird.
Alternativ können Sie anstelle von
$PROJECT_ID
eine benutzerdefinierte Substitution verwenden, um beim Build eine Projekt-ID anzugeben.- Wenn Sie den Befehl
Wenn Sie zum Ausführen des Builds bereit sind, geben Sie Werte für die benutzerdefinierten Substitutionen an. Dieser Befehl ersetzt beispielsweise:
us-east1
für den Speicherort des Repositorysmy-repo
für den Repository-Namenmy-image
für den Image-Namen
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_IMAGE="my-image" .
Go-Build konfigurieren
Nachdem Sie dem Ziel-Repository Berechtigungen gewährt haben, können Sie Ihren Build konfigurieren. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Build so konfigurieren, dass ein Go-Modul in ein Go-Repository hochgeladen wird.
So konfigurieren Sie den Build:
Fügen Sie der Build-Konfigurationsdatei die folgenden Schritte hinzu, um ein Go-Modul in das Go-Repository in Ihrem Build hochzuladen:
steps: - name: gcr.io/cloud-builders/gcloud args: - 'artifacts' - 'go' - 'upload' - '--project=$PROJECT_ID' - '--location=${_LOCATION}' - '--repository=${_REPOSITORY}' - '--module-path=${_MODULE_PATH}' - '--version=$TAG_NAME'
Die Build-Konfigurationsdatei enthält Cloud Build-Substitutionen. Dieser Ansatz ist nützlich, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Pakete für verschiedene Umgebungen wie Tests, Staging oder Produktion in Repositories hochzuladen.
${_LOCATION}
,${_REPOSITORY}
und${_MODULE_PATH}
sind benutzerdefinierte Substitutionen für den Speicherort des Repositorys, den Repository-Namen und den Modulpfad. Die Werte für diese Variablen geben Sie bei der Erstellung an.$PROJECT_ID
und$TAG_NAME
sind Standardersetzungen, die Cloud Build durch Folgendes ersetzt:$PROJECT_ID
wird durch die Google Cloud-Projekt-ID für den Build ersetzt.- Wenn Sie den Befehl
gcloud builds submit
ausführen, verwendet Cloud Build die aktive Projekt-ID in der gcloud-Sitzung. - Wenn Sie einen Build-Trigger verwenden, verwendet Cloud Build die ID des Projekts, in dem Cloud Build ausgeführt wird.
Alternativ können Sie anstelle von
$PROJECT_ID
eine benutzerdefinierte Substitution verwenden, um beim Build eine Projekt-ID anzugeben.- Wenn Sie den Befehl
$TAG_NAME
wird durch den Namen Ihres Tags ersetzt, um die Go-Konvention zur Verwendung von Git-Tags als Versionsnummern zu unterstützen.
Fügen Sie der Build-Konfigurationsdatei die folgenden Schritte hinzu, um das Paket aus dem Go-Repository zu installieren:
- Fügen Sie der Datei
.netrc
einen regionalen Cloud Build-Endpunkt am Speicherort Ihres Repositorys hinzu. - Führen Sie das Credential Helper-Tool aus, um OAuth-Tokens zu aktualisieren.
- Führen Sie den Befehl
go run
aus: Sie können dies auch ingo build
ändern, um das Modul zu kompilieren,go test
, um Tests auszuführen, odergo mod tidy
, um die Abhängigkeiten herunterzuladen.
Für den Befehlsschritt
go
istGOPROXY
auf das Cloud Build-Repository festgelegt, das private Abhängigkeiten hostet. Sie können den öffentlichen Proxy der durch Kommas getrennten ListeGOPROXY
hinzufügen, wenn das Modul öffentliche Abhängigkeiten hat.steps: - name: golang entrypoint: go args: ['run', 'github.com/GoogleCloudPlatform/artifact-registry-go-tools/cmd/auth@v0.1.0', 'add-locations', '--locations=${_LOCATION}'] env: # Set GOPROXY to the public proxy to pull the credential helper tool - 'GOPROXY=https://proxy.golang.org' - name: golang entrypoint: go args: ['run', 'github.com/GoogleCloudPlatform/artifact-registry-go-tools/cmd/auth@v0.1.0', 'refresh'] env: # Set GOPROXY to the public proxy to pull the credential helper tool - 'GOPROXY=https://proxy.golang.org' - name: golang entrypoint: go args: ['run', '.'] env: - 'GOPROXY=https://${_LOCATION}-go.pkg.dev/${_PROJECT_ID}/${_REPOSITORY}' options: env: # Disable GO sumdb checks for private modules. - 'GONOSUMDB=${_MODULE_PATH}'
- Fügen Sie der Datei
Wenn Sie zum Ausführen des Builds bereit sind, geben Sie Werte für die benutzerdefinierten Substitutionen an. Dieser Befehl ersetzt beispielsweise:
us-east1
für den Speicherort des Repositorysmy-project
für die Projekt-IDmy-repo
für den Repository-Namenexample.com/greetings
für den Modulpfad
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_PROJECT_ID="my-project",_REPOSITORY="my-repo",_MODULE_PATH="example.com/greetings" .
Java-Build konfigurieren
Nachdem Sie dem Ziel-Repository Berechtigungen gewährt haben, können Sie Ihren Build konfigurieren. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Build so konfigurieren, dass ein Java-Paket in ein Maven-Repository hochgeladen wird.
So konfigurieren Sie den Build:
Richten Sie die Authentifizierung für Maven ein. Achten Sie darauf, dass Sie in der Datei
pom.xml
das richtige Zielprojekt und Repository angeben.Fügen Sie Ihrer Cloud Build-Konfigurationsdatei einen Schritt hinzu, um das Paket mit Maven hochzuladen:
steps: - name: gcr.io/cloud-builders/mvn args: ['deploy']
Wenn die Build-Konfigurationsdatei fertig ist, starten Sie den Build mit dem folgenden Befehl:
gcloud builds submit
Node.js-Build konfigurieren
Nachdem Sie dem Ziel-Repository Berechtigungen gewährt haben, können Sie Ihren Build konfigurieren. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Build so konfigurieren, dass ein Node.js-Paket in ein npm-Repository hochgeladen wird.
So konfigurieren Sie den Build:
Fügen Sie Ihr Artifact Registry-Repository der Datei
.npmrc
in Ihrem Node.js-Projekt hinzu. Die Datei befindet sich im Verzeichnis mit der Dateipackage.json
.@SCOPE:registry=https://LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY //LOCATION-npm.pkg.dev/PROJECT_ID/REPOSITORY:always-auth=true
- SCOPE-NAME ist der Name des npm-Bereichs, der dem Repository zugeordnet werden soll. Mit Bereichen können Sie dafür sorgen, dass Pakete immer aus dem richtigen Repository veröffentlicht und installiert werden.
- PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
- LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
- REPOSITORY ist der Name des Repositorys.
Fügen Sie der Datei
package.json
in Ihrem Projekt ein Skript hinzu, das das Zugriffstoken zur Authentifizierung mit dem Repository aktualisiert."scripts": { "artifactregistry-login": "npx google-artifactregistry-auth" }
Fügen Sie den Schritt zum Hochladen des Pakets in das Repository in Ihre Build-Konfigurationsdatei ein.
steps: - name: gcr.io/cloud-builders/npm args: ['run', 'artifactregistry-login'] - name: gcr.io/cloud-builders/npm args: ['publish', '${_PACKAGE}']
${_PACKAGE}
ist eine Cloud Build-Substitution, die das Node.js-Projektverzeichnis darstellt. Sie können das Verzeichnis angeben, wenn Sie den Befehl zum Ausführen des Builds ausführen.Mit diesem Befehl wird das Paket beispielsweise aus einem Verzeichnis namens
src
hochgeladen:gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_PACKAGE="src" .
Python-Build konfigurieren
Nachdem Sie dem Ziel-Repository Berechtigungen gewährt haben, können Sie Ihren Build konfigurieren. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Build so konfigurieren, dass ein Python-Paket in ein Python-Repository hochgeladen und das Paket mithilfe von pip installiert wird.
Informationen zum Erstellen und Containerisieren einer Python-Anwendung und zum Hochladen in ein Docker-Repository finden Sie in der Cloud Build-Dokumentation unter Python-Anwendungen erstellen.
So konfigurieren Sie den Build:
Erstellen Sie im Verzeichnis mit Ihrer Cloud Build-Build-Konfigurationsdatei eine Datei namens
requirements.txt
mit den folgenden Abhängigkeiten:twine keyrings.google-artifactregistry-auth
- Twine dient zum Hochladen von Paketen in Artifact Registry.
- keyrings.google-artifactregistry-auth ist das Artifact Registry-Schlüsselbund-Back-End, das die Authentifizierung mit Artifact Registry für pip und Twine übernimmt.
Fügen Sie der Build-Konfigurationsdatei die folgenden Schritte hinzu, um ein Python-Paket in das Python-Repository in Ihrem Build hochzuladen:
steps: - name: python entrypoint: pip args: ["install", "-r", "requirements.txt", "--user"] - name: python entrypoint: python args: - '-m' - 'twine' - 'upload' - '--repository-url' - 'https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/' - 'dist/*'
In diesem Snippet werden im ersten Schritt Twine und das Artifact Registry-Schlüsselbund-Back-End installiert. Im zweiten Schritt werden Ihre erstellten Python-Dateien in das Unterverzeichnis
dist
hochgeladen. Passen Sie die Pfade zurequirements.txt
und Ihren erstellten Python-Dateien an, wenn sie nicht mit dem Snippet übereinstimmen.Der Repository-Pfad enthält Cloud Build-Substitutionen. Dieser Ansatz ist nützlich, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Pakete für verschiedene Umgebungen wie Tests, Staging oder Produktion in Repositories hochzuladen.
${_LOCATION}
und${_REPOSITORY}
sind benutzerdefinierte Substitutionen für den Speicherort des Repositorys, den Repository-Namen und den Paketnamen. Die Werte für diese Variablen geben Sie bei der Erstellung an.$PROJECT_ID
ist eine Standardersetzung, die Cloud Build mit der Google Cloud-Projekt-ID für den Build auflöst.- Wenn Sie den Befehl
gcloud builds submit
ausführen, verwendet Cloud Build die aktive Projekt-ID in der gcloud-Sitzung. - Wenn Sie einen Build-Trigger verwenden, verwendet Cloud Build die ID des Projekts, in dem Cloud Build ausgeführt wird.
Alternativ können Sie anstelle von
$PROJECT_ID
eine benutzerdefinierte Substitution verwenden, um beim Build eine Projekt-ID anzugeben.- Wenn Sie den Befehl
Fügen Sie der Build-Konfigurationsdatei einen Schritt hinzu, mit dem der Befehl
pip install
ausgeführt wird, um das Paket aus dem Python-Repository zu installieren.steps: - name: python entrypoint: pip args: - 'install' - '--index-url' - 'https://${_LOCATION}-python.pkg.dev/$PROJECT_ID/${_REPOSITORY}/simple/' - '${_PACKAGE}' - '--verbose'
Dieses Snippet enthält eine zusätzliche
${_PACKAGE}
-Substitution für den Paketnamen.Wenn Sie zum Ausführen des Builds bereit sind, geben Sie Werte für die benutzerdefinierten Substitutionen an. Dieser Befehl ersetzt beispielsweise:
us-east1
für den Speicherort des Repositorysmy-repo
für den Repository-Namenmy-package
für den Paketnamen
gcloud builds submit --config=cloudbuild.yaml \ --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_PACKAGE="my-package" .
Nächste Schritte
- Weitere Informationen zum Bereitstellen in Cloud Run
- Weitere Informationen zum Bereitstellen in Google Kubernetes Engine