注意
イベント直後ビアバッシュのアルコールが入っている状態で書いているので
論理だった内容だったりしたものは無いのでご注意ください。
居酒屋でエンジニアが記憶を掘り起こしながらブツブツ言ってるくらいに思ってくださいませ。
きっともっと正気を保てている人がわかりやすく全体の議論を整理してくれるはず。。。
書いた経緯
Cloud Native Deep Diveというイベントの第一回開催に参加してきたのでその参加レポート
途中でお酒が入ったのでよっているけれども、良いイベントだったので書いておきたいと思い、
アルコールにやられた脳みそで多少記憶があるうちに話しておきます。
参加した方に誰かわかるようにお伝えするとサスペンダーつけてた声のでかい怪しいやつです。
全体の雰囲気
こんな感じで Kubernetesをプロダクション利用する上で色々困ってる話について議論。
流石に、それなりに選りすぐられたメンバーだけあって議論がある程度空中戦にならずにすみました。
(メンバーが豪華過ぎて、俺ほんとに参加してよかったのかと正直ビビっていたのは事実です）
- テーマ１. k8sのマニフェスト管理・デプロイについて
- テーマ2. マニフェストファイル、誰が書いてる？
このあとお酒が入ってフリートーク & それぞれの班からどんなことを話したのか発表。
テーマ1. k8sのマニフェスト管理・デプロイについて
k8sのマニフェスト管理とデプロイについてどうすんの？という話題。
Spinnakerについて話を伺う
Kubernetesで安全にアプリケーションをデプロイするCDツール“Spinnaker”とは
でJapan Container Daysに登壇されていた溝内さんにSpinnakerについてざっくりと説明してもらう。
Spinnaker自体はCDツールなのでCIを準備しなければならないけれども、
CDツールとしてはよくできてますよとのこと。
ただし、問題点はないわけではなくて大きく2つ
- マイクロサービスで作られてるのでコンポーネントが複雑？なのでトラブルシュートが大変
- Javaで書かれている
個人的には後者はOpen JDKに移行するのでは？と答えたのですが、
そのあたり今後の状況についてご存知のかたいらっしゃれば教えてください。
あと、Netflixという超でっかいとこが作っただけあってリソース食うとかもろもろ。
個人的にも、Spinnakerには興味があるけれども、触ってないのでなんとも言えないのですが、
ちょっと知っている範囲で厳しそうだなと感じるのが認証・認可の仕組みを持ち合わせてないこと
（なんとかして外付けせいやみたいな話かもしれませんが、
ELBの認証機能とか使えば認証は今後できるかもしれないですね）
Concourseについて喋る
一応今トライしているプロジェクトではConcourseを使っていたので、その内容について紹介。
内容としてはこんな感じ(一部 @jacopen さんのフォローあり)と紹介。
- yamlでパイプラインを書く
- k8sの操作は @superbrothers さんの作成のリソース(kubernetes-resource)を利用
実は開発効率を上げるという観点で行くとイメージビルドのIO負荷が高すぎて
一番強いサーバがConcourseのサーバであること以外は問題なさそう。
(Dockerfileの書き方とかでの効率化は別として)
では、Concourseの問題点ってなんなの？という風になると
1. k8sのマニフェストのテンプレーティングとかは自前でパイプラインを作成する必要がある点
2. パイプラインを定義したyaml(コード)と実際にConcourseの中で動作しているパイプラインの差分が発生する点
前者は文字通り、Concourseとしてもともと認識されている問題。
sedやらPython + jinja2やら、envsubstやらをつかって頑張るしかないですかねという話題になりました。
jsonnet, ksnonnetとかもありかなという意見ももらいました。
デザパタで解決すべきだし、あんはあるけれども手を出せていない
後者についても同様でパイプラインを定義して適用するにもそれってどういうフローでやるんだっけ？
という話題。
ここはZ Labの方々も課題感があるらしく @jacopen さんからも、Concourseの勉強会で
このあたり掘り下げたいっすねとの言葉をもらったので今後期待してます。
Helmは？意外な議論
意外なことに自分が入っていたテーブルではHelmを使っている人はなし。
以外にテーブル内でも積極的に使おうという人がいなかったのは意外でした。
個人的な理由としては、
- ターゲットスコープとして単一のウェブサービスで使うには外れている感
- あとの引き継ぎの困難さ
というのを上挙げました。
前者は、Helm自身が特定のサービスに紐付かない共通的に使うものをパッケージングして
広く配布するためのものであって、単一のウェブサービス内部でパッケージングする理由って
そこまであるんだっけ？という個人的なHelmに対する認識として説明しました。
後者については、
組織にとって最適な技術スタックは組織の技術レベルに依存する
という観点から説明しました。
Dockerとかコンテナオーケストレーションについての理解が浅い(or 無い)状態の人に
いきなり、コンテナオーケとしては学習コストの高いk8sを入れた上でさらにはhelm、
実はIstioも入れようとしてるなんて話をしても、引き継ぎ先が混乱するばかりで
うまく行かないということをベースに説明させてもらいました。
(このあたりのノウハウある人がいらっしゃれば是非どこかでディスカッションしたいです)
このあたりをさくっと、
Helmに関しては否定的でした
と他のテーブル向けの全体説明で話したところざわっとなりましたが、
このような経緯です。使い物になるとかならないじゃなくて、オーバーキルだという話です。
テーマ2. マニフェストファイル、誰が書いてる
DevとOpsどっちが書く？という話で議論が始まったのですが、
テーブル内、全員Opsという状況でした。
それで現実問題としてOpsで書いているという状況でした。
テーブル内ではDevに書いてほしいよねという方向では一致でしたが、
k8sクラスタに対するリソースのリクエストとかの管理どうすんのよ。
という話題になりました。
そこで議論として上がったのが、
実は、それってk8sのクラスタ構成に依存するんじゃないかという話になりました。
つまり、
プロダクトごとに1クラスタ(シングルテナント)か、
プロダクト共通で1クラスタ(マルチテナント)
といったところの議論になりました。
このあたりの議論についてはアルコールの入ったの脳みそではうまく説明できないですが、
コンウェイの法則とかと交えて整理するとうまい具合に整理できそうですね。
個人的には、
Dockerfile(のドラフト)とシステム構成図さえくれればなんとかしますよ
というマッチョ路線を推したいですが、現実はそうならないことが多いので落としどころは考えないといけない感じですね。
フリートークで出た話題
最後にフリートークがあったのですが、ここでは色々と面白い話が出ましたが
具体的なベンダの名前などが出てくる & お酒が入ってる状態では失言の可能性
しかないので今回は割愛。
割に自分が思っていること、考えていることについては
ニーズが高いかもという感覚は得られたので
Japan Container Days 18.12にCFPでも出そうかと考えています。
まとめ
実はきっちりした結論はどのテーマでも出てないです。
なにせそれぞれについてだけで、
おそらくそれなりに分厚い本が一冊かけるくらい深い領域だからです。
これらについて2時間ガッツリ議論してそれなりに課題感の一致と
うちだとこうしてるといった話題、検討するポイントなどが暗に出てきただけでも
かなり成果として誇れるんじゃないでしょうかという印象です。
今回のイベントを企画してくださったオーガナイザの皆様には感謝の念しかないです。
ありがとうございました。
推敲も何もしてないので勤め先のSlackで怪文書として晒されないことを期待します。