Packer用vSphere-iso构建CentOS7镜像在Gitlab-runner运行失败如何解决

核心原因定位 #

问题本质是gitlab-runner非交互式运行环境和手动执行环境的隐性差异，触发了Packer vsphere-iso构建器的提前退出逻辑，并非配置参数本身语法错误。

优先级最高的解决方案 #

因为你使用静态IP分配，完全不需要依赖vCenter的IP上报能力，直接在Packer配置中添加以下两个参数即可：

wait_for_ip = false
ssh_host = "10.118.12.117"

• wait_for_ip = false 会直接关闭vsphere-iso构建器等待vCenter返回虚拟机IP的逻辑，跳过你日志中卡住的「Waiting for IP」阶段
• 固定ssh_host为你boot_command里指定的静态IP，Packer会直接尝试对该IP发起SSH连接等待，直到ssh_wait_timeout超时

其他排查项 #

如果上述方案无效，按以下顺序排查：

• 检查gitlab-runner的网卡与HTTP服务绑定IP：Packer默认会自动选择第一块网卡的IP作为{{.HTTPIP}}返回，如果Gitlab服务器有多网卡，runner运行时可能选择了虚拟机无法访问的内网/环回IP，导致虚拟机无法下载ks.cfg卡住。可以在Packer配置中手动指定http_interface或http_ip参数，绑定到虚拟机可以访问的网卡IP：

  http_ip = "你的Gitlab服务器可被虚拟机访问的IP"
  

• 检查gitlab-runner的执行环境权限：确认gitlab-runner运行用户对vCenter的权限和你手动执行时使用的用户权限完全一致，排除API访问异常触发的提前销毁
• 检查runner配置的信号转发：shell执行器的gitlab-runner默认会转发SIGINT/SIGTERM信号给子进程，确认runner的config.toml中没有配置过短的output_timeout（默认1小时，若小于你的安装总时长会直接杀进程）
• 运行时添加debug参数输出详细日志：在Packer命令前加PACKER_LOG=1，并添加-debug参数，收集runner执行的完整日志，定位具体触发退出的错误节点

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