搭建GitLab仓库

一 GitLab介绍

GitLab 是利用 Ruby on Rails 一个开源的版本管理系统，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。
与 Github 类似，GitLab 能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流

二 GitLib的安装与管理

1 安装

安装依赖包
        [root@ci-node1 git_test]# yum install curl policycoreutils openssh-server openssh-clients policycoreutils-python –y

获取安装包：
        [root@ci-node1 src]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.0.6-ce.0.el7.x86_64.rpm
        [root@ci-node1 src]# rpm -ivh gitlab-ce-10.0.6-ce.0.el7.x86_64.rpm

2 配置

GitLab 的默认配置文件为于：/etc/gitlab/gitlab.rb，修改下图所示的 external_url为本机 IP 地址或者一个可以访问到本机的域名。
修改完主配置文件后，使用 gitlab-ctl reconfigure 重新配置 gitlab

3 启动

重新配置执行成功后，我们就可以启动 Gitlab

[root@ci-node1 src]# gitlab-ctl restart
ok: run: gitaly: (pid 17752) 1s
ok: run: gitlab-monitor: (pid 17768) 0s
ok: run: gitlab-workhorse: (pid 17771) 1s
ok: run: logrotate: (pid 17815) 0s
ok: run: nginx: (pid 17821) 1s
ok: run: node-exporter: (pid 17828) 0s
ok: run: postgres-exporter: (pid 17833) 0s
ok: run: postgresql: (pid 17841) 1s
ok: run: prometheus: (pid 17850) 0s
ok: run: redis: (pid 17858) 1s
ok: run: redis-exporter: (pid 17865) 0s
ok: run: sidekiq: (pid 17871) 0s
ok: run: unicorn: (pid 17880) 0s

在浏览器地址里输入：http://10.0.0.11，出现如图所示页面：首次登录要求我们重新设置 root 用户的密码

4 GitLab 服务构成

GitLab 由主要由以下服务构成，他们共同承担了 Gitlab 的运作需要
Nginx：静态 web 服务器。
gitlab-shell：用于处理 Git 命令和修改 authorized keys 列表。
gitlab-workhorse: 轻量级的反向代理服务器。
logrotate：日志文件管理工具。
postgresql：数据库。
redis：缓存数据库。
sidekiq：用于在后台执行队列任务（异步执行）。
unicorn：An HTTP server for Rack applications，GitLab Rails 应用是托管在这个服务器上面的。
我们可以使用 gitlab-ctl status 命令来查看各服务的状态

5 GitLab 工作流程

GitLab Shell
GitLab Shell 有两个作用：为 GitLab 处理 Git 命令、修改 authorized keys 列表。
当通过 SSH 访问 GitLab Server 时，GitLab Shell 会：

• 限制执行预定义好的 Git 命令（git push, git pull, git annex）
• 调用 GitLab Rails API 检查权限
• 执行 pre-receive 钩子（在 GitLab 企业版中叫做 Git 钩子）
• 执行你请求的动作 处理 GitLab 的 post-receive 动作
• 处理自定义的 post-receive 动作

当通过 http(s)访问 GitLab Server 时，工作流程取决于你是从 Git 仓库拉取(pull)代码还是向 git 仓库推送(push)代码。
如果你是从 Git 仓库拉取(pull)代码，GitLab Rails 应用会全权负责处理用户鉴权和执行 Git 命令的工作；
如果你是向 Git 仓库推送(push)代码，GitLab Rails 应用既不会进行用户鉴权也不会执行 Git 命令，它会把以下工作交由 GitLab Shell 进行处理：

• 调用 GitLab Rails API 检查权限
• 执行 pre-receive 钩子（在 GitLab 企业版中叫做 Git 钩子）
• 执行你请求的动作
• 处理 GitLab 的 post-receive 动作
• 处理自定义的 post-receive 动作

GitLab Workhorse
GitLab Workhorse 是一个敏捷的反向代理。它会处理一些大的 HTTP 请求，比如文件上传、文件下载、Git push/pull 和 Git 包下载。其它请求会反向代理

6 GitLab 常用命令

