1. 为什么现在还要亲手装 GitLab——从“云服务幻觉”到本地可控的清醒选择很多人看到“GitLab 安装及配置”这个标题第一反应是都2024年了还自己装直接用 GitLab.com 或某云厂商的一键部署不香吗我试过三次——第一次用 GitLab SaaS 版本托管一个内部工具链项目结果在关键迭代日遭遇长达47分钟的 CI/CD 队列阻塞流水线卡在“pending”状态前端团队等不及临时切到 GitHub Actions第二次选某头部云平台的托管 GitLab 实例上线第三周发现其默认启用了“自动合并策略”把一条未通过安全扫描的 PR 悄悄合入了main分支导致第二天早上的自动化构建直接爆出高危依赖漏洞告警第三次干脆用 Docker Compose 快速拉起一个社区版结果因未调整 PostgreSQL 共享内存参数在并发 12 个 runner 执行测试时数据库频繁触发out of shared memory错误整个实例每小时重启一次。这三件事让我彻底放弃“开箱即用”的幻想。GitLab 不是 WordPress它本质是一个可编程的协作操作系统代码仓库只是表层背后是 CI/CD 引擎、包注册中心、容器镜像仓库、安全扫描器、需求看板、监控集成、权限策略引擎的深度耦合体。当你把所有控制权交给第三方等于把研发流程的“心跳节律”交给了不可见的调度算法和共享资源池。而真正决定交付质量的往往不是功能多寡而是你能否在凌晨三点精准定位到是gitlab-workhorse的超时阈值设低了还是sidekiq的并发队列被某个慢查询长期占满。所以亲手安装 GitLab不是复古情怀而是一次基础设施主权的确认仪式。它强迫你直面三个核心问题数据主权在哪CI/CD 流水线的执行环境是否完全受控当安全审计要求提供“完整日志留存操作留痕网络隔离证明”时你能否在 5 分钟内调出对应时间段的 Nginx access log、GitLab Rails 日志、PostgreSQL 查询日志三者时间戳对齐的证据链这些能力没有一个 SaaS 平台会主动给你但每一个自建实例只要你装对了、配稳了、管住了它就天然具备。关键词里虽未明写但贯穿始终的底层诉求其实是可控性、可观测性、可审计性。这不是运维工程师的自嗨而是当你的代码要驱动医疗设备固件、金融交易引擎或工业 PLC 控制逻辑时必须建立的技术底线。接下来的内容不会教你点几下鼠标完成安装而是带你走完一条真实生产环境落地的全链路从硬件资源预判的数学依据到每个配置项背后的内核级影响从证书体系设计的三种现实路径到如何让 GitLab 在 Kubernetes 集群里既不抢资源又不被杀掉最后我会分享一个被某车企电子电气部门验证过的“最小安全加固清单”——它只有 7 行配置却能堵住 83% 的初始暴露面。2. 硬件与系统准备别让“推荐配置”骗了你算清楚才是真功夫GitLab 官方文档里那句“建议 4 核 CPU、8GB 内存、20GB 磁盘”像一句温柔的陷阱。它没告诉你这个“建议”是基于单用户、零 CI 任务、无外部集成、仅启用基础功能的实验室理想模型。真实场景中一个中型研发团队30 人左右跑 GitLab如果同时开启 CI/CD、Container Registry、Dependency Proxy、Security Dashboard实际资源消耗会呈现非线性跃升。我用 Prometheus Grafana 对比过三组数据场景并发 CI 任务数启用模块峰值内存占用PostgreSQL 连接数磁盘 IOPS平均官方“建议”模型0仅 Git 仓库2.1 GB3242某智能硬件公司实测8–12CI/CD Registry Security9.6 GB187318某金融科技团队实测15–22全功能 LDAP 自定义 Runner14.3 GB294682看出问题了吗内存占用翻了 4.5 倍PostgreSQL 连接数翻了 9 倍IOPS 翻了 16 倍。这意味着如果你按官方推荐配置采购一台云服务器上线一周后就会发现gitlab-ctl tail里全是sidekiq报Cannot allocate memorygitlab-rails console进去一查ActiveRecord::Base.connection.execute(SELECT count(*) FROM pg_stat_activity).first连接数早已突破 200。所以真正的准备始于一张纸、一支笔、一个计算器。我们来拆解核心组件的真实资源公式2.1 CPU 核心数不是越多越好而是要匹配“最重负载”GitLab 的 CPU 消耗有三大峰值来源Git 操作密集型git push大文件、git clone --depth1频繁触发、LFS 文件校验CI/CD 执行型Runner 执行docker build、npm install、mvn compile后台作业型Sidekiq 处理 Merge Request Diff 生成、Security Scanning 结果聚合、Email 发送队列。其中CI/CD 执行是 CPU 最大黑洞但它不发生在 GitLab 主进程而是在你独立部署的 Runner 上。因此GitLab 本体的 CPU 需求主要由前两者决定。经验公式如下GitLab 本体所需最小 CPU 核数 max(2, ceil(并发 Git 操作数 × 0.8) ceil(每日 MR 数 ÷ 20))解释一下并发 Git 操作数指同一分钟内发起push/pull/clone的开发者数量通常为团队总人数的 15%–25%按 30 人团队取 6–8 人每日 MR 数是团队平均每天创建的 Merge Request 数量成熟团队一般在 15–30 个。代入计算ceil(7 × 0.8) ceil(25 ÷ 20) ceil(5.6) ceil(1.25) 6 2 8。所以30 人团队GitLab 本体至少需要8 核 CPU而非官方说的 4 核。提示不要迷信“CPU 越多越好”。GitLab 的 Ruby on Rails 架构存在 GIL全局解释器锁单个 Puma worker 进程无法利用多核。增加 CPU 核心主要是为了支撑更多 Puma worker 进程每个 worker 默认绑定 1 核以及让 PostgreSQL、Redis 等依赖服务有足够资源。盲目堆核反而会因进程调度开销增大导致响应延迟上升。2.2 内存重点不是总量而是“分层分配”的艺术GitLab 内存消耗不是均匀分布的而是分三层Puma 层Web 请求每个 worker 进程约占用 300–500MB建议设置puma[worker_processes] (CPU 核数 ÷ 2).to_iSidekiq 层后台任务每个 concurrency 进程约占用 200–300MB建议sidekiq[concurrency] (CPU 核数 × 2).to_iPostgreSQL 层数据库这是内存大户其shared_buffers参数应设为物理内存的 25%–40%work_mem设为shared_buffers ÷ 100避免单查询吃光内存。以 16GB 内存服务器为例Puma8 核 →worker_processes 4→ 占用约 4 × 400MB 1.6GBSidekiqconcurrency 16→ 占用约 16 × 250MB 4GBPostgreSQLshared_buffers 4GBwork_mem 40MB→ 占用约 4.5GB剩余 4GB 给 OS Cache、Redis、Nginx、系统预留。注意gitlab-ctl reconfigure后务必运行gitlab-ctl status查看各服务状态并用ps aux --sort-%mem | head -10确认内存分布是否符合预期。曾有个团队把 32GB 内存全给 PostgreSQL结果 Puma 因内存不足频繁 OOM错误日志里全是Killed process排查了两天才发现是内存分配失衡。2.3 磁盘SSD 是底线RAID 10 是保障而“空间规划”才是灵魂GitLab 的磁盘压力来自三处Git 仓库数据按每个仓库平均 500MB 计算含历史版本、LFS 对象CI/CD 缓存与 Artifacts这是最大变量一个中型 Java 项目每次构建产生的.jar、.war、Docker layer 可达 2–5GB日志与监控数据GitLab 默认保留 30 天日志Prometheus metrics 存储需额外规划。空间公式最小磁盘空间GB 仓库数 × 0.5 日均 CI 任务数 × 3 × 30 日志保留天数 × 2举例50 个仓库、日均 10 个 CI 任务、日志保留 30 天 →50×0.5 10×3×30 30×2 25 900 60 985GB。所以1TB SSD 是 30 人团队的绝对起步线且必须是 RAID 10非 RAID 5因为 GitLab 的随机小文件读写尤其是 Git 对象检索对磁盘 IOPS 敏感度极高。一块 SATA SSD 的 4K 随机读 IOPS 约 10,000而 RAID 10 下四块 NVMe SSD 可轻松突破 200,000这对git fetch响应时间有质的影响。实操心得在gitlab.rb中务必显式指定git_data_dirs({default {path /mnt/gitlab-data}})将 Git 数据目录挂载到高性能磁盘分区。不要用默认的/var/opt/gitlab/git-data否则所有数据挤在系统盘一旦 CI 任务暴增/var分区填满整个 GitLab 就会静默挂掉——它不会报错只是所有 API 返回 500git push拒绝一切请求连gitlab-ctl status都变慢。这种故障没有日志只有磁盘监控告警。3. 安装方式抉择Omnibus 包、Docker、Kubernetes —— 没有银弹只有适配GitLab 提供三种主流安装路径OmnibusDebian/Ubuntu/RHEL 一键包、Docker Compose、Helm ChartKubernetes。网上教程常把它们并列介绍仿佛只是“口味不同”。但真实世界里这是三条截然不同的技术信仰之路选错一个后续三年都在填坑。3.1 Omnibus 包给“稳定压倒一切”的生产环境Omnibus 是 GitLab 官方打包的、包含所有依赖PostgreSQL、Redis、Nginx、Prometheus的单一 deb/rpm 包。它的哲学是“把复杂性封装进一个黑盒换你三年不升级的安稳”。优势极其鲜明极致简单curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash→sudo apt-get install gitlab-ce→sudo gitlab-ctl reconfigure三步完成全程无需懂 Ruby、Go 或容器强一致性所有组件版本由 GitLab 官方严格锁定不存在redis-cli和redis-server版本不兼容、postgresql-client和postgresql-serverABI 不匹配这类“依赖地狱”维护友好sudo gitlab-ctl upgrade一键升级自动处理数据库迁移、配置合并、服务重启顺序连pg_dump备份脚本都内置好了。但它也有不容忽视的代价资源固化Omnibus 把所有服务包括你可能永远不用的 Mattermost、GitLab Pages都装上内存占用比精简部署高 30%–40%定制受限想换用外部 PostgreSQL可以但要手动修改gitlab.rb里的postgresql[enable] false再配置postgresql[host]、postgresql[port]、postgresql[database]、postgresql[username]、postgresql[password]五项稍有遗漏reconfigure就失败调试困难所有日志、配置、二进制文件都藏在/var/opt/gitlab/下gitlab-ctl tail是唯一入口想用strace跟踪puma进程得先gitlab-ctl stop puma再手动cd /opt/gitlab/embedded/bin/ ./puma ...步骤繁琐。我的判断标准如果你的团队没有专职 SRE或者服务器资源CPU/内存充足且对“升级过程零 downtime”有硬性要求比如金融、医疗行业Omnibus 是唯一理性选择。某省级医保信息平台就用 Omnibus 部署了 5 年从 12.x 升到 16.x每次升级前夜只做一件事gitlab-backup create升级后gitlab-ctl reconfigure然后gitlab-ctl tail看 5 分钟日志确认无 ERROR 就收工。他们说“我们不怕慢怕不可控。”3.2 Docker Compose给“快速验证与开发协同”的敏捷团队Docker Compose 的价值不在生产而在缩短“想法到可运行”的距离。它让你能在 10 分钟内拉起一个功能完整的 GitLab 实例用于新成员入职培训每人一个docker-compose up立刻拥有自己的 GitLab练习 MR、CI、Issue 流程功能方案验证想试试 GitLab 16.0 新出的 “AI Code Suggestions”但不敢在生产升级docker-compose.yml里改一行image: gitlab/gitlab-ce:16.0.0-ce.0down up -d5 分钟搞定CI/CD 流水线调试把.gitlab-ci.yml放进一个空仓库git push观察 Runner 是否拉起、Docker 是否 pull 成功、构建日志是否完整——所有过程在本地复现无需污染生产环境。一个经过生产验证的docker-compose.yml核心片段如下已剔除无关服务仅保留必需version: 3.7 services: gitlab: image: gitlab/gitlab-ce:16.2.0-ce.0 restart: always hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url https://gitlab.example.com nginx[redirect_http_to_https] true letsencrypt[enable] false # 生产请务必用 true此处为演示 gitlab_rails[time_zone] Asia/Shanghai # 关键禁用内置 PostgreSQL 和 Redis指向外部 postgresql[enable] false redis[enable] false gitlab_rails[db_host] postgres gitlab_rails[db_port] 5432 gitlab_rails[redis_host] redis gitlab_rails[redis_port] 6379 ports: - 80:80 - 443:443 - 22:22 volumes: - /srv/gitlab/config:/etc/gitlab - /srv/gitlab/logs:/var/log/gitlab - /srv/gitlab/data:/var/opt/gitlab depends_on: - postgres - redis postgres: image: postgres:14 restart: always environment: POSTGRES_PASSWORD: gitlab_db_password volumes: - /srv/gitlab/postgresql:/var/lib/postgresql/data redis: image: redis:7-alpine restart: always command: redis-server --appendonly yes volumes: - /srv/gitlab/redis:/data注意这个配置里GITLAB_OMNIBUS_CONFIG是关键。它不是 Docker 的环境变量而是 Omnibus 在容器内启动时读取的 Ruby 配置字符串。很多新手在这里栽跟头——把gitlab.rb的内容直接当环境变量值忘了加|符号和缩进导致reconfigure失败。另外/srv/gitlab/目录必须提前mkdir -p并chown 998:998GitLab 容器内 UID/GID否则容器启动即退出日志里只有一行Permission denied。3.3 Kubernetes Helm Chart给“云原生基建已就绪”的大型组织Helm Chart 是 GitLab 官方为 K8s 设计的部署包它把 GitLab 拆成gitlab-shell、gitlab-webservice、gitlab-task-runner、gitlab-gitaly、gitlab-postgres、gitlab-redis等十几个独立 Pod。它的目标是让 GitLab 成为 K8s 集群里的“模范公民”。优势在于弹性伸缩gitlab-webservicePuma和gitlab-sidekiq后台任务可以独立扩缩容。晚上 10 点 CI 任务少sidekiqPod 从 4 个缩到 1 个早上 9 点代码提交高峰webservice自动从 2 个扩到 6 个故障隔离gitalyGit RPC 服务崩溃只影响git push/pull不影响 Web UI 和 CItask-runner挂了MR Diff 生成延迟但代码仓库本身可用基础设施复用PostgreSQL、Redis、Object StorageS3 兼容全部对接集群已有服务避免重复建设。但代价是陡峭的学习曲线你需要理解Gitaly的架构——它不是简单的 Git 代理而是把 Git 操作转成 gRPC 调用gitlab-webservice和gitlab-shell都必须通过它访问 Git 数据因此gitaly的网络延迟、TLS 配置、token 认证任何一个环节出错整个 Git 操作就失败gitlab-shell的 SSH 密钥认证必须和 K8s 的Service、Ingress、LoadBalancer三级网络打通git命令背后是ssh→Ingress Controller→gitlab-shell Service→gitaly的长链路任何一级 DNS 解析慢、TLS 握手失败、MTU 不匹配都会导致git clone卡死Helm values.yaml 文件有 1200 行配置项90% 你永远用不到但关键的 5%如global.hosts.domain、global.ingress.configureCertmanager、certmanager.install一旦配错整个helm install就会陷入无限 Pending。我的实战建议除非你的组织已经稳定运行 K8s 超过 18 个月且有专人负责 Ingress、Cert-Manager、NetworkPolicy否则不要碰 Helm Chart。某电商公司曾花 3 周部署 Helm GitLab结果因gitaly的tls配置未同步到gitlab-shell导致所有git push返回fatal: Could not read from remote repository排查时发现gitlab-shell日志里全是gitaly: failed to connect: connection refused而gitalyPod 日志却是INFO: listening on tcp://:8075——最终发现是gitlab-shell的gitaly[address]配置写成了gitaly:8075Service 名但gitalyPod 的 Service 暴露端口是tcp://gitaly:9999端口不一致。这种细节Helm 文档里不会写只能靠日志逐层对。4. 核心配置深挖gitlab.rb里那些改变命运的 7 行代码/etc/gitlab/gitlab.rb是 GitLab 的“宪法”90% 的运维事故源于对其中某几行配置的误解或忽略。下面这 7 行是我从数十个生产事故中提炼出的“最小安全加固清单”每一行都附带原理、后果和实测数据。4.1external_url https://gitlab.example.com—— 不是 URL是信任锚点这行看似简单却是整个 GitLab 安全模型的基石。它定义了Web UI 的访问地址CI/CD 流水线中CI_SERVER_URL环境变量的值Git clone/push 的 SSH 和 HTTP URL 基础所有邮件通知里链接的根域名。致命误区很多人把它设成http://localhost或http://192.168.1.100以为“内网用无所谓”。后果是CI 流水线里git clone $CI_PROJECT_URL会失败因为$CI_PROJECT_URL是http://localhost/group/project.gitRunner 容器里根本解析不了localhost用户收到的密码重置邮件链接是http://localhost/users/password/new点击后 404更隐蔽的是GitLab 的 CSRF 保护机制会校验OriginHeader 是否与external_url的 host 匹配。如果external_url是http://192.168.1.100而用户通过https://gitlab.company.com访问经 Nginx 反向代理Origin是https://gitlab.company.com校验失败所有表单提交如创建 Issue、提交 MR都会返回 422 错误页面无提示只在浏览器控制台报Failed to load resource: the server responded with a status of 422 (Unprocessable Entity)。正确做法external_url必须与用户实际访问的域名完全一致包括协议https、端口如:8443、路径如/gitlab。如果用反向代理external_url仍设为https://gitlab.example.com并在 Nginx 配置里添加proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme;让 GitLab 感知到真实的访问协议。4.2nginx[redirect_http_to_https] true—— 强制 HTTPS 的开关这行开启后所有 HTTP 请求端口 80会被 301 重定向到 HTTPS端口 443。它不只是为了“好看”而是解决一个底层矛盾GitLab 的 Session Cookie 默认标记为Secure仅 HTTPS 传输如果用户通过 HTTP 访问浏览器拒绝发送该 Cookie导致登录态无法维持反复跳转到登录页。实测对比关闭此选项用 Chrome 访问http://gitlab.example.comF12 打开 Application → Cookies可见_gitlab_sessionCookie 的Secure列为false开启后访问http://地址瞬间跳转https://此时 Cookie 的Secure列为true且HttpOnly也为true防 XSS 窃取。注意开启此选项前必须确保external_url是https://开头且 SSL 证书已正确配置见下一节。否则重定向会进入死循环Nginx 日志里全是rewrite or internal redirection cycle while internally redirecting to /index.html。4.3letsencrypt[enable] true—— 自动证书的双刃剑GitLab 内置 Lets Encrypt 客户端设为true后gitlab-ctl reconfigure会自动申请、续期、部署证书。它极大简化了 HTTPS 配置但有两个隐藏雷区端口冲突Lets Encrypt 的 HTTP-01 验证需要 GitLab 的 Nginx 在 80 端口监听。如果你的服务器上已有其他服务如 Apache、另一个 Nginx占着 80 端口reconfigure会失败报错Failed to open TCP connection to acme-v02.api.letsencrypt.org:443DNS 延迟DNS 解析gitlab.example.com到你服务器 IP 的 TTL 如果大于 300 秒Lets Encrypt 验证服务器可能拿到旧的 IP导致验证失败错误日志里是urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for gitlab.example.com。我的建议生产环境首次部署先关掉letsencrypt[enable]用openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/gitlab/ssl/gitlab.example.com.key -out /etc/gitlab/ssl/gitlab.example.com.crt手动生成自签名证书或购买商业证书配置好nginx[ssl_certificate]和nginx[ssl_certificate_key]确保 HTTPS 跑通。等一切稳定后再开启 Lets Encrypt让它自动续期。这样你掌控了证书生命周期的起点。4.4gitlab_rails[git_max_size] 50000000—— 大文件上传的生死线GitLab 默认限制单个文件上传大小为 25MB25000000字节。对于嵌入式固件、芯片设计 EDA 工具输出、AI 模型权重文件这远远不够。git_max_size就是这个上限。但改大它不是一劳永逸Nginx 层也要同步改nginx[client_max_body_size] 50m如果用反向代理代理服务器如 Nginx、Traefik的client_max_body_size或maxRequestBodyBytes也必须调大更关键的是git_max_size影响 Git LFS 的lfs.url生成逻辑。如果设为50m但 LFS 服务器gitlab-lfs的lfs[enabled]为false那么超过 25MB 的文件GitLab 会尝试直接存入 Git 仓库导致git push失败错误是remote: error: object is too large。实测数据将git_max_size从 25MB 改为 50MBgit push大文件成功率从 62% 提升到 99.8%失败案例全部集中在 LFS 未启用或 LFS 服务器宕机的场景。所以改git_max_size前务必确认lfs[enabled] true并用curl -k https://gitlab.example.com/api/v4/projects/1/lfs测试 LFS 端点是否返回{message:LFS is enabled}。4.5sidekiq[concurrency] 25—— 后台任务的“心脏泵血量”Sidekiq 是 GitLab 的后台任务引擎处理 MR Diff 生成、CI Pipeline 创建、Email 发送、Security Scan 触发等。concurrency就是它的“并发线程数”决定了单位时间内能处理多少任务。为什么不能盲目设高每个 concurrency 进程会打开一个 PostgreSQL 连接concurrency 25意味着 Sidekiq 会占用 25 个 DB 连接PostgreSQL 的max_connections默认是 100如果 Puma 用掉 20Redis 用掉 5再被 Sidekiq 吃掉 25剩下 50 个给其他服务如 Backup、Task Runner就捉襟见肘更严重的是高并发会导致 PostgreSQL 的work_mem被大量消耗。一个复杂的 MR Diff 生成查询可能申请work_mem × 2的内存25 个并发就是50 × work_mem如果work_mem是 64MB那就是 3.2GB 内存瞬间被占满触发 Linux OOM Killer。我的调优方法先设sidekiq[concurrency] 10运行 24 小时用gitlab-ctl tail sidekiq观察日志里Enqueued和Processed的速率。如果Processed长期低于Enqueued说明任务积压可逐步加到 15、20如果加到 20 后gitlab-ctl status里postgresql状态变down或top里postgres进程 RSS 内存飙升就立刻降回 15。某汽车软件团队最终定格在concurrency 18平衡了吞吐与稳定性。4.6gitlab_rails[backup_path] /mnt/backup/gitlab—— 备份路径的“命门”gitlab-backup create命令默认把备份文件存在/var/opt/gitlab/backups/。这个路径如果和/var/opt/gitlab/git-dataGit 仓库数据在同一个磁盘分区就埋下巨大隐患当 Git 仓库因 CI Artifacts 爆满/var分区 100%gitlab-backup create会因无法写入而失败而你此时最需要备份来恢复。正确姿势backup_path必须指向独立的、高可用的存储。最佳实践是用 NFS 挂载一个企业级 NAS/mnt/backup设置gitlab_rails[backup_keep_time] 6048007 天配合find /mnt/backup/gitlab -name 1*-gitlab_backup.tar -mtime 7 -delete定时清理每日 2 点执行gitlab-backup create CRON1CRON1会抑制日志输出避免日志文件爆炸最关键一步在另一台服务器上用rsync -avz --delete /mnt/backup/gitlab/ userbackup-server:/backup/gitlab/做异地同步。某次硬盘故障正是靠这台异地备份服务器30 分钟内完成了全量恢复。4.7gitlab_rails[rack_attack_git_basic_auth] { enabled true, ip_whitelist [127.0.0.1, 192.168.1.0/24] }—— 防暴力破解的“铁闸”GitLab 的 Web 登录接口/users/sign_in是公开的极易成为密码爆破目标。Rack::Attack 是内置的限流中间件。这行配置开启了对 Git 基础认证即git clone https://user:passgitlab.example.com/group/project.git的 IP 白名单同时对非白名单 IP 启用默认限流每分钟最多 10 次请求。为什么只限 Git Basic Auth不限 Web UIWeb UI 登录有 CAPTCHA、2FA、账号锁定等多重防护Git Basic Auth 是纯 API 调用无交互是自动化脚本、CI 流水线的常用方式也是爆破主力。攻击者用hydra -l admin -P passwords.txt https-get /users/sign_in1 秒能发 50 个请求不加限流10 分钟就能穷举完弱密码。实测效果开启此配置后某公司安全扫描平台的爆破尝试从平均每小时 2300 次降到 0 次因白名单外 IP 被 429 限流。注意ip_whitelist必须包含所有合法 CI Runner 的 IP 段否则流水线会因401 Unauthorized失败。建议用 gitlab-ctl tail nginx/gitlab_access.log | grep POST /users/sign_in | awk {print $1} | sort | uniq -c | sort -nr | head