文章来源：
https://www.toutiao.com/i6805798581971190276/
近2年Docker非常的火热，各位开发者恨不得把所有的应用、软件都部署在Docker容器中，但是您确定也要把数据库也部署的容器中吗？这个问题不是子虚乌有，因为在网上能够找到很多各种操作手册和视频教程，小编整理了一些数据库不适合容器化的原因供大家参考，同时也希望大家在使用时能够谨慎一点。目前为止将数据库容器化是非常不合理的，但是容器化的优点相信各位开发者都尝到了甜头，希望随着技术的发展能够更加完美的解决方案出现。Docker不适合部署数据库的几个原因
1、数据安全问题
不要将数据储存在容器中，这也是 Docker 官方容器使用技巧中的一条。容器随时可以停止、或者删除。当容器被rm掉，容器里的数据将会丢失。为了避免数据丢失，用户可以使用数据卷挂载来存储数据。但是容器的 Volumes 设计是围绕 Union FS 镜像层提供持久存储，数据安全缺乏保证。如果容器突然崩溃，数据库未正常关闭，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件损伤也比较大。即使你要把 Docker 数据放在主机来存储 ，它依然不能保证不丢数据。Docker volumes 的设计围绕 Union FS 镜像层提供持久存储，但它仍然缺乏保证。使用当前的存储驱动程序，Docker 仍然存在不可靠的风险。如果容器崩溃并数据库未正确关闭，则可能会损坏数据。2、性能问题
大家都知道，MySQL 属于关系型数据库，对IO要求较高。当一台物理机跑多个时，IO就会累加，导致IO瓶颈，大大降低 MySQL 的读写性能。在一次Docker应用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈一般出现在IO上面，如果按 Docker 的思路，那么多个docker最终IO请求又会出现在存储上面。现在互联网的数据库多是share nothing的架构，可能这也是不考虑迁移到 Docker 的一个因素吧”。 如果使用Docker 跑 MySQL，数据库程序与数据需要进行分离，将数据存放到共享存储，程序放到容器里。如果容器有异常或 MySQL 服务异常，自动启动一个全新的容器。另外，建议不要把数据存放到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比较大。 Docker 里部署轻量级或分布式数据库，Docker 本身就推荐服务挂掉，自动启动新容器，而不是继续重启容器服务。 对于IO要求比较高的应用或者服务，将数据库部署在物理机或者KVM中比较合适。目前TX云的TDSQL和阿里的Oceanbase都是直接部署在物理机器，而非Docker 。3、网络问题
要理解 Docker 网络，您必须对网络虚拟化有深入的了解。也必须准备应付好意外情况。你可能需要在没有支持或没有额外工具的情况下，进行 bug 修复。我们知道：数据库需要专用的和持久的吞吐量，以实现更高的负载。我们还知道容器是虚拟机管理程序和主机虚拟机背后的一个隔离层。然而网络对于数据库复制是至关重要的，其中需要主从数据库间 24/7 的稳定连接。未解决的 Docker 网络问题在1.9版本依然没有得到解决。把这些问题放在一起，容器化使数据库容器很难管理。我知道你是一个顶级的工程师，什么问题都可以得到解决。但是，你需要花多少时间解决 Docker 网络问题？将数据库放在专用环境不会更好吗？节省时间来专注于真正重要的业务目标。4、状态
在 Docker 中打包无状态服务是很酷的，可以实现编排容器并解决单点故障问题。但是数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范围更大。下次您的应用程序实例或应用程序崩溃，可能会影响数据库。知识点在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。Docker 快速扩展的一个重要特征就是无状态，具有数据状态的都不适合直接放在 Docker 里面，如果 Docker 中安装数据库，存储服务需要单独提供。目前，TX云的TDSQL(金融分布式数据库)和阿里云的Oceanbase(分布式数据库系统)都直接运行中在物理机器上，并非使用便于管理的 Docker 上。5、资源隔离
资源隔离方面，Docker 确实不如虚拟机KVM，Docker是利用Cgroup实现资源限制的，只能限制资源消耗的最大值，而不能隔绝其他程序占用自己的资源。如果其他应用过渡占用物理机资源，将会影响容器里 MySQL 的读写效率。需要的隔离级别越多，获得的资源开销就越多。相比专用环境而言，容易水平伸缩是Docker的一大优势。然而在 Docker 中水平伸缩只能用于无状态计算服务，数据库并不适用。我们没有看到任何针对数据库的隔离功能，那为什么我们应该把它放在容器中呢？Docker是为开发人员和系统管理人员开发、装载和运行分布式应用程序的开放平台。由Docker Engine和Docker Hub两个部分组成，Docker Engine是轻量级的实时运行的打包工具，Docker Hub为应用程序的共享和工作流的自动化提供云服务。Docker能够快速装配组件状态的应用程序，并消除开发，测试和产品环境之间的差异。因此，IT人员无须作任何修改，就可以更加快捷地在笔记本、数据中心虚拟机和任何云端装载并运行同样的应用程序。
根据上述说法，我们就可以轻松地对Docker的价值给出定义：
易于安装软件；
易于重复部署（持续集成）；
易于横向展（此条来源于实践）；
易于保持各个环境的平等地位。
接下来我们考虑一下，这些功能特性如何与数据库相匹配。易于安装数据库？在运行时与数据库有什么特别不同之处吗？
如果拿MongoDB集群举例，那么集群的配置管理（Configuration Management）系统会是什么情况呢？配置管理系统被设计成执行一条命令就可以完成例行的程序。就拿MongoDB的安装来说，Ansible模块可以用在十几个实例上。无论怎么样，开发自己喜欢的配置管理系统就可以。我们可以了解到，这并不像火箭科学那样，并不能带来太多的价值。
易于重复部署？为了升级将数据库升级到下一个版本而重新部署数据库的频度有多大？即使集群存在适用性（usability）的问题，但数据库升级不属于此类问题，而属于工程问题。思考一下，我们的应用程序如何与新版的数据库引擎协同工作，数据库引擎发生变化时会产生哪些破坏性的影响，这才是更有价值的思考。而Docker是无法解决这些问题的。
易于水平扩展？我们是否要在很多不同实例之间共享数据目录？难道不怕直接发生数据并发和可能发生的数据崩溃？不是在特定的数据环境下部署多个实例更安全吗？还有最后去完成主从服务的复制。
易于保持各环境的平等地位？数据库实例环境发生变化的频度有多大？我们每天都升级操作系统吗？也许数据库的版本或依赖软件就像类库和模块一样的形式存在呢？与工程团队保持一致岂不是更容易吗？
我们就当这些说法都成立。但是是否存在这种可能性，“蹩脚”的工程师不遵守规则，坚持要使用不同版本的数据库进行开发？或者“出色”的工程师遵守规则但难于理解使用什么？我想对于上述后两个问题是这样。Docker并不是解决环境平等地位问题的有效解决方案。
至此，与数据库容器化相关的所有功能特性都被梳理了一遍。
7、云平台的不适用性
大部分人通过公有云开始项目。云简化了虚拟机操作和替换的复杂性，因此不需要在夜间或周末没有人工作时间来测试新的硬件环境。当我们可以迅速启动一个实例的时候，为什么我们需要担心这个实例运行的环境？这就是为什么我们向云提供商支付很多费用的原因。当我们为实例放置数据库容器时，上面说的这些便利性就不存在了。因为数据不匹配，新实例不会与现有的实例兼容，如果要限制实例使用单机服务，应该让 DB 使用非容器化环境，我们仅仅需要为计算服务层保留弹性扩展的能力。8、运行数据库的环境需求
常看到 DBMS 容器和其他服务运行在同一主机上。然而这些服务对硬件要求是非常不同的。数据库（特别是关系型数据库）对 IO 的要求较高。一般数据库引擎为了避免并发资源竞争而使用专用环境。如果将你的数据库放在容器中，那么将浪费你的项目的资源。因为你需要为该实例配置大量额外的资源。在公有云，当你需要 34G 内存时，你启动的实例却必须开 64G 内存。在实践中，这些资源并未完全使用。怎么解决？您可以分层设计，并使用固定资源来启动不同层次的多个实例。水平伸缩总是比垂直伸缩更好。所有数据库都存在同样的问题吗？
并不是所有的数据库都存在同样的问题。这些问题只存在于数据需要持久化的情况下。并且还要与特定资源需求相关的数据库才存在这样的问题。如果拿Redis来做缓存或者会话数据的存储，就不存在这样的问题。由于这些数据不需要存储在硬盘上，因而也就不存在数据丢失的风险。但如果我们拿Redis用作持久化的数据存储，那就最好将数据库放在容器之外。即使我们不断获得了RDB快照文件，在不断快速变化的计算集群中找到快照也是一件复杂的事情。
本地的开发环境就不用担心了。在本地开发环境中将数据库放到容器中会节省很多时间和力气。在产品环境中也是一样。要知道OS X或Windows系统下原生的PostgreSQL都不会百分百地与Linux版本兼容。所以构建起容器代替在主机系统上直接部署可以弥补这点不足。
总结
针对上面问题是不是说数据库一定不要部署在容器里吗？我们可以把数据丢失不敏感的业务（搜索、埋点）就可以数据化，利用数据库分片来来增加实例数，从而增加吞吐量。docker适合跑轻量级或分布式数据库，当docker服务挂掉，会自动启动新容器，而不是继续重启容器服务。数据库利用中间件和容器化系统能够自动伸缩、容灾、切换、自带多个节点，也是可以进行容器化的。
