CICD平台搭建：Gitlab应用
Gitlab的应用
应用说明
接下来将从开发和运维的两个视角来介绍Gitlab的应用。Gitlab强大之处在于具有强大的分布式代码版本控制系统的同时，也有出色的后台管理能力。它的后台管理可以针对不同项目、不同用户去制定不同的访问策略，开发和运维这两个角色可以各司其职，互不影响地在自己的场景下工作。
作为开发人员，关注点肯定就是代码的快速发布与审核。每一个项目下各个小组都会去维护自己的项目分支，当这个分支在多次不同环境下部署测试成功之后，接着会提交一个Master主分支合并的申请，然后等待项目领导去审核，决定是否确认合并操作，确认后开发人员又会接着另一个Feature分支继续工作。
作为运维人员，关注点肯定就是在保证Gitlab本身的维护与管理。平时运维人员大部分时间都需要去后台获取相关的系统关键值，如CPU利用率，内存、磁盘使用率，系统健康状态等，以保护Gitlab始终处于一种高可用、高并发、高性能的状态。除此之外也需要关注Gitlab的权限管理，作为Gitlab的admin你需要去分配不同人对项目具有不同的权限，保证开发人员具有分支的克隆、删除、推送、提交、合并和创建分支等权限，保证项目领导在具有开发人员基础权限的同时还具有添加项目用户、开启禁用保护分支、编辑项目信息、审核确认分支申请等不同权限。因此作为运维人员，你需要掌握开发人员使用Gitlab的能力的同时，也需要掌握Gitlab后台核心的管理能力，这样才能解决各种突发问题，保证Gitlab在一个安全、稳定、高效的状态下运转。
演示说明
后面将通过demo来演示运维人员如何去检查Gitlab的系统健康状况，以及给开发人员、项目领导分配特定的角色权限，然后演示一个开发人员在编写完一段代码之后，如何去将这段代码提交到项目的某Feature分支上，并发出合并到Master主分支的申请，接着演示项目领导如何确认这个合并申请，并将其分支代码合并到Master主分支上面，从而完成我们Master主分支合并请求。
检查系统健康状况
接下来以前面的first-repo为例来介绍运维人员如何去检查Gitlab的系统健康状况。
点击上面的“扳手”按钮，进入到Gitlab Admin Area区域：
接着选择左侧列表的Monitoring–>System Info一栏，可以看到右侧出现了很多信息，其中1代表当前虚拟机CPU核数为4核，2代表当前虚拟机内存为1.78G，目前已使用1.15G，3代表虚拟机目前已经运行30分钟，4代表虚拟机的磁盘使用情况：
继续选择左侧列表的Monitoring–>Logs一栏，可以看到右侧出现了7个log信息，但是我们比较关心的是图中的application_json.log和production.log，其中application_json.log存放的是我们操作Gitlab时的操作记录，像什么时候新建了一个repo，登录失败等，这个application_json.log其实就是Gitlab的审计，可以让我们实时追踪到所有Gitlab的任务记录，保证Gitlab在一个安全的状态下运转。
而production.log文件则详细的记录了我们所有的访问记录，举个例子来说：
1 | Completed 200 OK in 11ms (Views: 0.7ms | ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 660) |
这里是说你使用了Get请求来访问"/-/metrics"链接，你的IP地址是127.0.0.1，访问时间是2020-04-17 10:08:48，最后状态码是200，花费了11ms。因此你可以使用这个production.log文件来查看所有的访问记录，实时查看我们所访问链接的健康状况。
继续选择左侧列表的Monitoring–>Health Check一栏，可以看到右侧出现了当前Gitlab的系统状态为健康，说明当前的Gitlab处在一个健康的状态下运转：
创建项目开发人员和项目领导账号
接下来介绍如何创建项目开发人员和项目领导账号，并针对不同角色分配不同的权限。
选择左侧列表的Overview–>DashBoard一栏，可以看到右侧出现了3个字列表分别对应项目，用户，群组，然后在各自列表中就能新建项目，用户，群组了。
然后按照下图配置创建项目开发人员（dev）和项目领导账号（lead）信息，注意密码不用你设置，用户会收到一个密码重置的链接，第一次登录时需要设置密码。注意Access Level必须设置为Regular，表明这是一个普通账户：
然后为不同角色设置不同权限，注意这个是针对具体的项目来的，因此需要回到DashBoard页面，点击project1，接着点击项目first-repo：
然后为dev用户赋予Developer权限，lead用户赋予Maintainer权限。注意里面的Access expiration date是设置过期时间，这里就不设置了。
Gitlab用户在组中有四种权限：Guest、Reporter、Developer、Maintainer。注意在
GitLab 11.0中Master角色被定义为Maintainer角色，也就是维护者角色。虽然维护者是项目级别的最高角色，但是某些操作只能由拥有所有权限的个人或组所有者或实例管理员执行。而Gitlab中的组和项目有三种访问权限：Private、Internal、Public。其中Private表示只有组成员才能看到，Internal表示只要登录的用户就能看到，Public表示所有人都能看到。一般开源项目和组设置的都是Internal。
然后回到用户管理界面，点击右侧的Edit，给他们设置初始登录密码，之后保存即可：
发送合并Master申请
接下来演示开发人员在编写好一段代码以后，如何将这段代码提交至项目的一个Feature分支下，并发出合并到Master主分支的申请。
在前面我们克隆到本地的是Administrator身份的first-repo，现在是需要一个以dev身份克隆到本地的first-repo，依次执行以下命令：
1 | rm -rf first-repo |
注意如果在下载过程中不弹出密码框，可以执行下面的语句：
1 | git config --system --unset credential.helper |
然后继续执行git clone命令，之后进入到下载的first-repo目录，可以看到当前是master主分支：
1 | Administrator@EnvyBook MINGW64 ~/Desktop/repo/first-repo (master) |
接着使用git checkout -b V0.1命令创建本地V0.1分支，它会自动切换到V0.1分支：
1 | Administrator@EnvyBook MINGW64 ~/Desktop/repo/first-repo (master) |
可以看到之前主分支的test.py文件也已经存在了，那就修改这个test.py文件内容为：
1 | print("hello,this is my first repository which created by gitlab") |
然后将其添加到本地V0.1仓库，使用的命令为git add .，接着使用git commit -m 'V0.1 test'携带提交信息并提交至本地V0.1仓库，然后使用git -c http.sslVerify=false push origin V0.1命令来将本地的V0.1分支同步到远程服务器的V0.1分支，如果需要输入密码和账户，请输入dev及其密码即可。
接下来回到Gitlab Web页面，退出当前root用户，使用dev账户及密码进行登录，第一次进来需要重新设置密码：
点击上图中右侧的蓝色按钮，开始处理请求。这里面一般填写Description就是写一些话告诉你的上一级领导，你接下来需要它干嘛，这里写你需要合并V0.1代码至Master主分支上面，然后一定需要选择Assignee对象为lead，就是让他来处理你的请求。
接下来回到Gitlab Web页面，退出当前dev用户，使用lead账户及密码进行登录，第一次进来同样需要重新设置密码。可以看到lead用户就有一个合并请求和代办事项了：
点击Merge按钮同意合并：
在底下顺便写一些话，然后点击提交。也就是在我们确认这个Merge申请后，填写一个回复告诉开发人员，我已经成功的将这个V0.1这个分支合并到主分支当中，请检查一下。
最后查看一下主分支是否具有了V0.1分支的代码：
那么这样，我们我成功测试了从运维人员开始创建开发人员与项目领导角色权限账号，然后开发人员的账号编写完一段代码并将该代码提交到我们的Feature分支，同时提交一个Feature分支合并到master主分支的申请，项目领导收到合并请求并审核代码后，并最终确定合并申请，这样就将开发人员的代码合并到master主分支代码中，实现了开发人员与运维人员可以各司其职、互不影响的在其所在的场景下完成代码的开发与审核工作。
Clone with SSH or HTTPS
也许仔细的你注意到了，Clone有两种方式：SSH和HTTPS，那么两者之间有什么不同呢？
首先先来查看两者对于同一个项目时的git clone链接：
1 | git@gitlab.example.com:root/first-repo.git # SSH |
其实两者的区别就是所用的协议不同，HTTPS使用443端口，可以对repo根据权限进行读写，只要有账号密码就可进行操作。而SSH使用22端口，也可以对repo根据权限进行读写，但是需要SSH Keys授权，这个key是通过ssh key生成器生成的，然后放在gitlab上作为授权的证据，这样就不需要用户名和密码了。
