【阿里云ECS】GitLab的搭建配置过程和GitLab-CI服务的使用

2016-12-05

1. 前言
2. 准备工具
3. Git安装与使用
4. GitLab相关知识介绍
5. GitLab搭建配置的完整过程
6. GitLab-CI相关知识介绍
7. GitLab-CI安装配置的完整过程
8. GitLab-CI持续集成服务的测试
9. 小结

前言

　　GitHub是一个十分著名并相当活跃的社区，每天有世界各地的程序员在这里分享与交流。作为开源项目或者技术分享，我们当然可以将代码维护在这里。但是对于内部项目，我们应该具备私有仓库来进行维护。GitLab就是一个很好的选择。本文主要包括以下几个方面：

Git安装与使用
GitLab相关知识介绍
GitLab搭建配置的完整过程
GitLab-CI相关知识介绍
GitLab-CI安装配置的完整过程
GitLab-CI持续集成服务的测试
小结

准备工具

　　部署环境：阿里云ECS Centos7.0 64bit(已具备完整LAMP环境)
　　远程连接：Xshell 5
　　文件传输：Xftp 5

Git安装与使用

　　Git的安装是必要的，安装后我们可以从服务器clone下来GitLab仓库中的最新代码进行开发维护。Centos7自带Git，但是版本为1.8，考虑到使用新版本减少问题，决定升级至2.7.4。具体过程如下：

卸载Centos7自带的Git1.8
# yum remove git
下载Git2.7.4
# wget https://github.com/git/git/archive/v2.7.4.tar.gz
解压该文件
# tar zxvf v2.7.4.tar.gz
【配置】，configure用来生成Makefile，指定安装到 /usr/local/git，为下一步的编译做准备
# ./configure --prefix=/usr/local/git
【编译】，根据makefile的定义，调用源代码、函数库、编译器来编译
# make configure
【安装】
# make install
将Git添加至环境变量中
# echo "export PATH=$PATH:/usr/local/git/bin" >> /etc/bashrc
在当前bash环境下读取并执行/etc/bashrc中的每一条命令，使之立刻生效
# source /etc/bashrc

经过以上过程，Git就安装完成了，我们可以查看Git的版本：
# git --version

如下所示：

具体git知识的学习与git使用，参见廖雪峰的git教程。

GitLab相关知识介绍

　　首先，GitLab的官网是https://about.gitlab.com/gitlab-com/，这里有最权威的文档与介绍。其次，GitLab中文社区http://www.gitlab.cc/也比较活跃，可以在上面找找有没有类似的问题。
　　Gitlab是一个用Ruby on Rails开发的开源项目管理程序，可以通过WEB界面进行访问公开的或者私人项目。它和GitHub有类似的功能，能够浏览源代码，管理缺陷和注释。GitLab拥有Git仓库管理，code reviews(代码审查)，issue tracking(问题跟踪)，wikis等功能，GitLab搭配GitLab CI，能更简单的实现持续集成和自动部署。还可以使用issue，milestones，逐行code reviwe等功能进行团队协作，查看项目动态。GitLab可无缝集成Slack，Hipchat，LDAP，JIRA，Jenkins等其他流行的工具，提供了非常多的webhooks和完善的API。
　　GitLab社区版是开源的，可以免费下载使用。GitLab由超过1000人的社区维护。GitLab企业版提供深度的LDAP和Active Directory集成，以及Jira和Jenkins集成。
　　而无论是GitLab还是GitHub，都可以说是一种管理工具，其本质都是要学会Git的思想与使用。推荐廖雪峰的git教程。
　　Gitlab官方文档对于Gitlab的原理和重要组件有详细的说明，这里就不再展开了，但要推荐一位学长的帖子，他在帖子中讲述了一些对于Gitlab工作流程和重要组件的理解，值得一读。

GitLab搭建配置的完整过程

安装

　　GitLab官网上有详细的安装说明，选择操作系统版本后按步骤操作即可。但是阿里云主机无法连接GitLab Yum源，因此选择rpm包安装方式。

使用curl命令获取相应文件
# curl -LJO https://mirror.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-8.5.4-ce.0.el7.x86_64.rpm
rpm方式安装
# rpm -i gitlab-ce-8.5.4-ce.0.el7.x86_64.rpm
结果如图：

配置

　　我们在上一篇文章的“phpMyAdmin的安装与配置 3.测试”中提到，由于我的网站线上环境、GitLab都是搭建在一台服务器上的，因此在默认情况下会产生端口冲突。于是做出如下处理。

