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

1. Wenn das Ziel-Repository in Artifact Registry nicht vorhanden ist, erstellen Sie ein neues Repository.

2. Wenn sich Cloud Build und Ihr Repository in verschiedenen Projekten befinden oder Sie zum Ausführen von Builds ein benutzerdefiniertes Dienstkonto verwenden, gewähren Sie dem Build-Dienstkonto im Projekt mit den Repositories die Rolle „Artifact Registry-Schreiber“.

   Das Standard-Cloud Build-Dienstkonto hat Zugriff, um die folgenden Aktionen mit einem Repository im selben Google Cloud -Projekt auszuführen:

   • Artefakte hochladen und herunterladen
   • gcr.io-Repositories in Artifact Registry erstellen

Docker-Build konfigurieren

Nachdem Sie Berechtigungen für das Ziel-Repository erteilt haben, können Sie Ihren Build konfigurieren.

So konfigurieren Sie Ihren Build:

1. Fügen Sie in Ihrer Build-Konfigurationsdatei den Schritt zum Erstellen und Tagging des Images ein.

   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. Diese Herangehensweise ist sinnvoll, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Images für Repositories in verschiedenen Umgebungen wie Tests, Staging oder Produktion zu übertragen.

   • ${_LOCATION}, ${_REPOSITORY} und ${_IMAGE} sind nutzerdefinierte Platzhalter für den Speicherort, den Namen und das Bild des Repositorys. Die Werte für diese Variablen geben Sie zum Zeitpunkt des Builds an.

   • $PROJECT_ID ist eine Standardsubstitution, die von Cloud Build mit der Google Cloud -Projekt-ID für den Build aufgelöst wird.

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

2. Wenn Sie den Build ausführen möchten, geben Sie Werte für die benutzerdefinierten Substitutionen an. Mit diesem Befehl wird beispielsweise Folgendes ersetzt:

   • us-east1 für den Speicherort des Repositorys
   • my-repo für den Repository-Namen
   • my-image für den Bildnamen

   gcloud builds submit --config=cloudbuild.yaml \
     --substitutions=_LOCATION="us-east1",_REPOSITORY="my-repo",_IMAGE="my-image" .
   

Go-Build konfigurieren

Nachdem Sie Berechtigungen für das Ziel-Repository erteilt 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 Ihren Build:

1. Wenn Sie ein Go-Modul in Ihrem Build in Ihr Go-Repository hochladen möchten, fügen Sie Ihrer Build-Konfigurationsdatei die folgenden Schritte hinzu:

   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. Diese Herangehensweise ist sinnvoll, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Pakete für Repositories in verschiedenen Umgebungen wie Tests, Staging oder Produktion hochzuladen.

   • ${_LOCATION}, ${_REPOSITORY} und ${_MODULE_PATH} sind benutzerdefinierte Platzhalter für den Repository-Speicherort, den Repository-Namen und den Modulpfad. Die Werte für diese Variablen geben Sie zum Buildzeitpunkt an.

   • $PROJECT_ID und $TAG_NAME sind Standardsubstitutionen, die von Cloud Build durch Folgendes ersetzt werden:

     • $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.

2. Wenn Sie das Paket aus dem Go-Repository installieren möchten, fügen Sie Ihrer Build-Konfigurationsdatei die folgenden Schritte hinzu:

   • Fügen Sie der Datei .netrc einen regionalen Artifact Registry-Endpunkt an Ihrem Repository-Speicherort hinzu.
   • Führen Sie das Tool „Credential Helper“ aus, um OAuth-Tokens zu aktualisieren.
   • Führen Sie den Befehl go run aus: Sie können das auch in go build ändern, um das Modul zu kompilieren, in go test, um Tests auszuführen, oder in go mod tidy, um die Abhängigkeiten herunterzuladen.

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

3. Wenn Sie den Build ausführen möchten, geben Sie Werte für die benutzerdefinierten Substitutionen an. Mit diesem Befehl wird beispielsweise Folgendes ersetzt:

   • 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

