Cloud Native BuildpackでToil減らしていこうという話

NoOps Meetup Tokyo #4 で発表したスライドです。
コンテナイメージ作るのもそうだけど、その後のメンテナンスの視点は意外と忘れられがち。 Cloud Native Buildpackの仕組みを使えば、もしかしたらそのToilを減らせるかもしれません。

Transcript

1. で 減らしていこうという話
2. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen
3. 初
4. 第 回からサポーターとして参加
5. きっかけ にサポーターとして 参加してみません？ お、いいですよー で、 って何？
6. 運用が無い？ 必要無いってこと？
7. じゃん
8. ぐぐってみた
9. https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00263/041900001/
10. じゃん
11. 参加してみた
13. じゃん
14. なら任せろ • 勉強会 年から開催 • 現時点で 回開催
15. ぼくの昔の話
16. 年くらい前 受託開発ばっかりだとあれだし、 うちもウェブサービスやることにした いいけど誰が運用するんすか キミができるやろ、よろしく！ ちょっとまって
17. で、そのとき選んだのが
18. 結果 • 運用担当たった 人で、 サービスの構築・運用まで 全部出来てしまった • 自分が退職した後、つい最近までサービス提供出来ていたらしい すげえ
19. その後 に強い興味を抱くようになったところで、 である が登場 個人的な趣味として を触り始めた が、某通信会社がそれをベースにした を提 供する計画だと聞く ⇒ やりたいです！ の一心で転職 年
20. その後 某通信会社で 年間 の開発に携わったの ち、 の本家本元である に 転職 で衝撃を受けて以降、 年にわたって を本業で追い続けることに
21. ってなにがすごい？
22. もちろん満たしています https://www.slideshare.net/hiromasaoka/15-noops
23. や 使っている人？
24. 書くなんて 造作もないっていう人？
25. の モデル $ docker build $ docker push $ docker run 書いて イメージ作って どこかのレジストリに上げて 実行する
26. の モデル $ docker build $ docker push $ docker run 書いて イメージ作って どこかのレジストリに上げて 実行する 特にこのへんが大変
27. ここ特化の があるレベル https://build.connpass.com/event/98947/
28. 『コンテナ疲れ』と戦う、 ・ ・ の活用法 考えることが増えて面倒くさい・・・
29. これまでの のワークフロー の作成 の作成
30. これまでの のワークフロー の作成 の作成 どの にするか の書き方の知識 イメージビルドの環境 プライベートレジストリへの
31. これまでの のワークフロー の作成 の作成 どの にするか の書き方の知識 イメージビルドの環境 プライベートレジストリへの 詳しい人
32. これまでの のワークフロー の作成 の作成 どの にするか の書き方の知識 イメージビルドの環境 プライベートレジストリへの この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人
33. これまでの のワークフロー の作成 の作成 この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人 クソが
34. これまでの のワークフロー の作成 の作成 この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人 クソが じゃん
35. 誰もが同じようなことをやる の作成 の作成 の作成 の作成 の作成 の作成
36. 誰もが同じようなことをやる の作成 の作成 の作成 の作成 の作成 の作成 この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人
37. 誰もが同じようなことをやる の作成 の作成 の作成 の作成 の作成 の作成 この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人 クソが クソが クソが
38. 誰もが同じようなことをやる の作成 の作成 の作成 の作成 の作成 の作成 この 酷いですね 笑 イメージサイズでかいですよ 笑 詳しい人 クソが クソが クソが じゃん
39. 一方 ならこうなる
40. HerokuとCFにアプリをデプロイしてみるデモをしました。動画はこちら
41. $ cf push の例 コマンド一発 あとは全部おまかせ
42. コンテナイメージ コンテナレジストリ マニフェスト $ cf push
43. なぜこんなことが出来るのか
45. がうまいことやってくれる Buildpack 実行 $ cf push
46. とは によって作られた、 上で任意の言語や フレームワークを利用できるようにする仕組み や 、 などでも利用可能
47. のしくみ
48. デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージ Buildpack deploy
49. デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージ Buildpack deploy
50. デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージ Buildpack deploy
51. デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージ Buildpack deploy
52. 必須スクリプト で使える の場合、 以下にな らず以下のスクリプトが存在します • • •
53. 言語を検出するためのスクリプト
54. #!/usr/bin/env bash BUILD_DIR=$1 # Exit early if app is clearly not Python. if [ ! -f "$BUILD_DIR/requirements.txt" ] && [ ! -f "$BUILD_DIR/setup.py" ] && [ ! -f "$BUILD_DIR/Pipfile" ]; then exit 1 fi echo Python か か が無かったら 見つかった場合、 と文字を出して終わる
55. $ cf push のコード ① を実行 ではないので が返る ② を実行 ではないので が返る ③ を実行 ではないので が返る ④ を実行 のファイルがあるので が返る ⇒ を使った次の処理へ
56. か が返せればいいので、 でなくともよい。 例 で を実行している 例 の中で を実行している
57. 実行可能なイメージを作成するフェーズ 言語の実行環境の設定 • たとえば 自体、 自体の実行環境 ライブラリ類の解決 • なら 、 なら など ここでその名の通り環境のコンパイルを行うことができるが、実際のとこ ろは処理時間の都合上、コンパイル済みのバイナリを持ってくることが 多い
58. このフェーズの処理は複雑なことが多いため、外部のスクリプトを呼ん で実行しているケースが多い 例
59. $ cf push のコード compile script
60. 実行時に必要なメタデータを生成するスクリプト
61. 適用後 デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージ Buildpack deploy
62. 内部ではコンテナを活用 を使って を作 成し、 で実行 開発者はコンテナについて 意識する必要なし の場合
63. ここまでの話で 重要なポイント
64. • や は、開発者が楽になるような仕組みを によって実現している • の で、アプリがどんな 言語・フレームワークかを自動検出している • などを通じ、最終的にはアプリやランタイムがセットになっ たコンテナイメージが生成される
65. あれ
66. これでコンテナイメージ作れば いいんでは・・・
68. と により、 年の 月から開始されたプロジェクト と の の仕様を統一。 ソースコードから イメージを作成できる仕組みに
69. プロジェクト入り
70. $ ls README.md app manifest.yml node_modules package.json public server.js views $ pack build jacopen/testapp 2018/11/19 17:14:31 Pulling builder image 'packs/samples' (use --no-pull flag to skip this step) 2018/11/19 17:14:33 Selected run image 'packs/run' from stack 'io.buildpacks.stacks.bionic' 2018/11/19 17:14:33 Pulling run image 'packs/run' (use --no-pull flag to skip this step) *** DETECTING: 2018/11/19 08:14:43 Group: Sample Node.js Buildpack: pass *** ANALYZING: Reading information from previous image for possible re-use 2018/11/19 17:14:44 WARNING: skipping analyze, image not found 中略 ---> 170c76d2c366 Successfully built 170c76d2c366 Successfully tagged jacopen/testapp:latest Dockerfileすら無いnode.jsアプリのディレクトリで pack buildコマンドを一発打つだけで、 自動的にイメージのビルドやってくれて超らくちん　というデモをしました
71. 従来の との違い
72. 仕様がみっちり決められた https://github.com/buildpack/spec
73. 内部的には 扱い
75. アプリケーションのソースコードを実行 可能なアーティファクトに変換するソフト ウェア
76. • 考え方はこれまでの とあまり変わらない • と の コマンドが必須 • は無くなった
77. を利用し、アーティファクトを イメージに変換するソフトウェア
78. • つのフェーズを経て イメージを作成 • 最後に実行 https://github.com/buildpack/spec/blob/master/buildpack.md#launch
79. https://github.com/buildpack/spec/blob/master/buildpack.md#launch の を 実行して
80. https://github.com/buildpack/spec/blob/master/buildpack.md#launch 既存イメージを解析して、変 更点を検出
81. https://github.com/buildpack/spec/blob/master/buildpack.md#launch 変更点があった部分に対し、 の を実行
82. https://github.com/buildpack/spec/blob/master/buildpack.md#launch 変更されたレイヤーを イメージに反映
83. には、 のリファレンス実装がある
84. コマンドラインから を利用したイメージ作成ができるツール。 今回のデモで利用 リファレンス実装を利用している
85. アプリ開発者 エンドユーザー に を利用した機能を提供するソ フトウェア
86. 対応
87. 対応
89. によってもたらされるもの • 開発者の生産性向上 ◦ アプリケーション開発に注力できる ▪ どうやって 書くかとか気にしなくていい ◦ 一貫した操作でデプロイできる ▪ ▪ コマンド叩けば様々な言語で同様にイメージ作成できる • 持続可能な運用 ◦ のガードレールの元で開発者の生産性を高める ◦ スケーラブルなセキュリティ
90. によってもたらされるもの • 開発者の生産性向上 ◦ アプリケーション開発に注力できる ▪ どうやって 書くかとか気にしなくていい ◦ 一貫した操作でデプロイできる ▪ ▪ コマンド叩けば様々な言語で同様にイメージ作成できる • 持続可能な運用 ◦ のガードレールの元で開発者の生産性を高める ◦ スケーラブルなセキュリティ
91. これまでの のワークフロー の作成 の作成 手動、もしくはこれに相当する作業を CIツールで実施
92. これまでの のワークフロー の作成 の作成 手動、もしくはこれに相当する作業を CIツールで実施 FROM python:3.5.2 RUN apt-get update &&\ apt-get install xxxxxxxxx COPY xxxx xxxx CMD [xxxx] ベースイメージに 脆弱性が含まれていたら？ パッケージに 脆弱性が含まれていたら？
93. これまでの のワークフロー の作成 の作成 手動、もしくはこれに相当する作業を CIツールで実施 FROM python:3.5.2 RUN apt-get update &&\ apt-get install xxxxxxxxx COPY xxxx xxxx CMD [xxxx] ベースイメージに 脆弱性が含まれていたら？ パッケージに 脆弱性が含まれていたら？ 脆弱性が発見される度に Dockerfileを書き換え、イメージを作り直 す作業を開発者がしなくてはいけない それどころか、対応が後回しになって放置されるかもしれない
94. これまでの のワークフロー の作成 の作成 FROM python:3.5.2 RUN apt-get update &&\ apt-get install xxxxxxxxx COPY xxxx xxxx CMD [xxxx] を が管理？
95. これまでの のワークフロー の作成 の作成 FROM python:3.5.2 RUN apt-get update &&\ apt-get install xxxxxxxxx COPY xxxx xxxx CMD [xxxx] を が管理？ 開発チームが増え、運用対象が増えると管理が回らない (スケーラビリティの問題 ) コミュニケーションコストの問題で開発効率が落ちる
96. のときのワークフロー の管理と の提供 の作成
97. のときのワークフロー の管理と の提供 の作成 脆弱性が見つかったら、 自体をアッ プデート 再適用してイメージ再作成
98. のときのワークフロー
99. のときのワークフロー
100. 今ある • の は、順次 対応が行われる ◦ 現時点では が利用可能 ◦ https://github.com/cloudfoundry/nodejs-cnb.git • Herokuからは、JavaのBuildpackがリリース ◦ https://github.com/heroku/java-buildpack • Knativeの上でFaaSを実現するriff向けのbuildpack ◦ https://github.com/projectriff/riff-buildpack
101. まとめ のノウハウが凝縮されているのが は、コンテナイメージの作成と 運用に関わる面倒なところを楽にしてくれる 単にイメージを作るだけでなく、ライフサイクルまで意識 して技術選択すると良いかも
102. その他詳しい情報 まずは試そう 仕様を詳しく知るなら Buildpackのサンプルを 見るなら