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 der Build-Konfigurationsdatei werden Ihre Build-Logs in Cloud Logging-Buckets, Cloud Storage-Buckets oder an beiden Speicherorten gespeichert. Sie können auch den Typ des Logging- oder Cloud Storage-Bucket konfigurieren, der Ihre Logs enthält. Der Standort und der Typ Ihres Buckets wirken sich auf Ihre Möglichkeiten zur Analyse der Build-Logs und auf den Grad der Kontrolle aus, 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. Der Log-Explorer in Logging bietet im Vergleich zu Cloud Storage auch mehr Optionen zum Suchen nach bestimmten Build-Logs in einem Bucket. Wenn Sie Logging verwenden, kann es jedoch zu einer Verzögerung zwischen dem Zeitpunkt, an dem ein Build-Log generiert wird, und dem Zeitpunkt kommen, an dem Logging es empfängt.

  • Wenn Sie die Latenz zwischen dem Zeitpunkt, an dem ein Build-Log generiert wird, und dem Zeitpunkt, an dem Logging es empfängt, verringern 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 Bucket, dessen Inhaber ein Nutzer ist, können Sie beispielsweise die Einstellungen Ihres Buckets konfigurieren. Buckets, deren Inhaber Google Cloudist, werden von Google Cloud erstellt und können von Nutzern nicht geändert werden. Logging und Cloud Storage bieten mehrere Optionen zum Konfigurieren des Bucket-Typs, der Ihre Build-Logs empfängt.

Bucket-Standorte

Legen Sie im Feld logging in der Build-Konfigurationsdatei fest, wohin Ihre Build-Logs gesendet werden sollen:

  • 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 Speicherorten 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 den Optionen für Logging-Buckets. Wenn Sie Ihre Build-Logs an Cloud Storage senden, finden Sie im folgenden Abschnitt Informationen zu den 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 der Build-Konfigurationsdatei aus, um den Typ des Cloud Storage Buckets zu bestimmen, der die Build-Logs empfängt.

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

  • REGIONAL_USER_OWNED_BUCKET: Build-Logs werden an den von Cloud Build erstellten und vom Nutzer verwalteten 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 Google Cloud-verwalteten Bucket in einem Google Cloud-verwalteten Projekt gesendet. Dieser Wert entspricht dem Fall, dass dieses Feld nicht definiert ist.

Logspeicherung beim Erstellen aus Dockerfiles

Wenn Sie die Speicherung von Build-Logs 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 für ein:

  • regional-user-owned-bucket: Build-Logs werden an den von Cloud Build erstellten und vom Nutzer verwalteten 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 Google Cloud-verwalteten Bucket in einem Google Cloud-verwalteten Projekt gesendet. Dieser Wert entspricht dem Fall, dass dieses Feld nicht definiert ist.

Überlegungen zur Bucket-Inhaberschaft

Unabhängig davon, ob Sie Cloud Storage oder Logging verwenden, empfehlen wir, Ihre Build-Logs an einen Bucket zu senden, dessen Inhaber ein Nutzer ist. 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 vom Nutzer verwalteter Bucket (z. B. wenn Sie Einstellungen für einen regionalen, vom Nutzer verwalteten Bucket konfiguriert haben). So können Sie bestimmte Eigenschaften Ihres Buckets bearbeiten und die Logs im Bucket jederzeit ansehen. Da sich Buckets, deren Inhaber Google Cloudist, in Google Cloudvon verwalteten Projekten befinden, können sie nicht angesehen oder bearbeitet werden. Die zugehörigen Build-Logs können nur im Abschnitt Build-Log auf der Seite Build-Details angesehen werden.

Im Allgemeinen bieten vom Nutzer erstellte Buckets die größte Flexibilität bei der Konfiguration der Bucket-Einstellungen sowohl während als auch nach der Bucket-Erstellung. In diesem Fall müssen Sie jedoch immer darauf achten, dass Ihr vom Nutzer erstellter 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 vom Nutzer verwalteten 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, Ihren Build-Bucket so zu konfigurieren, dass er der Region Ihres Builds entspricht. Diese Einrichtung kann Ihnen helfen, 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 bei der Bucket-Erstellung definiert wurde. Wenn Sie einen vom Nutzer erstellten Bucket als logging-Wert Ihres Builds festlegen, muss die Region mit der Region Ihres Builds übereinstimmen.

  • Wenn Sie für Ihr Build-Log regionale, vom Nutzer verwaltete Buckets in Cloud Storage konfiguriert haben, werden Ihre Build-Logs immer an einen Bucket in derselben Region wie Ihr Build gesendet.

  • Buckets, deren InhaberGoogle Cloudist, werden auf eine von Google Clouddefinierte Region festgelegt. Daher stimmt diese Region möglicherweise nicht immer mit der Region Ihres Builds überein.

Hinzufügen von defaultLogsBucketBehavior zu vorhandenen Build-Konfigurationsdateien

Wenn Sie die Option defaultLogsBucketBehavior zu 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 gewünscht gespeichert werden. Cloud Build ignoriert defaultLogsBucketBehavior, wenn eine der folgenden Bedingungen erfüllt ist:

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

Wenn Sie einen Build ausführen, ohne dass in der Build-Konfigurationsdatei Felder für die Logspeicherung definiert sind, legt Cloud Build logging auf LEGACY fest.

Nächste Schritte