5. 效果图文详解

　　在2.3这个章节中，我们当时的操作如下，这个目的是向Git提交更新代码。

　　当时并没有细说后续发生的事情，既然上面已经说清楚了原理，那我们就可以接下来说说实际发生的事情啦。

　　5.1 上传代码到Git

　　这里貌似整个过程已经完成并顺利退出。其实，后台的工作才刚刚开始哦。

　　这时会触发Git服务器向相应的Jenkins服务器发出一个操作请求，此工作太过迅速，也没啥好说的，我们接下来看Jenkins都干啥子了。

　　5.2 Jenkins进行的精彩互动

　　如下这个自动运转的过程，让我们有些许成就感，值得端杯咖啡(如果不喜欢茶的话)，静静观赏。

　　1)Jenkins会自动”冒出来”一个构建任务。

　　2)我们点进来，看看具体操作日志。是的，正在接受来自Git的任务。

　　3)下载Maven相关的软件包(就是这个过程慢)。

　　4)下载完成后，就开始利用maven BUILD 新的hello项目包。

　　5)然后重建Maven容器，构建新的Image并Push到Docker私有库中。

　　6)最后，重新把Docker容器拉起来。这样，又新生了。呵呵

　　6. FAQ

　　问题1：采用这么相对复杂的办法(而不是把更新代码放在宿主机然后卷组映射)，是因为项目基于JAVA么;是否PHP项目就可以采用更新代码放在宿主机然后卷组映射这种方式?

　　回答1：将代码拆分出容器，违背了集装箱原则。导致装卸复杂度增加。从货运工人角度考虑，整体才是最经济的。一切版本化。抛弃过去的文件分发。这是正途。至于文件大小，大的war包也就50M或100M，在现有网络下不成问题，性能问题最好优化。另外建议关注docker 2 docker，p2p传输。

　　问题2：如果整体代码超过500m或者1g以上，整体集装箱是否就不太好了?如果容器与代码分离，镜像就100m左右(2层，base+服务)，然后代码的话，是放到共享存储里，每个代码有更新，比如svn的代码，可以直接在共享存储里进行svn update就可以控制版本

　　回答2：如果你的代码500M，那只能说明业务开发该打板子了。

　　问题3：如果测试环境使用您提供的完整集装箱服务还行，但在生产环境，集群里运行docker做应用，如果每个容器都是有完整的代码，是否有点臃肿，不如每个集群节点里就运行基础服务镜像，通过卷组功能绑定共享存储里的代码，加上Crontab、Python和Shell脚本，这样每次代码更新就1次就行了。

　　回答3：环境一致性，在过去从来没有解决好。10年前我们做paas时，和这个做法类似。不是说不好，时代变了，用脚本东拼西凑，终究难有好的系统。不能只考虑现在的方便，容器技术和vm如果类比，我觉得会让自己下决定时很纠结。

　　补充3：脚本一般是典型的运维工程师思维，quick & dirty。一般很难做成一个产品或者系统。整体考虑和扩展性考虑都比较少。现在做docker的难点在于到底怎么看待它。到底是拿它做调度的基本单位，还是部署的基本单位?考虑清楚，再聊方案。

　　备注：上述问题的回答，主要由王利俊@cSphere和陈尔冬@华为完成。

　　关于作者

　　萧田国，男，硕士毕业于北京科技大学，触控科技运维负责人。拥有十多年运维及团队管理经验。先后就职于联想集团、搜狐畅游、智明星通及世纪互联等。曾经的云计算行业从业者，现在喜欢琢磨云计算及评测、云端数据库，及新技术在运维中的应用。主张管理学科和运维体系的融合、人性化运维管理，打造高效、专业运维团队。

　　张春源，目前任职cSphere。国内最早期的Docker实践者，在生产环境拥有一年多的Docker容器管理经历。深刻理解Docker对于开发、测试以及运维的价值。擅长利用Docker构建整个DevOps自动化平台。热爱专研Dockerfile这门艺术，并对CoreOS有深入研究。

　　欢迎关注“希云cSphere”微信公众号，以第一时间获取本系列视频的最新内容，并获得第一手的Docker容器管理方案。实战视频：http://v.qq.com/page/x/0/y/x0160ip5e0y.html