Gitlab-CI 有什么玩法

[Bojie Li]

光宇说想搭建个 Gitlab-CI，持续集成这个东西我不太理解，是不是就是每次 git push 后自动编译（如果需要）、自动测试？这个编译和测试环境如何在 Gitlab-CI 中指定？这个测试环境是在虚拟机中吗，或者如何保证隔离性？是不是每次 git push，都要进行一次完整的编译测试，需要耗比较长的时间、占比较多的资源？

我感觉这种持续集成系统有助于避免开发环境与生产环境配置不一致带来的问题，也有助于减少硬编码、提高可配置性，因此想试试。望指教。

[Zhang Cheng]

2014-06-27 23:15 GMT+08:00 Bojie Li <boj...@gmail.com>:

光宇说想搭建个 Gitlab-CI，持续集成这个东西我不太理解，是不是就是每次 git push 后自动编译（如果需要）、自动测试？这个编译和测试环境如何在 Gitlab-CI 中指定？这个测试环境是在虚拟机中吗，或者如何保证隔离性？是不是每次 git push，都要进行一次完整的编译测试，需要耗比较长的时间、占比较多的资源？

我感觉这种持续集成系统有助于避免开发环境与生产环境配置不一致带来的问题，也有助于减少硬编码、提高可配置性，因此想试试。望指教。

​gitlab-ci分两部分，一个是gitlab-ci，另一个是gitlab-ci-runner。

​gitlab-ci主要是负责逻辑部分，简单的说：

* 管理项目、用户、runners

* ​展示一个网页

​gitlab-ci-runner，可以有许多个gitlab-ci-runner，任何系统都可以作为runner，通常可以创建多个虚拟机(freeshell)作为runner。​

​* 每一个runner创建后，需要运行一个程序向gitlab-ci注册，这样ci才知道这个runner的存在

* 当gitlab上有一个项目有push之后，​会根据配置向ci发送一个信号，ci会根据配置选择一个runner，向这个runner发送一个任务

​* 一个runner接收到任务后，会首先git clone这个项目（使用http的方式clone，ci会提供一个一次性的token给runner用于clone项目，所以无需为runner配置ssh key）​

* runner会进一步在这个项目的目录下运行一个脚本（不妨称为集成任务），这个任务可以是编译这个项目，也可以是执行一个make test之类的，任意事情

由于每个项目的编译环境不一样，runner上需要手动安装依赖。

例如我们有10个项目，P0-P9，分别有不同的编译依赖。​

​

​假设我们创建5个runner(记为R0-R4)，第一个runner安装了P0,P1的依赖，第二个runner安装了P2,P3的依赖，依次类推。在ci中可以配置，R0仅可运行P0,P1的集成任务，R1仅可运行P2,P3的集成任务，依次类推。此时，假设有人向gitlab push了P3，gitlab会通知ci P3有更新，gitlab会找到一个允许运行P3集成任务的runner，R1，让R1执行这个集成任务。

总结一下：

* ci是一个管理业务逻辑的组件。它自己没有用户系统，当用户登陆时，它会将用户名密码发给gitlab验证，验证通过后，会将这个用户的项目信息同步过来。用户可以配置哪些项目需要运行集成任务。​

* ci也负责维护一个runner列表。

* ci会记录下所有历史上运行过的集成任务脚本的输出，以及运行状态，并提供一个图片的url，显示最后因此集成任务运行的状态（成功、失败、运行中），大家在github上可能经常会见到这样的图标。我已经无法登陆原来公司里的ci了，所以无法提供截图样例了。

* runner是实际运行集成任务脚本的机器，通常可以用虚拟机来做。我见过一些集成环境，例如saltstack使用jekins，他们做测试更加复杂，会动态申请一个aws的instance，将代码放进去运行一系列测试脚本，完了再销毁这个instance。不过要注意，这里提到的动态申请的instance不是jekins的runner，而是runner在运行脚本时创建了一个instance。

再说一下使用，我用gitlab-ci其实也不够多，当时gitlab-ci还是挺buggy的，有时候不知为何不会被触发。说一下我在使用github时见过的ci服务（不是gitlab-ci），当时我向saltstack发了一个pull request，立刻就触发了jekins进行测试，包括代码风格、语法检查以及其他的单元测试。如果这个测试失败，会自动拒绝这个pull request，只有测试成功后，才会有项目管理员来处理这个pull request。

我在使用gitlab-ci时，印象中pull request也会触发ci的，但是有时候不知为何触发不了，感觉其完成度还不够，不过至少是一个能用的产品了。

--

Cheng,

Best Regards

[Yifan Gao]

