Transcript

• 1. 新しいDiegoの仕組み入門
• 2. Kazuto Kusama @jacopen
• 3. Enlightened A13
• 4. 普段はCloud Foundry関連の仕事もしています
• 5. Diegoとは何か？ の前に、今のCFの復習
• 6. Cloud Controller APIの提供やコントロールを行うCCがあって
• 7. Cloud Controller DEA ユーザーアプリを動かすDEAがあって
• 8. Router Cloud Controller DEA リクエストをルーティングするRouterがあって
• 9. Router Cloud Controller DEA HM アプリの死活監視をするHealth Managerがあって
• 10. Router Cloud Controller DEA HM NATS それらのコンポーネントはNATSで通信をする
• 11. Router Cloud Controller DEA HM NATS これが今のCloud Foundry
• 12. DEA + Go = Diego?
• 13. Router Cloud Controller Diego HM NATS こうなる？
• 14. 違います。
• 15. DiegoはCloud Foundryにとって 初めての、アーキテクチャの大変革 覚えて欲しいこと
• 16. 今回の流れ • Diegoのアーキテクチャ解説 • DiegoのDocker & .NET対応について • CFとDiegoの関係 • 深掘りはまた次回！
• 17. 今回の注意点 • 20分のセッションに80ページ詰め込んでいる ため、かなり駆け足になるよ • Cloud Foundry (特に、現在のV2)をある程度 知っている人向けなので、初めての人には分 からない話があるかも • 分からない事があったら後で聞いてください • デモも考えたけど分かりにくすぎたので、
 また今度！
• 18. V1 2011∼2013 V2 2013∼ 初めての変革はV2じゃないの？
• 19. Router Cloud Controller DEA HM NATS (Ruby nats) V1
• 20. Gorouter Cloud Controller ng DEAng HM
 9000 NATS(gnatsd) V2
• 21. V1→V2では • APIが新しくなった • 各コンポーネントが1から書き直された(Goと かRubyとか) • Buildpack対応や、Servicesの刷新が入った • 全体のアーキテクチャは、V1と大差ない
• 22. 第1章 Diegoの
 アーキテクチャを見ていこう
• 23. これがDiegoのコンポーネント 出典: https://github.com/cloudfoundry-incubator/diego-design-notes
• 24. この部分がDiego
• 25. 大きく分けると4つの役割に分けられる Receptor Cell Brain BBS APIを提供 コンテナを動かす スケジューリング 情報を集約する
• 26. Cell Receptor Cell Brain BBS APIを提供 コンテナを動かす スケジューリング 情報を集約する
• 27. Cellの仕事 • コンテナを動かすのが最大の役割 • コンテナはWardenのGo版、Gardenを使って 動かす • コンテナの動かし方には、一時的なTaskと、 永続的なLRP(Long Runnning Process)という2 種類がある。 • たとえばDropletを作るStaging作業はTask、 ユーザーアプリはLRPとして動作する
• 28. Brain Receptor Cell Brain BBS APIを提供 コンテナを動かす スケジューリング 情報を集約する
• 29. Brain • スケジューリングを司る Auctioneer • コンテナ数の管理を行うConverger • メトリクスを収集するMetrics Server
• 30. これまでのスケジューリング CC DEADEA DEA 3GB 空いてるよ 2GB いける 4GB 余裕がある！ CC DEADEA DEA App お前に 任せる
• 31. Diegoのスケジューリング Auctioneer CellCell Cell 10! App こんな仕事があるぞ! 12! 15! 30! 20!
• 32. Diegoのスケジューリング • Auctioneerが、TaskやLRPに関するオークショ ンを掲示する • Cell内のRepが、オークションに参加する • 最終的に残ったRepのCellが選ばれる • TaskやLRPを動かすためのStart Auctionと、ダ ブついたLRPを止めるStop Auctionの2種類が ある
• 33. Auction形式のメリット • あるらしいんだけど、今度誰か解説して！
• 34. Convergerの役割 • クラスタ内のインスタンス数(=コンテナ数)の 一貫性を担保する • アプリのインスタンス数が不足していれば、 Start Auctionをリクエストする • インスタンス数が過剰であれば、Stop Auction をリクエストする • これまでのHealth Managerに近い
• 35. Brain Receptor Cell Brain BBS APIを提供 コンテナを動かす スケジューリング 情報を集約する
• 36. BBS • etcdそのもの • Diegoのコンポーネントは
 NATSではなくetcdで情報をやり取りする
