Heat/Blueprints/hot-software-config
目录
HOT 软件配置
--stevebaker (讨论) 21:10, 15 October 2013 (UTC)
注意:此规范仍在讨论中,尚未获得 heat 项目的认可。
背景
蓝图 software-configuration-provider 及其规范 [1] 是迄今为止指定 HOT 解决方案来处理 Heat 软件配置的最完整的尝试。
蓝图 hot-software-config 和 hot-software-config-deps 似乎与 software-configuration-provider 密切相关
此规范试图解决与 [2] 相同的问题,但在某些方面采取了不同的方法。希望 heat-core 开发人员能够达成共识,以便开始实施。
蓝图 native-tools-bootstrap-config 和规范 [3] 与此规范相关,并将随着更改的进行而共同发展。
另请参阅 Angus 的精彩(咯咯)方法,请参见此 [4]
组件与资源:表示软件配置
Heat 资源代表通过其 API 管理的云资源的配置和生命周期。少量 Heat 资源不映射到云资源,而是代表内部 Heat 状态。这通常是问题的原因,并提醒我们不要将资源抽象用于其设计目的之外的用途。其他编排/配置管理工具选择单一抽象来表示编排和配置管理。根据选择的抽象,通常这些工具中的一个或另一个领域会得到较差的表示。
组件定义
Heat 的软件配置涉及定义需要在计算资源上执行的工作单元(组件),每当创建或更新该资源时。
每个组件需要能够指定以下内容
- 配置组件的类型
- 表示组件将执行的工作单元的配置数据
HOT 模板将具有一个新的顶级部分,称为 components。就像 resources 一样,components 将包含命名块,其中每个块代表可以由其名称在其他地方引用的单个组件。每个组件还将具有以下属性
-
type指定要使用的组件实现,指示config部分将使用哪种配置管理工具语法。 -
config数据将传递给配置管理工具以执行组件所需的配置。config块中没有对 HOT 内置函数的处理;它们旨在是自包含的配置单元。理想情况下,应该能够在没有任何修改或 Heat 参与的情况下,直接使用配置管理工具调用config部分的内容。根据配置管理工具要求的格式,config属性可以包含包含脚本的字符串,也可以包含 YAML 结构。 -
config-file作为config的替代方案,指定加载配置的 URL 或相对文件路径。解析为本地文件的路径需要由 heat 客户端解析。
components 部分的示例
components:
install_mysql:
type: Heat::SoftwareConfig
config:
packages:
yum:
mysql: []
mysql-server: []
services:
systemd:
mysqld: {enabled: 'true', ensureRunning: 'true'}
install_wordpress:
type: Heat::SoftwareConfig
config:
packages:
yum:
httpd: []
wordpress: []
services:
systemd:
httpd: {enabled: 'true', ensureRunning: 'true'}
foo_file:
type: Heat::SoftwareConfig
config:
files:
/tmp/foo/bar:
content: 'foo_bar_contents'
组件调用
组件只能在计算资源上调用。AWS::EC2::Instance 的属性必须与 cfn 兼容,但是 OS::Nova::Server 没有这样的限制。OS::Nova::Server 将获得一个 components 属性,该属性指定应用于服务器的组件列表,顺序为所需顺序。components 列表中的每个条目将包含以下属性
-
name要调用的组件的名称,如components部分中指定 -
params来自堆栈资源、参数、属性或静态值的参数映射到每个组件中的配置管理变量。这些参数的处理方式取决于组件类型以及该类型使用的配置管理工具。
具有 components 属性的 OS::Nova::Server 的示例
resources:
the_server:
type: OS::Nova::Server
properties:
components:
- name: install_things
- name: write_foo_bar
params:
foo_bar_contents:
get_param: the_file_contents
- name: repo_epel_5_testing
- name: some_user_data
为什么不使用 hosted_on、depends_on、connects_to 关系?
先前关于 HOT 组件的 提案 指定每个组件定义可以指定一个 relationships 属性,该属性允许定义以下关系
-
hosted_on定义组件托管在引用的组件或资源上 -
depends_on定义组件对引用的组件或资源具有一般依赖关系 -
connects_to定义组件需要连接到引用的组件或资源。与 depends_on 相比,connects_to 关系通常涉及执行一些代码以建立连接
此提案故意没有 relationships 属性。由于以下原因,每种关系类型都不需要
-
hosted_on在 OS::Nova::Server 的components属性中表示。hosted_on反转了 Heat 已经建立的两个实体之间关系的约定。如果组件/资源关系由资源定义,则可以建立分层,从而组件层永远不会引用堆栈/资源层。 -
depends_on由 OS::Nova::Server 的components属性中指定的组件顺序表示。从实践上讲,一个组件根本不“依赖”另一个组件。相反,一个组件可能具有可以通过另一个特定组件满足的先决条件,或者可以通过以不同方式执行该先决条件的另一个组件满足,或者该先决条件可能已经由服务器镜像满足。对这些先决条件进行建模是许多配置管理工具的核心目的。在 HOT 组件中进行此建模将是重新发明一些已经由一些组件将使用的工具更完整地实现的工具。因此,此提案认为不应建模组件依赖关系,并且模板作者应确保组件的先决条件通过指定组件顺序或构建自定义镜像来满足。 -
connects_to此关系类型的提案尚未提供足够的细节来对其进行评估,但如果需要,应该有一种以其他方式对其进行建模的方法。
可组合性
HOT 组件的既定目标是将应用程序配置与堆栈架构分离,并允许在不同的模板中重用应用程序配置组件。
通过使用 config-file 属性来最大化可组合性,以便配置脚本作为它们自己的可重用文件存在。考虑以下伪示例
components:
install_db:
type: Heat::Puppet
config-file: install_db.pp
configure_db_for_app:
type: Heat::Puppet
config-file: configure_db_for_app.pp
configure_app:
type: Heat::Puppet
config-file: configure_app.pp
resources:
db_and_app:
type: OS::Nova::Server
properties:
components:
- name: install_db
- name: configure_db_for_app
- name: configure_app
params:
db_server: localhost
指定简单两层架构的模板可以指定相同的 components 部分,并为资源指定以下内容
resources:
db_server:
type: OS::Nova::Server
properties:
components:
- name: install_db
- name: configure_db_for_app
app_server:
type: OS::Nova::Server
properties:
components:
- name: configure_app
params:
db_server:
get_attr: [db_server, first_address]
另一个模板可以指定应用程序服务器的负载均衡 HA,同时仍然使用相同的 configure_app.pp 组件配置。
并发性和依赖关系
考虑以下资源
resources:
db_server:
type: OS::Nova::Server
app_server:
type: OS::Nova::Server
properties:
components:
- name: do_first_thing
- name: configure_app
params:
db_server:
get_attr: [db_server, first_address]
- name: do_last_thing
Heat 的当前行为是在完成 db_server 创建后才开始创建资源 app_server。此依赖关系由 configure_app 组件中对 get_attr: [db_server, first_address] 的调用确定。
但是,在此场景中存在增加并发性的潜力。可以在创建 db_server 的同时创建 app_server,并且 do_first_thing 组件可以执行其配置。然后,在创建 db_server 后,可以阻止进一步的配置进度,然后 configure_app 和 do_last_thing 可以执行其配置。
考虑以下 app_server 的替代方案
app_server:
type: OS::Nova::Server
properties:
component_execution: async
components:
- name: do_first_thing
- name: configure_app
params:
db_server:
get_attr: [db_server, first_address]
- name: do_last_thing
指定 component_execution: async 将执行以下操作
- 防止为
components属性内的任何 get_attr 或 get_resource 调用建立资源依赖关系(在这种情况下,app_server将不再依赖于db_server) - 防止在能够解析所有值之前构建
configure_app和do_last_thing的元数据 - 依赖 os-collect-config 轮询,以便在完成
db_server创建时触发configure_app和do_last_thing。
等待条件
目前在 Heat 中,等待条件是接受的从服务器向编排引擎通信数据或事件的方式。目前使用等待条件编写模板可能很麻烦,因为它需要
- 一个等待条件资源
- 一个等待句柄资源
- 服务器配置以调用 cfn-signal(或 curl)并使用等待句柄 URL
- 对等待条件进行
get_attr调用以建立对等待条件结果的资源依赖关系。
将来可能会实现一种完全不同的机制,但与此同时,此蓝图应启用更简洁的等待条件表示,以简化其使用。
实际方法将在蓝图 hot-software-config-deps 中指定,因此此处不会对其进行详细探讨,但提供了一个可能的解决方案,只是为了确认组件具有简化此功能的潜力
components:
install_db:
type: Heat::Puppet
config-file: install_db.pp
configure_db_for_app:
type: Heat::Puppet
config-file: configure_db_for_app.pp
return_db_url:
type: Heat::WaitCondition
config: |
#!/bin/sh
# shell script which builds and returns a db URL
configure_app:
type: Heat::Puppet
config-file: configure_app.pp
resources:
db_server:
type: OS::Nova::Server
properties:
components:
- name: install_db
- name: configure_db_for_app
- name: return_db_url
params:
wait_condition_resource: db_server_url
app_server:
type: OS::Nova::Server
properties:
components:
- name: configure_app
params:
db_server:
get_attr [db_server_url, first_data]
在这里,Heat::WaitCondition 组件实现调用 cfn-signal 并使用任意数据所需的任何内容,因此配置脚本的唯一工作是构建要发出的数据。
指定 wait_condition_resource: db_server_url 将隐式创建可以由其他资源引用的等待句柄资源和等待条件资源。