江苏龙网

  1. 主页 > 生活百科 > >

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

docker

对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案 。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了 。生产环境的数据库是否应当放入容器中，仍然是一个充满争议的问题 。
站在开发者的角度上，我非常喜欢Docker ， 并相信容器也许是未来软件开发部署运维的标准方式 。但站在DBA的立场上，我认为就目前而言，将生产环境数据库放入Docker / K8S 中仍然是一个馊主意 。
Docker解决什么问题？
让我们先来看一看Docker对自己的描述 。

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

文章插图

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

文章插图
Docker用于形容自己的词汇包括：轻量、标准化、可移植、节约成本、提高效率、自动、集成、高效运维 。这些说法并没有问题，Docker在整体意义上确实让开发和运维都变得更容易了 。因而可以看到很多公司都热切地希望将自己的软件与服务容器化 。但有时候这种热情会走向另一个极端：将一切软件服务都容器化，甚至是生产环境的数据库 。
容器最初是针对无状态的应用而设计的 ， 在逻辑上 ， 容器内应用产生的临时数据也属于该容器的一部分 。用容器创建起一个服务，用完之后销毁它 。这些应用本身没有状态，状态通常保存在容器外部的数据库里 ， 这是经典的架构与用法，也是容器的设计哲学 。
但当用户想把数据库本身也放到容器中时 ， 事情就变得不一样了：数据库是有状态的，为了维持这个状态不随容器停止而销毁，数据库容器需要在容器上打一个洞，与底层操作系统上的数据卷相联通 。这样的容器，不再是一个能够随意创建，销毁，搬运，转移的对象，而是与底层环境相绑定的对象 。因此，传统应用使用容器的诸多优势，对于数据库容器来说都不复存在 。
可靠性
让软件跑起来，和让软件可靠地运行是两回事 。数据库是信息系统的核心，在绝大多数场景下属于关键（Critical）应用，Critical Application可按字面解释，就是出了问题会要命的应用 。这与我们的日常经验相符：word/Excel/PPT这些办公软件如果崩了强制重启即可，没什么大不了的；但正在编辑的文档如果丢了、脏了、乱了，那才是真的灾难 。数据库亦然，对于不少公司，特别是互联网公司来说，如果数据库被删了又没有可用备份 ， 基本上可以宣告关门大吉了 。
可靠性（Reliability）是数据库最重要的属性 。可靠性是系统在困境（adversity）（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）的能力 。可靠性意味着容错（fault-tolerant）与韧性（resilient），它是一种安全属性，并不像性能与可维护性那样的活性属性直观可衡量 。它只能通过长时间的正常运行来证明，或者某一次故障来否证 。很多人往往会在平时忽视安全属性，而在生病后 ， 车祸后，被抢劫后才追悔莫及 。安全生产重于泰山，数据库被删，被搅乱，被脱库后再捶胸顿足是没有意义的 。
回头再看一看Docker对自己的特性描述中 ， 并没有包含“可靠”这个对于数据库至关重要的属性 。
可靠性证明与社区知识
如前所述，可靠性并没有一个很好的衡量方式 。只有通过长时间的正确运行，我们才能对一个系统的可靠性逐渐建立信心 。在裸机上部署数据库可谓自古以来的实践，通过几十年的持续工作，它很好地证明了自己的可靠性 。Docker虽为DevOps带来一场革命 ， 但仅仅五年的历史对于可靠性证明而言仍然是图样图森破 。对关乎身家性命的生产数据库而言还远远不够：因为还没有足够的小白鼠去趟雷 。
想要提高可靠性 ， 最重要的就是从故障中吸取经验 。故障是宝贵的经验财富：它将未知问题变为已知问题，是运维知识的表现形式 。社区的故障经验绝大多都基于裸机部署的假设，各式各样的故障在几十年里都已经被人们踩了个遍 。如果你遇到一些问题 ， 大概率是别人已经踩过的坑 ， 可以比较方便地处理与解决 。同样的故障如果加上一个“Docker”关键字，能找到的有用信息就要少得多 。这也意味着当疑难杂症出现时 ， 成功抢救恢复数据的概率要更低，处理紧急故障所需的时间会更长 。
微妙的现实是，如果没有特殊理由 ， 企业与个人通常并不愿意分享故障方面的经验 。故障有损企业的声誉：可能暴露一些敏感信息，或者是企业与团队的垃圾程度 。另一方面，故障经验几乎都是真金白银的损失与学费换来的，是运维人员的核心价值所在 ， 因此有关故障方面的公开资料并不多 。


推荐阅读


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

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