phpcn_u15822017-04-27 09:03:42
关于数据库不适合放在docker里面，有两个歪果仁的文章，其一就是楼主所贴，其二是这篇，译文
还是那个观点：
量小的时候随便搞，量大了有些东西就不行了，传统型数据库和docker并不对路，建议不要直接容器化，非要把数据库容器化，那么需要各种系统的支撑，包括中间件系统、容器化系统。
如果你的数据库能够自动伸缩、容灾、切换、自带多节点解决方案等，docker算是一个比较好的方案。
但是如果不能，还是不要用docker。
原文中也说得很清楚：
在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。流量小的情况下，什么东西容器化都行。数据库，应用，hadoop，各种节点，nginx。
量大的情况下，存储相关的不适合容器化，应用层、业务层等无状态的服务适合容器化，缓存这类内存密集型的服务可以容器化。
简单来说就是三个问题，容灾、性能和数据一致性。
就mysql这种传统数据库而言，仅仅我所能列出来的问题就有如下这么多：
mysql怎么容器化？
主库mysqld跪了怎么办？
主库dockerd跪了怎么办？
从库mysqld跪了怎么办？
从库dockerd跪了怎么办？
能否在高峰来临之际通过容器快速扩容mysql？方案？
数据主从切换方案？一致性如何保证？
高峰时期量足够大，有时候一般一台物理机的容量只够一个mysql进程。
那么同样是单台机器，为什么不能直接启动mysql？
为什么还要外面套一层容器？对性能损耗多少？
mysql如何升级？
数据卷是否会丢失数据？（损坏容器我遇到过很多次了……）
但是mysql也不是全然不能容器化。
对数据丢失不敏感的业务（例如京东搜索搜到的商品）就可以数据化，利用数据库分片来实现通过增加实例数增加吞吐量。
题主原文中提到的问题，有些东西是有槽点的，但是考虑的很周全。比如如下问题就很有槽点（关于共享数据目录）：
容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？就我目前接触到的数据库来看，只有cassandra这类（个）（还有tidb和cockroachdb，但是目前还没遇到过大公司的用例）数据库适合容器化。
但是cassandra自身也接近是无状态了：自己提供容灾，扩容，切换方案。
以下提一下京东。
京东是个异类，但是京东也提到过类似的问题和需要注意的地方。
计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。甚至，对docker做了很多的定制。
可以看京东分享。
伊谢尔伦2017-04-27 09:03:42
不适合, 而不是不能.
如果单机没什么问题, 在某些情况下还是有利的. 比如之前我公司的oracle数据库调参数时导致数据库崩溃彻底起不来了, 还好那时用的是docker, 直接run一个, 把数据目录指向原来的就好了.
集群的话不管怎么样, 用docker手工组, 或swarm这类工具也好, 都不怎么好搞. 还不如直接在物理机上搭建省事.
国外有家公司就是专做docker的数据存储方案的. 比如flocker, 还有rancher的convoy
PHPz2017-04-27 09:03:42
docker放更适合无状态，不会变更服务。
如大量集群的时候：
编写好docker file。然后当代码上传到代码仓库的后，在然后部署让好docker file以后，再让发布脚本批量构建docker服务并把服务代码放进去。
不仅仅是MySQL，类似于redis，mc都不适合放入docker中，或者说放把数据库放docker中有为了使用docker而这样做，并没有太多的好处。