Cloud Build

ubuntu,debian,alpine,busybox などのイメージはある

シークレットと認証情報の使用 | Cloud Build のドキュメント | Google Cloud

Cloud KMS の値を secretEnv で引く

substitutions から substitutions の値は参照できない

まあそう

yaml 中では $RPROJECT_ID とかも使えない(空になる)

変数値の置換 | Cloud Build のドキュメント | Google Cloud

cloudbuild の各ステップの shell 中では使えるはず

手元から gcloud で実行する例

$ gcloud builds submit --config cloudbuild.yaml .

$ gcloud --project ${GCP_PROJECT} builds submit --config cloudbuild.yaml .

Github トリガなど、リポジトリの内容が渡ってくるものと .gcloudignore で食い違う場合があるのは注意

cloudbuild.yml

変数値の置換 | Cloud Build | Google Cloud

$RPROJECT_ID という環境変数が使える

GitHub タグでトリガーする場合は $TAG_NAME はあるけど $BRANCH_NAME は無い

ログを Cloud Logging にだけ残す

code:options.yaml

options:

logging: CLOUD_LOGGING_ONLY

Cloud Build waitFor の挙動

Cloud Build Conditional Step と向き合う

シェルスクリプト書く

まあよく必要になる

bash スクリプトの実行 | Cloud Build Documentation | Google Cloud

shbang を省略したら #!/bin/sh

環境変数は当然動く、変数置換はデフォルトオフ

automapSubstitutions: true で利用する

code:scripting.yaml

steps:

- name: "gcr.io/cloud-builders/docker"

script: |

#!/usr/bin/env bash

docker create --name=foo hogehoge:latest

docker cp foo:/app ./app

# これでも書けるが古い

- name: ...

entrypoint: bash

args:

- c

- |

docker ...

Cloud Build マシンタイプ

MachineType | Cloud Build のドキュメント | Google Cloud で指定できる

UNSPECIFIED

N1_HIGHCPU_8

N1_HIGHCPU_32

メモリサイズなどはこちら GCE の対応するマシンタイプで分かりそう

マシンタイプ | Compute Engine ドキュメント | Google Cloud

UNSPECIFIED は n1-standard-1、1CPU

料金 | Cloud Build のドキュメント | Google Cloud

github app のトリガでやってくるのは git リポジトリではない

gcr.io/cloud-builders/git で log とかやってもだめ

一度 clone する必要がある

timeout

must be <= build timeout "10m0s" cloud build

のように言われる時は、ビルドの timeout を伸ばす必要がある

timeout - ビルド構成の概要 | Cloud Build のドキュメント | Google Cloud

timeout にはビルド全体と、ステップ単位のがある

ステップの timeout がビルド全体の timeout より長ければエラーになる、省略した場合デフォルトは "10m0s"

手元で実行する

ローカルでのビルドとデバッグ | Cloud Build | Google Cloud

$ gcloud components install cloud-build-local でインストールしてもどこに入るねんという話は

gcloud のインストール先の bin ディレクトリ gcloud#5d00c6eebbf73900004a1c0b に作られる

Github 経由か手元からか

Github トリガだとリポジトリの内容が clone されてそこを workspace に実行される。

手元から $ gcloud builds submit --config cloudbuild.yaml $DIR とすると、$DIR の内容をアップロードする。

後者の場合 .gcloudignore が参照されるので、git リポジトリに含まれるけど .gcloudignore で無視されている、という場合実行結果が異なる場合がある

(例えばデプロイ速くするために go mod vendor してアップロードしたりしていると、go.mod はリポジトリには入っているけど .gcloudignore されている、というようなことが起きる)

デバッグ

各ステップの image を GCR から落としてこれるので、そのイメージをローカルで眺めて調べると便利

$ gcloud auth configure-docker しておくと

docker pull gcr.io/... したときに gcloud の認証情報を通して pull できる

イメージの push と pull | Container Registry のドキュメント | Google Cloud

マルチアーキテクチャビルドのサンプル

GoogleCloudPlatform/solutions-build-multi-architecture-images-tutorial: Build multi-architecture container images on Google Cloud

SLSA

Cloud Builders Community イメージ

https://github.com/GoogleCloudPlatform/cloud-builders-community

クラウドビルダー | Cloud Build | Google Cloud

例えば、CloudBuild は各ステップを docker container 上で実行するけど、そこで docker-compose を使いたい場合 docker-compose が動くイメージが必要になる。cloud-buidlers-community には、そいう典型的なイメージを作って GCR に上げるための cloudbuild タスク定義が置いてある、という感じ。

code:push-cloudbuilders-community-image.sh

#!/bin/bash

# Cloud Builder のコミュニティイメージをビルドして GCR へ push するスクリプト

# https://cloud.google.com/cloud-build/docs/cloud-builders?hl=ja

# https://github.com/GoogleCloudPlatform/cloud-builders-community

set -ex

GCP_PROJECT=${CGP_PROJECT:-hogehoge}

BUILDER_IMAGE=${BUILDER_IMAGE:-docker-compose}

DIR=$(mktemp -d)

cd ${DIR}

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community

cd ${DIR}/cloud-builders-community/${BUILDER_IMAGE}

gcloud --project ${GCP_PROJECT} builds submit --config cloudbuild.yaml .

echo "https://console.cloud.google.com/gcr/images/${GCP_PROJECT}"

echo "Use gcr.io/${GCP_PROJECT}/{BUILDER_IMAGE}"

#GoogleCloud