Diese Seite wurde von der Cloud Translation API übersetzt.

Build-Konfigurationsdatei erstellen

Auf dieser Seite wird beschrieben, wie Sie eine Build-Konfigurationsdatei erstellen, mit der Sie einen Build auf Cloud Build starten können.

Eine Build-Konfigurationsdatei definiert die Felder, die Cloud Build zur Ausführung Ihrer Aufgaben benötigt. Sie benötigen eine Build-Konfigurationsdatei, um Builds mit dem gcloud-Befehlszeilentool oder mit Build-Triggern zu starten. Sie können die Build-Konfigurationsdatei in der YAML- oder in der JSON-Syntax schreiben.

Hinweise

Unter Build-Konfiguration – Übersicht erfahren Sie mehr über die Felder, die Sie in einer Build-Konfigurationsdatei verwenden können.

Build-Konfiguration erstellen

In den folgenden Schritten wird erläutert, wie Sie eine einfache Build-Konfigurationsdatei erstellen. Jedes der Felder in der Build-Konfigurationsdatei definiert einen Teil der Aufgabe, die Sie ausführen möchten. Das einzige Pflichtfeld in der Build-Konfigurationsdatei ist das Feld name innerhalb eines Schritts. Alle anderen sind optional.

YAML

Build-Konfigurationsdatei erstellen: Erstellen Sie im Stammverzeichnis des Projekts eine Konfigurationsdatei mit dem Namen cloudbuild.yaml. Dies ist die Konfigurationsdatei für Cloud Build.
Feld "steps" hinzufügen: Der Abschnitt steps in der Build-Konfigurationsdatei enthält die Build-Schritte, die von Cloud Build ausgeführt werden sollen.
```
steps:
```
Ersten Schritt hinzufügen: Fügen Sie unter steps: ein Feld name hinzu, das zum Ausführen Ihrer Aufgabe auf ein Container-Image verweist. Cloud Build und dessen Entwicklercommunity stellen mehrere Containerimages bereit, in denen häufig genutzte Tools und Sprachen installiert sind. Sie können jedes dieser Images (auch Cloud Builder genannt) oder jedes öffentlich verfügbare Image in einem Build-Schritt verwenden. Informationen zu den verschiedenen Arten von Container-Images, die Sie in einem Build-Schritt verwenden können, finden Sie unter Cloud-Builder.

Das folgende Snippet zeigt einen Build-Schritt mit einem docker-Builder gcr.io/cloud-builders/docker, bei dem es sich um ein Container-Image handelt, auf dem Docker ausgeführt wird.
```
steps:
- name: 'gcr.io/cloud-builders/docker'
```
Schrittargumente hinzufügen: Im Feld args eines Schritts wird eine Liste von Argumenten abgerufen und an den Builder übergeben, auf den im Feld name verwiesen wird. Wenn der Builder im Feld name einen Einstiegspunkt hat, wird für den Zugriff auf diesen Einstiegspunkt args verwendet. Wenn der Builder im Feld name keinen Einstiegspunkt hat, wird als Einstiegspunkt das erste Element in args verwendet.

Im folgenden Beispiel gilt:
- build ist der Einstiegspunkt für den Docker Cloud Builder.
- -t ist das Docker-Tag.
- us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image ist der Name des Images, das in Artifact Registry erstellt werden soll. Im Build-Schritt wird die Standardsubstitution für die Projekt-ID verwendet. Daher wird dieser Wert bei der Build-Erstellung automatisch ersetzt.
- . ist der Speicherort des Quellcodes, der angibt, dass sich der Quellcode im aktuellen Arbeitsverzeichnis befindet.
```
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image', '.']
```
Weitere Schritte hinzufügen: Sie können die Build-Konfigurationsdatei um eine beliebige Anzahl von Build-Schritten erweitern. Dazu fügen Sie zusätzliche Felder vom Typ name ein, die auf Cloud-Builder verweisen.