再补充几点。以前，我自己的服务器上搭建了gitlab-CI。感觉Gitlab-CI比较适合团队使用。如果作为开放服务会带来许多问题。

1. 仅管理员可以配置Gitlab-CI-runner。由于不同的项目需要的环境不同，不可能在一个runner中安装所有编译环境，而普通用户又不能添加自己的runner，这就矛(che)盾(dan)了。

2. 安全性问题。gitlab-CI允许用户执行任意命令，虽然是以普通用户权限执行的，但还是可以干许多“坏事”。团队内部大家似乎会有所顾忌，还不太容易出现问题，但作为公共服务器，就不得不考虑这类问题了。

3. 目前的gitlab服务器性能太差，运行gitlab-ci还没问题，但运行gitlab-ci-runner就拙荆见肘了。如果要做，可能需要把runner运行在其他服务器上。

4. gitlab-ci功能比较弱，远不及jenkin。

5. 第二次运行时可以选择是git clone 还是 git pull

6. 我们可以考虑在gitlab-ci上二次开发，允许用户自己添加runner。当然，还可以在freeshell上建立一个runner模板，以便用户使用。

-- 
Yifan Gao

开启 2014年6月27日 at 下午11:15:37, Bojie Li (boj...@gmail.com) 写:

光宇说想搭建个 Gitlab-CI，持续集成这个东西我不太理解，是不是就是每次 git push 后自动编译（如果需要）、自动测试？这个编译和测试环境如何在 Gitlab-CI 中指定？这个测试环境是在虚拟机中吗，或者如何保证隔离性？是不是每次 git push，都要进行一次完整的编译测试，需要耗比较长的时间、占比较多的资源？

我感觉这种持续集成系统有助于避免开发环境与生产环境配置不一致带来的问题，也有助于减少硬编码、提高可配置性，因此想试试。望指教。

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zhang Cheng]

2014-06-28 0:49 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

1. 仅管理员可以配置Gitlab-CI-runner。由于不同的项目需要的环境不同，不可能在一个runner中安装所有编译环境，而普通用户又不能添加自己的runner，这就矛(che)盾(dan)了。

2. 安全性问题。gitlab-CI允许用户执行任意命令，虽然是以普通用户权限执行的，但还是可以干许多“坏事”。团队内部大家似乎会有所顾忌，还不太容易出现问题，但作为公共服务器，就不得不考虑这类问题了。

3. 目前的gitlab服务器性能太差，运行gitlab-ci还没问题，但运行gitlab-ci-runner就拙荆见肘了。如果要做，可能需要把runner运行在其他服务器上。

4. gitlab-ci功能比较弱，远不及jenkin。

5. 第二次运行时可以选择是git clone 还是 git pull

6. 我们可以考虑在gitlab-ci上二次开发，允许用户自己添加runner。当然，还可以在freeshell上建立一个runner模板，以便用户使用。

​是的，针对你的第二点的顾虑，所以runner最好放在虚拟机上，而且可以开许多个，其实runner并不占太多的资源，也就是执行集成任务的时候需要一些资源，其他时候全都是闲置的。在以前我们公司内部有虚拟机之前，我是用chroot的方式，在一台机器上启动了多个runner，效果其实跟lxc差不多，只不过我没有闲置每一个chroot中进程使用的资源。​ci本身基本不耗资源，因为它几乎没有运算任务，只是管理整个系统运行的逻辑而已。

添加runner麻烦的地方在于，每次添加时都需要输入一个由ci生成的一次性token，只有管理员能获取到这个token。所以即使在freeshell上建了模板，用户也无法自助添加runner。ci的这个设计，主要是因为默认添加的runner可以用于所有项目，所以有泄露隐私的隐患，因此只有管理员可以添加runner。我觉得这方面可以做开发，例如用户可以添加自己的runner，但这个runner仅能用于自己拥有的项目，做完这个开发后，可以向上游提交，感觉上游在ci上的开发人力不够。

--

Cheng,

Best Regards

[Yifan Gao]

其实有一种比较简单的方案：

1. 将普通用户权限方案更改为管理员配置
2. 移除用户project页面的所有权限
3. 为runner增加owner字段
4. 删除runner时增加 判断owner的逻辑

-- 
Yifan Gao

开启 2014年6月28日 at 上午12:58:04, Zhang Cheng (steph...@gmail.com) 写:

[Yan Wang]

之前的讨论里也提到jenkins的功能比gitlab-ci更强，有没有特别的理由让我们向gitlab-ci里投入精力而不是直接上jenkins呢？

--

[Yifan Gao]

其实gitlab-ci还是有一点点优势的

1. 与gitlab整合的较好

