恩，可能你现在还没有感受到 docker 的好处，这也挺正常的。刚开始接触 docker 的人多多少少都会有这个想法的。 你可以想象一下， 现在你们只有 2 套测试环境，环境也不复杂，没有多少服务，所以用 jenkins+shell 是没问题的。 如果你的环境数量扩大 10 倍，20 倍，30 倍，甚至 100 倍的话，纯虚拟机 +shell 还管不管的过来呢？模块更新的时候， 环境依赖变更的时候，服务挂掉的时候， 甚至是环境迁移的时候 (由于某种原因该服务器下线或者迁移到其他机房，这期间难道环境就这么不可用不管了么？) 还有所有这些环境的配置管理和服务发现怎么办？运维成本会变成一个噩梦，有多少人都会累的像条狗。所以这时候 docker+ 容器编排框架就体现出了无穷的优势，只要有镜像，可以迅速更新所有的环境，增容扩容也很简单，同时监控，容灾，持久化等等都做的好好的。 以你现在测试环境的规模确实是很难感受到 docker 的好处的，在这种体量下用 docker 还是虚拟机都无所谓，区别不大。

我现在用 docker+k8s 管理着一个容器集群，高峰期七八十套环境共存，加上测试服务，监控，集群管理，测试执行机器也在这里面跑着。 而运维的人只有我一个，而且我还是带搭不惜理的管着 (我平时有测试任务和开发任务)。 这时候就体现出了 docker 的巨大优势和其强大的生态圈，k8s 的自动化运维做的很强，所以我才可以这么悠闲的管着这么多环境。

我最近也用 docker 将我们整个大数据环境迁移到了 docker 容器里。不过我不是将每个服务制作成一个镜像，然后去用 k8s 编排。主要是因为大数据的服务组件实在太多，而大数据有自身的部署工具 ambari，我是借助了 ambari，先启用一堆基础容器（debian），利用 ambari 在这些容器内部署各个大数据组件，然后将各个容器 commit 成镜像，出来一套容器镜像套件。然后用了 Swarm 去做容器跨主机的调度，监控用的是 Rancher。这些工作都是一个人在搞，不知道飞哥能不能给我这种方式一些点评和指导。

目前整个集群也是支持多环境的并行，利用的是 swarm 的 label 来区分不同环境。各个环境利用 docker 的跨主机通信机制，搭建自己的私有 overlay 网络。

其实除了部署和管理的便利性，docker 还有一个大的好处是开箱即用。以前我们往线上发布的是 war 包，服务器测试运维各管各的，用了 docker 以后发布的就是一个完整的容器，使用统一的镜像就可保证所有环境参数测试环境和线上是一致的，所以说容器的特性天生就符合持续交付的要求，当然前提你线上也已经开始用 docker。如果只是两三台服务器，线上也没有用 docker,我觉得用 shell 也差别不大，但对 docker 的技术必须保持关注，毕竟这个是大势。

挺好的，够用就行，其他的服务不用都追求极致。 根据你们的需求来就行。 swarm 我当初只是在调研方案的时候搞过一个单节点的出来，了解的不深，不知道加一些容灾，持久化，7 层路由等需求是不是特别麻烦。k8s 是自带就有这些方案的。 不过你们测试环境体量没那么大的话也没必要搞这些。够用就好。就是尽量别 commit， 能做 dockerfile 还是用 dockerfile 比较好。以防以后环境变化的时候会很麻烦

谢谢。我也知道 dockerfile 绝对是更好的方式，但是我们这种好像没办法用 dockerfile 来搞。因为没办法去制作单独的容器镜像，只能通过 ambari 界面化的 ui 部署工具，一体化地部署一堆组件，让 ambari 去处理各个组件之间的依赖关系。。。也考虑到 commit 的方式会让容器的体积越发庞大，所以我们只能基于此制定了一套镜像升级规范来约束镜像升级操作

恩，那也可以，只是第一次 commit 就好了。 以后根据这个镜像写 dockefile 就好了

如果你有多个环境，或者频繁需要启用一个临时环境时，用 docker 维护起来方便很多，也更容易确保环境配置的一致性。docker 本身的一个目标是开发、测试、生产都采用相同的配置，减少因为环境差异（如服务版本、系统版本等）引起的问题和风险。

如果是固定环境，或者环境数量少，我觉得差异不大。开箱即用这个特性用到的频率并不高。

从你的情况看，如果 tomcat 的配置不常改，而且两个环境每次上线是按顺序使用的（如用完第一个肯定会用第二个，固定顺序），那么用不用 docker 差异不会太大。但如果两个环境是相互独立，每次上线只会用其中一个，建议用 docker 便于确保两个环境的一致性，否则后面某个环境版本滞后，要升级到最新版会很痛苦。。。

这倒是一个很好的建议！ 我之前没有想到，基于这组基础镜像写 dockerfile

看到这么牛皮复杂的环境，一个人就爱答不理的就解决了，docker 生产力效率确实是高。感谢！

其实也没那么轻描淡写，前期封装这套体系的时候也是费了不少功夫的。前期打好基础了后面才能这么逍遥

恩，前期的工作没有白做，真的很让人叹服，哈哈。综合考虑我们这的情况，我们这种量级加上对 docker 不熟，我觉得暂时还是先以实际运用和落地为首要目标，如果环境多余５个了，我再做 docker 化，趁着间隙期间，充点电。哈哈哈

