Heat/蓝图/滚动更新
- Launchpad 条目: HeatSpec:rolling-updates
- 创建于: 2013年2月7日
- 贡献者: Clint Byrum
目录
总结
在管理大量实例时,我可能希望将拓扑和/或配置的更改推广到这些实例的有限百分比,然后等待查看这些初始推广是否产生故障或成功,然后再部署更大百分比的实例。 这被称为“金丝雀”部署策略,源自旧的采矿实践,即在灯笼中携带金丝雀来测试空气质量。
发布说明
多实例资源现在可以通过 update_pattern 属性与 OS::Heat::UpdatePattern 相关联。 这将导致 Heat 使用滚动或金丝雀策略应用更新。
原理
对于大规模部署,一次性在所有机器上更新配置可能会导致停机。 能够控制部署将为实施该部署的用户带来更高的可靠性。
用户故事
作为一名运维工程师,我希望能够在不冒重大停机或错误率风险的情况下,将拓扑或配置的更改推广到非常大的资源上。
前提条件
设计
OS::Heat::UpdatePattern
这将作为两种变体(滚动和金丝雀)的基础类
rolling_pattern:
type: OS::Heat::RollingUpdatePattern
properties:
min_in_service: 1
batch_size: 2
canary_pattern:
type: OS::Heat::CanaryUpdatePattern
properties:
min_in_service: 1
batch_size: 2
growth_factor: 2
rolling
更新将一次完成 batch_size 个资源。 如果正在运行的资源数量低于 min_in_service,则将启动 batch_size 减去 min_in_service 个更新。
canary
与 rolling 相同,除了每次成功批处理后,batch_size 将乘以 growth_factor 增加。
depends_on
为了确定如何继续更新,Heat 将在更新资源之前检查资源的依赖项。 Heat 将调用父级中的一个钩子,该钩子将允许父级返回一个等待条件。
example
resources:
rolling_update_dbs:
type: OS::Heat::RollingUpdate
properties:
min_in_service: 1
batch_size: 1
db_server1:
type: OS::Nova::Server
depends_on: rolling_update_dbs
properties:
image: db-server-image
flavor: giant-server
db_server2:
type: OS::Nova::Server
depends_on: [ rolling_update_dbs , db_server1 ]
properties:
image: db-server-image
flavor: giant-server
canary_update_app:
type: OS::Heat::CanaryUpdate
properties:
min_in_service: 10
batch_size: 2
growth_factor: 2
appservers:
type: OS::Heat::ResourceGroup
depends_on: [ db_server2, canary_update_app ]
properties:
count: 20
resource_def:
type: OS::Nova::Server
properties:
image: my-cool-app
flavor: meh-server
实现
更新父级钩子
必须创建两个新的资源 API 钩子点,资源作者可以实现这些钩子点来控制子资源的更新。 它们将是 child_creating 和 child_updating。 child_creating 将在创建子资源时调用,以允许它动态创建子资源可能获取的任何属性。 对于滚动更新,这将是更新等待条件句柄(或组的情况下的句柄)。 child_updating 将实现允许返回 Heat 等待子资源上的任何等待条件的逻辑。
OS::Heat::UpdatePattern
此资源将为每个依赖资源创建等待条件。 对于组,它需要为每个组的成员创建等待条件和句柄。 它将实现 update_child 钩子。 在收到通知子资源正在更新时,它将检查当前更新的状态并返回所有必须在子资源允许前进之前完成的等待条件。
heat.engine.update
必须进行更改以调用子级钩子,并等待由 child_updating 返回的等待条件。
UI 变更
不适用
代码变更
待定
迁移
测试/演示计划
- 回滚也应尊重更新模式,虽然鉴于该方案,这“应该”可以正常工作,但尚不清楚。因为回滚本质上是反向更新。
未解决的问题
- 在大型实例组中,故障可能很常见。 任何可以预期且不应回滚更新的故障条件都应识别并处理。