# 启动所有 gitlab 组件：
   gitlab-ctl start
# 停止所有 gitlab 组件：
   gitlab-ctl stop
# 停止 postgresql 组件：
   gitlab-ctl stop postgresql
# 停止相关数据连接服务
   gitlab-ctl stop unicorn
   gitlab-ctl stop sidekiq
# 重启所有 gitlab 组件：
   gitlab-ctl restart
# 重启 gitlab-workhorse 组件：
   gitlab-ctl restart gitlab-workhorse
# 查看服务状态
   gitlab-ctl status
# 如果更改了主配置文件 [gitlab.rb 文件],使配置文件生效 但是会初始化除了gitlab.rb 之外的所有文件
   sudo gitlab-ctl reconfigure
# 查看日志
   sudo gitlab-ctl tail
# 检查 redis 的日志
   sudo gitlab-ctl tail redis    

 三 Gitlab基本配置

1 关闭注册

由于我们Gitlab系统是私有仓库，一般用户都是由管理员创建和分派的，所以我们需要关闭注册。

 

 2 创建组

group（项目）下面可以创建subgroup，创建project（项目下的具体工程），添加user。group就是把相关的project或者user放在一起，进行统一的权限管理。

我们创建一公司网站的项目web-site，项目下面有两个工程，一个是前台pro-frontend， 一个是后台管理pro-backend。

visibility Level：选择谁可以访问该组：我们默认选择private,因为我建设的是私有仓库

Private:只有授权的用户才可以看到

Internal：只要是登录gitlab的用户就可以看到

Public：只要可以访问gitlab web页面的人就可以看到

点击group名称进去，我们在web-site下面创建project:

此时我们已经创建了一个frontend的project,是一个空的工程。我们暂时先不管其他的，使用同样的方法创建backend project。

3 创建用户

我们主要创建这两类用户，一类是项目经理PM（用来管理项目），另一类是开发DEV（项目功能的实现）。

注：

• 邮件不能重复；
• 新建用户不能设置密码，需要我们在添加完用户名，编辑用户并为用户设置一个初始密码，用户第一次登录时系统要求用户更改密码；
• 去掉勾选，普通用户我们一般不需要create group。

4 授权用户

创建完user后，我们需要将user添加到组或者project上，并选择不同的role。

首先我们add user to group

 

我们将选择dev1用户，角色选择Developer，过期日期不设置为永远不过期

用同样的方法添加dev2,pm(角色Master)，添加到group.

 5 添加SSH Key

我们使用dev1帐号登录到Gitlab，然后切换到一个具体的project下：

 

我们为dev1用户添加一个SSH Key，SSH Key可以让我以SSH的方式链接到代码仓库，然后就可以在本地和Gitlab仓库之间拉取和推送代码。SSH Key全局唯一。

我们在node1节点上生成SSH Key:

 

