Cloud Foundryas Containerized Services

@jyoshiseJapan Cloud Foundry GroupHewlett Packard Enterprise

自己紹介

• 吉瀬　淳一 (@jyoshise)• 担当 : 　ギター（たまにじゃんけんで負けるとベース）

• 　　　　　　　　　　　

• Lead Architect, Helion Professional Services APJ• IaaS(OpenStack) とか• PaaS(Stackato/CloudFoundry) とか• アジャイル / クラウドネイティブ開発とか

Container as a Service とか言われてますが

3

4

Docker• Swarm

CNCF• Kubernetes

Apache• Mesos

Mesosphere• DC/OS

クラスタ管理 / コンテナスケジューラいろいろ

コンテナとは、って話はしませんが• イメージの管理• Linux ホスト上でのコンテナの実

行管理という Docker の基本機能に加えて、• ホストクラスタのオーケストレー

ションと管理• クラスタ上へのコンテナのデプロ

イとスケジューリングを行うエコシステムが成熟してきています。

5

たいていの PaaS が Docker Image でのアプリケーションデプロイに対応している昨今。• Cloud Foundry : Diego で Docker Image に対応• RedHat OpenShift : Kubernetes+Docker を全面採用• Deis とか Flynn とか• そもそも Docker って PaaS(dotCloud) から生まれてますよね

Cloud Native Application （ 12factor-app) やマイクロサービスアーキテクチャにとって、 Artifact をコンテナイメージとして管理するということはなかなか都合がよろしい。

PaaS 界隈でもコンテナベースのアプリケーションデプロイは一般的に

6

ちなみに OpenStack （ IaaS ）界隈でもコンテナ関連が盛り上がっている様子。

