当前位置：首页 > 虚拟主机 > 正文

Gitlab 14.2.1怎么部署？,服务器搭建git网站步骤详解

GitLab 14.2.1的部署并不复杂，核心在于前期硬件评估、依赖环境配置和初始化参数调优三步，本文将给出一套可直接上手的完整部署路径。

部署前必须想清楚的三件事

很多团队在部署GitLab时习惯直接敲命令,结果跑到一半发现内存不足或者端口冲突，花十分钟确认以下三个问题，能省下后面几小时的排错时间。

硬件配置是否达标

GitLab是一个吃内存的应用,尤其是Gitaly和PostgreSQL这两个组件，根据官方文档对GitLab 14.2.1的硬件要求，4GB内存是运行小型团队实例（约100用户）的底线，2GB内存仅支持极轻量的测试环境，如果服务器内存低于4GB，强烈建议先配置Swap分区或直接升级配置。

磁盘性能直接决定代码克隆和推送的体验。SSD是必须的，机械硬盘在并发访问时会产生明显的延迟，建议为GitLab单独挂载一块数据盘，将代码仓库和数据库文件与系统盘隔离，避免系统日志写满磁盘导致服务异常。

操作系统选型

GitLab 14.2.1官方支持的主流系统包括：

  • Ubuntu 20.04 LTS / 18.04 LTS
  • CentOS 7 / Rocky Linux 8
  • Debian 10 / 11

CentOS 7和Ubuntu 20.04是社区中使用最广泛的两个选择，如果你是第一次部署，优先考虑Ubuntu 20.04，它的依赖管理更省心，使用CentOS 7时要注意，系统自带的Git版本较老，需要额外配置Software Collections仓库。

域名与端口规划

安装前确定好GitLab对外服务的域名和端口,默认情况下GitLab会占用80和443端口，如果服务器上还跑了Nginx或Apache，需要提前调整端口规划，或者直接让GitLab接管Nginx（默认行为），域名建议使用二级域名如git.example.com，后续配置HTTPS证书时会方便很多。

GitLab 14.2.1 部署实操全流程

以下步骤基于Ubuntu 20.04 LTS和CentOS 7两套命令分别说明，你可以根据自己的系统环境选择对应的命令执行。

第一步：安装系统依赖

Ubuntu系统执行：

sudo apt-get update sudo apt-get install -y curl openssh-server ca-certificates postfix

安装过程中如果弹出Postfix配置界面,选择“Internet Site”并将域名填为你的服务器域名，如果不想装Postfix，也可以用其他SMTP服务替代，但注意GitLab的邮件通知功能依赖它。

CentOS 7系统执行：

sudo yum install -y curl policycoreutils openssh-server openssh-clients postfix

这里有个细节：别省略policycoreutils，GitLab在安装后需要运行gitlab-ctl reconfigure，这个过程会调用SELinux相关的命令，缺了这个包会直接报错。

第二步：添加GitLab软件源并安装

GitLab CE（社区版）的源地址是固定的，直接执行：

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

仓库配置完成后,安装指定版本：

sudo apt install -y gitlab-ce=14.2.1-ce.0

CentOS 7的安装命令略有差异：

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash sudo yum install -y gitlab-ce-14.2.1-ce.0.el7.x86_64

锁定版本很重要，GitLab的升级节奏很快，如果不锁定版本，之后的yum update或apt upgrade可能会把GitLab带到一个你不熟悉的新版本，14.2.1的配置项和14.10或15.x版本之间存在不少差异。

第三步：修改核心配置文件

GitLab的主配置文件位于/etc/gitlab/gitlab.rb，用编辑器打开，至少需要修改以下几项：

external_url 'http://git.example.com' gitlab_rails['time_zone'] = 'Asia/Shanghai' gitlab_rails['gitlab_shell_ssh_port'] = 2222

  • external_url指定用户访问GitLab的地址，如果是内网部署就填内网IP，如果走HTTPS就写成https://git.example.com。
  • time_zone一定要设成Asia/Shanghai，否则提交记录显示的时间和本地时间差8个小时，排查问题时很容易误导。
  • gitlab_shell_ssh_port是SSH协议推送代码的端口，如果服务器的22端口已被占用，需要这里改个端口，同时还要同步修改SSH配置。

第四步：初始化并启动GitLab

执行配置生效命令：

sudo gitlab-ctl reconfigure

这个命令会依据gitlab.rb的配置生成所有组件（Nginx、PostgreSQL、Redis、Sidekiq、Gitaly等）的配置文件，并启动整个服务栈。首次执行需要耗时3到5分钟，期间会看到大量输出，只要最后没有红色的ERROR字样，就说明初始化成功。

启动完成后检查服务状态：

sudo gitlab-ctl status

看到类似run: nginx: (pid 1234)的绿色状态就说明组件运行正常。

第五步：访问并修改初始密码

首次访问http://git.example.com，浏览器会跳转到密码设置页面，为root账号设置一个强密码。root账号拥有全部管理权限，建议密码至少包含大小写字母、数字和特殊字符，同时开启二次验证。