[root@node1 ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:eEoexwPCixJX99Gr7H3Sn29BS4RIJ4IBIbnr2fGme1M root@node1
The key's randomart image is:
+---[RSA 2048]----+
|   .oo+.+o.o...  |
|   +.. o .o.o. . |
|. . + . .  .  .  |
| o o o +  .    o |
|. . o +.S.    o .|
| . . + =oE     o |
|  . o =... .    .|
|   o . =. o o  ..|
|     o= .  o .oo.|
+----[SHA256]-----+
[root@node1 ~]# ll .ssh/
total 12
-rw------- 1 root root 1679 Dec  4 15:17 id_rsa
-rw-r--r-- 1 root root  392 Dec  4 15:17 id_rsa.pub
-rw-r--r-- 1 root root  803 Dec  1 13:26 known_hosts
[root@node1 ~]# cat .ssh/id_rsa.pub 

 

我们将公钥id_rsa.pub的内容添加到Gitlab dev1用户的SSH Key中。

至此，我们已经完成打通了dev1的本机与Gitlab仓库之间的通道。

我们再将我们的windows的SSH Key添加到Gitlab，首先我们要安装Git GUI：

 

在窗口中重复执行我们在linux中创建SSH Key的过程

然后根据提示找到id_rsa.pub,将该文件中的内容添加到Gitlab中dev2的SSH Key。

由于SSH Key全局唯一，所以我只要任何一个用户中添加都可以

6 初始化GitLab仓库

刚才我们创建的前台和后台两个project现在还是空的，本次教程我们只使用其中的frontend，现在我们首先对这两个仓库进行初始化，并创建两个分支master，dev。我们使用pm用户对frontend进行初始化操作。

 

接下来我们自动创建dev分支：

我们可以mster分支是默认的分支，而且是受保护的。

在实际的开发过程中，master分支一般用来版本发布，dev分支用于存放开发代码

7 使用Gitlab远程仓库

前面我们已经创建了frontend的远程仓库，现在我们分别在linux下和windows下连接远程仓库，实现代码的摘取与推送。

用git clone 命令克隆远程frontend仓库到本地

root@node1 ~]# git clone git@192.168.56.12:web-site/frontend.git
Cloning into 'frontend'...
The authenticity of host '192.168.56.12 (192.168.56.12)' can't be established.
ECDSA key fingerprint is SHA256:SjPoetHYvGBI08VxTdzYOys+QpjR5vLNbU9Obs2Lx9Q.
ECDSA key fingerprint is MD5:39:3e:52:a1:45:9b:3e:23:72:e6:0d:0e:76:00:17:55.
Are you sure you want to continue connecting (yes/no)? yes   /第一次连接时会出现该提示

[root@node1 frontend]# git remote -v
origin    git@192.168.56.12:web-site/frontend.git (fetch)
origin    git@192.168.56.12:web-site/frontend.git (push)
从远程仓库拉下dev分支到本地
[root@node1 frontend]# git pull origin dev
From 192.168.56.12:web-site/frontend
 * branch            dev        -> FETCH_HEAD
Already up-to-date.
切换到dev分支
[root@node1 frontend]# git checkout dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'
[root@node1 frontend]# git branch
* dev
  master

在dev分支下添加linux.txt文件，然后commit。

[root@node1 frontend]# echo "this is linux agnet" >> linux.txt
You have new mail in /var/spool/mail/root
[root@node1 frontend]# git add .
[root@node1 frontend]# git commit -m "add linux.txt file"
[dev cdd58d8] add linux.txt file
 1 file changed, 1 insertion(+)
 create mode 100644 linux.txt

推送本地dev分支到远程仓库的dev分支

[root@node1 frontend]# git push origin dev

8 分支的保护

在实际使用过程中，我们通常会保持 master 分支稳定，用于生产环境的版本发布，只有授权的用户才可以向 master 合并代码。要实现此功能，我们需要将 master 设置为保护分支，并授权什么用户可以向 master 用户推送代码
使用 root 用户点击 git_test 仓库页面左下角的 Settings进入设置页面，选择设置菜单栏下面的 Repository 选项

 

设置完成后，在仓库分支页面，可看到 master 分支后面出现一个绿色的 protected 标记

此时我们再尝试在 ci-node2 上推送 master 分支到 GitLab

[root@ci-node2 git_test]# touch ci-node2
[root@ci-node2 git_test]# git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ci-node2
nothing added to commit but untracked files present (use "git add" to track)
[root@ci-node2 git_test]# git add .
[root@ci-node2 git_test]# git commit -m "commit ci-node2 on ci-node2"
[master 291395b] commit ci-node2 on ci-node2
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 ci-node2
[root@ci-node2 git_test]# git push -u origin master
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 232 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: GitLab: You are not allowed to push code to protected branches on this

四 GitLab高级应用

1 Milestones（里程碑）

里程碑计划是一个目标计划，它表明为了达到特定的里程碑，去完成一系列活动。根据frontend的开发计划，我们为frontend建立一个v1.0的里程碑。

 

2 Issue  and Issue Tracker（问题跟踪器）

Issue可以有很多的作用：

1、阐述一个新的想法；2、提交功能建议；3、报告bugs等。

根据我们frontend的开发计划，我们使用Issue来分派计划中的任务：

使用同样的方法，添加剩下的三个计划。完成后如下：

