jenkinsgitlab仓库配置文档

未经允许不得转载

jenkinsgitlab仓库拉取文档

一：登录网站

https://gitlab.yocardhome.com/users/sign_in用户：xxxxx 密码：xxxxxxxx

配置文件目录

vi /etc/gitlab/gitlab.rb**

**vim /opt/gitlab/etc/gitlab.rb.template** 

**vim /opt/gitlab/etc/gitlab-rails/gitlab-rails-rc**

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 命令来查看各服务的状态

root@iZwz98v31srmqduvfmt4gkZ:~# gitlab-ctl status**

**run: alertmanager: (pid 18125) 1348770s; run: log: (pid 31847) 17674658s**

**run: gitaly: (pid 18146) 1348770s; run: log: (pid 31846) 17674658s**

**run: gitlab-monitor: (pid 18161) 1348769s; run: log: (pid 31788) 17674659s**

**run: gitlab-workhorse: (pid 18165) 1348769s; run: log: (pid 31735) 17674659s**

**run: logrotate: (pid 9868) 2356s; run: log: (pid 31737) 17674659s**

**run: nginx: (pid 18205) 1348768s; run: log: (pid 31736) 17674659s**

**run: node-exporter: (pid 18217) 1348768s; run: log: (pid 31761) 17674659s**

**run: postgres-exporter: (pid 18224) 1348767s; run: log: (pid 31937) 17674657s**

**run: postgresql: (pid 18231) 1348767s; run: log: (pid 31785) 17674659s**

**run: prometheus: (pid 18239) 1348766s; run: log: (pid 31819) 17674658s**

**run: redis: (pid 18246) 1348766s; run: log: (pid 31713) 17674660s**

**run: redis-exporter: (pid 18258) 1348766s; run: log: (pid 31789) 17674659s**

**run: sidekiq: (pid 19556) 1348595s; run: log: (pid 31716) 17674660s**

**run: unicorn: (pid 19900) 1348569s; run: log: (pid 31715) 17674660s

GitLab 工作流程

img

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 包下载。其它请求会反向代理到 GitLab Rails 应用，即反向代

理给后端的 unicorn。

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 主要目录

/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 关闭用户注册

我们 Gitlab 系统是企业内部私有代码仓库，所有用户都是由管理员创建，并不需要注册功能， 因此我们需要关闭此功能

img

使用 root 用户登录，点击页面最上方的 Admin area

如图：

img

进入管理员区域页面，点击页面左侧菜单栏最下方的 Settings

img

进入 Settings 页面，下拉页面找到 Sign-up Restrictions 选项

img

取消 Sign-up enabled 选项前面的勾选，下拉到页面的最下方，点击 Save 按钮完成配置。退回到系统的登录页面，发现已经没有用户注册功能。

Gitlab 仓库管理

GitLab 是通过组（group）的概念来统一管理仓库（project）和用户（user），通过创建组， 在组下再创建仓库，再将用户加入到组，从而实现用户与仓库的权限管理。

创建组create group

在管理员页面点击页面顶部的 Admin area 按钮，进入管理员区域

在页面右侧点击绿色的 New group 按钮，进入创建组页面：

img

在创建组页面中，组路径和组名称为必填项，而且此两处内容最好一致：

img

注：visibility Level：选择谁可以访问该组：我们默认选择 private 即可， Private:只有授权的用户才可以看到 Internal：只要是登录 gitlab 的用户就可以看到 Public：只要可以访问 gitlab web 页面的人就可以看到点击页面最下的 create group 按钮，完成组的创建，进入组管理页面

img

在页面我们可为组添加用户。

创建用户create user

在管理员页面点击页面顶部的 Admin area 按钮，进入管理员区域

img

在创建用户页面，输入用户名昵称、用户名、电子邮件、选择用户级别

图一：

img

图二：

img

点击页面最下部的 create user 按钮，完成用户创建，进入用户管理页面

img

点击页面右上页的 Edit 按钮，为用户设置初始密码

用户授权（grant user）

用户创建完成后，我们就需要对用户进行授权，从而使用户可以管理仓库，有两种方式，一 是将用户加入到组，这样用户可以管理组内的仓库，二是直接授权用户管理仓库。通常我们 采用的方式是将用户加入相应的组，并赋予不同的角色。GitLab 中用户的角色是系统定义好 的，不能更改。这一点可能不符合我们正常的思维习惯。下面我们将刚创建的 dev 用户添加 到我们的例如frontEnd组，将赋予 developer 权限， 在管理员区域，

img

点击frontEnd组，进入组管理页面：

img

选择我们刚创建的 xxx用户，选择 xxx角色，然后添加到组：

