私有化部署gitlab

团队要把代码仓库搬到自己的服务器上，一般都会先想到 GitLab。但真动手时容易卡在几件事上：机器怎么配、域名和证书怎么接、备份到底测没测过、权限和密钥该收紧到什么程度。这篇按部署顺序把流程、安全项和验收清单串一遍，每个环节只讲判断标准和要做的动作，具体参数和数字以你们自己的压测与站内页面核对为准。

把代码仓库从托管平台搬到自己服务器上，多数团队第一反应就是上 GitLab。原因也简单：功能全、权限模型够细、CI 也能一起搭起来。但真动手时卡住人的往往不是安装本身，而是安装之前的几个决定，以及装完之后没人管的备份和权限。

这篇按部署顺序讲：先定规模、域名和备份归属，再理部署方式和网络入口，然后收权限和密钥，最后做备份演练和上线验收。每个环节只给判断标准和动作，具体配置数值和容量表现，去站内相关页面核对当时的数字，不要照抄别人的模板。

动手前先定三件事：规模、域名、备份归属

很多人上来就买机器、装软件，结果装到一半发现域名没定、备份没人管，返工的成本比前期规划高得多。规划阶段不用很细，但下面这四个问题必须在开装前有明确答案，答不上来就先别动手。

• 规模怎么估：统计现有仓库数量、单仓最大体积、每月新增提交量，再按团队人数留出并发余量，别按最低配置买；磁盘水位留足，代码仓涨起来比想象快
• 访问入口定死：内网域名还是公网域名，证书用正式签发还是自签，这一步决定反向代理怎么写，装完再改域名会让所有克隆地址失效
• 备份责任到人：多久备一次、备份放哪、谁有权恢复、多久演练一次；没有责任人的私有化部署等于没部署
• 合规边界先对齐：代码是否允许出内网、日志留存多久、离职账号怎么回收，先跟安全和 HR 过一遍再买机器

部署顺序与网络入口：把外部访问收成一条路

部署方式没有绝对优劣，关键看你们的运维习惯。集成包适合单机起步、不想管依赖的团队；容器方式适合要独立升级组件、跟现有运维体系对齐的团队。两种方式别混用，否则升级和排障时容易踩坑。

1. 装完先改域名和证书在导入任何真实仓库之前，把访问地址、证书、邮件配置全部调通，用浏览器访问确认无证书告警。
2. 网络只留一个入口外部请求统一走反向代理或网关再转到内部服务端口，其余端口在防火墙和云安全组里全部关掉；改完从外网实际扫一遍端口验证。
3. 量一条延迟基线上线前用站内 /tools/speed-test 测一轮接口响应，记下基线，后面用户抱怨慢的时候才有对照。

网络这块最容易犯的错是图省事把服务端口直接暴露出去。短时间没人发现，时间一长日志里全是扫描记录。反代加防火墙是最低要求，不是可选项。

安全加固清单：账号、密钥、权限三块

安全加固不需要一次做全，但账号、密钥、权限这三块必须在上线前完成基本收敛。它们决定的是最坏情况下损失有多大，而不是日常好不好用。

账号收敛

接入公司统一登录或强制二次验证，关掉自助注册，管理员账号单独一个，日常运维不用最高权限账号操作

令牌管理

仓库访问优先用短周期令牌或部署密钥，个人长期令牌定期轮换，密钥和口令不写进仓库或明文配置

权限最小化

按项目或群组授权，不给个人开全站可见，外部协作者单独拉群组，默认权限设为最低可读

审计留痕

开启登录和关键操作日志，异地登录、批量导出、权限变更要有人看，日志字段口径可到 /ai-dict/category/infra 对照

• 权限模型的专业术语和判定口径，可以到 /ai-dict/category/safety 核对，别凭印象配
• 离职和转岗人员账号要有回收流程，最好做成清单，每次变动逐项打勾
• 告警通道先接通再上线，不然出事时日志躺在服务器上没人看
• 定期检查一次公开项目和外部协作者列表，这两个地方最容易积压历史遗留

备份、恢复演练与上线验收

备份这件事的判断标准只有一个：你恢复过没有。没演练过的备份只能算心理安慰。恢复演练建议在独立的测试环境做，别拿生产环境当试验田。

• 备份分三层：仓库数据、数据库、配置文件各备一份，放到与服务器不同的位置
• 恢复必须在测试环境真做一次：确认仓库能克隆、历史提交完整、用户权限正常
• 上线前走验收清单：新建仓库并克隆、提交合并请求、触发一次流水线、邀请测试账号并回收、重启服务后数据还在
• 灰度放量：先让一两个小组用，稳定后再全量迁移，迁移期间旧仓库保留只读一段时间

迁移期间最大的风险不是新平台出问题，而是旧仓库被提前关停。保留一段只读时间是成本最低的保险，等团队用顺手了再下线。