优雅重启是按依赖顺序、分批次、带健康检查、可中断回滚的受控运维操作。它通过serial控制并发、pre_tasks/post_tasks联动负载均衡、wait_for/uri校验就绪、block/rescue实现回滚，并需--check预演、assert守卫、Vault加密和日志告警。
在 Linux 中用 Ansible 优雅重启大规模集群服务，核心不是“暴力杀进程再启”，而是**按依赖顺序、分批次、带健康检查、可中断回滚**地完成。它要求你把“重启”这件事当作一个受控的运维操作来设计，而不是一条 shell 命令。
定义什么是“优雅重启”
对服务集群而言，“优雅”意味着：
- 不中断用户请求：新请求能被剩余健康节点承接（如负载均衡自动摘除+加回）
- 不丢数据：服务主动拒绝新连接、处理完存量请求后再退出（graceful shutdown）
- 不雪崩：避免所有节点同时重启导致后端依赖（DB、缓存、下游 API）被打满
- 可感知状态：每一步执行结果明确，失败时能快速定位是哪台机器、哪个环节卡住
关键步骤：分组 + 滚动 + 校验
Ansible 本身不内置“滚动重启”逻辑，但通过组合参数和模块，可以精准实现：
-
用
serial控制并发数：在 Playbook 的 top-level 设置serial: 2或serial: "25%"，让每次只对 2 台或 25% 的主机执行该 Play，其余等待 -
用
pre_tasks和post_tasks补位：例如前置调用负载均衡 API 摘除节点，后置调用 API 加回并等待健康检查通过 -
用
wait_for或自定义脚本校验服务就绪：比如检查curl -f http://localhost:8080/actuator/health返回 200，或监听端口是否可连通 -
用
ignore_errors: yes+block+rescue实现失败回滚：某台机器重启失败时，自动触发还原配置或重启旧版本服务
典型 Playbook 片段示例
以重启 Java Web 服务为例（假设使用 systemd）：
- name: Rolling restart of app service
hosts: app_servers
serial: 2
vars:
app_service_name: myapp.service
pre_tasks:
- name: Drain node from LB (e.g., via HTTP API)
uri:
url: "https://www.php.cn/link/d637dca8c61547167d887daeec510c16{{ inventory_hostname }}/drain"
method: POST
status_code: 200
delegate_to: localhost
run_once: true
<p>tasks:</p><ul><li><p>name: Stop service gracefully
systemd:
name: "{{ app_service_name }}"
state: stopped
force: no</p></li><li><p>name: Wait for port to close (confirm graceful exit)
wait_for:
port: 8080
state: stopped
timeout: 60</p></li><li><p>name: Start service
systemd:
name: "{{ app_service_name }}"
state: started
enabled: yes</p></li><li><p>name: Wait for service to be healthy
uri:
url: "http://{{ inventory_hostname }}:8080/actuator/health"
status_code: 200
timeout: 30
register: health_check
until: health_check.status == 200
retries: 6
delay: 5</p></li></ul><p>post_tasks:</p><ul><li>name: Re-enable node in LB
uri:
url: "<a href="https://www.php.cn/link/d637dca8c61547167d887daeec510c16">https://www.php.cn/link/d637dca8c61547167d887daeec510c16</a>{{ inventory_hostname }}/enable"
method: POST
status_code: 200
delegate_to: localhost
run_once: true
生产环境必须加的防护项
直接跑上面 Playbook 还不够稳妥，上线前建议补全：
-
启用
--check模式预演：先运行ansible-playbook deploy.yml --check看哪些主机会被影响、哪些任务会变更，不实际执行 -
用
assert模块做前置守卫：比如确认所有目标主机已安装对应 systemd unit 文件、JVM 版本符合要求、磁盘剩余空间 >10GB -
敏感操作加 Vault 加密：LB API Token、数据库密码等绝不硬编码在 Playbook 中，统一走
ansible-vault管理 -
记录执行日志到文件 + 推送告警：用
callback_plugins或log_plays插件落盘，并在失败时触发企业微信/钉钉通知
本质上，Ansible 不是“重启工具”，而是“运维意图表达语言”。你写下的每行 YAML，都是在声明“我希望集群此刻处于什么状态”。只要这个声明足够精确、覆盖边界、留有退路，大规模服务的重启就能既稳定又可控。
