在Google Cloud Platform创建实例时启动脚本无法运行的问题排查

我之前在GCP部署实例时也碰到过类似情况，核心问题出在启动脚本的运行身份和手动执行时的环境差异上，下面拆解原因和解决办法：

为什么会出现这个问题？ #

GCP的启动脚本默认是以root用户身份执行的，但你手动操作时是用普通用户（比如ubuntu）通过sudo执行命令，两者的环境变量、包安装路径处理逻辑有细微差别：

1. 脚本里的sudo完全多余——root用户执行sudo不会切换身份，但可能干扰apt的安装上下文，导致bundle的路径没有被正确添加到系统全局环境中；
2. 即使包安装成功，普通用户的PATH可能没包含bundle的实际安装路径（比如Ruby gem的二进制文件目录），登录后自然找不到命令。

具体解决步骤 #

方案1：移除启动脚本中的多余sudo #

修改你的startup.sh，去掉所有sudo（因为启动脚本本身就是root身份运行）：

#!/usr/bin/env bash
apt update
apt install -y ruby-full ruby-bundler build-essential

重新创建实例后，登录执行bundle -v应该就能正常识别命令了。

方案2：确保普通用户PATH包含bundle路径 #

如果方案1无效，先登录实例找到bundle的实际安装路径：

sudo which bundle

假设输出是/var/lib/gems/2.3.0/bin/bundle，就在启动脚本末尾添加以下内容，把这个路径添加到系统全局的PATH配置中：

echo 'export PATH=$PATH:/var/lib/gems/2.3.0/bin' >> /etc/profile.d/ruby-path.sh
chmod +x /etc/profile.d/ruby-path.sh

这样所有用户登录时都会自动加载这个路径配置。

方案3：检查启动脚本执行日志排查错误 #

如果以上方法都不行，先看看启动脚本有没有执行失败的情况：
登录实例后查看cloud-init的输出日志：

cat /var/log/cloud-init-output.log

或者过滤syslog中的启动脚本相关内容：

grep -A 20 -B 5 'startup-script' /var/log/syslog

看看apt安装过程中有没有报错（比如依赖缺失、网络超时等），根据日志再针对性解决。

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