第一章(一)：代码管理之Gitlab的部署及使用_gitlab-ctl

第一章(一)：代码管理之Gitlab的部署及使用

如果转载，还请注明我文章的链接，书写不易，互相珍重，期待技术交流

系统环境：centos7.8

gitlab版本：gitlab-ce-13.5.4-ce.0.el7.x86_64.rpm

Yu
2020年11月

一、gitlab的介绍

代码版本管理是cicd中极为重要的一环，当前常见的代码管理平台有github，gitlab，以及国内的 码云，github与码云等因为是公开型代码管理平台，对于企业来讲，设计一个安全性问题，所以当前应用中，大部分企业是会选择搭建自己的本地代码版本管理服务，gitlab就是应用较多的方案。

gitlab也是有商业版和社区版之分，CE是社区版，EE为企业版，企业版的功能会更多，但是大部分通过CE版本与其他开源方案组合后也都可以实现类似的功能

二、环境准备

在安装之前，我们依然要准备好我们的基本系统和软件运行的环境。

这里也会是通篇笔记唯一一次演示基本的系统设置，后续默认均以此处的环境为基础

1、关闭firewalld防火墙

因为是演示环境，为了避免防火墙带来的通讯阻隔，关闭防火墙以方便操作,
在生产环境中，要根据具体安全需求，来决定是否关闭防火墙。

