频道栏目
首页 > 系统 > 其他 > 正文

谈持续集成的详情介绍

2018-01-10 10:04:18      个评论    来源:Frank的博客  
收藏   我要投稿

我们必须先明确一点,持续集成大体上是有这样几个步骤的:
1 开发者更新代码到代码仓库,触发持续集成的pipeline
2 pipeline中进行build,test,package,deploy

简单提一下Jenkins和travis

Jenkins做持续集成可以说是学习和使用成本很低的,思路也很简单。例如一个github的项目,他可以监听仓库的push来触发更新,然后运行设定好的shell语句。例如我们可以设置mvn package这样的语句,将仓库进行测试和打包,当然这需要Jenkins这台机器安装了maven并设置为了环境变量。而部署则比较灵活,如果是本机部署,直接将打包好的jar包进行复制到特定目录下,运行即可。因为都是shell所以很灵活。Jenkins的原理比较容易理解,我们甚至可以自己通过github的webhook自己写一个类似的功能。其核心思想就是代码仓库的webhook触发执行一系列的shell语句。在这些shell语句一开始运行一个git clone先把代码克隆下来,之后对代码构建,测试,打包,部署,都可以用shell去操作。这里我就不再写例子了,网上有很多Jenkins用法的教程,我以前也写过一个

travis则是github上最受欢迎的持续集成工具(插件),主要是用在开源项目的build。一般不用来进行部署,当然也可以这样做。travis需要在github仓库根目录创建.travis.ci这个文件,并指定使用什么语言。在travis官网中有介绍都有哪些语言的环境。其运行原理是,当代码push后会触发travis开始集成,首先读取这个文件,按照上面指定的语言环境申请一个临时的机器(容器),然后运行后面的脚本。可以看出travis和Jenkins不同的是他提供了很多语言环境的机器,供所有github用户使用,不需要自己的计算机或服务器。travis的例子网上也很多,我以前也写过一个

github上的开源项目只进行构建的话,travis是最好的选择。如果不用github或者不开源或者还有复杂的部署的步骤的话,用Jenkins是最稳的。虽然我们现在来看Jenkins的界面感觉像是20年前的东西,但是Jenkins却非常稳定可靠,所以仍旧是最主流的CI工具之一。

Docker为持续集成带来了革命

Docker的出现使得持续集成过程中的环境搭建问题得以解决,travis提供了多种语言的环境,直接提供一个docker镜像就解决了。在部署阶段如果用Jenkins我们可能是将打包好的程序复制到指定目录然后运行。如果使用docker,我们甚至直接将打包好的程序连同运行环境构建成一个docker镜像。然后将这个镜像传到私有仓库,或者直接部署这个镜像就可以了。

DaoCloud

Daocloud是一个国产平台,他在docker容器的管理编排和利用docker做持续集成方面都有建树。他的持续集成方式也是监听代码仓库的hook,目前可以接入github gitlab coding等平台。push代码后触发pipeline,这个pipeline是图形化添加的,也可以通过根目录下daocloud.yml编辑,效果一样。可以选择自定义环境进行各种构建和测试,就是自己写一个docker镜像名,然后写shell脚本。这样我们可以完成各种测试和构建任务。除了代码构建任务,DaoCloud还提供了docker的构建任务,默认就是将根目录下的Dockerfile进行构建(可以修改),并按照git版本号命名为这个docker镜像的版本号,这个docker镜像会存到属于自己这个账号的空间下,且默认是私有的,非常方便。至于打包和部署,自定义的流程中可以设置“输出”将打包好的程序如jar包或者dist目录等输出,这个输出会在依赖于这个流程的流程中下载下来,放到原来的目录下。最后部署则直接将这个docker部署到自己的主机上即可(当然要事先用daocloud提供的脚本绑定一下主机)。

这个平台的优点非常明显,国内速度非常快,而且非常实用,提供了镜像仓库配合平台使用速度更快。另外daocloud本身是容器编排的一个工具,对于持续交付的最后一环节可以替换已经部署的docker。代码仓库如果放在coding,持续集成放在daocloud,那在国内环境下应该是最快速docker的持续集成搭配了。要说缺点的话,这个平台是基于docker进行构建和部署的,而且必须使用docker,再有就是不能自己在局域网安装,这个是基于云平台提供的服务,所以不能在私网内单独使用。

GitLab

Gitlab的持续集成是通过根目录下的.gitlab.ci进行的,这个文件的写法和daocloud.yml类似也有自己的一套dsl,且用法更复杂。这个文件中你可以定义CICD的阶段,和每个阶段运行的脚本。oh,环境怎么办,你可以写在脚本最开始安装apt-get install xxxx。这个例子就是这样。当然这是不用docker的情况下,如果使用docker就变得简单很多,直接在开始指定image,之后的步骤都在这个镜像中运行。这个例子就是基于docker image运行的。当然我们还应该想到的是package后的程序包怎么传给下一个流程,就像daocloud通过“输出”+“依赖流程”解决了这个问题。gitlab中也采用了类似的“artifacts”+“dependencies”,默认不加dependencies就可以一直传输的。artifacts还可以设置时效等属性,参考文章。gitlab的工件(artifacts)可以在web界面中查看和下载。另外gitlab也可以实现docker的构建,即在docker in docker中运行docker build即可参考。gitlab为每个仓库都提供了一个docker仓库。在最后的部署问题上,gitlab比较自由,需要自己写shell脚本进行部署。gitlab执行这些任务的机器可以是他给提供的机子也可以是自己的一台linux机器(注册到仓库下即可)。

Gitlab本身是git仓库,daocloud本身是编排docker的工具,所以gitlab和代码的提交触发天然融合,通过docker进行持续集成持续交付的工作,最后的部署是较为自由shell指令。而daocloud则和自动部署天然集成直接将更新后的代码按照git版本号生成一个新的镜像,并可以替换原来的镜像。还可以写docker-compose进行多容器部署。Gitlab的功能是更强大的,ci文件的语法非常多,而且gitlab有很多贴心的设置。另外很重要一点是gitlab服务器可以在本地自己搭建,运行在私网中。

不要盲目的崇拜docker

docker容器的概念慢慢变成一种时尚,但是这种时尚不一定适合所有项目。比如你是个web应用用户上传的头像等数据直接就保存在了源码仓库的img文件夹下。如果你部署在docker中,docker镜像升级后意味着用户头像的全部丢失。对于这种集中式的小项目还是不推荐使用docker。一般只负责提供服务不进行数据存储的服务可以单独封装成docker看做是一个微服务,这种无状态的应用是非常适合使用docker的。

小结

对于持续集成持续交付,如果项目不大服务器就一台,选择coding管理代码+Jenkins持续集成是最稳健,而且学习和使用成本最低的。如果你的应用使用了docker,那coding+daocloud是非常不错的选择。如果你的代码不能放到别的服务器,那就git本地仓库+Jenkins。如果上一种情况下你还要用docker那你可以专门找一台机子搭建个公司内网的gitlab服务器。gitlab除了CICD还有很多强大而丰富的功能一定不会让你失望的。

上一篇:Docker Swarm 入门学习
下一篇:nginx的使用操作步骤及配置教程
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站