2. 界面甩jenkin几条街

-- 
Yifan Gao

开启 2014年6月28日 at 上午2:29:34, Yan Wang (gra...@gmail.com) 写:

[Zhang Cheng]

2014-06-28 2:29 GMT+08:00 Yan Wang <gra...@gmail.com>:

之前的讨论里也提到jenkins的功能比gitlab-ci更强，有没有特别的理由让我们向gitlab-ci里投入精力而不是直接上jenkins呢？

​gitlab-ci目前还只是一个非常​naive的工具。

jenkins很老牌了，而且跟各种主流project management/issue tracker都集成的很好，所以在大型的团队里一般会选择使用jenkins。

但目前gitlab还没有官方支持集成jenkins（这种集成是双方的事，双方需要互相集成），jenkins看上去已经有不少插件开始支持gitlab了。我没有维护过jenkins，只是“被动”的用过一两次，所以不太清楚配置jenkins会碰到什么问题，以及jekins后台是什么样的结构我也不清楚。

--

Cheng,

Best Regards

[Guangyu Zhang]

gitlab-ci-runner只要预先配置好常用的就行了吧
比如travis-ci就是只能用它支持的

[Bojie Li]

多谢，每个 gitlab-ci-runner 是只会被分配到一个任务（即前一个任务不结束，后一个任务即使排队也不会来）吗？

如果希望做公共服务的话，能不能修改添加 runner 部分的界面和权限设置，允许 project 的 owner 和 master 为这个 project 添加 runner？这样不需要修改 gitlab-ci 的数据结构。不过有个缺点，添加的 runner 都是只为一个 project 服务的，不方便复用 runner 资源（话说回来，这样也保证了项目之间的隔离）。

这些 runner 显然不能运行在 gitlab 服务器上，需要项目所有者自己找机器（可以是 freeshell 也可以是其他服务器）添加进来。

--

[Zhang Cheng]

2014-06-28 23:36 GMT+08:00 Bojie Li <boj...@gmail.com>:

多谢，每个 gitlab-ci-runner 是只会被分配到一个任务（即前一个任务不结束，后一个任务即使排队也不会来）吗？

​这个我倒没有观察过，在公司用，没那么多项目，活跃度也很低，没出现过同时push的情况。不过应该可以这么预期吧。

 

如果希望做公共服务的话，能不能修改添加 runner 部分的界面和权限设置，允许 project 的 owner 和 master 为这个 project 添加 runner？这样不需要修改 gitlab-ci 的数据结构。不过有个缺点，添加的 runner 都是只为一个 project 服务的，不方便复用 runner 资源（话说回来，这样也保证了项目之间的隔离）。

​没看过gitlab-ci的实现。我猜测gitlab-ci那么实现的原因是，gitlab本身是为企业内部或者小团队使用设计的，所以从公司的保密需求来说，可能由管理员统一管理runner最好。

但是修改gitlab-ci应该不是很难，只是我现在想想，这样的修改上游不一定会接受。

 

这些 runner 显然不能运行在 gitlab 服务器上，需要项目所有者自己找机器（可以是 freeshell 也可以是其他服务器）添加进来。

​要运行在gitlab服务器上也没啥问题，可以用chroot隔离。以前我在公司里还不方便创建虚拟机时，就是使用的chroot的方式创建运行了多个runner。

--

Cheng,

Best Regards

[Bojie Li]

如果管理员统一管理 runner 的话，项目团队如何维护编译测试环境呢？比如某项目多了一个依赖库，还要麻烦管理员去安装？

--

[Zhang Cheng]

2014-06-28 23:55 GMT+08:00 Bojie Li <boj...@gmail.com>:

如果管理员统一管理 runner 的话，项目团队如何维护编译测试环境呢？比如某项目多了一个依赖库，还要麻烦管理员去安装？

​​

在公司里的话，一般会由IT或者运维来负责编译的事情。开发者原则上是没有权限提供编译好的二进制上线的，上线的二进制应该是由CI工具编译生成的。

通常应该是开发者提出需求（例如对编译、测试环境有哪些需求），运维负责搭建相应的环境，QA团队会检查编译、测试的结果（包括开发者提出的编译依赖，原则上也是需要审查的内容）。

​

--

Cheng,

Best Regards

[Bojie Li]

哦，原来公司里开发者是碰不到生产服务器的啊。我还以为运维团队是负责搭建 IT 基础设施，项目团队从“私有云”里申请了资源就可以随便用了呢。不过这样有个问题，如果线上发现个 bug，怎么解决？是运维把开发者叫来一起解决吗？项目上线之后，如果开发者需要调整参数（例如机器学习的算法）或者拿日志来分析，也要麻烦运维？

