22、服务器镜像与集群的管理与应用

服务器镜像与集群的管理与应用

跨团队提供和使用服务器镜像

在许多组织中，通常由一个核心团队负责构建服务器镜像，然后供其他团队使用。这种模式在管理服务器镜像更新时会带来一些挑战。使用镜像的团队需要确保自身已做好使用新版本镜像的准备。例如，内部应用团队可能会在计算团队提供的基础 Linux 镜像上安装 bug 跟踪软件。若计算团队发布了包含更新的基础 Linux 镜像新版本，而这些更新可能与 bug 跟踪软件不兼容。

理想情况下，服务器镜像应融入每个团队的基础设施管道。当拥有镜像的团队通过其管道发布新版本时，各团队的基础设施管道会拉取该版本并更新其服务器实例。内部团队的管道应在重建用户依赖的服务器之前，自动测试 bug 跟踪软件与新镜像版本的兼容性。

有些团队会采取更保守的方法，固定他们使用的镜像版本号。例如，内部应用团队可以将其基础设施固定为使用基础 Linux 镜像的 1 版本。当计算团队发布 2 版本的镜像时，内部应用团队会继续使用 1 版本，直到他们准备好测试并推出 2 版本。许多团队在测试和向服务器基础设施交付变更的自动化不够成熟时会采用这种固定版本的方法，这些团队需要进行更多的手动工作来确保镜像变更的安全性。即使自动化已经成熟，一些团队也会固定那些变更风险较高的镜像（和其他依赖项）。这可能是因为团队部署到镜像上的软件对操作系统的变化更敏感，或者提供镜像的团队（可能是外部团队）有发布存在问题版本的记录，导致信任度较低。

处理镜像的重大变更

服务器镜像的某些变更更为显著，更可能需要手动测试和修改下游依赖项。例如，应用服务器镜像的新版本可能包含应用服务器软件的重大版本升级。对于这种情况，你可以使用语义化版本控制来表明这是一个更重大的变