数据库容器化的价值——反驳数据库不适合容器化的错误观点

前几天高可用架构文章《数据库不适合Docker及容器化的7大原因》(后面简称7文),在群里引起一些讨论,我个人是有一些不同的观点,不过争论未必能说得非常清楚透彻,后来我说写文章回应。于是有了这篇文章。

这篇文章不仅仅是反驳该文,同时也想说说应用容器化以及云化的价值。阅读本文时建议先阅读一下本人上周发的《2016年容器技术思考: Docker, Kubernetes, Mesos将走向何方?》(后面简称容文),本文中会直接引用该文的一些观点。

《7文》虽然列举了7大原因,总结一下其实主要是两点:

  1. 容器化数据库没有带来太多额外价值,数据库不需要经常构建和部署,也不需要经常升级,数据库实例的环境也不需要经常变,用 Ansible 也可以轻松部署和设置。
  2. 引入容器带来的,安全,IO,网络等方面的技术成本和风险,如非必要,勿增实体。

本文主要也从这两点开始,逐个分析。因为该文其实本质上是在分析一项通用技术的价值,所以我们先聊下如何对一项通用技术做价值评估。

如何对一项通用技术做价值评估

任何通用的技术,都承载着一定的技术使命,有其历史背景和最终目标。评价其价值是要思考它的使命和目标,不能单纯的从自己的个例出发。

比如以该文中提到的 Ansible 来说,一次我给一技术负责人推荐 Ansible 的时候,他说 Ansible 的功能我们自己用 shell 写的一套框架已经搞定了,完全没必要引入额外的工具增加复杂度。我说 Ansible 可以屏蔽操作系统的细节,容易些写出跨操作系统的通用配置脚本,他说我们的操作系统都是 ubuntu ,这个功能对我们没价值。我说 Ansible 可以把变量和配置脚本分离,提高脚本的复用程度,他说我们的脚本也一定程度上做了变量分离,我们只分离必要的,满足我们当前的项目了。我说 Ansible 文档详细,学习成本低,他说 shell 脚本看看源码就会了,并且改起来也容易。最后这个争论没有任何结果,谁都没说服谁。

后来我也一直在思考,到底问题在哪儿?其实每种技术的推广时,无论是工具,框架还是语言,都会遇到类似的争论。后来我想明白了,任何通用的技术的最重要的目标其实是增加软件的复用能力,无论是该技术本身还是由该技术衍生出来的产物,但如果不考虑复用,应用到具体的场景时效果都会打折,所以不能只用具体的场景去评估通用技术的价值。

再拿前面的 Ansible 为例,Ansible 本身是一个服务器配置管理工具,它的目标是让服务器的配置变更代码化(Configuration management Infrastructure as Code),然后让应用的安装以及配置的能力组件化,它称之为 Playbook,然后可以共享复用。所以你可以在网上搜索到各种 Ansible 的 Playbook,比如数据库集群的安装配置等。它为了实现这个目标,抽象了一套配置语法,通过声明式的配置来定义服务器上的基础设施状态,也一定程度上屏蔽了操作系统细节(实在屏蔽不了的,也可以通过简单的配置规则来适配),同时做了变量和配置的分离,避免和具体的环境的耦合。也就是说,只有能接受它的核心思想 —- 服务器基础设施变更代码化,然后考虑到复用价值,复用别人的 Playbook 或者将自己的 Playbook 复用到更多的项目或者团队,Ansible 的价值才会体现出来。比如前面争论的那个案例,如果考虑到以后会