什么是不可变服务器？

关于不可变服务器，存在一些问题，例如：

• 如何在不丧失进行验尸的能力的情况下实现不可变的服务器模式？
• 配置管理工具在不变的基础架构中扮演什么角色？

显然，这与服务器有关（这是我得到的）。而且，只要消化不可变的语法，我就会认为这与“不可能静音 ”有关。如果这个猜测很接近，我不知道到底什么是不能静音的（我怀疑这与声卡或其他东西有关）。

我的问题：

• 什么是真正的“不可变服务器”（在DevOps的上下文中）？
• 为什么使用它们？

不变性是计算机科学界经常使用的一个术语，通常可以归结为“创建后无法更改”。它通常用于表示并行性，并发性和线程安全性。

关于该主题的讨论很有趣，但是通常可以在Stack Overflow的其他地方找到。我抵制在这里潜入其中的冲动。关键概念是“创建后无法更改”。

想象一下，如果您在Amazon上通过将Web服务烘焙到机器映像中来部署Web服务（AMI-您可以重复重新配置的预建实例）。它通过启动时退出注册表的凭据连接到后端数据库。它将日志转储到Splunk之类的日志记录工具中。对于正常的日常操作，您没有理由使用此框。如果需要扩展该服务，则只需创建该AMI的更多实例并调整负载均衡器即可。降低速度只是破坏实例和负载平衡器。

对于日常操作，此框没有理由更改。我们可以在AMI上启动更多功能。

当您需要提供操作系统级别的安全补丁时，会发生什么？这是您决定进行以下操作的时间...是要在安装了补丁的情况下烘烤新的AMI并重新部署所有正在运行的实例，还是将ssh转换为现有映像并更新补丁？有很多人会屈服。“不可变架构”的拥护者甚至向我吼叫，甚至暗示这样的事情是可能的。

不可变主义者（如果有这样的话）主张烘烤新的阿米。他们主张消除所有理由将ssh放入计算机。他们主张通过将配置详细信息从存储库中拉出，任何特定的计算机配置都应在该计算机启动时进行。这是“牛而不是宠物”的最终表达。

不可变的体系结构专门针对机器配置，这些机器配置在创建机器映像后无需更改。如果需要更改，请烘烤新的实例映像，关闭旧的实例映像，然后启动新的实例映像。

云技术改变了硬件和软件之间的边界，因此许多以前是硬件世界专有的技术操作也是软件领域的主题。共享计算环境可能与计算机本身一样古老^1，但是云技术可以通过提供方便且熟悉的隐喻与之交互来普及它们：云用户保留实例，完整的计算机或模拟对象，而较旧的共享计算环境则具有所有可能的设置。局限性很大，“您的程序必须在该FTP服务器上上传，将在环境X中运行（通常使用您要使用的任何软件的10y旧版本），最多60分钟”对于以前的用户或实际用户来说听起来都很熟悉计算中心。

这种转变的实际结果是，部署过程现在可以由软件人工制品来表示。（部署过程是说明如何设置基础结构的说明，其中包括数据库，Web服务器或属于该基础结构的任何内容，以及它们运行所在的网络。）与这些新的镜头一起，服务器的手动维护看起来像手动修补生产代码–仅在极少数情况下才是可取的。手动维护很容易在生产中实际运行的系统和描述这些系统的代码之间引入差异，这反过来又意味着行为不可重现，无法进行错误分析，双重错误修复以及其他灾难。

在一成不变的服务器模式仅仅是上述口头禅云操作的换位，根据我们应该避免正在运行的程序的人工维护。不可变服务器模式建议不要自动配置服务器，而建议使该配置自动化。

实现方式

尽管不可变服务器模式的总体思路很明确，但是实现方面有很多细微差别。例如，一些方法建议根本不更新服务器，而是系统地替换服务器。这是因为更新会产生这样的情况：部署由在几个不同的时间启动并经过几个不同的更新过程的服务器组成，这意味着一组不均匀的服务器，并且可能导致服务器处理其工作方式的细微差异。第二个流行的变化点是有关远程访问服务器的规则。有些人喜欢禁用对服务器的完全远程管理访问，以确保永远不会进行手动维护。

