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 die Google Cloud-Befehlszeile.

  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 der gcloud-CLI der Google Cloud-Befehlszeile. Sie können sie je nach System mit dem Befehl gcloud, apt-get oder 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]

Dabei gilt:

  • [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]

Dabei gilt:

  • [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 nicht alle Funktionen mit dem gehosteten Cloud Build-Dienst. Beispiele für Funktionen, die vom lokalen Builder nicht unterstützt werden, sind unter anderem:
    • Dynamische Substitutionen
    • Private Pools

Unterschiede zwischen lokalem Builder und Cloud Build

Der lokale Builder ist eine Art Nachbildung von Cloud Build, funktioniert jedoch nicht vollständig interoperabel. Ein Build, der erfolgreich auf dem lokalen Builder läuft, sollte mit ähnlichem Verhalten auf dem Cloud Build laufen. Kompatibilität ist aber in beiden Richtungen nicht garantiert, und es gibt Funktionen, die im Cloud Build verfügbar sind, die im lokalen Builder nicht implementiert wurden.

Zu den Umgebungsunterschieden zwischen den beiden Buildern gehören:

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

Nächste Schritte