Cloudify从项目开发云端架构

标签：

4.5  Cloudify

       Cloud foundry作为业务第一个开源的paas，给我们带来了难得的学习和借鉴的机会，得以窥视paas的盒子内部的构造。Cloud foundry是基于ruby开发的，ruby相比之下比java开发的速度更快，这也是CF发展很快的原因之一把（原因之二，架构稳健，容易扩展）。如果把CF看作是大象，功能齐全，结构完整，那cloudify就是灵活的豹子，号称上手最快的平台。

       Cloudify是gigaspaces公司推出的基于java的paas平台。从语言习惯上看基于java的cloudify更贴近我们的开发习惯（其实我也愿意花点时间学点ruby或者groovy，赚点零花钱）。Gigaspaces是业界非常著名的paas提供商，也是高端产品XAP的厂家（eXtreme Application Platform，高端的Java 应用服务器）。有意思的是gigaspaces-cloudify-2.1.0-ga和gigaspaces-xap-premium-9.0.0-ga 的lib库是相同的。也就是说在同一个基本库的基础上开发了2套针对不同场景的应用。      

4.5.1            简单介绍

       Cloudify通过提供基于Groovy的领域特定语言，为创建部署脚本准备应用，同时基于out-of-the-box模式，从而推出云端Java元素，这个元素包括Apache服务器、Cassandra分布式数据库、Spring框架、XAP内存数据网格等。和CF相比，cloudify非常的精巧。那Cloudify提供了哪些功能呢：

• 在无需更改代码的情况下, 部署任何企业应用程序到任何虚拟环境

• 在云平台的应用程序提供企业级的生产环境:

• 持续的可用性

• 弹性和可扩展性

• 完全自动化的部署

• 无与伦比的控制和可视化

• 应用程序和群集感知的详细监测

• 无厂商锁定

• 保持现有的软件开发方式和过程

• 支持任何应用程序堆栈

1、基于资源定制的配置（Recipe-based configuration）:

       基于Groovy的领域特定语言，扩展和自定义很容易并直观，内部绑定了常用中间件组件，比如：JBoss, Tomcat, MySQL, Cassandra, MongoDB等。对于资源定制，CF有个概念：Droplet，指提交的源代码 + 配套好的运行环境 +管理脚本，在cloudify中这个概念被深化，Recipe包括的更多，包括应用生命周期脚本，服务的关联设定等。

图45-01： 内建的资源定制

2、通用服务适配器（USA，Universal Service Adapter）:

       该组件运行在每个节点上，并把recipe 在本地节点转化为动作来执行（比如安装，服务初始化，服务监控）。它可以被视为Cloudify的每个节点上的本地代表，只要在recipe文件中配置正确，不需要对服务进行特别管理（Tomcat, MySQL, Cassandra, JBoss, Apache with mod_php）。

3、插件式集群感知控制台（Pluggable cluster-aware monitoring）:

       监测框架是用来创建通用的监督协议插件集合（比如JMX, SNMP, JDBC/SQL）。USA激活在本地每个服务节点上的插件，然后插件连接到本地服务，并开始收集从它的信息。这些数据指标，会传递给Cloudify运行时环境，cloudify会根据recipe中的定义规则来控制系统的自动扩展能力，并通过各种用户接口暴露给用户。

4、移植性

       Cloudify 提供一个抽象能力功能：Cloud Driver，该层被设计成抽象方式来隔离我们的应用和云环境，并提供公用方法来集成了业界所有的主要云和虚拟机（采取的是jclouds的组件，支持业界众多的云环境）

       GigaSpaces Cloudify 已经集成了Microsoft Windows Azure 和 Amazon EC2 clouds，并且马上集成其他的云平台。 比如Citrix CloudStack，OpenStack，Rackspace，GoGrid，Citrix XenServer。

支持的IaaS平台

5、关键特征

l        版本功能

       虽然cloudify提供开源的是社区版本，一些高级功能（我们很想拥有的）并不提供，但这不妨碍我对cloudify敬意。除了CF，开源社区有了更多的选择，而且提供了新的思路和方式。CF也有2种版本，CF只是vmware的开源版本，vwmare也有商业版本。