注：关于每一种角色对应的权限，可参见官方文档相关内容：、

https://docs.gitlab.com/ee/user/permissions.html

创建仓库（create project）

在 GitLab 中，你可以创建 project 用来存储你的程序代码、作为一个问题跟踪器、用于代码协作、用于持续集成中的构建、测试和部署等。在管理员区域点击 New project 按钮，或者点击导航栏中的选择 New project 选项，

img

进入到新建 project 页面

img

选择仓库所属的组，输入仓库名称、仓库描述，选择可见级别，即可完成仓库创建。进入仓库主页面：页面左侧部分为仓库操作相关菜单栏，右侧空仓库下显示如何在命令行连接该仓库，非空时显示仓库内容。

img

img

配置SSH KEY 目前环境没用

推送本地客户端仓库到 GitLab配置ssh才行

首先我们要将 GitLab 上的 git_test 仓库配置为 ci-node1 上 git_test 仓库的远程仓库，

 [root@ci-node1 git_test]# git remote add gitlab https://gitlab.yocardhome.com/root/youxin3.0.git

[root@ci-node1 git_test]# git remote gitlab 其次，使用 git push 命令直接推送本地仓库的 master 分支到远程仓库。 

[root@ci-node1 git_test]# git push -u gitlab master 

The authenticity of host 'ip段' can't be established. 

ECDSA key fingerprint is SHA256:/Mye5etA/3xRViWgkHVCoXGwWM/7UNYOnHDE3Dr82R4.

 ECDSA key fingerprint is MD5:83:8f:b2:af:39:0c:e0:31:f9:fc:30:23:cf:18:5f:ad. 

Are you sure you want to continue connecting (yes/no)? yes 

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

Counting objects: 24, done. 

Delta compression using up to 2 threads. 

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

Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. 

Total 24 (delta 6), reused 0 (delta 0) 

Tohttps://gitlab.yocardhome.com/root/youxin3.0.git

\* [new branch]  master -> master 

Branch master set up to track remote branch master from gitlab.

提示推送功能，我们在 GitLab 上的 git_test 仓库就可以看到我们推送上来的内容

克隆 GitLab 仓库到本地客户端配置ssh

首先，我们配置 XXX客户端与 GitLab 上 xxx用户绑定，

img

第二，使用 git clone 命令克隆仓库到 ci-node2 本地

root@iZwz98v31srmqduvfmt4gkZ:~# #git clone git@https://gitlab.yocardhome.com/root/youxin3.0.git

我们可以看到已经将 GitLab 上的 git_test 仓库克隆到了本地服务器，同时为本地仓库添加

了一个指向 GitLab 上 git_test 仓库的远程仓库。

我们 root@iZwz98v31srmqduvfmt4gkZ 的仓库上创建一个分支，并将分支，推送到 GitLab 上：

root@iZwz98v31srmqduvfmt4gkZ: git checkout -b dev

Switched to a new branch 'dev'

root@iZwz98v31srmqduvfmt4gkZ:# git status

\# On branch dev

nothing to commit, working directory clean

[root@ci-node2 git_test]# git push -u origin dev

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

remote:

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

remote:

https://gitlab.yocardhome.com/root/youxin3.0.git

ev

remote:

To git@10.0.0.11:oldboy/git_test.git

\* [new branch] dev -> dev

Branch dev set up to track remote branch dev from origi

设置保护分支

在实际使用过程中，我们通常会保持 master 分支稳定，用于生产环境的版本发布，只有授

权的用户才可以向 master 合并代码。要实现此功能，我们需要将 master 设置为保护分支，

并授权什么用户可以向 master 用户推送代码。

使用 root 用户点击 XXX仓库页面左下角的 Settings

img

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

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

root@iZwz98v31srmqduvfmt4gkZ:~# touch ci-node2

root@iZwz98v31srmqduvfmt4gkZ:~# git status

\# On branch master

\# Untracked files:

\# (use "git add <file>..." to include in what will be committed)

\#

\#iZwz98v31srmqduvfmt4gkZ

nothing added to commit but untracked files present (use "git add" to track)

root@iZwz98v31srmqduvfmt4gkZ:~# git add .

root@iZwz98v31srmqduvfmt4gkZ:~# 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@iZwz98v31srmqduvfmt4gkZ:~# 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 project.

To git@https://gitlab.yocardhome.com/root/youxin3.0.git

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

error: failed to push some refs to 'git@10.0.0.11:oldboy/git_test.git'

我们发现此时我们已经不能在目前的服务器向 GitLab 上推送 master 分支，因为我们在另一台已经

绑定了一个用户，比如dev 用户属于 developer 角色，master 分支不允许 developer 角色向其推

送内容。

