Optionen für die Speicherung von Build-Logs

Wenn Sie Builds ausführen, erfasst und speichert Cloud Build Ihre Build-Logs in einem Log-Bucket. Je nach den Einstellungen in der Build-Konfigurationsdatei werden Ihre Build-Logs in Cloud Logging-Buckets, Cloud Storage-Buckets oder an beiden Orten gespeichert. Sie können auch den Typ des Logging- oder Cloud Storage-Bucket konfigurieren, der Ihre Logs enthält. Der Speicherort und der Typ des Buckets wirken sich auf die Möglichkeit aus, die Build-Logs zu analysieren, und auf die Kontrolle, die Sie über die Bucket-Einstellungen haben.

Übersicht

Beachten Sie beim Einrichten der Build-Konfigurationsdatei Folgendes:

  • Wenn Sie die Aufbewahrungsdauer Ihrer gespeicherten Build-Logs steuern möchten, senden Sie sie an Logging. Die Loganzeige in Logging bietet im Vergleich zu Cloud Storage auch mehr Optionen, um einen Bucket nach bestimmten Build-Logs zu durchsuchen. Wenn Sie jedoch Logging verwenden, kann es zu einer Verzögerung zwischen dem Erstellen eines Build-Logs und dem Empfang durch Logging kommen.

  • Wenn Sie die Latenz zwischen dem Erstellen eines Build-Logs und seiner Verfügbarkeit in Cloud Storage reduzieren möchten, senden Sie Ihre Build-Logs an einen Bucket in Cloud Storage.

Die Inhaberschaft Ihres Buckets wirkt sich auch darauf aus, wie Sie mit gespeicherten Build-Logs interagieren können. In einem nutzereigenen Bucket können Sie beispielsweise die Einstellungen Ihres Buckets konfigurieren, während Buckets im Besitz von Google Cloudvon Google Clouderstellt werden und von Nutzern nicht geändert werden können. Logging und Cloud Storage bieten mehrere Optionen zum Konfigurieren des Bucket-Typs, der Ihre Build-Logs empfängt.

Bucket-Standorte

Richten Sie das Feld logging in Ihrer Build-Konfigurationsdatei ein, um festzulegen, wohin Ihre Build-Logs gesendet werden:

  • GCS_ONLY: Build-Logs werden an Cloud Storage-Buckets gesendet.
  • CLOUD_LOGGING_ONLY: Build-Logs werden an Logging-Buckets gesendet.
  • LEGACY: Build-Logs werden an Buckets an beiden Standorten gesendet. Wenn logging nicht definiert ist, verwendet Cloud Build diesen Wert.
  • NONE: Build-Logs werden nicht gespeichert.

Wenn Sie Ihre Build-Logs an Logging senden, finden Sie unter Cloud Logging-Routingkonfiguration Informationen zu Logging-Bucket-Optionen. Wenn Sie Ihre Build-Logs an Cloud Storage senden, finden Sie im folgenden Abschnitt Informationen zu verfügbaren Cloud Storage-Buckets. Im Abschnitt Überlegungen zur Bucket-Inhaberschaft werden die Vorteile und Überlegungen für Buckets basierend auf der Bucket-Inhaberschaft unabhängig vom Bucket-Standort beschrieben.

Bucket-Optionen in Cloud Storage

Wenn Ihre Build-Logs an Cloud Storage gesendet werden, wertet Cloud Build die Felder logsBucket und defaultLogsBucketBehavior in Ihrer Build-Konfigurationsdatei aus, um den Typ des Cloud Storage-Buckets zu bestimmen, der die Build-Logs empfängt.

Das Feld logsBucket kann einen beliebigen Bucket-Typ haben. Wenn logsBucket definiert ist, werden Logs unabhängig vom Wert defaultLogsBucketBehavior immer an diesen Bucket in Cloud Storage gesendet. Wenn logsBucket nicht definiert ist, wird der Wert von defaultLogsBucketBehavior so verwendet:

  • REGIONAL_USER_OWNED_BUCKET: Build-Logs werden an den von Cloud Build erstellten und nutzereigenen Bucket in Cloud Storage gesendet. Dieser Bucket befindet sich im Projekt des Nutzers und verwendet dieselbe Region wie der Build.
  • LEGACY_BUCKET: Build-Logs werden an den von Cloud Build erstellten und zu Google Cloudgehörenden Bucket in einem zu Google Cloudgehörenden Projekt gesendet.
  • Kein Wert: Build-Logs werden an einen von Cloud Build erstellten und nutzereigenen Bucket in Cloud Storage gesendet. Dieser Bucket befindet sich im Projekt des Nutzers und verwendet dieselbe Region wie der Build. Wenn das Erstellen dieses Buckets fehlschlägt, werden Build-Logs an einen von Cloud Build erstellten und zuGoogle Cloudgehörenden Bucket in einem zu Google Cloudgehörenden Projekt gesendet.

