核心是三步：启动Runner容器、注册为有效Runner、修改config.toml设置concurrent参数；需挂载docker.sock和cache目录，配置Docker-in-Docker及output_limit等关键项以保障并发构建稳定运行。
在 Docker 中运行容器化的 GitLab Runner 并配置并发构建，核心是三步：启动 Runner 容器、注册为有效 Runner、修改 config.toml 调整并发参数。整个过程不依赖宿主机安装二进制，环境干净、可复用、易扩缩。
启动并注册容器化 Runner
使用官方镜像启动一个长期运行的 Runner 容器，并完成注册。推荐用 gitlab/gitlab-runner:alpine（轻量）或 latest（功能全）：
- 确保宿主机已安装 Docker，且
/var/run/docker.sock可被容器访问（用于 Docker-in-Docker 构建） - 创建挂载目录：
mkdir -p /opt/gitlab-runner/{config,cache} - 运行容器（示例）：
进入容器注册 Runner：
docker exec -it gitlab-runner gitlab-runner register \ --non-interactive \ --executor "docker" \ --docker-image "alpine:latest" \ --url "https://your-gitlab-domain.com/" \ --registration-token "YOUR_REGISTRATION_TOKEN" \ --description "docker-runner-prod" \ --tag-list "docker,linux" \ --run-untagged="true" \ --locked="false" \ --access-level="not_protected"注册成功后，Runner 会自动写入 /etc/gitlab-runner/config.toml（即宿主机 /opt/gitlab-runner/config/config.toml）。
修改 config.toml 设置并发数
并发控制由 config.toml 顶层的 concurrent 参数决定，它限制该 Runner 实例**最多同时执行多少个 job**（无论来自哪个项目或流水线）：
系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。
- 编辑宿主机上的配置文件：
nano /opt/gitlab-runner/config/config.toml - 在文件最上方（全局作用域）添加或修改：
concurrent = 6 - 保存后重启容器使配置生效：
docker restart gitlab-runner
注意：concurrent 是硬上限，不是建议值。设太高会导致资源争抢（如内存 OOM、CPU 过载），设太低则作业排队。参考值：
- 2 核 4GB 服务器 →
concurrent = 2~4 - 4 核 8GB 服务器 →
concurrent = 4~8 - 8 核 16GB+ 服务器 →
concurrent = 8~16
关键配置项补充（提升稳定性与构建能力）
仅改 concurrent 不够，还需确认以下几处，否则可能无法拉镜像、构建失败或日志截断：
-
Docker-in-Docker 支持：确保
[runners.docker]下有正确挂载：volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/usr/bin/docker:/usr/bin/docker"] -
日志缓冲优化（防“log exceeded limit”）：在
[runner]或全局段加：output_limit = 16384（单位 KB，即 16MB） -
检查间隔调优：减小轮询延迟，加快响应新 job：
check_interval = 3（默认 3 秒，最小支持 1） -
缓存持久化：确认
/cache已挂载到宿主机目录，避免每次构建都重下依赖
验证并发是否生效
配置生效后，可通过两个方式快速验证：
- 访问 GitLab 管理后台 → Admin Area → Runners，查看该 Runner 的 “Concurrent jobs” 显示值是否为你设置的数字
- 触发两个及以上带
tags匹配的 pipeline（如都含docker），观察它们是否同时出现在 “Running” 状态，而非一个 Pending 一个 Running
若仍排队，检查 Runner 是否被锁（locked = true）、是否设置了 run_untagged = false 却没打 tag、或 job 指定的 image 拉取超时。