--

[Zhang Cheng]

2014-06-29 0:17 GMT+08:00 Bojie Li <boj...@gmail.com>:

哦，原来公司里开发者是碰不到生产服务器的啊。我还以为运维团队是负责搭建 IT 基础设施，项目团队从“私有云”里申请了资源就可以随便用了呢。不过这样有个问题，如果线上发现个 bug，怎么解决？是运维把开发者叫来一起解决吗？项目上线之后，如果开发者需要调整参数（例如机器学习的算法）或者拿日志来分析，也要麻烦运维？

​不同规模的公司，不同的技能分配，实际的运作模式也会有差别。在便利性和规范性之间需要折中。

​从最严格的规范来说：

​* 应用开发者永远不能接触线上的机器，但可以访问到所有他们应用输出的日志，以便调试。

* 原则上上线后就不允许调试，如果线上出现问题，那就属于事故。

* 一个应用在上线(更新)前需要​进行严格的测试，包括自我测试、自动化测试以及QA团队的测试。特殊情况下也可以部署一些测试服务器，将部分线上的流量切到测试服上，不过原则上这也是要算作常规的上线了。

​* 所有线上的操作都必须运维执行。

* 在较大的项目中，比如在阿里巴巴，往往一次上线会更新几十个甚至上百个小组件，各组件之间有着很复杂的依赖关系。通常会有专门的人负责理清各组件之间的依赖关系，并制定上线的流程以及中间任何时候出问题时的回滚方案。上线流程必须按照计划进行。所以，任何一个小组件都不能独立更新或者回滚，这都是牵一发动全身的事。我见过一次阿里巴巴上线前的依赖关系图，真的很复杂。

* 运维通常可以分类，有基础运维和业务运维。基础运维或者开发运维主要负责与应用无关的事情，例如硬件、系统、路径规范、架构等事情，应用运维则需要对应用逻辑有非常充分的了解。举例说，我之前的公司里，有一天晚高峰时，发现CDN带宽远高于预期，运维收到报警后（CDN带宽高的报警一般不会发到应用那里），迅速分析日志，定位到资源是一个聊天系统加载的，但是这个聊天系统当天并没有更新，经过分析后确认问题是由后台聊天分房间的算法问题导致的。这个例子里，CDN带宽的异常报警无论如何不可能发到后端分房间应用的开发者那里，因为没有直接的关系。所以应用运维就必须熟悉各应用的业务逻辑，知道各业务之间都是如何运作的，会使用哪些资源，并能快速定位问题。

在实际情况下：

* 可能不是所有的运维都能熟悉应用业务路基，可能有些应用开发者有较强的系统维护能力，所以有些开发会直接接触线上的机器。

* 许多公司的应用很少，依赖远没有阿里巴巴那么复杂。所以临时升级/回滚某一个应用是没有问题的。

* 在小公司里面，可能没有完善的测试流程，没有QA团队，所以经常会将有问题的应用发布上线，上线后发现bug需要紧急修复。

​各种情况很多，所以在便利性和规范性中间有个折中，看公司的规模、成员能力的分布等不同的因素，折中点会不一样。

​

--

Cheng,

Best Regards

[Yifan Gao]

只是讨论不太直观，刚搭了一个测试用的Gitlab-CI，位于 freeshell ，大家可以试试

注：目前runners安装了gcc g++ make cmake autoconf automake openjdk  maven ruby golang python django 

在 2014年6月27日星期五UTC+8下午11时15分38秒，Bojie Li写道：

[Bojie Li]

2014-06-29 16:03 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

只是讨论不太直观，刚搭了一个测试用的Gitlab-CI，位于 freeshell ，大家可以试试

注：目前runners安装了gcc g++ make cmake autoconf automake openjdk  maven ruby golang python django 

赞！刚才添加了一个 nodejs project，但 build 状态一直是 pending。系统中只有两个项目，另一个项目目前还没有 build，为什么这个还在 pending 状态？

另外，build 是以什么用户的身份进行的？有没有权限安装软件包？

[Yifan Gao]

在 2014年6月29日星期日UTC+8下午6时37分56秒，Bojie Li写道：

这是由于runner配置出错了，现已修正，node.js 目前处于building状态

另外，build 是以什么用户的身份进行的？有没有权限安装软件包？

build是以gitlab_ci_runner用户身份进行的，目前没有权限安装软件包，但可以考虑给用户增加sudo权限（只允许以root执行封装好的apt-get-install命令） 

不过增加这类权限是危险的，如果检查不严格，可以执行apt-get purge 等破坏性命令。