• 37. Brain Receptor Cell Brain BBS APIを提供 コンテナを動かす スケジューリング 情報を集約する
• 38. Receptor • APIを提供する
• 39. なるほど、これまでのCloud Controllerに
 相当するのがReceptorなのね！
• 40. 違います。
• 41. Receptorが提供するAPI • TaskのCRUD • LRPのCRUD • CellのList 以上！
• 42. Receptorの役割 • APIでTask/LRPのリクエストを受け付けて、 Diegoのクラスタ内に展開する • アプリ作成のリクエストであれば、
 Start Auctionにかける • 削除のリクエストであれば、
 Stop Auctionにかける • PaaSとしての機能は提供しない
• 43. マルチノードで組むならこんな感じ？ Receptor Cell Brain BBS Cell Cell
• 44. あれ、これって･･･ Receptor Cell Brain BBS Cell Cell
• 45. Kubernetes Master Minion Minion Minion
• 46. KubernetesとDiego 似ているところ • スケジューラー(Master<=>Brain) と
 ランナー(Minion<=>Cell) が、etcdを通して 疎結合に連携する 違うところ • スケジューリングの仕組み • コンテナの仕組み (Docker<=>Garden)
• 47. Diegoは単体で動くってこと？ • 答えはYes. • Latticeという、Diego+リクエストルータ
 +ログストリーミングのセットを構築出来る
 仕組みが提供されている
 https://github.com/cloudfoundry-incubator/lattice
• 48. Lattice
• 49. Diego Gorouter Router Emitter Receptor Cell Cell App1 App2 App2 1. Receptorから、アプリと
 ルートの情報を取得 2. Gorouterに登録 3. Gorouterがルーティング app1.example.com app2.example.com
• 50. Latticeを単体で触ってみた感想 • Kubernetesほど機能は充実していないが、
 その分シンプル • リクエストルーティングの仕組みがあるため、 80番さえ空いていればOK。あとはURLを見て 自動的にルーティングしてくれる • KubernetesのServiceの仕組みはちょっと分か りづらいが、こっちは直感的 • TerraformでAWS, GCE,Digital Oceanに、
 簡単にマルチノードデプロイできる BOSHとは
• 51. 第2章 Diegoの
 Docker / .NET対応
• 52. やっぱりみんな、気になるよね
• 53. DiegoはDocker対応！
• 54. DiegoはDocker対応！ Docker image
• 55. Cellの中身 Cell rep exector garden garden-linux Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container
• 56. Garden garden garden-linux Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Garden コンテナの作成/削除やリソース制限、ネットワーク設 定などを定義したインターフェース Garden Backend 実際にコンテナの作成や管理を行うバックエンド
 サービス。各プラットフォームごとに用意される。
 Linux向けのBackend実装がgarden-linux.
• 57. Garden-linuxのDocker対応 • Buildpackを用いて作られたDropletが渡されたら、 それを使ってコンテナを作成(今までの仕組みと同等) • Docker imageへのパスが渡されたら、Docker image をダウンロード。全てのレイヤーをフェッチし、 GardenコンテナのRootfsとして設定 • Dockerコンテナが動くのではなく、
 GardenコンテナのRootfsとしてDocker imageが
 指定出来るという仕組み • なので、Dockerfileには非対応
