Google container builderと友だちになるまで

Google Container Builder と
友だちになるまで
GCPUG Tokyo Container Builder Day
February2018
Daisuke Maki @lestrrat (HDE inc)

• @lestrrat
• Perl/Go hacker, author, father
• Author of github.com/peco/peco
• Organizer for builderscon

<宣伝>
http://blog.builderscon.io/entry/call-for-sponsors-2018
スポンサー募集中！！！

Google Cloud Container Builder を使用すると、Google
Cloud Storage、Google Cloud Source Repositories、
GitHub、BitBucket にあるアプリケーションソースコード
から Docker コンテナイメージを作成できます。
Container Builder で作成したコンテナイメージは Google
Container Registry に自動的に格納されます

「なるほどわからん」

GCBとは?
ソースコード step 1
step 2
…
step N
Google Container Registry
Google Source Repository その他
…

GCBとは?
• ソースコードを送る
• 指定された「ステップ」実行する
• ステップから成果物をどこか（例：gcr.io）に送る

「これ知ってる」
CIサービスだ！

補足
• GCP的にはCIサービスではない
• やろうと思えばテストもある程度できる
• あくまで「構造が似ている」という意味

Should I Use GCB
いきなりですが…

GCBを使うべき理由
• コンテナイメージをビルドしたい
• GCP上にリソースが全部ある
• もうリモートデバッグしたくない
（後述）

GCBを使わない理由
• コンテナを使ってない
• テストを（真面目に）走らせたい
• GCPのサービスを使っていない

背景
• ソースコードはGitlabにあるmonorepo
• テストは別で行う
• イメージデプロイ先はasia.gcr.io

GCBリクエスト
gcloud container builds submit …
GCBビルドは「リクエスト」から始まる

GCBリクエスト
• docker buildコマンドのようにコンテキストを受け取る
gcloud container builds submit source

GCBリクエスト
• コンテキストはGoogle Storageに保存される
• GSRからのキックの場合は、clone結果が保存
される？（試してない）

ソースコード step 1
step 2
…
step N
Google Container Registry
Google Source Repository
…
GitlabはGSRでサポートされない…

GCBリクエスト
• 毎回monorepoを全部Google Storageに保存す
るの… 嫌だ…
• → 後述

ステップ
• リクエストを受け取った後、cloudbuild.yaml
内のステップを順番に実行する

ステップ
https://cloud.google.com/container-builder/docs/api/build-steps
https://cloud.google.com/container-builder/docs/how-to/writing-build-requests

ステップ
https://cloud.google.com/container-builder/docs/api/build-steps
https://cloud.google.com/container-builder/docs/how-to/writing-build-requests
「わかるよーな…わからんよーな…」

ステップ
• CIサービスでは「コマンド」を指定していく
スタイルが多い
• GCBは「コンテナ」を指定してく

GCBステップの「原理」
for step in config.steps
docker run step.image step.args
done

ステップ実行のイメージ
• git clone コンテナ
• go build コンテナ
• docker push コンテナ

ステップのコンテナイメージ
• よく使うものについてはGoogleが用
意してくれている → https://github.com/
GoogleCloudPlatform/cloud-builders
• gcloud, git, go等

ソースの取得
• Gitlabからプライベートなレポジトリを
クローンする（コードをアップロードしない）
• Gitlabの認証を行う必要がある

認証
• 認証トークンのようなデータはレポジト
リに入れたくない
• Google Key Management Services (KMS)
• KMSについては… 詳しくはWebで！

KMSからキーを得る
- name: 'gcr.io/cloud-builders/gcloud'
args:
- kms
- decrypt
- --ciphertext-file=gitlab-deploy.enc
- --plaintext-file=/root/.ssh/id_ed25519
- --location=global
- --keyring=cloudbuild
- --key=gitlab
volumes:
- name: 'ssh'
path: /root/.ssh

args:
- kms
- decrypt
- --location=global
- --key=gitlab
volumes:
- name: 'ssh'
path: /root/.ssh
gcloudを使うための
コンテナを指定じゃ

args:
- kms
- decrypt
- --location=global
- --key=gitlab
volumes:
- name: 'ssh'
path: /root/.ssh
gcloudコマンドの引数
じゃ。/root/.ssh以下
に解読結果を残すぞ！

