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.

Hinweis

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 unterschiedlichen Projekten befinden oder wenn Sie ein vom Nutzer angegebenes Dienstkonto Builds, die Artifact Registry-Rolle „Autor“ gewähren an das Build-Dienstkonto im Projekt mit den Repositories.

   Das Cloud Build-Standarddienstkonto hat Zugriffsrechte für folgende Aufgaben: die folgenden Aktionen mit einem Repository im selben Google Cloud-Projekt:

   • Artefakte hoch- 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 Ihren Build:

1. 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 möchten dieselbe Build-Konfigurationsdatei verwenden, um Images per Push in Repositories zu übertragen. für verschiedene Umgebungen wie Tests, Staging oder Produktion.

   • ${_LOCATION}, ${_REPOSITORY} und ${_IMAGE} sind nutzerdefinierte Platzhalter für den Speicherort, den Namen und das Bild des Repositorys. Sie geben die Werte für diese Variablen verfügbar sind.

   • $PROJECT_ID ist eine Standardsubstitution, die von Cloud Build in die 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 Projekt, in dem Cloud Build ausgeführt wird.

     Alternativ können Sie eine benutzerdefinierte Substitution verwenden $PROJECT_ID, damit Sie bei der Build-Erstellung eine Projekt-ID angeben können.

2. Wenn Sie bereit sind, den Build auszuführen, geben Sie Werte für die benutzerdefinierten Substitutionen. 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 Ihren Build:

1. Fügen Sie Folgendes hinzu, um ein Go-Modul in Ihr Go-Repository in Ihrem Build hochzuladen: Schritte zu Ihrer Build-Konfigurationsdatei:

   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 Substitutionen für Cloud Build. Dieser Ansatz ist nützlich, dieselbe Build-Konfigurationsdatei verwenden, um Pakete in Repositories für wie Test, Staging oder Produktion.

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

   • $PROJECT_ID und $TAG_NAME sind Standardersetzungen, die Cloud Build wird wie folgt 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 Projekt, in dem Cloud Build ausgeführt wird.

       Alternativ können Sie eine benutzerdefinierte Substitution verwenden $PROJECT_ID, damit Sie bei der Build-Erstellung eine Projekt-ID angeben können.

     • $TAG_NAME wird durch den Namen Ihres Tags ersetzt, um Go zu unterstützen zur Verwendung von Git-Tags als Versionsnummern.

2. Fügen Sie die folgenden Schritte hinzu, um das Paket aus dem Go-Repository zu installieren: Ihre Build-Konfigurationsdatei so:

   • Regionalen Artifact Registry-Endpunkt im Repository hinzufügen Speicherort in der Datei .netrc.
   • Führen Sie das Tool „Credential Helper“ aus, um OAuth-Tokens zu aktualisieren.
   • Führen Sie den Befehl go run aus: Sie können dies auch zu go build ändern, um Kompilieren Sie das Modul, go test, um Tests auszuführen, oder go mod tidy zum Herunterladen die Abhängigkeiten.

   Für den Befehlsschritt go ist GOPROXY auf das Artifact Registry-Repository festgelegt, das private Abhängigkeiten hostet. Sie können fügen Sie den öffentlichen Proxy der durch Kommas getrennten Liste GOPROXY hinzu, 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 bereit sind, den Build auszuführen, geben Sie Werte für die benutzerdefinierten Substitutionen. 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

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 die Konfiguration Ihres Builds beschrieben ein Node.js-Paket in ein npm-Repository hochzuladen.

So konfigurieren Sie Ihren Build:

1. Artifact Registry-Repository der Datei .npmrc in Node.js hinzufügen Projekt arbeiten. 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. Durch die Verwendung von Bereichen können Sie Pakete immer aus dem richtigen Repository veröffentlichen und installieren.
   • 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.

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

   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 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 Ihrer Build-Konfigurationsdatei für Cloud Build Folgendes: Datei namens requirements.txt mit den folgenden Abhängigkeiten:

   twine
   keyrings.google-artifactregistry-auth
   

   • Twine steht für Pakete in Artifact Registry hochladen.
   • keyrings.google-artifactregistry-auth ist das Artifact Registry-Schlüsselbund-Backend, das die Authentifizierung bei Artifact Registry für pip und Twine übernimmt.

2. Um ein Python-Paket in Ihr Python-Repository in Ihrem Build hochzuladen, fügen Sie den folgende Schritte in Ihre Build-Konfigurationsdatei ein:

   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-Schlüsselbund-Backend installiert. Im zweiten Schritt werden Ihre erstellten Python-Dateien in den dist-Unterverzeichnis. Passen Sie die Pfade zu requirements.txt und zu Ihren erstellten Python-Dateien an, falls sie nicht mit dem Snippet übereinstimmen.

   Der Repository-Pfad enthält Cloud Build Substitutionen Dieser Ansatz ist nützlich, dieselbe Build-Konfigurationsdatei verwenden, um Pakete in Repositories für wie Test, Staging oder Produktion.

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

   • $PROJECT_ID ist eine Standardersetzung den Cloud Build mit der Google Cloud-Projekt-ID auflöst für den Build.

     • 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 Projekt, in dem Cloud Build ausgeführt wird.

     Alternativ können Sie eine benutzerdefinierte Substitution verwenden $PROJECT_ID, damit Sie bei der Build-Erstellung eine Projekt-ID angeben können.

3. Fügen Sie Ihrem Build einen Schritt hinzu, um das Paket aus dem Python-Repository zu installieren Konfigurationsdatei, die den Befehl pip install ausführt.

     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 pip 21.2 müssen Sie das Flag --verbose oder -v mit bis zu drei für zusätzliche Debugging-Ausgabe. Wenn Sie beispielsweise die nächste Ebene der Debug-Details aufrufen möchten, verwenden Sie --verbose --verbose oder -vv.

4. Wenn Sie bereit sind, den Build auszuführen, geben Sie Werte für die benutzerdefinierten Substitutionen. 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" .