基于Docker的Jenkins pipeline工作流
2020-03-27 来源：多智时代
1、传统我们的项目开发模式是产品调研提出需求，开发团队研究决定开发方案选型。然后开始一个周期的开发，模块开发完成之后开始模块间的联调。联调结束之后打包交付给测试团队。测试团队，系统测试或自动化测试，然后提交bug，开发团队修复bug，周而复始。
2、传统的模式中，存在着较多的不确定因素。例如，开发环境、编译环境、测试环境、生产环境，等不确定因素。人为介入打包中的不确定因素，缺乏单元测试和自动化测试的整合。从而导致的结果是，开发-测试-修复的周期较长，而且很多小的问题完全可以由单元测试进行覆盖。
持续交付并不是某个特定的软件，而是一个结果。这个结果要求团队可以随时的发布一个新的准确版本，而且要求在编译发布的过程中进行自动化测试，通过自动化测试可以及时的发现并定位存在的bug，修复bug之后再进行快速的发布到测试环境，测试团队直接进行测试。
与传统模式的区别在于持续交付可以提前发现bug的存在和快速修复而不必等到测试人员的介入之后才发现。持续交付分解出来就是“持续”和“交付”。 持续 :持续要求任何时，候任何情况都能进行准确的发布，做到准确的发布需要注意以下几个关键点。
持续应该是一个周期性的，可以是每天的某个时间点，也可以是某次代码的提交，或者某次人为触发。所以人工进行构建是不可能的，需要自动化的构建，自动化要求构建的任何一个流程都必须以脚本的形式运行，代码检出、代码构建、各模块代码单元测试、集成测试、UI自动化测试等。
发布的程序版本不允许是各个模块在开发环境编译出一个版本作为交付，而要求在一个纯净的编译环境中进行构建。
构建的过程应该要求最大可能的固化，例如操作系统的版本，构建环境的版本，相关的依赖等。
避免从网络获取相关的文件，这点以nodejs为开发或编译的项目尤其重要，安装node的依赖包总是一个漫长的过程，就算有国内的源，一般的项目也需要一两分钟的node依赖包，这不符合快速构建。
交付 : 在持续编译的过程，使用自动化已经可以避免大多数的错误了。但是还是需要人为介入的系统测试，毕竟自动化的测试一般只能覆盖到70%左右。
根据我们团队内部推广这种工作方式的效果来看，持续集成确实让我们工作便利了许多， 每次代码的构建和自动化测试让我们及时发现存在的bug。好的工作模式也需要团队成员的遵守，团队成员应该积极的拥抱这种工作方式，团队成员需要做好以下几点。
使用版本工具例如git。git有强大的版本回溯，成员每次完成一个小的功能点进行代码提交。合并到master分支，持续交付工具应该配置为代码更新触发。团队内部应该等到持续交付流程结束之后，确认编译、自动化测试通过之后方可进行下一个版本的提交，这样容易定位bug。而不会导致这次bug影响团队内其他成员的工作。
主分支的代码bug不应该存留时间过长，避免团队内其他成员合并代码的时候引入其他问题。
测试驱动开发，任何一个新的功能开发都应该先写好单元测试脚本，并积极更新自动化测试脚本。并且积极地拥抱测试，虽然你明白这个测试不通过的问题并不会引起很大的系统性问题 ，但是还是应该进行修复而不是想方设法的跳过这个自动化测试。
临近下班的时候不要提交代码，这主要是因为遵守第2点。
Docker已经越来越火，CICD和Devops也是Docker一个重要的场景。在持续交付中使用Docker有一下优点。
Docker强大的环境隔离性可以将环境和程序打包在一起，测试、运维，人员无需知道我们的程序是如何配置的，只需要一条docker 的命令就可以将我们的程序运行起来，这也更加容易实现持续部署。
减少编译环境的污染，因为Docker天然的隔离性，也避免了传统编译环境难以配置多套编译环境的问题。在基于Docker的持续发布中，我们可以在同一台宿主机上同时编译不同版本的Java项目，不同版本的Python项目，而无需任何配置，镜像也只是从docker hub中获取。
持续集成
在持续集成方面，我们选择Jenkins。Jenkins是一款开源软件，拥有众多优秀的插件，依靠这些插件，我们可以完成一些周期、繁琐、复杂的任务。例如我们今天分享的持续发布，虽然Jenkins解决了我们繁琐复杂周期性的操作，但是没有解决我们在多种环境下编译构建的需求。而这个场景正是Docker的强项。
通过Jenkins的pipeline我们可以实现代码检出、单元测试、编译、构建、发布、测试等流程的自动化，而最终通过Jenkins的Docker插件将产出物构建成镜像，方便部署到Docker环境。
持续部署
持续集成让我们新的代码源源不断的构建成了镜像，这些镜像经历了单元测试，自动化测试，但还没有接受过测试团队的严格测试。Jenkins是一个强大的持续集成工具，然而持续部署并不是Jenkins的强项，但是Jenkins拥有很多强大的插件。22.而且我们持续集成产出的是镜像，所以持续的部署，我们只需要将镜像运行起来，或者利用第三方的容器管理平台提供的API进行部署。
本地部署应用到Docker:本地部署到Docker容器可以使用Jenkins的docker插件，下面会介绍。
部署到远程主机的Docker、Appsoar。Docker和Appsoar都支持开启API调用。通过现有的API我们可以运行我们生成镜像版本。从而达到持续的部署最新版本。
部署到kubernetes。kubernetes除了可以通过API调用还可以在jenkins中配置kubectl的方式创建或更新deployments。
Docker中运行Jenkins: Docker部署Jenkins的方式简单方便，下面我们介绍用Docker的方式运行Jenkins。
这里将docker.sock和docker的可执行文件挂载到jenkins容器中，这样我们就可以在容器中使用docker了。
jenkins容器，默认的用户是jenkins因为我们需要使用docker所以我们需要使用root用户。
/var/jenkins_home的挂在卷是可选的，jenkins_home存放了所有任务、日志、认证、插件等jenkins运行后的文件。可做数据恢复使用。
配置Jenkins
解锁jenkins:解锁的密码在容器的log中可以查看，或者直接查看jenkins_home指定文件
选择插件
创建Pipeline
下面我们创建一个的Jenkins的Pipeline完成简单的cicd流程。
新建pipeline，在左侧新建选择pipeline。
在左侧的Credentials中新建git和镜像仓库的credentials
配置pipeline，例如定时触发，代码更新触发，webhook触发等。
在pipeline script中填入下面的demo.
以下是伪代码，仅提供思路
Jenkins pipeline的脚本语法是groovy的语法，其中docker 、Git是插件提供的能力。代码的执行流程如下：
通过Git插件获取最新代码到jenkins的工作区,例如`/var/jenkins_home/workspace/pipelineDemo。
docker.image().inside是如何编译我们的代码呢，通过查看Jenkins的console 可以看到如下log.
通过docker插件提供的能力构建镜像，Dockerfile存放在代码目录中。构建镜像后push到镜像仓库，私有仓库需要自行配置镜像仓库。
镜像构建完成之后就可以删掉旧版本，并重新运行一个新的版本。
熟悉Docker命令的朋友应该很容易理解了，原来是docker.image().inside启动的时候会将当前的目录挂在到容器中，然后在容器中执行./script/build.sh，这样我们就完成了利用容器中存在的环境做单元测试或构建编译了。
通过简单的例子，可见Jenkins和Docker的结合给CICD带来了足够的便利和强大。我们需要准备的只是一个编译的脚本，在编译脚本中可以使用任何的环境和任何的版本。
Pipeline 介绍
Jenkins 的任务两个主要版本。
free style 只是一个自动化的脚本，脚本类型为shell。所有的脚本在一台机器上运行，需要的环境需要提前准备。配置不集中，混乱。但是一般情况下还是够用的。
pipeline 是jenkins2的版本使用了一个基于groovy脚本的任务类型，通过一系列的stage 将构建的不同部分组合成一个pipline。而且配合step可以完成异步操作。因为基于groovy可编程性更加
强大，而且脚本可以存放在源码中，脚本的更改不需要直接到jenkins中修改。
pipeline的一些使用经验和技巧
jenkins的资料较少，官网可以查看的内容也不多，一般的需求Jenkins内置的pipeline-syntax里面就有常用的命令生成器。可以满足大多数需求。
在pipeline脚本调试完成之后应该将脚本以文件的形式放在源码目录中，这样子方便修改。和多分支需要编译的情况下进行互相隔离。
应该多查找下相应的插件，而不是使用sh用执行脚本的方式来解决问题。
应该将jenkins_home目录挂在出来，如果遇上了Jenkins崩溃了可以及时的恢复数据。
应该新建一个定时的pipeline用来清理生成的镜像，减少硬盘资源的占用。
页面新建的pipeline,在页面删除之后，jenkins_home/workspace中对应的项目文件并不会被删除。
版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。
下一篇:在非容器环境中实现DevOps
