从某种程度上讲，历史上将IT行业出于任何原因分为两个条件阵营：赞成和反对。 而且，争议的主题可以是绝对任意的。 哪种操作系统更好：Win或Linux？ 在Android或iOS智能手机上？ 将所有内容都保留在云中或上传到冷RAID存储并将螺钉放在安全的地方？ PHP schnicks是否有权被称为程序员？ 有时，这些争执本质上完全是存在的，除了体育利益之外没有其他依据。
碰巧的是，随着容器的出现以及带有docker和条件k8的所有备受人们喜爱的厨房的出现，纠纷的利弊开始在后端的各个领域中利用新的机会。 （我们会提前保留，尽管在本次讨论中大多数情况下会将Kubernetes指示为协调器，但该工具的选择并不重要。相反，您可以替换任何对您来说最方便和熟悉的工具。）
而且，对于同一枚硬币的两面看来，这将是一个简单的争论。 就像永恒的对抗Win vs Linux一样毫无意义和残酷，在这种对抗中，足够多的人为自己而存在。 只是在容器化不是那么简单的情况下。 通常，在此类纠纷中没有权利，但是在“应用”或“不应用”用于存储数据库的容器的情况下，所有内容都被颠倒了。 因为从某种意义上说，这种方法的支持者和反对者都是正确的。
光明的一面
您可以用一个短语简短地描述“光明面”的参数：“您好，窗外2k19！” 当然，这听起来像民粹主义，但是如果您详细研究这种情况，它有其优势。 现在，我们将对其进行分析。
假设您有一个大型Web项目。 它最初可能是建立在微服务方法的基础上，或者在某种程度上以一种渐进的方式出现了-实际上，这并不是很重要。 您将我们的项目分散在单独的微服务上，设置业务流程，负载平衡，扩展。 现在，凭着明确的良心，在哈伯效应期间，在吊床上喝鸡尾酒，而不是举起倒下的服务器。 但是所有动作必须一致。 通常，只有应用程序本身是容器化的-代码。 除了代码之外，我们还有什么？
是的，数据。 任何项目的核心都是数据：它可以是典型的DBMS（MySQL，Postgre，MongoDB），也可以是用于搜索的存储（ElasticSearch），也可以是用于缓存的键值存储（例如Redis）。现在，我们不再我们将讨论由于查询书写不当而导致数据库崩溃时，后端实现方案的歪斜，相反，我们将讨论在客户端负载下确保该数据库的容错能力。 确实，当我们对应用程序进行容器化并允许其自由扩展以处理任意数量的传入请求时，这自然会增加数据库的负载。
实际上，在我们漂亮的容器化后端中，用于访问数据库和数据库旋转的通道已成为人们关注的焦点。 同时，容器虚拟化的主要动机是结构的移动性和可塑性，这使得有可能在我们可用的整个基础架构中尽可能高效地组织峰值负载的分配。 也就是说，如果我们不容器化并将系统的所有可用元素滚动到群集中，则会犯下非常严重的错误。
不仅对应用程序本身进行集群，而且对负责数据存储的服务进行集群也更加合乎逻辑。 当在k8s中独立地群集和部署工作并分配Web服务器的负载时，我们已经解决了数据同步的问题-如果您以某种媒体或博客平台为例，则对帖子的注释相同。 无论如何，我们都将数据库内部或虚拟表示为外部服务。 问题是数据库本身尚未集群-部署在多维数据集中的Web服务器从静态战斗基地获取有关更改的信息，该战斗基地是单独循环的。
感觉到了吗？ 我们使用k8s或Swarm来分配负载并避免主Web服务器崩溃，但是我们不对数据库执行此操作。 但是毕竟，如果数据库崩溃，那么在我们整个集群基础架构中就没有意义了-空网页返回数据库访问错误的用途是什么？
这就是为什么不仅需要像通常那样对Web服务器进行集群，而且还要对数据库基础结构进行集群。 只有这样，我们才能确保在一个团队中完全可操作但同时又彼此独立的相同结构的元素。 同时，即使后端有一半的负载“崩溃”，其余部分也将幸免，并且集群中彼此之间的数据库同步系统以及无限扩展和部署新集群的可能性将有助于快速达到所需的容量-数据中心中会有机架。
此外，集群中分布的数据库模型使您可以将同一数据库带到需要的地方。 如果我们谈论的是全球服务，那么在访问莫斯科地区的数据库时扭曲旧金山地区某个地方的网络集群并同时驱动程序包是不合理的，反之亦然。
同样，数据库容器化允许您在相同的抽象级别上构建系统的所有元素。 反过来，这使得开发人员可以直接从代码中管理此系统，而无需管理员的积极参与。 开发人员认为他们为新的子项目需要一个单独的DBMS-轻松！ 写了一个Yaml文件，上传到集群中，您就完成了。
好吧，当然，内部操作大大简化了。 告诉我，当团队的新成员把手伸进战斗数据库进行工作时，您斜视了几次？ 实际上，哪一个正在旋转？ 当然，我们这里的所有人都是成年人，在某个地方我们有一个新鲜的备份，甚至更进一步-在祖母的黄瓜和旧滑雪板放在架子后面的地方-另一个备份，甚至可能在冷藏库中，因为一旦您的办公室着火了。 但是，每次引入一个新成员即可访问战斗基础设施，当然还有战斗数据库，对于周围的每个人来说都是一堆有效的东西。 好吧，一个新手知道的人，也许他在着眼睛？ 吓人，同意。
容器化，实际上是项目的分布式物理数据库拓扑有助于避免发生这种情况。 不信任新手？ 好吧 我们将为此增加自己的集群，并将其与其余数据库集群断开连接-仅通过手动推动和同时旋转两个键（一个团队负责人，第二个管理员）来进行同步。 每个人都很高兴。
现在是时候改变数据库容器化的对手了。
阴暗面
在争论为什么没有必要对数据库进行容器化并继续在一台中央服务器上旋转数据库时，我们不会屈从于正统的言论和诸如“祖父将数据库置于硬件上的声明，而我们会的！”这样的说法。 相反，让我们尝试提出一种情况，在这种情况下，集装箱化确实会带来切实的红利。
您必须承认，真正需要在容器中放置底座的项目可以用一只手指望，而不是最好的铣床操作员。 在大多数情况下，甚至使用k8s或Docker Swarm也是多余的-由于技术的普遍炒作性质以及性别中的“全能”安装，他们经常会诉诸于这些工具，以将所有事物驱赶到云和容器中。 好吧，因为现在它很时尚，每个人都在做。
至少在一半的情况下，在项目上使用kubernetis或仅使用docker是多余的。 问题在于，并非所有为客户基础架构服务的团队或外包公司都意识到这一点。 更糟糕的是，在强加容器时，会向客户增加一定数量的硬币。
通常，有一种观点认为docker / mafia多维数据集会愚蠢地粉碎将这些基础结构问题外包的客户。 确实，为了使用集群，您需要有能力做到这一点并总体上了解已实现解决方案的体系结构的工程师。 我们已经以某种方式在Republic版中描述了我们的案例-在那儿，我们培训了客户团队使其在kubernetis的现实中工作，每个人都感到满意。 而且还不错。 k8的“实施者”通常会把客户的基础设施劫为人质-现在他们只了解那里的一切工作原理，客户端没有专家。
现在想象一下，通过这种方式，我们不仅将Web服务器部分交给了外包，而且还提供了数据库维护。 我们说过，DB是心脏，而心力衰竭对任何生物都是致命的。 简而言之，前景并不是最好的。 因此，代替大肆宣传kubernetis，许多项目都不应仅仅为AWS的正常收费而烦恼，这将解决其网站/项目负载的所有问题。 但是AWS不再是时尚，而且炫耀比金钱更昂贵-不幸的是，在IT环境中。
好吧 也许项目确实需要集群，但是如果无状态应用程序一切正常，那么我们如何为集群数据库组织适当的网络连接呢？
如果我们正在谈论一个无缝的工程解决方案，这似乎是向k8s的过渡，那么我们的主要头疼就是集群数据库中的数据复制。 最初，某些DBMS非常忠实于其各个实例之间的数据分配。 许多其他人并不那么欢迎。 在很多情况下，为我们的项目选择DBMS的主要论据不是以最小的资源和工程成本进行复制的能力。 特别是如果该项目最初并未计划为微服务，而只是朝这个方向发展。
我们不需要谈论网络驱动器的速度-它们很慢。 即 在这种情况下，我们仍然没有真正的可能性在某个地方升级DBMS实例，该地方有更多的处理器容量或可用的RAM。 我们非常快速地了解了虚拟磁盘子系统的性能。 因此，必须将DBMS牢牢地钉在自己的个人计算机上。 或者，有必要以某种方式将数据同步的足够快速的同步与估计的储备分开。
延续虚拟FS的主题：不幸的是，Docker Volumes并非一帆风顺。 通常，在长期可靠的数据存储的情况下，我想使用最简单的技术方案进行管理。 从FS容器向父主机FS添加新的抽象层本身就是一种风险。 但是，当在集装箱化支持系统的操作中在这些层之间传输数据时也遇到困难时，那确实是一场灾难。 目前，进步人类已知的大多数问题似乎已经消除。 但是您自己了解，机制越复杂，破解就越容易。
鉴于所有这些“冒险”，将数据库保存在一个位置将更加有利可图，而且更加容易，即使您需要对应用程序进行容器化，也可以让它自己旋转，并通过分发网关接收与数据库的同步通信，并且该通信只能进行一次读写。在一个地方。 这种方法将错误和错误同步的可能性降低到最小值。
我们要做什么？ 另外，在确实需要数据库的容器化是合适的。 您无法塞入完整的应用程序基础，就好像拥有两打微服务一样扭曲它-这是行不通的。 这必须清楚地理解。
代替输出
如果您正在等待“虚拟化或非虚拟化数据库”这一可理解的结论，那么我们将感到失望：它将不在这里。 因为在创建任何基础架构解决方案时，不应以时尚和进步为指导，而应以常识为指导。
在某些项目中，kubernetis随附的原理和工具非常合适，并且在此类项目中，至少在后端领域实现了和平。 而且有些项目不需要容器化，但是需要一个普通的服务器基础结构，因为它们基本上将无法扩展到微服务集群模型，因为它们会崩溃。