开拓同学通过git push上传代码，经Git和Jenkins合营，自动完成程序支配、发布，全程无需运维职员参与。
这是一种真正的容器级的实现，这个带来的好处，不仅仅是效率的提升，更是一种变革：
开拓职员第一次真正为自己的代码卖力——终于可以跳过运维和测试部门，自主掩护运行环境(首先是测试/开拓环境)
1. 持续支配的技能思路
在本例中，假设我们JAVA项目的名称为hello。简要的技能思路如下
本案例中假设代码托管在git.oschina.com上，Jenkins和Docker Registry(类似于yum源)各运行在一个Docker容器中。JAVA项目自己也单独运行在一个叫hello的容器中。
本文采纳的持续支配方案，是从私有的Docker Reistry拉取代码。有些变通的方案，把代码放在宿主机上，让容器通过卷组映射来读取。这种方法不建议的缘故原由是，将代码拆分出容器，这违背了Docker的集装箱原则：
这也导致装卸繁芜度增加。从货运工人角度考虑，整体才是最经济的。这样，也才能实现真正意义的容器级迁移。
或者说，容器时期，抛弃过去文件分发的思想，才是正途。本文末了的问答环节对此有更多阐述。
容器即进程。我们采取上述方案做Docker持续支配的缘故原由和意义，也在于此。容器的生命周期，该当远远短于虚拟机，容器涌现问题，该当是立即杀掉，而不是试图规复
2. 效果展示
本文末了实现的效果，究竟有多惊艳呢?且看如下的演示。
2.1 程序代码更新前的效果
我们以韶光戳来简洁、显式的表述程序更新情形。
2.2 提交程序代码更新
本例中，我们把首页的韶光戳从201506181750，修正为201506191410(见如下)
2.3 上传新代码到Git
顺序实行如下操作，输入精确的git账号密码
然后呢?
然后什么都不用做了。端杯茶(如果不喜好咖啡的话)，悄悄地等待自动支配的发生， 察看犹豫一系列被自动触发的过程，机器人似的运转起来(请容稍候再加以描述)。
为什么须要3~5分钟?只是由于本案例中的JAVA项目，须要从国外download Maven程序包，以供Jenkins调用和编译JAVA。正式运用环境中，可以把Maven源放在海内或机房。如果仅仅须要对PHP项目做持续支配，那就更快捷了
2.4 查看代码更新后的效果
在悄悄地等待几分钟后，新的代码确实已经自动支配完毕
3. 配置Git和Jenkins联动
3.1 Jenkins配置Git源
Jenkins中新建项目java-app，并配置从Git拉取程序代码。详细如下：
3.2 Jenkins配置远程构建
Jenkins中配置token，以供git远程调用时利用
3.3 Git开启钩子
怎么让Git在吸收到用户更新的代码后，把和任务通报给Jenkins呢?这借助于Git的hook功能，配置起来也非常大略，如下
4. 配置Jenkins自动更新代码
Jekins在吸收到Git通报过来的后，再触发一个远程构建(到目标做事器)，按照预定义的任务列表，实行一系列的事情，重修容器等。详见如下：
我们把个中最关键的Shell脚本内容摘抄出来
1)Jenkins会自动冒出来一个构建任务
2）利用maven BUILD 新的hello项目包
3）然后重修Maven容器，构建新的Image并Push到Docker私有库中
4）重新把Docker容器拉起来
6. FAQ
问题1：采取这么相对繁芜的办法(而不是把更新代码放在宿主机然后卷组映射)，是由于项目基于JAVA么;是否PHP项目就可以采取更新代码放在宿主机然后卷组映射这种办法?
回答1：将代码拆分出容器，违背了集装箱原则。导致装卸繁芜度增加。从货运工人角度考虑，整体才是最经济的。统统版本化。抛弃过去的文件分发。这是正途。至于文件大小，大的war包也就50M或100M，在现有网络下不成问题，性能问题最好优化。其余建议关注docker 2 docker，p2p传输
问题2：如果整体代码超过500m或者1g以上，整体集装箱是否就不太好了?如果容器与代码分离，镜像就100m旁边(2层，base+做事)，然后代码的话，是放到共享存储里，每个代码有更新，比如svn的代码，可以直接在共享存储里进行svn update就可以掌握版本
问题3：如果测试环境利用您供应的完全集装箱做事还行，但在生产环境，集群里运行docker做运用，如果每个容器都是有完全的代码，是否有点臃肿，不如每个集群节点里就运行根本做事镜像，通过卷组功能绑定共享存储里的代码，加上Crontab、Python和Shell脚本，这样每次代码更新就1次就行了
回答3：环境同等性，在过去从来没有办理好。10年前我们做paas时，和这个做法类似。不是说不好，时期变了，用脚本东拼西凑，究竟难有好的系统。不能只考虑现在的方便，容器技能和vm如果类比，我以为会让自己下决定时很纠结
补充3：脚本一样平常是范例的运维工程师思维，quick & dirty。一样平常很难做成一个产品或者系统。整体考虑和扩展性考虑都比较少。现在做docker的难点在于到底怎么看待它。到底是拿它做调度的基本单位，还是支配的基本单位考虑清楚，再聊方案
