【Cloud Foundry】Cloud Foundry学习（五）——Cloud Controller

标签：

概述

    Cloud Controller负责管理应用程序的生命周期。当开发者将一个应用发布到Cloud Foundry时也就是指发布到了Cloud Controller中，CC将存储原始应用程序部分，并创建一个记录来追踪应用程序的数据、并且通知DEA打包运行应用。CC还会保存orgs、spaces、services、service实例、user角色等信息。

架构

Cloud_Controller_ng架构图

从ccng架构图中可以看出ccng可以分为以下多个模块：

功能：

Cloud Controller是CloudFoundry的管理模块。主要工作包括：

a)     对apps的增删改读；

b)     启动、停止应用程序（通过DEA）；

c)      Stagingapps（把apps打包成一个droplet，通过Stager）；

d)     修改应用程序运行环境，包括instance、mem等等；

e)     管理service，包括service与app的绑定等；

f)      Cloud环境的管理；

g)     修改Cloud的用户信息（通过UAA，ACM）；

h)     查看CloudFoundry，以及每一个app的log信息。

这似乎有点复杂，但简单的说，可以很简单：就是与VMC和STS交互的服务器端。VMC和STS与CloudFoundry通信采用的是restful接口，另一方面Cloud Controller是一个典型的Ruby on Rails项目，从VMC或者STS接到JSON格式的协议，然后写入Cloud ControllerDatabase，并发消息到各模快去控制管理整个云。

我们以部署一个App到CloudFoundry为例，在我们在敲完那条简单的push命令后，VMC开始工作，在做完一轮的用户鉴权、查看所部署的apps数量是否超过预定数额，问了一堆相关app的问题后，需要发4个指令：

a)     发一个POST到“apps”，创建一个app;

b)     发一个PUT到“apps/:name/application”，上传app;

c)      发一个GET到“apps/:name/”，取得app状态，看看是否已经启动；

d)     如果没有启动，发一个PUT到“apps/:name/”，使其启动。

第一版的CloudController是基于Ruby On Rails的，在新版中，为了与CloudFoundry其他模块一致，并且让架构更加简单，CloudController用Sinatra进行了重写，并且加入了更多的模块去细化CloudController的工作。

另外一个重要的改进是，第一个版本的Droplet是通过NFS共享的，但这样会带来安全、性能等问题，而新版中进行了两大改进：

a)     移除NFS，采用自己开发的，简单的blobstore来存放Droplet;

b)     为Ruby项目进行了优化，把常用的Gem保存在package cache里面。所以在打包Ruby项目的时候不需要到公网上下载Gem文件，而是从CloudFoundry内部的Cache获得，大大加速了Stage过程。

随着CloudFoundry的逐渐成熟，权限管理功能在新的版本进行了很大的加强，在原有的用户模型基础上，加入了组织、用户空间的概念。

用户模型的认证是由UAA模块实现的，它可以与企业已有的认证系统进行整合，例如LDAP，CAS等；鉴权是由ACM模块实现的。

上图示例了一个用户访问CloudController的API的过程。我们可以分别看到UAA与ACM模块在一套鉴权流程各自扮演的角色。

【Cloud Foundry】Cloud Foundry学习（五）——Cloud Controller

标签：

原文地址：http://blog.csdn.net/u010515761/article/details/44155699