GitLab Runner自动伸缩场景下ECR镜像拉取失败排查求助

遇到这种Runner执行上下文和SSH登录上下文不一致导致的问题确实挺闹心，我给你整理两个问题的具体排查步骤：

1. 查看GitLab Runner拉取ECR镜像所用的命令 #

有几个靠谱的途径可以拿到完整的拉取命令：

• 提升Runner日志级别，查看详细执行日志
  编辑GitLab Runner的配置文件（默认路径是/etc/gitlab-runner/config.toml），找到log_level字段，把它改成debug或者trace，然后重启Runner服务：

  sudo gitlab-runner restart
  

  之后触发一次构建，通过以下方式查看日志：

  sudo gitlab-runner logs
  # 或者查看Ubuntu系统日志
  tail -f /var/log/syslog | grep gitlab-runner
  

  在日志里搜索docker pull相关的内容，就能看到Runner执行的完整拉取命令，包括镜像地址、携带的参数等细节。
• 查看GitLab项目的构建日志
  直接在GitLab项目的流水线页面打开对应构建的日志，Runner执行的所有步骤都会在这里输出——不管是你在.gitlab-ci.yml里显式写的拉取命令，还是Runner自动拉取image字段指定镜像的操作，日志里都会展示完整的docker pull命令。

2. 查看GitLab Runner运行相关操作时的用户 #

可以通过以下几种方式确认执行用户：

• 在CI脚本里直接输出用户信息
  修改你的.gitlab-ci.yml，添加一个调试阶段：

  stages:
    - debug
  
  check_runner_user:
    stage: debug
    script:
      - whoami
      - id
      - echo "Current user home directory: $HOME"
  

  触发构建后，在这个步骤的日志里就能看到Runner执行脚本时的用户、用户ID以及家目录，这能帮你快速判断是否和SSH登录的用户环境一致。
• 确认GitLab Runner服务的运行用户
  在Runner所在的主机上，执行以下命令查看Runner服务的运行用户：

  ps aux | grep gitlab-runner
  

  默认情况下，GitLab Runner服务是用gitlab-runner用户运行的。另外还要检查这个用户是否在docker组里，避免Docker权限问题：

  groups gitlab-runner
  

• 检查docker-machine虚拟机内的执行用户
  对于自动伸缩的docker-machine环境，Runner在虚拟机内的执行用户通常也是gitlab-runner。你可以在CI脚本里添加命令直接查看，或者登录到虚拟机后检查/var/log/gitlab-runner目录下的日志，确认执行操作的用户。

额外提一句：既然SSH登录虚拟机时能正常拉取ECR镜像，大概率是Runner用户缺少ECR的认证凭证——比如~/.aws/credentials文件、AWS环境变量，或者没有正确执行aws ecr get-login-password这类认证命令，你可以结合上面的排查结果进一步定位。

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