延迟服务重启¶
当一个 charm 或包被升级时,服务会被重启。这可能会影响数据平面,导致中断。本规范旨在为云操作员提供延迟这些重启到以后更方便的时间的选择。
问题描述¶
一个例子是,一个 charm 升级包含一个小的模板更改。Charm 升级会在应用程序的所有单元上同时执行(云操作员无法控制这一点)。这些 charm 被设计为在配置文件更改时重启服务,因此所有单元上的相同服务集将同时重启。
另一个例子是,当 charm 触发一个包更新时,在长时间的包更新完成后,延迟任何服务重启可能是有用的。
提议的变更¶
添加 charm 配置选项以控制自动服务重启。
enable-auto-restarts:
type: boolean
default: True
description: |
Allow the charm and packages to restart services automatically when
required
添加 charm 操作以运行服务重启。
restart-services:
description: |
Restarts services this charm manages.
params:
deferred-only:
type: boolean
default: false
description: |
Only restart deferred services.
services:
type: string
default: ""
description: |
Optional space seperated list of services to restart. If unset
then it applies to all services the charm controls.
show-deferred-restarts:
description: |
Show the outstanding restarts
如果一个 charm 禁用了 enable-auto-restarts,这将反映在 charm 的工作负载状态消息中。通过运行 show-deferred-restarts 操作,可以看到 charm 或包更新请求但已延迟的重启。
为了阻止重启,charm 首先会检查是否禁用了 enable-auto-restarts,并且仅在允许的情况下才执行重启。理想情况下,防止服务被停止或重启应该在 systemd 中完成,但这似乎没有一种干净的方式来实现。依赖 charm 来自我约束不是理想的,因为重启命令可能来自许多地方,并且始终存在未来 charm 更新引入不遵守 enable-auto-restarts 的重启调用的风险。
包更新期间可能会尝试重启服务。为了防止这种情况发生,将安装一个自定义的 /usr/sbin/policy-rc.d 脚本,以阻止包更改导致任何重启。Charm 将通过将文件写入 /etc/policy-rc.d 来指示它们想要阻止重启哪些服务。/usr/sbin/policy-rc.d 将收集来自 /etc/policy-rc.d 的所有文件,以构建一个不允许重启的服务列表。
延迟重启的流程
操作员更新应用程序以设置 enable-auto-restarts=False
写入一个 /usr/sbin/policy-rc.d 文件
将一个 charm 特定的文件放置在 /etc/policy-rc.d 中,其中列出了应阻止重启的服务。
重新启用重启的流程
操作员更新应用程序以设置 enable-auto-restarts=True
从 /etc/policy-rc.d 中删除 charm 特定的文件
可选地,操作员可以针对每个应用程序单元运行 restart-services 操作。
现有的 Pause 和 Resume 操作将继续像现在一样运行,而与 enable-auto-restarts 的值无关
备选方案¶
如果 Juju 能够实现一个允许逐个单元执行 charm 更新的功能,就可以处理这个问题。
实现¶
负责人¶
- 主要负责人
gnuoy
Gerrit Topic¶
对于与本规范相关的所有补丁,请使用 Gerrit 主题“deferred-restarts”。
git-review -t deferred-restarts
工作项¶
将 policy-rc.d 脚本写入并添加到 charm-helpers 中
在 charm-helpers 中编写函数,用于管理服务的屏蔽以及 /etc/policy-rc.d 中的文件。
每个 charm 都需要添加新的操作和配置选项,并且 charm 需要以类似于现有的 is_unit_paused_set 的方式,根据 enable-auto-restarts 的值来限制任何中断服务的重启。
仓库¶
不需要新的仓库。
文档¶
需要在 charm-guide 中记录新的操作,并更新升级部分。
安全性¶
无
测试¶
定期安排的升级测试将是测试此功能的良好场所。
依赖项¶
无