对于docker容器的理解

当前大部分项目都是部署在虚拟机上，但是虚拟机镜像实在是太大了，动不动几个G，每次启动，环境配置都非常磨叽，浪费时间，而且运维还要问开发需要什么环境，比如jdk版本，mysql版本等等。

这个时候，容器就有作用了。镜像是容器的根本性发明，是封装和运行的标准，是一个缩小版的虚拟机。

原来开发交付给运维的，是一个war包，一系列配置文件，一个部署文档，但是由于部署文档更新不及时，常常出现运维部署出来出错的情况，或者开发和运维互相扯皮的事情，笔者的公司以前就出现过，运维布置环境的时候，jdk版本安装错误，导致应用出现了bug，造成了损失。

有了容器镜像，开发交付给运维的，是一个容器镜像，运维直接运行整个镜像就行，里面包含了应用运行所需的一系列组件（jdk等等），容器内部的运行环境，应该体现在Dockerfile文件中，这个文件是应该开发写的。

这个时候，从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。由于容器镜像是标准的，就不存在脚本无法标准化的问题，一旦单个容器运行不起来，肯定是Dockerfile的问题。