跳转到: 导航, 搜索

Heat/软件配置提供者

重要提示:在 OpenStack 设计峰会上讨论后,此页面正在重做。更新内容将很快发布。

此页面已被更新的蓝图和规范取代。现在代表概念的存档。请参阅:https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec

此 wiki 页面与蓝图 https://blueprints.launchpad.net/heat/+spec/software-configuration-provider 相关。其目标是提供有关该蓝图的一些背景信息,从用户(模板作者)的角度解释预期的好处,定义实施要求,并对参考蓝图的实施进行初步设计考虑。

软件配置资源提供者项目的目标是允许模板作者声明性地定义托管在计算实例上的软件组件,从而将软件组件作为 HOT 模板中的一等公民。与 CFN 模板相反,在 CFN 模板中,与软件相关的信息混合在实例元数据和用户数据中(例如,内联脚本),我们希望清楚地将软件组件信息与基础设施定义分离,然后表达软件组件与基础设施的托管关系。
目标不是为不同的软件片段引入不同的资源提供者,而是拥有一个通用的提供者,可以使用 chef 进行声明性配置,也许还有另一个提供者,允许使用自定义脚本(使用对自定义脚本的引用)。

讨论页面: https://wiki.openstack.org/wiki/Talk:Heat/Software-Configuration-Provider

示例

考虑一个用例,其中应将 Wordpress 安装在单个实例上,并且应使用 chef cookbook 来执行此配置。模板作者将声明一个软件组件并声明它应托管在示例模板中定义的计算实例上

heat_template_version: 2013-05-23

parameters:
  # parameters for Wordpress and compute instance ...

components:
  wordpress:
    type: OS::Heat::software_config::chef_solo
    cookbooks:
      wordpress: http://www.example.com/my_cookbooks/wordpress.zip
    # more metadata for chef solo based deployment
    relationships:
      hosted_on: my_instance

resources:
  my_instance:
    type: AWS::EC2::Instance
    # details for instance resource ...

上面的模板定义了一个组件 wordpress 和一个资源 my_instance(请参阅 组件和资源 以获取有关组件与资源的更多详细信息)。该组件 hosted_on 在计算实例资源上(请参阅 组件和资源之间的关系 以获取有关关系的更多详细信息)。支持类型 OS::Heat::software_config::chef_solo 的提供者实现知道如何解释 wordpress 组件声明中的信息。
在 cookbooks 部分,声明了一组必需的 cookbooks,包括对各自存档的引用。在以下内容中,将提供更多元数据(例如要配置的角色)。

relationships 部分列出了当前组件与其他组件或模板中的资源之间的关系。在当前示例中,它表明该软件组件托管在示例模板中定义的计算实例上。也可以只表达对特定类型资源的托管要求(请参阅 HOT 模板中关系的表示法)。无论哪种方式,软件层都与基础设施层清晰分离,从而在以后实现部署灵活性。

实施要求

  • Heat 引擎应跟踪软件组件的状态,即
    • 当所有定义的软件组件都处于 CREATE_COMPLETE 状态时,应将堆栈标记为 CREATE_COMPLETE,而无需模板编写者定义显式等待条件
    • 堆栈数据(heat stack-show 命令的输出)应包含软件组件的表示形式


实施考虑事项

计算实例资源定义不包含有关托管在其上的软件组件的任何数据 - 也就是说,用户不必在模板中定义此数据。在部署时,必须确保将相应用户数据或元数据传递给实例,以便实例内的代理可以负责配置托管在实例上的软件组件。

实例内的代理必须在软件组件的配置完成(或失败)后向 Heat 引擎发出信号,以便可以更新堆栈中的软件组件的状态(请参阅 实施要求)。重要的是,这将隐式完成,而无需模板编写者在模板中显式定义信号构造。

关于某些 HOT 构造的说明

组件和资源

上面的 HOT 模板草案区分了组件和资源。组件构成模板描述的实际工作负载,而资源代表工作负载所需的底层资源。资源由各自的资源提供者(例如 nova 计算资源提供者实现)作为服务提供。

模板可以是嵌套的,即模板可能包含引用更高层模板中的更抽象方式的较低层实现。也就是说,模板可以是更高层模板中引用的资源的提供者。

组件和资源之间的关系

组件和资源可以相互之间具有关系。可以存在从一个组件到另一个组件、从一个组件到资源以及从一个资源到另一个资源的关系。关系在 HOT 模板中资源或组件定义的“relationships”子句中定义。

components:
  my_component:
    # general information
    # ...
    relationships:
      # relations to other components or resources

编排运行时了解三种基本类型的关系

  • hosted_on:定义的组件托管在引用的组件或资源上
  • depends_on:定义的组件对引用的组件或资源具有一般依赖关系
  • connects_to:定义的组件需要连接到引用的组件或资源。与 depends_on 相比,connects_to 关系通常涉及执行一些代码来建立连接

从上述基本关系类型,编排器可以推导出基本的编排流程。例如,必须先创建托管资源,然后才能在其之上创建托管组件。

HOT 模板中关系的表示法

在 HOT 模板中定义关系有两种方法

1. 短表示法

components:
  comp1:
    relationships:
      hosted_on: comp2

在上面的示例中,显示了 hosted_on 关系的短表示法。关系定义的键是关系类型 - 在本例中为 hosted_on - 值是引用的组件或资源。

作为引用资源 ID 的替代方法,也可以表示资源类型(例如 os::nova::compute)。这将表示 comp1 需要托管在计算实例上,但不会对计算实例施加任何其他约束。如果需要表达更多约束,则应使用长表示法。

2. 长表示法

components:
  comp1:
    relationships:
      hosted_on_comp2:
        type: hosted_on
        target: comp2

上面的示例显示了 hosted_on 关系的长表示法,即 comp1comp2 之间的关系 - 也就是说,与之前在短表示法中使用的示例相同。关系名称 hosted_on_comp2 是一个任意名称。type 属性表示关系类型。target 属性引用另一个组件或资源。

如果应表达与组件或资源类型的关系(而不是通过 ID 引用具体的组件或资源),则 target 属性将不包含另一个组件或资源的 ID,而是将表示所需资源的类型。然后,编排平台负责以适当的方式满足要求。

示例

components:
  comp1:
    relationships:
      hosted_on_comp2:
        type: hosted_on
        target: os::nova::compute
        constraints:
          arch: x86_64
          cpu:
            greater_or_equal: 2
          memory:
            greater_or_equal: 4GB