随着新世界关于容器与虚拟机的争论继续，有状态容器与无状态容器的争论也在激烈进行。这真的是一件事吗？这真的发生在生产环境中吗？我们真的需要备份容器吗，还是只备份它们访问的数据集？容器不是有状态的，是吗？这场争论每天都在Twitter、reddit和我与客户的每一次谈话中都在激烈地进行。现在，争论通常从以下问题开始：为什么运行有状态容器？为了理解这个问题，首先我们需要理解有状态容器和无状态容器之间的区别以及它们背后的目的。什么是容器？"容器可以在操作系统级别抽象资源，使多个应用程序能够共享二进制文件，同时保持彼此的隔离"*引用自实际技术媒体的话容器是捆绑在一起的应用程序和依赖项，可以作为映像部署在容器主机上。这使得应用程序的部署变得快速而简单，而无需担心底层操作系统。下图有助于解释这一点：当您查看上面的图表时，您可以看到每个应用程序都部署了自己的库。应用程序状态如何？当我们一般地考虑任何应用程序时，它们都有持久性数据，并且都有应用程序状态数据。应用程序是什么并不重要，它必须在某个地方存储数据，否则应用程序的意义何在？以CRM应用程序为例，所有的客户数据都需要保存在某个地方。传统上，云报，这些应用程序使用数据库服务器来存储所有信息。从这方面看，一切都没有改变。但是当我们考虑应用程序状态时，这就是关于有状态容器的讨论的地方。通常，应用程序有五种状态类型：连接会议配置集群持久的出于本博客的兴趣，我们不会深入讨论这些状态，大数据是什么概念，但是对于今天编写的应用程序（本机于容器），这些状态都被卸载到某个数据库中。当现有的应用程序被集装箱化时，云店，挑战就来了。这是一个将安装在操作系统上的传统应用程序转换为容器化应用程序的过程，以便可以在前面所示的模型中进行部署。这些应用程序将这些状态保存在本地的某个地方，具体位置取决于应用程序和开发人员。另外，一种更常见的方法是将数据库作为容器运行，因此，它们满足上面列出的许多状态类型。有状态容器包含有状态数据的容器通常被写入持久存储或保存在内存中，这就是挑战所在。能够在基础架构发生故障时恢复应用程序非常重要。如果备份的所有内容都在数据库中运行，那么如前所述，这是一个简单的解决方案，但如果不是，如何在不中断用户的情况下协调这些应用程序的恢复？如果运行负载平衡的应用程序，并且必须恢复该应用程序，但它不知道连接或会话状态，最终用户将面临问题。如果我们看一下图表，我们可以看到"app1"已经在不同的主机上部署了两次。我们有多个用户通过负载平衡器访问这些应用程序。如果右侧的"app1"崩溃，然后在没有任何应用程序状态感知的情况下重新启动，免费企业管理软件，那么用户2将不会简单地重新连接到该应用程序。该应用程序无法理解连接，很可能会要求用户重新进行身份验证。对用户来说真的很沮丧，对为用户提供服务的公司来说也很糟糕。当然，使用不同类型的负载平衡器和其他软件可以缓解这种情况，但挑战是真实存在的。这是有状态容器的挑战。这不仅仅是在发生数据损坏时备份数据，还涉及如何恢复和操作连续服务。无状态容器现在使用无状态容器非常简单。根据上面的图表，会话数据将存储在某个数据库中。在发生故障时，只需重新部署应用程序，并从停止的地方恢复。容器是如何工作的。那么，有状态容器真的发生了吗？当我们想到容器化的应用程序时，我们通常会想到新时代，云原生的，诞生于云端的，无服务器的应用程序[在这里插入最新的流行语]但是当我们深入研究容器带来的简单方法时，我们可以理解企业如何利用容器来减少运行这些应用程序所需的复杂基础设施。许多需要一致状态数据的现有应用程序在生产中无处不在，这是有道理的。理解如何协调有状态容器的恢复是需要关注的，物联网应用技术是什么，而不是它们是否正在发生。VN:F[1.9.22_1171]请评价这篇文章对您的评价有多大帮助：3.6/5（投10票）生产中的有状态容器，这是一件事吗？，根据10个评分，5分中有3.6分