很久以前就听闻docker很火，替代虚拟化的一种容器技术，一直也有心学习，但是一直都…。(好吧，太懒了)
公司有近20+的mysql数据库，一直使用Kernel-based Virtual Machine的虚拟化技术进行资源隔离，随着公司的发展，各种类型的数据库越来越多。
kvm的方案对于cpu，memory，disk io方面负载都是非常明显的。
在实际测试中，在一台40核96G内存和固态raid10的服务器上，创建5个kvm实例，每个实例设定8核16G数据盘放在固态raid上（实例中运行mysql）。
在每日峰值下，经常会出现磁盘io而导致的cpu wait耗时,sql平均执行时间耗时到了秒级。kvm主机上，磁盘io负载在400%左右。更严重的是，在实例没有任何负载（kvm实例没有运行mysql）情况下，kvm主机的磁盘io还是明显降低了近30%左右。
而在kvm实例中。分配的16G内存实际应用占用的仅有14G左右，剩下的所有都被系统用于buffer,而swap空间占用也很严重，能达到真实内存的2倍。
使用资源隔离，但是作为代价，资源隔离也要消耗资源。当然希望隔离消耗的资源越小越好。
去了解了docker技术的实现，阅读了一本入门书籍《Docker 实践》，在线上使用docker运行mysql实例跑了一段时间。
确实相对于kvm资源隔离的消耗减少，管理也相对便利。最重要是解决了磁盘io性能上的问题。在最近一段时间内的测试，在每日峰值下，docker主机磁盘io负载降低为60%~80%，mysql实例内存为真实的限定值。而且所有docker实例共享cache，而不是kvm的每个单独实例共享cache，猜测也是io负载下降如此大的原因。
但是也随之而来的发现一些问题。
No1. 在使用中发现一些bug，restart的时候，如果服务器负责较大，实例在重启完成后，会出现实例假死的情况，而ps显示在正常运行。
No2. docker的网络配置不够强大。无法实现某些需求（比如docker主机和实例在同一网段）
No3. docker的镜像创建不够强大。dockerfile只能从另外一个镜像开始，而一个简单的nginx容器完成创建后，可能会不符合你日常熟悉的配置路径。（也可以用go语言编译）
No4. 这是在国内才有的问题。由于被墙的原因，docker仓库基本上访问不了。（在学习中使用的alpine镜像都是我从国外vps下的）
No5. docker的联合文件系统，让selinux很尴尬。
No6. docker的容器环境也是一个大问题。