GCE托管实例组启动脚本失败：如何终止启动、上报错误及重启实例？

我之前处理过不少GCE MIG启动脚本失败的场景，给你梳理几个关键的处理思路和实践方案：

一、在启动脚本中传递错误信号并终止流程 #

Bash脚本本身可以通过退出码向GCE传递失败信号，核心是确保脚本在关键步骤失败时以非零状态码退出：

1. 启用严格错误检查
   在脚本开头添加这行命令，让脚本在任何命令失败、使用未定义变量或管道命令出错时立即退出：

   set -euo pipefail
   

   这样大部分失败场景都会自动触发脚本退出，无需手动检查每个命令的状态。

2. 手动精细控制错误（可选）
   如果需要针对特定步骤输出自定义错误信息，或者有特殊的失败处理逻辑，可以手动检查命令的退出码：

   # 拉取代码失败时终止脚本
   git pull https://your-git-repo.git || { echo "ERROR: Git代码拉取失败"; exit 1; }
   
   # 安装依赖失败时终止脚本
   apt-get install -y your-dependency-package || { echo "ERROR: 依赖安装失败"; exit 2; }
   

   这里的exit 1/exit 2就是传递给GCE的错误信号，非零值会被识别为启动失败。

二、让失败实例自动重启/替换（MIG核心能力） #

托管实例组（MIG）的自动修复和健康检查机制是处理启动失败的最佳方式，比脚本内直接重启更可靠：

1. 配置启动健康检查
   GCE的启动健康检查会验证实例是否完成初始化。你可以：

   • 在启动脚本的最后一步（所有操作成功后）创建一个标记文件：

     touch /var/run/startup-successful
     

   • 创建一个自定义脚本健康检查，检查这个文件是否存在；或者如果你的服务启动后有HTTP端点，也可以用HTTP健康检查。
     当健康检查检测到文件不存在（即脚本失败），会把实例标记为不健康。

2. 启用MIG自动修复
   确保你的托管实例组开启了自动修复功能：

   • 在MIG配置中，设置自动修复的健康检查为你刚才创建的启动健康检查
   • 当实例被标记为不健康时，MIG会自动删除这个失败实例，并基于实例模板创建新的实例，直到启动成功。

3. 脚本内重启（不推荐但可用）
   如果临时需要脚本失败后立即重启实例，可以在错误分支添加reboot命令，但这种方式不如MIG自动修复可靠（比如重启后仍失败会陷入循环）：

   git pull ... || { echo "拉取失败，重启实例"; reboot; }
   

三、其他优化方案 #

• 添加重试机制：针对网络波动导致的git拉取或依赖安装失败，可以用循环重试：

  MAX_RETRIES=3
  RETRY_COUNT=0
  until git pull https://your-repo.git; do
    RETRY_COUNT=$((RETRY_COUNT+1))
    if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
      echo "重试$MAX_RETRIES次失败，终止启动"
      exit 1
    fi
    echo "拉取失败，10秒后重试..."
    sleep 10
  done
  

• 完善日志记录：把脚本输出重定向到日志文件，方便排查失败原因：

  # 在脚本开头添加，将所有输出写入日志
  exec > /var/log/startup-script.log 2>&1
  

• 预打包自定义镜像：如果启动脚本经常因为拉取代码/安装依赖失败，可以预先把代码、依赖打包到自定义镜像中，实例启动时直接运行服务，避免每次启动都执行这些易失败的步骤。

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