[这篇文章是由DeWayne Filppi撰写的。]
在Cloudify中,“部署”定义了一个包含节点和关系集合的独立命名空间。这些节点和关系通常被视为一个提供完整计算平台的完整技术“栈”。一个典型的负载平衡器,web服务器,应用程序服务器和数据库堆栈就是例子。在某些情况下,需要让这些平台”不“代表一个完整的堆栈,而代表一个堆栈的一部分(例如一层)。
在这个模型中,数据库部署(举例)可以独立于其他层实例化。其他层可以独立于数据库进出。Cloudify没有内置的能力来表达这种模型,但通过灵活的插件架构做到这点相当容易。
DeploymentProxy节点允许您在部署之间设置启动从属关系。一个DeploymentProxy节点已经被嵌入到相关蓝图中,并被配置为代表独立蓝图的输出结果,更准确地说,代表的是独立部署的输出结果。插件的源代码在github上,并包含一个示例。这个示例演示了一个从属MongoDB蓝图的NodeJS蓝图。从属关系的细节有些不太自然,但作为演示已经足够好了。
DeploymentProxy使用蓝图“ outputs(输出) ”功能作为切入点。所以在这个例子中,第一步是在MongoDB蓝图中建立有意义的输出。
outputs:
endpoint:
description:MongoDB endpoint
value:
ip_address:{get_property:[host,ip]}
port:{get_property:[mongod,port]}
一旦建立了输出,所有工作都将移到包含Deploymentproxy 节点的从属蓝图(NodeJS)上。首先,NodeJS蓝图包括DeploymentProxy 的插件定义和TOSCA节点定义。
import:
- http://www.getcloudify.org/spec/cloudify/3.1/types.yaml
- http://www.getcloudify.org/spec/diamond-plugin/1.1/plugin.yaml
- types / nodecellar.yaml
#代理的yaml文件是本地的例子,但理想情况是
#位于共享驱动器或Web服务器上
- plugins/proxy/ plugin.yaml
接下来,DeploymentProxy节点本身已被添加。DeploymentProxy节点表示NodeJS蓝图中的独立蓝图(MongoDB)。它的唯一功能,是被用来在内置的安装过程中等待(如有必要)和提供有关蓝图/部署的信息。
proxy:
type:cloudify.nodes.DeploymentProxy
properties:
deployment_id:md
wait_for:expr
test:outputs ['endpoint'] ['value'] ['port']> 0
这个特定的节点演示了一个python布尔表达式,用于决定代理在安装过程中何时成功返回。换句话说,NodeJS安装会等待这个条件成立,或超时。目标部署给该表达式提供了“outputs(输出)”字典。另一种情况是“exists(存在)”,如果命名属性存在于输出中,则成功返回。
最后一步是通过一些关系将NodeCellar应用程序连接到代理所代表的MongoDB数据库。除了简单地等待MongoDB变得可用之外,该示例还演示了通过访问输出来连接到数据库。DeploymentProxy节点在其运行属性中返回来自其目标蓝图的输出。
nodecellar:
type:nodecellar.nodes.NodecellarApplicationModule
properties:
port:8080
relationships:
################################
#设置mongo连接
################################
- type:node_connected_to_mongo
target:mongod
在“Node_connected_to_mongo”关系中,从标准NodeCellar蓝图的原始版本中稍微修改,后配置生命周期方法就得到了MongoDB主机和端口。在原始版本中,它从当前蓝图中的MongoDB节点获取值。在这个版本中,由于MongoDB具有完全独立的蓝图,它从代理节点获取主机和端口。这在/scripts/mongo/set-mongo-url.sh关系实现的NodeJS蓝图中显示。
ctx source instance runtime_properties mongo_ip_address $(ctx target instance runtime_properties outputs.endpoint.value.ip_address)
ctx source instance runtime_properties mongo_port $(ctx target instance insruntime_properties outputs.endpoint.value.port)
该插件只有一个实现函数“wait”,等待目标部署输出的条件。当“start”方法被调用时,“wait”接收以下参数:
“wait”函数调用Cloudify REST API接口来从配置好部署的id中获取输出。 它要么检查一个特定的输出属性是否存在,要么评估一个提供的python布尔表达式来处理更复杂的情况。如果配置表达式,包含目标部署“outputs”字典的“输出”字典在评估表达式时将被包括在内。该函数试图满足“timeout”数秒的条件,此时会引发“RecoverableError(可恢复性错误)”。 这会使Cloudify安装流程进入它自己的重试循环。 这一直持续直到安装流程最终停止,或表达式评估为真的时候。 当DeploymentProxy完成时,它将目标部署的输出复制到它自己的运行属性中。 这允许包含蓝图中的其他节点轻松访问输出,例如可能位于服务器的IP地址和端口的输出。
cloudify.nodes.DeploymentProxy节点提供了部署之间的基本从属关系机制。它伪装成本地部署节点的同时访问另一个部署,等待其输出描述的就绪状态。这只是这个概念的冰山一角,因为沟通仅限于产出,而且是单向的。原则上,实际完全可以通过拓展这个插件来触发目标部署的安装,访问和显示运行属性,并不断更新输出和其他属性。源代码以及在本文中的演示的使用示例都放在github上以供查阅。