服务器更新与变更的模式与实践

# 服务器更新与变更的模式与实践 ## 1 服务器变更管理的重要性 在动态基础设施环境中，创建新服务器相对容易，但保持已创建服务器的更新却颇具挑战。这种情况常常导致服务器配置不一致，形成难以管理的混乱局面。不一致的服务器会使自动化管理变得困难，进而导致基础设施难以维护。 ### 1.1 服务器变更管理的目标 - **全面更新**：确保所有相关现有服务器都能及时应用变更。 - **保持一致**：防止相似服务器出现配置差异。 - **简化流程**：让自动化流程成为团队成员进行变更的最便捷方式。 ### 1.2 有效服务器变更流程的特点 - **轻松变更**：无论受影响的服务器数量多少，变更过程都应轻松完成。 - **无人值守**：变更应能自动应用，无需人工持续干预。 - **快速反馈**：能迅速发现变更过程中出现的错误。 ## 2 服务器变更管理的模型 ### 2.1 临时变更管理 传统做法是在需要特定变更时才对服务器进行操作。即便有像 Chef、Puppet、Ansible 等新的配置管理工具，许多团队仍仅在有特定变更需求时才使用它们。这种方式容易导致服务器配置不一致，影响自动化的全面应用。因为要在多台服务器上运行自动化流程，服务器的初始状态需要基本一致。 ### 2.2 配置同步 持续同步是指按照无人值守的时间表，定期将配置定义应用并重新应用到服务器上。这样可以确保系统中受这些定义覆盖的部分保持一致，从而保证自动化流程的可靠运行。配置同步有助于维护自动化基础设施的规范性，配置运行的时间间隔越短，就能越快发现配置定义中的问题，团队也能更快地进行修复。不过，编写和维护配置定义存在一定开销，且能通过定义合理管理的服务器配置范围有限，这使得服务器配置的其他部分容易受到工具之外的变更影响，从而导致配置漂移。 ### 2.3 不可变基础设施 不可变基础设施是通过构建新的基础设施元素来进行配置变更，而不是对正在使用的元素进行修改。这样可以确保任何变更在投入生产前都经过测试，避免对运行中的基础设施进行变更可能产生的意外影响。服务器的配置被嵌入到服务器模板中，因此服务器的内容是可预测的，除了运行时状态和数据部分，其他部分都经过了测试。不过，不可变服务器仍然可能受到配置漂移的影响，通常会结合缩短服务器寿命的做法（如 Phoenix Server 模式）来减少未管理变更的机会，也可以将服务器文件系统中不应在运行时更改的部分设置为只读。需要注意的是，“不可变”这个术语更多地适用于服务器的配置，而不是整个服务器，它有助于团队明确区分配置和数据。 ### 2.4 容器化服务 标准化的轻量级容器打包、分发和编排方法的日益普及，为简化服务器配置管理提供了机会。在这种模式下，服务器上运行的每个应用程序或服务都与其所有依赖项一起打包到容器中。通过构建和部署新的容器版本来进行应用程序的变更，这是不可变基础设施概念在应用程序层面的应用。托管容器的服务器可以大大简化，只需保留运行容器所需的软件和配置。目前，很少有组织将其基础设施进行如此彻底的转换，大多数仅在少数经常变更的应用程序和服务中使用容器。但随着容器化技术的成熟，它有可能成为基础设施管理的主流模式。 以下是这四种模型的对比表格： | 模型名称 | 特点 | 优点 | 缺点 | | ---- | ---- | ---- | ---- | | 临时变更管理 | 仅在需要时进行变更 | 简单直接 | 易导致配置不一致，影响自动化 | | 配置同步 | 定期应用配置定义 | 保持配置一致，利于自动化 | 编写维护有开销，部分配置易漂移 | | 不可变基础设施 | 构建新元素进行变更 | 变更可测试，内容可预测 | 仍可能有配置漂移 | | 容器化服务 | 应用打包到容器，通过容器变更 | 简化服务器管理 | 目前应用范围有限 | ## 3 通用模式与实践 ### 3.1 配置应用于服务器供应过程 采用配置同步模型的团队通常在新服务器创建时使用相同的工具和定义进行供应，确保应用最新的配置定义。在构建服务器模板时，也可能使用相同的工具应用部分通用定义。服务器管理过程可能在以下几个阶段使用配置管理工具： - **模板打包**：应用特定模板中所有服务器角色通用的配置定义子集。 - **服务器创建**：运行配置工具，应用给定服务器角色的所有定义，使服务器为指定角色做好准备，并应用自模板打包以来通用定义的任何变更，避免为每个变更更新服务器模板。由于大部分通用配置和软件包已包含在模板中，服务器