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
Installieren und initialisieren Sie die Google Cloud-Befehlszeile.
Installieren Sie Docker. Es empfiehlt sich, dieselbe Docker-Version wie in Cloud Build zu verwenden.
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.
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 Namencloudbuild.yaml
hat, müssen Sie dieses Flag nicht hinzufügen.
- Befindet sich die Konfigurationsdatei beispielsweise im Arbeitsverzeichnis und hat den Namen
[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]
.
- Wie bei Cloud Build können Sie
--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 Feldimages
oderartifacts
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
durchvalue
und_FOO
durchfoo
ersetzt.
Weitere Informationen finden Sie unter Substitutionen.
Lokale Fehlersuche im Build
Zur Fehlersuche können Sie so vorgehen:
- Überprüfen, ob die Konfigurationsdatei korrekt ist, indem Sie einen Probelauf des Builds ausführen.
- Die Zwischenartefakte überprüfen, die während des Build-Vorgangs im Arbeitsbereich erstellt wurden. Weitere Informationen hierzu finden Sie unter Zwischenartefakte erhalten.
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.
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.
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
- Informationen zum Erstellen von Artefakten mit Cloud Build