CF介绍与安装
1. 安装环境
- ruby 1.9.3
- bundle
2. 主要组件
- nats-server
- warden
- dea
- router
- cloud_controller
- health_manager
- uaa
3. 注意事项
- nats-server是系统的消息总线（mbus），必须最先安装
- cf-2.0中，dea依赖warden，所以warden必须在dea之前安装
4. 主要组件的作用
- dea
directory server是由go语言编写的，并内嵌到新版dea中，以代替旧版的目录服务器。针对directories/files的请求由dea来处理，dea以一个HTTP重定向到一个URL来作为响应，此URL会直接命中directory server。此URL是由dea指定的，directory server在servering之前会检查此URL的有效性。
一个打好压缩包就是一个droplet，打压缩包的程序就叫buildpack，打包的过程叫staging。不同的应用类型对应的buildpack代码也不同。如果要增加一门cloudfoundry默认不支持的语言或者应用类型，就需要自定义buildpack。
dea控制的container对外提供服务。router和dea会定时通过NATS通信，dea将dea下的container的ip，host，port等消息报告给router。
dea启动时会附带启动一个file api server，而dea directory server的启动则是单独进行的，代码在dea/go目录下。这两个server的区别在于：
dea directory server 启动后会向router注册，即外部可以访问到dea directory server。所有跟dea相关的上传（上传droplet）和下载（获取各种文件内容，如log文件）都是直接通过dea directory server来进行的。 file api server起一个验证并返回请求真实路径的作用。
比如执行cf logs XXX -t命令，表面上看起来是客户端cf向cloud controller发起请求，但实际上是cloud controller 重定向到dea directory server来提供服务的。
每一种语言只有一个buildpack，不同类别的应用打包在buildpack代码里面单独进行区分。在buildpacks/vendor目录下，官方提供了三种语言（java，nodejs，ruby）的若干种应用类型的支持，同时也提供了一种方便添加自定义buildpack支持的机制。
- warden
warden的主要目的是提供一种简单的API来管理被隔离的环境。这种被隔离的环境，或者称之为容器，可以限制CPU、memory、disk、network等。warden目前只支持linux。
一般说warden实际上指的是warden server，上层DEA通过warden client来调用warden server提供的api创建并控制container，container可以添加诸多限制，且container之间互相隔离。应用的实例最终在container中运行。
- NATS
不管是外部用户对平台上的应用发起的请求，还是内部组件提供对外的api（uaa和cloud controller），都是通过router转发的request。要能让router转发则首先需要向router注册，以下是实现逻辑：
1）router启动时，会订阅 router.register 这个channel，同时也会定时的向 router.start 这个channel发送消息，
2）其他需要向router注册的组件，启动时会订阅router.start这个channel。一旦接收到此消息，会立刻收集组件本身需要注册的信息（如ip，port等）然后向router.register频道发送消息。
3）router接收到router.register消息后立即更新路由信息。
4）以上过程不停循环，使router的状态时刻保持最新。
cloud controller指挥dea进行打包和运行的逻辑如下：
1）所有组件，包括dea启动时，会生成一个唯一的UUID，来标识组件。dea会定时的将自身情况和ID发送到stager.advertise 和 dea.advertise这两个channel，同时会订阅 staging.<uuid>.start 和dea.<uuid>.start这两个channel
2）cloud controller 订阅这两个channel 并根据channel的信息构造并时刻更新dea_pool和stager_pool,
3）当有打包或者运行应用的请求时，cloud controller会去查询这两个pool，如果有合适的dea，就会向对应的[dea|stager].<uuid>.start发送消息
4）对应uuid的dea收到消息，根据消息执行打包或运行任务。
- cloud controller
- 对apps的增删改读；
- 启动、停止应用程序；
- Staging apps（把apps打包成一个droplet）；
- 修改应用程序运行环境，包括instance、mem等等；
- 管理service，包括service与app的绑定等；
- Cloud环境的管理；
- 修改Cloud的用户信息；
- 查看Cloud Foundry，以及每一个app的log信息。
Cloud Controller 的用户认证
Cloud Controller 2.0 去除了原有的用户认证相关代码，改为使用与uaa配合验证的方式，即uaa负责认证用户之后生成token，然后用户请求Cloud Controller时，需要将这个token以request 的 Authorization header的形式伴随HTTP请求发送。Cloud Controller对称解密token得到用户信息。因此，Cloud Controller 配置项中的uaa -> symmetric_secret 要和uaa中的密钥保持一致。
Cloud Controller 需要一个数据库（即CCDB），如果你选择mysql，请使用Innodb或其他支持事务处理的引擎，千万记得不要使用默认的MYisAM引擎，因为它不支持事务。Cloud Controller 的创建或更新都依赖数据库的事务功能：先创建或更新，再判断是不是有权限执行操作。如果使用了一个不支持事务的数据库，虽然不会报错，但任何无权限的创建或更新都会被执行，留下隐患。
- Health manager
- uaa
uaa有实现用户认证的逻辑，但如果需要自定义登录比如使用LDAP登录，并不需要修改uaa的代码。之前在cloud controller中提到，cloud controller对请求的验证是通过解密在Authorization header中的token来实现的。uaa可以仅仅起一个token分发者的作用，然后将用户认证的部分委托出去。cloudfoundry已经替我们考虑到了这一点。只需要在cloud controller的配置项里配置到login这个配置为自己的登录服务器（假设叫login-server）再使用cf或者cfoundry api 进行登录都会使用login-server来进行登录验证。
- console
只能自己写，结合uaa和cc api。
5. 安装
cf2.0的安装，官方给出的方案需要有openstack，Vsphere 等底层IaaS作为支持，如果没有IaaS, 那就只能自己摸索通过源代码安装。如果是ubuntu系统（官方声明最好是10.04）基本所有组件安装后经过合理的配置，都可以正常运行。后面会另外写一篇文章详细描述。