args:
- kms
- decrypt
- --location=global
- --key=gitlab
volumes:
- name: 'ssh'
path: /root/.ssh
解読結果を残すためのスト
レージじゃ。あとでマウン
トして読み込めるぞい

.ssh/configを設定する
• .ssh/configで gitlab.comで使うキーを
設定する
• 諸事情により、後ほど説明

キーを使ってgit cloneする
- name: 'gcr.io/cloud-builders/git'
args:
- clone
- —depth=1
- —branch=master
- --single-branch
- git@gitlab.com:myaccount/myrepo.git
volumes:
- name: 'ssh'
path: /root/.ssh

args:
- clone
- —depth=1
- —branch=master
- --single-branch
volumes:
- name: 'ssh'
path: /root/.ssh
gitを使うためのコ
ンテナじゃ

args:
- clone
- —depth=1
- —branch=master
- --single-branch
volumes:
- name: 'ssh'
path: /root/.ssh 前のステップで作ったキー
を読み込むためにボリュー
ムをマウントするぞ

args:
- clone
- —depth=1
- —branch=master
- --single-branch
volumes:
- name: 'ssh'
path: /root/.ssh
git コマンドの引数
じゃ。~/.sshのキーを
勝手に使ってくれるぞ

依存関係
• まだ glide
•

公式イメージ
- name: gcr.io/cloud-builders/glide
id: glide:myrepo
waitFor:
- checkout-done
env:
- PROJECT_ROOT=myproject/myrepo # おまじない
args:
- install
注：公式イメージからコミュニティレポジトリに移動されているので、
多分イメージはそのうちなくなる

公式イメージ使えば簡単だと思った？
残念でした！

問題
• 我々はmonorepoを使っている
• つまり、ワークスペース直下にglide.yamlがあるわけで
はない）
• オフィシャルのステップは、コマンドそ
のものではなく、ラッパースクリプトをかま
している

問題
• 正しいディレクトリにcdできれば…
• あれ、どうやって任意のコマンドを実行
するの？
• まさか… イメージをそのために作る？

デバッグどうするの
• lsしたりenvしたり、環境を確認したい
• 適時echoをはさんだりしたい
• 主コマンド以外どうやって実行するの？

entrypoint
entrypoint: …

entrypoint
docker run —entrypoint=… image

