gitlab

时间 2019-11-08

标签 gitlab 栏目 Git 繁體版

原文原文链接

rpm -ivh gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm

vim /etc/gitlab/gitlab.rb 
# external_url 'http://127.0.0.1'

gitlab-ctl  reconfigure
gitlab-ctl restart







gitlab备份管理

在配置文件中加入
# vim /etc/gitlab/gitlab.rb
gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = '/data/backup/gitlab'            # 备份目录，自动建立
gitlab_rails['backup_keep_time'] = 604800                    # 保留时间


gitlab-ctl reconfigure
若是自定义备份目录须要赋予git权限

mkdir    /data/backup/gitlab

chown    -R    git.git        /data/backup/gitlab
/usr/bin/gitlab-rake    gitlab:backup:create    # 执行备份

# 定时任务Crontab中执行
0 2 * * *     /usr/bin/gitlab-rake    gitlab:backup:create


中止数据写入服务
gitlab-ctl    stop    unicorn
gitlab-ctl    stop    sidekiq
gitlab-rake    gitlab:backup:restore    BACKUP=15112711475_2018_12_14_10.2.2        #  恢复数据
gitlab-ctl    restart

1、经常使用命令

gitlab-ctl status:查看gitlab组件状态

 

gitlab-ctl start:启动所有服务

gitlab-ctl restart:重启所有服务

gitlab-ctl stop：中止所有服务

gitlab-ctl reconfigure:使配置文件生效（通常修改完主配置文件/etc/gitlab/gitlab.rb，须要执行此命令）

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

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

gitlab-ctl cleanse:删除全部数据，重新开始

gitlab-ctl tail <service name>查看服务的日志

2、经常使用的组件

nginx：静态Web服务器

gitlab-shell：用于处理Git命令和修改authorized keys列表，咱们的gitlab是以Git作为最层的，你操做实际上最后就是调用gitlab-shell命令进行处理。

gitlab-workhorse:轻量级的反向代理服务器

logrotate：日志文件管理工具

postgresql：数据库

redis：缓存数据库

sidekiq：用于在后台执行队列任务（异步执行）

unicorn：GitLab Rails应用是托管在这个服务器上面的

3、基础目录：

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

/opt/gitlab： 应用代码和相应的依赖程序

/var/opt/gitlab：gitlab-ctl reconfigure命令编译后的应用数据和配置文件，不须要人为修改配置

/etc/gitlab： 配置文件目录

/var/log/gitlab：此目录下存放了gitlab各个组件产生的日志

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

4、Gitlab基本配置

1、关闭注册

 

因为咱们Gitlab系统是私有仓库，通常用户都是由管理员建立和分派的，因此咱们须要关闭注册。

2、create group

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。

 

subgroup建立同group一样，在此咱们再也不详细说明。

3、create user

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

 

 

 

注：1、邮件不能重复；

2、新建用户不能设置密码，须要咱们在添加完用户名，编辑用户并为用户设置一个初始密码，用户第一次登陆时系统要求用户更改密码；

3、去掉勾选，普通用户咱们通常不须要create group。

 

重复以上步骤，咱们建立dev，dev1，dev2用户。

4、grant user

建立完user后，咱们须要将user添加到组或者project上，并选择不一样的role。

首先咱们add user to group

 

 

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

 

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

 

将用户添加到组后，咱们发现组里的每一个project下自动添加了咱们刚才添加的用户。

 

 

咱们将dev用户添加到backend中，

 

咱们切换到frontend project看一下：发现没有dev用户。

 

如今咱们可使用用户模拟的功能看一下每一个用户的权限。

具体每一种角色的权限，能够参考以下地址：

