supervisor自动化部署需动态生成配置、精准reload并清晰日志：部署脚本生成/etc/supervisor/conf.d/下.conf文件，指定路径、用户、环境及startsecs=10；设autorestart=unexpected、startretries=3、stopwaitsecs=15、重定向日志；部署后执行reread/update/status校验；联动生命周期，部署前stop、覆盖后update、多进程用[group]统一管理。
用 Supervisor 实现自动化部署后应用的崩溃自动拉起，核心是让部署脚本生成或更新 Supervisor 配置，再触发重载，整个过程可嵌入 CI/CD 流水线。关键不在“装一次”，而在于“配得准、 reload 得稳、日志看得清”。
部署时自动生成配置文件
自动化部署脚本（如 Ansible、Shell 或 GitHub Actions）应在应用安装完成后，动态生成对应的 .conf 文件到 /etc/supervisor/conf.d/ 目录下。例如：
- 路径统一：应用二进制放在 /opt/myapp/bin/app，日志目录预建为 /var/log/myapp/
- 用户隔离：指定非 root 用户（如 myapp），避免权限越界
- 环境注入：若应用依赖特定 PATH 或 PYTHONPATH，通过 environment 字段写入
- 启动校验：设置 startsecs=10，确保进程真正就绪才标记为 RUNNING，防止假启动
配置中必须包含的重启策略
仅设 autorestart=true 不够稳妥。建议组合使用以下参数：
- autorestart=unexpected：跳过主动退出（如调用 exit(0)），只对崩溃、信号终止等异常重启
- startretries=3：连续失败 3 次后停止尝试，避免无限拉起掩盖真实问题
- stopwaitsecs=15：给应用优雅退出留足时间，防止 kill -9 强杀导致状态残留
- redirect_stderr=true + stdout_logfile + stderr_logfile：分离输出，便于定位是 stdout 卡死还是 stderr 报错
部署后立即 reload 并验证状态
配置写入后不能只靠手动操作。脚本中应顺序执行：
- sudo supervisorctl reread：扫描新增/变更的 conf 文件
- sudo supervisorctl update：加载新配置，对已存在程序执行 restart，新程序 start
- sudo supervisorctl status myapp：检查返回是否为 RUNNING，非则报错退出流水线
- （可选）sudo supervisorctl tail -f myapp stdout | head -n 20：快速抓取最新几行日志确认初始化成功
与部署生命周期联动的细节
真正的稳定性来自和部署动作强绑定：
- 每次部署前，先 sudo supervisorctl stop myapp，避免旧进程残留
- 部署包解压覆盖后，再执行 reread/update，确保加载的是新版二进制
- 若应用含多进程（如 Web + worker），可用 [group:myapp] 统一管理，supervisorctl start myapp:* 一键启停整组
- 日志路径建议用绝对路径并提前 mkdir -p /var/log/myapp + chown myapp:myapp，防止启动失败因权限拒绝写日志
