版本管理系统 Git 和 GitLab
持续集成 (CI-Continuous Integration)
集成指将多位开发者的开发代码提交后,合并集成在一起,存放在代码库的过程,并且后续还会不断的迭代更新代码
持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不
影响工作。很多情况下每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
CI属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。
根据测试结果，可以确定新代码和原有代码能否正确地集成在一起。通过持续集成可以自动编译、打
包、签名项目，配合单元测试可以实现持续集成+自动化测试。让工程师从重复而又枯燥的手动打包完全
解放出来，让工程师能更加专注于代码本身，最大限度的减少误操作风险，降低修复错误代码的成本，
大幅提高工作效率。
持续交付(CD-Continuous Delivery)
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可以自动的将已验证的代码发布到存储
库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代
码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
持续交付完成了构建和测试过程细致的自动化，但是如何发布以及发布什么仍然是需要人工操作，持续部署可以改变这一点。
持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的
工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以
保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确
保新增的代码能够与原先代码正确的集成。
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」
（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的
Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。此方式是当前普遍
采用的方式
持续部署(CD-Continuous Deployment)
对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付(自动将生产就绪型构建版本发
布到代码存储库)的进一步延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段
没有手动风控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。
实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测
试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用
的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动
化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。
持续部署是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产
品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。
与持续集成相比，持续交付（CONTINUOUS DELIVERY）的侧重点在于交付，其核心对象不在于代码，
而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续
交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产
Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。
在持续交付的基础上，把部署到生产环境的过程自动化。如果你对比上图持续部署就可以发现持续部署
和持续交付的区别就是最终部署到生产环境是自动化的。因为自动发布存在较大的风险,当前采用此方式
较少.
DevOps 和 CICD
对比角度 DevOps CI/CD
本质 一种文化、理念、方法论 一组自动化技术实践
目标 打通开发与运维，提升交付速度与质量 实现自动构建、测试、部署
作用范围 覆盖整个软件生命周期（开发、测试、运
维、监控） 主要聚焦在将代码完成部署的流程
是否需要
工具
需要（CI/CD、监控、日志、IaC、协作
等） 本身就是工具链
举例 GitOps、容器化、监控告警、自动化测试 Jenkins、GitLab CI、GitHub
Actions、ArgoCD
DevOps：是一种涵盖文化、流程和工具的方法论，目的在于打破开发团队和运维团队之间的壁垒，促进双方协作与沟通，实现软件的高效交付与快速迭代。
其核心目标是提升团队间的协作效率，优化整个软件交付流程，缩短从开发到上线的周期，同时保证软件质量的稳定性。
贯穿于软件开发生命周期（SDLC）的全过程，从需求分析开始，历经开发、测试、部署，直至上线后的监控和反馈
CI/CD：
属于 DevOps 方法论中的具体技术实践，它借助自动化手段来达成软件开发流程中的持续集成（CI）、持续交付（CD）以及持续部署（CD）。
主要聚焦于自动化构建、测试和部署流程，减少人工干预，提高软件交付的频率和可靠性。
主要集中在开发和部署阶段，强调代码变更的自动化处理。
CICD 流程过程和架构
应用部署发展阶段
开发人员自行手动上传构建并部署代码
早期项目,没有专业的运维人员,运维的工作由开发兼职完成,项目发布很不专业,很容易出错,也是最原始的方式
开发人员先将代码发给运维,再由运维人员手动上传至生产环境
专业的运维人员完成应用的部署,每次项目发布都由运维人员一步一步手动实现,效率低下且容易出错
运维利用脚本和自动化运维工具实现部署
由运维人员编写Shell,Python等脚本或利用自动化运维工具,如Ansible等实现半自动化应用部署,效率很高,但对技术专业性有较高要求
通过 Web 等 GUI 界面实现一键自动化部署
可以通过开源或自研的运维平台实现方便的应用部署,操作容易,效率高,但需要提前构建运维平台，
比如，Jenkins等
CICD 流程
传统方式的CICD 流程
开发人员不断的进行代码提交到本地，再提交到运程的代码仓库服务器
Jenkins作为持续集成工具，使用Git工具到Git仓库拉取代码到集成服务器，代码测试与审查，再配
合JDK，Maven，Go等软件完成代码编译，测试，打包等工作，在这个过程中每一步如果出错，都
需要重新再执行一次整个流程。
Jenkins把生成的软件jar或war包等分发到测试服务器或者生产服务器，测试人员或用户就可以访问应用。
容器化方式的 CICD 流程
Kubernetes 环境的 CICD 流程
CICD 基础架构
常见的版本控制系统
SVN(Subversion) 集中式版本控制系统
SVN 由 CollabNet 公司于 2000 年资助并发起开发，目的是创建一个更好用的版本控制系统以取代
CVS。
2000 年 2 月，CollabNet 联系了 Open Source Development with CVS（Coriolis, 1999）的作者 Karl
Fogel，问他是否愿意为这个新项目工作。这时 Karl 已经在和他的朋友 Jim Blandy 讨论一个新的版本控
制系统的设计。他不仅已经起好了名字 “Subversion”，而且有了 Subvesion 资料库的基本设计。
经过 14 个月的编码，在 2001 年 8 月 31 号，Subversion 可以“自我寄生”了。就是说，Subversion 开
发人员停止使用 CVS 管理 Subversion 的源代码，开始使用 Subversion 代替。
2009 年 11 月，Subversion 被 Apache Incubator 项目所接收。2010 年 1 月，正式成为 Apache 软件
基金会的一个顶级项目
SVN 依赖于网络，需要在各个开发主机上安装客户端软件,并且在一台服务器集中进行版本管理和存储.
目前依然有部分公司在使用
优点：
- 管理方便，逻辑明确，符合一般人思维习惯。
- 易于管理，集中式服务器更能保证安全性。
- 代码一致性非常高。
- 适合开发人数不多的项目开发。
缺点：
- 服务器压力太大，数据库容量暴增。
- 如果不能连接到服务器上，基本上不可以工作，如果服务器不能连接上，就不能提交，还原，对比等等。
- 不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中
- 式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决
- 开发人数众多的问题。
Git
Git 重要特性:
在本地就可以完成提交,因此不需要网络,提交完成后,可以有网络环境时,再同步到远程仓库服务器
优点：
- 适合分布式开发，强调个体。
- 公共服务器压力和数据量都不会太大。
- 速度快、灵活。
- 任意两个开发者之间可以很容易的解决冲突。
- 支持离线工作。
缺点：
- 不符合常规思维。
- 是命令行工具，学习难度大，学习周期相对而言比较长。
- 没有实现安全控制，代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
- 无力支持大型二进制文件
- 具有大量历史记录的超大型存储库会降低交互速度
GitLab 网站和软件
Github 提供了公有云的软件仓库服务，但实现私有仓库早期是收费的，而GitLab的出现解决了这一问
题。GitLab由乌克兰程序员DmitriyZaporozhets和ValerySizov开发，它使用Ruby语言写成。后来，一
些部分用Go语言重写，是完全免费的开源软件，按照MIT许可证分发。2013年7月，GitLab产品被拆分
为两个版本：GitLab CE（社区版）和GitLab EE（企业版），2014年2月，GitLab宣布采用开放核心业
务模式。GitLabEE设置在专有许可证下，并且包含CE版本中不存在的功能。GitLabCE是使用MIT许可证
的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础
上搭建起来的Web服务。
从安全方面来看，公司不希望员工获取到全部的代码，这个时候Gi tLab是最佳的选择。但对于开源项目
而言，GitHub 依然是代码托管的首选平台。
GitLab 官方网站: https://about.gitlab.com/
Gitlab 企业版：
Gitlab 的优势
- 开源免费，搭建简单、维护成本较低、可适用于中小型公司内部项目使用。
- 权限管理功能强大灵活，能实现代码对部分人可见，确保项目的安全性。
- 支持离线提交，基于git实现,可以不在实时依赖网络环境进行代码提交。
常见的软件部署模式
蓝绿部署 Blue-green Deployments
蓝绿部署指的是不停止老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测
试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。但本方式成本较高,
一般小公司较少使用
蓝绿色部署是一种部署策略，利用两种相同的环境，即"蓝色"（又名预发布）环境和"绿色"（又名生产）
环境，具有不同版本的应用程序或服务。质量保证和用户接受度测试通常在承载新版本或更改的蓝色环
境中进行。一旦蓝色环境中测试并接受新的变化，用户流量就会从绿色环境切换为蓝色环境。然后，一
旦部署成功，您可以切换到新环境。
具体过程：
1、当前版本(V1)业务正常访问
2、在另外一套环境部署新代码版本(V2)，代码可能是增加了功能或者是修复了某些bug
3、测试通过之后将用户请求流量切到新版本环境
4、观察一段时间，如有异常直接切换旧版本
5、下次升级，将旧版本(V2)升级到新版本(V3)
蓝绿部署适用的场景：
1、不停止老版本，额外部署一套新版本，等测试确认新版本正常后，才将用户请求切换至新版本，如果
有问题，切换回老版本
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完
全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
金丝雀(灰度)发布 Canary Deployment
“金丝雀”的由来：17世纪英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量
的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发
身亡。当时在采矿设备相对简陋的条件下，工人每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以
便在危险状况下紧急撤离。
金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布
（例如：2%、25%、75%、100%）进行更新)的一种类型，灰度发布是在原有版本可用的情况下，同时
部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，
尽早发现、调整问题。因此，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整
问题，以保证其影响度。
此方式在实际生产中使用较为普遍
金丝雀/灰度发布步骤组成：
1、准备好部署各个阶段的工件，包括：构建组件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器（选择全部服务器中的一部分）。
3、升级“金丝雀”应用（排掉原有流量并进行部署）。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
6、如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。否则就回滚回旧版本
金丝雀/灰度发布部署适用的场景：
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。
3、经常与A/B测试一起使用，用于测试选择多种方案。
灰度发布可以在发布新版本应用时:
- 自定义控制新版本应用流量比重
- 渐进式完成新版本应用的全量上线
- 最大限度地控制新版本发布带来的业务风险
- 降低故障带来的影响
- 同时支持快速回滚
滚动发布(更新)
滚动发布即逐步升级服务中的节点
滚动发布是指每次只升级一个或多个服务实例，升级完成后加入生产环境，不断执行这个过程，直到集
群中的全部旧版本升级新版本。
红色：正在更新的实例，正在升级过程中间状态
蓝色：更新完成并加入集群的实例,升级完成的新版本
绿色：正在运行的实例，升级前的旧版本
滚动发布过程
1. 先升级1个服务实例，主要做部署验证
2. 每次升级1个服务实例，自动从LB上摘掉，升级成功后自动加入集群
3. 事先需要有自动更新策略，分为若干次，每次数量/百分比可配置
4. 回滚是发布的逆过程，先从LB摘掉新版本，再升级老版本，这个过程一般时间比较长
5. 自动化要求高
A/B测试 A/B Testing
A/B测试即同时对外提供两个APP运行环境，这和蓝绿部署的同时只有一个版本在线是不同的
A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等
蓝绿部署和A/B测试是不同的,蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚
即蓝绿部署是同一时间只有一套正式环境在线，而A/B测试是两套正式环境同时在线，一般用于多个产
品竟争时使用
版本控制系统 Git
Git 相关概念和原理
Git 的区域
Git 的数据存储从物理上分为当前项目目录和当前项目目录下的隐藏子目录.git，分别称为工作区和版本库
Git 版本库逻辑上又分为暂存区和本地仓库
工作区 Workspace：
工作区是你当前正在编辑和修改文件的地方。它是你的项目目录 ，通常是对应于<项目目录>
在这里你可以添加、修改或删除文件。工作区中的文件可以是已被Git跟踪的文件，也可以是未被
跟踪的文件。
工作区中的文件的变更不受Git的跟踪和管理，无法实现版本回滚等功能
需要将工作的的变更，通过 git add 命令加入暂存区后，才可纳入Git 的版本管理控制的范畴
暂存区 Staging Area/Index/Cached：
也称为索引区,缓存区，用于存储在工作区中对代码进行修改后的文件所保存的地方，只有放入此区
的文件才能被git进行管理,使用 git add添加,对应为<项目目录>/.git/index文件
暂存区主要用于临时保存文件少量变更，类似于邮件中的草稿箱
当变更累积到一定阶段，希望生成里程碑式的结果时，会使用commit，将暂存区的变更一次性的
批量提交到本地仓库
本地仓库 Local Repository：
用于存储在工作区和暂存区中改过并提交的文件地方，使用 git commit 提交,对应于/<项目目录
>/.git/
每一次commit 会生成一个唯一的ID，通常用于表示一个阶段性的新的版本
checkout命令执行了同commit命令相反的操作，它将版本中存储的commit所代表着的某个版本
恢复至工作区中
checkout命令完成后，工作区中的文件内容与其检出的提交那一刻的状态相同
若工作区中存储此前未被提交的新文件，这些文件的未被提交的新的更改会被存储仓库的旧内容覆
盖
当然，用户也可以暂存这些新文件，并将带有新文件的工作区提交到版本库中，这将是新的暂存和
提交循环
远程仓库 Remote Repository ：
多个开发人员共同协作提交代码的仓库，即私有 gitlab 服务器或公有云github,gitee网站等
利用远程仓库，可以实现异地备份和远程协作
dnf install git -y
#设置git，提交commit之前需要先配置git的基本信息
#选项--system 表示针对所有用户的配置,保存在/etc/gitconfig文件中
#选项--global 表示当前用户环境,保存在~/.gitconfig文件中,推荐使用
#选项--local 表示只针对当前目录(项目)的配置,保存在当前目录的.git/config文件中，此为默认值，
可省略
#优先级:local > global > system
#配置文件使用ini格式，存在一至多个[section]，各配置参数可以section为前缀引用
#列出已有配置：git config -l | --list
#用户名，另外还可以使用author.name标记作者，以及使用committer.name标记提交者
git config --global user.name ming
#用户的邮箱，还可以使用author.email标记作者邮箱和使用committer.email标记提交者邮箱
git config --global user.email root@ming.com
创建项目并初始化配置
mkdir /data/testproject/
cd /data/testproject/
#初始化
git init
添加暂存区并提交数据
touch a.txt
git add a.txt
git add .
git commit -m 'add a.txt'
mkdir 项目目录 myai
cd myai
git init (生成 .git,生成了暂存区和本地仓库空间)
git config --global
touch hello.java 工作区
git add . 工作区文件复制到暂存区
git commit -m xxxx 暂存区复制到本地仓库
查看暂存区的文件内容
echo testdata > test.txt
git add .
#查看暂存区的文件
git ls-files -s
git cat-file -p 4871fd52755be519c29ae719f385bd5f2863627c
echo testdata1 >> test.txt
git add .
git cat-file -p 4871fd52755be519c29ae719f385bd5f2863627c
利用暂存区恢复误删除的工作区文件
root@master1 myai]# git cat-file -p 60e4fd786d04261ad604d635a593d1f8b07b72ca
testdata
testdata1
[root@master1 myai]# cat test.txt
testdata
#从暂存区复制文件到工作目录
git restore test.txt
root@master1 myai]# cat test.txt testdata testdata1
如果工作区和暂存区数据不一致,会显示红
如果暂存区和本地仓库数据不一致,会显示绿色的提示
设置忽略文件
配置.gitignore文件让 Git 不再管理当前目录下的某些文件。
生产中有如下几类文件可能需要忽略
- 程序运行时产生的临时文件
- 程序连接数据库这一类的配置文件
- 程序本地开发使用的图片文件
- 其它不想被共享的文件
cat .gitignore
*.swp
*.exe
#注意:无须提交此文件.gitignore 就可以立即生效忽略，但为了保存此文件，还是最终需要提交此文件到本地仓库中
将文件加入暂存区再取消添加
touch f1.txt
git status
git add .
#从暂存区删除
git rm --cached f1.txt
#确认暂存区文件不存在
git ls-files -s
同时删除工作区和暂存区
touch f2.txt
git add .
git ls-files -s
ls
#同时删除工作区和暂存区文件
git rm -f f2.txt
ls
git ls-files -s
多次提交后回滚至指定提交的版本
git reset
git reset 官方说明
https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E9%87%8D%E7%BD%AE%E6%8F%AD%E5%AF%86
https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
git reset 是对本地仓库的项目进行回滚操作的命令，它主要有如下三个参数
--soft #工作目录和暂存区都不会被改变，只是本地仓库中的文件回滚到指定的版本，仅移动HEAD和master指针的指向，不会重置暂存区或工作区
--mixed #默认选项。回滚暂存区和本地仓库，但工作目录不受影响
--hard #本地仓库,暂存区和工作目录都回滚到指定的提交,该选项非常危险
[root@master1 myai]# cat f1.txt
v1
git add .
git commit -m "v1"
echo v2 >> f1.txt
git add .
git commit -m "v2"
echo v3 >> f1.txt
git add .
git commit -m "v3"
[root@master1 myai]# git log commit 799afaa7c77988df5cd952fbb305efae3615012c (HEAD -> master) Author: root <root@master1.org> Date: Sun Aug 30 18:44:37 2026 +0800 v3 commit a300412b82d0065ec00b911fc5efbd5cdd72700a Author: root <root@master1.org> Date: Sun Aug 30 18:43:36 2026 +0800 v2 commit 3a7f63cb4b674bd4bd95f7802e408058024bba4f Author: root <root@master1.org> Date: Sun Aug 30 04:38:03 2026 +0800 v1 commit eab685538c73b7747c292139229a5d7c8550c3f0 Author: root <root@master1.org> Date: Sun Aug 30 02:48:33 2026 +0800 commit
git revert
如果我们修改了某些内容，已经commit到本地仓库，并且push到远程仓库了，这种情况下想把本地和
远程仓库都回退到某个版本，该怎么做呢？
前面用git reset只是在本地仓库中回退版本，而远程仓库的版本不会变化，这样，即使本地reset了，但
如果再次git pull，那么，远程仓库的内容又会和本地之前版本的内容进行merge，造成回退失败。
对于已经把代码push到远程仓库，你退回本地代码其实也想同时退回线上代码，回滚到某个指定的版
本，线上线下代码保持一致。git revert用于撤销某次操作，此次操作之前和之后的commit和history都
会保留，即用一个新提交来消除一个历史提交所做的任何修改。
revert之后你的本地代码会回滚到指定的历史版本，然后再git push
git revert 用法
git revert HEAD #撤销前一次commit,会交互式打开文本编辑器提示输入提交信息
git revert HEAD --no-edit #非交互式撤销前一次提交
git revert HEAD^ #撤销前前一次commit
git revert <commitid> #撤销指定的版本，撤销也会作为一次提交进行保存
reset和revert区别
git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
git reset是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容跟要
revert的内容正好相反，能够抵消要被revert的内容。
以进为退
v1.0 ---> v2.0 --> v3.0 -- git revert v2.0 --> v2.0
源分支
目标分支
1）切换至目标分支
2）合并 git merge 源分支
当前状态打 tag 并利用 tag 回滚
git tag v3 799afaa7c77988df5cd952fbb305efae3615012c
私有软件仓库 GitLab
GitLab 介绍
Gitlab 介绍
GitLab 是一个基于Ruby on Rails构建用于仓库管理系统的开源项目，使用Git作为代码管理工具，提供
了Web界面进行访问公开的或者私有的项目
GitLab 特性
- 开源免费
- 可以作为 Git 代码仓库
- 提供了方便易用的 Web 管理界面
- 支持多租户
- 功能丰富
- 支持离线提交
- 安全性高, 可以对不同的用户设置不同的权限,并且支持不同用户只能访问特定的代码,实现代码部分可见
GitLab 架构
Gitlab 是一个由很多应用组成复杂的系统
https://panlw.github.io/15365441001781.html
Gitlab的服务构成
- Nginx：静态web服务器
- GitLab shell：用于处理基于ssh会话的Git命令和修改authorized keys列表
- gitlab-workhorse：轻量级的反向代理服务器,它旨在充当智能反向代理，以帮助整个 GitLab 加速
- unicorn：An HTTP server for Rack applications, GitLab Rails应用是托管在这个服务器上面的
- Gitaly：Git RPC service for handing all Git calls made by GitLab
- Puma (GitLab Rails)：处理发往Web接口和API的请求
- postgresql：数据库
- redis：缓存数据库
- sidekiq：用于在后台执行队列任务（异步执行)
- GitLab Exporter：GitLab指标暴露器
- Node Exporter：节点指标暴露器
- GitLab self-monitoring的多个组件：Prometheus、Alertmanager、Grafana、Sentry和Jaeger
- Inbound emails（SMPT）：接收用于更新issue的邮件
- Outbound email (SMTP)：向用户发送邮件通知
- LDAP Authentication：LDAP认证集成
- MinIO：对象存储服务
- Registry：容器注册表，支持Image的push和pull操作
- Runner：执行GitLab的CI/CD作业
管理各组件使用统一命令为gitlab-ctl，例如gitlab-ctl reconfigure或gitlab-ctl restart等能统—执行各组
件的重新配置及重启操作
此外还有一些各组件专用的命令，如:gitlab-backup,gitlab-pgsql,gitlab-rails和gitlab-rake等
提供统一配置模板文件, 用于为GitLab中的每个组件提供配置信息
在配置模板文件中对于每个组件配置参数格式为: ['']=
GitLab 安装
GitLab 有两个版本：EE商业版和CE社区版，以下使用CE版
安装方法
Gitlab 服务的安装文档：
https://docs.gitlab.com/install/
安装方法说明
https://docs.gitlab.com/ee/install/install_methods.html
Linux 安装包：官方的 deb/rpm 安装包（也被称作 Omnibus GitLab）包含极狐GitLab 和依赖的组件，包括PostgreSQL、Redis 和 Sidekiq
Source：源码安装，在GitLab没有提供适用的安装包的平台上（例如各类BSD系统）只能采用这种安装方式
Docker：Docker 容器化的极狐GitLab 软件包
GitLab Operator：Kubernetes Operator风格的部署模式
Helm Chart：用于在 Kubernetes 上安装极狐GitLab 及其所有组件的云原生 Helm chart
GitLab Environment Toolkit（GET）：自动化工具集，用于在主流的公有云（Azure、GCP和
AWS）上部署GitLab
安装 GitLab 要求
Gitlab硬件和软件的环境要求：
https://docs.gitlab.com/ce/install/requirements.html
硬件配置要求较高：
测试环境：内存4G以上，新版gitlab-ce_17.3.1建议8G以上
生产环境：建议CPU2C以上，内存8G以上，磁盘10G以上配置，和用户数有关
注意:如果内存较低,可以会导致Gitlab有些服务无法启动,建议4G以上内存
数据库要求:
从GitLab 12.1 开始Linux包安装不再支持MySQL,只支持PostgreSQL
RHEL 系统环境安装前准备
基于最小化服务器安装，建议修改配置如下：
wget http://mirrors.aliyun.com/repo/epel-7.repo
systemctl disable firewalld
sed -i '/SELINUX/s/enforcing/disabled/' /etc/sysconfig/selinux
hostnamectl set-hostname gitlab.ming.org
reboot
vim /etc/hosts
192.168.3.60 gitlab.ming.org
GitLab 安装
gitlab 安装有多种方式,下面选择包安装方式
https://docs.gitlab.com/install/
https://docs.gitlab.com/ce/install/
安装 GitLab
官方gitlab 包下载链接
https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/
https://packages.gitlab.com/gitlab
https://docs.gitlab.com/install/package/ubuntu/
GitLab-CE 安装包官方下载地址：
https://packages.gitlab.com/gitlab/gitlab-ce
yum源清华大学下载地址：
https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/
rocky国内镜像下载并安装 GitLab
wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/9/gitlab-ce-18.0.0-ce.0.el9.x86_64.rpm/download.rpm -O gitlab-ce.rpm
EXTERNAL_URL="http://192.168.3.60" dnf install -y ./gitlab-ce.rpm
安装缺失的依赖（在 Rocky 默认仓库里）
dnf install -y policycoreutils-python-utils
用 dnf 安装 GitLab（自动解决依赖 + 执行配置）
EXTERNAL_URL="http://gitlab.ming.org" dnf install -y ./gitlab-ce.rpm
Notes:
Default admin account has been configured with following details:
Username: root
Password: You didn't opt-in to print initial root password to STDOUT.
Password stored to /etc/gitlab/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours.
NOTE: Because these credentials might be present in your log files in plain text, it is highly recommended to reset the password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.
gitlab Reconfigured!
Thank you for installing GitLab!
GitLab should be available at http://gitlab.ming.org
For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
Help us improve the installation experience, let us know how we did with a 1 minute survey:
https://gitlab.fra1.qualtrics.com/jfe/form/SV_6kVqZANThUQ1bZb?installation=omnibus&release=18-0
gitlab-ctl status # 查看所有组件状态
gitlab-ctl restart # 重启 GitLab
gitlab-ctl stop # 停止
gitlab-ctl start # 启动
gitlab-ctl tail # 查看实时日志
gitlab-rake gitlab:check # 环境检查
# 查看初始 root 密码
# 密码保存在这里，24 小时后自动删除
cat /etc/gitlab/initial_root_password
# 登录 http://192.168.3.60，用户名 root
# 如需修改配置
vim /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure
登录并修改密码
浏览器访问 http://192.168.3.60（或你的域名）：
用户名：root
密码：上面文件中的内容
首次登录后务必修改 root 密码！
# gitlab root密码
,12345678
关闭账号注册功能
内存优化（小内存机器）
vim /etc/gitlab/gitlab.rb
# 减少 Puma worker 数量（默认根据 CPU 自动，小内存建议手动限制）
puma['worker_processes'] = 1
puma['min_threads'] = 1
puma['max_threads'] = 4
puma['per_worker_max_memory_mb'] = 850
# Sidekiq
sidekiq['concurrency'] = 5
# Redis
redis['maxmemory'] = '128mb'
redis['maxmemory_policy'] = 'allkeys-lru'
# 减少 PostgreSQL 内存
postgresql['max_connections'] = 50
postgresql['shared_buffers'] = "256MB"
postgresql['max_worker_processes'] = 4
postgresql['effective_cache_size'] = "512MB"
postgresql['work_mem'] = "8MB"
postgresql['maintenance_work_mem'] = "64MB"
# Nginx
nginx['worker_processes'] = 2
# 禁用 Prometheus（监控，很吃内存）
prometheus_monitoring['enable'] = false
# 重配置
gitlab-ctl reconfigure
GitLab 用户和组管理
用户管理
创建用户
创建gitlab用户账户并登录
修改密码
创建用户完成后,再编辑用户信息，才能修改密码
用户首次登录会提示修改密码
创建组群
使用管理员root 或用户都可以创建group组
一个group组里面可以拥有多个project项目分支，可以将开发的用户添加到组里，再进行设置权限
如果gitlab使用者的组织规模较大,每一个group组可以分别对应一个组织,如:某个分公司或部门
如果gitlab使用者的组织规模较小, 每一个group组也可以对应一个项目或业务,即每一个不同的group组
对应同一个组织内部的不同的项目
不同的组中添加不同的开发人员帐号，即可实现对开发者实现权限的管理。
GitLab 项目管理
创建项目
新建项目
项目project属于一个group组,即一般project对应一个项目中的功能模块或服务
注意: 此处在新建项目时先不进行初始化
创建项目,指定项目属于组,并选择不进行初始化项目仓库
导入项目
新版需要用root用户开启导入项目用到Gitlab功能才支持导入
搜索--管理中心--设置-- 通用--导入和导出设置
https://gitee.com/lbtooth/spring-boot-helloworld.git
保护分支
默认master 分支被保护,开发者角色无法对被保护的分支提交代码
也可以将其它分支进行保护,防止指定分支被破环
GitLab 的数据备份和恢复
数据备份和恢复官方帮助：
https://docs.gitlab.com/ee/raketasks/backup_restore.html
备份相关配置文件
/etc/gitlab/gitlab.rb
/etc/gitlab/gitlab-secrets.json #双因子验证等使用此文件
备份配置文件命令
gitlab-ctl backup-etc --backup-path <DIRECTORY>
#如果不指定--backup-path <DIRECTORY>，则默认备份至/etc/gitlab/config_backup/
范例：备份配置文件命令
gitlab-ctl backup-etc
root@master1 ~]# ls /etc/gitlab/config_backup/
gitlab_config_1788288876_2026_09_02.tar
cd /etc/gitlab/config_backup/
tar -xf gitlab_config_1788288876_2026_09_02.tar
root@master1 gitlab]# ll
total 176
-rw------- 1 root root 158849 Aug 31 03:25 gitlab.rb
-rw------- 1 root root 16316 Aug 31 03:25 gitlab-secrets.json
-rw------- 1 root root 749 Aug 31 02:34 initial_root_password
drwxr-xr-x 2 root root 6 Aug 31 02:34 trusted-certs
[root@master1 gitlab]# pwd
/etc/gitlab/config_backup/etc/gitlab
手动备份数据
不同版本的备份数据命令
#GitLab 12.2之后版本
gitlab-backup create
备份相关配置
#默认在/etc/gitlab/gitlab.rb文件中指定备份路径，如果目录空间不足，可以修改新的目录
#注意：修改完配置需要执行gitlab-ctl reconfigure
# gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
#备份的文件权限，所有者和所属组为git
# gitlab_rails['backup_archive_permissions'] = 0644
#默认备份过期时长为7天，单位为s, 之后会被自动删除
# gitlab_rails['backup_keep_time'] = 604800
范例：新版备份
gitlab-backup create
#默认备份保存在下面目录
ll /var/opt/gitlab/backups/
ll /var/opt/gitlab/backups/
total 660
-rw------- 1 git git 675840 Sep 2 03:02 1788289374_2026_09_01_18.0.0_gitlab_backup.tar
模拟删除项目
执行恢复
恢复的前提条件
备份和恢复使用的版本要一致
还原相关配置文件后，执行gitlab-ctl reconfigure
确保gitlab正在运行状态
新版恢复方法
#恢复前先停止两个服务
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
#恢复时指定备份文件的时间部分，不需要指定文件的全名
gitlab-backup restore BACKUP=备份文件名的时间部分_Gitlab版本
#示例
gitlab-backup restore BACKUP=1788289374_2026_09_01_18.0.0
gitlab-ctl reconfigure
gitlab-ctl restart
范例：新版恢复过程
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
gitlab-ctl status
#确保备份的版本名称
ll /var/opt/gitlab/backups/1788289374_2026_09_01_18.0.0_gitlab_backup.tar
#注意：备份文件所有目录及权限属性，无需指定完整文件名
gitlab-backup restore BACKUP=1788289374_2026_09_01_18.0.0
gitlab-ctl reconfigure
gitlab-ctl restart
#观察日志，等待恢复完成，需要再等一会儿再验证是否恢复
gitlab-ctl tail
确保还原完成
恢复后，项目及用户信息都已还原
注意：可能需要等一段时间才能打开浏览器进行访问
GitLab 迁移和升级
在生产中升级往往伴随着服务器的迁移,比如从本地机房迁移到云环境中,而实现升级
迁移流程
- 在原GitLab主机上备份配置文件和数据
- 在目标主机上安装相同的版本的GitLab软件
- 还原配置和数据
- 本质上就是备份和恢复的过程
升级流程
- 如果新主机，需要先安装原版本，并还原配置和数据
- 不能直接跳过中间的版本直接升级,选择最近的大版本进行升级 比如:12.1想升级到13.0,先升级到12.X最高版,再升级到13.0
- 下载新版本的安装包,直接安装包
- 安装包时可能会提示出错,原因是版本升级后有些配置项会过时,根据提示修改配置即可
- 重新配置: gitlab-ctl reconfigure
- 重启服务: gitlab-ctl restart
实现 Https
GitLab 如果用于不安全的网络，建议使用 https
注意：建议使用权威CA颁发的证书，自签名的证书需要加入信任,否则会导致后续git clone等操作失败
官方说明
https://docs.gitlab.com/omnibus/settings/nginx.html#enable-http
范例:
#创建证书
mkdir -p /etc/gitlab/ssl && cd /etc/gitlab/ssl
openssl genrsa -out gitlab.ming.org.key 2048
注意：CN=gitlab.ming.org 必须你的网站的域名
openssl req -days 3650 -x509 -sha256 -nodes -newkey rsa:2048 -subj "/C=CN/ST=beijing/L=beijing/O=wang/CN=gitlab.ming.org" -keyout gitlab.ming.org.key -out gitlab.ming.org.crt
修改配置文件的如下内容,必选项共4项
vim /etc/gitlab/gitlab.rb
external_url "https://gitlab.ming.org" #此项必须修改为https，必选项，还原为http时，只修改此行即可
nginx['redirect_http_to_https'] = true # 必选项，默认值为false，修改为true，实现http自动301跳转至https，，还原为http时，无需修改此行
nginx['ssl_certificate'] ="/etc/gitlab/ssl/gitlab.ming.org.crt" #必选项
nginx['ssl_certificate_key'] ="/etc/gitlab/ssl/gitlab.ming.org.key" #必选项
puma['worker_processes'] = 1
puma['min_threads'] = 1
puma['max_threads'] = 4
puma['per_worker_max_memory_mb'] = 850
postgresql['max_connections'] = 50
postgresql['shared_buffers'] = "256MB"
postgresql['max_worker_processes'] = 4
postgresql['effective_cache_size'] = "512MB"
postgresql['work_mem'] = "8MB"
postgresql['maintenance_work_mem'] = "64MB"
redis['maxmemory'] = '128mb'
redis['maxmemory_policy'] = 'allkeys-lru'
sidekiq['concurrency'] = 5
prometheus_monitoring['enable'] = false
nginx['worker_processes'] = 2
nginx['redirect_http_to_https'] = true # 必选项，默认值为false，修改为true，实现http自动301跳转至https，，还原为http时，无需修改此行
nginx['ssl_certificate'] ="/etc/gitlab/ssl/gitlab.ming.org.crt" #必选项
nginx['ssl_certificate_key'] ="/etc/gitlab/ssl/gitlab.ming.org.key" #必选项
#重新初始化
gitlab-ctl reconfigure
ss -ntlp|grep 443
#还登录原来的URL,会自动跳转到 https
范例: 解决自签名证书的信任问题
#由于自签名证书不信息,访问出下面错误
git clone https://gitlab.ming.org/devops/myai.git
#在使用git客户端的主机上信任自签名证书
scp gitlab-server:/etc/gitlab/ssl/gitlab.ming.org.crt .
#红帽系统证书路径
cat gitlab.ming.org.crt >> /etc/pki/tls/certs/ca-bundle.crt
cat /etc/gitlab/ssl/gitlab.ming.org.crt >> /etc/pki/tls/certs/ca-bundle.crt
重置 GitLab 忘记的密码
官方说明
https://docs.gitlab.com/ee/security/reset_user_password.html#reset-the-rootpassword
范例:
gitlab-rails console -e production
#此步可能比较慢,需要等一段时间
#输入下面指令
user = User.find_by_username 'root'
#更改密码并确认密码,注章：密码需要符合复杂性要
user.password=",123456789"
user.password_confirmation=",123456789"
#保存
user.save
#退出控制台
quit
#验证用新密码登录，注意：要使用external_url对应的URL登录才可以
浙公网安备 33010602011771号