Protokollspeicher beim Erstellen aus Dockerfiles

Wenn Sie den Build-Log-Speicher beim Erstellen aus einem Dockerfile einrichten möchten, fügen Sie beim Ausführen von gcloud builds submit einen der default-buckets-behavior-Flag-Werte ein:

  • regional-user-owned-bucket: Build-Logs werden an den von Cloud Build erstellten und nutzereigenen Bucket in Cloud Storage gesendet. Dieser Bucket befindet sich im Projekt des Nutzers und verwendet dieselbe Region wie der Build.
  • legacy-bucket: Build-Logs werden an den von Cloud Build erstellten und zu Google Cloudgehörenden Bucket in einem zu Google Cloudgehörenden Projekt gesendet. Dieser Wert entspricht dem Nichtdefinieren dieses Felds.

Überlegungen zur Bucket-Inhaberschaft

Unabhängig davon, ob Sie Cloud Storage oder Logging verwenden, empfehlen wir, Ihre Build-Logs an einen Bucket zu senden, der dem Nutzer gehört. Dies kann entweder ein vom Nutzer erstellter Bucket sein (z. B. wenn Sie logsBucket auf einen von Ihnen erstellten Bucket festlegen) oder ein von Cloud Build erstellter, aber dem Nutzer gehörender Bucket (z. B. wenn Sie Einstellungen für einen regionalen, dem Nutzer gehörenden Bucket konfiguriert haben). So können Sie bestimmte Attribute Ihres Buckets bearbeiten und die Logs im Bucket jederzeit ansehen. Da Buckets, die zu Google Cloudgehören, sich in Projekten befinden, die zuGoogle Cloudgehören, können diese Buckets nicht angesehen oder bearbeitet werden. Ihre Build-Logs können nur im Abschnitt Build-Log auf der Seite Build-Details angesehen werden.

Im Allgemeinen bieten von Nutzern erstellte Buckets die größte Flexibilität bei der Konfiguration von Bucket-Einstellungen, sowohl während als auch nach der Bucket-Erstellung. In diesem Fall müssen Sie jedoch immer darauf achten, dass der von Ihnen erstellte Bucket den Anforderungen Ihres Builds entspricht. In einigen Fällen, z. B. beim Verwalten von Bucket-Regionen, können Sie mit einem von Cloud Build erstellten und nutzereigenen Bucket Build-Logs an einen Bucket senden, der standardmäßig in Cloud Storage verfügbar ist und sich immer in derselben Region wie Ihr Build befindet. Im folgenden Abschnitt finden Sie weitere Informationen zu diesem Anwendungsfall:

Überlegungen zu Bucket-Regionen

Wir empfehlen, den Build-Bucket so zu konfigurieren, dass er der Region Ihres Builds entspricht, da diese Einrichtung Ihnen helfen kann, die Anforderungen an den Datenstandort zu erfüllen. Wenn Sie Ihre Regionen auf diese Weise ausrichten möchten, beachten Sie Folgendes:

  • Von Nutzern erstellte Buckets in Logging und Cloud Storage verwenden die Region, die beim Erstellen des Buckets definiert wurde. Wenn Sie einen vom Nutzer erstellten Bucket als logging-Wert Ihres Builds festlegen, muss die Region mit der Build-Region übereinstimmen.

  • Wenn Sie Ihr Build-Log so konfiguriert haben, dass regionale, nutzereigene Buckets in Cloud Storage verwendet werden, werden Ihre Build-Logs immer an einen Bucket in derselben Region wie Ihr Build gesendet.

  • Buckets, die zuGoogle Cloudgehören, werden auf eine von Google Clouddefinierte Region festgelegt. Daher stimmt diese Region möglicherweise nicht immer mit der Region Ihres Builds überein.

defaultLogsBucketBehavior zu vorhandenen Build-Konfigurationsdateien hinzufügen

Wenn Sie die Option defaultLogsBucketBehavior einer vorhandenen Build-Konfigurationsdatei hinzufügen, in der Sie zuvor logging oder logsBucket konfiguriert haben, empfehlen wir, alle Einstellungen für die Logspeicherung zu prüfen, um sicherzustellen, dass Ihre Logs wie vorgesehen gespeichert werden. Cloud Build ignoriert defaultLogsBucketBehavior, wenn eine der folgenden Bedingungen zutrifft:

  • logging ist auf CLOUD_LOGGING_ONLY oder NONE gesetzt.
  • logging ist auf GCS_ONLY oder LEGACY gesetzt und logsBucket ist definiert.

Wenn Sie einen Build ohne in der Build-Konfigurationsdatei definierte Logspeicherfelder ausführen, setzt Cloud Build logging auf LEGACY.

Nächste Schritte