GitLab 最新安装&备份&升级教程（全）
前言
今天介绍下GitLab，一款基于web的Git代码托管平台和源代码管理工具，它提供了类似GitHub的功能，但是具有更多的特性，可以用来管理和协作开发项目。在互联网公司、政务信息化企业、金融科技公司一般都需要建设自己的代码托管平台。GitLab是一个不错的选择，它具备强大的5功能，简洁的界面，可以通过hooks联动Jenkins以及一些项目管理软件，实现一条龙的开发协作流程，个人认为是DevOps的神器。
安装教程
- 官网地址： about.gitlab.com/
- 官方文档：docs.gitlab.com/
关于安装和后期的升级运维，我比较倾向于Docker安装的方式，安装尽量以最少的操作步骤完成任务，保证出错的可能性。
目前官方给出了比较丰富的部署方式来满足不同用户的需求：
- Linux package （通过Linux安装包进行安装）
- Helm chart（Kubernetes的一种安装方式）
- Operator （Kubernetes的另一种安装方式）
- Docker （个人认为相对简单并且可维护性高的方式）
- Self-compiled（需要自行编译源代码）
接下来我讲解的也是Docker部署的方式，在中小型公司推荐，简单方便，维护成本低。
Docker安装
Docker安装也有3种选项：
- 使用Docker Engine 安装，可以使用shell脚本配合docker命令较好的实现安装
- 使用Docker Compose安装，通过docker-compose.yaml进行配置
- 使用Docker Swarm安装，适合多节点访问压力较大的场景
个人喜欢第二种方式，简洁明了（代码洁癖~~）
安装步骤
- 安装Docker Compose。（参考Docker官方文档安装就行）
- 配置
docker-compose.yaml文件。
yaml
version: '3.6'
services:
web:
image: 'gitlab/gitlab-ee:latest'
restart: always
hostname: 'gitlab.example.com'
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'https://gitlab.example.com'
# Add any other gitlab.rb configuration here, each on its own line
ports:
- '80:80'
- '443:443'
- '22:22'
volumes:
- '$GITLAB_HOME/config:/etc/gitlab'
- '$GITLAB_HOME/logs:/var/log/gitlab'
- '$GITLAB_HOME/data:/var/opt/gitlab'
shm_size: '256m'这是官方文档描述的最精简的配置，如果有自定义配置需求（例如https配置、邮件服务、LDAP登录配置等可以参考官方文档中的配置）在GITLAB_OMNIBUS_CONFIG中进行添加。
注意：配置文件中的环境变量
$GITLAB_HOME可以使用下述几种方式：（推荐第三种）
- Bash:
~/.bash_profile- ZSH：
~/.zshrc- GitLab目录下的
.env目录
通过volumes中3个目录挂在到宿主机中，实现GitLab数据的持久化：
| 宿主机路径 | 容器路径 | 用法 |
|---|---|---|
$GITLAB_HOME/data |
/var/opt/gitlab |
存储GitLab运行过程中的数据 |
$GITLAB_HOME/logs |
/var/log/gitlab |
存储日志文件 |
$GITLAB_HOME/config |
/etc/gitlab |
存储GitLab各类配置文件 |
- 在
docker-compose.yaml文件所在目录执行后台启动命令来启动GitLab：
shell
docker compose up -d- 启动完毕后可以查看宿主机文件夹中新增了数据卷中配置的三个文件夹。
shell
➜ gitlab ls
config data docker-compose.yaml logs- 登录查看部署效果：
控制台效果，最新版本右上角相关用户设置功能区已经移动到左侧：
备份恢复教程
由于最早部署GitLab的时候版本是v14.6.1，使用期间遇到一些不知名问题，虽然重启恢复了，但是本着IT男的强迫症，尝试研究升级。
升级前需要准一个备份恢复环境用于升级验证，生产数据需要十分小心。
备份操作
Docker安装方式备份的话直接执行以下docker命令：
shell
docker exec -t <container name> gitlab-backup create执行的时候需要一点时间，需要耐心等待，会有如下类似的输出：
shell
Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
- Dumping table keys... [DONE]
- Dumping table merge_requests... [DONE]
- Dumping table milestones... [DONE]
- Dumping table namespaces... [DONE]
- Dumping table notes... [DONE]
- Dumping table projects... [DONE]
- Dumping table protected_branches... [DONE]
- Dumping table schema_migrations... [DONE]
- Dumping table services... [DONE]
- Dumping table snippets... [DONE]
- Dumping table taggings... [DONE]
- Dumping table tags... [DONE]
- Dumping table users... [DONE]
- Dumping table users_projects... [DONE]
- Dumping table web_hooks... [DONE]
- Dumping table wikis... [DONE]
Dumping repositories:
- Dumping repository abcd... [DONE]
Creating backup archive: $TIMESTAMP_gitlab_backup.tar [DONE]
Deleting tmp directories...[DONE]
Deleting old backups... [SKIPPING]备份的文件是一个tar包，位于配置文件中的backup_path路径中，默认为/var/opt/gitlab/backups，宿主机中为$GITLAB_HOME/data/backups，进入目录可以看到[TIMESTAMP]_gitlab_backup.tar带有时间戳的压缩包，该压缩包包含了所有gitlab运行以来所有的数据。
同时，我们需要备份一下$GITLAB_HOME/config目录中的配置文件以及相关的key、cert、gitlab.rb、gitlab-secrets.json文件，包含了各类配置以及数据库加密秘钥等。
最后docker-compose.yaml文件也要备份一下。
总结：
- 使用命令备份
gitlab运行数据 - 备份配置文件
- 备份
docker-compose.yaml文件 - 不放心可以把整个
GITLAB_HOME文件夹备份下~
恢复操作
准备一个新的宿主机（云服务器、虚拟机、笔记本都行~！）➜ 验证备份文件完整性。
在新的宿主机上准备与生产一致的环境：
GITLAB_HOME文件夹docker-compose.yaml文件- 前面备份的配置文件
[TIMESTAMP]_gitlab_backup.tar文件放回$GITLAB_HOME/data/backups文件夹- 配置文件放回
$GITLAB_HOME/config文件夹
重新启动：
shell
docker compose up -d等docker启动状态由starting➜healthy后执行下述操作：
shell
# Stop the processes that are connected to the database
docker exec -it <name of container> gitlab-ctl stop puma
docker exec -it <name of container> gitlab-ctl stop sidekiq
# Verify that the processes are all down before continuing
docker exec -it <name of container> gitlab-ctl status
# Run the restore. NOTE: "_gitlab_backup.tar" is omitted from the name
docker exec -it <name of container> gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce
# Restart the GitLab container
docker restart <name of container>
# Check GitLab
docker exec -it <name of container> gitlab-rake gitlab:check SANITIZE=true上述操作步骤，简单理解就是停止2个影响恢复的服务，确认下2个服务是否停止，然后将tar包中的数据恢复到新的环境中，然后重启容器，使得之前停止的2个服务恢复，然后检查下整个GitLab的健康状态。打开gitlab确认下数据是否完整，没有问题后可进行升级操作。
升级教程
由于GitLab系统较为复杂庞大，因此升级需要遵循官方的升级路径进行升级，升级前先检查是否与升级路径一致，切记不可直接跨大版本升级，可能会由于数据结构不一致导致无法启动。
因此升级需要遵循官方升级路径的版本顺序依次升级，不可跳过中间版本直接升级，否则会报错无法启动成功。例如我当前的版本是：v14.6.1,我的升级路径如下:
shell
14.9.5 => 14.10.5 => 15.0.5 => 15.4.6 => 15.11.13 => 16.3.1每次更新docker-compose.yaml中的镜像版本号，然后执行：
shell
docker compose up -d确保每次更新版本号启动后进入healthy状态，并且日志输出变缓，只有访问gitlab才有少量请求日志后再进行重复操作，直至版本升级至最新版。
总结
截止教程发表之日，目前最新的release版本为v16.3.0，作者亲身实践从v14.6.1-->v16.3.0，如果遇到困惑的小伙伴可以关注留言，一起探讨~