基础设施即代码，第2版

第 12 章 管理服务器的更改 管理对服务器的更改

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

许多组织和团队专注于构建服务器和其他基础设施的流程和工具，却忽视了变更。当需要变更--修复问题、应用安全补丁或升级软件--时，他们会将其视为异常事件。如果每次变更都是例外情况，那么就无法实现自动化。正是因为这种思维模式，许多组织的系统才会不连贯、不稳定。这也是为什么我们中的许多人把时间都花在了处理枯燥的票据和灭火之间。

我们的系统唯一不变的就是它们的变化。如果我们将系统定义为代码，在动态基础架构平台上运行，并通过变更管道在整个系统中交付代码，那么我们就可以轻松实现例行变更。如果我们的系统只能通过代码和管道来创建和更改，那么我们就能确保系统的一致性，并确保它们符合我们所需的任何策略。

"服务器上有什么 "和"东西从哪里来"描述了服务器上有什么以及所有东西的来源。特定服务器上的所有东西都有一个确定的来源，无论是操作系统安装、系统软件包库还是服务器配置代码。你需要对服务器进行的任何更改，都是对其中之一的更改。

本章将介绍如何通过更改代码来定义服务器上的内容，并以某种方式加以应用。通过对服务器实施可靠的自动更改流程，可以确保在整个服务器中快速、可靠地推出更改。您只需付出最少的努力，就能让所有服务器使用最新批准的软件包和配置。

将配置代码应用到服务器上有几种模式，包括在每次更改发生时应用、持续同步更改以及重建服务器以更改它们。进行更改的另一个方面是如何运行工具将更改应用到服务器，是推送配置还是拉取配置。最后，服务器的生命周期中还有其他几个事件，从暂停、重建到删除服务器。

变更管理模式：何时应用变更

在决定何时对服务器实例应用更改时，有一种反模式和两种模式。

反模式：在更改时应用

也称为：临时自动化。

使用 "变更时应用"反模式，配置代码只有在有特定变更需要应用时才会应用到服务器上。

例如，考虑一个运行多个 Tomcat 应用程序服务器的团队。团队成员在创建新的服务器实例时，会运行 Ansible playbook 来安装和配置 Tomcat，但服务器一旦运行，他们就不再运行 Ansible，直到需要时才运行。当发布新版本的 Tomcat 时，他们会更新他们的操作手册并将其应用到他们的服务器上。

在这种反模式的最极端版本中，你只在服务器上应用你特别打算更改的代码。

我们例子中的团队注意到，其中一个应用程序服务器的流量大增，负载导致 Tomcat 不稳定。团队成员对他们的 playbook 做了一些更改，以优化 Tomcat 配置，适应更高的负载，然后将其应用到出现问题的服务器上。但他们并没有将游戏本应用到其他应用服务器上，因为这些服务器不需要更改。

动机

系统和 Network+ 管理员传统上都是手工管理服务器。需要更改时，登录相关服务器并进行更改。为什么要换一种方式呢？即使是使用脚本的人也倾向于编写和运行脚本来进行特定的更改。应用于变更的反模式就是这种工作方式的延伸，它碰巧使用了基础架构即代码工具，而不是手动命令或开关脚本。

适用性

只在特定变更需要时才应用代码，这对单个临时服务器来说可能没什么问题。但这种方法并不适合持续管理一组服务器。

后果

如果只应用配置代码来进行特定更改，可能会出现代码从未应用到特定服务器实例的长时间间隙。当你最终应用代码时，可能会因为服务器上的其他差异而失败，而不是你要更改的那个。

服务器上的事物总是会在你不注意的时候发生变化。有人可能会手动更改--例如，快速修复故障。还有人可能用新版本的操作系统或应用程序软件包修补了系统。这些都属于我们确信不会破坏任何东西的快速更改。而在一周后，我们却不记得自己做了哪些更改（因为这只是一个小更改），直到我们花了几个小时来调试它所破坏的东西。 ...