ビルドを実行すると、Cloud Build がビルドログを収集してログバケットに保存します。ビルド構成ファイルの設定に基づいて、ビルドログは Cloud Logging バケット、Cloud Storage バケット、またはその両方の場所に保存されます。ログを保存する Logging または Cloud Storage バケットのタイプを構成することもできます。バケットのロケーションとタイプは、ビルドログを分析する機能と、バケット設定を制御する量に影響します。
概要
ビルド構成ファイルを設定する際は、次の点を考慮してください。
保存されたビルドログの保持期間を制御する場合は、Logging に送信します。Logging のログビューアには、Cloud Storage と比較して、特定のビルドログをバケットで検索するためのオプションが用意されています。ただし、Logging を使用すると、ビルドログが生成されてから Logging がそれを受信するまでに遅延が発生することがあります。
ビルドログが生成されてから Cloud Storage で利用可能になるまでのレイテンシを短縮するには、ビルドログを Cloud Storage のバケットに送信します。
バケットの所有権は、保存されたビルドログの操作方法にも影響します。たとえば、ユーザー所有のバケットではバケットの設定を構成できますが、 Google Cloud所有のバケットは Google Cloudによって作成され、ユーザーが変更することはできません。Logging と Cloud Storage には、ビルドログを受信するバケットのタイプを構成するためのオプションがいくつかあります。
バケットのロケーション
ビルド構成ファイルの logging フィールドを設定して、ビルドログの送信先を決定します。
GCS_ONLY: ビルドログが Cloud Storage バケットに送信されます。CLOUD_LOGGING_ONLY: ビルドログは Logging バケットに送信されます。LEGACY: ビルドログは両方のロケーションのバケットに送信されます。loggingが未定義の場合、Cloud Build はこの値を使用します。NONE: ビルドログは保存されません。
ビルドログを Logging に送信する場合は、Logging バケットのオプションについて Cloud Logging のルーティング構成をご覧ください。ビルドログを Cloud Storage に送信する場合は、次のセクションで、使用可能な Cloud Storage バケットに関する情報をご覧ください。バケットのオーナー権限に関する考慮事項のセクションでは、バケットのロケーションに関係なく、バケットのオーナー権限に基づくバケットの利点と考慮事項について説明します。
Cloud Storage のバケット オプション
ビルドログが Cloud Storage に送信されると、Cloud Build はビルド構成ファイルの logsBucket フィールドと defaultLogsBucketBehavior フィールドを評価して、ビルドログを受信する Cloud Storage バケットのタイプを決定します。
logsBucket フィールドには、任意のタイプのバケットを指定できます。logsBucket が定義されている場合、defaultLogsBucketBehavior の値に関係なく、ログは常に Cloud Storage のそのバケットに送信されます。logsBucket が未定義の場合、defaultLogsBucketBehavior の値は次のように使用されます。
REGIONAL_USER_OWNED_BUCKET: ビルドログは、Cloud Build で作成され、ユーザーが所有する Cloud Storage のバケットに送信されます。このバケットはユーザーのプロジェクトにあり、ビルドと同じリージョンを使用します。LEGACY_BUCKET: ビルドログは、 Google Cloudが所有するプロジェクト内の Cloud Build で作成され、 Google Cloudが所有するバケットに送信されます。- 値なし: ビルドログは、Cloud Build で作成され、ユーザーが所有する Cloud Storage のバケットに送信されます。このバケットはユーザーのプロジェクトにあり、ビルドと同じリージョンを使用します。このバケットの作成に失敗すると、ビルドログは、 Google Cloudが所有するプロジェクト内の、Cloud Build が作成したGoogle Cloudが所有するバケットに送信されます。
Dockerfile からビルドする場合のログ ストレージ
Dockerfile からビルドするときにビルドログ ストレージを設定するには、gcloud builds
submit の実行時に default-buckets-behavior フラグ値のいずれかを含めます。
regional-user-owned-bucket: ビルドログは、Cloud Build で作成され、ユーザーが所有する Cloud Storage のバケットに送信されます。このバケットはユーザーのプロジェクトにあり、ビルドと同じリージョンを使用します。legacy-bucket: ビルドログは、Cloud Build によって作成され、 Google Cloudが所有するバケット( Google Cloudが所有するプロジェクト内)に送信されます。この値は、このフィールドを未定義のままにした場合と同じです。
バケットの所有権に関する考慮事項
Cloud Storage と Logging のどちらを使用する場合でも、ビルドログをユーザー所有のバケットに送信することをおすすめします。これは、ユーザーが作成したバケット(たとえば、作成したバケットに logsBucket を設定した場合)か、Cloud Build で作成されたがユーザーが所有するバケット(たとえば、リージョンのユーザー所有バケットの設定を構成した場合)のいずれかです。これにより、バケットの特定のプロパティを編集し、バケット内のログをいつでも表示できます。 Google Cloudが所有するバケットはGoogle Cloudが所有するプロジェクトにあるため、バケットの表示や編集はできません。ビルドログは、[ビルドの詳細] ページの [ビルドログ] セクションでのみ表示できます。
一般に、ユーザー作成バケットは、バケットの作成中と作成後の両方でバケット設定を構成する際に最も柔軟性が高くなります。ただし、この場合は、ユーザー作成のバケットがビルドのニーズに合っていることを常に確認する必要があります。バケット リージョンの管理など、場合によっては、Cloud Build で作成されたユーザー所有のバケットを使用すると、デフォルトで Cloud Storage で使用可能で、常にビルドと同じリージョンにあるバケットにビルドログを送信できます。次のセクションでは、このユースケースについて詳しく説明します。
バケット リージョンに関する考慮事項
この設定はデータ所在地の要件に準拠するのに役立つため、ビルドのリージョンに合わせてビルドバケットを構成することをおすすめします。この方法でリージョンを調整する場合は、次の点を考慮してください。
Logging と Cloud Storage でユーザーが作成したバケットは、バケットの作成時に定義されたリージョンを使用します。ユーザー作成のバケットをビルドの
logging値として設定する場合は、そのリージョンがビルド リージョンと一致していることを確認してください。Cloud Storage でリージョンのユーザー所有バケットを使用するようにビルドログを構成した場合、ビルドログは常にビルドと同じリージョンのバケットに送信されます。
Google Cloudが所有するバケットは、 Google Cloudで定義されたリージョンに設定されます。そのため、このリージョンがビルドのリージョンと一致しない場合があります。
既存のビルド構成ファイルに defaultLogsBucketBehavior を追加する
以前に logging または logsBucket を構成した既存のビルド構成ファイルに defaultLogsBucketBehavior オプションを追加する場合は、すべてのログ ストレージ設定を評価して、ログが意図したとおりに保存されるようにすることをおすすめします。次のいずれかに該当する場合、Cloud Build は defaultLogsBucketBehavior を無視します。
loggingがCLOUD_LOGGING_ONLYまたはNONEに設定されている。loggingがGCS_ONLYまたはLEGACYに設定され、logsBucketが定義されている。
ビルド構成ファイルにログ ストレージ フィールドを定義せずにビルドを実行すると、Cloud Build は logging を LEGACY に設定します。
次のステップ
- ビルドログを保存、表示、削除する方法を確認する。
- Cloud Build によって作成される監査ログについて学習する。
- ビルド結果を表示する方法を学習する。
- Cloud Build IAM 権限の詳細を確認する。