环境准备阶段
首先明确几个概念：GitLab Runner是独立于GitLab主服务的客户端，专门用来执行CI/CD流水线任务。支持安装在Linux/Windows/macOS，这里以CentOS 7为例演示。
服务器建议最低配置1核2G，太小了跑流水线会卡顿
提前准备好GitLab实例的访问地址（如果是私有化部署）
确保服务器能正常访问GitLab服务端
安装过程详解
如果想用Docker运行，可以先安装Docker再拉取镜像：
注册Runner关键步骤
这里是最容易出错的环节！需要提前准备两个重要参数：
GitLab项目地址：在项目设置→CI/CD→Runners页面查看
注册令牌：同一个页面找到"Set up a specific Runner manually"区域的token
执行注册命令：
接着会进入交互式配置：
输入GitLab地址：（根据实际修改）
输入注册令牌：glrt-xxxxxx（实际令牌）
填写描述：比如"测试环境Runner"
添加标签：dev,test（按逗号分隔）
选择执行器：推荐使用docker或shell
配置文件详解
注册成功后配置存储在/etc/gitlab-runner/config.toml，重点字段说明：
建议根据实际需求调整并发数，CPU核心数×2是比较合理的值。
实战踩坑记录
权限问题：如果使用Shell执行器，建议创建专用用户
网络超时：检查防火墙是否放通GitLab服务端端口
缓存配置：建议挂载volume提升构建速度
资源限制：内存不足会导致任务失败，记得监控服务器资源
服务管理常用命令
调试技巧分享
遇到任务失败时，可以开启调试模式：
查看详细日志：
在GitLab界面可以通过重试按钮重新触发失败的任务，配合日志输出能快速定位问题。
最后提醒几个注意点：生产环境建议配置多个Runner做负载均衡，重要项目建议使用专用Runner，定期更新Runner版本获取新特性。配置完成后可以在项目流水线页面看到Runner状态从"未分配"变为"在线"，这时候提交代码就能自动触发构建了。
其实Runner配置没什么黑科技，主要就是细节把控。如果遇到注册失败，大概率是网络或令牌问题，多检查几遍基本都能解决。