Nachdem Sie Berechtigungen für das Ziel-Repository erteilt 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 Ihren Build:

1. Richten Sie die Authentifizierung für Maven ein. Achten Sie darauf, dass Sie in der Datei pom.xml das richtige Zielprojekt und Repository angeben.

2. 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']
   

3. Wenn die Build-Konfigurationsdatei fertig ist, starten Sie den Build mit dem folgenden Befehl:

   gcloud builds submit
   

Node.js-Build konfigurieren

Nachdem Sie Berechtigungen für das Ziel-Repository erteilt 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 Ihren Build:

1. Fügen Sie der Datei .npmrc in Ihrem Node.js-Projekt Ihr Artifact Registry-Repository hinzu. Sie befindet sich im Verzeichnis mit Ihrer package.json-Datei.

   @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. Durch die Verwendung von Bereichen können Sie Pakete immer aus dem richtigen Repository veröffentlichen und installieren.
   • PROJECT_ID ist die Projekt-ID Ihrer Google Cloud .
   • LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
   • REPOSITORY ist der Name des Repositorys.

2. Fügen Sie der Datei package.json in Ihrem Projekt ein Skript hinzu, das das Zugriffstoken für die Authentifizierung mit dem Repository aktualisiert.

   "scripts": {
    "artifactregistry-login": "npx google-artifactregistry-auth"
   }
   

1. 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-Ersetzung, 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 Berechtigungen für das Ziel-Repository erteilt 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 mit pip installiert wird.

Informationen zum Erstellen und Containerisieren einer Python-Anwendung und zum Pushen in ein Docker-Repository finden Sie in der Cloud Build-Dokumentation unter Python-Anwendungen erstellen.

So konfigurieren Sie Ihren Build:

1. Erstellen Sie im Verzeichnis mit der 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-Backend, das die Authentifizierung bei Artifact Registry für pip und Twine übernimmt.

2. Wenn Sie ein Python-Paket in Ihrem Build in Ihr Python-Repository hochladen möchten, fügen Sie Ihrer Build-Konfigurationsdatei die folgenden Schritte hinzu:

   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 wird im ersten Schritt Twine und das Artifact Registry-Keyring-Backend installiert. Im zweiten Schritt werden die erstellten Python-Dateien in das Unterverzeichnis dist hochgeladen. Passen Sie die Pfade zu requirements.txt und zu den erstellten Python-Dateien an, falls sie nicht mit dem Snippet übereinstimmen.

   Der Repositorypfad enthält Cloud Build-Ersetzungen. Diese Herangehensweise ist sinnvoll, wenn Sie dieselbe Build-Konfigurationsdatei verwenden möchten, um Pakete für Repositories in verschiedenen Umgebungen wie Tests, Staging oder Produktion hochzuladen.

   • ${_LOCATION} und ${_REPOSITORY} sind benutzerdefinierte Substitutionen für den Repository-Speicherort, den Repository-Namen und den Paketnamen. Die Werte für diese Variablen geben Sie zum Zeitpunkt der Erstellung an.

   • $PROJECT_ID ist eine Standardsubstitution, die von Cloud Build in die Google Cloud -Projekt-ID für den Build umgewandelt wird.

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

3. Wenn Sie das Paket aus dem Python-Repository installieren möchten, fügen Sie Ihrer Build-Konfigurationsdatei einen Schritt hinzu, mit dem der Befehl pip install ausgeführt wird.

     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}-Ersetzung für den Paketnamen.

   Hinweis: Ab Version 21.2 von pip können Sie das Flag --verbose oder -v bis zu dreimal verwenden, um zusätzliche Debug-Ausgaben zu erhalten. Wenn Sie beispielsweise die nächste Ebene der Debug-Details aufrufen möchten, verwenden Sie --verbose --verbose oder -vv.

4. Wenn Sie den Build ausführen möchten, geben Sie Werte für die benutzerdefinierten Substitutionen an. Mit diesem Befehl wird beispielsweise Folgendes ersetzt:

   • 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" .