是否该在Docker容器中运行数据库?

戴声 译 2017-01-04 09:53:55

DBAplus社群译者:戴声

原标题:Is Docker Good for Your Database?

作者:Jon Tobin

地址:www.percona.com/blog/2016/11/16/is-docker-for-your-database/

 

几个星期前我写了一篇博客,从一个相当高的层面介绍了容器,涵盖了你在考虑使用Docker、rkt、LXC等技术时应该考虑的问题。我希望你已经快速阅读过了,因为那都是一些有助于理解新技术的好方法。

 

然而,它在我们的解决方案工程团队中引发了一些讨论。可能在你的组织中有这个相同的问题:是否应该让客户在容器中运行他们的数据库?

 

在开始之前,我必须承认Percona使用了容器。Percona的监控和管理模块(简称PMM)直接通过Docker容器来提供,提供了所有漂亮的图形和查询分析的功能。我们之所以做出了这个选择,是从为用户提供最大价值的角度出发,我们要能提供把组件集成起来的整个环境。Docker提供了这个能力,让我们能够分发很好很酷炫的集成单元。简而言之,它在你的应用程序集成环境方面具有巨大的潜力。

 

但是,对于数据库……这里是我们的一些建议:

 

 
它快但是不稳定
 

 

结论 = 对数据库不适用(从目前的情况看)

 

这不能针对所有环境的可能情况。这是我们认为的对大多数客户最好的默认建议。请注意,我只是针对的数据库提出这个建议。如果针对的是使用微服务架构的应用,那么,从你的数据库的负载特性、扩展需求和目前的技术栈分析,可能把你的数据库做成容器会是比较有意义的选择。

 

为什么?缺乏协同。

 

先别喷,咱们先花一些时间从源头开始考虑这个问题。首先,人们设计容器解决方案,是用来处理具有临时数据的无状态应用程序。容器快速地创建一个微服务,又快速地销毁它。这其中包含了该容器中的所有组件(包括其缓存和数据)。

 

容器的瞬时性质是由于该容器的所有组件和服务被认为是容器的一部分(基本上是全部或全都不是)。由底层操作系统提供数据卷,将其打穿到容器上来为容器提供存储的方式是非常具有挑战性的。当前的方法对于大多数数据库来说不太可靠。

 

开发层面上来说,花费大部分的精力去采用各种各样的解决方案只有一个目的:无状态。有一些解决方案可以帮助保持您的数据稳定性,但它们更新非常的迅速。可以肯定的是,它们需要很高的复杂度,由于增加了操作复杂性(和风险)而牺牲了效率。

 

为了进一步说明这一点,在我们回顾了使用容器(尤其是Docker)的实际需求后,正好是时候重新引出我们的结论。

 

 
他们只是还不够稳定
 

 

这些容器解决方案意味着应用程序的快速开发和部署被分解成微小的组成部分:微服务。通常,这些应用程序在软件/开发人员驱动的组织中更新迭代非常快。这似乎也是这些容器解决方案(同样的,这里尤其指Docker)被开发出来的原因。

 

新功能推出时只需少量测试和设计。主要焦点似乎是最新的功能集,并首先推向市场。他们乞求宽恕,而不是请求许可。除此之外,向后兼容性(从我们能知道的范围内)可能仅被给予了一点点的关注度(甚至这可能是夸大的)。这意味着,你将必须得在向客户提供一个经过测试的稳定版本容器镜像的同时,提供一个成熟的持续交付及测试环境版本的容器镜像。

 

有了恰当的使用场景,那这些工具非常酷,但他们需要时间,金钱,资源和经验。与许多我们的客户交谈,这正好就不适合他们组织的情况。他们的业务不是围绕软件开发设计的,他们根本没有钱来支持保持设备所需的资源。相反,他们正在寻找一个稳定和高性能的东西,可以让他们的用户7*24小时都满意。我知道,如果我们剥离容器,我们可以给他们一个高效、高可用的环境,这样的环境需要更少的管理成本。

 

有希望吗?

 

当然,事实上,还是很有希望的。目前有些公司在大规模地运行容器(包括数据库)!他们是具有非常成熟的研发流程的公司。软件研发是他们在业务计划和价值主张的核心内容。

 

你可能知道他们是谁,我说的就是:优步、谷歌、Facebook(还有更多,这些里提到的只是其中的小部分)。甚至从Joent公司,你还能获得如何才能坚持不懈地运行容器的一份概述。

 

但正如我之前所说,要获得必要的基本功能,来保持您的数据活跃和可用(这是数据库的最基本的使用需求),这中间造成的复杂度太高了,太过得不偿失。

 

在我看来,当容器有一个更好的和更稳定的解决方案来解决持久存储卷问题时,他们才更接近完备状态。即使如此,在大多数组织中,如果不处理大规模部署(50个以上的节点)并且工作负载变化很大的话,那甚至可能都不需要集中化的数据库。

 

 
不要让我们干等着…
 

 

我意识到,你可能不准备容器化你的数据库这样的论断,还不足以构成一个完整的解决方案。所以看这里:让解决方案工程团队(简称SolEng)来解决你的问题。Dimitri Vanoverbeke正在对配置管理撰写一系列很棒的博客。配置管理解决方案可以大大提高基础架构的重复性,并确保您的IT/应用开发流程在的环境的物理配置中是可重用的。

 

自动化这个过程可以带来巨大的收益。但是,应该利用成熟的开发/测试过程作为应用程序开发生命周期的一部分。过程和技术的结合才能创造稳定的应用和满意的客户。

 

除了配置管理作为增强的解决方案以外,还有一些服务可以使您的运营团队的工作更简单,这就是服务发现和健康检查。我最喜欢的解决方案是Consul,我们广泛地在PMM领域用于配置和服务元数据。Consul可以确保的前端应用程序和后端基础结构是的服务状态的实时快照工作。

 

 
总结
 

 

在管理环境时,尤其是当应用程序以快速的速度发展时,需要考虑很多问题。通过使用靠谱的解决方案,可以减少每个版本中的成本。此外,还可以提高弹性和可用性。

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告