Best Practices zur Beschleunigung von Builds

Diese Seite enthält Best Practices zur Beschleunigung von Cloud Build-Builds.

Kleinere Container erstellen

Beim Containerisieren einer Anwendung werden manchmal Dateien, die zur Laufzeit nicht benötigt werden, z. B. Abhängigkeiten bei der Build-Erstellung oder Zwischendateien, unbeabsichtigt in das Container-Image aufgenommen. Diese nicht benötigten Dateien erhöhen potenziell die Größe des Container-Images und verursachen dann zusätzlichen Zeitaufwand sowie zusätzliche Kosten, wenn das Image zwischen der Container-Image-Registry und der Containerlaufzeit verschoben wird.

Zur Reduzierung der Größe des Container-Images trennen Sie die Erstellung der Anwendung mit den dafür verwendeten Tools von der Zusammenstellung des Laufzeitcontainers.

Weitere Informationen finden Sie unter Kleinere Container erstellen .

Kaniko-Cache verwenden

Der Kaniko-Cache ist eine Cloud Build-Funktion, mit der Container-Build-Artefakte zwischengespeichert werden. Dazu werden Zwischen-Layer in einer Container-Image-Registry, z. B. der Container Registry von Google, gespeichert und indexiert, in der sie für nachfolgende Builds verfügbar sind. Weitere Informationen finden Sie unter Kaniko-Cache verwenden.

Im Cache gespeichertes Docker-Image

Der einfachste Weg, um Ihren Docker-Image-Build schneller zu erstellen, ist die Angabe eines im Cache gespeicherten Image, das für danach erstellte Builds verwendet werden kann. Sie können das im Cache gespeicherte Image durch Hinzufügen des Arguments --cache-from in Ihrer Build-Konfigurationsdatei angeben. Damit wird Docker angewiesen, dieses Image als Cache-Quelle zum Erstellen des Builds zu verwenden.

Jedes Docker-Image besteht aus gestapelten Layern. Bei Verwendung von --cache-from werden alle Layer vom geänderten Layer bis zum Ende des Builds neu erstellt. Die Verwendung von --cache-from ist deshalb nicht sinnvoll, wenn Sie einen Layer in frühen Phasen Ihrer Docker-Build-Erstellung ändern.

Es wird empfohlen, für Ihre Builds immer --cache-from zu verwenden. Dabei ist Folgendes zu beachten:

  • Sie benötigen ein zuvor erstelltes Docker-Image für den Cache.
  • Sie können --cache-from nur für Docker-Builds verwenden. Damit lassen sich keine Builds nutzen, die andere Artefakte erstellen.
  • Das im Cache gespeicherte Image muss aus einer Registry abgerufen werden. Das kann zusätzlich Zeit für die Erstellung des Builds in Anspruch nehmen.

In den folgenden Schritten wird erläutert, wie Sie mit einem zuvor im Cache gespeicherten Image ein Build erstellen:

YAML

  1. Fügen Sie Ihrer Build-Konfiguration Anweisungen für folgende Vorgänge hinzu:

    • Rufen Sie das im Cache gespeicherte Image aus Container Registry ab. Beachten Sie dabei, dass der unten aufgeführte Build-Schritt docker pull den entrypoint auf bash festlegt. Dadurch kann der Befehl ausgeführt und der zurückgegebene Fehler ignoriert werden. Das ist erforderlich, wenn zum ersten Mal ein Image erstellt wird und docker pull kein vorhandenes Image abrufen kann.

    • Fügen Sie das Argument --cache-from hinzu, um dieses Image für die Neuerstellung von Builds zu verwenden.

      steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args: ['-c', 'docker pull gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest || exit 0']
- name: 'gcr.io/cloud-builders/docker'
  args: [
            'build',
            '-t', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
            '--cache-from', 'gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest',
            '.'
        ]
images: ['gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest']

      Dabei ist [IMAGE_NAME] der Name Ihres Images.

  2. Erstellen Sie Ihr Image mit der oben dargestellten Build-Konfiguration:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. Fügen Sie Ihrer Build-Konfiguration Anweisungen für folgende Vorgänge hinzu:

    • Rufen Sie das im Cache gespeicherte Image aus Container Registry ab. Der unten aufgeführte Build-Schritt docker pull legt den entrypoint auf bash fest. Dadurch kann der Befehl ausgeführt und sämtliche zurückgegebenen Fehler können ignoriert werden. Das ist erforderlich, wenn zum ersten Mal ein Image erstellt wird und docker pull kein vorhandenes Image abrufen kann.

    • Fügen Sie das Argument --cache-from hinzu, um dieses Image für die Neuerstellung von Builds zu verwenden.

      {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/docker",
        "entrypoint": "bash",
        "args": ["-c", "docker pull gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest || exit 0"]
    },
    {
        "name": "gcr.io/cloud-builders/docker",
        "args": [
            "build",
            "-t",
            "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
            "--cache-from",
            "gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest",
            "."
        ]
    }
    ],
    "images": ["gcr.io/$PROJECT_ID/[IMAGE_NAME]:latest"]
}

      Dabei ist [IMAGE_NAME] der Name Ihres Images.

  2. Erstellen Sie Ihr Image mit der oben dargestellten Build-Konfiguration:

    gcloud builds submit --config cloudbuild.json .

