Builds lokal erstellen und debuggen

Auf dieser Seite wird erläutert, wie Sie Cloud Build auf Ihrem lokalen Computer verwenden. Mit dem lokalen Builder können Sie:

  • Builds schneller auf Ihrem lokalen Computer durchlaufen lassen.
  • Einen Probelauf ausführen, um Ihre Konfigurationsdatei mit Lint auszuwerten.

Der lokale Builder kann nur auf Linux oder macOS ausgeführt werden.

Hinweis

  1. Installieren und initialisieren Sie das Google Cloud SDK.

  2. Installieren Sie Docker. Es empfiehlt sich, dieselbe Docker-Version wie in Cloud Build zu verwenden.

  3. Sie benötigen Quellcode zum Erstellen, eine Build-Konfigurationsdatei für Ihren Build und Zugriff von Ihrem lokalen Rechner auf alle Tools und Abhängigkeiten, die für Ihre Build-Schritte erforderlich sind.

  4. Wenn der Build auf eine private Registry zugreifen muss, installieren und konfigurieren Sie das Anmeldedatenhilfsprogramm von Docker für Cloud Build. Dazu führen Sie die folgenden Befehle aus:

    gcloud components install docker-credential-gcr
gcloud auth configure-docker

Lokalen Builder installieren

Der lokale Builder ist eine Komponente des Google Cloud SDK-Tools gcloud. Sie können es je nach System mithilfe des gcloud-Befehls, mit apt-get oder mit yum installieren.

Mit diesem Befehl installieren Sie den lokalen Builder:

gcloud 

gcloud components install cloud-build-local

apt-get 

sudo apt-get install google-cloud-sdk-cloud-build-local

yum 

sudo yum install google-cloud-sdk-cloud-build-local

Nach der Installation des lokalen Builders können Sie Folgendes aufrufen:

  • Die Befehlszeilenhilfe mit dem folgenden Befehl:

    cloud-build-local --help

  • Die installierte Version mit dem folgenden Befehl:

    cloud-build-local --version

Build lokal erstellen

Warnung: Sie können nur jeweils einen Build auf Ihrem lokalen Computer ausführen. Wenn mehrere Builds parallel ausgeführt werden, schlägt der lokale Builder fehl.

Wenn Sie noch kein Projekt eingerichtet haben, können Sie den lokalen Builder mithilfe der Konfiguration aus dem Schnellstart testen.

Mit dem folgenden Befehl erstellen Sie lokal einen Build:

cloud-build-local --config=[BUILD_CONFIG] --dryrun=false --push [SOURCE_CODE]

Wobei:

  • [BUILD_CONFIG] ist der Pfad zu Ihrer Build-Konfigurationsdatei und deren Name.
    • Befindet sich die Konfigurationsdatei beispielsweise im Arbeitsverzeichnis und hat den Namen cloudbuild.json, verwenden Sie das Flag --config=cloudbuild.json.
    • Der Standardwert ist cloudbuild.yaml. Wenn sich die Konfigurationsdatei im Arbeitsverzeichnis befindet und den Namen cloudbuild.yaml hat, müssen Sie dieses Flag nicht hinzufügen.
  • [SOURCE_CODE] ist der Pfad zu Ihrem Quellcode.
    • Wie bei Cloud Build können Sie . für die Quelle verwenden, wenn sich der Quellcode in Ihrem aktuellen Arbeitsverzeichnis befindet.
    • Wenn Ihr Build keinen Quellcode benötigt, verwenden Sie das Flag --no-source anstelle von [SOURCE_CODE].
  • --dryrun=false ermöglicht das Ausführen Ihres Builds. Das Flag --dryrun ist standardmäßig auf "true" gesetzt. Wenn Sie mit dem Standardwert arbeiten, wird Ihre Konfigurationsdatei mit Lint ausgewertet, aber es werden keine Build-Befehle ausgeführt. Sie müssen --dryrun=false explizit festlegen, um den Build auszuführen.
  • --push verschiebt die resultierenden Images bzw. Artefakte in das in der Konfigurationsdatei durch das Feld images oder artifacts definierte Ziel. Images und Artefakte werden standardmäßig erstellt, aber nicht verschoben.

Nachdem der Build abgeschlossen ist, befinden sich die Images auf Ihrem lokalen Rechner und sind über Docker verfügbar. Wenn Sie --push zum Build-Befehl hinzugefügt haben, sind sie im angegebenen Repository verfügbar.

Zwischenartefakte erhalten

Während eines Builds werden Zwischenartefakte in einem Verzeichnis namens workspace platziert. Standardmäßig löscht der Builder den Arbeitsbereich und seinen Inhalt am Ende eines Builds.

So führen Sie einen Build aus und erhalten gleichzeitig die Artefakte aus dem Arbeitsbereich:

cloud-build-local --config=[BUILD_CONFIG] --dryrun=false --write-workspace=[LOCAL_DIRECTORY_PATH] [SOURCE_CODE]

Wobei:

  • [BUILD_CONFIG] ist der Pfad zu Ihrer Konfigurationsdatei.
  • [SOURCE_CODE] ist der Pfad zu Ihrem Quellcode.
  • [LOCAL_DIRECTORY_PATH] ist das lokale Verzeichnis, in dem der Arbeitsbereich auf Ihrem lokalen Rechner gespeichert werden soll. Dieses Verzeichnis darf sich nicht im Verzeichnis [SOURCE_CODE] befinden.

