# Git 安装

该章节包括 Git 以及与 Git 相关的一些工具的安装，例如 GitLab 的部署配置等。

# 参考文档

# GitLab 安装配置

# Linux 安装

# Docker 安装

启动容器：

docker run -id \
# --hostname 配置容器的主机名称，gitlab 如果不配置服务地址，默认可能会使用 hostname 配置。
--hostname=172.16.5.11 \
# 端口映射，-p 80:80 可以简写 -p 80
# 443 https 80 http 22 ssh
-p 443:443 -p 80:80 -p 5622:22 \ 
--name gitlab-ce \
# 将数据卷映射到 /srv 服务目录下
-v /srv/docker/gitlab/config/:/etc/gitlab  \ 
-v /srv/docker/gitlab/logs:/var/log/gitlab  \
-v /srv/docker/gitlab/data/:/var/opt/gitlab   \
# 以只读（ro）方式绑定宿主机与容器时间
-v /etc/localtime:/etc/localtime:ro \
# 镜像名
gitlab/gitlab-ce:17.7.0-ce.0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# GitLab 备份与恢复

这两个命令用于 docker 部署时

gitlab-backup create 即 docker exec -t gitlab-ce gitlab-backup create

gitlab-bakcup restore BACKUP=[timestamp] 即 docker exec -t gitlab-ce gitlab-bakcup restore BACKUP=[timestamp]

手动创建一次备份（用于验证命令是否正常工作）

使用 docker exec 命令进入容器并执行备份：
```
docker exec -t gitlab-ce gitlab-backup create
```
1
这将在容器内的 /var/opt/gitlab/backups/ 目录下创建一个备份文件。
将备份文件保存到主机

因为你的容器已经挂载了卷 /srv/docker/gitlab/data/:/var/opt/gitlab，所以任何在容器内 /var/opt/gitlab/backups/ 下创建的文件都会自动同步到主机的 /srv/docker/gitlab/data/backups/ 目录。
设置定时任务

在 Docker 主机上编辑 crontab 文件，添加一个定时任务来每天创建一次备份：
```
crontab -e
```
1
添加一行类似以下内容（假设你想每天凌晨2点执行备份）：
```
0 2 * * * docker exec -t gitlab-ce gitlab-backup create CRON=1
```
1
CRON=1 参数会使得输出更简洁，并且不会发送邮件通知。

在GitLab的配置文件/etc/gitlab/gitlab.rb中，有专门用于配置备份设置的部分。这些设置可以影响到备份的位置、频率以及保留策略等。以下是一些常用的与备份相关的配置项：

备份存储位置

默认情况下，GitLab会将备份文件保存在容器内部的 /var/opt/gitlab/backups/ 目录下。如果您想改变这个位置，可以通过如下配置来指定一个新的路径（注意：此路径必须是主机上的一个目录，并且需要通过Docker卷挂载到容器中）：

gitlab_rails['backup_path'] = "/mnt/backup"

备份频率和时间

GitLab本身并不直接控制备份的频率或时间，这通常由外部调度器（如cron）来管理。但是，您可以在脚本中使用gitlab-backup create命令来触发备份。

自动清理旧备份

您可以配置自动删除过期的备份文件，以避免磁盘空间被过多占用。以下是配置项示例，它表示只保留最近的5个备份文件：

gitlab_rails['backup_keep_time'] = 604800 # 单位为秒, 这里表示7天

请注意，backup_keep_time 配置项指的是创建备份后的时间间隔，在超过该时间间隔之后，备份文件将会被标记为可删除。实际上的删除操作是在新的备份创建时执行的。

备份压缩

为了节省空间，您可以启用备份文件的压缩功能：

gitlab_rails['backup_tar_options'] = '--gzip'

使用S3或其他云存储进行备份

如果您希望将备份文件上传到Amazon S3或其他支持的对象存储服务上，可以配置相关参数：

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => 'AKIAKIAKI',
  'aws_secret_access_key' => 'secret123'
}
gitlab_rails['backup_upload_remote_directory'] = 'my-s3-bucket'

1
2
3
4
5
6
7

请确保替换上述代码中的占位符为您自己的云存储凭据和信息。

应用更改

修改完gitlab.rb文件后，请记得运行以下命令使配置生效：

sudo gitlab-ctl reconfigure

以上就是一些关于GitLab备份配置的关键点。根据您的具体需求调整配置，并确保定期测试备份和恢复过程，以保证其有效性。如果还有其他问题或者需要进一步的帮助，请随时告知！

# 恢复步骤

当需要从备份中恢复时，请确保停止所有访问 GitLab 的流量，并且在恢复前停掉 GitLab 容器。

停止 GitLab 容器
```
docker stop gitlab-ce
```
1
执行恢复命令

找到你想用来恢复的备份文件，它应该位于 /srv/docker/gitlab/data/backups/。然后，启动容器并立即进入容器执行恢复命令：
```
docker start gitlab-ce && sleep 5 && docker exec -it gitlab-ce gitlab-backup restore BACKUP=timestamp_of_backup
```
1
把 timestamp_of_backup 替换为实际的备份文件名（不包括扩展名）。例如，如果文件名为 1672876800_gitlab_backup.tar，那么你应该指定 BACKUP=1672876800。
重启 GitLab

恢复完成后，重新启动 GitLab 服务：
```
docker restart gitlab-ce
```
1

请务必在执行这些操作之前阅读官方文档，因为 GitLab 的版本更新可能会引入新的特性或更改现有的行为。此外，建议在非生产环境中测试备份和恢复过程，以确保一切按预期工作。

容器内恢复操作

如果 exec 进入容器内部进行恢复数据，恢复前需要先停止puma和sidekiq服务。

gitlab-ctl stop puma
gitlab-ctl stop  sidekiq
gitlab-ctl status
# puma服务:是一个用于 Ruby 应用程序的简单、快速、多线程和高度并发的HTTP 1.1服务器。
# sidekiq服务:存储用户在后台执行队列任务(异步执行)

1
2
3
4
5

# 讨论区

由于评论过多会影响页面最下方的导航，故将评论区做默认折叠处理。

点击查看评论区内容，渴望您的宝贵建议~

← Git 进阶