Verzeichnisse mit Google Cloud Storage im Cache zwischenspeichern

Verwenden Sie die Ergebnisse eines vorherigen Builds noch einmal, um die Erstellung eines Builds zu beschleunigen. Sie können die Ergebnisse eines früheren Builds in einen Google Cloud Storage-Bucket kopieren, diese Ergebnisse für eine schnellere Berechnung verwenden und dann die neuen Ergebnisse in den Bucket kopieren. Verwenden Sie diese Methode, wenn die Erstellung Ihres Builds sehr lange dauert und nur eine kleine Anzahl von Dateien generiert wird, deren Kopieren in und aus Google Cloud Storage nicht lange dauert.

Im Gegensatz zum Argument --cache-from, das nur für Docker-Builds dient, eignet sich das Google Cloud Storage-Caching für jeden von Cloud Build unterstützten Build.

Mit den im Folgenden dargestellten Schritten können Sie Verzeichnisse mit Google Cloud Storage im Cache zwischenspeichern:

YAML

  1. Fügen Sie Ihrer Build-Konfigurationsdatei Anweisungen für folgende Vorgänge hinzu:

    • Kopieren Sie die Ergebnisse eines vorherigen Builds aus dem Google Cloud Storage-Bucket.
    • Verwenden Sie die Ergebnisse für die Erstellung des aktuellen Builds.

    • Kopieren Sie die neuen Ergebnisse zurück in den Bucket.

      steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://mybucket/results.zip', 'previous_results.zip']
# operations that use previous_results.zip and produce new_results.zip
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'new_results.zip', 'gs://mybucket/results.zip']

  2. Erstellen Sie Ihren Code mit der oben dargestellten Build-Konfiguration:

    gcloud builds submit --config cloudbuild.yaml .

JSON

  1. Fügen Sie Ihrer Build-Konfigurationsdatei Anweisungen für folgende Vorgänge hinzu:

    • Kopieren Sie die Ergebnisse eines vorherigen Builds aus dem Google Cloud Storage-Bucket.
    • Verwenden Sie die Ergebnisse für die Erstellung des aktuellen Builds.

    • Kopieren Sie die neuen Ergebnisse zurück in den Bucket.

      {
    "steps": [
    {
        "name": "gcr.io/cloud-builders/gsutil",
        "args": ["cp", "gs://mybucket/results.zip", "previous_results.zip"]
    },
    {
        // operations that use previous_results.zip and produce new_results.zip
    },
    {
        "name": "gcr.io/cloud-builders/gsutil",
        "args": ["cp", "new_results.zip", "gs://mybucket/results.zip"]
    }
    ]
}

  2. Erstellen Sie Ihren Code mit der oben dargestellten Build-Konfiguration:

    gcloud builds submit --config cloudbuild.json .

Hochladen nicht benötigter Dateien vermeiden

Beim Auslösen eines Builds wird Ihr Codeverzeichnis von Cloud Build zur Verwendung hochgeladen.

Sie können Dateien, die von Ihrem Build nicht benötigt werden, mit einem .gcloudignore um die Upload-Zeit zu optimieren.

Folgende Dateien werden häufig ausgeschlossen:

  • Dokumentation und Beispielcode für Projektentwickler
  • Bei der Entwicklung verwendetes Material: generierter Scaffolding-Code, Binärdateien, *.jar-Dateien oder kompilierte Webinhalte
  • Übernommene Abhängigkeiten von Drittanbietern für die lokale Entwicklung

Wenn Sie diese Fälle mit der Datei .gcloudignore ausschließen möchten, erstellen Sie im Stammverzeichnis des Projekts eine Datei mit folgenden Inhalten:

.git
dist
node_modules
vendor
*.jar

Der Ausschluss von kompiliertem Code und Abhängigkeiten von Drittanbietern führt auch zu einem beständigeren Build-Prozess. Außerdem besteht ein geringeres Risiko dafür, versehentlich Code bereitzustellen, der sich noch in der Entwicklung befindet.

Nächste Schritte