Docker容器

数据库不适合Docker及容器化的7大原因

本文主要是介绍数据库不适合Docker及容器化的7大原因,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1、数据不安全

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

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

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

3、网络问题

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

4、状态

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

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

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

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

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

7、云平台的不适用性

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

这篇关于数据库不适合Docker及容器化的7大原因的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!