不可变的服务器:为什么?
在云环境中出现了一些管理动态虚拟机(vm)的实用策略:
- 推
中央设施通过远程连接root和运行脚本来完成新的VM。同样，中央设施将更新和修补程序推送到运行VM实例。基础架构管理工具使用各种方案来保护来自黑客的根凭据。 - 拉
每个虚拟机模板包括配置管理工具和一个在启动时运行的初始化脚本。该脚本连接到管理云环境的服务器，以便进行自我注册。正在运行的实例负责检查可用的更新和补丁，并保持它们是最新的。 - 不可变的
引导过程确保新VM实例在网络上激活之前得到充分配置和发放。一旦运行，实例就永远不会被修改。当需要更新或补丁时，将根据需要从源和/或模板配置新实例，并销毁旧实例。云基础设施管理工具使得这个过程对应用程序是不可见的，从外部的角度来看，应用程序似乎是“总是打开的”。
概括
这是一个非常高级的描述。有许多细节可以从一个设置到另一个设置都不同。一般来说，策略推那拉， 和不变的情况下代表频谱从更易于安全，更难地缩放到更安全更容易缩放的频谱。您可以通过潜入特定云环境和配置产品的实施细节来争辩。这只是一个概括。
掌握配置管理
一种众所周知的方法无主的配置管理简化环境，方便扩展，提高安全性。配置和供应是脱机运行的，而不是使用主服务器来推送更新或作为获取更新的接触点。通过手动执行脚本或通过定时批处理过程，脚本可以将更新推送到服务器。为了支持拉策略，可以使用针对每个平台(如yum、apt或chocolatey)的包管理器打包更新。然后，运行实例可以使用标准机制从安全存储库中提取它们的更新。
挑战：配置漂移
当许多给定服务器定义的实例运行时，可以对各个实例的配置进行更改。在长时间之前，没有保证给定类型的所有服务器具有相同的配置。这可以使支持服务器的工作复杂化。较长的实例仍然升起并运行，修改的机会越大;通常，当某人手动更改服务器配置时，不经过通常的交付管道。这种现象被称为配置漂移。
挑战：安全
不幸的是，我们生活在一个坏人不断试图闯入系统的世界里。他们资金充足，经常得到政府的支持，整天除了攻击计算机网络什么也不做。他们拥有的安全技能比我们雇佣来保护我们网络的任何人都要多。没有切实可行的办法来确保没有人能够侵入我们的系统，也没有办法保证我们能够发现攻击，并在破坏发生之前处理它。
连续同步
使用涉及更新运行VM实例的策略（推送或拉动）时，技术连续同步已成为一种方法来减轻配置漂移和安全的两个关键挑战。在预定的基础上，对运行实例执行脚本以重新应用配置设置。脚本是Idempotent.，这意味着它们的设计是为了使它们运行多次不会造成任何问题。自上次更新以来更改的任何配置设置将被覆盖，已经正确的设置将不会被破坏。
该策略通过挖掘所有配置来减轻配置漂移，返回到它们每小时或两个时的所有配置。某些服务器可能不时暂时错误配置。
相同的策略减轻了通过重新配置每个实例来注入恶意软件的风险。这可能导致恶意软件被覆盖或删除，即使系统管理员不知道存在恶意软件。然而，这不是一个可靠的故障保险。
不可变的服务器策略
无主配置管理可以在某种程度上简化推或拉策略，但是不可变服务器策略通过完全消除同步的需要使事情变得更简单。云环境旨在以一种对应用程序不可见的方式动态地摧毁和创建vm。该环境管理实例之间的客户机通信流的切换，以便在销毁实例之前完成正在进行的事务。该环境还管理日志输出，以便以一种有意义的方式对数据进行整合，以便跟踪与应用程序相关的问题，而不管支持该应用程序的vm如何变化。
这些特性最初是为了支持弹性云。这意味着给定类别中的服务器数量，支持给定的应用程序，可以基于负载动态增加或减少。要使这无缝且可无形的应用程序，环境必须能够在应用程序处于活动状态时启动和关闭VM实例，而无需将任何日志数据或更新到应用程序文件和数据库，而不会对最终用户的影响。
菲尼克斯服务器
由于该功能，替换VM实例是可行的，而不是保持长期和应用更新。这导致所谓的菲尼克斯服务器战略。对于从自己的灰烬中升起的神话般的鸟，即使没有要应用的更新或修补程序，凤凰服务器也经常销毁并重建并重建并重新编写。
无法修改不可改变的实例，因此以这种方式管理的服务器不受配置漂移的影响。由于它不存在的事实来解决问题。
恶意软件可能会被注入到运行中的实例中，但它不会活太久，因为凤凰会自我焚毁并再次升起，重生时只安装了版本控制下的病毒扫描模板中的内容。因此，不可变phoenix服务器提供了非常好的安全保护。然而，要小心产生一种错误的安全感，因为专业的网络罪犯和网络战士除了找方法入侵你的系统外，他们的时间没有其他事可做，而你白天有很多其他事情要做。你永远不可能完全挫败他们，但你可以采取措施让他们的任务不那么方便。
结论
对我来说，安全问题是足以选择最多的有弹性策略的原因。然而，不可被广泛采用不变的服务器和凤凰服务器。相反，大多数系统管理员似乎拥有关于服务器的“旧学校”心态：他们尽可能长时间保持每个实例，甚至延伸到多年的连续上涨时间。由于停机费用和重启失败系统的延迟，这是一个合理的策略。在当代云环境中，相同的策略不会产生价值。如果有的话，它会增加风险，成本和困难。