什么是不可变基础设施？

组织可以通过两种方法管理基础设施：可变和不可变。不可变基础设施采用完全替换服务器的方式，而非对其进行修改。可变基础设施采用原地修改服务器的方式，直接在生产服务器上实施更新、补丁及配置变更。

因为它主要是在修改现有服务器，可变基础设施看起来似乎更高效。但是，有两个因素通常会使不可变基础设施更实用、更受欢迎。

首先，云计算和容器化改变了部署速度。组织现在可以在几分钟内替换虚拟机 (VM) 和容器，而不是像物理服务器那样需要数小时。基础设施自动化工具可以调配和配置新的服务器和 IT 资源，并规模化地应用统一的变更。

其次，不可变基础设施可以显著减少配置漂移，这是可变基础设施的常见问题，即系统随着变更的累积逐渐偏离其预期状态。当网络问题中断部署过程，导致部分更新或更新失败时，配置漂移尤其常见。这种漂移可能会导致性能不佳、安全漏洞和合规性违规行为。

例如，在 100 台生产服务器上部署安全更新时，自动化工具可以创建 100 台预安装了更新的新服务器，并单独对它们进行验证。验证完成后，他们会在几分钟内重定向流量并停用旧服务器，实现零停机时间。

不可变基础设施遵循三阶段工作流程：调配新资源、部署资源，以及在需要时实现即时恢复。

该工作流适用于服务器、容器、虚拟机、函数或任何其他基础设施资源的整个生命周期。

调配会自动创建新的 IT 基础设施组件，这些组件使用基础设施即代码 (IaC)，这是一种使用声明式模板或代码来定义预期基础设施状态的做法。

要更新不可变的环境，团队会创建一个具有已定义配置的全新资源，而不是使用 SSH（一种用于安全远程服务器访问的网络协议）来修改现有资源。

然后，所有基础设施更改都会记录在 Git 等版本控制系统中，确保这些更改经过测试且可重现。

常用的调配工具包括：

• Terraform：HashiCorp 的基础设施即代码平台通过其 API 在 AWS、Google Cloud、Azure 以及本地环境中调配和管理基础设施，使用声明式的 HCL 语法和状态文件来跟踪变更。

• Docker：基于分层文件系统和操作系统级虚拟化构建轻量级容器镜像，主要在 Linux 系统上运行，也支持 Windows 和 macOS，使部署速度比传统虚拟机更快。

• Packer：HashiCorp 的工具，可根据单一的 JSON 或 HCL 配置，同时为多个云供应商和平台创建相同的机器镜像（如 AWS 的 AMI、VMware 模板、Docker 容器）。

• AWS CloudFormation：这是一款基于 JSON/YAML 模板的 AWS 原生工具，可通过内置的回滚与漂移检测功能实现 AWS 资源调配。

• Pulumi：该 IaC 平台支持使用常用编程语言（Python、TypeScript、Go）替代领域专用语言，使开发者能够运用循环和条件判断等标准编程结构。

需要说明的是，Puppet 与 Chef 最初是为可变基础设施设计的工具，其原生工作模式为原地更新服务器，不过目前已有团队将其与不可变基础设施方法结合使用。

不可变基础设施中的部署具有原子性，要么完整成功，要么完全不执行。这种方法与 DevOps 实践和持续集成管道相一致，强调自动化测试、快速迭代和可靠部署。

自动化工具部署新版本的资源，将流量重定向到新版本，然后停用旧版本。如果在部署过程中出现问题，旧资源将保持不变并继续运行，从而消除停机时间和依赖性风险。

常见的部署和编排工具包括：

• Kubernetes：开源容器编排平台，通过自我修复、自动扩展和跨机器簇的滚动更新来大规模管理云原生容器化应用。

• Jenkins：基于服务器的 CI/CD 管道，通过庞大的插件生态系统（1800 多个插件）实现构建、测试和部署自动化，可自定义构建、测试和部署流程。

