Cloudify中的部署组合（转载）

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