4.5.2            总体架构

       Cloudify是基于java来实现的，在它的设计思想中，并没有一个paas平台的边界，而是把各种服务器理解为一个个的网格，然后有管理节点分别去关联计算节点，还是典型的C/S模式，这和它的设计它之前的XAP的设计理念一脉相承。

       这样的方式使得cloudify总工程很轻薄，但也具有相当的能力，抛去了硕大的PaaS支架的躯体，保留了paas最核心的本质。这种架构和之前的CF大相径庭，但这也是一种不错的思路，因为把这块撇给了DSL来定义，用人工定义的方式解决了服务和应用的定位和绑定功能，底层还是依赖iaas提供的对vm的控制能力，并把整体paas的管理功能封装在当前管理节点和与之相关的计算节点的管理。Cloudify抛弃了外壳，简化了架构，强化了DSL，终于换来了它轻盈的身姿。

图 45-02： Cloudify 体系结构

       在cloudify中，cloudcontrol处于绝对控制地位，解释dsl，调用jclouds，寻找合适的vm，根据规则部署应用，并对应用进行监控和管理。Cloudify cc和vm之间是有状态联系，这种关系和cf的无状态cc模式有极大的区别。

l         在cf中，cc是无状态的，可以有很多无状态CC节点，并通过一个消息机制和各个组件进行交互，其优势就是能构建巨大的云平台环境，从目前掌握的资料而言，一些公共开源云环境均采用这种模式，但结构复杂，运维和管理相对困难。

l         而在cloudify中，cc和vm/应用是有状态模式，这种方式劣势为不能管理数量众多的应用，优势是和vm/应用的关系很紧密，方便控制和管理，这点其实对于基于项目类型的云环境是有优势的，CC个数有限，每个CC对应N个vm/应用数量，分区画域，部署方便，管理容易。

4.5.3           组件说明

1.         dsl：脚本部署语言，解决部署依赖以及环境配置

图45-03：DSL描述（领域定义语言，用来部署云端应用）

2.         cli：提供基于console的客户端环境

图45-04：cli控制台（提供服务生命周期的管理）

3.         webui：提供for web的用户管理界面

图45-05：控制台界面

4.         usm：统一服务管理

5.         rest：对客户端提供基于rest的接口风格

6.         openapi：runtime的抽象层，用于2次开发使用

7.         runtime：核心包，实现agent,container，server manager

8.         jclouds：云端资源抽象层

4.5.4           业务流程

       Cloudify使用boostrapping进行管理，部署应用所需的服务机（vm或物理），安装需要提供的Cloudify组件。在Cloudify shell提示符运行相关的安装命令的时候初始化boostrapping。在一般来说，bootrapping的进程执行以下任务：

1.         在模板中定义中分配一台可用机器。有关模板的更多信息，参阅Cloudify驱动程序文件。

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（WINDOWS）

3.         安装并启动相关的组件

       一旦的boostrapping连接到分配的机器，它上传来引导机器所需的文件。这些通常包括一个启动脚本和上传文件夹中的任何所需的文件，如SSH密钥文件。一旦文件被上传，有关bootstrap脚本运行。

       在启动cloudify的控制进程，Bootstrapping开始管理机器，并推出Cloudify agant。Cloudify代理程序激活Cloudify controller去使用服务实例节点的机器去安装或者扩展服务。

Cloudify管理机的配置

       当有关的云驱动程序接收到一个请求启动云，它执行以下任务：

1.         在管理节点模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         通过SSH（* nix中）或WinRM的（WINDOWS）连接到分配的机器。

3.         安装和开始的Cloudify的管理组件（Cloudify controller和cloud driver）

图45-06： Cloudify管理节点的调用时序

应用服务的配置

       当Cloudify controller接受请求去安装一个应用，就会要求cloud driver提供机器以便运行该应用所需的服务。为了获取到具体的节点，cloud driver需要行以下任务：

1.         在管理节点的模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（windows）

3.         安装和启动Cloudify agent

4.         启动服务的安装，使用有关服务的安装脚本

4.5  Cloudify

       Cloud foundry作为业务第一个开源的paas，给我们带来了难得的学习和借鉴的机会，得以窥视paas的盒子内部的构造。Cloud foundry是基于ruby开发的，ruby相比之下比java开发的速度更快，这也是CF发展很快的原因之一把（原因之二，架构稳健，容易扩展）。如果把CF看作是大象，功能齐全，结构完整，那cloudify就是灵活的豹子，号称上手最快的平台。

       Cloudify是gigaspaces公司推出的基于java的paas平台。从语言习惯上看基于java的cloudify更贴近我们的开发习惯（其实我也愿意花点时间学点ruby或者groovy，赚点零花钱）。Gigaspaces是业界非常著名的paas提供商，也是高端产品XAP的厂家（eXtreme Application Platform，高端的Java 应用服务器）。有意思的是gigaspaces-cloudify-2.1.0-ga和gigaspaces-xap-premium-9.0.0-ga 的lib库是相同的。也就是说在同一个基本库的基础上开发了2套针对不同场景的应用。      

