GitLab
一、gitlab部署与使用
https://about.gitlab.com/install/ #Gitlab服务的安装文档
https://docs.gitlab.com/ce/install/requirements.html #安装环境要求
1.1 下载并部署gitlab
1.1.1 Ubuntu系统环境准备
服务器内存4G以上
1.1.1.1 配置Ubuntu远程连接
jack@ubuntu:~S sudo su - root
[sudo] password for jack:
root@ubuntu:~# passwd
Enter new UNlX password:
Retype new UNlX password:
passwd:password updated successfully
root@ubuntu:~#vim/etc/ssh/sshd config
PermitRootLogin yes
PasswordAuthentication yes
1.1.1.2 配置Ubuntu网卡和主机名
root@ubuntu:~# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
addresses: [192.168.8.2/21]
gateway4: 192.168.15.254
nameservers:
addresses: [192.168.15.254]
root@ubuntu:~#cat/etc/hostname
ienkins.example.com
root@ubuntu:~#reboot
1.1.1.3 安装gitlab
（1）配置Ubuntu仓库
首先信任 GitLab 的 GPG 公钥：
curl -fsSL https://packages.gitlab.com/gpg.key | gpg --dearmor -o /usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg
再选择你的 Debian/Ubuntu 版本，将下方内容写入 /etc/apt/sources.list.d/gitlab-ce.list
deb [signed-by=/usr/share/keyrings/gitlab_gitlab-ce-archive-keyring.gpg] https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu focal main
安装 gitlab-ce:
apt-get update
apt-get install gitlab-ce
（2）下载deb包
安装deb包
dpkg -i gitlab-ce_13.12.9-ce.0_amd64.deb
1.1.2 gitlab配置使用
root@wang:~# grep "^[a-Z]" /etc/gitlab/gitlab.rb
external_url 'http://172.16.1.31'
#可选邮件通知设置
gitlab rails['smtp_enable']= true
gitlab rails['smtp_address']="smtp.163.com'
gitlab _rails['smtp_port']= 465
gitlab_rails['smtp_user_name"]="w719429082@163.com'
gitlab rails['smtp_password']="zdhudwexecjbdhda"
gitlab rails['smtp_domain']="163.com"
gitlab _rails['smtp_authentication']= "login"
gitlab rails['smtp_enable_starttls_auto']= true
gitlab rails['smtp_tls']= true
gitlab rails['gitlab_email_from']="w719429082@163.com"
user["git_user_email"]="w719429082@163.com"
1.1.3初始化服务
执行配置并启动服务
gitlab-ctl reconfigure #修改完配置文件要执行此操作
gitlab相关的目录有哪些
/etc/gitlab #配置文件目录
/run/gitlab #运行pid目录
/opt/gitlab #安装目录
/var/log/gitlab #数据目录
1.1.4 常用命令
gitlab-rails #用于启动控制台进行特殊操作，比如修改管理员密码、打开数据库控制台（gitlab-rails dbconsole）等
gitlab-rake #数据备份恢复等数据操作
gitlab-ctl #客户端命令行操作行
gitlab-ctl stop #停止 gitlab
gitlab-ctl start #启动 gitlab
gitlab-ctl restar #重启 gitlab
gitlab-ctl status #查看组件运行状态
1.1.5 gitlab使用
1.1.5.1 常用的git命令
git config-global user.name "name" #设置全局用户名
git config-global user.email xxx@xx.com #设置全局邮箱
gitconfig--global -list#列出用户全局设置
git add index.html/.#添加指定文件、目录或当前目录下所有数据到暂存区
gitcommit-m “v1“#提交文件到工作区
git status #查看工作区的状态
git push #提交代码到服务器
git pull #获取代码到本地
git log #查看操作日志vim.gitignore #定义忽略文件上传至gitlab
git reset --hard HEAD^^#git版本回滚， HEAD为当前版本，加一个^为上一个，“^为上上一个版本
git reflog ##获取每次提交的ID，可以使用--hard根据提交的ID进行版本回退
git reset--hard 5ae4b06 #回退到指定 id 的版本
git branch #查看当前所处的分支
git checkout-b develop #创建并切换到一个新分支#git checkoutdevelop #切换分支
1.1.5.2 git缓存区与工作区等概念
工作区:clone的代码或者开发自己编写的代码文件所在的目录，通常是代码所在的个服务的目录名称。
暂存区:用于存储在工作区中对代码进行修改后的文件所保存的地方，使用gitadd添加。
本地仓库:用于提交存储在工作区和暂存区中改过的文件地方，使用gitcommit提交远程仓库:多个开发共同协作提交代码的仓库，即gitlab服务器
1.1.6 gitlab数据备份恢复
1.1.6.1备份内容
默认备份包括：
- 数据库（PostgreSQL）
- 仓库（Git 代码）
- 用户上传文件（如 CI 日志、LFS 文件）
- CI/CD 流水线数据
- 配置文件（需手动备份
/etc/gitlab/gitlab-secrets.json和/etc/gitlab/gitlab.rb）
1.1.6.2 停止gitlab数据服务
gitlab-ctl stop unicorn (gitlab13.0之前版本)
gitlab-ctl stop puma (gitlab13.0及之后版本)
gitlab-ctl stop sidekiq
- GitLab 12.6（2019年11月）
首次实验性支持 Puma，用户可通过手动配置启用，但 Unicorn 仍是默认选项。 - GitLab 12.10（2020年4月）
官方宣布将在 13.0 版本中将默认应用服务器从 Unicorn 切换为 Puma，并计划逐步淘汰 Unicorn。 - GitLab 13.0（2020年5月）
Puma 正式成为默认 Web 服务器，Unicorn 被默认禁用。用户需手动迁移自定义的 Unicorn 配置至 Puma。 - GitLab 14.0（2021年6月）
Unicorn 从 Linux 软件包中完全移除，仅支持 Puma。
1.1.6.3 手动备份数据
gitlab-rake gitlab:backup:create #在任意目录即可备份当前gitlab数据
通过添加参数定制备份行为：
| 参数 | 作用 | 示例 |
|---|---|---|
BACKUP=备份目录名 |
指定备份文件存储目录 | sudo gitlab-rake gitlab:backup:create BACKUP=/mnt/backups |
SKIP=组件名 |
跳过指定组件（如 db, uploads 等） |
sudo gitlab-rake gitlab:backup:create SKIP=repositories,uploads |
STRATEGY=copy |
使用直接文件复制（替代 tar 打包） |
sudo gitlab-rake gitlab:backup:create STRATEGY=copy |
1.1.6.4 查看要恢复的文件
/var/opt/gitlab/backups/ #gitlab数据备份目录，需要使用命令备份的（默认备份数据存储路径）
/var/opt/gitlab/nginx/conf #nginx配置文件
/etc/gitlab/gitlab.rb #gitlab配置文件
/etc/gitlab/gitlab-secrets.json #key文件
1.1.6.5 修改 /etc/gitlab/gitlab.rb 配置文件以优化备份策略：
# 备份路径（默认: /var/opt/gitlab/backups）
gitlab_rails['backup_path'] = "/mnt/gitlab-backups"
# 备份保留时间（秒，默认 7天=604800）
gitlab_rails['backup_keep_time'] = 2592000 # 30天
# 启用上传到远程存储（如 AWS S3）
gitlab_rails['backup_upload_connection'] = {
provider: 'AWS',
aws_access_key_id: 'AKIAXXX',
aws_secret_access_key: 'secretXXX',
region: 'us-east-1'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups'
1.1.6.6 执行恢复
#停止服务
root@wang:~# gitlab-ctl stop puma
ok: down: puma: 1s, normally up
root@wang:~# gitlab-ctl stop sidekiq
ok: down: sidekiq: 0s, normally up
root@wang:~# ll /var/opt/gitlab/backups/
total 500
drwxr-xr-x 2 git git 4096 May 18 14:35 ./
drwxr-xr-x 21 root root 4096 May 18 14:31 ../
-rw------- 1 git git 501760 May 18 14:35 1747578932_2025_05_18_16.11.9_gitlab_backup.tar
root@wang:~# gitlab-rake gitlab:backup:restore BACKUP=1747578932_2025_05_18_16.11.9
...
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes
...
#确认恢复数据
2025-05-18 15:01:47 UTC -- Restoring ci secure files ...
2025-05-18 15:01:47 UTC -- Restoring ci secure files ... done
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes
#恢复完成启动服务
root@wang:~# gitlab-ctl start sidekiq
ok: run: sidekiq: (pid 21732) 0s
root@wang:~# gitlab-ctl start puma
ok: run: puma: (pid 21753) 0s
1.2 常见代码部署方式
1.2.1 蓝绿部署
蓝绿部署指的是不停老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。
具体过程
1、当前版本业务正常访问(V1)
2、在另外一套环境部署新代码(V2)，代码可能是增加了功能或者是修复了某些 bug
3、测试通过之后将用户请求流量切到新版本环境
4、观察一段时间，如有异常直接切换旧版本
5、下次升级，将旧版本升级到新版本(V3)
蓝绿部署使用场景
1、不停止老版本，额外部署一套新版本，等测试发现新版本OK后，删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
1.2.2 金丝雀发布
金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。
金丝雀发布（灰度发布）步骤组成
1、准备好部署各个阶段的工件，包括:构建工件，测试脚本，配置文件和部署清单文件。
2、从负载均衡列表中移除掉“金丝雀”服务器。
3、升级“金丝雀”应用(排掉原有流量并进行部署)。
4、对应用进行自动化测试。
5、将“金丝雀”服务器重新添加到负载均衡列表中(连通性和健康检查)。
6、如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。(否则就回滚)灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
金丝雀发布（灰度发布）使用场景
1、不停止老版本，额外搞一套新版本，不同版本应用共存。
2、灰度发布中，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝新版本。
3、经常与 A/B 测试一起使用，用于测试选择多种方案。
1.2.3 滚动发布
滚动发布，一般是取出一个或者多个服务器停止服务,执行更新,并重新将其投入使用周而复始，直到集群中所有的实例都更新成新版本。
1.2.4 A/B测试
A/B测试也是同时运行两个APP环境，但是蓝绿部署完全是两码事，A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等，蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚，即蓝绿部署是一套正式环境环境在线，而A/B测试是两套正式环境在线。
本文来自博客园，作者：原味玉米烙，转载请注明原文链接：https://www.cnblogs.com/yml2024/p/18882941
浙公网安备 33010602011771号