我们使用dev2用户登录，可以看到：

然后我们模拟dev2用户在本地开发about功能，并将开发的代码上传gitlab，然后合并到dev分支。

我们发送一个合并请求给pm，请求我们的about功能合并到开发分支

 五 GitLab备份

对 gitlab 进行备份将会创建一个包含所有库和附件的归档文件。对备份的恢复只能恢复到与备份时的 gitlab 相同的版本。将 gitlab 迁移到另一台服务器上的最佳方法就是通过备份和还原。gitlab 提供了一个简单的命令行来备份整个 gitlab，并且能灵活的满足需求

1 备份配置

备份文件将保存在配置文件中定义的backup_path 中 ，文 件 名 为TIMESTAMP_gitlab_backup.tar,TIMESTAMP 为备份时的时间戳。 TIMESTAMP 的格式为：EPOCH_YYYY_MM_DD_Gitlab-version。

默认的备份文件目录为：/var/opt/gitlab/backups，如果自定义备份目录需要赋予目录 git 权限，具体操作如下：

# 配置文件中加入
gitlab_rails['backup_path'] = '/data/backup/gitlab'
gitlab_rails['backup_keep_time'] = 604800 #备份保留的时间（以秒为单位这个是七天默认值）

在命令行执行如下命令

[root@ci-node1 git_test] # mkdir /data/backup/gitlab -p
[root@ci-node1 git_test] # chown -R git.git /data/backup/gitlab
[root@ci-node1 git_test] # gitlab-ctl reconfigure

2 手动备份

在命令执行：gitlab-rake gitlab:backup:create 生成一次备份

[root@ci-node1 git_test]# gitlab-rake gitlab:backup:create
[root@ci-node1 git_test]# ll /data/backup/gitlab/
total 80
-rw------- 1 git git 81920 Aug 3 17:22
1533288168_2018_08_03_10.2.2_gitlab_backup.tar

3 定时备份

通过在定时任务里添加：

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

我们来实现定时备份，由于代码是一个企业非常重要的资产，所以我们要重视 GitLab的备份工作。至少做到每天备份一次，平时要注意检查备份的完整性。
环境变量CRON=1 的作用是如果没有任何错误发生时， 抑制备份脚本的所有进度输出

4 恢复实践

GitLab 的恢复只能还原到与备份文件相同的 gitlab 版本的系统中，恢复时，停止连接到数据库的进程（也就是停止数据写入服务），但是保持 GitLab 是运行的

[root@ci-node1 git_test]# gitlab-ctl stop unicorn
ok: down: unicorn: 0s, normally up
[root@ci-node1 git_test]# gitlab-ctl stop sideki
[root@ci-node1 git_test]# gitlab-ctl status
run: gitaly: (pid 46031) 25295s; run: log: (pid 8831) 68406s
run: gitlab-monitor: (pid 46042) 25294s; run: log: (pid 9000) 68380s
run: gitlab-workhorse: (pid 46051) 25294s; run: log: (pid 8898) 68400s
run: logrotate: (pid 26776) 93s; run: log: (pid 8930) 68393s
run: nginx: (pid 46068) 25293s; run: log: (pid 8906) 68399s
run: node-exporter: (pid 46074) 25292s; run: log: (pid 8978) 68387s
run: postgres-exporter: (pid 46079) 25292s; run: log: (pid 9107) 68362s
run: postgresql: (pid 46126) 25291s; run: log: (pid 8649) 68455s
run: prometheus: (pid 46134) 25291s; run: log: (pid 9071) 68368s
run: redis: (pid 46142) 25291s; run: log: (pid 8589) 68467s
run: redis-exporter: (pid 46146) 25290s; run: log: (pid 9050) 68374s
run: sidekiq: (pid 25878) 524s; run: log: (pid 8811) 68412s
down: unicorn: 33s, normally up; run: log: (pid 8772) 68418s

接下来执行 gitlab 恢复操作

[root@ci-node1 git_test]# gitlab-rake gitlab:backup:restore
BACKUP=1533288168_2018_08_03_10.2.2