Azure 虚拟机规模集(VMSS)应用代码更新部署方案咨询

针对你的现有架构和需求，以下是两类可行的方案，你可以根据自己的运维习惯选择：

最小改动方案（无需新增工具，完全复用现有逻辑） #

这是成本最低、适配最快的方案，几乎不需要修改你已经跑通的更新流程：

• 保留你现有针对单个站点的更新 Bash 脚本，将脚本和 Git 仓库配置直接内置到你制作 VMSS 的基础镜像中，各个站点的独立目录结构和 Nginx 配置完全沿用单VM时期的逻辑即可
• 把原有的 cron 定时自动拉取逻辑改为按需触发，匹配你需要先做手动调整的发布要求
• 需要更新指定站点时，直接通过 Azure CLI 的 az vmss run-command invoke 命令，批量在所有 VMSS 实例上执行对应站点的更新脚本，示例命令如下：

# 触发所有VMSS实例执行站点1的更新脚本
az vmss run-command invoke \
  --resource-group <你的资源组名称> \
  --name <你的VMSS集群名称> \
  --command-id RunShellScript \
  --scripts "/opt/site-scripts/update-site1.sh"

• 优势：不需要引入额外的CI/CD工具，手动调整步骤可以直接集成到对应站点的更新脚本中，天然支持单站点独立更新，不需要全量发布。

Azure 原生标准方案（适合后续扩容、需要发布管控的场景） #

如果你需要更规范的发布流程、灰度发布能力，可以采用Azure原生的扩展+滚动更新方案：

• 将各个站点的更新脚本/发布包提前上传到Azure存储账户的私有容器中，完成客户要求的手动调整后再上传最终版本
• 给VMSS配置自定义脚本扩展，指定拉取存储账户中对应站点的更新脚本执行
• 触发VMSS滚动更新，Azure会自动按批次逐个更新实例，更新过程中应用网关会自动切走正在更新实例的流量，不会影响业务可用性
• 同样支持单站点独立更新，仅需要指定对应站点的更新脚本即可，不会修改其他站点的文件。

注意事项 #

• 两种方案都建议在发布前先对VMSS做一次镜像备份，出现发布问题时可以快速回滚
• 如果你需要保留实例本地的自定义修改，确保VMSS的升级策略没有配置为重新镜像模式，避免实例被重置导致修改丢失
• 你的SSL已经在应用网关层终结，VMSS实例侧的Nginx配置不需要做任何调整，直接复用单VM时期的配置即可。

内容的提问来源于stack exchange，提问作者DLB555