Artefakte in Artifact Registry speichern

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 Cloud Build-Standarddienstkonto hat Zugriffsrechte für folgende Aufgaben: die 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 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. 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 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.

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 die Konfiguration Ihres Builds beschrieben um ein Go-Modul in ein Go-Repository hochzuladen.

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 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 benutzerdefiniert Substitutionen für Repository-Speicherort, Repository-Name und Modul Pfad. Sie geben die Werte für diese Variablen bei der Erstellung 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 in der gcloud-Sitzung die aktive Projekt-ID.
       • Wenn Sie einen Build-Trigger verwenden, verwendet Cloud Build die ID des Projekt, 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 Go zu unterstützen zur Verwendung von Git-Tags als Versionsnummern.

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 Cloud Build-Endpunkt an Ihrem Repositoryspeicherort 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 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 go-Befehlsschritt wird GOPROXY auf die Cloud Build-Repository, 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 den Build ausführen möchten, 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

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. Mit Bereichen können Sie Pakete aus dem richtigen Repository zu veröffentlichen und zu 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 ein Cloud Build Substitution, die Ihr Node.js-Projekt darstellt -Verzeichnis. 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 die Konfiguration Ihres Builds beschrieben ein Python-Paket in ein Python-Repository hochladen und das Paket mit pip.

Um eine Python-Anwendung zu erstellen und zu containerisieren und sie anschließend per Push an einen Docker-Repository finden Sie unter Python-Anwendungen erstellen in der Cloud Build-Dokumentation.

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 steht für Pakete in Artifact Registry hochladen.
   • keyrings.google-artifactregistry-auth ist das Artifact Registry-Schlüsselbund-Back-End, Artifact Registry für pip und Twine authentifiziert.

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-Schlüsselbund-Backend installiert. Im zweiten Schritt werden die erstellten Python-Dateien in das Unterverzeichnis dist hochgeladen. Passe die Pfade zu requirements.txt und deinem Python-Dateien erstellt werden, wenn diese 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 die Repository-Speicherort, Repository-Name und Paketname. Sie geben die Werte für diese Variablen bei der Erstellung festlegen.

   • $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 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 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-package für den Paketnamen

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

Nächste Schritte

• Mehr zum Bereitstellen in Cloud Run
• Mehr zum Bereitstellen in Google Kubernetes Engine