历史记录

据我所知，术语“不可变的服务器”已经由基夫·莫里斯（Kief Morris）推广，但是这个想法本身已经很老了。在1999年，FreeBSD监狱已经普及了使一次性计算环境的配置完全自动化的想法，这就是我很多年才开始实现“不可变服务器”模式的方法，直到我听到这个名称来描述这种技术。

以基于CD-ROMS的物理不变性为幌子的不变性也已成为制造可信计算系统的流行措施。不可将其与不变的服务器模式相混淆。

不可变服务器是指不能进行任何更改的服务器（理想情况下，除了更新和安全补丁程序以外）。无需更改服务器上的软件，而是使用所需的软件为新服务器创建假脱机，然后终止较旧的服务器。

此概念有助于确保您的测试，开发和QA服务器完全相同，这出于该问题范围之外的多种原因而非常重要。不可变服务器的另一个好处是能够将应用程序回滚到较旧的服务器上。例如，我需要在生产服务器1上更改K，所以我将服务器2后台处理并更改K。现在，在10分钟后，我注意到K破坏了我的应用程序，而不必立即进行修复，这可能需要几个小时并可能导致我的客户停机，我将流量重定向回服务器1，而我却发现2出了什么问题。

最好的解释可以（一如既往）在Martin Fowler的bliki文章Immutable Servers上找到。

服务器（无论是硬件还是云中的虚拟服务器）通常都在其上运行操​​作系统和应用程序。

通常，应用程序和操作系统组件需要配置并需要进行更改。例如安全补丁，应用程序新版本的部署和配置更改。

当您认为任何更改都是服务器状态的突变时，该术语immutable就会变得更有意义。这意味着在这样的服务器上不允许任何突变。

当人们参与更改服务器状态时（通常是版本的部署，配置更改或安全路径），通常是这种情况。结果是服务器不再按预期工作。例如，由于配置错误等原因，该应用程序可能现在无法运行。

这就是为什么建立了创建不可变服务器的实践的原因。与不可变的服务器，一个图像的服务器的与所有的结构中，补丁，应用在捆绑版本创建的。然后该服务器的图像可用于创建在各种环境中的服务器。

使用此类图像的第一个环境将是可以测试该图像工作的环境。检测到任何异常，然后才可以将此类映像提升到生产环境，以使用新版本（已知运行良好）替换那里的服务器。

一旦创建映像和提升映像的过程自动化，您将获得非常可靠的防故障过程，该过程几乎不需要人工，并且很少有机会将故障引入服务。

通常，不可变服务器甚至不包含任何“输入”它们的方法，例如ssh服务器丢失。在这种情况下，通常还会将服务器的所有度量（度量标准，日志）都运送到外部系统，例如度量标准数据库或日志聚合服务。

对于容器（请参阅：Docker），还有一个过程来创建映像，然后将它们生成到正在运行的容器中。这些通常会被基于更新图像的新容器替换，并且永不突变。意思是没有人进入容器来通过引入更改来“修复某些东西”。

让我们从相反的角度开始，什么是可变服务器？

传统上，可变服务器基础结构是不断进行修改和更新的基础结构。您可以将外壳固定到其中，升级软件包，对其进行配置，安装服务并向其中部署新代码。这就是使其可变的原因，您可以对其进行突变或修改。

不变的基础架构是另一种基础架构范式，其中服务器在部署后再也不会修改。如果需要以任何方式更新，修复或修改某些内容，则可以使用具有适当更改的通用映像构建新服务器，以替换旧服务器。经过验证后，它们便会投入使用，旧的将退役。

为什么使用它们？ 不变的基础架构的好处是基础架构具有更高的一致性和可靠性，以及更简单，更可预测的部署过程，并且可以缓解可变基础架构中常见的服务器问题，例如服务器崩溃或其他原因造成的停机。

但是您必须知道如何通过全面的部署自动化和快速的服务器配置来有效地配置它。

想象一下，您正在开采比特币，如果服务器崩溃，您将不希望停机，您将需要尽快对其进行备份，因此，不变的基础架构应该是解决方案。