Wenn Sie Builds ausführen, erfasst und speichert Cloud Build Ihre Build-Logs. Auf dieser Seite wird erläutert, wie Sie Build-Logs speichern, aufrufen und löschen.
Speicherort für Build-Logs auswählen
Sie können Cloud Build so konfigurieren, dass Build-Logs in Cloud Logging oder in Cloud Storage gespeichert werden. Fügen Sie dazu das Feld logging
in Ihre Cloud Build-Konfigurationsdatei ein.
Wenn Sie in der Build-Konfigurationsdatei kein logging
-Feld angeben, speichert Cloud Build sowohl Build-Logs als auch Cloud Storage.
Mit den folgenden Schritten werden Build-Logs nur in Logging gespeichert:
Legen Sie in der Build-Konfigurationsdatei den Wert von
logging
aufCLOUD_LOGGING_ONLY
fest:YAML
steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/myproject/myimage', '.'] options: logging: CLOUD_LOGGING_ONLY
JSON
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "gcr.io/myproject/myimage", "." ] } ], "options": { "logging": "CLOUD_LOGGING_ONLY" } }
Verwenden Sie die Build-Konfigurationsdatei, um einen Build über die Befehlszeile, die API oder über Trigger zu starten.
Build-Logs im standardmäßigen von Google erstellten Bucket speichern
Cloud Build speichert Ihre Build-Logs standardmäßig in einem von Google erstellten Cloud Storage-Bucket. Sie können die in dem von Google erstellten Cloud Storage-Bucket gespeicherten Build-Logs anzeigen, aber keine weiteren Änderungen daran vornehmen. Wenn Sie die volle Kontrolle über Ihren Log-Bucket benötigen, speichern Sie die Logs in einem vom Nutzer erstellten Cloud Storage-Bucket.
Build-Logs in einem von Nutzern erstellten Bucket speichern
IAM-Berechtigungen:
Um Build-Logs in Ihrem eigenen Cloud-Storage-Bucket zu speichern, müssen Sie zuerst dem Cloud Build-Dienstkonto oder dem benutzerdefinierten Dienstkonto die erforderlichen IAM-Berechtigungen erteilen:
Wenn sich der Cloud Storage-Bucket und Cloud Build im selben Cloud-Projekt befinden und Sie das Cloud Build-Dienstkonto verwenden, hat Ihr Cloud Build-Dienstkonto standardmäßig die erforderlichen IAM-Berechtigungen. Sie müssen keine zusätzlichen Berechtigungen erteilen.
Wenn sich Ihr Cloud Storage-Bucket und Cloud Build im selben Cloud-Projekt befinden und Sie ein benutzerspezifisches Dienstkonto verwenden, gewähren Sie dem Dienstkonto die Rolle Storage-Administrator. Eine Anleitung zum Zuweisen einer Rolle zu einem Dienstkonto finden Sie unter Rollen für das Projekt zuweisen.
Wenn sich Ihr Cloud Storage-Bucket und Cloud Build in verschiedenen Cloud-Projekten befinden, weisen Sie dem Cloud Build-Dienstkonto die Rolle Storage-Administrator zu:
Zur Seite "IAM":
Wählen Sie das Projekt aus, in dem Sie Builds mit Cloud Build ausführen.
Suchen Sie in der Tabelle mit den Berechtigungen nach der E-Mail-Adresse, die mit
@cloudbuild.gserviceaccount.com
endet, und notieren Sie sie. Dies ist Ihr Cloud Build-Dienstkonto.Öffnen Sie die IAM-Seite in dem Projekt, in dem sich Ihr Cloud Storage-Bucket befindet:
Klicken Sie auf Zugriff erlauben.
Geben Sie die E-Mail-Adresse des Cloud Build-Dienstkontos ein.
Wählen Sie Cloud Storage und dann Storage-Administrator aus.
Klicken Sie auf Speichern.
So geben Sie einen Cloud Storage-Bucket zum Speichern von Build-Logs an:
Erstellen Sie in Ihrem Cloud-Projekt einen Cloud Storage-Bucket ohne Aufbewahrungsrichtlinie zum Speichern Ihrer Build-Logs.
Fügen Sie der Build-Konfigurationsdatei das Feld
logsBucket
hinzu, das auf den Cloud Storage-Bucket verweist, den Sie zum Speichern von Build-Logs erstellt haben. Die folgende Build-Konfigurationsdatei enthält eine Anleitung zum Erstellen eines Container-Images und zum Speichern der Build-Logs in einem Bucket namensmylogsbucket
:YAML
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'gcr.io/myproject/myimage', '.' ] logsBucket: 'gs://mylogsbucket' options: logging: GCS_ONLY
JSON
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "gcr.io/myproject/myimage", "." ] } ], "logsBucket": "gs://mylogsbucket", "options": { "logging": "GCS_ONLY" } }
Verwenden Sie die Build-Konfigurationsdatei, um einen Build über die Befehlszeile, die API oder über Trigger zu starten.
Wenn der Build abgeschlossen ist, speichert Cloud Build die Logs in dem Cloud Storage-Bucket, den Sie in der Build-Konfigurationsdatei angegeben haben.
Build-Logs in einem nutzereigenen und regionalisierten Bucket speichern
Standardmäßig speichert Cloud Build Build-Logs in einer von Google angegebenen Region, die sich möglicherweise von dem Standort unterscheidet, an dem ein Build ausgeführt wird. Mit der Option defaultLogsBucketBehavior
können Sie Cloud Build so konfigurieren, dass ein Standard-Log-Bucket in Ihrem eigenen Projekt und in derselben Region wie der Build verwendet wird. Mit dieser Konfiguration haben Sie mehr Kontrolle über den Speicherort Ihrer Logdaten und können so die Anforderungen an den Datenstandort besser erfüllen.
Für das Speichern von Logs in Ihrem eigenen Projekt fallen Kosten an. Preisinformationen finden Sie unter Cloud Storage – Preise.
Konfigurieren Sie Cloud Build für die Verwendung regionalisierter, nutzereigener Logs:
Erforderliche IAM-Berechtigungen erteilen.
Wenn Sie das Cloud Build-Dienstkonto verwenden, hat Ihr Cloud Build-Dienstkonto standardmäßig die erforderlichen IAM-Berechtigungen. Sie müssen keine zusätzlichen Berechtigungen erteilen.
Wenn Sie ein benutzerdefiniertes Dienstkonto verwenden, weisen Sie dem Dienstkonto die Rolle Storage-Administrator zu. Eine Anleitung zum Zuweisen einer Rolle zu einem Dienstkonto finden Sie unter Rollen für das Projekt erteilen.
Fügen Sie in der Build-Konfiguration die Option
defaultLogsBucketBehavior
hinzu und legen Sie als WertREGIONAL_USER_OWNED_BUCKET
fest:YAML
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'us-central1-docker.pkg.dev/myproject/myrepo/myimage', '.' ] options: defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET
JSON
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "us-central1-docker.pkg.dev/myproject/myrepo/myimage", "." ] } ], "options": { "defaultLogsBucketBehavior": "REGIONAL_USER_OWNED_BUCKET" } }
Mit der Build-Konfigurationsdatei können Sie einen Build über die Befehlszeile, die API oder Trigger starten.
Wenn Sie Ihren Build ausführen, erstellt Cloud Build den neuen Log-Bucket in der Region, in der Sie den Build ausführen. Anschließend werden die Build-Logs in diesem Bucket gespeichert. Für nachfolgende Builds im selben Projekt und in derselben Region wird standardmäßig der vorhandene Bucket verwendet.
Wenn Sie die Option defaultLogsBucketBehavior
festlegen und dann Builds in mehreren Regionen erstellen, erstellt Cloud Build mehrere Buckets für Ihre Build-Logs.
Regionale Build-Logs, die in Ihrem eigenen Projekt gespeichert sind, haben keine Aufbewahrungsrichtlinie. Diese Einstellung ist unveränderlich.
Vorrang zwischen Logeinstellungen
Wenn Sie die Option defaultLogsBucketBehavior
in eine vorhandene Build-Konfigurationsdatei einfügen und zuvor die Optionen logging
oder logsBucket
konfiguriert haben, empfehlen wir, diese Einstellungen zu löschen, um Konflikte zwischen Einstellungen zu vermeiden.
defaultLogsBucketBehavior
funktioniert insbesondere nicht, wenn Sie Folgendes konfiguriert haben:
logging: CLOUD_LOGGING_ONLY
zum Speichern Ihrer Build-Logs in Cloud Logginglogging: NONE
, um das Logging zu deaktivieren.
Wenn Sie einen Build ohne Logging-Optionen in Ihrer Build-Konfiguration ausführen, legt Cloud Build logging: LEGACY
fest und speichert Logs im standardmäßig von Google erstellten Cloud Storage-Bucket. Wenn Sie defaultLogsBucketBehavior: REGIONAL_USER_OWNED_BUCKET
hinzufügen, überschreibt logging: LEGACY
diese Option.
Build-Logs anzeigen
IAM-Berechtigungen:
Wenn sich Ihre Build-Logs in Logging befinden, gewähren Sie den Hauptkonten, die die Build-Logs einsehen möchten, die Rolle Log-Betrachter für das Projekt, in dem der Build konfiguriert ist:
Zur Seite "IAM":
Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.
Suchen Sie in der Berechtigungstabelle nach der E-Mail-ID des Hauptkontos und klicken Sie auf das Stiftsymbol.
Wählen Sie die Rolle Logging > Log-Betrachter aus.
Klicken Sie auf Speichern.
Wenn sich Ihre Build-Logs im von Google erstellten Cloud Storage-Standard-Bucket befinden, weisen Sie Hauptkonten, die Build-Logs ansehen möchten, die Rolle Projektbetrachter für das Projekt zu, in dem der Build konfiguriert ist:
Zur Seite "IAM":
Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.
Suchen Sie in der Berechtigungstabelle nach der E-Mail-ID des Hauptkontos und klicken Sie auf das Stiftsymbol.
Wählen Sie Projekt und dann Betrachter aus.
Klicken Sie auf Speichern.
Wenn sich Ihre Build-Logs in einem von Nutzern erstellten oder nutzereigenen Cloud Storage-Bucket befinden, gewähren Sie Hauptkonten, die sich Build-Logs ansehen möchten, die Rolle Storage-Objekt-Betrachter:
Zur Seite "IAM":
Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.
Suchen Sie in der Berechtigungstabelle nach der E-Mail-ID des Hauptkontos und klicken Sie auf das Stiftsymbol.
Wählen Sie die Rolle Cloud Storage und dann Storage-Objekt-Betrachter aus.
Klicken Sie auf Speichern.
So rufen Sie Build-Logs in Cloud Build auf:
Console
Öffnen Sie in der Google Cloud Console die Seite „Cloud Build“.
Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.
Wählen Sie im Drop-down-Menü Region die Region für den Build aus.
Klicken Sie auf der Seite Build-Verlauf auf einen bestimmten Build.
Klicken Sie auf der Seite Build-Details unter Schritte auf Build-Zusammenfassung, um Build-Logs für den gesamten Build aufzurufen, oder klicken Sie auf einen Build-Schritt, um Build-Logs für diesen Schritt aufzurufen.
Wenn Ihre Logs in Logging gespeichert sind, klicken Sie im Bereich Build-Log auf das Symbol
, um die Logs im Log-Explorer aufzurufen.
gcloud
Führen Sie den Befehl gcloud builds log
aus, wobei build-id die ID des Builds ist, für den Sie Build-Logs abrufen möchten. Die Build-ID wird am Ende des Übermittlungsprozesses für den Build angezeigt, wenn Sie gcloud builds submit
ausführen, oder in der ID-Spalte, wenn Sie gcloud builds list
ausführen.
gcloud builds log build-id
So rufen Sie Build-Logs in GitHub und GitHub Enterprise auf:
Wenn Sie einen GitHub- oder GitHub Enterprise-Trigger erstellen und --include-logs-with-status
als Option angegeben haben, können Sie Ihre Build-Logs in GitHub und GitHub Enterprise aufrufen.
So rufen Sie Build-Logs in GitHub und GitHub Enterprise auf:
Rufen Sie das Repository auf, das mit Ihrem Trigger verknüpft ist.
Rufen Sie die Liste der Commits auf.
Suchen Sie die Zeile des Commits, für das Sie Build-Logs ansehen möchten.
Klicken Sie auf das Ergebnissymbol in der Zeile des Commits.
Sie sehen eine Liste der mit Ihrem Commit verknüpften Prüfungen.
Klicken Sie für die Zeile, deren Build-Logs Sie aufrufen möchten, auf Details.
Sie gelangen zur Seite Zusammenfassung, die mit Ihrem Commit verknüpft ist. Wenn Sie einen Trigger mit dem Flag
--include-logs-with-status
erstellt haben, werden Ihre Build-Logs im Abschnitt Details der Seite angezeigt.
Build-Logs löschen
Sie können keine Build-Logs im von Google erstellten Log-Bucket löschen.
So löschen Sie Build-Logs in einem vom Nutzer erstellten Log-Bucket:
Gewähren Sie dem Nutzer oder dem Dienstkonto, das Logs löscht, die Rolle Storage Object Admin.
Löschen Sie die Build-Logs gemäß der Anleitung zum Löschen von Cloud Storage-Objekten unter Objekte löschen.
So löschen Sie den vom Nutzer erstellten Log-Bucket:
Weisen Sie dem Nutzer oder dem Dienstkonto, das den Log-Bucket löscht, die Rolle Storage-Administrator zu.
Löschen Sie den Log-Bucket unter Verwendung der Anleitung zum Löschen von Buckets.
Nächste Schritte
- Informationen zu Audit-Logs, die von Cloud Build erstellt wurden
- Build-Ergebnisse aufrufen
- Informationen zu Cloud Build-IAM-Berechtigungen.