数据库真的不适合Docker及容器化吗？

我的文章是对“数据库不适合Docker及容器化”的回应。声明我自己并没有在Docker里大规模部署数据库的经验，但在网上搜索一下不难发现这篇文章不正确。有几个障人耳目的地方：

1. 数据库的这些问题有没有Docker都存在
2. 解决这些问题Docker单独实现不了，但Docker加其它的工具一起可以解决

有个人逐一反驳了这篇文章的观点：

1. 数据不安全

作者混淆了Docker镜像和数据库自有数据的区别。Docker的图形驱动确有问题，但它不存储任何数据。镜像层是可选项并与数据库数据无关。

2. 运行数据库的环境需求

不清楚为什么在数据库机器上运行其它进程会是反对Docker的论据。Docker容器不会强迫你去这么做。

3. 网络问题

这部分比较奇怪，作者就是想说“网络很难”。如果你不想学习“软件定义网络”，那么你可以把容器运行在本地主机网络上。

4. 状态

如果作者想要提出的观点是Docker容器玩不转状态，这就如同说“进程玩不转状态”，因为Docker容器就是一个Linux进程。你对数据库在那儿运行和如何运行有完全的控制。你可以按需使用Docker的功能。

5. 数据库不适应使用主要的Docker功能

这部分作者只是说了一件事情，使用配置管理工具安装数据库比使用像Docker这样的工具更容易。确实，一个问题有多种解法，坦率地讲你可以把配置管理工具和Docker容器一起使用。我只是不明白为什么作者把这条作为反驳Docker的论据。

6. 额外的隔离对数据库是不利的

作者在此处又重提容器会带来高昂的额外的代价。这是站不住脚的。我建议把“容器”替换成“进程”，这样更容易理解。你可以在主机的文件系统上使用本地主机网络来运行容器，这与在本机上运行的其它进程无异。同时使用网络命名空间不会显著影响性能。

7. 云平台的不适用性

首先本节标题与内容不符。其次作者想阐明的观点不外乎“平台不可知”这一容器的优势毫无价值。这或许对数据库管理员无足轻重，但能在不同平台上运行有着巨大商业价值：对于6位数的企业及许可证的商业部署，你会发现软件需要能够在虚拟机集群上运行，这时候容器能提供帮助。容器重要并不仅仅因为受开发者欢迎，而是能够使得公司大幅减少基础设施规模和减轻负载。另外一个并不显而易见的优势是能够在公有云和私有云上运行同样的SaaS技术栈。这样就打开了全新的市场。

反驳的原文地址：http://www.talkwithtrend.com/Article/217011
数据库不适合Docker及容器化的7大原因