修改Apache端口为4040
使用命令：
# cd etc/httpd/conf/
# vi httpd.conf
注释掉Listen 80，改为Listen 4040
配置GitLab
GitLab的配置文件默认位于/etc/gitlab/gitlab.rb
使用命令：
# cd /etc/gitlab
# vi gitlab.rb
在该文件的一开始就有关于external_url的配置，这里我填的就是我的阿里云ECS主机的ip地址。

这里注意，在配置url时直接指定一个未被占用的端口即可。如果不指定端口（仅填写域名或者IP地址），那么默认的是80端口，此时就必须保证Apache使用的不是80默认端口（修改方法见上述内容），否则冲突。
配置完成后，还要使用如下命令使之生效：
# gitlab-ctl reconfigure

测试

　　按照上述过程，GitLab本身的基本配置就可以了。打开浏览器输入external_url地址访问GitLab，却出现了如下界面：

原因：
查阅了相关资料，引起502的原因多样，比如设置的超时时间过短等。经过排查，我这里遇到这个问题是因为阿里云centos7默认的虚拟内存swap交换分区设置过小导致的。
解决方法：
增加系统的swap分区：

新建一个分区，创建/home/swap分区文件。文件的大小是1024000个block，1个block为1024，所以这里空间是1G
# dd if=/dev/zero of=/home/swap/swap bs=1024 count=1024000
将该分区格式化成swap分区，使其成为有效状态
# swapon /home/swap/swap
查看最新的分区情况：

发现swap分区已经创建成功。但这里还有一个问题，当系统重启后，这块分区将会消失。为此，我们需要将新分区设置为开机自动挂载。/etc/fstab文件正是负责配置Linux开机时自动挂载分区的，对其进行修改。
使用命令：
# cd /etc
# vi fstab
在最后增加如下一句：

1	/swap/swap/swap swap swap defaults 0 0

配置完分区后，再次访问external_url的地址，就可以看到正常的GitLab登录页。默认用户名：admin@local.host，密码5iveL!fe，登陆后可修改。

GitLab的管理员面板(Admin area)如下，在这里我们可以新增成员，创建项目，新建分组，邀请成员进入项目，项目持续集成配置等等，具体的问题可以进行相应搜索。

至此，我们就成功搭建了GitLab~

GitLab-CI相关知识介绍

　　目前，我们已经拥有了自己的GitLab仓库，可以进行正常的开发和版本控制了。我们现在需要考虑这样的场景：在团队合作开发中，每天每位成员都要做出很多修改，向GitHub仓库提交大量代码，且时间不定。版本库中代码虽是最新的，可是线上部署的却没有同时更新，如果测试人员需要及时跟进，或者比如APP端的同学需要调用最新的接口进行测试，就需要手动在线上进行部署，为了保证实时性一天可能就要部署很多次，烦。
　　这种场景，当然被很多人注意到了，CI–持续集成正是说的这样的问题。

