没有使用IaC的DevOps系统都是耍流氓 _生活百科

【没有使用IaC的DevOps系统都是耍流氓】作为现代软件工程的基础实践，基础设施即代码（Infrastructure as Code, IaC）是云原生、容器、微服务以及DevOps背后的底层逻辑。应该说，以上所有这些技术或者实践都是以基础设施即代码为基本模式的一种或者多种方法的集合。基础设施即代码并不是一种特定的技术，而是一种解决问题的思路。本文将从基础设施即代码的含义，原则和落地方法三个层面来帮助你理解为什么没有使用IaC的DevOps系统都是耍流氓。
什么是IaC基础设施即代码的目标是解决一个古老的问题：如何能够安全、稳定、快捷、高效得完成软件交付过程。注意这里的交付并不仅仅指将可部署的软件部署到最终的运行环境，而是更宽泛的概念上的交付，也就是将软件从一个看不见摸不到的想法或者创意，转变成用户可以操作并使用的一个系统。这个过程涉及软件创意的捕捉、设计、计划、开发、测试、部署和发布的全过程，也包括软件发布之后收集用户反馈重复启动以上过程的迭代。这个迭代在软件的整个生命周期里面会一直重复下去，直到这个软件不再有人使用，寿终正寝。

文章插图
软件生命周期中的这个持续的迭代过程构成DevOps反馈环路的概念，在这个反馈环路的左右两端分别是Dev和Ops ，而代码和基础设施正是Dev和Ops最重要的工件（Artifact）， Dev维护代码， Ops维护基础设施。传统意义上，代码和基础设施是有明确的界限的，一般来说：代码特指应用代码，而基础设施则是除了应用以外（或者以下）的所有“基础”组件。
在云计算技术出现以前，硬件被普遍认为是一旦创建就无法改变的，就好像你购买一台电脑，如果希望更换其中的CPU，内部，磁盘以及网卡，那么都必须重新购买相应的组件并重新组装。云计算将计算资源（电脑）解偶成了可以随意组合的计算、存储和网络三种资源类型，允许用户根据需要自助的进行组合。其底层实现机制是将硬件软件化，比如：对象存储技术和软件定义网络（SDN）就是云计算的基础技术。硬件被软件化之后的结果就是我们可以通过配置来变更硬件的能力。这其实就是基础设施即代码的最基础的含义。

文章插图
但是对于用户而言，其实并不关心所使用的软件到底运行在什么硬件，什么云上面。比如：对于用户的社交需求来说，微信就是社交需求的基础设施；对于需要编写文档的用户来说，WORD就是他的基础设施。相对于硬件，这其实是基础设施的另外一个极端含义，也就是：任何支撑用户完成某种操作的支撑能力，都可以成为用户这一类别操作的基础设施。
从这个极端含义的角度来说，以上环境堆栈中的任何一层都可能成为上层的基础设施。为了能够为上层提供类似云计算的自助化能力，都需要提供可配置性。为了满足这种可配置性的需要，IT行业里面就出现了容器化技术、Kubernetes、Terraform、Azure Resource Manager等等基础设施即代码的实现方式。其实这些技术解决的都是一个问题，也就是系统的可配置性问题。
IaC的实现原则实现可配置性能力的方法很多，传统运维的做法其实很简单，就是通过脚本来自动化这个配置过程，让原本繁琐的配置过程自动化起来。

文章插图
自动化脚本的方式虽然能够在一定程度上解决可配置问题，但是当系统变更频繁程度到达一定量级的时候，维护自动化脚本的工作量将会抵消自动化脚本所带来的效率提升，这个时候运维团队会发现采用人工处理的方式甚至比编写和维护自动化脚本更加高效。因此，在当今软件迭代速度越来越快的背景下，自动化脚本逐渐无法满足团队应对快速变化的市场的需要。我们需要一种能够能够允许团队轻松适应快速变化的环境维护方式，基础设施即代码（Infrastructure as Code, IaC）就是在这样的背景下诞生的。实际上，说诞生并不准确，IaC其实是工程师们在遇到问题之后持续改进的结果。
当维护自动化脚本的方式无法适应快速变化的市场需要的时候，如何让开发和运维团队解偶就变成了解决这个问题的核心。在上图左侧的工作模式中，问题的核心是开发和运维团队之间基于“请求-响应”的工作模式，这种工作模式让开发和运维团队相互依赖，无法独立的按照自己的节奏工作。为了解决这个问题，IaC借用了大规模软件架构设计中的分层原则，让那些需要被共享的能力变成通用组件，并在开发和运维之间共享这些组件，从而让本来互相依赖的两个团队变成依赖另外一个第三方组件。如下图：