GE Predix 云平台开发入门 -- 轻度解释Cloud Foundry命令行

轻诉架构 

1.应用之云飘啊飘

我们知道GE Predix云平台是基于Cloud Foundry （CF）平台开发的。 所以 CF命令行（CLI）在使用Predix云平台上有着重要的作用。 作为开始部署使用Predix云平台的用户来说， 一个轻度的CF CLI的解释会是一个比较好的入门选择。 所以飘在我们最前面的， 目前是Predix工业云平台， 其实背后有Cloud Foundry云平台。 

    

那为什么Predix云后面还有云呢？为什么选Cloud Foundry呢？ 因为Predix云是要将一个可以绑定工业数字化模型的PaaS云， 那么底层需要选择一个通用的PaaS云， 而CF就是一个极好的PaaS云。 PaaS是要帮屏蔽了管理中间件和运行部分， 让你集中在应用和数据。 底层还有IaaS云， 帮你屏蔽了管理操作系统。 

其实除了这三层之外，还有SaaS层， 但是Predix为了适应不同的工业领域的应用开发， 不能走到SaaS层， 固定好数据和应用， 所以只能到PaaS层：

那为什么选Cloud Foundry，而不选其他的PaaS平台呢？ 首先我们看一下目前有哪些知名的PaaS平台， 不知名的， 肯定不太靠谱了。 我们看到在PaaS层面上， 除了Docker和Cloud Foundry， 其他的分布式Amazon， IBM， Microsoft，RedHat和SAP的平台。 相比较而言， Amazon， IBM， Microsoft和SAP都有自己的工业业务， 一定程度是也可以是GE的竞争对手。 所以Predix不能选由竞争对手主导的平台作为主流。 再比较Docker，Cloud Foundry，和RedHat的OpenShift。 那么Cloud Foundry在可扩展，稳定性方面的优势就比较明显了。 所以GE和EMC一起投资了Pivotal Software。 

CF是方便你管理应用和数据的PaaS云平台。 那么， 一般一个在线服务， 会有三层：用户层， 服务层，和资源层（数据层）。 

2. 不同架构高呀高

那么对应到三层里面的服务层， 要做好用户层的需求， 有个经典的MVC模型， 划分出模型Model， 来搞业务逻辑， 视图View来搞展示界面， 还有控制器Controller， 来匹配模型和视图。 这样， 控制器就显得尤为重要。 

这样我们对应不同的URL访问， 就需要匹配不同的MVC模型。 

         

这时候， 人们把这个匹配的功能独立出来， 提出了路由Route的功能。 

随着路由功能的增强， 他成为了新型MVC模型的一部分，使得不同服务可以使用相同的Controller，同一个服务也可以使用不同的Controller。 

很快， 人们又发现， 一个Controller需要的有些子功能还需要其他服务Service的支持。

那么如何把Controller和后台一些服务绑定， 这就需要有服务代理Service Broker。

最明显的是数据服务Data Service：

这样， 我们把上面的应用， 除了Controller之外的路由Router， 服务代理Service Broker， 引入了Application的体系里面。 

其实， Controller还是会有相应的日志输出的， 这里用于经常服务日志Log的一个组件就是信息总线Message Bus。 

其实在Cloud Foundry里面， 一般情况下， Controller不是直接和Message Bus打交道， 很多时候是把状态发给Health Manager， 然后由Health Manager把日志信息发给总线的。 

这样在CF里面， Health Manager就把状态信息发给总线， 而总线会把信息发给Heath Monitor进行展示。 

除了上面这些比较集中的功能， CF还提供对用户登录的管理， 由两部分组成， 登录服务器Login Server 和 用户账户认证UAA User Account Authentation。 

这样综合上面三方面的内容， 我们可以大致得到CF提供了几大模块， 这些模块分成7层模型， 路由层routing， 用户认证层authentication， 应用生命期层app lifecycle， 应用存储运行层app storage & execution， 服务层 services， 信息层messaging， 日志和性能仪表层metrics and logging。 

他们之间的简单通信， 就得到了CF的架构， 譬如：

1. UAA Login和Cloud Controller之间。

2. Cloud Controller和Health Manager（HM9000）和NATS Message Bus 和Metrics Controller之间。