登录后建议立即做两件事：

  1. 在Admin Area -> Settings -> Visibility and access control

    中，将默认项目可见性设为“私有”。

  2. 在“用户”中关闭公开注册功能，避免陌生账号自动注册。

    3. 性能调优：让GitLab跑得更稳

    安装完成只是开始,如果不做调优，GitLab在低配服务器上的表现会比较吃力。

    内存优化

    GitLab 14.2.1默认配置的Unicorn Worker数量是CPU核心数+1，Puma可能还会额外产生几个进程，对4GB内存的服务器，建议手动调整：

    puma['worker_processes'] = 2 sidekiq['max_concurrency'] = 5 postgresql['shared_buffers'] = "512MB"

    这里需要说明的是,降低Worker数量会略微牺牲并发处理能力，但能明显降低内存峰值，实际使用中，10人以内的团队并发推送代码，2个Worker完全够用。

    交换分区设置

    如果服务器内存确实低于4GB且暂时无法升级,可以创建一个4GB的Swap文件缓解压力：

    sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

    同时在/etc/fstab中添加一行实现开机自动挂载，Swap能避免内存不足时进程被OOM Killer杀掉，但本质上Swap的性能远不如物理内存，长期使用还是建议加内存。

    存储路径分离

    将Git仓库的存储目录挪到独立数据盘是比较常见的做法：

    git_data_dirs({ "default" => { "path" => "/data/gitlab-data" } })

    修改后执行sudo gitlab-ctl reconfigure，新仓库会写入新路径，历史数据迁移需要停服操作，建议在部署初期就规划好。

    安全加固不可忽略

    GitLab本身的安全性不错,但默认配置面向通用场景，需要根据实际使用环境做一些加固。

    配置HTTPS

    自签证书或使用Let’s Encrypt都可以，在/etc/gitlab/gitlab.rb中：

    nginx['enable'] = true nginx['redirect_http_to_https'] = true

    将证书文件和密钥分别放到/etc/gitlab/ssl/目录下，并在配置中指定路径。HTTP到HTTPS的重定向务必开启，否则用户走HTTP提交的账号密码会被明文传输。

    防火墙与安全组配置

    只放行必要端口：22（SSH）、80/443（HTTP/HTTPS）、8080（如需启用Prometheus监控），在云服务器上，安全组规则和系统防火墙需要同时配置。

    定期备份

    GitLab内置了备份工具：

    sudo gitlab-backup create

    备份文件默认存放在/var/opt/gitlab/backups目录，配置文件

    /etc/gitlab/gitlab.rb不会被备份，需要额外拷贝，建议将备份文件同步到异地存储，单纯放在同一台服务器上无法抵御磁盘故障。

    常见问题排查思路

    502页面频繁出现

    多半是Unicorn/Puma进程崩溃或端口未监听，先执行sudo gitlab-ctl status查看组件状态，再用sudo gitlab-ctl tail puma查看实时日志，重点关注内存相关的错误信息。

    80端口被占用

    如果服务器上已经跑了Web服务,可以在gitlab.rb中修改Nginx监听端口：

    nginx['listen_port'] = 8081

    对外地址改为http://git.example.com:8081，或者用反向代理转发到8081端口。

    SSH推送代码无法连接

    确认gitlab.rb中gitlab_shell_ssh_port设置的端口，同时检查防火墙是否放行该端口，客户端侧的推送地址应与配置保持一致，格式为ssh://git@git.example.com:2222/group/project.git。

    Q&A：GitLab 14.2.1 部署高频疑问

    Q：GitLab 14.2.1可以无缝升级到新版吗？

    A：支持逐步升级，但14.2.1属于14.x早期版本，跨版本升级需要先升级到14系列最新版本，再跨越到15.x、16.x，每步升级前务必阅读官方升级路径文档，并做好快照和备份。

    Q：服务器配置有限，GitLab和Jenkins能共存吗？

    A：技术上可行，但不建议，GitLab本身占用内存已接近2GB左右，Jenkins又是一个内存大户，两者叠加容易出现资源竞争，如果必须共存，GitLab侧应降低Worker数量，Jenkins侧限制并发构建任务数。

    Q：选择自建GitLab是否比购买云代码托管服务更划算？

    A：这取决于团队规模和运维能力，自建GitLab能完全掌控数据归属和功能定制，但需要投入服务器成本、维护精力和安全防护精力，市面上一些提供代码托管服务的IDC服务商也提供预装GitLab的裸金属租用方案，比如国内持牌运营商西西云提供的应用托管类服务器，支持预置GitLab环境的镜像，配置好域名后即可投入使用，适合不想从零搭建的团队，需要强调的是，部署在哪一类的服务器上并不是关键，关键在于代码数据的持久化备份和恢复演练是否到位。

    Q：国内服务器部署GitLab需要注意什么？

    A：国内云服务器默认情况下面向公网提供服务需要完成ICP备案，这是基础合规要求，选择服务商时可以优先考虑持有工信部增值电信业务许可的持牌自营机房，比如具备IDC/CDN/ISP全牌照的西西云，以及运营超过20年的简米科技机房，备案流程通常需要2-3周，建议提前规划，如果只是内网测试环境，则无需备案，通过内网IP访问即可。

2.1部署步骤Gitlab安装与配置方法Gitlab服务器搭建指南服务器搭建Git网站教程
0

相关文章