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

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

1 服务器变更管理的重要性

在动态基础设施环境中，创建新服务器相对容易，但保持已创建服务器的更新却颇具挑战。这种情况常常导致服务器配置不一致，形成难以管理的混乱局面。不一致的服务器会使自动化管理变得困难，进而导致基础设施难以维护。

1.1 服务器变更管理的目标

• 全面更新 ：确保所有相关现有服务器都能及时应用变更。
• 保持一致 ：防止相似服务器出现配置差异。
• 简化流程 ：让自动化流程成为团队成员进行变更的最便捷方式。

1.2 有效服务器变更流程的特点

• 轻松变更 ：无论受影响的服务器数量多少，变更过程都应轻松完成。
• 无人值守 ：变更应能自动应用，无需人工持续干预。
• 快速反馈 ：能迅速发现变更过程中出现的错误。

2 服务器变更管理的模型

2.1 临时变更管理

传统做法是在需要特定变更时才对服务器进行操作。即便有像 Chef、Puppet、Ansible 等新的配置管理工具，许多团队仍仅在有特定变更需求时才使用它们。这种方式容易导致服务器配置不一致，影响自动化的全面应用。因为要在多台服务器上运行自动化流程，服务器的初始状态需要基本一致。

2.2 配置同步

持续同步是指按照无人值守的时间表，定期将配置定义应用并重新应用到服务器上。这样可以确保系统中受这些定义覆盖的部分保持一致，从而保证自动化流程的可靠运行。配置同步有助于维护自动化基础设施的规范性，配置运行的时间间隔越短，就能越快发现配置定义中的问题，团队也能更快地进行修复。不过，编写和维护配置定义存在一定开销，且能通过定义合理管理的服务器配置范围有限，这使得服务器配置的其他部分容易受到工具之外的变更影响，从而导致配置漂移。

2.3 不可变基础设施

不可变基础设施是通过构建新的基础设施元素来进行配置变更，而不是对正在使用的元素进行修改。这样可以确保任何变更在投入生产前都经过测试，避免对运行中的基础设施进行变更可能产生的意外影响。服务器的配置被嵌入到服务器模板中，因此服务器的内容是可预测的，除了运行时状态和数据部分，其他部分都经过了测试。不过，不可变服务器仍然可能受到配置漂移的影响，通常会结合缩短服务器寿命的做法（如 Phoenix Server 模式）来减少未管理变更的机会，也可以将服务器文件系统中不应在运行时更改的部分设置为只读。需要注意的是，“不可变”这个术语更多地适用于服务器的配置，而不是整个服务器，它有助于团队明确区分配置和数据。

2.4 容器化服务

标准化的轻量级容器打包、分发和编排方法的日益普及，为简化服务器配置管理提供了机会。在这种模式下，服务器上运行的每个应用程序或服务都与其所有依赖项一起打包到容器中。通过构建和部署新的容器版本来进行应用程序的变更，这是不可变基础设施概念在应用程序层面的应用。托管容器的服务器可以大大简化，只需保留运行容器所需的软件和配置。目前，很少有组织将其基础设施进行如此彻底的转换，大多数仅在少数经常变更的应用程序和服务中使用容器。但随着容器化技术的成熟，它有可能成为基础设施管理的主流模式。

以下是这四种模型的对比表格：
| 模型名称 | 特点 | 优点 | 缺点 |
| ---- | ---- | ---- | ---- |
| 临时变更管理 | 仅在需要时进行变更 | 简单直接 | 易导致配置不一致，影响自动化 |
| 配置同步 | 定期应用配置定义 | 保持配置一致，利于自动化 | 编写维护有开销，部分配置易漂移 |
| 不可变基础设施 | 构建新元素进行变更 | 变更可测试，内容可预测 | 仍可能有配置漂移 |
| 容器化服务 | 应用打包到容器，通过容器变更 | 简化服务器管理 | 目前应用范围有限 |

3 通用模式与实践

3.1 配置应用于服务器供应过程

采用配置同步模型的团队通常在新服务器创建时使用相同的工具和定义进行供应，确保应用最新的配置定义。在构建服务器模板时，也可能使用相同的工具应用部分通用定义。服务器管理过程可能在以下几个阶段使用配置管理工具：
- 模板打包 ：应用特定模板中所有服务器角色通用的配置定义子集。
- 服务器创建 ：运行配置工具，应用给定服务器角色的所有定义，使服务器为指定角色做好准备，并应用自模板打包以来通用定义的任何变更，避免为每个变更更新服务器模板。由于大部分通用配置和软件包已包含在模板中，服务器创建过程会更快。
- 服务器更新 ：定期应用配置定义，保持服务器配置的一致性和最新状态。

3.2 最小化服务器模板

服务器初始配置越简单，后续管理工作就越少，这对安全性、性能、稳定性和故障排除都有益。可以通过从标准镜像构建模板并运行脚本删除不必要的元素来实现，或者使用精简的操作系统发行版（如 Snappy Ubuntu、RedHat Atomic、CoreOS 等），有选择地添加所需内容。

