本稿はGoogle Cloud Container Builderの可能性を探る試みだ。Google Cloud Platform(1) Advent Calendar 2016の23日目の記事として書かれるはずのものだった（ごめんなさい）。
Google Cloud Container Builderとは
Google Cloud Container Builderとは，Google Cloud StorageまたはGoogle Cloud Source RepositoryにあるソースコードからDockerイメージを作成するためのサービスだ。GitHubのリポジトリ連携できないならもういいや，などと考えて読むのを止めようとする方がおられるだろうが，少し待ってほしい。Google Cloud Source RepositoryはGitHubまたはBitbucketのソースコードを同期する機能があるので，これらのホスティングサービスとの連携も可能なのだ。具体的にリポジトリを同期する方法はここでは説明しない。
Google Cloud Container Builderに出来る事
Google Cloud Container Builder（以下GCCBと呼ぶ）に出来る事は前述の通りで，指定されたソースコードからDockerイメージを作成する事だ。しかし，同じくリポジトリのソースコードからDockerイメージを作成するQuayやDocker Hubなどのサービスとは異なり，ビルドに関するメタ情報を持つBuildオブジェクトが柔軟なビルド定義を行えることだ。具体的には，Build Stepsを使って，複雑なDockerイメージのビルドプロセスを構築できる。詳細に見ていこう。
Build Steps
Build StepsはBuild Stepのシーケンスで構成される。一つの「Build Step」はDockerコンテナであり，スクリプトを構成する一つのコマンドの様なものであると説明されている。コンパイル環境とランタイム環境が異なる場合，これらのDockerイメージを分けてビルドを行うことは広く知られたプラクティスだと思うが，それを実現するにはちょっと泥臭い手間が必要になる（少なくとも僕にとってはそうだ）。例えば，Kubernetes上で動いているCIサービスのWerckerは素晴らしいサービスだが，Kubernetes上で動いているが為に，逆に自由にDockerイメージを作るのが難しい。Codeshipはこのような問題を認識しているようで，少し前から「DockerネイティブなCI」を標榜してプラットフォームの刷新を行い，Codeship Proとしてリブランドして提供している。
少し話がそれた。つまりBuild Stepsを使えば，Dockerイメージを函数合成の様に組み合わせて，求める最適なDockerイメージを得ることができるということだ。複数のBuild StepをBuildオブジェクトのstepsフィールドに指定した場合，前のBuild Stepの成果物は/workspaceに渡される。この連鎖で，単純ながら求める殆どの事が可能になるはずだ。
Build Stepには任意のDockerイメージを利用できるが，Googleは基本的なツール群をイメージとして公開している。リポジトリはここだ。このリポジトリの中をのぞくことで，またイメージを膨らませる事ができると思う。
実例
実際にいくつかのBuild Stepを組み合わせた例を作ってみよう。以下の様なビルドプロセスをGCCBを使って定義してみる。
- Finchを使ったScalaのソースコードをリポジトリから取得し，そこから単一の実行可能Jarを生成する
- Jarをカレントディレクトリにもってくる
- 生成したJarを含む，実行用Dockerコンテナを作成する
ごくごく単純な例だが，これを実際にGCCBでやってみる。gcloudコマンドを使う方法と，REST APIを直接使う方法がQuickstartでは提示されているが，gcloudコマンドでCloud Source Repositoriesを使う方法が無いようなので，curlを使ってやってみよう。Resource:BuildのAPIドキュメントに沿ってペイロードのJSONを書いていくだけなので，直観的に進めることができると思う。
ソースコードを取得する
Buildオブジェクトのsourceプロパティには，Sourceオブジェクトを設定する。SourceオブジェクトはstorageSourceまたはrepoSourceのいずれかになるsourceプロパティがあり，それぞれStorageSourceオブジェクトとRepoSourceオブジェクトを受け入れる。StorageSourceはその名の通り，Cloud Storageのアドレスを表現するオブジェクトで，RepoSourceはCloud Source Repositoriesを表現するものだ。今回はCloud Source Repositoriesにあるソースコードを使いたいので，RepoSourceオブジェクトを設定する。
"source": {
"repoSource": {
"projectId": "yananananana",
"repoName": "finch-hello",
"branchName": "master"
}
}
この例ではこのようなオブジェクトを書いてやる。これでCloud Source Repositoriesから全ての起点となるソースコードが/workspaceに配置される。
成果物を作成する
この例では，Javaのランタイムと，その上で実行するJarを最終的に生成するDockerイメージに配置したい。今回は全ての依存関係を一つのfat JARにまとめて成果物とする。ビルドツールとしてsbtを用いて，JARを作成する。sbtが入ったDockerイメージ上でsbt assemblyとコマンドを叩くだけだ。Build stepはこうした。
{
"name": "hseeberger/scala-sbt",
"args": ["sbt", "assembly"],
"id": "assemble"
}
とてもわかりやすい。Build Stepに組み込むDockerイメージは，この例の様にDocker image as a command的なイメージを使うとシンプルに記述でき，理解しやすいのでいいと思う。
これで/workspaceをカレントディレクトリとして，./target/scala-2.11/hello.jarというJARができるはず。ディレクトリの中身を確認したいところだが，それもアドホックにBuild Stepに組み込んでしまえばいい。
{
"name": "gcr.io/cloud-builders/docker",
"args": ["run", "--volume", "/workspace:/workspace/", "busybox", "ls", "-lR", "/workspace/target"],
"id": "probe-intermediary"
}
Dockerを使っているから，こんなことは簡単にできる。/workspaceをマウントしてやってlsコマンドを叩いているだけだが，これもまたGCCBのBuild Stepの使いやすさを示す一つの証左となるだろう。実際，途中に挟むBuild Stepはこれを発展させる形で書いてやればいい。
Jarをカレントディレクトリにもってくる
最終的なイメージからファイルを除外するのは.dockerignoreを使えばできるので，hello.jarをカレントディレクトリに移しておこう。これはDockerファイルのCOPYディレクティブを使えば不要な処理だが，汎用的なBuilderを書いてみたかったのでわざわざ追加してみた。
{
"name": "quay.io/yanana/cloud-builder-extractor",
"args": ["target/scala-2.11/hello.jar", "."],
"id": "extract"
}
extractと云うBuild Stepを定義した。ここでは，Builderをどうやって作ればいいのかを調べるのも兼ねて，ごくごく簡単なものを作ってみた。cloud-builder-extractorは渡した引数のファイルを移動するもので，カレントディレクトリを/workspaceとして処理を行う。この程度ならbusyboxイメージで処理を行えばいいと思うが，非常に簡単にワンオフのBuilderを作ることがリポジトリを見ればわかると思う（そして作らなくても大抵の事ができる事も）。
最終形のイメージを作成する
Google提供のdockerコマンドを実行できるBuilderを使う。argsにはdockerコマンドの引数を渡して実行するというものなので，Dockerイメージを作成する以外の目的でも，もちろん使える。イメージを作成する場合はこんな感じになるが，よく考えたらこの際は.dockerignoreファイルが有効なので，前節の内容は全くの無駄だった。まあでもせっかくなのでそのまま残しておく。
"name": "gcr.io/cloud-builders/docker",
"args": ["build", "--tag=asia.gcr.io/$PROJECT_ID/finch-hello", "-f", "Dockerfile.run", "."],
"id": "imagize"
これでasia.gcr.io/yananananana/finch-hello:latestというイメージが出来た。GCCBのビルド成否は，Buildオブジェクトのimagesプロパティに指定したDockerイメージが作成されたかどうかで決定される。今回の場合は最後に作成したイメージだけなので，こうなる。
"images": [
"asia.gcr.io/$PROJECT_ID/finch-hello"
]
Buildオブジェクトの全容
これまで説明したことを全て一つのJSONにするとこうなる（アドホックなデバッグコードは除いてある）。
{
"source": {
"repoSource": {
"projectId": "yananananana",
"repoName": "finch-hello",
"branchName": "master"
}
},
"steps": [
{
"name": "hseeberger/scala-sbt",
"args": ["sbt", "assembly"],
"id": "assemble"
}, {
"name": "quay.io/yanana/cloud-builder-extractor",
"args": ["target/scala-2.11/hello.jar", "."],
"id": "extract"
}, {
"name": "gcr.io/cloud-builders/docker",
"args": ["build", "--tag=asia.gcr.io/$PROJECT_ID/finch-hello", "."],
"id": "imagize"
}
],
"images": [
"asia.gcr.io/$PROJECT_ID/finch-hello"
]
}
まとめ
GCCBでできることとして，ありそうなユースケースを追いかけて使ってみた。感想としては，Werckerでこれができたらよかったのになあ，という事をまず感じた。使って感じたProsとConsを以下にまとめてみたので，参考までに見てほしい。
-
Pros
- 宣言的にビルドパイプラインを記述できることによる明快さ
- できることの自由度の高さ
-
Cons
- gcloudコマンドがAPIと完全に整合が取れていないこと
- 直接GitHubやBitbucketと連携できないこと
- Google Container Registry以外のDockerレジストリとの連携の弱さ
- クレデンシャルなどの見せたくない情報を外部から注入できないこと（KMSがAPIとして公開されれば解決する？）
- ビルド結果を同期で待つAPIが無い（と思われる）こと
Consで挙げた点は，今後改善されていくのを期待したい。僕は自分のプロジェクトで，すぐに使ってみたいと感じた。今回触れていない要素として，ビルドトリガがあるが，トリガでビルドされた結果の完了を知る方法がわかればこれも是非使いたい。CIサーバで同一コミットに対するビルドを同定するには，Buildオブジェクトのリストをとってコミットハッシュを見ていくしか今のところなさそうなので，ちょっと不便そう。
みんなでGCCBをどんどん使って機能改善してもらおう！