3. Cloud Controller和Service Broker之间。

4. 另外，运行虚拟机也有细分， DEA Droplet Execution, Agent Warden Server等构成了运行虚拟机作为应用执行环境：

举个PHP应用的例子， DEA里面运行好多节点， 每个节点有个PHP的运行， 然后由Warden管理这些节点的生命周期， 而他们的访问由Router导入访问， Cloud Controller （CC）把状态发给Health Manager （HM9000）， 而每个Controller要访问的数据库服务有服务代理Broker管理。 

3.应用执行Go吧Go

其实，在最新的CF架构里面， 对执行架构进行了升级， 从DEA Droplet Execution Agent架构升级到了Diego架构。  其中最大的升级就是把开发语言从Ruby换成了Go，同时更名了对应的名称。 核心的， 虚拟机的生命期管理，从Warden变成了Garden； Controller的运行从DEA 节点Node 变成了 Diego Cell； Controller之间的协调器从DEA变成了Diego Brain。 如下表所示：

还可以看到原来DEA是和Cloud Controller绑定的， 限制Diego和Cloud Controller解耦合了。 

这样我们来看一下整个组件有哪些变化：

从上图， 我们看到， 应用运行从DEA框架换成Diego框架之后， Message Bus 和 Health Manager 也对应进行了变化。 直观来说就是把Health Manager的功能进一步独立细分了， 把一部分功能独立成信息层的功能了。 从Health Manager (HM9000) 变成了 nsync, BBS, 和 Cell Rep 更多组件了。 

至此， 我们再来详细看一下， 前面讲的Controller， Router， Health Manager， Message Bus， Application Execution是如何变化的？

可以看到：

1. Controller不是再和Health Manager联系了， 是和nsync进行交互。 整个组成Controller API，CAPI模块。 

2. Router和Controller也不是和NATS Message Bus交互了，而是用bbs替换了NATS的功能。 

3. 引入auction机制到Diego Brain来作为协调机制

另外一个不太容易看到的特性是：

4. Warden只能运行Linux容器， 而Garden提供了各种操作系统的虚拟机。 

综上， 我们把Cloud Foundry的架构轻度解释了一遍， 这样是为了后面我们把命令行和这些部分对应起来。 

轻诉命令行

命令行操作的安装就跳过了， 可以参考 https://docs.cloudfoundry.org/cf-cli/install-go-cli.html。 

1. 登录进入CF

你需要制定API ，然后再login：

你也可以把上面两步，写成一步， 给login 加一个 -a 参数， 完了， 你可以把你自己的APP 推Push到云上去。 

然后， 你可以通过target来指定一个组织Organization和一个空间Space。 

登录到空间小结：

2.空间Space管理

一般来说你需要注册一个这个组织的用户， 然后获得对应Space的全新Permission。 一旦进入到Space， 你就可以推送APP和创建服务了。

譬如下面定义了一个student1-org的组织， 里面有development， production和test 三个空间， 每个空间都有apps和services的两大部分。 

空间管理小结：

3.应用APP管理

首先， 你要部署一个APP，通过push命令：

创建完成后， 一般你需要调整硬盘和内存大小， 这时候你需要利用cf scale命令。 

之后你需要启动， 重启， 停止app的命令。 

当然， 万一你忘记了app的名字和相关信息， 你还需要查询所有app，和单个app的详细信息。 

应用管理小结：

4.服务Service管理

在每个Space里面， 除了你可以创建管理APP之外， 非常类似你可以创建Service。 

你可以管理Service， 更新和删除。注意这里更新是使用update，而不是scale。

你可以绑定或者解绑定某个服务到某个APP。 

最后你也可以查询全部服务列表和单个服务的信息。 

不过Service和App最大的不同是， App是本地推送上去的。 而Service是注册使用的。 CF提供的服务来自Service marketplace，市场。 

只有市场上有的服务， 你才能创建一个实例。  这样你就要通过cf marketplace来查询有哪些服务可以被创建实例。 

理解service命令之后， 我们可以将前面提到的Controller的component功能就可以和service broker 链接起来， 这里我们可以看一下创建服务之后， 查询服务状态的过程中， controller是怎么和service broker进行交互的流程。 

服务管理小结：

5.路由Route管理

