总结对Docker这个东西的想法
记得一开始的时候，还只能在一些网站上看到关于Docker零星的一些消息，之后的不久，有关Docker消息就遍布网络。
是什么因素让Docker火起来的？
或者说什么原因促使大家都对Docker感兴趣并且开始运用的？
本文记录一下自己对Docker的一点见解，关于Docker是什么以及基本的操作网络上有大把大把的文献，或者参考这里：
这里就不再累述了。
首先需要明确的一点是，一个技术从诞生到流行，必定有其原因所在
并不是因为某种技术听起来叼叼的样子，或者说大家都在用我不用就跟不上时代
能被大众所认可，并广泛使用的，一定是解决了大部分人所烦恼的问题，或者改善了大部分人的应用现状的
而Docker正是如此，那么它到底解决了大家的哪些烦恼，如何让大家在用Docker的过程中感到有质的改善呢？
举一个简单的例子，相信很多开发人员都遇到过这样的问题：
要开发应用，那肯定要写代码的啊
要写代码，那肯定要配置某个语言的运行环境啊
再搞个好用的IDE，或者可以再装几个插件啥七七八八的
于是噼里啪啦的好不容易装好了，可以开始愉快地撸代码了
也许一段时间之内并没有什么问题出现
但是就在某一天（也许是很久很久之后的事情了），电脑好卡啊，想重新装个系统清静清静，或者来个更直接的，我要换一台更高配置的机器
那么问题就来了
是不是还要继续写程序咯
那是不是还要继续搭环境咯
那是不是还要继续装各种需要的软件咯
重新装？可以啊，下次再换系统再换电脑，每次都重新装过咯~
虽然现在很多图形化的工具可以帮人备份、还原、复制系统，但是这一般都是给个人PC机用的，如果是服务器要进行迁移什么的，怎么破？
这是第一个问题，环境配置的重复工作和繁杂性
接下来看看第二个问题
我在服务器上挂着一个tomcat，里面跑着一个java web程序在读着mysql数据库，原本是好好的没啥问题是吧
现在问题又来了我要对mysql升级一下，升级就升级吧，但是问题是我这个东西是已经在跑着了，有人用着呢，难道不顾用户的死活直接就升了吗，而且升级完敢百分百保证一点问题都没有吗
有人就会问了，好好的没事升级啥啊
= =有时候偏偏就有这种需求，新版本性能更好啊，支持的功能更多啊，巴拉巴拉的。。。
这是第二个问题，局部部件升级或更改的隐患
上面两个问题是比较切实而且确实是不好解决的
就以这两个问题为例，开始聊聊Docker是怎么做的
了解过Docker的人应该都知道Image和Container的概念，简单的说可以把Image看成是一个压缩包（生活中很常见的把，rar、zip、gz神马的）
你要用的时候呢，就解压缩，很简单，然后就开始愉快的使用里面的文档资料啥的
可能你觉得光看很不爽，因为这个文档写的太糟糕，所以你就发挥才华狠狠地修改了一通，然后又压缩变成另外一个压缩包
so，Image就是压缩包，Container就是解压缩出来的文档，修改之后还可以再次变成Image，然后Image又可以再次使用。。。此处无限循环自行脑补~
那么第一个问题就解决了啊
啥？没看懂？
对于第一个问题，Docker是这么干的：
你拉一个最基本的Image嘛，run一个Container出来，爱装啥装啥，跟自己的服务器一样操作，装好了再保存为一个Image不就完事了嘛
服务器要迁移？
你把这个Image拷过去再run一个Container不就是一个一模一样的环境了嘛
OK，搞定一个
还是看mysql升级的问题
之前我可能是这么干的：
搞一台Linux服务器，搭个tomcat、装个mysql，然后把java web程序部署到tomcat上面去，搞定走你~
再来看看Docker是怎么做的：
还是整一台服务器是吧，这是必须的
但是我不直接装tomcat、mysql啥的了
我先装Docker！
run一个Container是吧，关键的时刻来了，哎呀，一个Container也，那我就可以在里面装各种各样的东西了，跟自己的服务器操作一样嘛~
真这么干就完了，那你还是直接装在服务器上面吧= =
我要run出三个Container出来！
Container1：
搭tomcat，把webapps（放网站程序的地方）挂载在服务器上的某个路径（放程序的地方）
为何这么做？
首先，直接把程序放到Container中也不是不行，但是程序是会经常变化的，而Docker提供了可以直接将物理路径映射到Container中的方法，将会变化的程序放在物理路径上，Container再去访问岂不更好？
Container2：
安装mysql，其他啥都不做了
Container3：
这个更彻底了，我就挂载mysql的数据库文件的那个路径，啥都没有了
Container1中的tomcat跑着java web程序
java web程序通过Container之间互相暴露的IP和端口访问Container2中的mysql
Container2中的mysql的数据库文件是读Container3中的
Container3其实又是挂载着服务器的物理路径的（存放mysql数据库文件的真实路径）
那么看起来很复杂的一个流程，现在关键点来了，mysql要升级了
呵呵，我直接升级Container2中的mysql
我在run一个跟Container2一样的Container，我对这个新的Container里面的mysql升级！升级完连Container3中的数据库文件！
原来的mysql没有受到任何影响，数据库文件也不会因为升级受到牵连，
升级完事之后，Container1连到新版本mysql所在的Container，万事大吉~就算真的真的新版本出毛病了，重新切回去Container2就是了呗~
Docker就是这么被用来解决问题的，处理方式和传统的方式大有区别，但是确实能够带来方便和快捷
想想这样一个应用场景：
一个分布式集群不够用了，原本我需要在搞几台机器或者虚拟机装啊配啊地扩展（而且就算是配置强大的机器，虚拟机起的个数也是少少的，数的过来的）
现在不用了，我刷地一下起了N个Container！
然后就没有然后了…
再想想这样一个应用场景：
开发的时候一个环境，如果测试的人不是你，然后测试人员又要搭一个一样的环境来测试程序，更恐怖的是，发布上线的时候又要保持这个环境的问题
现在也不用这么干了，一个Image，开发的时候run一个Container，测试的时候、发布上线的时候…
这里的目的也不是想一下子就成为Docker砖家啊啥的
仅仅是作为一个引子，指出Docker为什么会被广泛接受，其应用场景可以是哪些
至于对Docker的应用
反正大家都是是八仙过海各显神通
能玩成什么样就看你想玩什么样~
