Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門

9,529 views

Published on

第25回PaaS勉強会で発表した資料です。
Cloud Foundryの新アーキテクチャ、Diegoについて。

Published in: Technology
0 Comments
48 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,529
On SlideShare
0
From Embeds
0
Number of Embeds
1,669
Actions
Shares
0
Downloads
147
Comments
0
Likes
48
Embeds 0
No embeds

No notes for slide

Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門

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

×