Cloudify中的部署组合
Hi胡瀚
572
快速演练
深入探讨
结论和未来的方向
[这篇文章是由DeWayne Filppi撰写的。]
在Cloudify中，“部署”定义了一个包含nodes（节点）和relationships（关系）集合的独立命名空间。这些节点和关系通常被视为一个完整的技术栈，提供一个完整的计算平台。一个典型的部署包括负载均衡器层，Web服务器层，应用程序服务器层和数据库集群层。在某些情况下，希望有一个island（此处用来代指技术栈的一部分）不代表一个完整的技术栈，而仅仅代表一个技术栈的一部分（例如某一层）。
在这种模式下，数据库部署可以独立于其他层而单独实例化。其他层可以独立于数据库运行。Cloudify默认不支持这种模式，但我们可以通过灵活的插件完成。
快速演练
DeploymentProxy（代理部署服务器）节点可以帮您在部署时解决相关的依赖关系。我们通过blueprint（蓝图）来部署DeploymentProxy节点，此节点其实是被定义为独立，更准确地说，是独立部署的输出。插件的源代码在github上，并包含一个示例。这个例子说明了一个的NodeJS蓝图，依赖于MongoDB的蓝图。依赖关系的细节有些做作，但足以证明。
DeploymentProxy使用蓝图“ 输出 ”作为基点的。所以在这个例子中，第一步是在MongoDB blueprint（蓝图）中建立有意义的输出。
outputs:
endpoint:
description: MongoDB endpoint # 此处是作为蓝图的描述
value:
ip_address: { get_property: [ host, ip ] } #我们通过使用get_property 内部函数提取主机ip
port: { get_property: [mongod, port] }
一旦建立了输出，所有工作都将移到依赖蓝图（NodeJS），该蓝图包含DeploymentProxy节点。首先，NodeJS蓝图包括DeploymentProxy 的插件定义和TOSCA节点定义。
imports:
- 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 Node是表示独立的MongoDb蓝图。它的唯一功能是在内置安装工作流程中使用，以等待（如有必要）或提供有关所引用的蓝图/部署的信息。
proxy:
type: cloudify.nodes.DeploymentProxy
properties:
deployment_id: md
wait_for: expr
test: outputs['endpoint']['value']['port']>0
这个特定的节点演示了一个python布尔表达式，用于确定代理在安装工作流程中何时成功返回。简单来说，安装NodeJS时会一直等待到此条件成立或者操作超时。该表达式是目标部署的“输出”字典。另一个wait_for 选项是“exists” --- 如果命名属性存在于输出中，则返回成功。
最后一步是通过关系将NodeCellar应用程序连接到代理的MongoDB数据库。除了简单地等待MongoDB可用之外，该示例还演示了访问输出以连接到数据库。DeploymentProxy节点在其运行时属性中返回其目标蓝图的输出。
nodecellar:
type: nodecellar.nodes.NodecellarApplicationModule
properties:
port: 8080
relationships:
################################
# 设置mongoDB连接
################################
- 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 runtime_properties outputs.endpoint.value.port)
深入探讨
该插件只有一个功能“wait”，等待目标部署输出的条件。当“启动”方法被调用时，“等待”接收以下参数：
deployment_id：所依赖的部署（部署类似是cloudify的一个应用）的id。
wait_for：“exits”或“expr”。
如果“exits”，将等待一个匹配属性为“test”（就是下面的test参数）的输出。
如果是“expr”，它将属性“test”（就是下面的test参数）解释为一个python布尔表达式，其中集合“outputs”是输出字典（例如expr：outputs [port]> 0
test：输出的名称或布尔表达式（请参阅wait_for）
timeout：等待的秒数。当超时到期时，会引发“RecoverableError”。默认值= 30。
“wait”函数调用Cloudify REST API以从配置的部署id中获取输出。它要么检查一个特定的输出属性是否存在，要么通过python布尔表达式来实现更复杂的条件判断。如果配置wait_for是 “expr”，如果布尔表达式为真则根据目标部署“输出”字典进行部署安装。该函数会因为超时而引发“RecoverableError”报错。Cloudify安装工作流程会自动重试。这一直持续到安装工作流程最终放弃，或表达式评估为真。当DeploymentProxy完成时，它将目标部署的输出复制到它自己的运行属性中。这样此蓝图中的其他节点就可以轻松通过IP和端口访问到此节点。
结论和未来的方向
cloudify.nodes.DeploymentProxy节点提供了部署之间的基本依赖关系机制。它伪装成本地部署节点，同时访问另一个部署，等待其输出描述的就绪状态。这只是这个概念的冰山一角，因为沟通仅限于输出，而且是单向的。这个插件理论上应该可以被扩展到实际触发目标部署的安装，访问和公开运行时属性，并不断更新输出和其他属性。源代码以及本文中的演练的使用示例均在github上可找到。
本文的版权归 Hi胡瀚 所有，如需转载请联系作者。
发表于 2018-01-10
转载自 https://cloud.tencent.com/developer/article/1017164