Cloudify中的部署组合

[这篇文章是由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”接收以下参数：

• deployment_id：依赖的部署。
• wait_for：“exist(存在)”或“expr(表达)”。
  • 如果“exist”，它将等待一个匹配属性“test”值的输出。
  • 如果是“expr”，它将属性“test”解释为一个python布尔表达式，其中集合“outputs”是输出字典（例如表达：outputs [port]> 0

• 测试：要么是输出的名称，或是布尔表达式（请参阅wait_for）
• 超时：需要等待数秒。当超时到期时，会抛出“RecoverableError”。默认值= 30。

“wait”函数调用Cloudify REST API接口来从配置好部署的id中获取输出。 它要么检查一个特定的输出属性是否存在，要么评估一个提供的python布尔表达式来处理更复杂的情况。如果配置表达式，包含目标部署“outputs”字典的“输出”字典在评估表达式时将被包括在内。该函数试图满足“timeout”数秒的条件，此时会引发“RecoverableError（可恢复性错误）”。 这会使Cloudify安装流程进入它自己的重试循环。 这一直持续直到安装流程最终停止，或表达式评估为真的时候。 当DeploymentProxy完成时，它将目标部署的输出复制到它自己的运行属性中。 这允许包含蓝图中的其他节点轻松访问输出，例如可能位于服务器的IP地址和端口的输出。

结论和未来的方向

cloudify.nodes.DeploymentProxy节点提供了部署之间的基本从属关系机制。它伪装成本地部署节点的同时访问另一个部署，等待其输出描述的就绪状态。这只是这个概念的冰山一角，因为沟通仅限于产出，而且是单向的。原则上，实际完全可以通过拓展这个插件来触发目标部署的安装，访问和显示运行属性，并不断更新输出和其他属性。源代码以及在本文中的演示的使用示例都放在github上以供查阅。