1. 项目概述与核心价值最近在帮几个初创团队做内部代码管理平台的迁移和升级发现一个挺普遍的现象很多团队还在用着老旧的SVN或者直接把代码仓库托管在第三方公有云上。不是说这些方案不好但对于有代码安全、流程规范化和持续集成需求的团队来说自建一个功能完备的GitLab-EE企业版服务往往是一个更具掌控力和长期价值的决策。尤其是在CentOS 7这个依然广泛存在于企业生产环境中的“老兵”系统上完成一次稳定、可靠的GitLab-EE部署可以说是每个运维或DevOps工程师的必修课。你可能会问现在云服务这么方便为什么还要自己折腾原因其实很直接成本、安全和定制化。对于代码资产很多企业倾向于将其放在自己的防火墙后面GitLab-EE提供的代码质量分析、安全扫描、高级CI/CD流水线、容器镜像仓库等企业级功能如果按用户数在SaaS版上购买长期来看是一笔不小的开销。而CentOS 7尽管其官方支持周期已近尾声但其极高的稳定性和海量的历史部署案例使得它依然是许多企业服务器环境的首选学会在其上部署关键服务是一项非常实用的技能。这次我就结合最近一次在物理服务器上部署GitLab-EE 16.x的经验从头到尾捋一遍流程。目标很明确不只是把服务跑起来而是要搭建一个性能达标、配置合理、数据安全、便于维护的生产级环境。过程中会涉及系统优化、存储规划、HTTPS配置、备份策略等实战细节这些都是官方文档可能一笔带过但实际部署时却至关重要的部分。2. 前期准备与环境规划在真正执行安装命令之前充分的准备工作能避免后续80%的麻烦。这一阶段的核心是“谋定而后动”根据你的团队规模和未来增长来规划资源。2.1 硬件与系统资源评估GitLab对资源的需求比较“实在”尤其是内存。一个轻量级的个人使用和支撑上百人团队协作的配置是天壤之别。以下是一个基于用户规模的参考配置表请注意这是最低生产环境要求预留余量是保证体验的关键。团队规模 (活跃用户)推荐CPU核心推荐内存推荐存储说明 100人4核8 GB100 GB基础运行能应对日常代码托管和简单CI。内存低于4GB极易导致服务不稳定。100 - 500人8核16 GB250 GB需要处理更多的并行CI/CD任务和仓库操作建议使用SSD存储提升响应速度。 500人16核32 GB500 GB需要考虑高可用、独立组件拆分如Gitaly、Sidekiq和对象存储。注意这里的“活跃用户”指的是频繁进行Git操作、创建Merge Request、触发流水线的用户。如果团队使用强度很高即使人数少也应向上靠拢配置。内存不足是GitLab运行缓慢、Sidekiq任务堆积最常见的元凶。对于CentOS 7系统本身请确保系统全新或纯净尽量避免在已有复杂业务的服务器上混装减少依赖冲突。网络畅通服务器需要访问互联网以下载GitLab包及依赖如果处于内网需提前配置好代理或内部镜像源。防火墙Firewalld/SELinux提前规划好端口。GitLab默认使用HTTP(80)、HTTPS(443)和SSH(22)。如果使用其他SSH端口需额外配置。2.2 存储规划与分区建议GitLab的数据主要分为以下几类对I/O的要求不同仓库数据/var/opt/gitlab/git-data存放所有Git仓库的实际文件。这是读多写少但随机I/O要求高的类型对延迟敏感。强烈建议放在SSD上能极大提升git clone、git fetch等操作的速度。应用数据/var/opt/gitlab包含PostgreSQL数据库、Redis、上传的文件如Issue附件、容器镜像等。同样受益于SSD。日志数据/var/log/gitlab运行日志和审计日志。可以放在机械硬盘上但需确保有足够的空间并建立日志轮转策略。实操建议即使只有一块硬盘也最好通过LVM进行分区为/var目录单独分配一个较大的分区方便未来扩展。例如# 假设新磁盘为 /dev/sdb pvcreate /dev/sdb vgcreate vg_gitlab /dev/sdb lvcreate -L 200G -n lv_var vg_gitlab mkfs.xfs /dev/vg_gitlab/lv_var # 将 /var 目录迁移至新逻辑卷操作前务必备份原数据 mkdir /mnt/newvar mount /dev/vg_gitlab/lv_var /mnt/newvar cp -ax /var/* /mnt/newvar/ umount /mnt/newvar # 修改 /etc/fstab 加入挂载项 echo /dev/vg_gitlab/lv_var /var xfs defaults 0 0 /etc/fstab mount -a这个操作有风险适用于新装系统。如果/var已有数据需在系统维护窗口谨慎操作。2.3 依赖软件检查与系统优化CentOS 7默认的软件源可能版本较旧。我们需要确保一些基础工具的可用性。# 更新系统并安装常用工具 sudo yum update -y sudo yum install -y curl policycoreutils-python openssh-server wget vim # 启用并启动SSH服务通常已启用 sudo systemctl enable sshd sudo systemctl start sshd一个关键优化关闭Swap交换分区对于像GitLab这样内存消耗大的服务频繁使用Swap会导致性能急剧下降。如果物理内存充足建议关闭Swap。# 临时关闭 sudo swapoff -a # 永久关闭注释掉 /etc/fstab 中所有包含 swap 的行 sudo sed -i /swap/s/^/#/ /etc/fstab注意关闭Swap的前提是物理内存足够如大于推荐配置的1.5倍。如果内存紧张保留Swap可以防止进程因OOM内存溢出被系统杀死但需接受性能损失。这是一个权衡。3. GitLab-EE 安装与核心配置详解准备工作就绪后我们就可以开始正式的安装流程了。官方提供了多种安装方式这里我们选择最通用、最易于维护的Omnibus包安装方式。它将所有依赖Ruby, PostgreSQL, Redis, Nginx等打包在一起管理起来非常方便。3.1 配置仓库并安装首先我们需要将GitLab官方的YUM仓库添加到系统中。# 下载并执行仓库配置脚本 curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash这个脚本会自动检测系统版本并创建相应的.repo文件在/etc/yum.repos.d/目录下。接下来是安装。这里有一个非常重要的技巧通过设置环境变量来自动配置初始访问地址。这能避免安装后需要手动修改配置文件的麻烦。# 将 EXTERNAL_URL 替换为你打算访问GitLab的地址。 # 如果还没配置域名可以先使用服务器IP后续再改。 sudo EXTERNAL_URLhttp://your-server-ip-or-domain yum install -y gitlab-ee执行这个命令后yum会自动下载并安装GitLab-EE及其所有依赖。安装过程可能会持续几分钟取决于网络速度。安装后发生了什么Omnibus安装包实际上做了以下几件事在/opt/gitlab下安装了所有软件组件。在/var/opt/gitlab下创建了应用数据目录。在/etc/gitlab下生成了主配置文件gitlab.rb。创建了gitlab-ctl这个强大的管理工具。已经启动了所有相关服务PostgreSQL, Redis, Sidekiq, GitLab Workhorse等。3.2 初始登录与安全加固安装完成后打开浏览器访问你设置的EXTERNAL_URL。首次访问会强制你设置root用户的密码。请务必设置一个极其强壮的密码这是你系统的最高权限。登录后我强烈建议你立即完成以下几项安全操作创建个人账户不要使用root进行日常操作。在Admin Area-Users中创建一个新用户并赋予其管理员权限可选。配置双因素认证(2FA)在用户设置中为root和你自己的账户启用2FA。这是防止密码泄露后未授权访问的最有效手段之一。限制注册初期建议关闭公开注册。在Admin Area-Settings-General-Sign-up restrictions中取消勾选Sign-up enabled。3.3 核心配置文件gitlab.rb深度解析/etc/gitlab/gitlab.rb是GitLab Omnibus安装的神经中枢。所有配置都通过修改这个文件然后重新配置应用来实现。它使用Ruby语法但配置方式主要是取消注释和修改变量。第一次配置的黄金法则先备份再修改。sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak.$(date %Y%m%d)让我们看几个最关键的配置项3.3.1 配置外部访问URL这是最重要的设置影响所有生成的链接如仓库克隆地址、邮件通知链接。external_url https://gitlab.yourcompany.com # 使用HTTPS如果你安装时用的HTTP现在想改为HTTPS域名就在这里修改。3.3.2 配置邮箱服务器GitLab发送通知如重置密码、合并请求依赖邮件服务。不配置的话很多功能会静默失败。gitlab_rails[smtp_enable] true gitlab_rails[smtp_address] smtp.your-email-provider.com gitlab_rails[smtp_port] 587 gitlab_rails[smtp_user_name] gitlabyourcompany.com gitlab_rails[smtp_password] your-strong-password gitlab_rails[smtp_domain] yourcompany.com gitlab_rails[smtp_authentication] login gitlab_rails[smtp_enable_starttls_auto] true gitlab_rails[smtp_tls] false gitlab_rails[gitlab_email_from] gitlabyourcompany.com gitlab_rails[gitlab_email_reply_to] noreplyyourcompany.com配置完成后可以通过控制台测试sudo gitlab-rails console # 在控制台内执行 Notify.test_email(your-emailexample.com, Test Subject, Test Body).deliver_now3.3.3 性能调优相关配置工作进程数与并发数根据CPU核心数调整可以提升Web请求和Sidekiq任务处理能力。puma[worker_processes] 4 # 通常设置为CPU核心数建议至少2 sidekiq[max_concurrency] 20 # Sidekiq并发线程数可根据内存调整数据库连接池postgresql[max_connections] 200 # 默认100对于中型团队可以增加 gitlab_rails[db_pool] 20 # 应与puma的worker_processes * 5 相当3.3.4 存储路径配置如果你想将仓库数据存放在单独的、空间更大的磁盘上可以修改git_data_dirs({ default { path /mnt/gitlab-data/git-data # 自定义路径 } })修改完配置后必须执行重配置命令使更改生效sudo gitlab-ctl reconfigure这个命令会根据gitlab.rb生成所有组件的实际配置文件并重启相关服务。过程可能需要几分钟。4. 进阶部署HTTPS、备份与日常维护一个面向生产的环境安全性和可靠性是生命线。接下来我们解决这两个核心问题。4.1 启用HTTPS加密访问在当今环境下使用HTTPS不再是可选项而是必选项。我们有多种方式这里介绍最通用的使用Let‘s Encrypt免费证书自动配置。Omnibus GitLab内置了对此的支持非常方便。确保你的external_url是https://开头然后找到并修改gitlab.rb中的以下部分letsencrypt[enable] true letsencrypt[contact_emails] [adminyourcompany.com] # 用于接收证书到期提醒 letsencrypt[auto_renew] true letsencrypt[auto_renew_hour] 0 letsencrypt[auto_renew_minute] 30 letsencrypt[auto_renew_day_of_month] */7 # 确保nginx配置也启用SSL nginx[redirect_http_to_https] true nginx[ssl_certificate] /etc/gitlab/ssl/gitlab.yourcompany.com.crt nginx[ssl_certificate_key] /etc/gitlab/ssl/gitlab.yourcompany.com.key执行sudo gitlab-ctl reconfigure。在重配置过程中GitLab会尝试通过ACME协议向Let‘s Encrypt申请证书。前提是你的域名gitlab.yourcompany.com的DNS记录必须已经指向这台服务器的公网IP。服务器的80或443端口必须能从公网访问Let‘s Encrypt验证需要。如果自动申请失败你可以手动将已有的证书文件.crt和.key放到/etc/gitlab/ssl/目录下并确保文件名与域名匹配然后取消letsencrypt[enable]的注释并设为false再执行reconfigure。4.2 实施可靠的备份策略“没有备份的运维就是在裸奔。” GitLab的备份非常简单但恢复的细节很重要。4.2.1 创建手动备份sudo gitlab-backup create备份文件会默认存储在/var/opt/gitlab/backups/目录下文件名类似1698765432_2023_10_31_16.5.0_gitlab_backup.tar。这个时间戳很重要恢复时需要用到。4.2.2 关键配置文件的备份备份命令不包含gitlab.rb和gitlab-secrets.json等关键配置文件。你必须手动备份它们sudo cp /etc/gitlab/gitlab.rb /path/to/your/backup/ sudo cp /etc/gitlab/gitlab-secrets.json /path/to/your/backup/gitlab-secrets.json文件包含数据库加密密钥、2FA秘密等丢失它将导致无法恢复备份4.2.3 配置自动备份通过Cron Job实现每日凌晨自动备份并保留最近7天的备份。sudo crontab -e # 添加以下行表示每天凌晨2点执行备份 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON1为了自动清理旧备份可以创建一个脚本#!/bin/bash # 删除超过7天的备份文件 find /var/opt/gitlab/backups -name *.tar -mtime 7 -delete然后将此脚本也加入cron定时任务。4.2.4 备份恢复演练非常重要定期演练恢复流程至关重要。务必在测试环境进行确保测试环境的GitLab版本与备份文件版本完全一致。将备份文件xxx_gitlab_backup.tar和两个配置文件拷贝到测试机。停止相关服务sudo gitlab-ctl stop puma sidekiq恢复备份sudo gitlab-backup restore BACKUP1698765432_2023_10_31_16.5.0恢复配置文件sudo cp /path/to/backup/gitlab.rb /etc/gitlab/ sudo cp /path/to/backup/gitlab-secrets.json /etc/gitlab/重配置并重启sudo gitlab-ctl reconfigure sudo gitlab-ctl restart检查服务状态和数据完整性sudo gitlab-rake gitlab:check SANITIZEtrue4.3 日常维护与监控命令GitLab提供了强大的命令行管理工具gitlab-ctl。查看所有服务状态sudo gitlab-ctl status查看实时日志sudo gitlab-ctl tail# 查看所有组件日志sudo gitlab-ctl tail nginx# 仅查看Nginx日志sudo gitlab-ctl tail postgresql# 仅查看数据库日志重启单个组件sudo gitlab-ctl restart sidekiq升级GitLab版本备份sudo gitlab-backup create查看可升级版本sudo yum --showduplicates list gitlab-ee安装特定版本sudo yum install gitlab-ee-version升级配置sudo gitlab-ctl reconfigure重启sudo gitlab-ctl restart升级前务必阅读官方升级指南特别是跨大版本的升级。5. 常见问题排查与性能优化实录即使按照最佳实践部署在实际运行中也可能遇到各种问题。这里记录几个我踩过的坑和解决方案。5.1 服务启动失败或访问502这是最常见的问题之一。检查端口占用sudo netstat -tlnp | grep :80或grep :8080。GitLab的Unicorn/Puma默认可能使用8080端口如果被其他程序占用会导致启动失败。修改gitlab.rb中的puma[port]。检查内存运行free -h。如果可用内存极少Swap被大量使用GitLab组件特别是Sidekiq可能会崩溃。这是导致502错误的常见原因。临时解决是重启服务sudo gitlab-ctl restart根本解决是增加物理内存或优化配置减少worker数量。查看详细日志sudo gitlab-ctl tail puma或查看/var/log/gitlab/puma/current通常会有明确的错误信息。5.2 Git操作Clone/Push速度慢网络问题在服务器上尝试git clone自己的一个仓库如果也慢则排除客户端网络问题。存储I/O瓶颈使用iostat -x 1查看磁盘利用率(%util)和响应时间(await)。如果%util持续接近100%说明磁盘是瓶颈。将仓库数据迁移至SSD是最有效的解决方案。Gitaly服务问题Gitaly是处理Git操作的核心服务。检查其日志sudo gitlab-ctl tail gitaly。有时重启Gitaly能解决临时性问题sudo gitlab-ctl restart gitaly。5.3 Sidekiq任务积压Sidekiq负责处理后台异步任务如发送邮件、处理CI流水线。如果任务队列越积越多表现为邮件发不出、流水线卡在“Pending”。监控面板访问Admin Area-Monitoring-Background Jobs查看队列长度和作业执行时间。增加并发在gitlab.rb中适当调高sidekiq[max_concurrency]的值如从10调到20然后reconfigure。注意这会增加内存消耗。检查依赖服务Sidekiq依赖Redis和PostgreSQL。确保它们运行正常没有性能瓶颈。可以使用sudo gitlab-ctl tail sidekiq查看是否有特定类型的作业持续失败。5.4 磁盘空间告急GitLab会占用大量磁盘空间尤其是仓库、容器镜像和日志。清理无用数据容器镜像仓库在Admin Area-Packages Registries-Container Registry中可以设置清理策略自动删除未使用的镜像层。流水线日志和产物设置CI/CD流水线的保留时间项目设置 - CI/CD - 通用流水线。上传文件清理项目中的临时上传附件。日志轮转Omnibus GitLab默认已配置日志轮转。你可以检查/etc/gitlab/gitlab.rb中的logging[logrotate]设置调整保留天数。使用对象存储对于企业版强烈建议将流水线缓存、产物、容器镜像甚至LFS对象迁移到S3兼容的对象存储如MinIO、AWS S3。这能极大减轻本地磁盘压力。配置在gitlab.rb的gitlab_rails[object_store]部分。5.5 性能优化速查表症状可能原因检查点与优化建议页面加载慢内存不足Puma进程频繁交换数据库慢查询。1.free -h看内存/Swap。2. 升级内存或减少puma[worker_processes]。3. 启用数据库慢查询日志在gitlab.rb中设置postgresql[log_min_duration_statement] 1000单位毫秒分析慢SQL。Git操作慢磁盘I/O瓶颈机械硬盘网络问题Gitaly故障。1.iostat -x 1看磁盘指标。2. 迁移git-data到SSD。3. 检查内网带宽和延迟。邮件发不出流水线卡住Sidekiq积压或故障Redis/PostgreSQL连接问题。1. 管理后台查看Background Jobs队列。2.sudo gitlab-ctl tail sidekiq看错误日志。3. 检查Redis内存使用sudo gitlab-redis-cli info memory。磁盘空间增长过快容器镜像、流水线产物、日志未清理。1. 配置容器镜像清理策略。2. 设置CI/CD产物过期时间。3. 规划并使用对象存储。高并发时502错误Puma工作进程处理不过来达到数据库连接上限。1. 适当增加puma[worker_processes]和puma[threads]。2. 增加postgresql[max_connections]和gitlab_rails[db_pool]。部署和维护一个生产级的GitLab-EE实例就像打理一个花园初期搭建需要精心规划后期则需要定期的照料和观察。整个过程最深的体会是文档和社区是你的最佳伙伴。遇到任何报错首先查看/var/log/gitlab下的日志然后带着错误信息去GitLab官方文档和Issues中搜索十有八九能找到答案。另外对于生产环境变更管理一定要谨慎任何对gitlab.rb的修改和版本升级最好先在测试环境完整走一遍流程。最后别忘了监控简单的服务器资源监控CPU、内存、磁盘、网络加上GitLab自身的健康检查sudo gitlab-rake gitlab:check能让你在用户抱怨之前就发现问题所在。