江苏龙网

  1. 主页 > 生活百科 > >

DBA视角：把数据库放入Docker是一个馊主意( 二 )

docker


额外失效点
开发关心Feature，而运维关注Bug 。相比裸机部署而言 ， 将数据库放入Docker中并不能降低硬件故障、软件错误、人为失误的发生概率 。用裸机会有的硬件故障 ， 用Docker一个也不会少 。软件缺陷主要是应用Bug，也不会因为采用容器与否而降低，人为失误同理 。相反 ， 引入Docker会因为引入了额外的组件、额外的复杂度、额外的失效点，导致系统整体可靠性下降 。
举个最简单的例子，dockerd守护进程崩了怎么办，数据库进程就直接歇菜了 。尽管这种事情发生的概率并不高，但它们在裸机上 —— 压根不会发生 。
此外，一个额外组件引入的失效点可能并不止一个：Docker产生的问题并不仅仅是Docker本身的问题 。当故障发生时，可能是单纯Docker的问题，或者是Docker与数据库相互作用产生的问题，还可能是Docker与操作系统、编排系统、虚拟机、网络、磁盘相互作用产生的问题 。可以参见官方PostgreSQL Docker镜像的Issue列表：https://Github.com/docker-library/postgres/issues?q= 。
正如《从降本增笑到降本增效》中所说 ， 智力功率很难在空间上累加 —— 团队的智力功率往往取决于最资深几个灵魂人物的水平以及他们的沟通成本 。当数据库出现问题时需要数据库专家来解决；当容器出现问题时需要容器专家来看问题；然而当你把数据库放入 Kube.NETes 时，单独的数据库专家和 K8S 专家的智力带宽是很难叠加的 —— 你需要一个双料专家才能解决问题 。而同时精通这两者的软件肯定要比单独的数据库专家少得多 。
此外 ， 彼之蜜糖，吾之砒霜 。某些Docker的Feature，在特定的环境下也可能会变为Bug 。
隔离性
Docker提供了进程级别的隔离性，通常来说隔离性对应用来说是个好属性 。应用看不见别的进程，自然也不会有很多相互作用导致的问题，进而提高了系统的可靠性 。但隔离性对于数据库而言不一定完全是好事 。
一个微妙的真实案例是在同一个数据目录上启动两个PostgreSQL实例，或者在宿主机和容器内同时启动了两个数据库实例 。在裸机上第二次启动尝试会失败，因为PostgreSQL能意识到另一个实例的存在而拒绝启动；但在使用Docker的情况下因其隔离性，第二个实例无法意识到宿主机或其他数据库容器中的另一个实例 。如果没有配置合理的Fencing机制（例如通过宿主机端口互斥，pid文件互斥），两个运行在同一数据目录上的数据库进程能把数据文件搅成一团浆糊 。
数据库需不需要隔离性？当然需要，但不是这种隔离性 。数据库的性能很重要，因此往往是独占物理机部署 。除了数据库进程和必要的工具，不会有其他应用 。即使放在容器中，也往往采用独占绑定物理机的模式运行 。因此Docker提供的隔离性对于这种数据库部署方案而言并没有什么意义；不过对云数据库厂商来说，这倒真是一个实用的Feature，用来搞多租户超卖妙用无穷 。
工具
数据库需要工具来维护，包括各式各样的运维脚本，部署 ， 备份，归档，故障切换，大小版本升级，插件安装，连接池，性能分析，监控，调优 ， 巡检 ， 修复 。这些工具，也大多针对裸机部署而设计 。这些工具与数据库一样，都需要精心而充分的测试 。让一个东西跑起来，与确信这个东西能持久稳定正确的运行，是完全不同的可靠性水准 。
一个简单的例子是插件与包管理 ， PostgreSQL提供了很多实用的插件，譬如PostGIS 。假如想为数据库安装该插件 ， 在裸机上只要yum install然后create extension postgis两条命令就可以 。但如果是在Docker里 ， 按照Docker的实践原则 ， 用户需要在镜像层次进行这个变更，否则下次容器重启时这个扩展就没了 。因而需要修改Dockerfile，重新构建新镜像并推送到服务器上，最后重启数据库容器，毫无疑问，要麻烦得多 。
包管理是操作系统发行版的核心问题 。然而 Docker 搅乱了这一切，例如 ， 许多 PostgreSQL 不再以 RPM/DEB 包的形式发布二进制 ， 而是以加装扩展的 Postgres Docker 镜像分发 。这就会立即产生一个显著的问题，如果我想同时使用两种，三种，或者PG生态的一百多种扩展 ， 那么应该如何把这些散碎的镜像整合到一起呢？相比可靠的操作系统包管理，构建Docker镜像总是需要耗费更多时间与精力才能正常起效 。
再比如说监控 ， 在传统的裸机部署模式下，机器的各项指标是数据库指标的重要组成部分 。容器中的监控与裸机上的监控有很多微妙的区别 。不注意可能会掉到坑里 。例如，CPU各种模式的时长之和，在裸机上始终会是100%，但这样的假设在容器中就不一定总是成立了 。再比方说依赖/proc文件系统的监控程序可能在容器中获得与裸机上涵义完全不同的指标 。虽然这类问题最终都是可解的（例如把Proc文件系统挂载到容器内） ， 但相比简洁明了的方案 ， 没人喜欢复杂丑陋的work around 。


推荐阅读


上一篇：Redis五大经典业务问题剖析及解决方法

下一篇：生成式人工智能潜力的释放：软件工程师的MLOps和LLM部署策略