Docker结合Jenkins的持续构建实践

lifefriend_007 发布于2019-06-28 15:01 / 875人阅读

摘要：此步的产出分支特定版本号自动构建自动构建代码包做法也很通用了，将的钩子同结合，达到特定分支有时机触发自动构建，将代码包从拉取并打包为代码包。

docker和Jenkins不是什么新东西了，两者结合也不是什么稀奇的事情，也已经有很多Jenkins和docker相结合的文章，此文仅为自己的一点心得实践，如有不对的地方，欢迎大家纠正。

先贴上大致的流程图，逐步说明：

代码-Git：

并没有什么好说明的，就是简单的使用了Git作为版本控制工具而已，通用使用规范不在细说。
此步的产出：
Git分支特定版本号

Git-自动构建、自动构建-代码包：

做法也很通用了，将project的Git钩子同Jenkins结合，达到特定分支有push时机触发自动构建，将代码包从Git拉取并打包为代码包。

此步产出：
打包好的代码包：project.tar.gz

代码包-Docker镜像

在此步中，我们为每个project提供特定的测试环境，并且在此环境中执行项目代码镜像打包操作。在此步中，需要提前准备几样东西：

测试环境：我们这里为一台干净的服务器（不要再问好奢侈，有钱就是任性），部署docker环境；

project的base镜像：对于一个成熟的项目，所依赖的环境是固定可知的，因此提前准备好其所依赖的base image是必要的。
如，我们一个项目的base image的Dockerfile:

FROM centos:liuyanglong
MAINTAINER liuyanglong "liuyanglong@xxxx.com"
MAINTAINER version "online"

USER root
ADD php.ini /home/work/local/php/etc/
ADD php-fpm.conf /home/work/local/php/etc/

ONBUILD ADD project-code.tar.gz  /home/work/
ONBUILD ENTRYPOINT ["supervisord", "-c", "/etc/supervisord.conf", "-n"]

注意最下面的两行ONBUILD
而在每一次Jenkins的构建时，要做的仅仅是将代码包传入，并且执行docker build即可，此时build所使用的Dockerfile的内容只有一行：

From this_project_image:base

而执行build时只会根据base image中的两行ONBUILD执行两个命令：

ADD project-code.tar.gz  /home/work/
ENTRYPOINT ["supervisord", "-c", "/etc/supervisord.conf", "-n"]

注意：此步仅仅在测试服务器做了docker build操作，并没有执行docker pull！！

镜像打包完毕后，此步并没有结束！！

调用脚本，根据此构件号的版本docker image创建对应的容器，脚本的输出为其对应的访问方式，供QA同学测试使用。
这样，每个构建好的版本都有对应的测试环境，且互不冲突！
鄙人的脚本地址为：https://github.com/Liuyanglong/docker-tools/blob/master/create_docker

此步的产出：

docker build成功的project image，如以构建号为image版本号，叫做： project_dev:530

此版本代码的测试环境地址，如：172.30.40.2

生成线上镜像

到上一步为止，测试构建环境已经结束，当QA同学确定要上线时，执行Jenkins的Promotion操作，这时触发此步，将对应build版本对应的docker镜像推送到 私有docker registry。
所执行的操作自然为：

docker tag project_dev:530  docker-registry.xxxxx.com/xxxxxxx/project_name:version
docker push docker-registry.xxxxx.com/xxxxxxx/project_name:version

此步产出：
push好的线上镜像

AB上线

此为最后一步，同样是执行promotion操作后最后所执行的步骤，调用我们的内部接口，对线上应用执行AB上线，具体可参见文章：http://segmentfault.com/a/1190000002978115#articleHeader6

总结

上述就是我们在生产环境中的使用Jenkins和docker所构建的持续集成&自动部署的逻辑架构。也欢迎各位大大拍砖指教。

云服务器 GPU云服务器 jenkins持续集成个推持续集成最佳实践 docker与jenkins docker 持续集成环境

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/26468.html

优势+工具+实践=DevOps&Docker的企业级落地

摘要：的设计模式的设计模式以持续集成持续测试持续交付和持续部署为中心，自动化协作和持续监控是中使用的一些其他设计模式。持续集成持续集成是不断地将源代码集成到一个新的构建或发布的过程，源代码可以在本地存储中，也可以在或中。 showImg(https://segmentfault.com/img/remote/1460000010452455); 识别二维码报名活动 8月19日，来自微软、数人...

stormjun 2019-06-28 15:54 评论0 收藏0
Docker + Jenkins + webhooks 自动部署基础实践

摘要：自动部署基础实践熟悉的基本操作实现本地后自动构建部署服务此实践用于优化自己在实际工作中的工作流在本地开发到服务器登录云服务器或者简化流程后本地开发云服务器自动构建部署本实践将结合技术来实现云服务器对各种环境的切换与部署。 Docker + Jenkins + webhooks 自动部署基础实践熟悉 jenkins 的基本操作 ☑️ 实现本地 git push 后 jenkins 自...

Charlie_Jade 2019-06-28 16:20 评论0 收藏0
Docker在开发、测试中的应用

摘要：对测试的影响让单元测试运行的更顺畅单元测试驱动开发是一个很好的应用程序开发方式，单元测试往往也是和代码一起被提交到代码仓库中。但是很多单元测试通常依赖于很多其他服务，而这些服务的标准化配置往往是一个难点，如数据库的搭建防火墙的配置等。传统的软件开发、测试、运维需要三个团队在三个不同的环境中进行，而三个环境的不同引发了很多的问题。如：工作内容的重复；开发环境中可运行的程序在测试和运维环...

mating 2019-06-28 15:15 评论0 收藏0
智能运维 | 如何做好持续集成——Jenkins on Mesos 实践

摘要：而持续集成的意义就在于减少风险，和重复的过程，最终提高工作效率。第二级调度由被称作的组件组成。能和不同类型的通信，每种由相应的应用集群管理。这是的任务启动过程。数人云运维平台持续集成实践这是数人云运维平台的持续集成实践。今天小数给大家带来的又是十足的干货：当运维遇到云计算，当Docker遇到Mesos和Jenkins，会擦出怎样的火花呢？且看来自数人云运维工程师金烨的演讲实录分享——...

lsxiao 2019-06-28 15:15 评论0 收藏0
CI Weekly #6 | 再谈 Docker / CI / CD 实践经验

摘要：阿里云效平台基于理念的私有平台实践本文将系统的从个方面，分享互娱运维团队对于运维平台实践经验及未来展望，希望对大家有一些参考意义。 CI Weekly 围绕『软件工程效率提升』进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、官...

justCoding 2019-06-28 17:49 评论0 收藏0