Bazelでビルドしたアプリを
GCPにデプロイしようとしてハマった話
(Dataflowのあたり)
GCPUG Tokyo DevOps Day September 2017
Katsunori Kanda (@potix2)

自己紹介
神田勝規(かんだかつのり) @potix2
株式会社サイバーエージェント アドテクスタジオ
サーバーサイドエンジニア
興味があること
ROS / droneの自律制御
Minecraft

結論
● gRPC使うならbazelは良い選択肢
● golangは依存関係の解決にやや難があるが使えなくは無い
○ 最近、cross compileできるようになった:)
● bazelを使ってJavaのビルドをするのは辛い(とくにDartaflow)

bazelとは？
● 最近、google関連のOSSでよく使われているビルドツール
○ tensorflow, kubernetes, istioなど
● 分散ビルドシステム
● 多言語マルチプロジェクトが扱いやすい(DAG)
● 競合プロダクト: pants
service.proto
java client
server app
golang
client
protocol bufferも
プロジェクトとして扱える
（オススメポイント）

Bazelの簡単な使い方
● ルートディレクトリにWORKSPACEファイルを置く
○ 読み込むbazelのrule(プラグインのようなもの)など、
全体設定を書く
● ビルド対象のディレクトリにBUILDファイルを置く
○ プログジェクトのビルド設定を書く。バイナリーの生
成ルールや、テストの実行方法など。

gRPCサービス・クライアントの例(golang)
.
├── BUILD
├── WORKSPACE
└── hello
├── BUILD
├── client
│ ├── BUILD
│ └── client.go
├── hello.proto
└── server
├── BUILD
└── server.go
ファイル一式: https://github.com/potix2/grpc-with-bazel
hello
hello/server
hello/client
ファイル構造 プロジェクトの依存関係

WORKSPACEの例
git_repository(
name = “io_bazel_rules_go”,
remote = “https://github.com/bazelbuild/rules_go.git”,
tag = “0.5.2”,
)
load(“@io_bazel_rules_go//go:def.bzl”, “go_repositories”, “go_repository”)
git_repository(
name = "org_pubref_rules_protobuf",
remote = "https://github.com/pubref/rules_protobuf.git",
tag = "v0.7.2",
)
load("@org_pubref_rules_protobuf//go:rules.bzl", "go_proto_repositories")
go_proto_repositories()
go_repositories(
go_version = "1.8.3",
)
...

package(default_visibility = ["//visibility:public"])
load("@org_pubref_rules_protobuf//go:rules.bzl", "go_proto_library")
go_proto_library(
name = "hello-go-proto",
protos = [
"hello.proto",
],
with_grpc = True,
)
BUILDの例: hello(gRPC)
hello/BUILD

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")
go_library(
name = "go_default_library",
srcs = ["server.go"],
visibility = ["//visibility:private"],
deps = [
"//hello:hello-go-proto",
"@org_golang_google_grpc//:go_default_library",
"@org_golang_x_net//context:go_default_library",
],
)
go_binary(
name = "server",
library = ":go_default_library",
visibility = ["//visibility:public"],
)
BUILDの例: hello/server (golang)
hello/server/BUILD

ここからはbazelのつらいはなし

Dataflowアプリのビルド
● 一言で言うと地獄
● Transitive dependencyを解決する良い方法がない
● jarのバージョンコンフリクトした時の解決ルールが
mavenと違う
○ bazelはプロジェクト初期からJavaのビルドをサポートしているはずな
のに・・・

Transitive Dependencyとは?
dependency
Transitive dependency
...
...

Dataflowアプリをビルドするためにやったこと
● 公式ページに書いてある方法だとうまく行かない
○ 参考: https://docs.bazel.build/versions/master/generate-workspace.html
● https://github.com/bazelbuild/miglation-tooling を使ってみた
○ が、これもうまく行かない
● mavenの実行結果から依存関係を抽出するスクリプトを書いて対処した
○ チームメンバーが作ってくれた！ありがとう:)bazelのjava_rulesがmavenと同じルールで依存関係を解決してくれるようになるといいな・・・

結論(ふたたび)
● gRPC使うならbazelは良い選択肢
● golangは依存関係の解決にやや難があるが使えなくは無い
○ 最近、cross compileできるようになった:)
● bazelを使ってJavaのビルドをするのは辛い(とくにDartaflow)

おしまい