• GitHub 操作：内置于 GitHub 仓库的事件驱动型 CI/CD 平台，可通过代码提交、拉取请求或定时计划触发，无需依赖外部服务器。

• Ansible (Red Hat)：主要是配置管理工具，但也用于部署。它使用 YAML 运行手册进行无智能体自动化，与 Puppet 或 Chef 不同，无需在被管理节点上安装任何软件。

由于不可变基础设施中的服务器是短暂的（不断被替换），因此持久性数据必须存储在外部。组织使用云数据库、块存储或对象存储服务，将数据与被替换的服务器分离存放。

当新服务器上线时，它会通过这些外部存储系统重新连接到现有数据。配置和元数据通常存放在类似 Git 的版本控制系统中。

每次更新都会创建一个新实例，为回滚保留一个干净的镜像。进行调配和部署的同样的自动化工具可以在几分钟内恢复先前的版本。团队重新部署先前的镜像，而不是调试和排查被修改的服务器，从而大幅减少在配置管理变更失败时传统上所需的排查工作。

不可变基础设施的优势主要体现在部署过程中，其不可变性使其更简单、更一致。

不可变基础设施通过原子性部署消除模糊的服务器状态，更新要么完全成功，要么彻底失败。

可变基础设施面临部分更新的风险，可能导致不可预测的“中间状态”，其特性对管理员而言并非完全可知。这种情况会使故障排除变得困难并增加安全风险。

不可变基础设施消除了出现这种状态的可能性。如果更新失败，服务器将保持其有据可查的状态。如果成功，新服务器将以完全配置和测试后的状态交付。

不可变基础设施有助于实现快速的水平扩展，即通过向网络中添加更多较小的机器（而不是一台大型机器）来满足需求。水平扩展的系统容错能力更强，并且可以通过分配工作量来减少处理瓶颈。

这种方法是通过使用负载均衡器来实现的，负载均衡器用于将网络流量分配到多台服务器上以提高性能。Nginx 和 Amazon 的 AWS Elastic Load Balancing (ELB) 等工具通过特定算法，将用户请求分配到最高效的服务器，从而有效支持这一实践。

负载均衡与容器编排的结合，使得采用可复制模板的不可变基础设施，能够快速部署多台相同服务器。当网络预计会出现大量流量高峰时，例如购物节假日或门票销售期间，这种设置可能特别有用。在协调跨区域业务时同样具有优势，能有效应对不同时段出现重叠的流量高峰。

不可变基础设施通过消除不可预测的“雪花状态”（即更新失败后服务器配置未知）来增强安全性，并维护所有更改的完整审计跟踪。

每台服务器都严格遵循描述它的源镜像文件，这使得识别安全漏洞（例如未经授权的软件安装或权限提升）和运行安全审计变得更加简单。版本控制系统跟踪对系统所做的每项更改，包括谁进行了更改、何时更改以及为何更改。这种不可更改的历史记录可加快取证分析和事件响应速度。团队可以立即识别受损的配置，并在必要时回滚到已知良好的状态。

不可变基础设施也消除了使用安全外壳 (SSH) 登录来就地编辑服务器的需要，从而减少了网络的整体攻击面。

与传统可变基础设施相比，不可变基础设施在数据存储方面存在明显短板。

在可变基础设施中，服务器可能将关键应用数据写入本地磁盘，若删除或替换该服务器及磁盘，将导致系统风险甚至崩溃。因此，在不可变基础设施中，数据必须存储在外部，这给系统增加了额外的复杂性。

这种方法可通过云数据库、块存储或对象存储等外部数据存储方案来实现。当一台新的虚拟机上线时，它可以通过这个外部存储空间无缝地与现有数据重新连接。组织通常在 Git 等版本控制系统中维护配置和元数据。

然而，不可变基础设施是否真正“不可变”仍存有争议。这一局限源于外部存储的网络用户数据持续处于流动状态，因而无法与已知状态进行比对。