个人的经验，docker 适合打包一个复杂的测试环境，并且非常适合到处迁移和扩展。举三个例子：1、假设你的测试环境需要配置 jdk1.7 和 python2.7，而测试服务器上的环境是 jdk1.8 和 python3，而你又不能随便修改服务器上的配置（可能已经作他用），docker 就比较方便了。2、假如你在 A 服务器搭了一套复杂的环境，某天需要同时在 B 服务器搭一套同样的环境，没有 docker 的话你只能从头来一遍了，特别是当 A 是 ubuntu 系统而 B 是 centos 系统，搭建相同的环境会让抓狂，而 docker 的话只需要一台 docker pull 命令即可。还有一种情况是某种测试环境可能几个月才用一次，你觉得留一台服务器比较好还是留一个 docker 镜像比较好？3、假如做压力测试的时候一台服务器压力不够，docker 可以快速扩展到多台机器，而且可以保证环境完全一样。
其实我觉得 docker 还有一个好处，和 git 差不多，假如你在开发一个复杂的测试代码，随着不断更新和完善，产生了 v1 和 v2 版本，v1 比较成熟，v2 可能会有 bug，再没有 docker 的情况下，如果 v2 发现了 bug，想回退到 v1，你们只能把代码切回 v1，和其他的环境也切回 v1，v1 还 v2 切来切去是个大麻烦，特别是 v1 需要 python2.7 而 v2 需要 python3.0 的时候，如果使用 docker，你只需要把 v2 实例删除，启动一个 v1 的实例就可以了，docker 就是这么方便。

你用 docker 做压力测试和 git 类比的视角很独特，赞一个

使用一个技术，应该是你的业务遇到壁垒，而不是别人用什么你用什么。我不排斥新技术，比如 apache 的 ignite 非常好，有些业务场景非常实用。
但是 docker 没感觉有啥用，自己也搭建了使用了一下。可能我写 shell 写习惯了。用到 docker 的某种功能，花几分钟写个 shell 就完事了。弄个 docker 也要有人维护的，估计成本会稍小一些而已。
但是真的没啥必要，我们所在的公司 20 台服务器吧，创建环境、部署脚本加一起估计 1000 行？反正我是有两天就写完了。变成 100 台这脚本还能用不是？
PS:jenkins 我也放弃了，jenkins 如果你只是用来部署的话，有 200 行 shell 就足以替换掉 jenkins 了。半天的事，何必引入一个新的技术，随时可能出问题的技术。

在有限的人力状态下，新技术如果可以提高单位人员的生产力，应该是没有问题的。现在我们单位代码规模扩张的很厉害，有 3 个团队加起来 40 多号人，10 个以上的子系统，都有构建发版的需求，使用 jenkins+shell 驱动，把工具交付出去，让他们自己玩，生产力解放了。

这个问题也困扰了我很久，断断续续的关注了 docker 的技术，领导似乎对 docker 很感兴趣，我虽然不排斥，但是也觉得没有必要。
我是公司唯一的运维，目前手上管理近百台的服务器，技术栈：java/php/前端，全部使用阿里云。
生产环境很单一，虽然不是以微服务的方式跑的，但是基本上各个模块也是分开的，生产环境中基本上只跑一个或者两个应用。
在云的环境中，我认为并没有使用 docker 的必要，我认为主要有几点：
一、云资源基本上是按需要开的，并不会出现过多的资源闲置，和传统的 IDC 不一样，需要购买很多的硬件资源备用，云资源的弹性伸缩也提供了硬件资源的扩容。
二、因为是按需开资源，所以基本上一台云服务器只跑一两个应用，也不存在资源抢占、环境变化或者环境不一致问题。（测试环境也在云上）
三、云资源提供的镜像的功能，也可以通过镜像生成各种环境。

我不知道在云环境中使用 docker 还有什么好处？可能是因为业务不够庞大和复杂，还没有体会到 docker 的好处，也可能我们是自有业务，没有交付给其他第三方用户的产品，所以体会不到 docker 的好处。

近期我们上了一个新的项目，这个项目需要交付给第三方用户，领导有意要使用 docker 交付，一个配置文件就能马上生成一个系统，听上去爽歪歪，但是不知道客户的接受程度如何。

但是如果交付的用户也是云环境的，我更偏向使用用镜像交付。

虽然这两天一直在学，除了一次编排到处运行的好处外，依然没有体会到 docker 的其他好处。

为了参加讨论特意注册了账号，还请各位大神不吝赐教。

本人的看法与你相同。确实，我觉得没有什么环境是部署脚本不能做的。

觉得 docker 的产生，还是跟分布式计算有关系。当你的一个同类的应用很多很多（商业上很成功，一个网站后台的同种的 tomcat 应用需要部署多份，做负载均衡，快速地分发到不同的服务器，那么确实用 docker 比 vm 要更快，更节省服务器资源）。但这只适合有一定规模的公司；或者说，适合那些向往着进入有一定规模公司的人，为了锤炼技术而在自己目前小一点的公司做技术尝试的人。

VM > Docker > 多 tomcat + 多 mysql+ 自动部署脚本 > 单一 tomcat + 单一 mysql 组合 + 自动部署脚本

其实，组合技术有千千万万种。没有最优，只有适合自己的。。。任何事物都是一样。。。