路由管理就是把某个域名下，对应的子域名 domain/subdomain （host + domain），或者路径path映射到对应的空间Space， 同时还可以指定对应的应用apps 和类型 type。 

譬如我们常用的空间有开发空间， 测试空间， 和产品空间。 

那么一旦创建了这个空间的路由之后， 那么对应的访问就会映射到这个空间来。 

如果再绑定路由和应用之后， 那么就可以根据应用找到对应的controller来处理请求了。 

当然也可以删除路由， 或者解开对应应用的映射。 

也可以查询当前空间下的所有的路由。 

路由管理小结：

6.域名Domain管理

传统意义上的域名是指DNS的不同级别。 但是这里的域名是指在一个组织org里面全面能够识别的全部域名

这里域名是对应到组织org的， 并且可以创建夸组织的域名。 有创建域名，就必然有删除域名。 

另外就是查询所有的域名， 如下图所示。 

域名管理小结：

7.环境变量Environment管理

除了上面空间， 应用，服务， 路由， 域名之外。 还有很重要求的就是环境变量和日志的管理。 

环境变量比较简单，就是创建（set）， 删除（unset）和查询（list）。 

日志有两种， 一种是logs，另外一种是events。 他们的区别就是logs一般是对某些变量的值进行输出， 记录。 

而events一般对生命周期的变化进行记录。 

环境变量和日志管理小结：

除了上述重要的部署命令（deployment）还有很多管理的命令（admin）， 详细可以参考： https://docs.cloudfoundry.org/cf-cli/cf-help.html

轻诉蓝绿部署

1.蓝绿之分

我们知道路由可以随意和应用绑定，解绑定的。 这种便利带来了部署上的蓝绿之分。 

蓝色是传统的部署方式。 就是我们把一个应用创建之后， 绑定好了对应的路由和日志， 等等。 

但是这样， 在线操作的时候， 有个问题， 线上的服务更新的时候， 可能需要宕机。 

而绿色部署就是先创建了另外一个应有，这是一个更新应有， 当我们需要更新， 直接把路由改变到新的服务。 

然后再停止就的应用。 这样就会带来零宕机时间。 

举个例子， 我们会把需要更新的应用先映射的demo-time-temp的hostname上面去， 然后再通过路由切换成demo-time， 这样就实现无宕机更替， 更为绿色。 

2.蓝绿之分

其实真正在运行时候， 还有一个staging的步骤。 就是虚拟机准备好容器开始跑运行程序了。 而具体到不同运行环境/容器来staging的时候， 又会不一样。

例如利用buildpack和docker。buildpack就需要有metadata和运行文件的准备工作。 

如果从DevOps的角度来看Buildpack和容器Container的对比， 其实Container就需要开发者也提供。 如果我们简单来比较Buildpack和Docker的话:

1. 从上传维护的角度， 上传一个container image，要比上传一堆代码文件要更为简单。

2. 从配置的角度， 由于buildpack和Cloudfoundry结合更为紧密， 好多自动化配置做的更为完善， 但是docker和Cloudfoundry结合就没有那么精密。

同时buildpack提供部分安全监控的端口， 但是docker就没有。

3. 从应用的角度， 如果一个独立运行的应用， 那么配置好了docker之后， 独立运行， 会比buildpack更为简单， 正如上图所演示的， 启动步骤也要少。 

但是如果需要部署一个分布式， 或者需要同步信息的时候， docker带来的配置就会变得比buildpack麻烦。 

4. 从随意迁移的角度， docker可能更为广泛的被应用， Buildpack主要是cloud foundry在应用。 

5. 从类比的角度， buildpack好比修好地面轻轨， 什么都自动化好了， 你只要应用就好了。  而docker好比开个SUV， 就算路面不好， 你也能翻山越岭。 

6. 从开源的角度， 不管是build pack还是docker， 都不是一个标准的app容器， 只有建立业界容器标准， 这样buildpack带来自动化配置的优势， 和docker带来的迁移优势就能都有了。 但是， 这还不在路上...

小结

这样我们从一个web应用出发，说明了Cloud Foundry是如何为这个应用建立需要的环境的。 之后，再介绍了部分核心的命令行， 与前面说明对应起来。 谢谢大家~~~