新しいDiegoの仕組み入門

Kazuto Kusama @jacopen

Enlightened A13

普段はCloud Foundry関連の仕事もしています

Diegoとは何か？ の前に、今のCFの復習

Cloud Controller

APIの提供やコントロールを行うCCがあって

Cloud Controller DEA

ユーザーアプリを動かすDEAがあって

Router

Cloud Controller DEA

リクエストをルーティングするRouterがあって

Router

Cloud Controller DEA HM

アプリの死活監視をするHealth Managerがあって

Router

Cloud Controller DEA HM

NATS

それらのコンポーネントはNATSで通信をする

Router

Cloud Controller DEA HM

NATS

これが今のCloud Foundry

DEA + Go = Diego?

Router

Cloud Controller Diego HM

NATS

こうなる？

違います。

DiegoはCloud Foundryにとって 初めての、アーキテクチャの大変革

覚えて欲しいこと

今回の流れ• Diegoのアーキテクチャ解説

• DiegoのDocker & .NET対応について

• CFとDiegoの関係

• 深掘りはまた次回！

今回の注意点• 20分のセッションに80ページ詰め込んでいるため、かなり駆け足になるよ

• Cloud Foundry (特に、現在のV2)をある程度知っている人向けなので、初めての人には分からない話があるかも

• 分からない事があったら後で聞いてください

• デモも考えたけど分かりにくすぎたので、また今度！

V1 2011～2013

V2 2013～

初めての変革はV2じゃないの？

Router

Cloud Controller DEA HM

NATS (Ruby nats)

V1

Gorouter

Cloud Controller

ngDEAng HM

9000

NATS(gnatsd)

V2

V1→V2では• APIが新しくなった

• 各コンポーネントが1から書き直された(GoとかRubyとか)

• Buildpack対応や、Servicesの刷新が入った

• 全体のアーキテクチャは、V1と大差ない

第1章

Diegoのアーキテクチャを見ていこう

これがDiegoのコンポーネント

出典: https://github.com/cloudfoundry-incubator/diego-design-notes

この部分がDiego

大きく分けると4つの役割に分けられる

Receptor

Cell Brain

BBS

APIを提供

コンテナを動かす スケジューリング

情報を集約する

Cell

Receptor

Cell Brain

BBS

APIを提供

コンテナを動かす スケジューリング

情報を集約する

Cellの仕事• コンテナを動かすのが最大の役割

• コンテナはWardenのGo版、Gardenを使って動かす

• コンテナの動かし方には、一時的なTaskと、永続的なLRP(Long Runnning Process)という2種類がある。

• たとえばDropletを作るStaging作業はTask、ユーザーアプリはLRPとして動作する

Brain

Receptor

Cell Brain

BBS

APIを提供

コンテナを動かす スケジューリング

情報を集約する

Brain

• スケジューリングを司る Auctioneer

• コンテナ数の管理を行うConverger

• メトリクスを収集するMetrics Server

これまでのスケジューリング

CC

DEADEA DEA

3GB空いてるよ

2GBいける

4GB余裕がある！

CC

DEADEA DEA

App

お前に任せる

Diegoのスケジューリング

Auctioneer

CellCell Cell

10!

App

こんな仕事があるぞ!

12! 15!

30! 20!

Diegoのスケジューリング• Auctioneerが、TaskやLRPに関するオークションを掲示する

• Cell内のRepが、オークションに参加する

• 最終的に残ったRepのCellが選ばれる

• TaskやLRPを動かすためのStart Auctionと、ダブついたLRPを止めるStop Auctionの2種類がある

Auction形式のメリット• あるらしいんだけど、今度誰か解説して！

Convergerの役割• クラスタ内のインスタンス数(=コンテナ数)の一貫性を担保する

• アプリのインスタンス数が不足していれば、Start Auctionをリクエストする

• インスタンス数が過剰であれば、Stop Auctionをリクエストする

• これまでのHealth Managerに近い

Brain

Receptor

Cell Brain

BBS

APIを提供

コンテナを動かす スケジューリング

情報を集約する

BBS

• etcdそのもの

• DiegoのコンポーネントはNATSではなくetcdで情報をやり取りする

Brain

Receptor

Cell Brain

BBS

APIを提供

コンテナを動かす スケジューリング

情報を集約する

Receptor

• APIを提供する

なるほど、これまでのCloud Controllerに相当するのがReceptorなのね！

違います。

Receptorが提供するAPI

• TaskのCRUD

• LRPのCRUD

• CellのList

以上！

Receptorの役割• APIでTask/LRPのリクエストを受け付けて、

Diegoのクラスタ内に展開する

• アプリ作成のリクエストであれば、Start Auctionにかける

• 削除のリクエストであれば、Stop Auctionにかける

• PaaSとしての機能は提供しない

マルチノードで組むならこんな感じ？

Receptor

Cell

Brain

BBS Cell

Cell