GitLab 备份、恢复、升级

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

备份配置

备 份 文 件 将 保 存 在 配 置 文 件 中 定 义 的 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@iZwz98v31srmqduvfmt4gkZ:~#mkdir /data/backup/gitlab -p

root@iZwz98v31srmqduvfmt4gkZ:~#chown -R git.git /data/backup/gitlab

root@iZwz98v31srmqduvfmt4gkZ:~#gitlab-ctl reconfigure

手动备份

备 份 文 件 将 保 存 在 配 置 文 件 中 定 义 的 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@iZwz98v31srmqduvfmt4gkZ:~#mkdir /data/backup/gitlab -p

root@iZwz98v31srmqduvfmt4gkZ:~#chown -R git.git /data/backup/gitlab

root@iZwz98v31srmqduvfmt4gkZ:~#gitlab-ctl reconfigure

 

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

root@iZwz98v31srmqduvfmt4gkZ:~# gitlab-rake gitlab:backup:create

root@iZwz98v31srmqduvfmt4gkZ:~# 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

我们看到在设定的目录中生成了对应的备份文件。

定时备份

通过在定时任务里添加：

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

我们来实现定时备份，由于代码是一个企业非常重要的资产，所以我们要重视 GitLab 的备

份工作。至少做到每天备份一次，平时要注意检查备份的完整性。

环境变量 CRON=1 的作用是如果没有任何错误发生时， 抑制备份脚本的所有进度输出

恢复实践

GitLab 的恢复只能还原到与备份文件相同的 gitlab 版本的系统中，恢复时，停止连接到数据

库的进程（也就是停止数据写入服务），但是保持 GitLab 是运行的。

root@iZwz98v31srmqduvfmt4gkZ:~# gitlab-ctl stop unicorn

ok: down: unicorn: 0s, normally up

root@iZwz98v31srmqduvfmt4gkZ:~# gitlab-ctl stop sideki

root@iZwz98v31srmqduvfmt4gkZ:~# gitlab-ctl status

run: gitaly: (pid 46031) 25295s; run: log: (pid 8831) 68406s

run: gitlab-monitor: (pid 46042) 25294s; run: log: (pid 9000) 68380s

 

接下来执行 gitlab 恢复操作：

root@iZwz98v31srmqduvfmt4gkZ:~#gitlab-rake gitlab:backup:restore

BACKUP=1533288168_2018_08_03_10.2.2

整个恢复执行过程中，我们可以看到基本是在删除表，创建表。

升级

首先，下载新版本的 RPM 包，可以通过官网或者清华镜像站获取。

其次关闭部分 gitlab 服务

gitlab-ctl stop unicorn

gitlab-ctl stop sidekiq

gitlab-ctl stop nginx

执行升级操作

rpm -Uvh gitlab-ce-10.0.4-ce.0.el7.x86_64.rpm

重新配置 gitlab

重启 gitlab 服务

Jenkins 使用

登录：

img

由于默认 jenkins 的密码较复杂，所以我首先更改成自己能记住的用户的密码

重复输入新密码后，点击 save 保存更改

img

img

Jenkins 常用目录及文件

学习 Jenkins，首先要明白一点，那就是 jenkins 下一切兼文件，也就是说 jenkins 没有数据库，

所有的数据都是以文件的形式存在，所以我要了解 Jenkins 的主要目录及文件，通过命令我

们可以查看到所有的 jenkins 目录及文件的位置

img

Jenkins 创建新项目

构建作业是一个持续集成服务器的基本职能，构建叙利亚的形式多种多样，可以是编译和单

元测试，也可能是打包及部署，或者是其他类似的作业。在 Jenkins 中，构建作业很容易建

立，而且根据你的需要你可以安装各种插件，来创建多种形式的构建作业，下面我们先来学

习创建自由式构建作业。

自由式的构建作业是最灵活和可配置的选项，并且可以用于任何类型的项目，它的配置相对

简单，其中很多配置在的选项也会用在其他构建作业中。

在 Jenkins 主页面，点击左侧菜单栏的“新建”或者“New job”

img

你给项目起个名字 下面可以拿现有的项目进行克隆 不然的话很多东西要填写

img

打开 Pipeline 配置页面，点 Pipeline 选项卡，下拉到 pipeline 部分，选择 pipeline script，

在页面定义 jenkinsfile 的方式，在脚本框输入下面的内容

pipeline {

 agent any

 stages {

 stage('Stage 1') {

 steps {

 echo 'Hello world!'

 } 

 }

}

img

构建

img

img

开发自己填写对应的地址

img

posted @ 2020-12-09 15:03  zhengjia1989  阅读(333)  评论(0)  编辑  收藏  举报