[root@node1 ~]# systemctl stop firewalld
[root@node1 ~]# systemctl disable firewalld
[root@node1 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

1
2
3
4
5
6
7
8

2、关闭selinux

[root@node1 ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
[root@node1 ~]# setenforce 0
1
2

3、关闭NetworkManager

如果使用的系统为centos8.x，那么networkManager服务不可关闭

[root@node1 ~]# systemctl stop NetworkManager
[root@node1 ~]# systemctl disable NetworkManager
[root@node1 ~]# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:NetworkManager(8)

1
2
3
4
5
6
7
8

4、配置IP

如果是centos8.x，在第三步不关闭NetworkManager的基础上，按常规方式修改 /etc/sysconfig/network-scripts/ifcfg-xxxx 文件后，使用 # nmcli c reload 命令来重启网络使配置生效

[root@node1 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ens33
TYPE="Ethernet"
BOOTPROTO="static"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.80.151
NETMASK=255.255.255.0
GATEWAY=192.168.80.1
DNS1=192.168.80.1

[root@node1 ~]# systemctl restart network
1
2
3
4
5
6
7
8
9
10
11
12

5、配置yum源

如果不具备网络环境，那么建议挂载本地镜像源，但建议在实验阶段尽力可以满足访问外部网络，不然很多应用及插件的安装会很困难

基本源为系统默认，不需要动

只配置一个epel源即可
[root@node1 ~]# yum -y install epel-release
或者
# 网络不好使用国内源
[root@node1 ~]# vim /etc/yum.repos.d/epel.repo
[epel]
name=tuna_epel
baseurl=https://mirrors.tuna.tsinghua.edu.cn/epel/7/x86_64/
enabled=1
gpgcheck=0
1
2
3
4
5
6
7
8
9
10
11
12

6、安装时间同步ntpdate

ntpdate在centos8中已经消失，需要采取其他方式，或者自行百度也是可以实现ntpdate的

同步时间的方式很多，我这里采用ntpdate
[root@node1 ~]# yum -y install ntpdate


[root@node1 ~]# ntpdate time1.aliyun.com
1
2
3
4
5

注意，时间同步很重要，尤其是当其他服务组件搭建起来后，整个服务集群中的时间一定要同步

7、主机名及hosts

整套的服务，都不建议采取IP地址直接写入配置中，这会为业务的迁移，或者设备宕机更换IP等等，带来很多额外的工作，如果以主机名写入配置，当需要更换主机IP时，仅更换dns/hosts即可重新解析。

[root@node1 ~]# hostnamectl set-hostname node1
[root@node1 ~]# echo "192.168.80.151 node1" >> /etc/hosts
1
2

以上就是系统环境的基础配置，是centos7.x通用的，后面其他的该系列文档，均默认采用此配置，后面将不再赘述此处

三、gitlab组件简述

1、gitlab workhorse

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

2、nginx

静态Web服务器，前台作用

3、postgresql

数据库，记录数据，问题，请求，权限，用户等等

4、redis

通信中心，实现任务列表

5、sidekiq

消息队列，依赖redis，这里用作接收redis的邮件任务，负责邮件的发送

6、alertmanager

负责告警

7、gitaly

提供git仓库的访问，处理各种git调用

8、gitlab-shell

用于处理Git命令和修改authorized keys列表

9、logrotate

日志文件管理

10、prometheus

监控

11、grafana

可视化套件

四、安装gitlab

主机信息说明：

1、下载gitlab-ce

[root@node1 ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-13.5.4-ce.0.el7.x86_64.rpm

1
2

如果报错缺少 wget 命令，执行 # yum -y install wget 进行安装

2、安装

[root@node1 tmp]# yum localinstall gitlab-ce-13.5.4-ce.0.el7.x86_64.rpm -y


1
2
3

3、修改配置文件

[root@node1 tmp]# vim /etc/gitlab/gitlab.rb
# 这里是填写一个外部访问gitlab的地址，IP与域名都可以，我这里采用域名的方式，等下配置一下windows(宿主机)域名解析即可，有DNS的自然更好
 32 external_url 'http://local.gitlab.com'



1
2
3
4
5
6

注意：gitlab默认的 unicorn端口为8080，如果后面还要将比如jenkins(默认端口8080)等的安装在这台机器上，要注意修改一方的端口，不然会冲突

4、初始化运行

第一次运行会比较慢，需要等待

[root@node1 tmp]# gitlab-ctl reconfigure

1
2

gitlab-ctl reconfigure 命令用于使修改后的配置生效，重载配置

重载完成后会自动启动gitlab，受限于性能和组件等，在初始化完成后需要等待一段时间，才可以访问gitlab

下面我们利用这个等待时间先来简单了解下gitlab的基础命令和目录

5、gitlab常用命令介绍

gitlab-ctl reconfigure : 重载配置

gitlab-ctl start : 启动

gitlab-ctl restart : 重启

gitlab-ctl stop ：停止

gitlab-ctl status ：查看gitlab各组件的状态

gitlab-ctl show-config ：验证配置文件

gitlab-ctl uninstall : 删除gitlab（保留数据）

gitlab-ctl cleanse : 删除所有数据

gitlab-ctl tail ： 查看日志(动态)

gitlab-ctl tail ${组件名} ： 查看特定组件的日志

演示一下

比如  gitlab-ctl status
[root@node1 tmp]# gitlab-ctl status
run: alertmanager: (pid 50212) 310s; run: log: (pid 48555) 510s
run: gitaly: (pid 50182) 313s; run: log: (pid 47121) 668s
run: gitlab-exporter: (pid 50142) 314s; run: log: (pid 48388) 529s
run: gitlab-workhorse: (pid 50110) 317s; run: log: (pid 48142) 555s
run: grafana: (pid 50234) 309s; run: log: (pid 49754) 363s
run: logrotate: (pid 48236) 545s; run: log: (pid 48266) 542s
run: nginx: (pid 48179) 551s; run: log: (pid 48210) 548s
run: node-exporter: (pid 50120) 317s; run: log: (pid 48314) 538s
run: postgres-exporter: (pid 50220) 310s; run: log: (pid 48643) 500s
run: postgresql: (pid 47288) 661s; run: log: (pid 47318) 657s
run: prometheus: (pid 50156) 314s; run: log: (pid 48493) 517s
run: puma: (pid 48007) 569s; run: log: (pid 48020) 568s
run: redis: (pid 47019) 678s; run: log: (pid 47048) 675s
run: redis-exporter: (pid 50144) 314s; run: log: (pid 48435) 523s
run: sidekiq: (pid 48061) 563s; run: log: (pid 48077) 562s


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

6、主要目录介绍

/var/opt/gitlab/git-data/repositories：库的默认存储目录

/opt/gitlab：gitlab应用目录

/var/opt/gitlab：gitlab-ctl reconfigure重载后生成的应用数据和配置文件

/etc/gitlab： 配置文件目录

/var/log/gitlab：gitlab日志

/var/opt/gitlab/backups/：备份文件生成的目录

五、gitlab的管理员级别常用配置与操作

是否还记得我们前面在初始化gitlab之前配置过一次 URL，要用以后面的访问，这里其实使用IP地址直接访问，也是通的，但是，还是之前说的，能采用域名解析的方式，就尽量不要直接采用IP地址。

因为局域网内并没有DNS服务器来解析这个域名，所以我这里需要修改要访问gitlab电脑的hosts文件

文件路径是  C:\Windows\System32\drivers\etc

因为win10系统的限制，我们拷贝此文件，在其他位置修改完成后再替换回来

在hosts文件中追加
192.168.80.151		local.gitlab.com

保存将文件粘贴回C:\Windows\System32\drivers\etc目录下
替换
		

1
2
3
4
5
6
7
8
9
10
11

1、web访问

浏览器输入我们配置并劫持好的域名(不愿配置域名解析，用ip也一样的)

2、初始密码设置

第一次打开界面时，需要为root进行密码配置，按提示操作即可

登录成功的界面

3、修改为中文

看需求，不想修改为中文这一步不需要操作

然后退出再登录，就是中文了

4、管理员用户信息的修改

可以修改图标，用户名称(不是账户名)，邮件等

5、关闭注册功能

因为我们使用gitlab就是要做私有仓库，所以用户管理要做好，禁止用户的注册是第一步要做的(默认是允许用户自主注册的)

验证

退出账户，千万登录页面，可以看到没有注册一栏了，仅剩登录

6、用户的创建与修改

因为我们已经关闭了用户的自主注册功能，所以这里演示的用户注册的方式为管理员创建

如果集成ldap，那么用户的创建与管理将由ldap统一实现

因为我这里所有的邮件都是虚构的，所以我们的这个普通用户必然收不到初始密码或者重置链接，所以我们这里要手动的在编辑里指定一次密码，然后该用户才可以登录

如果找不到用户编辑在哪的话，参见下图

该用户登录后，会强制要求修改密码

密码可以与原密码一致，位数要满足8位

7、创建组

8、将用户加入到组

9、新建项目

10、修改gitlab存储仓库的位置

默认情况下，gitlab存储在 /var/opt/gitlab/git-data/ 路径下，如果我们需要完成比如这台服务器上的数据存储位置统一管理，就可以通过修改gitlab.rb配置文件的方式完成存储目录的更换

比如：我们数据均存储在 /data/目录下，这里我们给gitlab创建一个 /data/gitlab/data 目录，用以存储gitlab的数据

10.1 创建存储目录并赋权

[root@node1 ~]# mkdir -p /data/gitlab/data
[root@node1 ~]# chown -R git.git /data/gitlab

1
2
3

因为gitlab是采用安装时自动创建的git用户来完成工作(部分)，所以我们需要给该目录以git用户权限

10.2 修改配置

这个配置需要自己手动新增，在575行左右有范例，可以复制一份进行修改

[root@node1 ~]# vim /etc/gitlab/gitlab.rb
581 ## 自定义gitlab数据存储路径
 582 git_data_dirs({
 583         "default" => { "path" => "/data/gitlab/data" }
 584 })

1
2
3
4
5
6
7
8

10.3 重载生效

[root@node1 ~]# gitlab-ctl reconfigure
重载完成后仍然需要等待一会才可以访问，这个时间取决于设备的性能

1
2
3

10.4 web端测试访问

会看到提示仓库不存在，这是因为我们切换了存储路径，但是之前的数据还在原始路径下，所以我们还需要完成数据的迁移

10.5 数据迁移

停止gitlab

[root@node1 ~]# gitlab-ctl stop
ok: down: alertmanager: 0s, normally up
ok: down: gitaly: 1s, normally up
ok: down: gitlab-exporter: 0s, normally up
ok: down: gitlab-workhorse: 0s, normally up
ok: down: grafana: 1s, normally up
ok: down: logrotate: 0s, normally up
ok: down: nginx: 1s, normally up
ok: down: node-exporter: 0s, normally up
ok: down: postgres-exporter: 1s, normally up
ok: down: postgresql: 0s, normally up
ok: down: prometheus: 0s, normally up
ok: down: puma: 0s, normally up
ok: down: redis: 0s, normally up
ok: down: redis-exporter: 1s, normally up
ok: down: sidekiq: 1s, normally up


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

拷贝数据

[root@node1 ~]# rsync -av /var/opt/gitlab/git-data/repositories /data/gitlab/data/


1
2
3

启动gitlab

[root@node1 ~]# gitlab-ctl start
ok: run: alertmanager: (pid 125010) 1s
ok: run: gitaly: (pid 125018) 0s
ok: run: gitlab-exporter: (pid 125032) 1s
ok: run: gitlab-workhorse: (pid 125046) 0s
ok: run: grafana: (pid 125055) 1s
ok: run: logrotate: (pid 125074) 0s
ok: run: nginx: (pid 125080) 0s
ok: run: node-exporter: (pid 125086) 1s
ok: run: postgres-exporter: (pid 125173) 0s
ok: run: postgresql: (pid 125180) 1s
ok: run: prometheus: (pid 125195) 0s
ok: run: puma: (pid 125206) 1s
ok: run: redis: (pid 125215) 0s
ok: run: redis-exporter: (pid 125223) 0s
ok: run: sidekiq: (pid 125229) 1s


执行完成也是需要等一会才可以访问web，速度区别于性能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

web验证

11、备份

11.1 数据备份

首先我们在项目里添加一点文件，用作恢复数据时成功与否的说明

接下来修改配置文件

注意看注释文字

修改配置文件，以定义备份方式
[root@node1 ~]# vim /etc/gitlab/gitlab.rb
 517 ### Backup Settings
     ......
 521 # gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
 
### 定义备份到什么路径下
 522 gitlab_rails['backup_path'] = "/data/gitlab/backups"
 523
 524 ###! Docs: https://docs.gitlab.com/ee/raketasks/backup_restore.html#backup     -archive-permissions
 525 # gitlab_rails['backup_archive_permissions'] = 0644
 
### 定义备份文件的文件权限
 526 gitlab_rails['backup_archive_permissions'] = 0644
 527
 528 # gitlab_rails['backup_pg_schema'] = 'public'
 529
 530 ###! The duration in seconds to keep backups before they are allowed to be      deleted
 531 # gitlab_rails['backup_keep_time'] = 604800
 
### 定义备份文件的保留时间(单位是秒)，604800秒为7天，也就是超出7天，文件会被删除
 532 gitlab_rails['backup_keep_time'] = 604800


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

创建我们定义的备份目录

备份到的位置，未必非要是本地，可以推到nfs，ceph等存储，也可以推到云存储(对象存储)中去，这个看需求而定，但是要注意，如果是推到云存储，是需要一些额外配置，具体可以百度一下，(官方也是有示例的)，因为我这里因为不具备环境，所以就不再演示了。

[root@node1 ~]# mkdir /data/gitlab/backups
[root@node1 ~]# chown -R git. /data/gitlab


1
2
3
4

重载生效

[root@node1 ~]# gitlab-ctl reconfigure


1
2
3

执行备份命令

会备份gitlab仓库、数据库、用户、用户组、用户密钥、权限等信息

但不会备份配置文件，所以我们等下需要自己手动备份配置文件

[root@node1 ~]# gitlab-rake gitlab:backup:create
2020-12-03 10:52:01 +0800 -- Dumping database ...
Dumping PostgreSQL database gitlabhq_production ... [DONE]
2020-12-03 10:52:05 +0800 -- done
2020-12-03 10:52:05 +0800 -- Dumping repositories ...
 * gitlab-instance-277c2eff/monitoring (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b) ...
 * gitlab-instance-277c2eff/monitoring (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b) ... [SKIPPED]
 * gitlab-instance-277c2eff/monitoring.wiki (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b.wiki) ...
 * gitlab-instance-277c2eff/monitoring.wiki (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b.wiki) ... [SKIPPED]
 * gitlab-instance-277c2eff/monitoring.design (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b.design) ...
 * gitlab-instance-277c2eff/monitoring.design (@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b.design) ... [SKIPPED]
 * ops/test1 (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35) ...
 * ops/test1 (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35) ... [DONE]
 * ops/test1.wiki (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.wiki) ...
 * ops/test1.wiki (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.wiki) ... [SKIPPED]
 * ops/test1.design (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.design) ...
 * ops/test1.design (@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.design) ... [SKIPPED]
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping uploads ...
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping builds ...
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping artifacts ...
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping pages ...
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping lfs objects ...
2020-12-03 10:52:06 +0800 -- done
2020-12-03 10:52:06 +0800 -- Dumping container registry images ...
2020-12-03 10:52:06 +0800 -- [DISABLED]
Creating backup archive: 1606963926_2020_12_03_13.5.4_gitlab_backup.tar ... done
Uploading backup archive to remote storage  ... skipped
Deleting tmp directories ... done
done
done
done
done
done
done
done
Deleting old backups ... done. (0 removed)
Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.
Backup task is done.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.

这个提示也是在说明，gitlab.rb gitlab-secrets.json两个文件包含敏感信息，请手动备份的意思

11.2 配置文件备份

[root@node1 ~]# ls /etc/gitlab/
gitlab.rb  gitlab-secrets.json  trusted-certs

配置文件中
gitlab.rb  gitlab-secrets.json  两个文件比较重要，
gitlab.rb是主配置文件
gitlab-secrets.json 记录了数据库的一些秘钥等信息


所以我们备份这两个文件即可

1
2
3
4
5
6
7
8
9
10
11

[root@node1 ~]# cp -a /etc/gitlab/gitlab* /data/gitlab/backups/

[root@node1 ~]# ll /data/gitlab/backups/
total 136
-rw------- 1 root root 115190 Dec  3 10:43 gitlab.rb
-rw------- 1 root root  18976 Dec  3 10:46 gitlab-secrets.json


1
2
3
4
5
6
7
8

11.3 简单查看下备份出的文件样式

[root@node1 ~]# cd /data/gitlab/backups/
[root@node1 backups]# ls
1606963926_2020_12_03_13.5.4_gitlab_backup.tar  gitlab.rb  gitlab-secrets.json

可以看到是tar包，以  "日期+gitlab版本号+gitlab_backup标识.tar"  方式命名

1
2
3
4
5
6

11.4 计划任务周期性备份

可以利用很多方法，比如脚本，crontab，或者一些自动化工具等完成周期的备份
我这里演示一下crontab吧

# 查看下命令的绝对路径
[root@node1 backups]# which gitlab-rake
/usr/bin/gitlab-rake


[root@node1 backups]# crontab -e
# 分 时 日 月 周    要执行的命令
# 每天的凌晨1点  执行备份一次
0 1 * * *  /usr/bin/gitlab-rake gitlab:backup:create CRON=1

查看下配置的计划任务
[root@node1 backups]# crontab -l
0 1 * * *  /usr/bin/gitlab-rake gitlab:backup:create CRON=1


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

12、还原

还原时的注意事项：

首先还原的话，分两种情况：

​ 一种是新安装的gitlab(版本一致)，这样的情况，需要先还原配置文件，不然新配置文件与tar包中的存储路径等对应不上，会报错

​ 另一种是恢复数据，gitlab程序没问题，这样的情况下，执行还原命令即可了

总而言之，要保证版本的一致，配置文件的一致

12.1 新安装gitlab还原数据

首选将原配置文件直接覆盖到新的gitlab配置目录下 "/etc/gitlab" ，
然后执行：
# gitlab-ctl reconfigure
使配置文件生效

后续数据还原与下文一致

1
2
3
4
5
6
7

12.2 数据的还原

一定要保证tar包放置在配置文件中定义的备份目录中了

在保证版本一致的前提下
(
	查看版本的方法：
		[root@node1 ~]# cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
		13.5.4
)


停止数据库连接服务
[root@node1 backups]# gitlab-ctl stop puma
ok: down: puma: 0s, normally up
[root@node1 backups]# gitlab-ctl stop sidekiq
ok: down: puma: 0s, normally up


执行还原命令
注： (
	语法：gitlab-backup restore force=yes BACKUP=备份文件
	force=yes 可以不加，就是非交互的意思，不加需要手动输入几个yes
)

[root@node1 backups]# gitlab-backup restore force=yes BACKUP=1606963926_2020_12_03_13.5.4


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

重载并重启gitlab

[root@node1 backups]# gitlab-ctl reconfigure


重启一下gitlab
[root@node1 backups]# gitlab-ctl restart
ok: run: alertmanager: (pid 34087) 0s
ok: run: gitaly: (pid 34102) 1s
ok: run: gitlab-exporter: (pid 34116) 0s
ok: run: gitlab-workhorse: (pid 34124) 1s
ok: run: grafana: (pid 34140) 0s
ok: run: logrotate: (pid 34155) 0s
ok: run: nginx: (pid 34168) 1s
ok: run: node-exporter: (pid 34174) 0s
ok: run: postgres-exporter: (pid 34185) 1s
ok: run: postgresql: (pid 34197) 1s
ok: run: prometheus: (pid 34216) 0s
ok: run: puma: (pid 34225) 1s
ok: run: redis: (pid 34312) 0s
ok: run: redis-exporter: (pid 34317) 0s
ok: run: sidekiq: (pid 34329) 1s

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

执行命令查看下恢复后组件状态
[root@node1 backups]# gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 13.11.0 ? ... OK (13.11.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK
alternative ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Incoming Email ...

Incoming Email: ... Reply by email is disabled in config/gitlab.yml

Checking Incoming Email ... Finished

Checking LDAP ...

LDAP: ... LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab App ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
2/1 ... yes
4/2 ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.6)
Git version >= 2.24.0 ? ... yes (2.28.0)
Git user has default SSH configuration? ... yes
Active users: ... 2
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes

Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

前往web页面查看

六、gitlab的使用者级别常用操作

1、项目的权限级别

1.1 项目中可见级别

1.2 项目中的用户权限

项目中用户权限较多，如下图(在设置权限时，有权限说明提示)

下面是权限列表说明的截图，建议去页面上自己打开查看，很详细，比较长

很长，建议去页面上看一看…

2、组中的权限级别

组由管理员创建，并指定该组的 owner，

owner具有创建项目，添加组成员并赋予其权限（不超过自身权限）

具体说明按图示打开页面查看

这里概括一下大概的权限吧

3、ssh配置

还记得前面提示的那个 “在您的个人资料中添加SSH密钥之前，您不能通过SSH来拉取或推送项目代码。” 吗

下面我们就来配置对应用户的 ssh认证，

3.1 git客户端生成公钥

linux下有ssh即可使用
windows下安装git的时候会有一个git-bash，或者用一些工具生成也是一样的

1
2
3

我这里以linux演示
[root@node1 ~]# ssh-keygen -t rsa -C "ops01@gitlab.local" -b 4096
......各种提示时，直接回车即可......
The key's randomart image is:
+---[RSA 4096]----+
|OB==   .++===o   |
|+o= o o..=o==.   |
|o .+ ..o*.++..   |
| +.  . .o=...    |
|. + .  .S o.     |
|.o .     .  .    |
|.            E   |
|                 |
|                 |
+----[SHA256]-----+


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

查看公钥

[root@node1 ~]# cat .ssh/id_rsa
id_rsa      id_rsa.pub
[root@node1 ~]# cat .ssh/id_rsa.pub
......


1
2
3
4
5
6
7
8

3.2 配置gitlab ssh认证

复制此公钥，

打开web页面，登录ops01账户

这样就完成了与gitlab的ssh免密认证，就可以使用ssh模式的代码的 clone push了

http模式在不配置验证的情况下也可以实现代码的clone（公开项目）

4、Git的代码拉取与上传

4.1 配置本地git

还记得前面新建了项目之后，让大家保存的那些页面上的那些命令提示吗，在这里就用上了

[root@node1 ~]# git config --global user.name "ops01"
[root@node1 ~]# git config --global user.email "ops01@gitlab.local"

查看配置
[root@node1 ~]# git config --list
user.name=ops01
user.email=ops01@gitlab.local


1
2
3
4
5
6
7
8
9

4.2 拉取gitlab的远端仓库到本地

拉取

先复制gitlab项目的仓库url

创建一个目录，模拟开发人员的代码存储文件夹
[root@node1 ~]# mkdir code
[root@node1 ~]# cd code/


配置一下 hosts解析
[root@node1 code]# vim /etc/hosts
192.168.80.151    local.gitlab.com


克隆gitlab仓库
[root@node1 code]# git clone git@local.gitlab.com:ops/test1.git
Cloning into 'test1'...
The authenticity of host 'local.gitlab.com (192.168.80.151)' can't be established.
ECDSA key fingerprint is SHA256:GJTZoZMoa73arErcYWMmbul7otaF4DJMT7NlBav84cE.
ECDSA key fingerprint is MD5:b5:dc:77:65:3e:46:fa:f8:61:c9:88:3f:8a:1f:d2:31.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'local.gitlab.com,192.168.80.151' (ECDSA) to the list of known hosts.
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

查看clone下来的仓库内容
[root@node1 code]# ls
test1
[root@node1 code]# cd test1/
[root@node1 test1]# ls
README.md


1
2
3
4
5
6
7
8

上传

我这里随便写个文件，用以演示
[root@node1 test1]# echo "master分支第一次代码上传测试" >> no1.py

[root@node1 test1]# git add no1.py

[root@node1 test1]# git commit -m "master分支第一次代码上传测试"
[master 2441b51] master分支第一次代码上传测试
 1 file changed, 1 insertion(+)
 create mode 100644 no1.py
 
[root@node1 test1]# git push -u origin master



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

可以看到，已经push成功

5、分支的创建与合并

当一个新项目创建后，默认是只有 master 分支的(部分模板创建除外)，并且master分支是处于保护状态的，这也就是说只有该项目的 owner & Maintainer两种身份的用户可以往master中写入内容(管理员不在此列)。

那比如我现在创建一个常规的账户，但是普通账户并不能直接往master分支提交代码，那么代码如何push

在实际开发工作中，一般不会允许开发人员直接将代码push到master，而是每位或每组开发人员单独使用一个 “分支” 的概念，然后当项目开发到一定程度，由开发部门有经验的老同事或者管理层完成代码的审计后，将分支合并到master中。

提交代码到gitlab，在一些严谨的开发流程中，还会利用到比如 gerrit 这类的代码审核工具，审核通过才可提交到仓库

5.1 创建与使用分支

比如我这里从gitlab创建分支 dev01 ，并且在分支下创建一个示例文件，然后拉取到本地

我在开发电脑上拉取一下，同步变化到本地

[root@node1 test1]# git pull
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From local.gitlab.com:ops/test1
 * [new branch]      dev01      -> origin/dev01
Already up-to-date.

[root@node1 test1]# git chechkout origin/dev01


本地就可以看到dev01分支及文件了
[root@node1 test1]# git checkout master
Switched to branch 'master'
[root@node1 test1]# ls
no1.py  README.md
[root@node1 test1]# git checkout dev01
Switched to branch 'dev01'
[root@node1 test1]# ls
dev_no1.txt  no1.py  README.md
[root@node1 test1]# git branch
* dev01
  master


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

我在本地dev01分支创建一个文件并push到gitlab

[root@node1 test1]# git branch
* dev01
  master
  
[root@node1 test1]# echo "dev01分支的push测试01" >> dev01_push_no1.txt

[root@node1 test1]# git add dev01_push_no1.txt

[root@node1 test1]# git commit -m "dev01分支第一次提交测试"
[dev01 b5ae795] dev01分支第一次提交测试
 1 file changed, 1 insertion(+)
 create mode 100644 dev01_push_no1.txt


[root@node1 test1]# git push -u origin dev01
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 402 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for dev01, visit:
remote:   http://local.gitlab.com/ops/test1/-/merge_requests/new?merge_request%5Bsource_branch%5D=dev01
remote:
To git@local.gitlab.com:ops/test1.git
   1f4f149..b5ae795  dev01 -> dev01
Branch dev01 set up to track remote branch dev01 from origin.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

5.2 合并分支

当合并请求提交后，要由有权限的人员来处理进行批准合并

登录Maintainer/owner权限的账号