2016年11月11日　Cloud Foundry Days Tokyo 2016 での発表資料です。 http://cfdays.connpass.com/event/41201/

1. Cloud Foundry
as Containerized Services
@jyoshise
Japan Cloud Foundry Group
Hewlett Packard Enterprise

2. 自己紹介
• 吉瀬 淳一 (@jyoshise)
• 担当: ギター（たまにじゃんけんで負けるとベース）
•
• Lead Architect, Helion Professional Services APJ
• IaaS(OpenStack)とか
• PaaS(Stackato/CloudFoundry)とか
• アジャイル/クラウドネイティブ開発とか

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

4. 4
Docker
• Swarm
CNCF
• Kubernetes
Apache
• Mesos
Mesosphere
• DC/OS
クラスタ管理/コンテナスケジューラいろいろ
コンテナとは、って話はしませんが
• イメージの管理
• Linuxホスト上でのコンテナの実行管理
というDockerの基本機能に加えて、
• ホストクラスタのオーケストレーションと管理
• クラスタ上へのコンテナのデプロイとスケ
ジューリング
を行うエコシステムが成熟してきています。

5. 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. 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. 7
オーケストレーションツールを使って、
「出来上がったソフトウェアスタック」をデプロイして動かすには
コンテナという仕組みはなかなか便利。

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

9. 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. 10
https://github.com/hpcloud/fissile
https://cfsummit2016.sched.org/event/6aQ5/dockerizing-bosh-releases-fissile-vlad-iovanov-aaron-lefkowitz-hpe

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

12. High Availability Model
– There is no known SPOF with multi-AZ configuration.
12

13. Containerizedされているとデプロイはざっくりこんな感じ（Stackato4の例）
1. インフラ（AWS or OpenStack or VMware）の準備
– ネットワークとかキーペアとかDNSとか
– bootstrap（インストーラ）を動かすためのJumpBox VM
2. 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. 14
メリット
• インフラの準備さえできてれば、デプロイが速い。楽。（3AZ構成でも1時間で完了）
• CFのデプロイ時に決めなければいけないことはAZの数（1 or 3）だけ。
• ノードのスケールは後からKubernetesクラスタにノードを足せばよい
（コンテナのスケジュールはKubernetes任せ）
• CF外のサービス（DB、CIツールなど）は後からコンテナを上げればよい
• ローリングアップデート的なことも理屈の上ではコンテナイメージの入れ替えでできる気がする
デメリット
• とにかく大量のコンテナが動く（CFだけで100個ぐらい）ので、何かおかしくなったときにわけがわからない
• BOSHでデプロイしないということはトラブルシューティングにBOSHが使えないということ
• Docker Imageの出来がすべて

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

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

17. Stackatoをひとりにしないで
http://container.cf/en/latest/
https://github.com/CiscoCloud/ContainerCF
Ciscoさんも取り組んでいるようです(ContainerCF)
今後コミュニティでこんな動きが出てきたら面白いなと個
人的に思っています。
• Fissileなどを使って作成したコンテナイメージの共有
• 各種コンテナオーケストレータ/Public Cloud上での
展開
• Containerizeで得られた知見のBOSHへのフィード
バック
• Stackato以外のContainerized CF distro
（商用/非商用）
• Cloud Foundry エコシステムの発展！

18. Questions?
18