http://192.168.56.12/help/user/permissions ，地址换成你的Gitlab地址便可。

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

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnWbgoAKbW5nCTnRo4IfAJ0KrEdbhiyEea2NTROP5QVsIZo8B7iIcoq78XfIZWscGkDypWRa1HTAGrdem0d28ihqrcFsepnKhRpiXC4ZbycZ7DIU1LXtCBioNrCJdm7fGOse/pUGt
8qpmeFProrkwFeUG5nxUBOChjYRqpwUQm4Nq5Z+fRGYVGiTngHyQ7L1d67Eqs4xuFjlTi72c0sySiOhk0lu4gFFyE9WuXBdiFGsNdOz504ypKxI2uMws6vj9k28ETykx5RC/0Uyk+xJMwoJE9L4xB+ihtMCQBGw1UG6T4djsoDn
iTp++PGpMxePieZQ88cB1dIJMqhTV0y0mv root@node1

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

 

 

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

咱们再将咱们的windows的SSH Key添加到Gitlab，首先咱们要安装Git GUI（参考gitlab安装文档）：

 

在窗口中重复执行咱们在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下链接远程仓库，实现代码的摘取与推送。

linux:

使用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         /*第一次链接时会出现该提示

Warning: Permanently added '192.168.56.12' (ECDSA) to the list of known hosts.

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (3/3), done.

Checking connectivity... done.

[root@node1 ~]# ll

total 4

-rw-------. 1 root root 1374 Nov 27 00:14 anaconda-ks.cfg

drwxr-xr-x  3 root root   94 Nov 30 22:28 demo

drwxr-xr-x  3 root root   32 Dec  4 21:02 frontend

drwxr-xr-x  3 root root   97 Dec  2 19:48 git-test

drwxr-xr-x  4 root root   49 Nov 30 15:53 web-site

[root@node1 ~]# cd frontend/

[root@node1 frontend]# ll

total 4

-rw-r--r-- 1 root root 16 Dec  4 21:02 README

[root@node1 frontend]# git branch

* master

[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

Counting objects: 3, done.

Delta compression using up to 2 threads.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

remote:

remote: To create a merge request for dev, visit:

remote:   http://192.168.56.12/web-site/frontend/merge_requests/new?merge_request%5Bsource_branch%5D=dev

remote:

To 192.168.56.12:web-site/frontend.git

   8a36a7f..cdd58d8  dev -> dev

而后咱们在Gitlab上查看：

 

windows:

  

 

第一次链接会出现此对话框，请输入yes。

 

拉取远程dev分支，而后切换

 

咱们在frontend文件夹里添加windows文件

 

 

 

 

      

上面的两个过程咱们都是从本地的dev推送到Gitlab仓库的dev分支，那我是否是能够直接在本地合并到master分支，而后推送master分支到Gitlab呢？这个问题留给你们课后实际操做一下。

实验结果：

[root@node1 frontend]# git checkout master

Switched to branch 'master'

[root@node1 frontend]# git merge dev

Updating 8a36a7f..cdd58d8

Fast-forward

 linux.txt | 1 +

 1 file changed, 1 insertion(+)

 create mode 100644 linux.txt

[root@node1 frontend]# ll

total 8

-rw-r--r-- 1 root root 20 Dec  4 21:50 linux.txt

-rw-r--r-- 1 root root 16 Dec  4 21:02 README

[root@node1 frontend]# git push origin master

Counting objects: 3, done.

Delta compression using up to 2 threads.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

remote: GitLab: You are not allowed to push code to protected branches on this project.

To 192.168.56.12:web-site/frontend.git

 ! [remote rejected] master -> master (pre-receive hook declined)

error: failed to push some refs to 'git@192.168.56.12:web-site/frontend.git'

5、Gitlab高级使用

在开始咱们的讲解前，咱们先为咱们的frontend项目作一个开发计划：html

v1.0版本：开始时间为12月5日，结束时间为12月11，工期5天node
模块linux	开发者nginx	完成日期git
首页web	dev1redis	7sql
新闻docker	dev1shell	8
产品	dev2	9
关于咱们	dev2	10

1、Milestones（里程碑）

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

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

Issue能够有不少的做用：1、阐述一个新的想法；2、提交功能建议；3、报告bugs等。

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

   

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

 

咱们使用dev2用户登陆，能够看到：

 

  

而后咱们模拟dev2用户在本地开发about功能，并将开发的代码上传gitlab，而后合并到dev分支。本地编辑文件并上传部分请参考前面（4.7章节），完成后gitlab上4-about分支的状态以下：

 

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

   

而后咱们使用pm用户登陆：

 

 

 

检查正确后，点击merge

 

咱们能够看about.html文件已经合并到了dev分支，而且生成了一次Merge branch的commit记录。而后咱们就能够关闭about 的issue。咱们可使用一样的方法完成其余几个模块的开发，并最后合并到dev分支。当全部的开发工做完成后，
由PM将dev分支合并到mster分支，而后咱们能够在Master分支建立一个发布版本进行发布。

3、GitLab CI

3.1简介

gitlab-ci全称是gitlab continuous integration的意思，也就是持续集成。中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，而后脚本的内容包括了测试，编译，部署等一系列自定义的内容。

 

GitLab CI是 GitLab 提供的持续集成服务，只要在你的仓库根目录 建立一个.gitlab-ci.yml 文件， 并为该项目指派一个Runner，当有合并请求或者 push的时候就会触发build。

这个.gitlab-ci.yml 文件定义GitLab runner要作哪些操做。 默认有3个[stages(阶段)]: build、test、deploy。

因此简单的说，要让CI工做可总结为如下几点:

在仓库根目录建立一个名为.gitlab-ci.yml 的文件

为该项目配置一个Runner

完成上面的步骤后，每次push代码到Git仓库， Runner就会自动开始pipeline。

3.2组件

GitLab-CI

这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。

GitLab-Runner

这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件以后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。

 

由于 GitLab Runner 能够安装到不一样的机器上，因此在构建任务运行期间并不会影响到 GitLab 的性能

.gitlab-ci.yml

这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。

3.3安装

安装GitLab-CI
这个不用安装了，装好GitLab就自带了

安装GitLab-Runner

[root@node1 src]# cd /usr/local/src/

[root@node1 src]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7/gitlab-ci-multi-runner-9.5.1-1.x86_64.rpm

[root@node1 src]# rpm -ivh gitlab-ci-multi-runner-9.5.1-1.x86_64.rpm

3.4注册

向gitlab-CI注册这个runner

[root@node1 src]# gitlab-ci-multi-runner register

Running in system-mode.                            

                                                   

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

http://192.168.56.12                              gitlab地址

Please enter the gitlab-ci token for this runner:

WUsLpmDFu6q4snDSqmds                 project的token

Please enter the gitlab-ci description for this runner:

[node1]: node1                                      runner的描述

Please enter the gitlab-ci tags for this runner (comma separated):

node1-runner                                        runner标签

Whether to run untagged builds [true/false]:

[false]: true                                            

Whether to lock Runner to current project [true/false]:

[false]: false

Registering runner... succeeded                     runner=WUsLpmDF

Please enter the executor: docker, docker-ssh, virtualbox, kubernetes, parallels, shell, ssh, docker+machine, docker-ssh+machine:

shell                                选择runner的类型

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

[root@node1 src]# gitlab-ci-multi-runner list

Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml

node1                                               Executor=shell Token=bcb3699e350002b905bcfead2f3f6d URL=http://192.168.56.12

[root@node1 src]#

3.5启动

[root@node1 src]# gitlab-ci-multi-runner start

3.6编写gitlab-ci.yml

咱们先介绍几个基本概念：

Pipeline

一次 Pipeline 其实至关于一次构建任务，里面能够包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。

 

Stages

Stages 表示构建阶段，说白了就是上面提到的流程。

咱们能够在一次 Pipeline 中定义多个 Stages，这些 Stages 会有如下特色：

全部 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始

只有当全部 Stages 完成后，该构建任务 (Pipeline) 才会成功

若是任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

 

Jobs

Jobs 表示构建工做，表示某个 Stage 里面执行的工做。

咱们能够在 Stages 里面定义多个 Jobs，这些 Jobs 会有如下特色：

相同 Stage 中的 Jobs 会并行执行

相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功

若是任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

 

基本写法

 

# 定义 stages

stages:

  - build

  - deploy

# 定义 job

job1:

  stage: deploy

  script:

    - echo "I am job1"

    - scp web.tar.gz /tmp

    - pwd

# 定义 job

job2:

  stage: build

  script:

    - echo "I am job2"

- tar czf web.tar.gz ./*

 

用 stages 关键字来定义 Pipeline 中的各个构建阶段，而后用一些非关键字来定义 jobs。

每一个 job 中能够能够再用 stage 关键字来指定该 job 对应哪一个 stage。

job 里面的 script 关键字是最关键的地方了，也是每一个 job 中必需要包含的，它表示每一个 job 要执行的命令。

6、GitLab备份

对gitlab进行备份将会建立一个包含全部库和附件的归档文件。对备份的恢复只能恢复到与备份时的gitlab相同的版本。将gitlab迁移到另外一台服务器上的最佳方法就是经过备份和还原。

gitlab提供了一个简单的命令行来备份整个gitlab，而且能灵活的知足需求。

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

若是自定义备份目录须要赋予git权限

配置文件中加入

gitlab_rails['backup_path'] = '/data/backup/gitlab'

gitlab_rails['backup_keep_time'] = 604800       备份保留的时间（以秒为单位，这个是七天默认值），

mkdir /data/backup/gitlab

chown -R git.git /data/backup/gitlab

完成后执行gitlab-ctl reconfigure

1、手动备份

执行：gitlab-rake gitlab:backup:create生成一次备份。

[root@node2 ~]# gitlab-rake gitlab:backup:create

Dumping database ...

Dumping PostgreSQL database gitlabhq_production ... [DONE]

done

Dumping repositories ...

 * web-site/frontend ... [DONE]

 * web-site/frontend.wiki ...  [SKIPPED]

 * web-site/backend ... [SKIPPED]

 * web-site/backend.wiki ...  [SKIPPED]

 * devops/accout ... [DONE]

 * devops/accout.wiki ...  [SKIPPED]

 * devops/user ... [DONE]

 * devops/user.wiki ...  [SKIPPED]

 * web-site/accout ... [DONE]

 * web-site/accout.wiki ...  [SKIPPED]

done

Dumping uploads ...

done

Dumping builds ...

done

Dumping artifacts ...

done

Dumping pages ...

done

Dumping lfs objects ...

done

Dumping container registry images ...

[DISABLED]

Creating backup archive: 1512811475_2017_12_09_10.2.2_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 ... skipping

[root@node2 ~]# ll /var/opt/gitlab/backups/

total 272

-rw------- 1 git git 276480 Dec  9 17:24 1512811475_2017_12_09_10.2.2_gitlab_backup.tar

2、定时备份

在定时任务里添加：

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

 

环境变量CRON=1的做用是若是没有任何错误发生时， 抑制备份脚本的全部进度输出。

3、恢复

只能还原到与备份文件相同的gitlab版本。

执行恢复操做时，须要gitlab处于运行状态，备份文件位于gitlab_rails['backup_path']。

[root@node2 ~]# ll /var/opt/gitlab/backups/

total 272

-rw------- 1 git git 276480 Dec  9 17:24 1512811475_2017_12_09_10.2.2_gitlab_backup.tar

中止链接到数据库的进程（也就是中止数据写入服务），可是保持GitLab是运行的。

[root@node2 ~]# gitlab-ctl stop unicorn

ok: down: unicorn: 0s, normally up

[root@node2 ~]# gitlab-ctl stop sidekiq

ok: down: sidekiq: 0s, normally up

确认：

[root@node2 ~]# gitlab-ctl status

run: gitaly: (pid 1497) 0s; run: log: (pid 540) 0s

run: gitlab-monitor: (pid 1507) 0s; run: log: (pid 543) 0s

run: gitlab-workhorse: (pid 1517) 0s; run: log: (pid 508) 0s

run: logrotate: (pid 14405) 1564s; run: log: (pid 510) 0s

run: nginx: (pid 1532) 0s; run: log: (pid 507) 0s

run: node-exporter: (pid 1538) 0s; run: log: (pid 525) 0s

run: postgres-exporter: (pid 1543) 0s; run: log: (pid 530) 0s

run: postgresql: (pid 1551) 0s; run: log: (pid 492) 0s

run: prometheus: (pid 1559) 0s; run: log: (pid 535) 0s

run: redis: (pid 1567) 0s; run: log: (pid 491) 0s

run: redis-exporter: (pid 1572) 0s; run: log: (pid 547) 0s

down: sidekiq: 121s, normally up; run: log: (pid 500) 0s

down: unicorn: 133s, normally up; run: log: (pid 502) 0s

[root@node2 ~]#

接下咱们进行恢复，指定时间戳你要从那个备份恢复：

[root@node2 ~]# gitlab-rake gitlab:backup:restore BACKUP=1512811475_2017_12_09_10.2.2

Unpacking backup ... done

Before restoring the database, we will remove all existing

tables to avoid future upgrade problems. Be aware that if you have

custom tables in the GitLab database these tables and all data will be

removed.

 

Do you want to continue (yes/no)?

将移除咱们自建的表。回答yes

Restoring uploads ...

done

Restoring builds ...

done

Restoring artifacts ...

done

Restoring pages ...

done

Restoring lfs objects ...

done

This will rebuild an authorized_keys file.

You will lose any data stored in authorized_keys file.

Do you want to continue (yes/no)?

将移除全部的认证Key。回答yes

....

Deleting tmp directories ... done

done

done

done

done

done

done

done

完成后重启GitLab服务

[root@node2 ~]# gitlab-ctl restart

ok: run: gitaly: (pid 18194) 0s

ok: run: gitlab-monitor: (pid 18204) 0s

ok: run: gitlab-workhorse: (pid 18209) 1s

ok: run: logrotate: (pid 18224) 0s

ok: run: nginx: (pid 18231) 1s

ok: run: node-exporter: (pid 18237) 0s

ok: run: postgres-exporter: (pid 18242) 0s

ok: run: postgresql: (pid 18314) 0s

ok: run: prometheus: (pid 18317) 1s

ok: run: redis: (pid 18326) 0s

ok: run: redis-exporter: (pid 18330) 0s

ok: run: sidekiq: (pid 18345) 0s

ok: run: unicorn: (pid 18354) 0s

 

检查GitLab的服务

[root@node2 ~]# gitlab-rake gitlab:check SANITIZE=true

Checking GitLab Shell ...

 

GitLab Shell version >= 5.9.4 ? ... OK (5.9.4)

Repo base directory exists?

default... yes

Repo storage directories are symlinks?

default... no

Repo paths owned by git:root, or git:git?

default... yes

Repo paths access is drwxrws---?

default... yes

hooks directories in repos are links: ...

2/3 ... ok

2/4 ... repository is empty

7/5 ... ok

7/7 ... ok

2/8 ... ok

Running /opt/gitlab/embedded/service/gitlab-shell/bin/check

Check GitLab API access: OK

Redis available via internal API: OK

 

Access to /var/opt/gitlab/.ssh/authorized_keys: OK

gitlab-shell self-check successful

 

Checking GitLab Shell ... Finished

 

Checking Sidekiq ...

 

Running? ... yes

Number of Sidekiq processes ... 1

 

Checking Sidekiq ... Finished

 

Reply by email is disabled in config/gitlab.yml

Checking LDAP ...

 

LDAP is disabled in config/gitlab.yml

 

Checking LDAP ... Finished

 

Checking GitLab ...

 

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/3 ... yes

2/4 ... yes

7/5 ... yes

7/7 ... yes

2/8 ... yes

Redis version >= 2.8.0? ... yes

Ruby version >= 2.3.5 ? ... yes (2.3.5)

Git version >= 2.7.3 ? ... yes (2.13.6)

Git user has default SSH configuration? ... yes

Active users: ... 5

 

Checking GitLab ... Finished