gitlab runner 是独立部署的 ci/cd 执行代理，需按项目需求选执行器（shell/docker等）、注册到 gitlab、配置服务与权限，并通过 .gitlab-ci.yml 中 tags 关联任务。
GitLab Runner 不是 GitLab 自带的服务，而是独立部署的执行代理。它负责拉取 CI/CD 任务、在指定环境中运行脚本，并将结果回传。配置的关键不在于“装上就行”，而在于匹配项目需求、环境特性和长期可维护性。
选对执行器：Shell 还是 Docker？
执行器类型决定 Runner 的行为模式和资源模型：
- Shell 执行器：命令直接在宿主机 shell（PowerShell 或 Bash）中运行。适合环境稳定、部署目标固定、资源有限的场景（如 Windows 服务器部署 Vue/React）。无需容器开销，调试直观，但要求 Node.js、Git 等工具已全局安装且版本一致。
-
Docker 执行器：每次作业启动一个新容器，镜像由
.gitlab-ci.yml指定。环境高度隔离、可复现，适合多项目共用 Runner 或需不同语言/版本的团队。但会增加镜像拉取、容器启停时间，对磁盘和网络有额外要求。 - 其他执行器（如 Kubernetes、SSH）适用于特定架构——K8s 适合云原生编排，SSH 适合无法安装 Runner 的远程主机，但运维复杂度明显上升。
注册 Runner：三步完成可信接入
Runner 必须注册到 GitLab 实例才能被识别和调度。核心动作包括：
- 获取注册令牌：进入 GitLab 项目 → Settings → CI/CD → Runners → Expand，复制 “Project registration token”（项目级）、或组/实例级对应令牌。
- 执行注册命令：
gitlab-runner register（Linux/macOS）或.\gitlab-runner.exe register（Windows PowerShell，需管理员权限）。 - 按提示填写关键信息：GitLab 实例 URL、注册令牌、Runner 描述（如 “prod-win-server-01”）、标签（如
vue,prod,shell，用于.gitlab-ci.yml中tags匹配）、执行器类型（输入shell或docker）。
注册成功后，Runner 在 GitLab UI 中显示为绿色 “online”，表示已就绪。
服务化与权限：保障长期稳定运行
注册只是起点，让 Runner 持续可靠工作需进一步配置：
- 安装为系统服务：Linux 上运行
sudo gitlab-runner install+sudo gitlab-runner start；Windows 上使用 PowerShell 管理服务：.\gitlab-runner.exe install后通过服务管理器或Start-Service gitlab-runner启动。 - 设置专用运行账户：避免以 root 或 Administrator 直接运行。Linux 创建
gitlab-runner用户并加入sudoers（仅限必要命令）；Windows 建议使用非管理员账户，通过组策略赋予 “登录为服务” 权限。 - 验证连接状态：定期运行
gitlab-runner verify检查 Runner 是否能正常响应调度；查看日志（gitlab-runner --debug run或系统日志）排查超时、权限拒绝等问题。
CI/CD 流水线联动：让 Runner 真正干活
Runner 本身不定义任务逻辑，它只执行 .gitlab-ci.yml 中声明的 job：
- 在项目根目录创建
.gitlab-ci.yml，明确stages（如 build、test、deploy）、variables（如构建路径、目标服务器地址）。 - 每个 job 需指定
tags，确保被对应 Runner 拾取。例如：tags: [vue, prod]只会由注册时打了这两个标签的 Runner 执行。 - 部署类 job 若涉及文件传输（如 rsync、scp），建议提前配置 SSH 免密登录；若用 PowerShell 脚本（Windows），注意路径分隔符（
\）、编码（UTF-8 with BOM）及执行策略（Set-ExecutionPolicy RemoteSigned -Scope CurrentUser）。
