想在公司内部搭一套自己的代码托管平台多数人绕不开GitLab CE社区版。这篇东西写给第一次在CentOS 7上用Omnibus方式安装GitLab CE的人也顺带记录一下我装过几次之后沉淀下来的习惯性操作。GitLab CE并不是一个单进程程序它是一整套服务Nginx、PostgreSQL、Redis、Sidekiq、Gitaly、Puma等等装完一看内存占用普遍超过2GB所以很多人第一次装完发现机器卡到不能自理。提前把环境规划讲清楚后面能少走很多弯路。这篇博文不会只贴命令我会把每一步为什么这么做讲透包括防火墙、SELinux、swap、external_url这些最容易被忽视但一错就是半天的点。适合三类人准备在公司内网搭GitLab的运维和开发想把自己代码仓库从第三方托管迁回本地的人以及单纯想学一下Linux服务部署的初学者。整个过程跟着做大概30到60分钟能跑完取决于机器配置和网络速度。装完之后你就能拥有一个包含仓库管理、MR/CI、Wiki、Issue跟踪的完整平台。1. 动手之前先想清楚装完要给谁用1.1 这不只是“一条命令”的事很多人看到安装命令就一条yum install -y gitlab-ce觉得跟装个Nginx差不多实际上GitLab把一堆服务打成了一个Omnibus包里面除了应用本身还打包了数据库、缓存、Web服务器、后台任务队列。用Omnibus方式安装好处是统一管理、配置集中但代价是资源占用相当可观。我第一次装的时候拿一台2核2G的虚拟机硬跑reconfigure过程直接卡死后来把日志翻出来发现内存耗尽进程被系统OOM Killer干掉。所以如果你想在生产环境长期用最低建议4GB内存起步8GB内存才算舒服。GitLab官方对4GB内存的定义是“可以跑但会很吃力”实际体验也确实如此开十几个开发者、跑几条流水线内存就会吃紧频繁触发swap导致页面响应变慢。这里有个概念要先建立GitLab不是一个“软件”它是一套“服务集群”。你在CentOS 7上安装它本质上是在搭一个小型服务器群组只是Omnibus包把复杂度包装起来了。理解了这一点后面遇到什么502、内存不足、端口冲突就不会一脸懵。1.2 Omnibus、Docker、源码为什么我选OmnibusGitLab主流的安装方式有三类Omnibusrpm/deb一键包、Docker容器、源码编译。源码方式在CentOS 7上非常痛苦依赖极多升级维护成本高现在基本没人自己编译了。源码方式我直接不建议除非你是想研究GitLab内部实现。Docker方式其实不错一条docker run就能起一个实例但这里有个细节GitLab在容器里也是跑一整套内部服务对宿主机内存、磁盘的要求并没有降低而且数据卷、端口映射、HTTPS证书这些细节需要额外理解对新手反而增加认知负担。我推荐Omnibus方式原因很实际。第一gitlab-ctl这个管理命令把所有服务的启停、状态检查、配置重载统一起来了不需要单独记nginx怎么重启、postgresql怎么启动。第二rpm包安装后会自动配置好systemd服务服务器重启后GitLab能自动拉起省心。第三CentOS 7本身就是Red Hat系rpm是原生包管理升级直接yum update gitlab-ce路径最顺畅。1.3 版本选择社区版还是企业版GitLab分CE社区版和EE企业版安装步骤一样只是包名不同。个人使用、小团队内网用CE完全够。有人担心CE缺功能实际上代码托管、Merge Request、CI/CD、Wiki、Issue这些核心功能CE都包含EE多的主要是审计日志、多LDAP、弹性伸缩等企业级能力小团队用不到。装的时候直接装gitlab-ce就行不要想着“先试试EE后面再说”两个版本包之间切换虽然可行但没必要。另外安装源默认给的是当前最新稳定版不需要手动指定版本除非你公司有版本合规要求那才需要在repo里锁定具体版本号。对新装环境跟随最新稳定版是最省心的选择。2. 环境准备把 CentOS 7 收拾干净再动手2.1 先确认系统身份和基础状态进服务器第一件事确认你的系统确实是CentOS 7。虽然标题写了CentOS 7但我见过太多人在CentOS 8甚至其他发行版上执行CentOS 7步骤结果处处报错。用cat /etc/redhat-release看下如果是7.x就继续。系统时间也很重要GitLab的HTTPS证书校验、日志排序、Cron任务都依赖准确时间。我习惯在装GitLab前把时区调到中国标准时间并同步sudo timedatectl set-timezone Asia/Shanghai sudo chronyd -qCentOS 7关于yum update -y我的建议是装GitLab之前别直接执行全量更新。原因很现实GitLab的rpm包本身会带依赖它需要的运行库版本在CentOS 7的默认源里都有不需要先升级一堆包。全量更新容易把内核、glibc这些基础组件升级到新版本万一跟当前环境有兼容问题排查起来非常头疼。如果你非要更新至少先把需要用的磁盘空间预留好。GitLab安装包加依赖大概会占2到4GB的空间这还不算以后的仓库数据。所以装之前用df -h确认/opt和/var所在分区有足够空间。以后仓库数据默认全放到/var/opt/gitlab别让这个目录所在磁盘只有十几GBGit仓库长起来是很快的。2.2 防火墙与SELinux两个最容易背锅的地方CentOS 7默认开着firewalld默认策略会把80端口挡在外面。GitLab的Web服务走HTTP/HTTPSSSH走22端口这些都要放行。最简单的做法是直接停掉防火墙但我不建议在正式环境这么干正确的做法是只放行需要的端口sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --reload如果装了云服务器还要记得在安全组里放行对应的端口这一步经常被忽略防火墙放行了但外面访问不了就是这个原因。然后是SELinux。CentOS 7默认SELinux是Enforcing模式GitLab的Nginx要监听端口、读写大量目录默认策略下经常出现页面能打开但静态资源加载不了或者Git clone时连接被拒的情况。GitLab官方对SELinux的态度是支持但需要额外配置策略对小团队来说最简单的是直接设为permissivesudo setenforce 0 sudo sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config第一行立即生效第二行保证重启后依然生效。设成permissive之后SELinux只会记录违规日志不会真正拦截行为对GitLab这种内部服务完全够用。千万别设成disabled那是把所有SELinux保护层全部关掉除非你很清楚自己在做什么。2.3 swap别省帮你扛过安装期的高峰GitLab reconfigure的时候会同时启动数据库初始化、Nginx配置生成、资产文件预编译等一系列任务内存峰值相当高。4GB内存机器在安装阶段很容易触发OOM这时候一个swap能救命。我个人习惯给2GB到4GB的swap尤其内存小于8GB时这一步很值得做。创建swap文件的方式sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab老版本内核可能需要用dd来创建swap文件CentOS 7默认4.18内核一般fallocate够用。swap能缓解内存压力但它不是万能的如果日常使用中swap持续被大量占用说明物理内存确实不够该加内存就加内存。3. GitLab CE 安装全流程记录3.1 先装Postfix还是装完再配邮件GitLab本身不自带邮件发送服务它依赖系统里有一个SMTP服务器默认情况下Omnibus包找的是Postfix。新用户注册、密码找回、MR通知、CI结果通知全靠邮件。如果不装Postfix这些功能都不会正常工作但你不会立刻发现因为GitLab不会在页面上弹红色警告。所以我建议的安装顺序是先装Postfix再装GitLab。Postfix在CentOS 7源里直接有sudo yum install -y postfix sudo systemctl enable postfix sudo systemctl start postfix装完后检查一下systemctl status postfix确认是active状态。如果你的环境不允许出站25端口邮件功能还是发不出去那也别慌后面可以在GitLab里配置外部SMTP服务器比如用企业邮箱、第三方邮件服务这个等以后需要时再配。如果实在是内网测试不想折腾邮件Postfix可以不启动GitLab其他功能不受影响只是通知类邮件发不了。3.2 配置YUM源并执行安装GitLab官方提供了安装脚本一行命令就能把yum源配好curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash这条命令做了三件事下载GitLab仓库配置文件到/etc/yum.repos.d/gitlab_gitlab-ce.repo导入GPG签名公钥最后自动执行yum makecache刷新缓存。脚本输出里能看到仓库地址和源版本。国内服务器访问官方源很慢甚至超时。这种时候建议手动改用国内镜像源新建/etc/yum.repos.d/gitlab-ce.repo内容替换为镜像站地址。这里以清华源为例[gitlab-ce] nameGitlab CE Repository baseurlhttps://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/ gpgcheck0 enabled1需要说明的是这里gpgcheck0是省掉了密钥校验的麻烦。如果你有安全洁癖可以保留官方源里的GPG key导入步骤再把gpgcheck1写回。我一般在内网环境图省事会用0外网环境还是建议完整校验。源准备好后直接安装sudo yum install -y gitlab-ce这个包目前大约1GB上下下载时间取决于带宽。安装过程末尾会提示你用gitlab-ctl reconfigure完成初始化还会提示默认的初始密码位置。到这一步GitLab的二进制文件已经就位但服务还没有真正起来因为配置文件里最关键的一项external_url还没设置。3.3 external_url 到底怎么填这一步值得单独说/etc/gitlab/gitlab.rb是GitLab的核心配置文件安装后我要做的第一件事就是改external_url。这个词的意思是“外部访问这个GitLab的URL”可以填域名也可以填IP。# /etc/gitlab/gitlab.rb external_url http://10.0.0.8如果你有正式域名就填http://gitlab.company.com这种如果是纯内网测试直接填服务器IP。填完务必执行gitlab-ctl reconfigure让配置生效。这里很多人犯错改了配置文件却只执行gitlab-ctl restart然后发现没生效。因为restart只是重启服务不会重新读取gitlab.rb里的配置变化只有reconfigure会把配置重新生成并应用。如果机器80端口已经被其他服务占了你要用别的端口访问GitLab可以把external_url改成带端口的形式external_url http://10.0.0.8:8090GitLab会自动让Nginx监听8090端口克隆地址也会带上端口。但这里有个坑Git仓库走SSH协议的时候默认用的是22端口。如果服务器22端口是ssh服务在占你不能让GitLab的SSH也用22得在gitlab.rb里单独设置gitlab_rails[gitlab_shell_ssh_port] 2222否则用户clone时得到的地址是git10.0.0.8:group/project.git但服务器的22端口根本不是GitLab的SSH服务连不上。设了2222之后clone地址会变成ssh://git10.0.0.8:2222/group/project.git。这个细节不提前知道等用户报“我拉不下代码”再排查就费劲了。3.4 首次reconfigure与root账号登录改完external_url执行初始化sudo gitlab-ctl reconfigure这一步耗时长4核8G的机器大概3到5分钟2核4G的要8到10分钟。整个过程会依次初始化PostgreSQL、Redis、Nginx配置启动Sidekiq、Gitaly最后编译Webpack资产。期间输出一大片日志看着像报错其实大多数是INFO信息。判断成功与否看最后几行有没有gitlab Reconfigured!或者直接执行sudo gitlab-ctl status看服务状态。安装完成后第一次访问浏览器打开http://你的IP会自动跳转到密码重置页。但这里有个问题如果你没有这一步跳转或者想直接用管理员账号登录需要用初始密码。新版GitLab把初始root密码写进了文件sudo cat /etc/gitlab/initial_root_password文件里有个Password:字段就是root的初始密码。这个文件只在安装后24小时内有效那个时间段内你申请的密码会写入过了24小时文件里的内容也不会变了但如果你没及时保存之后文件可能被自动清理。所以拿到密码后立刻登录进去赶紧改密码。登录成功后我强烈建议顺手做一件事关闭公开注册。公司内网GitLab默认是允许任何人注册账号的哪怕你不知道地址扫到IP就能注册。在管理设置里找到Sign-up restrictions取消勾选Sign-up enabled只保留管理员手动创建账号这样避免陌生人注册进来。4. 启动之后日常管理和资源优化4.1 reconfigure、start、restart 的命令区别装完之后你手里的管理命令主要是gitlab-ctl不要把它跟systemctl混淆。gitlab-ctl是Omnibus包装好的统一管理入口它对内管理Nginx、PostgreSQL、Redis、Puma这些服务。日常会用到三条命令我刻意把它们拆开讲因为用法差别很大sudo gitlab-ctl reconfigure修改gitlab.rb配置文件后必须执行它它会重新生成所有服务配置并重启受影响的服务。注意它不是“重启”而是“应用配置变更”。sudo gitlab-ctl restart重启GitLab所有服务不读取配置变更。进程异常挂掉、内存泄漏需要重置时用。sudo gitlab-ctl status查看所有服务当前状态。排查问题第一步先看它输出。另外单独重启某个服务也是支持的比如sudo gitlab-ctl restart sidekiq。有时候Sidekiq卡住了没必要整套服务重启单点重启就能恢复这在生产环境是很有用的操作。我有个习惯做完任何配置修改先跑gitlab-ctl status看看各服务是不是都是run然后再打开页面验证功能。4.2 内存不够时怎么把花哨功能关掉先说一个现实GitLab全功能启动后内存占用通常在3到5GB不等这还不算后台任务峰值。如果你只有4GB内存开机后什么都没干内存已经见底。Omnibus包默认把一堆监控组件也装上了其中Prometheus全家桶最吃内存。省内存的第一步关掉Prometheus监控# /etc/gitlab/gitlab.rb prometheus_monitoring[enable] false改完执行sudo gitlab-ctl reconfigure。这个默认带的监控体系对小团队来说基本用不上关掉能省下几百MB内存。第二步调整Puma的worker数量。Puma是处理HTTP请求的应用服务器默认会根据CPU核数起worker已经占了不少内存。限制一下puma[worker_processes] 2 puma[max_threads] 4同样要reconfigure。调整之后内存占用会明显降低但并发处理能力也相应下降。实时验证效果用free -h看内存装完到现在内存下降很明显。这套操作对小规模内网使用是合理的取舍人少并发低不需要那么多worker吃内存。4.3 备份、升级和卸载的合规流程GitLab的数据分两部分一部分是PostgreSQL数据库里的项目元数据、用户信息、MR记录另一部分是Git仓库本体文件。所以备份命令是专门设计的不是简单打包整个目录sudo gitlab-backup create老版本这条命令叫sudo gitlab-rake gitlab:backup:create新版改成gitlab-backup。备份输出默认放/var/opt/gitlab/backups文件名带时间戳。备份仓库数据库和Git文件但有一个东西不会自动备份配置文件。/etc/gitlab/gitlab.rb和/etc/gitlab/gitlab-secrets.json必须手动备份。尤其是gitlab-secrets.json它保存了GitLab的各种加密密钥丢了的话即使你有数据库备份恢复出来也是各种解密错误。我习惯把这两个文件连同备份一起打包下载sudo tar czf /var/opt/gitlab/backups/gitlab-config-$(date %F).tar.gz /etc/gitlab/升级GitLab前流程必须是先备份再升级。在CentOS 7上升级就是sudo yum install -y gitlab-ceyum会装最新版。但这里有个大坑GitLab跨大版本升级不能直接跳比如13升14可以14升15可以但13升15会失败。官方要求每次只能升一个大版本。所以如果你旧版本比较老得先改成老版本对应的源锁版本逐步升一次一次reconfigure。这不是危言耸听我见过有人从12直接升15数据库迁移报错之后整个实例起不来最后靠备份恢复才解决。卸载倒是简单sudo gitlab-ctl uninstall会停止服务并移除rpm安装记录但数据目录还在。想彻底清掉数据执行sudo gitlab-ctl cleanse之后手动删除/etc/gitlab、/var/opt/gitlab、/var/log/gitlab这三个目录。一般只有准备重装才需要这么干。5. 常见问题与排查速查表5.1 几个我实际遇到过的问题先说502。安装完第一次打开页面看到“Whoa there! GitLab is taking too much time to respond.”绝大多数情况下是服务还没完全启动。这不一定是故障等多一两分钟刷新可能就好了。确认方法就是跑gitlab-ctl status如果Puma或者Sidekiq还在启动中等它从down变run。如果等了很久还是502大概率是内存不足导致Puma起不来用dmesg | tail能看到OOM Killer的痕迹。解决方案就是之前说的加内存、加swap、关Prometheus三选一或者都做。再说reconfigure卡住。这可能是网络源慢也可能是系统时间不对导致证书校验失败。如果卡在下载或者ruby_block上先确认date时间是否正确不对就同步然后看是不是yum源访问慢换国内镜像源。实在不行重新执行一次reconfigure有时候就是网络抖动导致某一步失败重跑能过。Postfix启动失败我也踩过。25端口被占是常见原因看systemctl status postfix确认端口是谁占了。如果确实不想用Postfix就在gitlab.rb里把SMTP配置改成外部邮件服务比如改成阿里云或腾讯的企业邮箱SMTP这个后面可以单独配。5.2 排查前先养成三个习惯排错最重要的不是记命令是建立一套自己的排查顺序。我每次遇到GitLab异常第一件事是sudo gitlab-ctl status看服务整体状态。第二件事是看日志GitLab日志全在/var/log/gitlab下按组件分目录比如gitlab-rails目录里是应用日志nginx目录里是访问日志和错误日志。回滚一个技巧先看tail -n 200最近日志时间点对齐出问题的时刻基本能找到直接线索。不要凭感觉改配置很多“玄学”问题最后都能在日志里找到答案。比如静态资源加载404看一眼Nginx错误日志多半是SELinux拦截比如git clone报权限错误看一下gitlab-shell日志多半是SSH key配置问题。5.3 问题速查表症状最常见原因处理动作页面502Puma未启动或内存不足运行gitlab-ctl status查看OOM日志加内存或关Prometheus静态资源加载失败SELinux拦截Nginx读写临时setenforce 0永久改permissive页面能开但克隆报错external_url或SSH端口配置错误检查gitlab.rb里的external_url和gitlab_shell_ssh_port初始密码文件找不到超过24小时后被清理用gitlab-rails console修改root密码reconfigure卡在ruby_block网络源慢或系统时间不对换国内镜像源同步时间后重跑邮件发不出去Postfix未启动或25端口被限制启动Postfix或配置外部SMTP写到这里GitLab在CentOS 7上的安装流程、配置、管理、排错就基本讲完了。这套流程我在不同的机器上重复过很多次最深的体会是GitLab安装本身并不难难的是先把环境准备做扎实。我现在的习惯是拿到一台新机器固定顺序先把swap建好、SELinux关掉、防火墙端口放行、Postfix装好然后才碰GitLab的安装包顺序不乱后面省下的时间远超前期这点准备功夫。你装的时候可能环境跟我不完全一样但只要抓住“服务全套、配置统一、日志兜底”这几个关键词遇到任何报错都能把问题缩小到一个可排查的范围内。