DevOps、Git 和 GitLab
一、DevOps
DevOps 流水线模型
DevOps 涉及的四大相关平台
项目管理：如：Jira,禅道
代码托管：如：Gitlab,SVN
持续交付：如：Jenkins,Gitlab
运维平台：如：腾讯蓝鲸,Spug等
二、持续集成、持续交付和持续部署 CICD
持续交付：目标是拥有一个可随时部署到生产环境的代码库。
持续部署：可以自动将应用发布到生产环境。
（一）CICD 流程过程和架构
开发人员自行手动上传构建并部署代码
早期项目,没有专业的运维人员,运维的工作由开发兼职完成,项目发布很不专业,很容易出错,也是最原始的方式
开发人员先将代码发给运维,再由运维人员手动上传至生产环境
专业的运维人员完成应用的部署,每次项目发布都由运维人员一步一步手动实现,效率低下且容易出错
运维利用脚本和自动化运维工具实现部署
由运维人员编写Shell,Python等脚本或利用自动化运维工具,如Ansible等实现半自动化应用部署,效率很高,但对技术专业性有较高要求
通过 Web 等 GUI 界面实现一键自动化部署
可以通过开源或自研的运维平台实现方便的应用部署,操作容易,效率高,但需要提前构建运维平台，比如，Jenkins等
（二）版本控制系统 VCS
是用于追踪、管理文件 / 代码的修改历史、实现多人协作开发、保障数据完整性的核心工具，核心解决「版本混乱、协作冲突、代码丢失、追溯无据」四大问题，从单人开发到大型团队协作均能适配，其核心功能可分为基础核心功能、分支协作功能、团队管理功能、实用辅助功能四大类，不同类型 VCS（本地 / 集中式 / 分布式）在功能实现上有差异，但核心能力一致，以下是通用且核心的功能总结：版本追踪与快照记录文件的每一次修改（增 / 删 / 改），为每次有效修改生成唯一版本号 / 提交 ID，同时保存修改的作者、时间、修改内容，形成完整的版本历史链；部分 VCS（如 Git）会为项目生成版本快照，记录整个项目在某一时刻的完整状态，而非仅记录修改差异。修改备注与溯源要求每次提交修改时填写提交说明（备注改了什么、为什么改），结合版本历史链，可快速追溯任意版本的修改背景；支持按「作者、时间、关键词、版本号」检索历史修改，定位问题根源。回滚与恢复当代码出现 bug、误修改 / 误删除，或新功能开发失败时，可一键回滚到项目任意稳定版本；也可单独恢复某一文件的历史版本，避免因单次错误操作导致整个项目失效。本地备份与数据保护本地 VCS 会在本地生成版本库，集中式 / 分布式 VCS 会将版本数据同步到服务端 / 远程仓库，即使本地文件丢失、设备损坏，也能从版本库 / 远程仓库中完整恢复项目所有历史版本，实现数据容灾。
（三）常见的版本控制系统
最初是这两个，后面就演化出了熟悉的github等
（四） 常见的软件部署模式
蓝绿部署（Blue-green Deployments）
- 核心原理：维护两套完全相同的生产环境（蓝环境 = 旧版本，绿环境 = 新版本）。先在绿环境部署新版本并验证，确认无误后，通过流量切换（如 DNS、负载均衡）将所有用户流量一次性切到绿环境。如果出现问题，可瞬间切回蓝环境。
- 适用场景：需要零停机发布、对服务可用性要求极高的场景，适合中小型服务或状态无依赖的应用。
- 优点：发布与回滚都非常迅速，用户无感知；新旧版本完全隔离，风险可控。
- 缺点：需要双倍的服务器资源，成本较高；对环境一致性要求高，若涉及数据库等有状态组件，数据同步会比较复杂。
2. 金丝雀（灰度）发布（Canary Deployment）
- 核心原理：先将新版本推送给一小部分用户（比如 1%–5%），验证新版本的稳定性和性能。如果无异常，再逐步扩大用户比例（如 10%→30%→100%），直到全量用户切换到新版本。
- 适用场景：大型服务、用户量较大的场景，希望逐步验证风险，避免全量发布故障影响所有用户。
- 优点：风险可控，问题仅影响小范围用户；无需额外的完整环境，资源成本较低；可在发布过程中收集真实用户反馈。
- 缺点：发布周期较长；需要流量分割和用户分组能力；若新版本有问题，可能需要回滚已推送的部分用户。
3. 滚动发布（Rolling Deployment）
- 核心原理：按批次逐步替换旧版本的服务器实例。例如，将 10 台服务器分成 3 批，先更新 2 台，验证无误后再更新 3 台，最后更新剩余 5 台，直到所有实例都切换到新版本。
- 适用场景：资源有限、无法支撑蓝绿部署的场景，适合无状态或状态可平滑迁移的服务。
- 优点：无需额外资源，成本低；发布过程平稳，对用户影响较小。
- 缺点：发布过程中存在新旧版本共存的情况，可能引发兼容性问题；回滚速度较慢，需要反向分批操作；若中间出现问题，会导致部分用户使用旧版本、部分使用新版本。
4. A/B 测试（A/B Testing）
- 核心原理：并非传统意义上的 “发布”，而是同时运行两个或多个版本（A 版和 B 版），给不同用户群体展示不同版本，通过收集用户行为数据（如转化率、留存率）来对比效果，目的是验证功能价值或用户体验优化，而非部署新版本。
- 适用场景：产品功能迭代、UI 优化、营销策略验证等，需要基于数据做决策的场景。
- 优点：可以量化不同版本的效果，驱动数据化决策；风险低，仅影响测试用户。
- 缺点：需要专业的流量分流和数据埋点能力；若测试周期长，可能导致用户体验不一致。
三、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网站等
利用远程仓库，可以实现异地备份和远程协作
（一）Linux 安装 git，常见命令
官方：https://git-scm.com/download/linux
1.包安装
root@ubuntu11:~ apt-get install git 2.常见命令
（二）Git 案例
1.创建项目并初始化配置
root@ubuntu11:~ mkdir myapp root@ubuntu11:~ cd myapp/ 初始化 root@ubuntu11:~/myapp git init root@ubuntu11:~/myapp ls -a . .. .git #设置git，提交commit之前需要先配置git的基本信息
#选项--system 表示针对所有用户的配置,保存在/etc/gitconfig文件中
#选项--global 表示当前用户环境,保存在~/.gitconfig文件中,推荐使用
#选项--local 表示只针对当前目录(项目)的配置,保存在当前目录的.git/config文件中，此为默认值，可省略
#优先级:local > global > system
一般都是用global
标记是谁邮箱是什么 root@ubuntu11:~ git config --global user.name lty root@ubuntu11:~ git config --global user.email [email protected] root@ubuntu11:~ git config -l user.name=lty [email protected] root@ubuntu11:~ cat .gitconfig [user] name = lty email = [email protected] 2. 添加暂存区并提交数据
假如创建了一个java文件
root@ubuntu11:~/myapp cat hello.java hello.world v1.0 root@ubuntu11:~/myapp git add hello.java root@ubuntu11:~/myapp git status 位于分支 master 尚无提交 要提交的变更： （使用 "git rm --cached <文件>..." 以取消暂存） 新文件： hello.java 查看暂存区 root@ubuntu11:~/myapp git ls-files hello.java 提交当前目录到暂存区 root@ubuntu11:~/myapp git add . 添加缓存并提交 root@ubuntu11:~/myapp git add hello.java root@ubuntu11:~/myapp git commit -m 'v3.0' [master c059438] v3.0 1 file changed, 1 insertion(+), 1 deletion(-) 以上两个命令可以通过以下命令实现，但是必须是已经提交过的不是新的文件 root@ubuntu11:~/myapp cat hello.java hello.world v4.0 root@ubuntu11:~/myapp git commit -am 'v4.0' [master df13be7] v4.0 1 file changed, 1 insertion(+), 1 deletion(-) 3.设置忽略文件
root@ubuntu11:~/myapp cat .gitignore /bin /target .classpath .project .settings *.h !test.h *.py[c|x] 4. 将文件加入暂存区再取消添加
root@ubuntu11:~/myapp git add f1.txt root@ubuntu11:~/myapp git ls-files f1.txt hello.java root@ubuntu11:~/myapp git status 位于分支 master 要提交的变更： （使用 "git restore --staged <文件>..." 以取消暂存） 新文件： f1.txt 未跟踪的文件: （使用 "git add <文件>..." 以包含要提交的内容） .gitignore 删除 方法一： root@ubuntu11:~/myapp git rm --cached f1.txt rm 'f1.txt' 方法二： root@ubuntu11:~/myapp git restore --staged f1.txt 验证 root@ubuntu11:~/myapp git status 位于分支 master 未跟踪的文件: （使用 "git add <文件>..." 以包含要提交的内容） .gitignore f1.txt 提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪） root@ubuntu11:~/myapp git ls-files hello.java 5.利用暂存区恢复误删除的工作区文件
提交暂存区 root@ubuntu11:~/myapp touch test.txt root@ubuntu11:~/myapp git add . root@ubuntu11:~/myapp git ls-files .gitignore f1.txt hello.java test.txt root@ubuntu11:~/myapp rm -f test.txt root@ubuntu11:~/myapp ls f1.txt hello.java 从暂存区复制文件到工作目录，两种方式 root@ubuntu11:~/myapp git restore test.txt root@ubuntu11:~/myapp git checkout test.txt 从索引区更新了 0 个路径 root@ubuntu11:~/myapp ls f1.txt hello.java test.txt 6.同时删除工作区和暂存区
git rm -f f2.txt7.回滚工作区的文件为暂存区中版本
root@ubuntu11:~/myapp echo v1 > f1.txt root@ubuntu11:~/myapp git status 位于分支 master 要提交的变更： （使用 "git restore --staged <文件>..." 以取消暂存） 新文件： .gitignore 新文件： f1.txt 新文件： test.txt 尚未暂存以备提交的变更： （使用 "git add <文件>..." 更新要提交的内容） （使用 "git restore <文件>..." 丢弃工作区的改动） 修改： f1.txt root@ubuntu11:~/myapp git add . root@ubuntu11:~/myapp echo v2 > f1.txt root@ubuntu11:~/myapp# git status 位于分支 master 要提交的变更： （使用 "git restore --staged <文件>..." 以取消暂存） 新文件： .gitignore 新文件： f1.txt 新文件： test.txt 尚未暂存以备提交的变更： （使用 "git add <文件>..." 更新要提交的内容） （使用 "git restore <文件>..." 丢弃工作区的改动） 修改： f1.txt 回滚 root@ubuntu11:~/myapp git checkout -- f1.txt root@ubuntu11:~/myapp cat f1.txt v1 8.多次提交后回滚至指定提交的版本
（1）git reset
git reset
--soft #工作目录和暂存区都不会被改变，只是本地仓库中的文件回滚到指定的版本，仅移动 HEAD和master指针的指向，不会重置暂存区或工作区
--mixed #默认选项。回滚暂存区和本地仓库，但工作目录不受影响
--hard #本地仓库,暂存区和工作目录都回滚到指定的提交,该选项非常危险
git reset --soft HEAD~ 执行的效果
git reset --soft HEAD~ 执行的效果
git reset --hard HEAD~ 执行的效果
（2）git revert
这个相比上个可以保留历史，从内容来说确实回退了但是从逻辑来说是一个新的文件上传了
git revert HEAD #撤销前一次commit,会交互式打开文本编辑器提示输入提交信息
git revert HEAD --no-edit #非交互式撤销前一次提交
git revert HEAD^ #撤销前前一次commit
git revert <commitid> #撤销指定的版本，撤销也会作为一次提交进行保存
9.创建分支和合并分支
查看当前分支状态
root@ubuntu11:~/myapp git branch * master 只创建分支不切换
root@ubuntu11:~/myapp git branch dev切换分支
root@ubuntu11:~/myapp git checkout dev A .gitignore A f1.txt A test.txt 切换到分支 'dev' #创建并切换新分支dev root@ubuntu11:~/myapp git checkout -b dev（1）快进式合并：切换分支至dev分支，此分支为被合并的目标分支
root@ubuntu11:~/myapp git checkout dev A .gitignore A f1.txt A test.txt 切换到分支 'dev' 合并dev分支到当前分支master
交互式合并
root@ubuntu11:~/myapp git merge dev 更新 df13be7..5eb0533 Fast-forward .gitignore | 8 ++++++++ f1.txt | 1 + hello.java | 2 +- test.txt | 0 4 files changed, 10 insertions(+), 1 deletion(-) create mode 100644 .gitignore create mode 100644 f1.txt create mode 100644 test.txt 三路合并：平行分支(有多次独立的提交的多个分支)中因为不同分支中同一个文件内容不同,会出现冲突,需要手动解决冲突,并重新add和commit
（2）修改分支名称
想改哪个分支的名称需要先进入相应的分支中
root@ubuntu11:~/myapp git branch dev * master root@ubuntu11:~/myapp git checkout dev 切换到分支 'dev' root@ubuntu11:~/myapp git branch -M devel root@ubuntu11:~/myapp git branch * devel master 10.当前状态打 tag 并利用 tag 回滚
命令：git tag
git tag v1.0
git push origin v1.0 #推送单个标签
git push origin --tags #提交全部新建标签给远程仓库
root@ubuntu11:~/myapp echo v1.0 > a.txt;git add .;git commit -m v1.0 [devel 08a1902] v1.0 1 file changed, 1 insertion(+) create mode 100644 a.txt root@ubuntu11:~/myapp cat a.txt v1.0 root@ubuntu11:~/myapp git tag v1.0 root@ubuntu11:~/myapp git tag v1.0 root@ubuntu11:~/myapp echo v2.0 > a.txt;git add .;git commit -m v2.0 [devel 4e16df4] v2.0 1 file changed, 1 insertion(+), 1 deletion(-) root@ubuntu11:~/myapp git tag v2.0 root@ubuntu11:~/myapp git tag v1.0 v2.0 root@ubuntu11:~/myapp git show v1.0 root@ubuntu11:~/myapp git log commit 4e16df4f494ed92f4c6064ad43f41be8a477181d (HEAD -> devel, tag: v2.0) Author: lty <[email protected]> Date: Mon Feb 2 11:39:02 2026 +0800 v2.0 commit 08a1902aac496b12e9e83578d825a156d4f89535 (tag: v1.0) Author: lty <[email protected]> Date: Mon Feb 2 11:38:39 2026 +0800 v1.011.本地代码提交给公有云仓库码云
root@ubuntu11:~/myapp git remote add origin https://gitee.com/heyibushuoh/myapp.git # git remote add origin是对这个仓库起名 root@ubuntu11:~/myapp git remote -v origin https://gitee.com/heyibushuoh/myapp.git (fetch) origin https://gitee.com/heyibushuoh/myapp.git (push)提交代码
root@ubuntu11:~/myapp git push -u origin master #把 origin 设置成默认的提交仓库，提交master节点 Username for 'https://gitee.com': heyibushuoh #账户 Password for 'https://[email protected]': #密码 枚举对象中: 15, 完成. 对象计数中: 100% (15/15), 完成. 使用 4 个线程进行压缩 压缩对象中: 100% (6/6), 完成. 写入对象中: 100% (15/15), 1.02 KiB | 348.00 KiB/s, 完成. 总共 15（差异 0），复用 0（差异 0），包复用 0 remote: Powered by GITEE.COM [1.1.23] remote: Set trace flag fb433ba4 To https://gitee.com/heyibushuoh/myapp.git * [new branch] master -> master 分支 'master' 设置为跟踪 'origin/master'。 推送标签
root@ubuntu11:~/myapp git push --tags Username for 'https://gitee.com': heyibushuoh Password for 'https://[email protected]': 枚举对象中: 7, 完成. 对象计数中: 100% (7/7), 完成. 使用 4 个线程进行压缩 压缩对象中: 100% (4/4), 完成. 写入对象中: 100% (6/6), 469 字节 | 469.00 KiB/s, 完成. 总共 6（差异 2），复用 0（差异 0），包复用 0 remote: Powered by GITEE.COM [1.1.23] remote: Set trace flag 0a4c3a9f To https://gitee.com/heyibushuoh/myapp.git * [new tag] v1.0 -> v1.0 * [new tag] v2.0 -> v2.0 四、私有软件仓库 GitLab
（一）安装下载
官方说明：https://docs.gitlab.com/install/package/ubuntu/?tab=Enterprise+Edition
安装软件
root@ubuntu16:~ apt install ./gitlab-ce_18.6.4-ce.0_amd64.deb root@ubuntu16:~ vim /etc/gitlab/gitlab.rb …… ##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html external_url 'http://gitlab.lty.com' #改成要使用的域名 …… 执行生效命令 gitlab-ctl reconfigure域名解析
默认的账户是root，默认密码在
root@ubuntu16:~ cat /etc/gitlab/initial_root_password （二）软件管理
改语言
取消注册权限，方便自己管理账号
邀请成员
可以对默认仓库改名重设，推送内容和标签进仓库
root@ubuntu11:~/myapp git remote origin root@ubuntu11:~/myapp git remote rename origin old-origin 正在重命名远程引用: 100% (1/1), 完成. root@ubuntu11:~/myapp git remote old-origin root@ubuntu11:~/myapp git remote -v old-origin https://gitee.com/heyibushuoh/myapp.git (fetch) old-origin https://gitee.com/heyibushuoh/myapp.git (push) root@ubuntu11:~/myapp git remote add origin http://gitlab.lty.com/lty/devops.git root@ubuntu11:~/myapp vim /etc/hosts #做域名解析，机器多的话建议配置DNS服务器 root@ubuntu11:~/myapp git push --set-upstream origin --all #设置为默认仓库 root@ubuntu11:~/myapp git push --set-upstream origin --tags #推送标签 Username for 'http://gitlab.lty.org': xiaoming Password for 'http://[email protected]': 总共 0（差异 0），复用 0（差异 0），包复用 0 To http://gitlab.lty.org/lty/devops.git * [new tag] v1.0 -> v1.0 * [new tag] v2.0 -> v2.0 
在lty账号上也可以看到同步的内容
克隆到10.0.0.10主机
root@ubuntu10:~/myapp git clone http://gitlab.lty.org/lty/devops.git 正克隆到 'devops'... Username for 'http://gitlab.lty.org': xiaoming Password for 'http://[email protected]': remote: Enumerating objects: 24, done. remote: Counting objects: 100% (24/24), done. remote: Compressing objects: 100% (12/12), done. remote: Total 24 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0) 接收对象中: 100% (24/24), 4.10 KiB | 4.10 MiB/s, 完成. 处理 delta 中: 100% (2/2), 完成. root@ubuntu10:~/myapp cd devops/ root@ubuntu10:~/myapp/devops git tag v1.0 v2.0 看不到分支但其实是存在的 root@ubuntu10:~/myapp/devops git checkout master 分支 'master' 设置为跟踪 'origin/master'。 切换到一个新分支 'master' root@ubuntu10:~/myapp/devops git branch main * master root@ubuntu10:~/myapp/devops git checkout devel 分支 'devel' 设置为跟踪 'origin/devel'。 切换到一个新分支 'devel' root@ubuntu10:~/myapp/devops git branch * devel main master 推送到仓库
root@ubuntu10:~/myapp/devops vim test.txt test.txt root@ubuntu10:~/myapp/devops git commit -am test.txt root@ubuntu10:~/myapp/devops git push --all 
注意：默认分支开发者是没有权限做修改的
1.使用SSH连接
在gitlab主机上生成公钥密钥对
ssh-keygen将 .ssh 目录下的 id_ed25519.pub 公钥文件内容复制到某个账号的这里，那么这台主机就和这个账号关联到一起了
2.其他仓库上传到本仓库
（三）GitLab 的数据备份和恢复
备份配置文件命令；本地备份了最好把这个文件放到远程服务器上做备份
gitlab-ctl backup-etc #备份配置文件 root@ubuntu16:~ ls /etc/gitlab/ config_backup/ gitlab.rb gitlab-secrets.json initial_root_password trusted-certs/ root@ubuntu16:~ ls /etc/gitlab/config_backup/ gitlab_config_1770088913_2026_02_03.tar root@ubuntu16:~ tar tvf /etc/gitlab/config_backup/gitlab_config_1770088913_2026_02_03.tar tar: 从成员名中删除开头的“/” drwxrwxr-x root/root 0 2026-02-03 11:21 /etc/gitlab/ drwxr-xr-x root/root 0 2026-02-02 19:34 /etc/gitlab/trusted-certs/ -rw------- root/root 160135 2026-02-03 10:07 /etc/gitlab/gitlab.rb -rw------- root/root 745 2026-02-02 19:34 /etc/gitlab/initial_root_password -rw------- root/root 16499 2026-02-03 10:07 /etc/gitlab/gitlab-secrets.json 1.手动备份数据文件
gitlab-backup create 默认的备份地址：/var/opt/gitlab/backups/ 配置文件中可以改路径 root@ubuntu16:~ vim /etc/gitlab/gitlab.rb …… ### Backup Settings ###! Docs: https://docs.gitlab.com/omnibus/settings/backups.html # gitlab_rails['manage_backup_path'] = true # gitlab_rails['backup_path'] = "/var/opt/gitlab/backups" # gitlab_rails['backup_gitaly_backup_path'] = "/opt/gitlab/embedded/bin/gitaly-backup" ……2.执行恢复
恢复前先停止两个服务
root@ubuntu16:~ gitlab-ctl stop puma ok: down: puma: 0s, normally up root@ubuntu16:~ gitlab-ctl stop sidekiq ok: down: sidekiq: 0s, normally up 恢复时指定备份文件的时间部分，不需要指定文件的全名
root@ubuntu16:~ gitlab-backup restore BACKUP=1770089118_2026_02_03_18.6.4重启服务
gitlab-ctl reconfigure gitlab-ctl restart（四）实现 Https
创建证书
mkdir -p /etc/gitlab/ssl && cd /etc/gitlab/ssl openssl genrsa -out gitlab.lty.org.key 2048 openssl req -days 3650 -x509 \修改配置文件
[root@gitlab ~] vim /etc/gitlab/gitlab.rb external_url "https://gitlab.wang.org" #此项必须修改为https，必选项，还原为http时，只修改此行即可 nginx['enable'] = true #可选 nginx['client_max_body_size'] = '1000m' #可选 nginx['redirect_http_to_https'] = true #必选项，默认值为false，修改为true，实现http自动301跳转至https，，还原为http时，无需修改此行 nginx['redirect_http_to_https_port'] = 80 #可选,所有请求80的都跳转到443，默认值，可不修改，保持注释状态 nginx['ssl_certificate'] ="/etc/gitlab/ssl/gitlab.wang.org.crt" #必选项 nginx['ssl_certificate_key'] ="/etc/gitlab/ssl/gitlab.wang.org.key" #必选项 nginx['ssl_ciphers'] = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256" #可选 nginx['ssl_prefer_server_ciphers'] = "on" #可选 nginx['ssl_protocols'] = "TLSv1.2" #可选 nginx['ssl_session_cache'] = "shared:SSL:10m" #可选 nginx['ssl_session_timeout'] = "1440m" #可选重新初始化
gitlab-ctl reconfigure由于自签名证书不信任，访问出下面错误
git clone http://gitlab.lty.org/devops/myai.git 正克隆到'myai' ... fatal:无法访问'http://gitlab.lty.org/ devops/myai.git/ ': server certificate verification failed.CAfile: none CRLfile: none在使用git客户端的主机上信任自签名证书，把证书文件给想克隆仓库文件的主机，再把证书文件内容追加到 /etc/ssl/certs/ca-certificates.crt 文件的最后
scp gitlab-server:/etc/gitlab/ssl/gitlab.lty.org.crt . cat gitlab.lty.org.crt >> /etc/ssl/certs/ca-certificates.crt 红帽系统证书路径 /etc/pki/tls/certs/ca-bundle.crt（五）重置 GitLab 忘记的密码
官方文档：https://docs.gitlab.com/ee/security/reset_user_password.html#reset-the-root-password
root@ubuntu16:~ gitlab-rails console -e production -------------------------------------------------------------------------------- Ruby: ruby 3.2.8 (2025-03-26 revision 13f495dc2c) [x86_64-linux] GitLab: 18.6.4 (2bcd6614856) FOSS GitLab Shell: 14.45.3 PostgreSQL: 16.10 ------------------------------------------------------------[ booted in 39.26s ] Loading production environment (Rails 7.1.6) irb(main):001> User.find_by_username 'root' #账户是root irb(main):002> user.password="L!@#$%^l" #重新设置密码 irb(main):003> user.password_confirmation="L!@#$%^l" #二次确认 irb(main):004> user.save #保存 => true 修改完成
