如何使用Docker容器内的gitlab-runner在本地执行流水线阶段

完全可以通过临时启动官方GitLab Runner镜像的方式实现等效操作，不需要在宿主机额外安装gitlab-runner二进制文件。

你本地常驻的Docker版GitLab Runner能正常处理流水线任务，说明Docker环境本身是通的，本地执行单阶段的核心是让临时启动的runner容器拿到三个必要权限：能调用宿主机Docker创建任务容器、能读取本地项目代码和.gitlab-ci.yml配置、必要时能复用你现有runner的自定义配置。

直接用下面的命令就能等效执行gitlab-runner exec docker linting的效果：

docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v $(pwd):/workspace \
  -v /path/to/your/exist/gitlab-runner/config:/etc/gitlab-runner \
  -w /workspace \
  gitlab/gitlab-runner:latest \
  exec docker linting

参数说明：

• --rm -it：任务执行完自动删除临时容器，同时开启交互模式，可以实时看到任务日志，需要输入交互内容时也能正常操作
• 挂载/var/run/docker.sock是核心配置，缺了这步容器内的runner没法拉起执行具体job的Docker容器，和你常驻runner用Docker执行器的逻辑一致
• -v $(pwd):/workspace 会把你当前终端所在目录（必须是项目根目录，也就是放.gitlab-ci.yml的位置）挂载到容器内的工作路径，-w /workspace 把容器工作目录切到这里，runner就能直接读取本地的ci配置和代码，不需要把代码推送到GitLab远端
• 如果你之前部署的常驻runner有自定义配置（比如镜像加速、缓存规则、特权模式配置等），把你本地存config.toml的目录替换掉命令里的路径挂载进去就行；如果没有自定义配置，这行挂载可以直接删掉，用镜像默认配置就能满足大部分场景需求

几个注意点：

• 执行命令前一定要切到项目根目录，不然runner找不到.gitlab-ci.yml会直接报错
• 如果执行时遇到Docker权限报错，在docker run参数里加--user root即可
• 如果job需要访问本地其他文件、或者需要挂载缓存目录，按需追加-v参数挂载对应路径就行
• 这个操作启动的是临时独立容器，跑完自动清理，不会影响你已经在正常运行的常驻GitLab Runner服务

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