本文讲的是数据库真的适合容器化吗，也许不是【编者的话】本文主要评估了数据库容器化的可行性和必要性并最终提出了建议和解决方案。
容器概念（特别是Docker）非常火热。但是，在把数据库包装到一个全新的容器之前，有一些事情需要先在脑海里过一下。
本文评估了Docker和其他容器解决方案在数据库环境下的可行性。
几周前，我写了一篇相对概括的 关于容器的文章 。它介绍了你什么时候该考虑使用 Docker 、 rkt 、 LXC 等容器技术。方便的话不妨先浏览一下。这是一个很好的方式，在迁移到新技术架构前先了解一些需要考虑的方面。而这也引发了我们解决方案工程师团队的一次内部讨论。你的团队应该也会有一个相同的困惑：客户应该把数据库跑在容器里吗?
在开始之前，我们先得认可一个事实：Percona正在使用容器。Percona监控和管理（简称PMM）提供的全部优美的图表和查询分析都是通过运行一个Docker容器承载的。我们做出这个选择是因为组件之间的集成即是我们可以为用户提供最大价值的地方。Docker使得我们可以很酷的分发一个准备好的单元。简而言之，它在企业环境的应用端拥有巨大的潜力。
然而，对于数据库来说...这里有几个建议。
投入到各种解决方案的绝大多数开发力量脑海中都有一个目标：无状态化。有很多方案可以帮助你的数据持久化，但是它们仍处于快速迭代中。可以说，使用它们会引入很高的复杂度，上升的运维复杂度（和风险）也否定了容器化所带来的效率上的收益。之前我们在回顾有关容器（特别是Docker）使用时的一些“真实世界”的反馈所得出的结论也确实例证了这一点。
市面上的确有一些很酷的工具用在了正确的用例上，但是他们有的是时间，金钱，资源还有经验。就我们多数顾客来说，作为一家企业这不是他们该考虑的地方。他们的业务并不是围绕软件开发设计的，他们也没有足够的钞票来支撑保持这些机器运转所需的资源。相反，他们只想弄出一个稳定和高性能的服务，可以让他们的用户7*24小时开心地用着服务。
我知道，如果我们将数据库从容器剥离出来的话是可以给他们提供一个高性能、高可用的环境，并且不用怎么操心。
除了将配置管理作为改进方案，有一些服务也可以让运维团队的日子好过些。第一个想到的便是服务发现和健康检测。我最喜欢的是 Consul ，我们用在PMM里做扩展，完成配置和服务元数据的管理。Consul可以确保前端应用和后端基础架构所工作的服务状态每时每刻都是一个快照。
容器概念（特别是Docker）非常火热。但是，在把数据库包装到一个全新的容器之前，有一些事情需要先在脑海里过一下。
本文评估了Docker和其他容器解决方案在数据库环境下的可行性。
几周前，我写了一篇相对概括的 关于容器的文章 。它介绍了你什么时候该考虑使用 Docker 、 rkt 、 LXC 等容器技术。方便的话不妨先浏览一下。这是一个很好的方式，在迁移到新技术架构前先了解一些需要考虑的方面。而这也引发了我们解决方案工程师团队的一次内部讨论。你的团队应该也会有一个相同的困惑：客户应该把数据库跑在容器里吗?
在开始之前，我们先得认可一个事实：Percona正在使用容器。Percona监控和管理（简称PMM）提供的全部优美的图表和查询分析都是通过运行一个Docker容器承载的。我们做出这个选择是因为组件之间的集成即是我们可以为用户提供最大价值的地方。Docker使得我们可以很酷的分发一个准备好的单元。简而言之，它在企业环境的应用端拥有巨大的潜力。
然而，对于数据库来说...这里有几个建议。
临时应急
决策 = 不做数据库的容器化（保持现状）
这并不是说每个环境都这样。而是默认情况下我们认为最建议绝大多数客户采纳的做法。请记住，我只是建议你对 数据库 这样做而已。如果今天你的应用已经实现了 微服务化 ，那么依赖于数据库的负载特点、扩展需求以及工程师们现有的技能集来实施数据库的容器化可能会更有意义。为什么？
缺乏协同
先别发火，不妨花点时间回想下我们的初衷吧。首先，人们设计出来的容器解决方案是为了处理有临时数据的 无状态应用 。容器快速建起一个 微服务 ，然后销毁它。这囊括了该容器的所有组件（包括它的缓存和数据）。容器的瞬时特质决定了该容器的所有组件和服务都被认为是该容器的一部分（基本上全是，或者都不是）。通过在容器上打孔的方式为容器提供一个属于底层操作系统的数据卷本身可能会很有挑战。现有方案对于绝大部分数据库系统来说都太不可靠了。投入到各种解决方案的绝大多数开发力量脑海中都有一个目标：无状态化。有很多方案可以帮助你的数据持久化，但是它们仍处于快速迭代中。可以说，使用它们会引入很高的复杂度，上升的运维复杂度（和风险）也否定了容器化所带来的效率上的收益。之前我们在回顾有关容器（特别是Docker）使用时的一些“真实世界”的反馈所得出的结论也确实例证了这一点。
它们还不够稳定
这些容器方案的本意都是为了快速开发和部署那些被拆解成众多微小组件： 微服务 的应用。通常，这些应用在那些软件/工程师驱动的组织里发展的非常快。这似乎也是这些容器解决方案（再次强调，尤其是Docker）被开发出来的原因。新功能在经过少量测试和设计之后便推送出来。主要的焦点似乎被放在最新的功能集，还有最先推向市场。它们不再向用户“征得许可“，取而代之的是事后的”乞求宽恕“。除此之外，它们将向后兼容性（从我们之前所说便可以得知这一点）优先级排的很远（甚至还有所夸大）。这意味着你将不得不打算去建立一个成熟的 持续交付 和测试的环境，以及一个对于容器而言广为人知并经过测试的镜像仓库。市面上的确有一些很酷的工具用在了正确的用例上，但是他们有的是时间，金钱，资源还有经验。就我们多数顾客来说，作为一家企业这不是他们该考虑的地方。他们的业务并不是围绕软件开发设计的，他们也没有足够的钞票来支撑保持这些机器运转所需的资源。相反，他们只想弄出一个稳定和高性能的服务，可以让他们的用户7*24小时开心地用着服务。
我知道，如果我们将数据库从容器剥离出来的话是可以给他们提供一个高性能、高可用的环境，并且不用怎么操心。
有希望吗？
当然有，事实上，可不仅仅只是有希望而已。现今有很多企业已经在大规模运行容器（包括数据库）！这些公司的典型特点都是拥有非常成熟的流程。他们的软件开发是业务规划的核心部分并主导了价值取向。我所说的这些你大概知道： Uber ， Google ， Facebook （还有很多，这里只是一部分）。还有一个很好的选择，那便是你可以通过使用Joyent来获得 容器数据的持久化 。但是正如我之前所说，要保证必要的数据存留和可用性（数据库绝大多数最基本的用途）随之带来的复杂度实在是太高了。我个人的观点是，当容器拥有一个更好和更稳定的持久存储卷解决方案时他们也就离成功只有一步之遥了吧。即便如此，在大多数组织内部，如果不是支撑大规模部署（超过50个节点）并且工作负载变化很大的话，可能也无需容器化数据库。不要吊我们胃口...
我知道，”你可能还没准备好容器化数据库“这种话并不能构成一个解决方案。所以在这里：解决方案工程师团队（简称SoIEng）给出了解决方案。 Dimitri Vanoverbeke 正在编写一套很赞的关于配置管理的系列博客。配置管理解决方案可以极大地提高基础架构的可重复性，并确保你的IT/App开发流程在自己环境的物理配置中也是可重复的。自动化这个过程可以带来巨大的收益。而成熟的开发/测试流程应当成为整个应用开发生命周期的一部分。流程和技术的结合可以缔造出稳定的应用从而让客户开心。除了将配置管理作为改进方案，有一些服务也可以让运维团队的日子好过些。第一个想到的便是服务发现和健康检测。我最喜欢的是 Consul ，我们用在PMM里做扩展，完成配置和服务元数据的管理。Consul可以确保前端应用和后端基础架构所工作的服务状态每时每刻都是一个快照。
结论
在管理一个环境，尤其是当应用快速迭代的时候需要考虑的事情很多。通过采用可选的解决方案，你可以减少每次发布的开销。此外，你还可以提高应用的弹性能力及可用性。原文链接：Is Docker Good for Your Database? (Probably Not)（翻译：吴佳兴)
原文发布时间为：2017-01-04
本文作者：吴佳兴
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：数据库真的适合容器化吗，也许不是