• 58. Garden-linuxのDocker対応 • 将来的にはGarden-linuxをlibcontainerを使った実装 にする構想があるらしい
• 59. .NET対応の話
• 60. 最近オープンソース化された.NET Framework http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
• 61. .NET対応の実装イメージ オープンソース化された
 .NET Coreを使って実装？
 (.NET Buildpackとか) WindowsにGardenを
 実装して直接.NETアプリを
 動かす？
• 62. .NET対応の実装イメージ オープンソース化された
 .NET Coreを使って実装？
 (.NET Buildpackとか) WindowsにGardenを
 実装して直接.NETアプリを
 動かす
• 63. IronFoundry
• 64. IronFoundry • Century LinkによるCloud FoundryのWindows対応 • v1の頃からWindows対応のCloud Foundryフォーク を作っていた • 現在はCloud Foundry FoundationのIncubationに採 択され、Gardenの実装が進められている
• 65. https://github.com/cloudfoundry-incubator/garden-windows
• 66. Windows Cell rep (Go) exector
 (Go) Containerizer (C#) if_warden (C#) Container Container Container Container Container Container Container Container garden-windows
 (Go)
• 67. Windows Container • どうやってWindowsでコンテナを実現しているのか は、追えてない。(誰か調べて！) • https://github.com/IronFoundry/if_warden/
 がそれっぽい • IISのHostable Web Coreというマイナーな機能を使っ ているらしい
• 68. 第3章 Cloud Foundryの
 Diego integration
• 69. Cloud Foundry + Diego
• 70. Gorouter Cloud Controller ng DEAng HM
 9000 NATS(gnatsd) 今のV2の仕組みは、そのまま残せる
• 71. DEAs Gorouter etcd NATS HM UAA Doppler Traffic controller Cloud Controller CC Bridge Route Emitter Receptor Cells Brain Common layer V2 layer Diego layer Bridge layer Routing layer
• 72. DEAs Gorouter etcd NATS HM UAA Doppler Traffic controller Cloud Controller CC Bridge Route Emitter Receptor Cells Brain Common layer V2 layer Diego layer Bridge layer Routing layer app app app app DEAやCell上のアプリ、CC、Receptorへのルートは Gorouterに登録される。ただし、Receptor、CellはRoute Emitter経由で行われる
• 73. DEAs Gorouter etcd NATS HM UAA Doppler Traffic controller Cloud Controller CC Bridge Route Emitter Receptor Cells Brain Common layer V2 layer Diego layer Bridge layer Routing layer app app V2へのリクエストは、従来通り行われる
• 74. DEAs Gorouter etcd NATS HM UAA Doppler Traffic controller Cloud Controller CC Bridge Route Emitter Receptor Cells Brain Common layer V2 layer Diego layer Bridge layer Routing layer app app Diegoへのリクエストは、CC Bridge経由でReceptorに 送られる。
• 75. Diegoへのリクエスト • GET /v3/apps • POST /v3/apps • PUT /v3/apps/:guid/processes 主にDiego向けとして、v3 APIが定義されている
• 76. CFのDiego対応まとめ • Cloud Controllerが従来のV2と、Diego向けの V3に両対応することで、V1→V2のような仕切 り直しになる事態は避けられた • 一方、巨大なスタックとなり運用が大変そ う・・・ • 将来的には、Route EmitterやCC Bridgeは廃止 予定(それぞれRouter、CCにマージされる) • ちなみに、まだV3 API対応クライアントは無い
• 77. Diegoの投入時期 • 現在は “Production Beta” • そう遠くないうちに正式リリースになるはず だが、今日の資料作成のためにDiegoを組んで いる間にもさまざまな変更が・・・。 • どこも「Docker対応」を謳いたいはずなの で、正式リリース後は多くのサービスで取り 込まれるんじゃないかと推測
• 78. Diegoを知るにはどうすれば？ • フルセットで組むなら cf-release + diego- release • でもBOSHつらいので、まずはlatticeを触って みるのがお勧め • https://github.com/cloudfoundry-incubator/lattice • GCEの無料枠でさくっと試せる！