Wenn Sie den Arbeitsbereich beibehalten, können Sie:

  • Zwischenartefakte bei der Fehlersuche in einem Build analysieren.
  • Auf ein Build-Ergebnis, z. B. ein Binärprogramm, zugreifen, das der Builder im Arbeitsbereich erstellt hat.

Substitutionen in einem Build verwenden

Zur Verwendung von Substitutionen in Ihrem Build nutzen Sie das Flag --substitutions mit dem key=value-Paar, das Sie ersetzen möchten. Beachten Sie, dass Sie Werte für bestimmte Standardvariablen sowie für von Ihnen definierte Variablen angeben können.

Beispiel:

cloud-build-local --config=[BUILD_CONFIG] --dryrun=false --substitutions _KEY=value,_FOO=foo [SOURCE_CODE]

Dabei gilt:

  • [BUILD_CONFIG] ist der Pfad zu Ihrer Konfigurationsdatei.
  • [SOURCE_CODE] ist der Pfad zu Ihrem Quellcode.
  • In diesem Beispiel wird _KEY durch value und _FOO durch foo ersetzt.

Weitere Informationen finden Sie unter Substitutionen.

Lokale Fehlersuche im Build

Zur Fehlersuche können Sie so vorgehen:

Lokale Builds werden mit den während der Ausführung auf dem lokalen Host verfügbaren Berechtigungen ausgeführt. In Cloud Build wird der Build-Schritt mit den Berechtigungen des Dienstkontos Ihres Projekts ausgeführt. Wenn Sie ein Berechtigungsproblem beheben möchten, richten Sie Ihre Berechtigungen so ein, dass sie mit denen des Cloud Build-Dienstkontos übereinstimmen. Dies ist sinnvoll, damit sich die lokalen Builds in einer Umgebung befinden, die der Cloud Build-Umgebung möglichst nahe kommt.

Build im Probelauf prüfen

Bei einem Probelauf des Builds können Sie die Konfigurationsdatei mit Lint auswerten und erhalten Fehler, wenn Probleme auftreten. Der Probelauf hat den Vorteil, dass Sie die Konfigurationsdatei analysieren können, ohne den gesamten Build ausführen zu müssen. Ein Probelauf kann nur mit einem lokalen Builder ausgeführt werden.

  1. Mit diesem Befehl führen Sie einen Probelauf des Builds aus:

    cloud-build-local --config=[BUILD_CONFIG] [SOURCE_CODE]

    Dabei gilt:

    • [BUILD_CONFIG] ist der Pfad zu Ihrer Konfigurationsdatei.
    • [SOURCE_CODE] ist der Pfad zu Ihrem Quellcode.

  2. Prüfen Sie alle Fehlermeldungen und beheben Sie alle Probleme in Ihrer Konfigurationsdatei.

Beschränkungen

  • Der lokale Builder kann nur auf Linux oder macOS ausgeführt werden.
  • Der lokale Builder führt jeweils nur einen Build auf einem bestimmten Host aus. Wenn mehrere Builds parallel ausgeführt werden, schlägt der lokale Builder fehl.
  • Der lokale Builder unterstützt keine 100% Featurefeature-Gleichheit mit dem gehosteten Cloud Build-Dienst. Beispiele für Funktionen, die vom lokalen Builder nicht unterstützt werden:
    • Dynamische Substitutionen
    • Private Pools

Unterschiede zwischen lokalem Builder und Cloud Build

Der lokale Builder ist dazu gedacht, Cloud Build zu imitieren, ist jedoch nicht vollständig interoperabel. Ein Build, der erfolgreich auf dem lokalen Builder ausgeführt wird, sollte in Cloud Build ähnlich ausgeführt werden. Die Kompatibilität wird jedoch nicht in beide Richtungen garantiert. Außerdem sind in Cloud Build Features verfügbar, die nicht in die Der lokale Builder.

Zwischen den beiden Buildern unterscheiden sich die Umgebungsunterschiede:

  • Der lokale Builder wird auf Ihrem lokalen Rechner ausgeführt. Cloud Build wird auf der Google Cloud Platform ausgeführt.
  • Zur Ausführung von Builds verwendet der lokale Builder Ihr persönliches Konto. Cloud Build verwendet das Cloud Build-Dienstkonto [PROJECT_ID]@cloudbuild.gserviceaccount.com. Wenn Sie für Ihr persönliches Konto Berechtigungen für den lokalen Builder festlegen, müssen Sie diese Berechtigungen möglicherweise für das Cloud Build-Dienstkonto replizieren. Weitere Informationen finden Sie unter Dienstkontoberechtigungen festlegen.
  • Die von den Buildern verwendete Version von Docker kann verschieden sein. Während der Ausführung gibt der lokale Builder eine Warnung aus, wenn sich die installierte Docker-Version von der in Cloud Build verwendeten Version unterscheidet. Es empfiehlt sich, dieselbe Docker-Version wie in Cloud Build zu verwenden.

Weitere Informationen