Gestalten Sie die Zukunft der Softwarebereitstellung und tragen Sie Ihre Stimme durch. Nehmen Sie dazu den 2021 der DevOps-Umfrage an.

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

Vorbereitung

Build-Konfiguration erstellen

In den folgenden Schritten wird erläutert, wie Sie eine einfache Build-Konfigurationsdatei erstellen. Jedes der Felder in der 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 Felder sind optional.

YAML

  1. Build-Konfigurationsdatei erstellen: Erstellen Sie im Stammverzeichnis des Projekts eine Konfigurationsdatei mit dem Namen cloudbuild.yaml. Dies ist die Build-Konfigurationsdatei für Cloud Build.

  2. 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:
    
  3. 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 Container-Images bereit, in denen häufig genutzte Tools und Sprachen installiert sind. Sie können in einem Build-Schritt eines dieser Images (auch als Cloud-Builder bezeichnet) oder ein öffentlich verfügbares Image 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'
    
  4. 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 der Listeneintrag 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
    • gcr.io/my-project/my-image ist der Name des Images, das erstellt werden soll
    • . ist der Speicherort des Quellcodes

      steps:
      - name: 'gcr.io/cloud-builders/docker'
        args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
      
  5. Zusätzliche Felder für den Schritt hinzufügen. Sie können im Rahmen der Konfiguration Ihren Build-Schritt auch um weitere Felder wie Umgebungsvariablen und Arbeitsverzeichnisse erweitern. Eine Beschreibung aller Felder, die Sie in einem Build-Schritt verwenden können, finden Sie unter Build-Schritte.

    Im folgenden Beispiel ist das Feld timeout enthalten, um anzugeben, dass der Schritt docker nach 500 Sek. zu einer Zeitüberschreitung führen muss:

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
      timeout: 500s
    
  6. 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 Container Registry überträgt.
    • Einen kubectl-Build-Schritt zum Aufrufen des Befehls kubectl set image, der das Image in einem Kubernetes Engine-Cluster bereitstellt. Das Feld env ist enthalten, um die Compute Engine-Zone und den Kubernetes Engine-Cluster anzugeben.

      steps:
      - name: 'gcr.io/cloud-builders/docker'
        args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
        timeout: 500s
      - name: 'gcr.io/cloud-builders/docker'
        args: ['push', 'gcr.io/my-project/my-image']
      - name: 'gcr.io/cloud-builders/kubectl'
        args: ['set', 'image', 'deployment/my-deployment', 'my-container=gcr.io/my-project/my-image']
        env:
        - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
        - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
      
  7. Zusätzliche Build-Konfigurationen hinzufügen: Sie können die Build-Konfiguration auch um zusätzliche Felder wie machineType und tags erweitern. Im Überblick über Build-Konfigurationen werden alle Felder beschrieben, die Sie in der Build-Konfigurationsdatei verwenden können.

    Im anschließenden Beispiel werden die folgenden Felder zum Build hinzugefügt:

    • machineType gibt die VM-Größe an, mit der der Build ausgeführt wird.
    • timeout gibt an, wann der Build aufgrund der Überschreitung des Zeitlimits beendet wird.
    • tags zum Hinzufügen von Anmerkungen zum Build.

      steps:
      - name: 'gcr.io/cloud-builders/docker'
        args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
        timeout: 500s
      - name: 'gcr.io/cloud-builders/docker'
        args: ['push', 'gcr.io/my-project/my-image']
      - name: 'gcr.io/cloud-builders/kubectl'
        args: ['set', 'image', 'deployment/my-deployment', 'my-container=gcr.io/my-project/my-image']
        env:
        - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
        - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
      options:
          machineType: 'N1_HIGHCPU_8'
      timeout: 660s
      tags: ['mytag1', 'mytag2']
      
  8. Erstellte Images und Artefakte speichern. Wenn Ihr Build Container-Images erzeugt, können Sie diese in Container Registry speichern. Dazu können Sie das Feld images verwenden.

    Im folgenden Beispiel wird das im Docker-Schritt erstellte Image in Container Registry gespeichert:

    steps:
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
      timeout: 500s
    - name: 'gcr.io/cloud-builders/docker'
      args: ['push', 'gcr.io/my-project/my-image']
    - name: 'gcr.io/cloud-builders/kubectl'
      args: ['set', 'image', 'deployment/my-deployment', 'my-container=gcr.io/my-project/my-image']
      env:
      - 'CLOUDSDK_COMPUTE_ZONE=us-east4-b'
      - 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster'
    options:
        machineType: 'N1_HIGHCPU_8'
    timeout: 660s
    tags: ['mytag1', 'mytag2']
    images: ['gcr.io/my-project/myimage']
    

    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

  1. Build-Konfigurationsdatei erstellen: Erstellen Sie im Stammverzeichnis des Projekts eine Konfigurationsdatei mit dem Namen cloudbuild.json. Dies ist die Build-Konfigurationsdatei für Cloud Build.

  2. Feld "steps" hinzufügen: Der Abschnitt steps in der Konfigurationsdatei enthält die Build-Schritte, die von Cloud Build ausgeführt werden sollen.

    {
        "steps": [
        {
        }
        ]
    }
    
  3. Ersten Schritt hinzufügen: Unter "steps" fügen Sie ein Feld "name" hinzu, das zum Ausführen der Aufgabe auf ein Container-Image verweist. Cloud Build und dessen Entwicklercommunity stellen mehrere Container-Images zur Verfügung, in denen häufig genutzte Tools und Sprachen installiert sind. Sie können in einem Build-Schritt eines dieser Images (auch als Cloud-Builder bezeichnet) oder ein öffentlich verfügbares Image 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 dem Docker-Builder gcr.io/cloud-builders/docker. Dabei handelt es sich um ein Container-Image, auf dem Docker ausgeführt wird.

    {
        "steps": [
        {
            "name": "gcr.io/cloud-builders/docker"
        }
        ]
    }
    
  4. 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 der Listeneintrag 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
    • gcr.io/my-project/my-image ist der Name des Images, das erstellt werden soll
    • . ist der Speicherort des Quellcodes

      {
          "steps": [
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "build",
                  "-t",
                  "gcr.io/my-project/my-image",
                  "."
              ]
          }
          ]
      }
      
  5. Zusätzliche Felder für den Schritt hinzufügen. Sie können im Rahmen der Konfiguration Ihren Build-Schritt auch um weitere Felder wie Umgebungsvariablen und Arbeitsverzeichnisse erweitern. Eine Beschreibung aller Felder, die Sie in einem Build-Schritt verwenden können, finden Sie unter Build-Schritte.

    Im folgenden Beispiel ist das Feld timeout enthalten, um anzugeben, dass der Schritt docker nach 500 Sek. zu einer Zeitüberschreitung führen muss:

    {
        "steps": [
        {
            "name": "gcr.io/cloud-builders/docker",
            "args": [
                "build",
                "-t",
                "gcr.io/my-project/my-image",
                "."
            ],
            "timeout": "500s"
        }
        ]
    }
    
  6. 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 Container Registry überträgt.
    • Einen kubectl-Build-Schritt zum Aufrufen des Befehls kubectl set image, der das Image in einem Kubernetes Engine-Cluster bereitstellt. Das Feld env ist enthalten, um die Compute Engine-Zone und den Kubernetes Engine-Cluster anzugeben.

      {
          "steps": [
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "build",
                  "-t",
                  "gcr.io/my-project/my-image",
                  "."
              ],
              "timeout": "500s"
          },
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "push",
                  "gcr.io/my-project/my-image",
              ],
          },
          {
              "name": "gcr.io/cloud-builders/kubectl",
              "args": [
                  "set",
                  "image",
                  "deployment/my-deployment",
                  "my-container=gcr.io/my-project/my-image"
              ],
              "env": [
                  "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
                  "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
              ]
          }
          ]
      }
      
  7. Zusätzliche Build-Konfigurationen hinzufügen: Sie können die Build-Konfiguration auch um zusätzliche Felder wie machineType und tags erweitern. Im Überblick über Build-Konfigurationen werden alle Felder beschrieben, die Sie in der Build-Konfigurationsdatei verwenden können.

    Im anschließenden Beispiel werden die folgenden Felder zum Build hinzugefügt:

    • machineType gibt die VM-Größe an, mit der der Build ausgeführt wird.
    • timeout gibt an, wann der Build aufgrund der Überschreitung des Zeitlimits beendet wird.
    • tags zum Hinzufügen von Anmerkungen zum Build.

      {
          "steps": [
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "build",
                  "-t",
                  "gcr.io/my-project/my-image",
                  "."
              ],
              "timeout": "500s"
          },
          {
              "name": "gcr.io/cloud-builders/docker",
              "args": [
                  "push",
                  "gcr.io/my-project/my-image",
              ],
          },
          {
              "name": "gcr.io/cloud-builders/kubectl",
              "args": [
                  "set",
                  "image",
                  "deployment/my-deployment",
                  "my-container=gcr.io/my-project/my-image"
              ],
              "env": [
                  "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
                  "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
              ]
          }
          ],
          "options": {
              "machineType": "N1_HIGHCPU_8"
          },
          "timeout": "660s",
          "tags": [
              "mytag1",
              "mytag2"
          ]
      }
      
  8. Erstellte Images und Artefakte speichern. Wenn Ihr Build Container-Images erzeugt, können Sie diese in Container Registry speichern. Dazu können Sie das Feld images verwenden.

    Im folgenden Beispiel wird das im Docker-Schritt erstellte Image in Container Registry gespeichert:

    {
        "steps": [
        {
            "name": "gcr.io/cloud-builders/docker",
            "args": [
                "build",
                "-t",
                "gcr.io/my-project/my-image",
                "."
            ],
            "timeout": "500s"
        },
        {
                "name": "gcr.io/cloud-builders/docker",
                "args": [
                    "push",
                    "gcr.io/my-project/my-image",
                ],
        },
        {
            "name": "gcr.io/cloud-builders/kubectl",
            "args": [
                "set",
                "image",
                "deployment/my-deployment",
                "my-container=gcr.io/my-project/my-image"
            ],
            "env": [
                "CLOUDSDK_COMPUTE_ZONE=us-east4-b",
                "CLOUDSDK_CONTAINER_CLUSTER=my-cluster"
            ]
        }
        ],
        "options": {
            "machineType": "N1_HIGHCPU_8"
        },
        "timeout": "660s",
        "tags": [
            "mytag1",
            "mytag2"
        ],
        "images": [
            "gcr.io/my-project/myimage"
        ]
    }
    

    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.

Weitere Informationen