gitlab

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

# gitlab-ce为稳定版本，后面不填写版本则默认pull最新latest版本
docker pull gitlab/gitlab-ce

mkdir -p /tmp/gitlab/config
mkdir -p /tmp/gitlab/logs
mkdir -p /tmp/gitlab/data

sudo docker run -p 443:443 -p 80:80 -p 222:22 --name gitlab --restart always \
-v /tmp/gitlab/config:/etc/gitlab \
-v /tmp/gitlab/logs:/var/log/gitlab \
-v /tmp/gitlab/data:/var/opt/gitlab --privileged=true gitlab/gitlab-ce
# -d：后台运行
# -p：将容器内部端口向外映射
# --name：命名容器名称
# -v：将容器内数据文件夹或者日志、配置等文件夹挂载到宿主机指定目录
特权模式

访问80,默认root

vim /home/gitlab/config/gitlab.rb
# 配置http协议所使用的访问地址,不加端口号默认为80
external_url 'http://192.168.199.231'

# 配置ssh协议所使用的访问地址和端口
gitlab_rails['gitlab_ssh_host'] = '192.168.199.231'
gitlab_rails['gitlab_shell_ssh_port'] = 222 # 此端口是run时22端口映射的222端口
:wq #保存配置文件并退出
docker restart gitlab

https://www.cnblogs.com/zuxing/articles/9329152.html

Failed asserting that mode permissions on "/var/opt/gitlab/git-data/repositories" is 2770 ---- Begin output of set -x && [ "$(stat --printf='%04a' $(readlink -f /var/opt/gitlab/git-data/repositories) | grep -o '....$')" = '2770' ] ---- STDOUT: STDERR: + grep -o ....$+ readlink -f /var/opt/gitlab/git-data/repositories

fix method: 
mkdir -p /Users/Shared/gitlab/data/git-data/repositories 
sudo chmod g+s /Users/Shared/gitlab/data/git-data/repositories

一、常用命令

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:

[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:

[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（参考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
[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分支

推送本地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
[root@node1 frontend]# git push origin master

五、Gitlab高级使用

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简介

sudo docker run -d --name gitlab-runner --restart always \
--link gitlab \
-v /tmp/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest

docker exec -it gitlab-runner gitlab-runner register

1、如果使用docker启动，需要用本地ip,使其可以访问
2、token ->访问  gitlab的admin/runners

--link gitlab-runner互联gitlab;两者之间通过host访问不暴露端口

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 要执行的命令。

六、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
[root@node2 ~]# ll /var/opt/gitlab/backups/

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/
停止连接到数据库的进程（也就是停止数据写入服务），但是保持GitLab是运行的。

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

[root@node2 ~]# gitlab-ctl status
[root@node2 ~]#
接下我们进行恢复，指定时间戳你要从那个备份恢复：

[root@node2 ~]# gitlab-rake gitlab:backup:restore BACKUP=1512811475_2017_12_09_10.2.2Do you want to continue (yes/no)?
将移除我们自建的表。回答yes
Do you want to continue (yes/no)?
将移除所有的认证Key。回答yes
完成后重启GitLab服务
[root@node2 ~]# gitlab-ctl restart
检查GitLab的服务

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

docker restart gitlab

posted @ 2018-12-14 09:10 慕沁阅读(399) 评论(0) 收藏举报

刷新页面返回顶部

慕沁