Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話

290 views

Published on

Bazelを使ってDataflowアプリをビルドするとつらかったという話。gRPC+golangの組み合わせであればそれなりに使える。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

BazelでビルドしたアプリをGCPにデプロイしようとしてハマった話

  1. 1. Bazelでビルドしたアプリを GCPにデプロイしようとしてハマった話 (Dataflowのあたり) GCPUG Tokyo DevOps Day September 2017 Katsunori Kanda (@potix2)
  2. 2. 自己紹介 神田勝規(かんだかつのり) @potix2 株式会社サイバーエージェント アドテクスタジオ サーバーサイドエンジニア 興味があること ROS / droneの自律制御 Minecraft
  3. 3. 結論 ● gRPC使うならbazelは良い選択肢 ● golangは依存関係の解決にやや難があるが使えなくは無い ○ 最近、cross compileできるようになった:) ● bazelを使ってJavaのビルドをするのは辛い(とくにDartaflow)
  4. 4. bazelとは? ● 最近、google関連のOSSでよく使われているビルドツール ○ tensorflow, kubernetes, istioなど ● 分散ビルドシステム ● 多言語マルチプロジェクトが扱いやすい(DAG) ● 競合プロダクト: pants service.proto java client server app golang client protocol bufferも プロジェクトとして扱える (オススメポイント)
  5. 5. Bazelの簡単な使い方 ● ルートディレクトリにWORKSPACEファイルを置く ○ 読み込むbazelのrule(プラグインのようなもの)など、 全体設定を書く ● ビルド対象のディレクトリにBUILDファイルを置く ○ プログジェクトのビルド設定を書く。バイナリーの生 成ルールや、テストの実行方法など。
  6. 6. 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 ファイル構造 プロジェクトの依存関係
  7. 7. 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", ) ...
  8. 8. 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
  9. 9. 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
  10. 10. ここからはbazelのつらいはなし
  11. 11. Dataflowアプリのビルド ● 一言で言うと地獄 ● Transitive dependencyを解決する良い方法がない ● jarのバージョンコンフリクトした時の解決ルールが mavenと違う ○ bazelはプロジェクト初期からJavaのビルドをサポートしているはずな のに・・・
  12. 12. Transitive Dependencyとは? dependency Transitive dependency ... ...
  13. 13. Dataflowアプリをビルドするためにやったこと ● 公式ページに書いてある方法だとうまく行かない ○ 参考: https://docs.bazel.build/versions/master/generate-workspace.html ● https://github.com/bazelbuild/miglation-tooling を使ってみた ○ が、これもうまく行かない ● mavenの実行結果から依存関係を抽出するスクリプトを書いて対処した ○ チームメンバーが作ってくれた!ありがとう:)bazelのjava_rulesがmavenと同じルールで依存関係を解決してくれるようになるといいな・・・
  14. 14. 結論(ふたたび) ● gRPC使うならbazelは良い選択肢 ● golangは依存関係の解決にやや難があるが使えなくは無い ○ 最近、cross compileできるようになった:) ● bazelを使ってJavaのビルドをするのは辛い(とくにDartaflow)
  15. 15. おしまい

×