DevOps必知概念：不可变基础设施
如果你正在学习或刚开始接触DevOps和基础设施自动化，这篇文章将帮助你详细了解不可变基础设施（Immutable infrastructure）模型。
在进入技术解释之前，首先，你应该对可变和不可变这两个词的字面意思有一个清晰的认识。
- 可变的（Mutable）： 可以被改变的东西。意味着你可以在它被创建后继续对它进行修改。
- 不变的（Immutable）： 不能改变的东西。一旦它被创建，你就不能改变其中的任何东西。
现在让我们看一个真实世界的例子，即一所房子。在一所房子里，有一些你可以改变的对象（可变的），也有一些必须被替换的对象（不可变的），如果它们发生了什么变化。例如，你可以给一扇门涂上不同的颜色，更换门把手，给它一个不同的外观。在这里门是一个可变的对象。同时，一个洗脸盆是一个不可变的对象。如果你想改变脸盆的颜色，你需要用一个新的脸盆来替换它。这一点也适用于地砖。
在IT界，我们在软件工程和DevOps中都有可变性和不可变性的概念。在软件工程中，这一概念被应用于面向对象的编程，而在DevOps中，它被应用于基础设施自动化。在本指南中，我们将从DevOps的角度重点讨论不可变的基础设施。
什么是不可变的基础设施？
要理解不可变的基础设施，首先，你应该知道服务器的生命周期。
下面是一个带有应用程序的服务器的简略的生命周期（仅供参考，各组织的流程有所不同）。
- 部署一个服务器。
- SSH进入服务器。
- 安装所需的工具。
- 配置安全代理、防火墙和实用程序以保证安全。(安全加固)
- 安装和配置所需的应用程序。
- 修改应用程序和服务器配置，以提高应用程序的性能。
- 使服务器用于生产工作。
- 每个月登录服务器，为服务器打上安全补丁（服务器更新）。
- 在应用程序可用时进行升级。
正如你所看到的，上面提到的步骤是一个可变的模型。这是因为我们正在根据要求对服务器进行修改。因此，当你使用Ansible、Puppet或Chef等配置管理工具来管理服务器时，你遵循的是可变模式。
「不可变」，就像它的字面意思一样，不可变的基础设施是一个概念，在你部署服务器之后，你不会对它做任何改变。意思是说，服务器在部署的时候已经预先配置好了配置、安装好了工具和应用程序。服务器出现的那一刻，应用程序就开始运行。
如果您想进行任何更改，则应销毁现有服务并用新服务替换。更改可能是打补丁、应用程序升级、服务器配置更改等。
你可以为大多数现代应用遵循不可变的基础设施模型，包括数据库集群。
例如，如果你有应用程序在自动缩放组中运行，而你遵循的是不可变的服务器部署模型。每当你想部署新的代码时，你需要销毁现有的虚拟机，这样由自动缩放启动的新虚拟机就会下载最新的代码。另一种方法是，你需要用带有代码的最新镜像来改变启动模板。
在一个不可变的模型中，在配置方面应遵循标准的最佳实践。
例如，使用配置存储或服务发现工具，将经常改变的配置外部化。一个典型的例子是Nginx的upstream配置。
这样一来，你就不必为小的变化和配置而重新生成服务器。
如果你知道容器，它是不可变基础设施的最好例子。除了外部化的配置，对容器的任何改变都会导致重建。
用于CI/CD的不可变的基础设施模型
那么，不可变的基础设施模式如何用在CI/CD过程？
当你在虚拟机环境的CI管道中遵循不可变的基础设施模式时，可部署的工件将是一个虚拟机镜像或一个docker镜像。
例如，一旦CI完成，利用Docker或packer等工具，你可以把程序代码塞到容器或虚拟机镜像（AWS AMI）中，并使用它在相关环境中进行部署。
当涉及到部署时，你可以遵循蓝绿部署或金丝雀部署。让我们来看看这两种方法。
- 蓝绿模式： 在这种模式下，使用最新的应用程序镜像，你将一组新的服务器（蓝色）与生产服务器（绿色）一起部署，但它不会提供流量。当蓝色服务器被验证OK之后，流量将被重定向到新的（蓝色）服务器组，旧的（绿色）服务器将被销毁。
- 金丝雀模型： 在这个模型中，不是将全部流量导到新的服务器集上，而是只将流量的一个子集导到新的服务器上。流量切换是根据团队制定的时间节奏逐渐发生的。一旦流量完全切换到新的服务器集，旧的服务器就会被删除。
镜像生命周期管理和补丁
在不可改变的基础设施模型中，虚拟机或容器镜像的创建和修补起到了关键作用。你需要利用CI/CD工具，制定良好的镜像生命周期管理。
在云和容器环境中，首先我们需要一个基础镜像。之后基于这个基础镜像创建应用镜像。在实际的项目环境中，这个过程会比较复杂。
下面我们来聊一下这一切在实际项目环境中是如何发生的，以及如何根据公司的安全策略建立应用程序镜像。
因此，这里列出了在安全的项目环境中遵循的通用镜像生命周期管理（虚拟机和容器）步骤。
注意：该列表是为了给你一个关于镜像生命周期管理的总体情况。它在每个组织中都是不同的。
- 在一个安全、合规的环境中，你不允许使用云提供商提供的基础镜像或docker hub等公共容器注册处提供的docker基础镜像。
- 每个组织都会用标准的安全工具（各种agent）、DNS/Proxy、LDAP配置等创建虚拟机/容器基础镜像（它根据每个组织的安全政策而改变）。通常，这种镜像是由中央平台团队或安全团队创建和维护的。你可以叫它黄金镜像。
- 经过批准和认证的基本镜像将与组织中的所有团队共享。它可以是一个单一的云账户或与组织内的多个子账户共享。
- 然后，每个团队可以在批准的基础镜像上创建自己的应用镜像。（这里使用像Docker和Packer这样的工具）。
- 团队创建的新镜像将被测试并部署到生产中。
- 现在，当基础镜像得到新的更新或补丁时，平台或企业安全团队会发布新版本的基础镜像并通知所有项目团队。
- 每个组织都有一个打补丁的生命周期。意思是说，安全团队对VMS的更新和补丁的应用有一定的准则。例如，它可能是一个月或三个月一次。
- 对于虚拟机，补丁可以是 “就地” 的，也就是对现有实例进行补丁，也可以是不可更改的，也就是用新的镜像替换现有的镜像。容器在本质上是不可变的。
- 基于补丁的生命周期，每个团队都会用新的基础镜像更新现有的应用镜像，并将其部署到生产中，而不管应用的代码是否有变化。这同时适用于虚拟机和容器。
结论
我们已经看了不可变的基础设施的关键概念。
作为一名DevOps工程师，你应该在构建和部署不可变镜像时遵循所有标准的最佳实践，以减少攻击面。
如果你正在使用容器或容器编排工具（如Kubernetes），你已经在遵循应用程序部署的不可变模式。
扩展阅读
