使用 Packer、Ansible 和 Terraform 构建不可变的基础设施Devops工具链

在容器编排领域，Kubernetes 已成为事实上的标准，而容器镜像 (Docker Image) 作为容器技术栈中最关键的创新之一，极大的推动了企业内部 Devops 运动的进程。

容器镜像所具有的轻量性、便携性、分层机制和内核共享机制真正意义上实现了 “Build once, run anywhere”。这种不可变的基础设施 (Immutable Infrastruture) 高度保持了开发、测试和生产环境的一致性。因为镜像的易移植、易复制的特性，也给运维带来了很大的弹性和灵活性。

对于还无法容器化，只能部署在虚拟机里的传统应用，是否也能构建像容器镜像这样不可变的的基础设施？

可变的服务器部署 vs. 不可变的服务器部署

可变的服务器部署

在可变的服务器部署模式中，首先我们通过 Terraform 创建出所需的虚拟机以及其它基础设施资源，然后通过配置管理工具 Ansible 对已经存在的服务器资源进行应用相关的配置和部署。

上述的部署过程看似非常快速、简便，但是随着业务的需求增加，需要对服务器操作系统进行更新，或对部署的应用进行频繁的升级。这种情况下，可变的服务器部署模式所带来的挑战和风险是我们无法预估的。

在真实的用户场景里，运行的应用程序与操作系统、或第三方软件资源存在各种各样复杂的依赖。当给操作系统打补丁，亦或升级应用程序所依赖的软件包时，可能会出现应用程序无法正常启动、DNS 解析异常、网络不可达、性能下降等现象，这些异常可能是无法预测的，甚至是我们无法控制的。

即使应用程序更新成功，一旦线上环境产生不可预知的严重 Bug ，需要将应用程序回滚时，由于可变的服务器部署的不确定性，回滚的过程对于运维人员仍然是一项挑战。

当线上环境负载过高时，在可变的服务器部署模式下，响应也会显得不够高效。按照上述流程，需要创建新的虚拟机资源，再运行配置管理工具去部署该版本的应用。整个过程比较耗时，也较容易出错。

不可变的服务器部署

相对于可变的服务器部署模式，不可变的服务器部署模式要求服务器在部署完成之后，后续每次做部署变更时，不再对现存的服务器做任何更新或升级。

不可变的服务器部署模式下，我们将会基于基础的虚拟机镜像，创建新的虚拟机，为该虚拟机安装所需软件包，部署应用程序所需要的新的代码和配置。最后将该虚拟机打包成一个新的虚拟机应用镜像。

每次部署应用时，基于以上过程创建出来的应用镜像，创建新的服务器，在这个过程中，我们不会去改动当前环境中运行的基础设施资源。

同时在整个过程中，出现任何错误，我们将直接退出。待问题解决之后，基于以上过程重新打包镜像。如果一切顺利，待虚拟机启动成功，再将线上环境流量切换到该新虚拟机上，随后销毁掉的虚拟机。这样就完成了一次部署变更。

如果线上流量较高，需要横向扩展虚拟机数量时，只需将上述已经打包好的应用镜像部署成新的虚拟机，作为额外资源加入到线上集群即可。整个响应过程十分迅速且可靠。

基础设施即代码 (IAC)

基于 Packer、Ansible 和 Terraform 等开源工具，构建不可变服务器部署模式的持续集成和持续部署的 Jenkins Pipeline：