持续集成(Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

　　强大的GitLab自然也考虑到了这个问题。GitLab-CE 8.0以上的版本已经将GitLab-CI集成进了GitLab，并且默认开启。所以不需要像以前一样再单独安装GitLab-CI并且为GitLab-CI开启单独的Server。但是GitLab-Runner还是需要我们单独安装的，来配合GitLab-CI使用。为此，这部分我们来详细讨论一下GitLab-CI相关问题。
　　GitLab官网上提供了详尽的CI文档http://doc.gitlab.com/ce/ci/，可以查阅。
　　关于GitLab-Runner的介绍，这里我要引用一下那位学长的另一篇帖子中的一部分介绍，如下。

　　GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

　　所以，GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：

Runner类型
　　GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。
Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

文／tsyeyuanfeng（简书作者）
原文链接：http://www.jianshu.com/p/2b43151fb92e
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。

GitLab-CI安装配置的完整过程

安装

　　之前已经说过，GitLab-CE 8.0以上的版本已经将GitLab-CI集成进了GitLab，因此下面安装GitLab-Runner。
　　官网确实给出了详细的安装方式（针对各种操作系统）https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/linux-repository.md，但是，我也确实无论如何都无法下载下来文档中提到的yum源。。。
为此，我“换了种方式”下载了rpm包，使用Xftp将rpm文件放进了阿里云ECS的centos系统中，再通过rpm命令进行了安装，绕了个大圈，如图：

注册

　　安装好gitlab-ci-multi-runner后，我们就可以用它向GitLab-CI注册Runner了。
　　根据官网的介绍，如果我们需要注册Shared Runner，就在管理员面板Admin Area中获取token和url，如下图：

　　如果我们需要注册Specific Runner，就要在该项目的setting中的runner面板中获取token和url，如下图：

这里，我是新建了一个Specific Runner，使用命令：# gitlab-ci-multi-runner register 操作如下:

注册成功后，我们可以在/etc/gitlab-runner/config.toml中看到runner的配置信息：

但是这个配置信息在runner运行时候并没有起到实质作用，因为在接下来要讲到的运行runner中，命令中必须还要带上这个配置信息中的一些内容，可以说这个配置信息只是起到了一个记录作用。

运行

runner注册完成之后还必须让它运行起来，否则无法接收到GitLab-CI的通知或执行脚本。我们使用命令：

1	# gitlab-ci-multi-runner run-single --url http://*.../ci --token ************* --executor shell

运行配置好的runner，其中–url、–token和–executor参数是必须的，具体值与配置文件中的相同。其他参数可根据具体情况设置。

使用如下命令了解更多：
# gitlab-ci-multi-runner run-single --help

当具有多个runner，可以使用命令：
# gitlab-ci-multi-runner run
来批量运行，使用如下命令了解更多：
# gitlab-ci-multi-runner run --help

目前还有一个问题，当runner运行后，它是保持在前台的，这时候terminal不能再做其他事情，这当然不行。因此我们要把runner运行这件事做成一个服务。
使用命令：

1	# gitlab-ci-multi-runner install --service gitlab-runner --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --user gitlab-runner

将这个runner做成服务，并启动：
# gitlab-ci-multi-runner start --service gitlab-runner
这时候，在terminal中可以继续操作，查看后台进程：
# ps -aux | grep gitlab-runner
发现正常运行：

至此，GitLab-CI和GitLab-Runner配置完成。

GitLab-CI持续集成服务的测试

　　前文完成了GitLab-CI持续集成服务的配置，那么它是如何起作用的呢？
　　我们已知，我们针对我们项目的仓库已经建立了一个Specific Runner，并且将它运行起来了，runner就处于一种“监听状态”。当项目成员向仓库提交代码，runner检测到像git push这样的事件后，就会做出一些处理，实现项目的自动部署持续集成。具体的：
　　我们需要在根目录下建立一个名为.gitlab-ci.yml的文件。当整个项目进行git push的时候，runner会去检查这个文件，去执行里面的脚本。

　　我们想实现的效果是：每次提交的新代码都可以自动部署到/var/www/html目录下，这样访问网站或者API接口就可以获取最新情况。那么，其实就相当于删除原先该目录下的代码，将新提交的内容放在该目录下。这样就很清楚脚本怎么写了，只需要两句：

deploy:
  script:
    - rm -rf /var/www/html/project_name
    - cp -r ../project_name /var/www/html/project_name

解释：

使用rm命令加上-rf递归强制删除项目文件/var/www/html/project_name。

使用命令cp加上-r参数递归复制相对于当前.gitlab-ci.yml文件的上一层目录的整个项目文件，复制到/var/www/html/project_name目录。

之所以是复制../project_name目录，是因为runner检测到.gitlab-ci.yml文件时，是处于最新的工程文件夹的根目录下，这样的话../project_name就表示了最新的代码。(更多的，我们可以了解到项目文件其实是位于这个runner的子目录下的：
/home/gitlab-runner/builds/runner_name/0/root/project_name)

　　实践一下，在工程中建立.gitlab-ci.yml文件，并对项目中代码做出一些修改（内容随意，主要是想看到修改效果），检查冲突后git push。这时在GitLab中该项目的控制面板的Builds菜单中监测，发现build失败了：

查看以上日志可以发现是在删除时遇到了权限问题，没有写的权限，于是更改整个项目目录的权限为777，保证删除顺利。
之后再次git push测试，发现build成功：

(注：如果考虑直接将权限变为777这种比较暴力的方法的安全性问题，也可以采用更换文件夹所属用户组的方法，改owner为gitlab-runner：)

1	# chown -R gitlab-runner /var/www/html/ebfinance

这时，去Apache配置的4040端口去查看网站的效果，发现已经是最新代码对应的效果，说明自动部署成功！

小结

　　至此，本文的主要内容就结束了。我们拥有了自己的项目仓库并且可以自动部署持续集成，这大大提高了我们的效率。同时，这套完整的配置过程中也可以学习到很多东西，踩了不少坑，积累了一些经验，明白了一些原理，总之还是收获很大的。

gaochang.gcidea

The relentless pursuit of perfection.

搭建部署阿里云