あれ、これって･･･

Receptor

Cell

Brain

BBS Cell

Cell

Kubernetes

Master

Minion

Minion

Minion

KubernetesとDiego似ているところ

• スケジューラー(Master<=>Brain) とランナー(Minion<=>Cell) が、etcdを通して疎結合に連携する

違うところ • スケジューリングの仕組み

• コンテナの仕組み (Docker<=>Garden)

Diegoは単体で動くってこと？• 答えはYes.

• Latticeという、Diego+リクエストルータ+ログストリーミングのセットを構築出来る

仕組みが提供されているhttps://github.com/cloudfoundry-incubator/lattice

Lattice

Diego

Gorouter

Router Emitter Receptor

Cell

Cell

App1

App2

App2

1. Receptorから、アプリとルートの情報を取得

2. Gorouterに登録

3. Gorouterがルーティング

app1.example.com

app2.example.com

Latticeを単体で触ってみた感想• Kubernetesほど機能は充実していないが、その分シンプル

• リクエストルーティングの仕組みがあるため、80番さえ空いていればOK。あとはURLを見て自動的にルーティングしてくれる

• KubernetesのServiceの仕組みはちょっと分かりづらいが、こっちは直感的

• TerraformでAWS, GCE,Digital Oceanに、簡単にマルチノードデプロイできる BOSHとは

第2章

DiegoのDocker / .NET対応

やっぱりみんな、気になるよね

DiegoはDocker対応！

DiegoはDocker対応！Docker image

Cellの中身

Cell

rep

exector

garden

garden-linux

Container Container Container Container Container Container

Container Container Container Container Container Container

Container Container

Container Container

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.

Garden-linuxのDocker対応

• Buildpackを用いて作られたDropletが渡されたら、それを使ってコンテナを作成(今までの仕組みと同等)

• Docker imageへのパスが渡されたら、Docker imageをダウンロード。全てのレイヤーをフェッチし、GardenコンテナのRootfsとして設定

• Dockerコンテナが動くのではなく、GardenコンテナのRootfsとしてDocker imageが指定出来るという仕組み

• なので、Dockerfileには非対応

Garden-linuxのDocker対応

• 将来的にはGarden-linuxをlibcontainerを使った実装にする構想があるらしい

.NET対応の話

最近オープンソース化された.NET Framework

http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx

.NET対応の実装イメージ

オープンソース化された.NET Coreを使って実装？

(.NET Buildpackとか)

WindowsにGardenを

実装して直接.NETアプリを動かす？

.NET対応の実装イメージ

オープンソース化された.NET Coreを使って実装？

(.NET Buildpackとか)

WindowsにGardenを

実装して直接.NETアプリを動かす

IronFoundry

IronFoundry

• Century LinkによるCloud FoundryのWindows対応

• v1の頃からWindows対応のCloud Foundryフォークを作っていた

• 現在はCloud Foundry FoundationのIncubationに採択され、Gardenの実装が進められている

https://github.com/cloudfoundry-incubator/garden-windows

Windows Cell

rep (Go)

exector(Go)

Containerizer (C#)

if_warden (C#)

Container Container Container Container Container Container Container Container

garden-windows(Go)

Windows Container

• どうやってWindowsでコンテナを実現しているのかは、追えてない。(誰か調べて！)

• https://github.com/IronFoundry/if_warden/がそれっぽい

• IISのHostable Web Coreというマイナーな機能を使っているらしい

第3章

Cloud FoundryのDiego integration

Cloud Foundry + Diego

Gorouter

Cloud Controller

ngDEAng HM

9000

NATS(gnatsd)

今のV2の仕組みは、そのまま残せる

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

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経由で行われる

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へのリクエストは、従来通り行われる

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に 送られる。

Diegoへのリクエスト• GET /v3/apps • POST /v3/apps • PUT /v3/apps/:guid/processes

主にDiego向けとして、v3 APIが定義されている

CFのDiego対応まとめ• Cloud Controllerが従来のV2と、Diego向けの

V3に両対応することで、V1→V2のような仕切り直しになる事態は避けられた

• 一方、巨大なスタックとなり運用が大変そう・・・

• 将来的には、Route EmitterやCC Bridgeは廃止予定(それぞれRouter、CCにマージされる)

• ちなみに、まだV3 API対応クライアントは無い

Diegoの投入時期• 現在は “Production Beta”

• そう遠くないうちに正式リリースになるはずだが、今日の資料作成のためにDiegoを組んでいる間にもさまざまな変更が・・・。

• どこも「Docker対応」を謳いたいはずなので、正式リリース後は多くのサービスで取り込まれるんじゃないかと推測

Diegoを知るにはどうすれば？• フルセットで組むなら cf-release + diego-

release • でもBOSHつらいので、まずはlatticeを触ってみるのがお勧め

• https://github.com/cloudfoundry-incubator/lattice

• GCEの無料枠でさくっと試せる！