3.3 模板变更时替换服务器

当服务器模板更新并创建新服务器时，新服务器可能与旧模板创建的现有服务器不同。如果服务器使用时间较长且模板多次更新，可能会出现配置漂移，而持续同步无法解决这个问题。因此，建议在模板更新时逐步替换运行中的服务器，例如先在测试环境应用新模板，再推广到更敏感的环境。对于服务器集群，可以依次替换成员以避免服务中断。

3.4 Phoenix 服务器模式

一些组织发现，即使服务器模板未更新，定期替换服务器也是应对配置漂移的有效方法。通过为所有服务器设置最大寿命，并按计划重建超过该限制的服务器，可以实现对服务器表面区域的全面自动管理。在重建服务器时，应确保服务不中断，例如使用零停机替换模式。

以下是服务器供应过程中配置应用的 mermaid 流程图：

graph LR
    A[模板打包] --> B[服务器创建]
    B --> C[服务器更新]

4 持续同步的模式与实践

4.1 推送与拉取

持续同步可以通过两种方式实现：
- 推送模式 ：由中央进程控制时间表，连接到各个服务器并发送和应用配置。许多服务器配置工具都有一个主服务器来推送配置，可能需要在每个受管理的服务器上运行客户端，通过网络端口或消息总线接收命令。也有系统使用 ssh 等远程命令协议来连接和执行配置命令。推送模式的优点是可以集中控制配置变更的时间和位置，有助于按特定顺序或时间安排在基础设施中协调变更。
- 拉取模式 ：在受管理的服务器上安装代理，由代理安排和应用变更。可以是使用 cron 的定时进程，也可以是运行自己调度程序的服务。客户端从主服务器或中央存储库下载最新的配置定义并应用。拉取模式的安全模型更简单，因为受管理的服务器不需要为自动化系统提供连接端口或登录账户。而且根据配置工具的设计，拉取系统可能比推送系统更具可扩展性，因为推送系统的主服务器需要打开与受管理系统的连接，在大规模基础设施中可能成为瓶颈。

4.2 无主配置管理

许多团队发现，即使配置工具支持集中式服务器，放弃这种方式也能提高稳定性、可用性和可扩展性。做法是在离线模式下运行配置管理工具（如使用 chef-solo 而非 chef-client），使用下载到受管理服务器本地磁盘的配置定义副本。这样可以消除主服务器作为潜在故障点，定义可以作为静态文件托管，使用对象存储服务可以很好地实现扩展。另一种实现无主模式的方法是将定义打包成系统包（如 .rpm 或 .deb 文件），存放在私有包存储库中，通过 cron 脚本执行 yum update 或 apt-get update 下载并解压最新定义，然后运行配置工具。

4.3 持续同步流程

持续同步是将配置定义应用并反复应用到服务器的过程。一旦配置定义应用到服务器，每次配置过程运行时，如果定义没有修改，服务器将不再进行更改。当定义被修改并可供服务器使用时，下一次配置过程运行时，服务器将应用这些更改。这个过程还能确保自动化之外的变更被还原，当有人在服务器上手动进行与配置定义冲突的更改时，下一次配置过程运行时会重新应用定义，撤销手动更改。

以下是推送和拉取模式的对比表格：
| 模式 | 控制方式 | 安全性 | 可扩展性 |
| ---- | ---- | ---- | ---- |
| 推送 | 中央进程控制 | 需管理服务器暴露连接方式，安全管理较复杂 | 大规模时主服务器连接可能成瓶颈 |
| 拉取 | 服务器代理控制 | 管理服务器无需暴露连接，安全管理较简单 | 设计合理时可扩展性更好 |

以下是持续同步流程的 mermaid 流程图：

graph LR
    A[初始配置定义应用] --> B[配置定义未修改]
    B --> C[服务器无更改]
    A --> D[配置定义修改]
    D --> E[下次配置过程运行]
    E --> F[服务器应用更改]

综上所述，在服务器更新与变更管理中，选择合适的模型和实践方法对于确保服务器配置的一致性、提高自动化管理效率以及保障基础设施的稳定性至关重要。不同的模型和实践各有优缺点，需要根据实际情况进行综合考虑和应用。

5 不同模型和实践的应用场景分析

5.1 临时变更管理的应用场景

临时变更管理适用于服务器变更需求较少、对自动化依赖程度不高的场景。例如，一些小型企业的内部服务器，业务相对稳定，变更需求主要集中在特定的业务功能添加或调整时。在这种情况下，手动进行变更操作虽然简单直接，但需要注意记录每次变更的内容和时间，以便后续的维护和排查问题。

5.2 配置同步的应用场景

配置同步适合对服务器配置一致性要求较高、自动化程度较高的场景。大型企业的生产环境服务器通常需要保持高度一致的配置，以确保业务的稳定运行。通过定期同步配置定义，可以及时发现和纠正配置差异，保证自动化流程的可靠性。例如，在电商平台的服务器集群中，使用配置同步可以确保所有服务器的软件版本、参数设置等保持一致，避免因配置不一致导致的业务故障。

