最近在兼职做 IT 咨询期间遇到过许许多多问题，其中咨询较多的问题之一就是在 Docker 容器中部署数据库。每每接到这个咨询我就想说一句：Are you crazy? Docker 在这几年可以说是大火，几乎所有的公司都将网站或者应用系统部署在 Docker 中，更有甚者将数据库也部署在 Docker 中（这个内容占到 Docker 问题咨询的一半左右）。那么将数据库部署在 Docker 中真的好吗？虽然像 MySQL、MSSQL、Oracle 等知名数据库都有 Docker 镜像，但是就目前 Docker 的情况来看将数据库容器化是不合理的，主要原因有如下6个方面：
- 数据安全
- 网络问题
- 资源隔离
- 云平台适用问题
- 运行环境
- 状态问题
下面分别对这七6方面进行一一讲解。
一、数据安全
Docker 官方明确说明过不要将数据存储在容器中，因为容器可以随时被删除，这样存储在容器中的数据也就随之丢失，因此官方推荐使用挂载 Volumes 的形式来存储数据，但是 Volumes 是由 Union FS 镜像层提供数据持久存储的，了解这个镜像层的开发人员都知道它很难保证数据安全，如果容器意外挂掉那么数据就很有可能损坏。其次，如果频繁对容器的共享数据卷（组）读写操作也会对物理服务器的硬件造成损害，进而造成数据丢失。
二、网络问题
数据库一般都具有高负载，因此需要专用的网络和持续的吞吐。如果对 Docker 的网络和网络虚拟化没有深入的了解的话，做这一块将会非常的困难，即使做了出来也很难保证网络的稳定。
三、资源隔离
Docker 目前还无法完全实现资源隔离，它只利用 Cgroup 来实现资源限制，只能限制资源消耗的最大值。如果有其他应用系统大量占用物理服务器资源，那么将会影响到部署在容器中的数据库的执行效率。
四、云平台适用问题
目前主流的云平台都支持弹性扩展，如果像让我们的数据库服务器也可以弹性扩展的话，就必须适用非容器化环境。
五、运行环境
我在进行 IT 咨询的时候遇到过很多将数据库容器和其他服务容器部署在同一台服务器上的情况，我们都知道不同类型的服务所需的硬件要求是不同的，尤其是像数据库这种服务对 IO 的要求会比较高。正常情况下我们会将数据库单独部署在独立的服务器上，这样就要可以避免并发资源竞争，但是如果将数据库部署在容器中那么可想而知将会限制数据库对资源的利用进而引发数据库的性能问题。
六、状态问题
Docker 快速扩展的重要特征是无状态，可以实现编排容器解决单点故障，一般来说具有状态的数据都不适合放在容器中，但是数据库是有状态的，如果将其部署在容器中会就必须单独部署存储服务，那么如果数据库崩溃/出错造成的故障范围就会扩大，进而应用系统崩溃。
七、总结
上面六条总结了为什么 Docker 不适合部署数据库，当然这不是绝对的。如果你使用的是轻量级数据库或者分布式数据库的话其实是可以部署在 Docker 中的。