4.5.1            简单介绍

       Cloudify通过提供基于Groovy的领域特定语言，为创建部署脚本准备应用，同时基于out-of-the-box模式，从而推出云端Java元素，这个元素包括Apache服务器、Cassandra分布式数据库、Spring框架、XAP内存数据网格等。和CF相比，cloudify非常的精巧。那Cloudify提供了哪些功能呢：

• 在无需更改代码的情况下, 部署任何企业应用程序到任何虚拟环境

• 在云平台的应用程序提供企业级的生产环境:

• 持续的可用性

• 弹性和可扩展性

• 完全自动化的部署

• 无与伦比的控制和可视化

• 应用程序和群集感知的详细监测

• 无厂商锁定

• 保持现有的软件开发方式和过程

• 支持任何应用程序堆栈

1、基于资源定制的配置（Recipe-based configuration）:

       基于Groovy的领域特定语言，扩展和自定义很容易并直观，内部绑定了常用中间件组件，比如：JBoss, Tomcat, MySQL, Cassandra, MongoDB等。对于资源定制，CF有个概念：Droplet，指提交的源代码 + 配套好的运行环境 +管理脚本，在cloudify中这个概念被深化，Recipe包括的更多，包括应用生命周期脚本，服务的关联设定等。

图45-01： 内建的资源定制

2、通用服务适配器（USA，Universal Service Adapter）:

       该组件运行在每个节点上，并把recipe 在本地节点转化为动作来执行（比如安装，服务初始化，服务监控）。它可以被视为Cloudify的每个节点上的本地代表，只要在recipe文件中配置正确，不需要对服务进行特别管理（Tomcat, MySQL, Cassandra, JBoss, Apache with mod_php）。

3、插件式集群感知控制台（Pluggable cluster-aware monitoring）:

       监测框架是用来创建通用的监督协议插件集合（比如JMX, SNMP, JDBC/SQL）。USA激活在本地每个服务节点上的插件，然后插件连接到本地服务，并开始收集从它的信息。这些数据指标，会传递给Cloudify运行时环境，cloudify会根据recipe中的定义规则来控制系统的自动扩展能力，并通过各种用户接口暴露给用户。

4、移植性

       Cloudify 提供一个抽象能力功能：Cloud Driver，该层被设计成抽象方式来隔离我们的应用和云环境，并提供公用方法来集成了业界所有的主要云和虚拟机（采取的是jclouds的组件，支持业界众多的云环境）

       GigaSpaces Cloudify 已经集成了Microsoft Windows Azure 和 Amazon EC2 clouds，并且马上集成其他的云平台。 比如Citrix CloudStack，OpenStack，Rackspace，GoGrid，Citrix XenServer。

支持的IaaS平台

5、关键特征

l        版本功能

       虽然cloudify提供开源的是社区版本，一些高级功能（我们很想拥有的）并不提供，但这不妨碍我对cloudify敬意。除了CF，开源社区有了更多的选择，而且提供了新的思路和方式。CF也有2种版本，CF只是vmware的开源版本，vwmare也有商业版本。

4.5.2            总体架构

       Cloudify是基于java来实现的，在它的设计思想中，并没有一个paas平台的边界，而是把各种服务器理解为一个个的网格，然后有管理节点分别去关联计算节点，还是典型的C/S模式，这和它的设计它之前的XAP的设计理念一脉相承。

       这样的方式使得cloudify总工程很轻薄，但也具有相当的能力，抛去了硕大的PaaS支架的躯体，保留了paas最核心的本质。这种架构和之前的CF大相径庭，但这也是一种不错的思路，因为把这块撇给了DSL来定义，用人工定义的方式解决了服务和应用的定位和绑定功能，底层还是依赖iaas提供的对vm的控制能力，并把整体paas的管理功能封装在当前管理节点和与之相关的计算节点的管理。Cloudify抛弃了外壳，简化了架构，强化了DSL，终于换来了它轻盈的身姿。

图 45-02： Cloudify 体系结构

       在cloudify中，cloudcontrol处于绝对控制地位，解释dsl，调用jclouds，寻找合适的vm，根据规则部署应用，并对应用进行监控和管理。Cloudify cc和vm之间是有状态联系，这种关系和cf的无状态cc模式有极大的区别。

l         在cf中，cc是无状态的，可以有很多无状态CC节点，并通过一个消息机制和各个组件进行交互，其优势就是能构建巨大的云平台环境，从目前掌握的资料而言，一些公共开源云环境均采用这种模式，但结构复杂，运维和管理相对困难。

