Mit Cloud Build verbinden

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 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 Repositorys
- my-repo für den Repository-Namen
- my-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.
  - $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 Artifact Registry-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 in go build ändern, um das Modul zu kompilieren, go test, um Tests auszuführen, oder go mod tidy, um die Abhängigkeiten herunterzuladen.

Für den go-Befehlsschritt ist GOPROXY auf das Artifact Registry-Repository festgelegt, das private Abhängigkeiten hostet. Sie können den öffentlichen Proxy der durch Kommas getrennten Liste GOPROXY 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}'

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 Repositorys
- my-project für die Projekt-ID
- my-repo für den Repository-Namen
- example.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

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

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 Datei package.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

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 zu requirements.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.
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.

Hinweis: Verwenden Sie ab pip 21.2 bis zu dreimal das Flag --verbose oder -v, um eine zusätzliche Debugging-Ausgabe zu erhalten. Wenn Sie beispielsweise die nächste Ebene der Fehlerbehebungsdetails abrufen möchten, verwenden Sie --verbose --verbose oder -vv.
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 Repositorys
- my-repo für den Repository-Namen
- my-package für den Paketnamen
```
gcloud builds submit --config=cloudbuild.yaml \
  --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_PACKAGE="my-package" .
```