Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016

1,501 views

Published on

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

Published in: Software
  • Be the first to comment

Cloud Foundry as Containerized Services - Cloud Foundry Days Tokyo 2016

  1. 1. Cloud Foundry as Containerized Services @jyoshise Japan Cloud Foundry Group Hewlett Packard Enterprise
  2. 2. 自己紹介 • 吉瀬 淳一 (@jyoshise) • 担当: ギター(たまにじゃんけんで負けるとベース) • • Lead Architect, Helion Professional Services APJ • IaaS(OpenStack)とか • PaaS(Stackato/CloudFoundry)とか • アジャイル/クラウドネイティブ開発とか
  3. 3. Container as a Serviceとか言われてますが 3
  4. 4. 4 Docker • Swarm CNCF • Kubernetes Apache • Mesos Mesosphere • DC/OS クラスタ管理/コンテナスケジューラいろいろ コンテナとは、って話はしませんが • イメージの管理 • Linuxホスト上でのコンテナの実行管理 というDockerの基本機能に加えて、 • ホストクラスタのオーケストレーションと管理 • クラスタ上へのコンテナのデプロイとスケ ジューリング を行うエコシステムが成熟してきています。
  5. 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. 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. 7 オーケストレーションツールを使って、 「出来上がったソフトウェアスタック」をデプロイして動かすには コンテナという仕組みはなかなか便利。
  8. 8. Cloud Foundryは「出来上がったソフトウェアスタック」か? 8
  9. 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. 10 https://github.com/hpcloud/fissile https://cfsummit2016.sched.org/event/6aQ5/dockerizing-bosh-releases-fissile-vlad-iovanov-aaron-lefkowitz-hpe
  11. 11. Containerized serviceとしてのCloud Foundryの実装例:Helion Stackato 4 11
  12. 12. High Availability Model – There is no known SPOF with multi-AZ configuration. 12
  13. 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. 14 メリット • インフラの準備さえできてれば、デプロイが速い。楽。(3AZ構成でも1時間で完了) • CFのデプロイ時に決めなければいけないことはAZの数(1 or 3)だけ。 • ノードのスケールは後からKubernetesクラスタにノードを足せばよい (コンテナのスケジュールはKubernetes任せ) • CF外のサービス(DB、CIツールなど)は後からコンテナを上げればよい • ローリングアップデート的なことも理屈の上ではコンテナイメージの入れ替えでできる気がする デメリット • とにかく大量のコンテナが動く(CFだけで100個ぐらい)ので、何かおかしくなったときにわけがわからない • BOSHでデプロイしないということはトラブルシューティングにBOSHが使えないということ • Docker Imageの出来がすべて
  15. 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. 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. 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. 18. Questions? 18

×