l         而在cloudify中，cc和vm/应用是有状态模式，这种方式劣势为不能管理数量众多的应用，优势是和vm/应用的关系很紧密，方便控制和管理，这点其实对于基于项目类型的云环境是有优势的，CC个数有限，每个CC对应N个vm/应用数量，分区画域，部署方便，管理容易。

4.5.3           组件说明

1.         dsl：脚本部署语言，解决部署依赖以及环境配置

图45-03：DSL描述（领域定义语言，用来部署云端应用）

2.         cli：提供基于console的客户端环境

图45-04：cli控制台（提供服务生命周期的管理）

3.         webui：提供for web的用户管理界面

图45-05：控制台界面

4.         usm：统一服务管理

5.         rest：对客户端提供基于rest的接口风格

6.         openapi：runtime的抽象层，用于2次开发使用

7.         runtime：核心包，实现agent,container，server manager

8.         jclouds：云端资源抽象层

4.5.4           业务流程

       Cloudify使用boostrapping进行管理，部署应用所需的服务机（vm或物理），安装需要提供的Cloudify组件。在Cloudify shell提示符运行相关的安装命令的时候初始化boostrapping。在一般来说，bootrapping的进程执行以下任务：

1.         在模板中定义中分配一台可用机器。有关模板的更多信息，参阅Cloudify驱动程序文件。

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（WINDOWS）

3.         安装并启动相关的组件

       一旦的boostrapping连接到分配的机器，它上传来引导机器所需的文件。这些通常包括一个启动脚本和上传文件夹中的任何所需的文件，如SSH密钥文件。一旦文件被上传，有关bootstrap脚本运行。

       在启动cloudify的控制进程，Bootstrapping开始管理机器，并推出Cloudify agant。Cloudify代理程序激活Cloudify controller去使用服务实例节点的机器去安装或者扩展服务。

Cloudify管理机的配置

       当有关的云驱动程序接收到一个请求启动云，它执行以下任务：

1.         在管理节点模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         通过SSH（* nix中）或WinRM的（WINDOWS）连接到分配的机器。

3.         安装和开始的Cloudify的管理组件（Cloudify controller和cloud driver）

图45-06： Cloudify管理节点的调用时序

应用服务的配置

       当Cloudify controller接受请求去安装一个应用，就会要求cloud driver提供机器以便运行该应用所需的服务。为了获取到具体的节点，cloud driver需要行以下任务：

1.         在管理节点的模板定义中的资源池中，分配一台可用的机器（使用特定的cloud api）

2.         连接到分配的机器通过SSH（* nix中）或WinRM的（windows）

3.         安装和启动Cloudify agent

4.         启动服务的安装，使用有关服务的安装脚本

图45-07： Cloudify计算节点的调用时序

下面用一张图来示意cloudify的内部工作流程。

1.         用户提交写好recipe的应用，cc根据recipe的配置，通过cloud dirver寻找需要的vm。

2.         cloud diriver透过jclouds调用iaas api，通过iaas的计算服务得到新的vm。

3.         cc通过安装程序把agent部署在新的vm上，并执行一系列引导处理，使得该vm成为新的计算节点，并被cc所监控。

4.         透过计算节点的agent，安装应用，启动服务，新的节点启动完毕。

图45-08： cc启动应用服务

4.5.5           安装部署

       相对其他的paas平台来说，Cloudify的安装和配置较为简单，一般来说分为4个步骤：

l         配置底层云平台（Configure Clouds）

   每个云的实现是不同的。因此，为Cloudify工作与你的云，你可能需要配置您的云，如SSH安全方面。有关配置云提供商与Cloudify工作的信息，是指对有关主题，从下面的列表支持云： Azure，EC2，OpenStack，Traditional Data Center等。

l         创建云端镜像盘（Create Cloud Images）

   Cloudify在启动过程中需要配置机器的时候，就需要使用云端镜像。根据配置，由cloud service为某台机器创建特定的云端镜像盘，当然了镜像盘需要满足起码的最低要求。

   软件方面：

ü         每个镜像盘预必须安装JDK 1.6或更高，

ü         以及SSH守护进程必须启动并运行22端口；

   网络方面：

ü         在相同的服务，彼此之间的机器端口要开放；

ü         管理机和节点机之间的所有端口打开；

ü         管理虚拟机上，8099和8100端口必须是从互联网开放的沟通，通过虚拟机的公网IP地址。以便允许Cloudify shell与REST服务器交互，并允许用户访问管理Web应用程序。