愚痴
• entrypointについて、ビルドステップの
ドキュメントに一切説明がない (https://
cloud.google.com/container-builder/docs/build-config)
• APIの説明まで行くと解説がある (https://
cloud.google.com/container-builder/docs/api/reference/
rest/v1/projects.builds#Build)

entrypoint=bash
entrypoint: bash
args:
— -c
— |
echo “Hello, World!”

entrypoint=bash
entrypoint: bash
args:
— -c
— |
echo “Hello, World!”
bash -cを通して任意
のスクリプトを実行で
きるのじゃ！

cd && glide installでいいと思った？
残念でした！

問題
• cd … && glide install はだめ
• 「正しいGoのファイル配置」をゴニョゴニョして
あげる必要がある

glide Dockerfile
FROM gcr.io/cloud-builders/go:debian
RUN GOPATH=/go && curl https://glide.sh/get | sh
COPY glide.bash /builder/bin/
ENV PATH=/builder/bin:$PATH
ENTRYPOINT ["glide.bash"]

glide Dockerfile
. /builder/prepare_workspace.inc
prepare_workspace || exit
/go/bin/glide "$@"

問題
• cd … && glide.bashもだめ
• /workspace直下にいる事を前提としたスクリプト
になっている…

正解
id: glide:myrep
env:
- PROJECT_ROOT=myproject/myrepo
entrypoint: bash
args:
- '-c'
- |
cd subdirectory
/go/bin/glide install

正解
id: glide:myrep
env:
- PROJECT_ROOT=myproject/myrepo
entrypoint: bash
args:
- '-c'
- |
cd subdirectory
/go/bin/glide install
glide.bashをバラして
自分で記述したの
じゃ！

ここまでのおさらい
• ステップはイメージ
• 認証関連は KMS 使おう
• イメージの中では主コマンド実行以外にも色々やっている
• デバッグはentrypoint=bash
• 主コマンド以外色々やりたかったらentrypoint=bash

これだけでやりたい事は
ほぼ全てできるはずです

変数
• 全てのユーザ変数は “_”で始まる必要がある
• 展開がわかりにくいので、「なるたけ使わな
い」が吉と見た。

entrypoint: bash
args:
- '-c'
- |
chmod 600 /root/.ssh/id_ed25519
cat <<EOF >/root/.ssh/config
Hostname gitlab.com
IdentityFile /root/.ssh/id_ed25519
EOF
mv known_hosts /root/.ssh/known_hosts
volumes:
- name: 'ssh'
path: /root/.ssh

entrypoint: bash
args:
- '-c'
- |
Hostname gitlab.com
EOF
volumes:
- name: 'ssh'
path: /root/.ssh
このコンテナを使う
意味は特にないぞ
い。

entrypoint: bash
args:
- '-c'
- |
Hostname gitlab.com
EOF
volumes:
- name: 'ssh'
path: /root/.ssh
よくあるヤツじゃ。

entrypoint: bash
args:
- '-c'
- |
Hostname gitlab.com
EOF
volumes:
- name: 'ssh'
path: /root/.ssh このファイルも/root/.ssh
で後ほど使うのでマウント
じゃ。

スクリプトで複数ステップ
• デプロイは gcloud, gsutil, helm, kubectlをいっぺんに
使ったスクリプトを使いたい
• GCBには個別のイメージはあるが、全部一緒のものはない

スクリプト実行
- name: asia.gcr.io/$PROJECT_ID/cloud-sdk
entrypoint: bash
args:
- -c
- |
cd myrepo
./deploy/scripts/deploy.sh

entrypoint: bash
args:
- -c
- |
cd myrepo
自分で作ったイメー
ジじゃ

entrypoint: bash
args:
- -c
- |
cd myrepo
この中で色々使うの
じゃ。

イメージの準備
FROM alpine:3.6 AS helm
RUN apk add --update --no-cache ca-certificates git
ENV FILENAME helm-v2.7.2-linux-amd64.tar.gz
RUN apk add --update -t deps curl tar gzip
RUN curl -L http://storage.googleapis.com/kubernetes-helm/${FILENAME} | tar
zxv -C /tmp
FROM google/cloud-sdk:alpine
COPY --from=helm /tmp/linux-amd64/helm /bin/helm
RUN gcloud components install kubectl docker-credential-gcr gsutil

zxv -C /tmp
マルチステージDockerfile
でまずhelmを取得しておい
て、あとでコピーじゃ

zxv -C /tmp
こちらではすでにビル
ドされているcloud-
sdkをまるっと使うぞ

zxv -C /tmp
kubectl等もこのタイ
ミングでgcloudからイ
ンストールじゃ

zxv -C /tmp
gcr.ioにpushするなら
これをいれておくとよ
いぞ！

CIで開発の憂鬱
• ジョブを送る → 待つ
• 失敗する
• 手元に環境がないので適当にあたりをつ
けてデバッグ用コードをしこむ
• 最初に戻る

待つの辛い
（一度gitlabで10時間待たされた…）

GCB
• ほとんど待ち時間はない
• が、リソースを消費する
• デバッグならローカルでてきたほうが嬉しい

ローカルで動くGCB
gcloud components install container-builder-local

ここまで説明してきた事が
全部ローカルで実行可能！
最高です

The Good Parts
• ローカル環境で爆速で開発できる
• ローカル環境で爆速で開発できる（2回目）
• 下手にCIサービスのキャッシュとかに振り
回されるより効率的な環境を作れる
• Googleのサービスと絡めやすい

The Bad Parts
• Moving Partsが増える
• コンテナイメージの管理等
• UIとはなんだったのか
• ドキュメントとはなんだったのか
• entrypointのトリックを知らないとデバッグ
が無理

参考
• https://medium.com/@lestrrat/taming-google-
container-builder-22a6dded155c

Google container builderと友だちになるまで

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Google container builderと友だちになるまで

Similar to Google container builderと友だちになるまで (20)

More from lestrrat

More from lestrrat (20)

Google container builderと友だちになるまで