とある会社のビルドデプロイ / A certain company's application building

1. Scala関西勉強会 2020年4月14日 hayasshi とある会社のビルド・デプロイ
2. 自己紹介 • こんにちは。林です。 ◦ Twitter: @hayasshi_ ◦ GitHub: hayasshi • Chatwork株式会社 • 最近は既存のScalaプロダクトのお手入れ 2
3. Scala関西勉強会 2020年4月14日 hayasshi とある会社のビルド・デプロイ
4. 今日お話すること 1. とある会社のScalaアプリケーションのビルドについて ◦ パッケージング方式 ◦ ビルド実行 4
5. 今日お話しないこと 1. とある会社のデプロイメントについて 2. とある会社のCI/CDの詳細 3. とある会社の開発フローの詳細 5
6. 01 Scalaアプリケーションの パッケージングについて
7. 前提 とある会社は、Scalaアプリケーションを、 　　　　Kubernetes上でDockerコンテナとして、動作させています なので本日は、 　　　　Scalaアプリケーションを どのようにDockerイメージにするか を話します 7
8. sbt-native-packager https://sbt-native-packager.readthedocs.io/en/stable/index.html https://github.com/sbt/sbt-native-packager 各プラットフォーム向けのパッケージングを行ってくれるsbtプラグイン Dockerイメージに加え、最近はGraalVMによるネイティブイメージ化にも対応 8
9. sbt-native-packager とある build.sbt (https://github.com/hayasshi/sbt-native-packager-sample ) 公式ドキュメント (https://sbt-native-packager.readthedocs.io/en/stable/formats/docker.html ) 9
10. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 10
11. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 11
12. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 12
13. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 13 起動スクリプト この例では AshScriptPlugin が使われているため ash
14. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 14 依存ライブラリjar
15. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 15 アプリケーション
16. sbt-native-packager `sbt docker:stage`をすると、`docker build`する前の状態が確認できます 16 起動スクリプトから読まれる設定ファイ ル
17. とある会社の工夫 アプリケーションの設定情報は全て環境変数から渡せるようにしている • なぜ？ ◦ コンテナ実行時に注入することで設定変更による再ビルドを避ける • 良い点 ◦ 同じイメージをつかって環境ごとに異なる設定情報で動作できる (ポータビリティの向上) ◦ コンテナランタイムは環境変数での値の受け渡しがよく使われる • 悪い点 ◦ 設定しないといけない環境変数が多くなりがち 17
18. とある会社の工夫 アプリケーションの設定情報は全て環境変数から渡せるようにしている Typesafe Config • 環境ごとに異なるアプリケーション設定はすべて環境変数からも渡せるように ◦ e.g. JDBC URL、ポート、各種タイムアウト値、固有のしきい値など • ローカルで動作させるための設定をデフォルト値に置いている 18
19. とある会社の工夫 アプリケーションの設定情報は全て環境変数から渡せるようにしている JVMオプション • 起動スクリプト内関数の`addJava`を使うことで`java`コマンドのオプション引数を 追加できる • そこに環境変数を指定することで起動スクリプト実行時の環境変数が使われる つまり`docker run -e`で指定した環境変数でJVMの設定値も調整できる • シェルのデフォルト値付き変数展開をつかってデフォルト値を設定 19
20. とある会社の工夫 アプリケーションの設定情報は全て環境変数から渡せるようにしている JVMオプション (起動スクリプト) 20
21. とある会社の注意点 • コンテナでjdk8を使っている場合、アップデートバージョンに注意 ◦ jdk8u191より前は、コンテナにかけられたCGroupのCPUやメモリを見ずに、 ホストマシンのものを見ていたため、スレッド数計算やヒープ計算が適切にな らない可能性がある ◦ https://bugs.openjdk.java.net/browse/JDK-8146115 ▪ jdk10からjdk8u191にバックポートされている ◦ jdk8u191以降を利用する 21
22. 02 ビルドについて
23. とある会社のビルド • ビルド内容はいたって普通です ◦ CIサーバー上でシェルスクリプトを実行してScalaアプリケーションのパッキ ングをおこない、Dockerイメージを作成する ▪ ビルドに対してイメージタグを付与 ◦ Dockerイメージタグに対応したGitタグを作成し、 どの時点のコミットでビルドしたものかを追跡できるようにしている • 一点だけ工夫している点としては、CIサーバーの実行モデルに合わせた sbtのビルドキャッシュを作成管理している ◦ ~/.ivy2/cache (ivy cache) ◦ ~/.sbt (boot directory) ◦ ~/cache/.coursier (coursier cache, sbt 1.3.X) 23
24. とある会社のビルドの工夫 • とある会社のCIサーバーでのシェルスクリプトの実行はDockerコンテナ上でおこな われる • sbtビルドキャッシュのファイル・システムのみのDockerイメージを作成してお き、実行するDockerコンテナにマウントすることで、ビルドキャッシュを利用して いる • 問題点も... ◦ アプリケーションビルドのたびにキャッシュ更新しているとビルドが遅くなる ◦ 定期的な手動更新の必要性 • 対策(検証検討中) ◦ Docker レイヤーキャッシュ ◦ ビルドのみCI SaaS等に切り出す 24
25. 03 まとめ
26. まとめ • sbt-native-packager ◦ Dockerfileのプラクティスがよくわからないアプリケーション開発者でも正し いDockerイメージをつくってくれる ◦ とある会社ではパッケージングされたアプリケーションを様々な場所で動かせ れるような工夫を行っている ◦ コンテナベースイメージには jdk8u191 以降を利用する • ビルド ◦ ビルドキャッシュの管理をいかに楽に正しくおこなえるかで 全体のビルド体験がよくなる ◦ ビルドはSaaSに乗れるのであればのるのが良さそう ▪ キャッシュの扱い等がやはり優れている 26
27. 働くをもっと楽しく、創造的に