Das folgende Snippet enthält zwei weitere Schritte in der Build-Konfigurationsdatei:
- Einen Docker-Build-Schritt zum Aufrufen des Befehls docker push, der das im vorherigen Schritt erstellte Image per Push in Artifact Registry überträgt.
- Einen Build-Schritt für den Google Cloud SDK-Befehl mit dem angegebenen Einstiegspunkt gcloud, der eine Compute Engine-Instanz aus dem Container-Image in Artifact Registry erstellt. Das Feld env dient dazu, die Compute Engine-Zone und -Region anzugeben.
```
 - name: 'gcr.io/cloud-builders/docker'
   args: ['push', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image']
 - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
   entrypoint: 'gcloud'
   args: ['compute', 'instances', 'create-with-container', 'my-vm-name', '--container-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image']
   env:
   - 'CLOUDSDK_COMPUTE_REGION=us-central1'
   - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'
```

Zusätzliche Build-Konfigurationsfelder hinzufügen: Sie können die Build-Konfiguration auch um zusätzliche Felder wie machineType, tags oder timeout erweitern. Unter Build-Konfiguration – Übersicht werden alle Felder beschrieben, die Sie in der Build-Konfigurationsdatei verwenden können.

Im folgenden Beispiel wird der Build-Schritt gcr.io/google.com/cloudsdktool/cloud-sdk nach 240 Sekunden beendet.

  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    timeout: 240s
    args: ['compute', 'instances', 'create-with-container', 'my-vm-name', '--container-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image']
    env:
    - 'CLOUDSDK_COMPUTE_REGION=us-central1'
    - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'

Das folgende Snippet zeigt ein umfassendes Beispiel für eine einfache Build-Konfigurationsdatei:

steps:
  # Docker Build
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t',
           'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage',
           '.']

  # Docker Push
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push',
           'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage']

  # Entrypoint, timeout and environment variables
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    timeout: 240s
    args: ['compute', 'instances',
           'create-with-container', 'my-vm-name',
           '--container-image',
           'us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage']
    env:
      - 'CLOUDSDK_COMPUTE_REGION=us-central1'
      - 'CLOUDSDK_COMPUTE_ZONE=us-central1-a'

In diesem Beispiel werden Container-Images in Artifact Registry gespeichert. Wenn Ihr Build Artefakte außerhalb des Containers erzeugt, können Sie diese mit dem Feld artifacts in Cloud Storage speichern. Eine Anleitung dazu finden Sie unter Images und Artefakte speichern.

JSON

Build-Konfigurationsdatei erstellen: Erstellen Sie im Stammverzeichnis des Projekts eine Konfigurationsdatei mit dem Namen cloudbuild.json. Dies ist die Konfigurationsdatei für Cloud Build.
Feld "steps" hinzufügen: Der Abschnitt steps in der Build-Konfigurationsdatei enthält die Build-Schritte, die von Cloud Build ausgeführt werden sollen.
```
{
   "steps":
}
```
Ersten Schritt hinzufügen: Fügen Sie unter steps: ein Feld name hinzu, das zum Ausführen Ihrer Aufgabe auf ein Container-Image verweist. Cloud Build und dessen Entwicklercommunity stellen mehrere Containerimages bereit, in denen häufig genutzte Tools und Sprachen installiert sind. Sie können jedes dieser Images (auch Cloud Builder genannt) oder jedes öffentlich verfügbare Image in einem Build-Schritt verwenden. Informationen zu den verschiedenen Arten von Container-Images, die Sie in einem Build-Schritt verwenden können, finden Sie unter Cloud-Builder.

Das folgende Snippet zeigt einen Build-Schritt mit einem docker-Builder gcr.io/cloud-builders/docker, bei dem es sich um ein Container-Image handelt, auf dem Docker ausgeführt wird.
```
{
   "steps": [
      {
         "name": "gcr.io/cloud-builders/docker"
      }
   ]
}
```
Schrittargumente hinzufügen: Im Feld args eines Schritts wird eine Liste von Argumenten abgerufen und an den Builder übergeben, auf den im Feld name verwiesen wird. Wenn der Builder im Feld name einen Einstiegspunkt hat, wird für den Zugriff auf diesen Einstiegspunkt args verwendet. Wenn der Builder im Feld name keinen Einstiegspunkt hat, wird als Einstiegspunkt das erste Element in args verwendet.

