Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門
•
52 j'aime•13,725 vues
第25回PaaS勉強会で発表した資料です。 Cloud Foundryの新アーキテクチャ、Diegoについて。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門
Similaire à Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門 (20)
Plus de Kazuto Kusama
Plus de Kazuto Kusama (20)
Dernier
Dernier (11)
Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門
- 13. DEA + Go = Diego?
- 15. 違います。
- 17. 今回の流れ • Diegoのアーキテクチャ解説 • DiegoのDocker & .NET対応について • CFとDiegoの関係 • 深掘りはまた次回！
- 18. 今回の注意点 • 20分のセッションに80ページ詰め込んでいる ため、かなり駆け足になるよ • Cloud Foundry (特に、現在のV2)をある程度 知っている人向けなので、初めての人には分 からない話があるかも • 分からない事があったら後で聞いてください • デモも考えたけど分かりにくすぎたので、 また今度！
- 20. Router Cloud Controller DEA HM NATS (Ruby nats) V1
- 22. V1→V2では • APIが新しくなった • 各コンポーネントが1から書き直された(Goと かRubyとか) • Buildpack対応や、Servicesの刷新が入った • 全体のアーキテクチャは、V1と大差ない
- 25. この部分がDiego
- 28. Cellの仕事 • コンテナを動かすのが最大の役割 • コンテナはWardenのGo版、Gardenを使って 動かす • コンテナの動かし方には、一時的なTaskと、 永続的なLRP(Long Runnning Process)という2 種類がある。 • たとえばDropletを作るStaging作業はTask、 ユーザーアプリはLRPとして動作する
- 30. Brain • スケジューリングを司る Auctioneer • コンテナ数の管理を行うConverger • メトリクスを収集するMetrics Server
- 33. Diegoのスケジューリング • Auctioneerが、TaskやLRPに関するオークショ ンを掲示する • Cell内のRepが、オークションに参加する • 最終的に残ったRepのCellが選ばれる • TaskやLRPを動かすためのStart Auctionと、ダ ブついたLRPを止めるStop Auctionの2種類が ある
- 35. Convergerの役割 • クラスタ内のインスタンス数(=コンテナ数)の 一貫性を担保する • アプリのインスタンス数が不足していれば、 Start Auctionをリクエストする • インスタンス数が過剰であれば、Stop Auction をリクエストする • これまでのHealth Managerに近い
- 41. 違います。
- 42. Receptorが提供するAPI • TaskのCRUD • LRPのCRUD • CellのList 以上！
- 43. Receptorの役割 • APIでTask/LRPのリクエストを受け付けて、 Diegoのクラスタ内に展開する • アプリ作成のリクエストであれば、 Start Auctionにかける • 削除のリクエストであれば、 Stop Auctionにかける • PaaSとしての機能は提供しない
- 47. KubernetesとDiego 似ているところ • スケジューラー(Master<=>Brain) と ランナー(Minion<=>Cell) が、etcdを通して 疎結合に連携する 違うところ • スケジューリングの仕組み • コンテナの仕組み (Docker<=>Garden)
- 49. Lattice
- 50. Diego Gorouter Router Emitter Receptor Cell Cell App1 App2 App2 1. Receptorから、アプリと ルートの情報を取得 2. Gorouterに登録 3. Gorouterがルーティング app1.example.com app2.example.com
- 51. Latticeを単体で触ってみた感想 • Kubernetesほど機能は充実していないが、 その分シンプル • リクエストルーティングの仕組みがあるため、 80番さえ空いていればOK。あとはURLを見て 自動的にルーティングしてくれる • KubernetesのServiceの仕組みはちょっと分か りづらいが、こっちは直感的 • TerraformでAWS, GCE,Digital Oceanに、 簡単にマルチノードデプロイできる BOSHとは
- 53. やっぱりみんな、気になるよね
- 54. DiegoはDocker対応！
- 56. Cellの中身 Cell rep exector garden garden-linux Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container Container
- 57. 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.
- 58. Garden-linuxのDocker対応 • Buildpackを用いて作られたDropletが渡されたら、 それを使ってコンテナを作成(今までの仕組みと同等) • Docker imageへのパスが渡されたら、Docker image をダウンロード。全てのレイヤーをフェッチし、 GardenコンテナのRootfsとして設定 • Dockerコンテナが動くのではなく、 GardenコンテナのRootfsとしてDocker imageが 指定出来るという仕組み • なので、Dockerfileには非対応
- 60. .NET対応の話
- 62. .NET対応の実装イメージ オープンソース化された .NET Coreを使って実装？ (.NET Buildpackとか) WindowsにGardenを 実装して直接.NETアプリを 動かす？
- 63. .NET対応の実装イメージ オープンソース化された .NET Coreを使って実装？ (.NET Buildpackとか) WindowsにGardenを 実装して直接.NETアプリを 動かす
- 64. IronFoundry
- 65. IronFoundry • Century LinkによるCloud FoundryのWindows対応 • v1の頃からWindows対応のCloud Foundryフォーク を作っていた • 現在はCloud Foundry FoundationのIncubationに採 択され、Gardenの実装が進められている
- 67. Windows Cell rep (Go) exector (Go) Containerizer (C#) if_warden (C#) Container Container Container Container Container Container Container Container garden-windows (Go)
- 68. Windows Container • どうやってWindowsでコンテナを実現しているのか は、追えてない。(誰か調べて！) • https://github.com/IronFoundry/if_warden/ がそれっぽい • IISのHostable Web Coreというマイナーな機能を使っ ているらしい
- 70. Cloud Foundry + Diego
- 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
- 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 app app DEAやCell上のアプリ、CC、Receptorへのルートは Gorouterに登録される。ただし、Receptor、CellはRoute Emitter経由で行われる
- 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 V2へのリクエストは、従来通り行われる
- 75. 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に 送られる。
- 76. Diegoへのリクエスト • GET /v3/apps • POST /v3/apps • PUT /v3/apps/:guid/processes 主にDiego向けとして、v3 APIが定義されている
- 77. CFのDiego対応まとめ • Cloud Controllerが従来のV2と、Diego向けの V3に両対応することで、V1→V2のような仕切 り直しになる事態は避けられた • 一方、巨大なスタックとなり運用が大変そ う・・・ • 将来的には、Route EmitterやCC Bridgeは廃止 予定(それぞれRouter、CCにマージされる) • ちなみに、まだV3 API対応クライアントは無い
- 78. Diegoの投入時期 • 現在は “Production Beta” • そう遠くないうちに正式リリースになるはず だが、今日の資料作成のためにDiegoを組んで いる間にもさまざまな変更が・・・。 • どこも「Docker対応」を謳いたいはずなの で、正式リリース後は多くのサービスで取り 込まれるんじゃないかと推測
- 79. Diegoを知るにはどうすれば？ • フルセットで組むなら cf-release + diego- release • でもBOSHつらいので、まずはlatticeを触って みるのがお勧め • https://github.com/cloudfoundry-incubator/lattice • GCEの無料枠でさくっと試せる！