ビルドを実行すると、Cloud Build がビルドログを収集して保存します。このページでは、ビルドログを保存、表示、削除する方法について説明します。
ビルドログの送信先を選択する
Cloud Build を構成して、ビルドログを Cloud Storage のバケット、Cloud Logging のバケット、またはその両方に送信できます。
保存されたビルドログの保持期間を制御する場合は、Cloud Logging に送信します。Cloud Logging には、特定のビルドログのバケットを検索するためのオプションも用意されています。
ビルドログが生成されてから Logging が受信するまでに遅延が発生することがあります。ビルドログを Cloud Storage のバケットに送信すると、レイテンシが短縮されることがあります。
Cloud Storage と Logging のどちらでも、Google が作成したデフォルト バケットまたはユーザーが作成したカスタム バケットにログを保存できます。デフォルト バケットでは、バケットに保存されているログを表示できますが、バケットに関する変更はできません。ビルドログの保存に使用するバケットを完全に制御する必要がある場合は、ユーザーが作成したバケットにログを送信します。
デフォルト バケットにビルドログを保存する
Cloud Logging と Cloud Storage には、ビルドログを保存できるデフォルトのバケットがあります。これらのバケットは Google によって作成および所有され、複数のリージョンからログを受信できます。ビルドログをこれらのバケットのいずれかに送信するには、ビルド構成ファイルの LoggingMode
を次のいずれかの値で構成します。
GCS_ONLY
: ログはデフォルトの Cloud Storage バケットに保存されます。CLOUD_LOGGING_ONLY
: ログはデフォルトの Logging バケットに保存されます。LEGACY
: ログは両方のデフォルト バケットに保存されます。
デフォルトの Logging バケットには、保存されたログの 30 日間の保持ポリシーが設定されています。Logging に保存されているビルドログにカスタム保持ポリシーを設定するには、ビルドログをカスタム バケットに保存します。
デフォルトの Cloud Storage バケットに保持ポリシーがありません。
ユーザー所有のリージョン固有の Cloud Storage バケットへのビルドログの保存
ビルドログをデフォルトの Cloud Storage バケットに送信すると、Cloud Build はビルドを実行するロケーションとは異なる Google 指定のリージョンにビルドログを保存します。ただし、ビルドを実行するリージョンにあるユーザー所有の Cloud Storage バケットに Cloud Build がビルドログを送信するようにビルドを構成することもできます。この構成により、ビルドログ データの保存場所をより詳細に制御できるため、データ所在地に関する要件を遵守できます。
IAM 権限を付与する:
Cloud Storage バケットと Cloud Build が同じ Google Cloud プロジェクトにあり、Cloud Build の従来のサービス アカウントを使用している場合、そのサービス アカウントには必要な IAM 権限がデフォルトで付与されています。別途権限を付与する必要はありません。まだ完了していない場合は、次の操作を行います。
ビルドログをユーザー所有のリージョン固有のバケットに保存するために必要な権限を取得するには、ビルドに使用するサービス アカウントに対するストレージ管理者 (roles/storage.admin
)IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
リージョン固有の Cloud Storage バケットを構成します。
ビルド構成ファイルで、
defaultLogsBucketBehavior
オプションを追加し、その値をREGIONAL_USER_OWNED_BUCKET
に設定します。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" } }
ビルド構成ファイルを使用して、コマンドライン、API、またはトリガーでビルドを開始します。
ビルドを実行すると、Cloud Build はビルドを実行しているリージョンに新しいバケットを作成し、そのバケットにビルドログを保存します。
REGIONAL_USER_OWNED_BUCKET
が有効である限り、同じプロジェクトとリージョンの以降のビルドでは既存のバケットが使用されます。このバケットはユーザー所有であるため、ユーザー作成のバケットと同様に構成できます。
REGIONAL_USER_OWNED_BUCKET
オプションを設定して複数のリージョンでビルドを作成すると、Cloud Build はビルドログ用に複数のバケットを作成します。
リージョン固有のデフォルトの Cloud Storage バケットには保持ポリシーがありません。ただし、オブジェクトのライフサイクル ルールを構成することで、バケットからビルドログの削除を自動化できます。
ユーザーが作成したバケットにビルドログを保存する
ユーザーが作成したバケットを使用すると、ログバケットの管理と構成をより細かく制御できます。
ユーザーが作成した Cloud Logging バケットにビルドログを保存する
ユーザーが作成した Logging バケットを使用すると、保存されたビルドログの保持期間を調整できます。Logging のユーザーが作成したバケットにビルドログを保存するには、次の操作を行います。
IAM 権限を付与する:
ユーザーが作成した Cloud Logging バケットにビルドログを保存するために必要な権限を取得するには、プロジェクトに対するログ構成書き込み (roles/logging.configWriter
)IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
Logging バケットを構成する:
バケットを作成し、[保持期間] フィールドの値を設定します。
ビルドログを新しいバケットに転送するシンクを作成します。
シンクのビルド包含フィルタに次のように入力します。
logName = "projects/PROJECT_ID/logs/cloudbuild"
PROJECT-ID は、実際の Google Cloud プロジェクト ID に置き換えます。
(省略可)ログがデフォルトの Logging バケットに送信されないようにするには、ログバケットへのログエントリの保存を停止するの例に従います。
ユーザーが作成した Cloud Storage バケットにビルドログを保存する
ユーザーが作成した Cloud Storage バケットにビルドログを保存するには、次の操作を行います。
IAM 権限を付与する:
Cloud Storage バケットと Cloud Build が同じ Google Cloud プロジェクトにあり、Cloud Build の従来のサービス アカウントを使用している場合、Cloud Build の従来のサービス アカウントには必要な IAM 権限がデフォルトで付与されています。別途権限を付与する必要はありません。まだ完了していない場合は、次の操作を行います。
ユーザーが作成した Cloud Storage バケットにビルドログを保存するために必要な権限を取得するには、ビルドに使用するサービス アカウントに対するストレージ管理者 (roles/storage.admin
)IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
Cloud Storage バケットを構成する:
Google Cloud プロジェクトで、保持ポリシーを設定せずに、ビルドログを保存する Cloud Storage バケットを作成します。
ビルド構成ファイルに、ビルドログを保存するために作成した Cloud Storage バケットを指す
logsBucket
フィールドを追加します。次のビルド構成ファイルの例では、コンテナ イメージをビルドし、ビルドログをmylogsbucket
という名前のバケットに保存します。YAML
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'us-east1-docker.pkg.dev/myproject/myimage', '.' ] logsBucket: 'gs://mylogsbucket' options: logging: GCS_ONLY
JSON
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "us-east1-docker.pkg.dev/myproject/myimage", "." ] } ], "logsBucket": "gs://mylogsbucket", "options": { "logging": "GCS_ONLY" } }
ビルド構成ファイルを使用して、コマンドライン、API、またはトリガーでビルドを開始します。
ビルドが完了すると、Cloud Build はビルド構成ファイルで指定した Cloud Storage バケットにログを保存します。
ログ設定間の優先度
logsBucket
でユーザーが作成した Cloud Storage バケットを定義すると、Cloud Build はデフォルトの Cloud Storage バケットではなく、ユーザーが作成したバケットにビルドログを送信します。
既存のビルド構成ファイルに defaultLogsBucketBehavior
オプションを追加する場合、以前に logging
オプションまたは logsBucket
オプションを構成している場合は、設定間の競合を回避するために、それらの設定を削除することをおすすめします。具体的には、次の設定では、defaultLogsBucketBehavior
は機能しません。
- ビルドログを Cloud Logging に保存する
logging: CLOUD_LOGGING_ONLY
。 - ロギングをオフにする
logging: NONE
。
ビルド構成ファイルでロギング オプションを設定せずにビルドを実行すると、Cloud Build は logging: LEGACY
を設定し、デフォルトの Cloud Storage バケットにビルドログを保存します。defaultLogsBucketBehavior
を REGIONAL_USER_OWNED_BUCKET
に設定すると、logging: LEGACY
がオーバーライドされます。
ビルドログを表示する
ビルドログを表示するには、次の操作を行います。
IAM 権限を付与する:
Cloud Storage または Logging でビルドログを表示するために必要な権限を取得するには、ビルドに使用するサービス アカウントに対する次の IAM ロールを付与するよう管理者に依頼してください。
-
ユーザーが作成または所有する Cloud Storage バケットでビルドログを表示する:
-
Storage オブジェクト閲覧者(
roles/storage.objectViewer
) - ビルドログを表示するプリンシパル -
ログ表示アクセス者(
roles/logging.viewAccessor
) - ビルドログを表示するプリンシパル
-
Storage オブジェクト閲覧者(
-
デフォルトの Cloud Storage バケットでビルドログを表示する: 閲覧者(
roles/viewer
) - ビルドが構成されているプロジェクト -
Logging でビルドログを表示する: ログビューア(
roles/logging.viewer
) - ビルドログを表示するプリンシパル
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
Google Cloudでビルドログを表示する:
コンソール
Google Cloud コンソールで Cloud Build ページを開きます。
プロジェクトを選択し、[開く] をクリックします。
[リージョン] プルダウン メニューで、ビルドのリージョンを選択します。
[ビルド履歴] ページで、特定のビルドを選択します。
[ビルドの詳細] ページの [ステップ] で、[ビルドの概要] をクリックしてビルド全体のビルドログを表示するか、ビルドステップを選択して対象のステップのビルドログを表示します。
ログが Logging に保存されている場合は、[ビルドログ] パネルで
アイコンをクリックして、ログ エクスプローラでログを表示します。
gcloud
gcloud builds log
コマンドを実行します。ここで、build-id はビルドログを取得するビルドの ID です。ビルド ID は、gcloud builds submit
の実行時にビルド送信プロセスの最後に表示されるか、gcloud builds list
の実行時に ID 列に表示されます。
gcloud builds log build-id
GitHub と GitHub Enterprise でビルドログを表示する:
gcloud CLI または Cloud Build API を使用して GitHub トリガーまたは GitHub Enterprise トリガーを作成し、オプションとして --include-logs-with-status
を指定した場合、GitHub と GitHub Enterprise でビルドログを表示できます。
GitHub と GitHub Enterprise でビルドログを表示するには:
トリガーに関連付けられているリポジトリに移動します。
commit のリストに移動します。
ビルドログを表示する commit の行を見つけます。
commit の行にある結果アイコンをクリックします。
commit に関連付けられているチェックのリストが表示されます。
ビルドログを表示する行の [詳細] をクリックします。
commit に関連付けられている [概要] ページが表示されます。
--include-logs-with-status
フラグを使用してトリガーを作成した場合、ページの [詳細] セクションにビルドログが表示されます。
ビルドログとバケットを削除する
Cloud Storage でビルドログとバケットを削除するために必要な権限を取得するには、ビルドに使用するサービス アカウントに対する次の IAM ロールを付与するよう管理者に依頼してください。
-
ユーザー作成またはユーザー所有の Cloud Storage バケットからビルドログを削除する:
ストレージ管理者(
roles/storage.admin
) - ビルドログを削除するユーザーまたはサービス アカウント -
ユーザーが作成または所有する Cloud Storage バケットを削除する:
ストレージ管理者(
roles/storage.admin
) - バケットを削除するユーザーまたはサービス アカウント -
ユーザー作成の Logging バケットを削除する: ログ構成書き込み(
roles/logging.configWriter
)- プロジェクト
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
ユーザーが作成または所有する Cloud Storage バケット内のビルドログを削除するには、Cloud Storage ドキュメントのオブジェクトの削除の手順に沿って操作します。
ユーザーが作成または所有する Cloud Storage バケットを削除するには、Cloud Storage ドキュメントのバケットの削除の手順に沿って操作します。
ユーザーが作成した Logging バケットを削除するには、Logging ドキュメントのバケットを削除するの手順に沿って操作します。
次のステップ
- Cloud Build によって作成される監査ログについて学習する。
- ビルド結果を表示する方法を学習する。
- Build Cloud IAM 権限の詳細を確認する。