5.3 不可变基础设施的应用场景

不可变基础设施适用于对变更风险控制要求较高、需要快速部署和回滚的场景。互联网应用的开发和部署过程中，经常需要频繁进行版本更新和功能迭代。采用不可变基础设施可以将变更封装在新的服务器模板中，在投入生产前进行充分测试，降低变更带来的风险。同时，如果出现问题，可以快速回滚到之前的稳定版本。例如，在微服务架构中，每个微服务可以使用不可变基础设施进行部署，提高系统的稳定性和可维护性。

5.4 容器化服务的应用场景

容器化服务适用于需要快速部署、弹性伸缩和资源隔离的场景。云计算环境中的多租户应用、DevOps 开发流程等都非常适合使用容器化服务。通过将应用程序及其依赖项打包到容器中，可以实现快速部署和迁移，同时利用容器的资源隔离特性，提高资源利用率和安全性。例如，在大数据处理平台中，使用容器化服务可以根据业务需求动态调整计算资源，提高处理效率。

以下是不同模型应用场景的对比表格：
| 模型名称 | 适用场景 | 优势体现 |
| ---- | ---- | ---- |
| 临时变更管理 | 小型企业内部服务器，变更需求少 | 操作简单，适合简单业务场景 |
| 配置同步 | 大型企业生产环境服务器集群 | 保证配置一致，提高自动化可靠性 |
| 不可变基础设施 | 互联网应用开发部署，微服务架构 | 降低变更风险，便于快速部署和回滚 |
| 容器化服务 | 云计算多租户应用，DevOps 流程 | 快速部署，弹性伸缩，资源隔离 |

6 实施建议与注意事项

6.1 选择合适的模型

在选择服务器变更管理模型时，需要综合考虑企业的业务需求、技术能力、资源状况等因素。如果企业对自动化程度要求较高，且有一定的技术团队支持，可以优先考虑配置同步、不可变基础设施或容器化服务等模型；如果企业业务相对简单，变更需求较少，可以选择临时变更管理模型。同时，也可以根据不同的业务场景组合使用不同的模型，以达到最佳的管理效果。

6.2 做好测试和监控

无论采用哪种模型，都需要做好测试和监控工作。在进行变更前，要对变更进行充分的测试，确保变更不会对系统造成负面影响。可以使用测试环境进行模拟测试，验证变更的可行性和稳定性。在变更过程中，要实时监控服务器的状态和性能指标，及时发现和处理异常情况。例如，可以使用监控工具对服务器的 CPU、内存、网络等资源进行实时监控，一旦发现异常，立即采取措施进行处理。

6.3 加强团队培训

服务器变更管理涉及到多种技术和工具，需要团队成员具备相应的知识和技能。因此，要加强团队培训，提高团队成员的技术水平和管理能力。可以定期组织内部培训课程，邀请专家进行技术分享，让团队成员了解最新的技术趋势和最佳实践。同时，要鼓励团队成员进行实践和探索，积累经验，提高解决问题的能力。

6.4 建立完善的文档体系

建立完善的文档体系对于服务器变更管理至关重要。要详细记录服务器的配置信息、变更历史、测试结果等内容，以便后续的维护和参考。文档要保持及时更新，确保其准确性和完整性。例如，可以使用文档管理工具对服务器文档进行集中管理，方便团队成员查阅和共享。

以下是实施建议的列表：
1. 综合考虑业务需求、技术能力和资源状况，选择合适的变更管理模型。
2. 在变更前进行充分测试，变更过程中实时监控服务器状态。
3. 加强团队培训，提高团队成员的技术水平和管理能力。
4. 建立完善的文档体系，记录服务器配置、变更历史等信息。

7 总结

服务器更新与变更管理是确保服务器配置一致性、提高自动化管理效率和保障基础设施稳定性的关键。通过介绍临时变更管理、配置同步、不可变基础设施和容器化服务等四种服务器变更管理模型，以及通用模式与实践、持续同步的模式与实践等内容，我们了解到不同模型和实践各有优缺点，适用于不同的应用场景。在实际应用中，需要根据企业的具体情况选择合适的模型和实践方法，并做好测试、监控、团队培训和文档管理等工作，以实现服务器变更管理的最佳效果。

希望本文能够为从事服务器管理和运维的人员提供有益的参考，帮助他们更好地应对服务器更新与变更带来的挑战。

通过以下 mermaid 流程图总结整个服务器变更管理的流程：

graph LR
    A[选择变更管理模型] --> B[实施变更]
    B --> C[测试与监控]
    C --> D{是否通过测试?}
    D -- 是 --> E[应用变更到生产环境]
    D -- 否 --> F[调整变更并重新测试]
    E --> G[持续监控和维护]
    F --> B

以上就是关于服务器更新与变更的模式与实践的详细介绍，希望能对大家有所帮助。在实际操作中，要根据具体情况灵活运用这些知识，不断优化服务器管理流程，提高服务器的可靠性和性能。