Im folgenden Beispiel gilt:
- build ist der Einstiegspunkt für den Docker Cloud Builder.
- -t ist das Docker-Tag.
- us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/my-image ist der Name des Images, das in Artifact Registry erstellt werden soll. Im Build-Schritt wird die Standardsubstitution für die Projekt-ID verwendet. Daher wird dieser Wert bei der Build-Erstellung automatisch ersetzt.
- . ist der Speicherort des Quellcodes, der angibt, dass sich der Quellcode im aktuellen Arbeitsverzeichnis befindet.
```
{
   "steps": [
      {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
            "build",
            "-t",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage",
            "."
         ]
      }
   ]
}
```
Weitere Schritte hinzufügen: Sie können die Build-Konfigurationsdatei um eine beliebige Anzahl von Build-Schritten erweitern. Dazu fügen Sie zusätzliche Felder vom Typ name ein, die auf Cloud-Builder verweisen.

Das folgende Snippet enthält zwei weitere Schritte in der Build-Konfigurationsdatei:
- Einen Docker-Build-Schritt zum Aufrufen des Befehls docker push, der das im vorherigen Schritt erstellte Image per Push in Artifact Registry überträgt.
- Einen Build-Schritt für den Google Cloud SDK-Befehl mit dem angegebenen Einstiegspunkt gcloud, der eine Compute Engine-Instanz aus dem Container-Image in Artifact Registry erstellt. Das Feld env dient dazu, die Compute Engine-Zone und -Region anzugeben.
```
      {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
            "push",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage"
         ]
      },
      {
         "name": "gcr.io/google.com/cloudsdktool/cloud-sdk",
         "entrypoint": "gcloud",
         "args": [
            "compute",
            "instances",
            "create-with-container",
            "my-vm-name",
            "--container-image",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage"
         ],
         "env": [
            "CLOUDSDK_COMPUTE_REGION=us-central1",
            "CLOUDSDK_COMPUTE_ZONE=us-central1-a"
         ]
      }
```

Im folgenden Beispiel wird der Build-Schritt gcr.io/google.com/cloudsdktool/cloud-sdk nach 240 Sekunden beendet.

      {
         "name": "gcr.io/google.com/cloudsdktool/cloud-sdk",
         "entrypoint": "gcloud",
         "timeout": "240s",
         "args": [
            "compute",
            "instances",
            "create-with-container",
            "my-vm-name",
            "--container-image",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage"
         ],
         "env": [
            "CLOUDSDK_COMPUTE_REGION=us-central1",
            "CLOUDSDK_COMPUTE_ZONE=us-central1-a"
         ]
      }

Das folgende Snippet zeigt ein umfassendes Beispiel für eine einfache Build-Konfigurationsdatei:

{
   "steps": [
      {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
            "build",
            "-t",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage",
            "."
         ]
      },
      {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
            "push",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage"
         ]
      },
      {
         "name": "gcr.io/google.com/cloudsdktool/cloud-sdk",
         "entrypoint": "gcloud",
         "timeout": "240s",
         "args": [
            "compute",
            "instances",
            "create-with-container",
            "my-vm-name",
            "--container-image",
            "us-central1-docker.pkg.dev/${PROJECT_ID}/my-docker-repo/myimage"
         ],
         "env": [
            "CLOUDSDK_COMPUTE_REGION=us-central1",
            "CLOUDSDK_COMPUTE_ZONE=us-central1-a"
         ]
      }
   ]
}

Nächste Schritte

Builds manuell ausführen und Builds mit Build-Triggern automatisieren
Build-Konfigurationen schreiben, um Abhängigkeiten zu berücksichtigen und Artefakte zu erstellen, zu testen und bereitzustellen