l         配置云端驱动（Configure Cloud Drivers）

   Cloudify通过抽象层来屏蔽底层云平台的差异，所以在不同的云平台进行切换的时候，不必改变我们为应用写的资源定制（recipe）。但是在私有云上工作，需要在配置云端驱动之前额外做点工作。

1.         在私有云Cloudify分布文件存储。由于私有云经常断开与互联网连接，或者是加快Cloudify配置过程，cloudify推荐在本地存储Cloudify分发文件。分发文件引导Cloudify管理机时，使用的Cloudify云端驱动时安装上的应用机器Cloudify代理。一些私有云平台提供了存储服务，从中获取分发文件，在云端驱动的序配置文件中指定此服务的URI位置即可。如果使用Cloudstack，必须创建一个虚拟机上存储Cloudify的分发文件。

2.         需要创建镜像盘。Cloudify分发文件带有内置在Cloudify镜像盘。如果应用需要额外的图像，你可以创建它们使用私有云的控制台。

l         创建资源定制（Create Recipes）

       在部署应用程序之前，用Recipes对应用进行配置并部署

Cloudify的快速范例，参看《补充资料_cloudify快速上手.doc》

4.5.6           开发方式

参看《补充资料_Cloudify开发上手.doc》

4.5.7            后续工作

图45-07： Cloudify计算节点的调用时序

下面用一张图来示意cloudify的内部工作流程。

1.         用户提交写好recipe的应用，cc根据recipe的配置，通过cloud dirver寻找需要的vm。

2.         cloud diriver透过jclouds调用iaas api，通过iaas的计算服务得到新的vm。

3.         cc通过安装程序把agent部署在新的vm上，并执行一系列引导处理，使得该vm成为新的计算节点，并被cc所监控。

4.         透过计算节点的agent，安装应用，启动服务，新的节点启动完毕。

图45-08： cc启动应用服务

4.5.5           安装部署

       相对其他的paas平台来说，Cloudify的安装和配置较为简单，一般来说分为4个步骤：

l         配置底层云平台（Configure Clouds）

   每个云的实现是不同的。因此，为Cloudify工作与你的云，你可能需要配置您的云，如SSH安全方面。有关配置云提供商与Cloudify工作的信息，是指对有关主题，从下面的列表支持云： Azure，EC2，OpenStack，Traditional Data Center等。

l         创建云端镜像盘（Create Cloud Images）

   Cloudify在启动过程中需要配置机器的时候，就需要使用云端镜像。根据配置，由cloud service为某台机器创建特定的云端镜像盘，当然了镜像盘需要满足起码的最低要求。

   软件方面：

ü         每个镜像盘预必须安装JDK 1.6或更高，

ü         以及SSH守护进程必须启动并运行22端口；

   网络方面：

ü         在相同的服务，彼此之间的机器端口要开放；

ü         管理机和节点机之间的所有端口打开；

ü         管理虚拟机上，8099和8100端口必须是从互联网开放的沟通，通过虚拟机的公网IP地址。以便允许Cloudify shell与REST服务器交互，并允许用户访问管理Web应用程序。

l         配置云端驱动（Configure Cloud Drivers）

   Cloudify通过抽象层来屏蔽底层云平台的差异，所以在不同的云平台进行切换的时候，不必改变我们为应用写的资源定制（recipe）。但是在私有云上工作，需要在配置云端驱动之前额外做点工作。

1.         在私有云Cloudify分布文件存储。由于私有云经常断开与互联网连接，或者是加快Cloudify配置过程，cloudify推荐在本地存储Cloudify分发文件。分发文件引导Cloudify管理机时，使用的Cloudify云端驱动时安装上的应用机器Cloudify代理。一些私有云平台提供了存储服务，从中获取分发文件，在云端驱动的序配置文件中指定此服务的URI位置即可。如果使用Cloudstack，必须创建一个虚拟机上存储Cloudify的分发文件。

2.         需要创建镜像盘。Cloudify分发文件带有内置在Cloudify镜像盘。如果应用需要额外的图像，你可以创建它们使用私有云的控制台。

l         创建资源定制（Create Recipes）

       在部署应用程序之前，用Recipes对应用进行配置并部署

Cloudify的快速范例，参看《补充资料_cloudify快速上手.doc》

4.5.6           开发方式

参看《补充资料_Cloudify开发上手.doc》

4.5.7            后续工作

Cloudify从项目开发云端架构

标签：

原文地址：http://my.oschina.net/u/2322561/blog/399973