• Magnum 　 (https://github.com/openstack/magnum)Kubernetes などのコンテナオーケストレーションエンジンの管理

• Zun (https://github.com/openstack/zun) コンテナの管理

• Kuryr (https://github.com/openstack/kuryr)コンテナのネットワーキングを Neutron と連携させる

• Kolla (https://github.com/openstack/kolla)OpenStack の Docker Image をビルドして、 OpenStack 自体をコンテナとして実行する

7

オーケストレーションツールを使って、

「出来上がったソフトウェアスタック」をデプロイして動かすには

コンテナという仕組みはなかなか便利。

Cloud Foundry は「出来上がったソフトウェアスタック」か？

8

Cloud Foundry に BOSH は必須？

9

BOSH により実現されている機能 Containerize するなら・・・

Cloud Foundry リリースの管理

BOSH Release として管理することにより整合性 / 互換性を担保

BOSH Release からコンテナイメージを作成

マルチ IaaS 対応 各 IaaS 用の CPI と Stemcell コンテナホストクラスタのオーケストレーションと CF 機能（コンテナ）のオーケストレーションを分離

デプロイ Director にアップロードされた Stemcell と Release をBlobstore に保存して Stemcell から CombilationVM を作成しその上で Release のビルドを行ってからデプロイ先の仮想マシンを作成し NATS 経由でコンポーネントを配備

コンテナオーケストレータが配備

コンポーネント間のメッセージング

NATS （これは必要だ）

HA 障害時に BOSH Resurrector がコンポーネントを再配置

コンテナオーケストレータがコンテナを再配置

• BOSH 大事。 BOSH は単なるデプロイツールではありません。• Distribution のユーザの使い勝手を考えると、 BOSH Release をベースに

Containerize してデプロイを容易にするというアプローチもアリなのでは？

10

https://github.com/hpcloud/fissilehttps://cfsummit2016.sched.org/event/6aQ5/dockerizing-bosh-releases-fissile-vlad-iovanov-aaron-lefkowitz-hpe

Containerized service としての Cloud Foundry の実装例： Helion Stackato 4

11

High Availability Model

– There is no known SPOF with multi-AZ configuration.

12

Containerized されているとデプロイはざっくりこんな感じ（ Stackato4 の例）1. インフラ（ AWS or OpenStack or VMware ）の準備

– ネットワークとかキーペアとか DNS とか

– bootstrap （インストーラ）を動かすための JumpBox VM2. Kubernetes クラスタと Core Services のセットアップ

– VM のデプロイ– Kubernetes Master– Kubernetes Node– Gluster Node

– Core Services の起動– Helion Control Plane : クラスタ管理– UAA : ユーザ管理– Helion Service Manager : コンテナとして動くサービスの管理

3. Containerized Services の展開と起動– Helion Cloud Foundry (Cloud Foundry そのもの）

– Helion Code Engine (Concource ベースの CI ツール）

– Helion Sevice Console （ GUI ）

– その他（ MySQL, Postgresql, Redis, RDS connector など）

13

Bootstrap （ Terraform ）がやってくれるので待つだけ。30 分ぐらい

ServiceManager が DockerHub からイメージを持ってきてKubernetes 上に展開するだけなので待つだけ。Cloud Foundry で 20 分ぐらい（他も並行実行可）

14

メリット• インフラの準備さえできてれば、デプロイが速い。楽。（ 3AZ 構成でも 1 時間で完了）

• CF のデプロイ時に決めなければいけないことは AZ の数（ 1 or 3 ）だけ。

• ノードのスケールは後から Kubernetes クラスタにノードを足せばよい

（コンテナのスケジュールは Kubernetes 任せ）

• CF 外のサービス（ DB 、 CI ツールなど）は後からコンテナを上げればよい

• ローリングアップデート的なことも理屈の上ではコンテナイメージの入れ替えでできる気

がする

デメリット• とにかく大量のコンテナが動く（ CF だけで 100 個ぐらい）ので、何かおかしくなったと

きにわけがわからない

• BOSH でデプロイしないということはトラブルシューティングに BOSH が使えないという

こと

• Docker Image の出来がすべて

15

HCF Roles ( 1 of 2)HCF Role Purpose/Function HA Config SDL- Memory (MB )api Exposes CF API endpoint n 2560api-worker Background jobs for the API n 512blobstore Storing droplets, buildpacks 1 1536cf-usb CF service broker 1 256clock-global CC cleanup scheduler 1 512consul DNS within CF 3 256couchdb Storage for the autoscaler 1 256demophon Listener for Windows Diego Cell 1 128diego-access ssh-proxy and file-server n 256diego-brain Coordinates auctioning / orch n 256diego-cc-bridge Translates CC calls to Diego-speak n 512diego-cell [1…n] Where the apps run n 4096diego-database Storage and main API for Diego n 256diego-route-emitter Routes for all the containers n 256doppler Logging aggregator n 256etcd Used for Routing and Loggregator 3 256

`kubectl get pods –namespace=<hcf cluster name>`

HCF Roles ( 2 of 2 )

16

HCF Role Purpose/Function HA Config SDL- Memory (MB )ha-proxy Load balances HCF 0 or 1 256hcf-sso Built-in SSO service 1 128hcf-versions Bolt-on Versioning 1 128loggregator Logs and drains n 256mysql Back end for CC 3 3072mysql-proxy Allows mysql to be HA >2 256nats Cluster message bus 3 256router Routes to apps n 256routing-api API endpoint for routing features n 512routing-ha-proxy For TCP routing 1 256sclr-api Autoscaler's API endpoint 1 1536sclr-broker Autoscaler service broker 1 1536sclr-server Actual autoscaler 1 1024

Stackato をひとりにしないで

http://container.cf/en/latest/https://github.com/CiscoCloud/ContainerCF

Cisco さんも取り組んでいるようです (ContainerCF)

今後コミュニティでこんな動きが出てきたら面白いなと個人的に思っています。

• Fissile などを使って作成したコンテナイメージの共有

• 各種コンテナオーケストレータ /Public Cloud 上での展開

• Containerize で得られた知見の BOSH へのフィードバック

• Stackato 以外の Containerized CF distro （商用 / 非商用）

• Cloud Foundry エコシステムの発展！

Questions?

18