不把DB放进容器的理由

原文地址:http://www.tuicool.com/articles/6VbqeqQ

原文为英文,以下是笔者的个人总结。

此处的DB包括但不限于Redis、ElasticSearch。

1、数据安全
Docker程序中断时,如果容器内的DB没有被正常关闭,可能造成数据丢失
甚至如果容器损坏,内部的DB数据文件可能无法恢复,丢失全部数据


2、额外的硬件资源使用
DB在内存使用、磁盘I/O控制等方面需要使用额外的资源,除了数据文件之外,DBMS也会占用容器的硬件资源
如果有多个数据库,多个容器内的多个DBMS比同一台物理机上,一个DBMS下的多个数据库占用的资源更多


3、网络问题
Docker使用了网络虚拟化技术,如果是部署在虚拟机环境下的Docker,可能会引起DB额外的问题


4、DB是有状态的
Docker本身是stateless的,而数据却是有状态的,不同时间写入DB的不同数据让DB也成了有状态的
因此容器的损坏可能影响业务工作流程


5、与Docker的特点不合
Docker的特点:
- 便于安装
- 便于部署
- 便于平行展开
- 适用于不同的系统环境

而DB不需要频繁的安装和部署,即使存在备份,也不需要在每个环境中都有一份(这样也会带来额外的同步负担),而且考虑到兼容性,DB本身也不会经常更新版本


6、DB层不需要安装在“隔离室”中
安装在高于系统环境的虚拟机Docker中,会带来额外的硬件资源消耗和网络问题


7、云平台的版本更新问题
Docker中的DB导致如果要更新云平台上的容器,就需要将容器中DB的数据导入新容器的DB中,再进行更新
这与使用容器,便捷更新的初衷不符

 

posted @ 2017-02-08 09:29 harelion 阅读(...) 评论(...) 编辑 收藏