GitLab的使用

Posted zdqc

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了GitLab的使用相关的知识,希望对你有一定的参考价值。

Gitlab使用

一、常用命令

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>查看服务的日志

 技术分享图片

 

二、常用的组件

nginx:静态Web服务器

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

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

logrotate:日志文件管理工具

postgresql:数据库

redis:缓存数据库

sidekiq:用于在后台执行队列任务(异步执行)

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

三、基础目录:

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

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

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

/etc/gitlab:   配置文件目录

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

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

四、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:

[[email protected] ~]# 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 [email protected]

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]-----+

[[email protected] ~]# 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

[[email protected] ~]# cat .ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnWbgoAKbW5nCTnRo4IfAJ0KrEdbhiyEea2NTROP5QVsIZo8B7iIcoq78XfIZWscGkDypWRa1HTAGrdem0d28ihqrcFsepnKhRpiXC4ZbycZ7DIU1LXtCBioNrCJdm7fGOse/pUGt8qpmeFProrkwFeUG5nxUBOChjYRqpwUQm4Nq5Z+fRGYVGiTngHyQ7L1d67Eqs4xuFjlTi72c0sySiOhk0lu4gFFyE9WuXBdiFGsNdOz504ypKxI2uMws6vj9k28ETykx5RC/0Uyk+xJMwoJE9L4xB+ihtMCQBGw1UG6T4djsoDniTp++PGpMxePieZQ88cB1dIJMqhTV0y0mv [email protected]

我们将公钥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仓库到本地

[[email protected] ~]# git clone [email protected]: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.

[[email protected] ~]# 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

[[email protected] ~]# cd frontend/

[[email protected] frontend]# ll

total 4

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

[[email protected] frontend]# git branch

* master

[[email protected] frontend]# git remote -v

从远程仓库拉下dev分支到本地

[[email protected] frontend]# git pull origin dev

From 192.168.56.12:web-site/frontend

 * branch            dev        -> FETCH_HEAD

Already up-to-date.

切换到dev分支

[[email protected] frontend]# git checkout dev

Branch dev set up to track remote branch dev from origin.

Switched to a new branch ‘dev‘

[[email protected] frontend]# git branch

* dev

  master

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

[[email protected] frontend]# echo "this is linux agnet" >> linux.txt

You have new mail in /var/spool/mail/root

[[email protected] frontend]# git add .

[[email protected] 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分支

[[email protected] 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呢?这个问题留给大家课后实际操作一下。

实验结果:

[[email protected] frontend]# git checkout master

Switched to branch ‘master‘

[[email protected] frontend]# git merge dev

Updating 8a36a7f..cdd58d8

Fast-forward

 linux.txt | 1 +

 1 file changed, 1 insertion(+)

 create mode 100644 linux.txt

[[email protected] 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

[[email protected] 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 ‘[email protected]:web-site/frontend.git‘

 

五、Gitlab高级使用

在开始我们的讲解前,我们先为我们的frontend项目做一个开发计划:

 

v1.0版本:开始时间为12月5日,结束时间为12月11,工期5天

模块

开发者

完成日期

 

 

首页

dev1

7

 

 

新闻

dev1

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

[[email protected] src]# cd /usr/local/src/

[[email protected] 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

[[email protected] src]# rpm -ivh gitlab-ci-multi-runner-9.5.1-1.x86_64.rpm

 

3.4注册

         向gitlab-CI注册这个runner

[[email protected] 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!

[[email protected] 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

[[email protected] src]#

3.5启动

[[email protected] 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 要执行的命令。

 技术分享图片

技术分享图片

技术分享图片

 

六、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生成一次备份。

[[email protected] ~]# 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

[[email protected] ~]# 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‘]。

[[email protected] ~]# 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是运行的。

[[email protected] ~]# gitlab-ctl stop unicorn

  • ok: down: unicorn: 0s, normally up

[[email protected] ~]# gitlab-ctl stop sidekiq

  • ok: down: sidekiq: 0s, normally up

确认:

[[email protected] ~]# 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

[[email protected] ~]#

接下我们进行恢复,指定时间戳你要从那个备份恢复:

[[email protected] ~]# 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服务

[[email protected] ~]# 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的服务

[[email protected] ~]# 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

以上是关于GitLab的使用的主要内容,如果未能解决你的问题,请参考以下文章

gitlab的安装和使用

使用 gitlab java api 连接到 gitlab

gitlab的安装和使用

GitLab的基本使用

GITLAB(gitlab)安装和使用

Gitlab Runner的使用(涵盖gitlab-page)