1. 为什么在内网环境自建代码托管平台把代码托管在第三方平台上对很多团队来说是最省事的选择但一旦涉及内部项目、交付源码、涉密模块或者公司网络本身就不允许访问外部服务自建一套代码托管平台就成了刚需。GitLab 是这类场景里被讨论最多的方案之一原因很直接它不只是个 Git 仓库还自带代码评审、议题跟踪、持续集成、制品仓库、权限体系一套装下来基本能把研发协作的主链路覆盖掉。这次要聊的是在 CentOS 7 上部署 GitLab 13.1.2 这个具体版本。为什么专门挑这个版本因为 13.x 系列在功能完整度和资源占用之间取得了一个相对平衡的位置13.1.2 属于该系列早期的一个稳定小版本很多老服务器、老内核环境跑起来比较稳。而 CentOS 7 虽然已经进入维护末期但大量企业内部服务器仍然停留在它上面短期内不会全部迁移所以“CentOS 7 GitLab 13.1.2”这个组合在实际运维里出现的频率依然很高。这篇文章适合三类人看一是第一次自建代码托管平台、想照着一步步做下来的运维或后端同学二是已经在用 GitLab 但想搞清楚安装过程中那些参数到底在干什么的人三是遇到安装失败、服务起不来、内存爆掉等问题想找排查思路的人。我会把整个安装过程拆开讲包括环境准备、依赖处理、安装包获取、配置调整、初始化、验证以及几个我实际踩过的坑。文中涉及的命令和配置都可以直接抄但每一步背后的原因我也会说清楚避免你只会照抄、出了问题无从下手。需要提前说明的是GitLab 对资源的要求不算低尤其是内存。很多人装完发现服务起不来八成是内存不够。这一点我会在环境准备部分重点展开。2. 部署前的整体思路与环境规划2.1 为什么选择 Omnibus 安装方式GitLab 的安装方式主要有几种源码编译、Docker 容器、Omnibus 包安装。源码编译基本可以排除依赖太多、维护成本极高除非有特殊定制需求否则没人愿意走这条路。Docker 方式很干净但对宿主机内核和容器运行时有一定要求而且在一些老旧的 CentOS 7 环境里Docker 本身的安装和存储驱动配置就可能先卡住一批人。Omnibus 是官方主推的方式它把 GitLab 需要的 Ruby、PostgreSQL、Redis、Nginx、Gitaly 等组件全部打包进一个 rpm 包里安装时一次性铺开配置文件集中在/etc/gitlab/gitlab.rb一个文件里。对运维来说这种“一个包 一个配置文件”的模式最省心升级和备份也有明确的路径。所以这次我们走 Omnibus 路线。选 Omnibus 的另一个理由是版本可控。GitLab 官方提供了各版本的 rpm 包下载地址13.1.2 这种具体小版本可以直接定位到对应的包不会因为仓库里最新版变了而装出预期之外的结果。这一点在需要版本一致性的团队环境里很重要。2.2 硬件与系统的最低要求在动手之前先把资源账算清楚。GitLab 官方给的最低配置是 2 核 CPU、4GB 内存但这是“能跑起来”的底线实际使用中 4GB 内存会非常紧张尤其是开启持续集成之后。我的建议是资源项最低可用推荐配置说明CPU2 核4 核及以上编译、CI 任务吃 CPU内存4GB8GB 及以上4GB 需配合 Swap 才能稳磁盘20GB50GB 以上仓库和制品会持续增长Swap2GB4GB内存不足时的缓冲这里有个关键点GitLab 内部跑着 PostgreSQL、Redis、Puma或 Unicorn、Sidekiq、Gitaly 等一堆进程4GB 内存下这些进程会互相抢资源系统频繁触发 OOM Killer表现就是“装完了但网页打不开”或者“用一会儿就 502”。所以如果物理内存只有 4GB务必配好 Swap并且把一些非核心组件关掉。系统方面CentOS 7 需要是较新的小版本7.6 以上比较稳妥内核版本不要太老。可以用uname -r看一下3.10 系列是 CentOS 7 的标配没问题。另外确认系统是 64 位uname -m输出x86_64即可。2.3 网络与域名规划GitLab 对外访问需要一个地址可以是域名也可以是 IP。如果只是内网测试直接用 IP 也能跑但配置里要写对否则会出现资源加载失败、克隆地址错误等问题。生产环境建议提前准备好域名并规划好是否启用 HTTPS。端口方面Omnibus 默认会用 80 和 443 给 Nginx8080 给 Puma/Unicorn 内部使用9090 给 Prometheus9187 给 PostgreSQL exporter 等等。如果这些端口和现有服务冲突需要在配置文件里改。我一般会在部署前用ss -tlnp把当前监听端口列一遍心里有数。3. 系统环境准备与依赖处理3.1 基础环境检查与更新第一步永远是确认系统状态。登录服务器后先看几个关键信息cat /etc/redhat-release uname -r uname -m free -h df -h/etc/redhat-release应该显示 CentOS Linux release 7.x。free -h看内存和 Swapdf -h看根分区剩余空间。如果根分区只剩几个 G先清理或者挂载新盘别急着装。接下来更新系统包。这一步不是必须但能避免一些已知的依赖问题yum update -y更新完建议重启一次确保内核和库都是最新的。重启后再次确认服务状态正常。3.2 安装必要依赖GitLab Omnibus 包本身依赖不多但有几个基础工具建议先装上后面排查问题会用到yum install -y curl policycoreutils-python openssh-server openssh-clientspolicycoreutils-python是给 SELinux 用的如果你的系统 SELinux 是 enforcing 状态后面配置防火墙和端口时需要它。openssh-server是 Git 通过 SSH 协议访问仓库的基础必须确保它在运行systemctl enable sshd systemctl start sshd3.3 防火墙与 SELinux 处理CentOS 7 默认开着 firewalld。GitLab 需要放行 HTTP、HTTPS 和 SSH 端口firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-servicessh firewall-cmd --reload如果你改了 GitLab 的访问端口比如把 80 改成 8888那就要用--add-port8888/tcp的方式放行。SELinux 这块GitLab 官方其实提供了对应的策略但配置起来比较绕。如果内网环境安全要求没那么严可以把它设为 permissive 模式避免各种权限拦截setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config注意把 SELinux 改成 permissive 是降低安全等级的操作生产环境如果合规要求必须 enforcing那就不要动它而是去配置对应的 SELinux 策略。这里只是给出内网测试环境的常见做法。3.4 配置 Swap内存不足时的救命稻草如果物理内存小于 8GB强烈建议加 Swap。创建 4GB Swap 文件的操作如下dd if/dev/zero of/swapfile bs1M count4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab执行完用free -h确认 Swap 已经生效。这里有个经验dd生成大文件比较慢可以用fallocate -l 4G /swapfile替代速度快很多但某些文件系统上 fallocate 生成的 Swap 文件可能有问题稳妥起见还是用 dd。另外可以调一下 Swap 的使用倾向。默认vm.swappiness是 30 或 60GitLab 这种内存吃紧的场景可以适当调高让系统更愿意用 Swapsysctl vm.swappiness30 echo vm.swappiness30 /etc/sysctl.conf4. GitLab 13.1.2 安装包获取与安装4.1 定位正确的安装包GitLab 的 rpm 包命名有固定格式比如gitlab-ce-13.1.2-ce.0.el7.x86_64.rpm。其中ce是社区版el7表示适配 CentOS 7x86_64是架构。下载时一定要认准这几个标识下错了装不上。获取方式有两种一是配置官方仓库用 yum 装二是直接下载 rpm 包手动安装。用仓库装的问题是仓库里通常只有最新版想装 13.1.2 这种特定版本需要指定版本号而且仓库地址的可用性受网络环境影响。手动下载 rpm 包更直接版本完全可控。下载完成后建议校验一下包的完整性rpm -K gitlab-ce-13.1.2-ce.0.el7.x86_64.rpm如果输出digests OK说明包没问题。4.2 执行安装安装命令本身很简单rpm -ivh gitlab-ce-13.1.2-ce.0.el7.x86_64.rpm或者用 yum 本地安装能自动处理依赖yum localinstall -y gitlab-ce-13.1.2-ce.0.el7.x86_64.rpm安装过程会输出一堆信息最后通常会提示你“GitLab 已安装请运行 gitlab-ctl reconfigure”。这时候先别急着重启先把配置文件改好。4.3 安装后的目录结构装完之后几个关键目录需要知道/etc/gitlab/主配置目录核心文件是gitlab.rb/var/opt/gitlab/数据目录仓库、数据库、日志都在这里/var/log/gitlab/各组件日志/opt/gitlab/程序本体和内置工具理解这个结构很重要后面备份、迁移、排查问题都围绕这几个目录展开。尤其是/var/opt/gitlab/它才是真正存数据的地方备份时不能只备份配置文件。5. 核心配置调整与初始化5.1 编辑 gitlab.rb 的关键参数打开/etc/gitlab/gitlab.rb这个文件很长但真正需要改的没几项。用grep定位比通读高效grep -n external_url /etc/gitlab/gitlab.rb第一项必改的是external_url。它决定了 GitLab 生成的所有链接、克隆地址的基础。默认是http://gitlab.example.com改成你实际的访问地址external_url http://192.168.1.100或者用域名external_url http://gitlab.internal.lan这里有个坑如果你后面想加端口比如http://192.168.1.100:8888那 Nginx 的监听端口会自动跟着变但防火墙也要同步放行 8888。改完地址后克隆仓库时显示的 URL 也会用这个地址所以一定要写对。第二项是时区。默认可能是 UTC日志时间会对不上改成东八区gitlab_rails[time_zone] Asia/Shanghai第三项是邮件配置。如果不需要邮件通知可以先不管如果需要配置 SMTPgitlab_rails[smtp_enable] true gitlab_rails[smtp_address] smtp.example.com gitlab_rails[smtp_port] 465 gitlab_rails[smtp_user_name] gitlabexample.com gitlab_rails[smtp_password] your_password gitlab_rails[smtp_domain] example.com gitlab_rails[smtp_tls] true gitlab_rails[gitlab_email_from] gitlabexample.com5.2 针对小内存环境的优化配置如果服务器内存只有 4GB 或 8GB下面这些配置能显著降低内存压力。在gitlab.rb里加上puma[worker_processes] 2 sidekiq[max_concurrency] 10 prometheus_monitoring[enable] falsepuma[worker_processes]控制 Web 服务的工作进程数默认是按 CPU 核数算的小机器上设成 2 就够。sidekiq是后台任务处理器并发数调低能省内存。prometheus_monitoring是监控组件会额外起好几个进程内网自用可以直接关掉能省下几百 MB 内存。提示13.x 版本默认用的是 Puma 还是 Unicorn取决于具体小版本。13.1.2 这个阶段 Puma 已经是默认选项但如果你在配置里看到unicorn相关参数说明该版本还在用 Unicorn对应调整unicorn[worker_processes]即可。5.3 执行 reconfigure 初始化配置改完后执行gitlab-ctl reconfigure这个命令是 Omnibus 的核心它会读取gitlab.rb生成各组件真正的配置文件然后启动服务。第一次执行时间比较长几分钟到十几分钟都有可能取决于机器性能。过程中会输出大量日志重点看有没有error或failed。reconfigure 完成后用下面的命令看整体状态gitlab-ctl status正常的话run:开头的行表示各服务在运行。如果有down:或fail:就要去看对应组件的日志。5.4 获取初始密码并登录GitLab 安装后会自动生成一个 root 用户的初始密码存在这个文件里cat /etc/gitlab/initial_root_password这个文件在 24 小时后会被自动删除所以拿到密码后尽快登录并修改。用浏览器打开external_url配置的地址用户名root密码就是文件里那串。登录后第一件事是改密码路径在用户设置里。如果这个文件不存在或者密码不对可以用下面的命令重置gitlab-rails console进入控制台后user User.where(id: 1).first user.password NewPassword123 user.password_confirmation NewPassword123 user.save! exit这个重置方法在忘记密码时非常管用比重新装一遍省事得多。6. 安装后的验证与常见问题排查6.1 服务状态与端口验证装完之后别只看网页能不能打开要从多个角度验证。先看服务gitlab-ctl status再看端口监听ss -tlnp | grep -E 80|443|808080 应该是 Nginx 在监听8080 是内部应用端口。如果 80 没起来检查 Nginx 日志tail -f /var/log/gitlab/nginx/error.log网页能打开但很慢或者时不时 502多半是内存问题去看系统日志有没有 OOM 记录dmesg | grep -i out of memory6.2 常见问题速查表下面这张表是我在实际部署中整理出来的高频问题遇到时可以直接对照排查现象可能原因排查方向解决方式网页 502内存不足应用进程被杀dmesg、free -h加内存或 Swap降低 worker 数reconfigure 卡住资源不足或端口冲突看输出日志、ss -tlnp释放端口增加资源克隆地址是 example.comexternal_url 没改检查gitlab.rb改对地址后重新 reconfigure邮件发不出SMTP 配置错误/var/log/gitlab/sidekiq/current核对 SMTP 参数和网络登录密码不对初始密码文件已删检查文件是否存在用 rails console 重置磁盘快速占满日志或制品堆积du -sh /var/opt/gitlab/*清理日志配置日志轮转6.3 日志排查的基本方法GitLab 组件多日志分散。掌握几个关键日志位置排查效率会高很多/var/log/gitlab/gitlab-rails/production.log应用主日志报错先看这里/var/log/gitlab/nginx/Web 服务器日志/var/log/gitlab/postgresql/数据库日志/var/log/gitlab/sidekiq/后台任务日志/var/log/gitlab/gitaly/Git 存储服务日志用gitlab-ctl tail可以实时跟踪所有日志也可以指定组件gitlab-ctl tail nginx gitlab-ctl tail gitlab-rails这个命令比手动 tail 多个文件方便得多是我排查问题时用得最频繁的工具。6.4 几个我踩过的坑第一个坑是磁盘空间。GitLab 的日志增长很快尤其是production.log如果不配置轮转几天就能吃掉几个 G。建议在gitlab.rb里配置日志保留logging[logrotate_frequency] daily logging[logrotate_rotate] 7第二个坑是备份恢复时的版本一致性。GitLab 的备份文件对版本敏感13.1.2 的备份恢复到 14.x 上大概率失败。所以升级前一定要先备份并且记录当前版本号。查看版本cat /opt/gitlab/embedded/service/gitlab-rails/VERSION第三个坑是external_url改了之后没重新 reconfigure。有些人改完配置直接重启服务结果链接还是旧的。Omnibus 的配置必须通过gitlab-ctl reconfigure生效restart只是重启进程不重新生成配置。第四个坑是时间不同步导致 Git 提交时间错乱。CentOS 7 默认可能没开时间同步装个 chrony 同步一下yum install -y chrony systemctl enable chronyd systemctl start chronyd chronyc sources时间同步这件事看起来小但在多人协作环境里提交时间错乱会让人很头疼。7. 日常维护与后续扩展思路7.1 备份与恢复的基本操作GitLab 自带备份命令执行一次全量备份gitlab-backup create备份文件默认放在/var/opt/gitlab/backups/文件名带时间戳和版本号。注意这个命令备份的是数据配置文件/etc/gitlab/gitlab.rb和/etc/gitlab/gitlab-secrets.json需要单独备份恢复时这两个文件必须一致否则会出现解密失败的问题。恢复的流程是先确保目标机器装好同版本 GitLab把配置文件和 secrets 文件放回原位再把备份文件放到备份目录执行gitlab-backup restore BACKUP备份文件名恢复完再 reconfigure 一次。整个过程建议在测试环境先演练一遍别直接在生产上试。7.2 版本升级的注意事项GitLab 的升级有路径要求不能跨大版本直接升。比如从 13.1.2 升到 14.x需要先升到 13.x 的最后一个版本再升 14.0再逐步往上。官方有升级路径文档升级前务必对照。升级前必做三件事备份、确认当前版本、确认目标版本。升级命令用 yum 或 rpm 装新包然后 reconfigure。升级过程中服务会中断要选在低峰期操作。7.3 后续可以扩展的方向一套 GitLab 装起来只是起点后面可以按需扩展。比如接入持续集成在项目里加.gitlab-ci.yml就能跑流水线配置 Runner 来执行构建任务开启容器镜像仓库来存制品接入 LDAP 做统一认证。这些功能都在 Omnibus 包里通过gitlab.rb开关控制不需要额外装东西。不过每开一个功能都会增加资源消耗所以扩展要循序渐进边加边观察资源使用情况。我个人的习惯是每加一个组件就跑一段时间确认稳定了再加下一个避免一次性开太多导致问题难以定位。最后分享一个实用小技巧把常用的 GitLab 维护命令做成别名能省不少事。比如在~/.bashrc里加alias gstatusgitlab-ctl status alias greconfiggitlab-ctl reconfigure alias gtailgitlab-ctl tail alias gbackupgitlab-backup create这样日常操作敲几个字母就行比记完整命令轻松。装 GitLab 这件事第一次做会觉得步骤多但把流程走通一遍之后后面再部署就是复制粘贴的事真正花时间的往往是排查那些意料之外的资源问题和配置冲突。