作者 | 林俊（万念）
起源 |尔达 Erda 公众号

从一个小故事开始

你是一个高级开发工程师。

某天，你自信地写好了 主动煮咖啡 性能的代码，并在本地调试通过。代码合并入主干分支后，你筹备把服务公布到测试环境，进入提测流程。

你熟练地关上我的项目协同，新建了一个公布工单给运维同学，具体备注了须要公布的代码分支，并特别强调这次须要专门新增一个环境变量开关 AUTO_MAKE_COFFIE_ENABLED=true。

过了一段时间，工单解决实现，测试同学开始测试。

忽然，噩耗传来：你的我的项目协同里呈现了几个 Bug。

你很纳闷，为什么本地完满运行的代码，在测试环境被提了这么多 Bug？

你开始狐疑代码中某个中央的逻辑有问题。可认真排查后却依然定位不到问题。

最初，你终于发现，是运维同学复制环境变量时少复制了一个字母：
AUTO_MAKE_COFFIE_ENABLE=true，ENABLED 少了一个 D。

下面这种状况是不是很相熟？尽管不是你的锅，却拖慢了你成为十倍程序员的进度。

那么，该怎么防止呢？

你肯定在想：要是没有手工复制操作就好了。那就要有个中央来保留你的配置，然而你没有权限、也不想登录到运维操作平台本人粘贴配置。

你灵光一现：要是和运维同学约定好一个配置文件，把部署配置也提交进代码里，运维同学从文件里读取应用环境配置，问题就迎刃而解了。
​

IaC 是什么

在下面的故事里，这个非凡约定好的配置文件就是这个利用基础设施的一部分（IaC 中的 I）。

咱们该怎么了解基础设施呢？一个略微简单点的利用，只有代码是无奈运行起来的，因为它还有很多环境依赖须要被精确形容，比方须要运行环境有 make、git 等指定的命令行工具，依赖了哪些中间件等。

因而，产品团队在施行继续交付的过程中，必须思考将基础设施的保护纳入进来，作为反对产品运行的一部分。
同时，技术的疾速提高和演变，也使得基础设施的配置不得不频繁变动。在这种疾速变动的过程中，要求基础设施既要灵便，也要平安、牢靠。

参考 Wikipedia 上的定义，IaC 里的 Infrastructure 狭义上是指 IaaS 层的基础设施，包含物理服务器、虚拟机以及相干的资源定义等。As Code 是指这些配置都应该被放到 VCS 上治理起来。

As Code 的益处是，你能够享受版本治理人造的福利，很不便地做一些回滚操作等。
​

当你把 Code 保护在 Git 里，就成了 GitOps。感兴趣的同学能够搜寻 GitOps 相干文章进行学习。

​

那么，As Code 里的 Code 应该长什么样？这个格局由具体的自动化平台来定。至于 Code 的类型，指令式和申明式都能够。例如，常见的 Ansible 一般来说是指令式的，而 Terraform 是申明式的。当然，申明式定义更为举荐，因为这是一种面向终态的定义，对开发者屏蔽了具体实现细节，更加敌对。

云原生时代，以利用为核心的 IaC 有什么不同？

工夫快进到云原生时代。

在服务上云的大趋势下，基础设施的概念曾经不再局限于 IaaS 层。云原生时代，开发者的焦点逐步汇集到了利用上。即：以利用为核心。

继续集成、继续部署和 DevOps 这些概念的宽泛推广和承受，要求产品团队对部署和运维要有更高的自主性。

首先，在 DevOps 概念深入人心的明天，一个开发工程师如果仅仅是把代码写好，是远远不够的，那只是做好了 Dev。真正的软件交付的生命周期，是从 Ops 开始的，运维同学早已不再负责利用的部署和运维，这都是开发者的事件。

Docker 的呈现使得镜像交付成为大多数应用软件事实上的交付规范。所以，利用里须要有一个文件来定义怎么样把你的代码制作成镜像，这个文件通常是 Dockerfile。

与此同时，PaaS 平台的遍及，使得开发者甚至不须要关怀 Dockerfile。因为 PaaS 平台能够通过你的利用目录构造和特色文件，主动探测和抉择适合的构建形式，这个代码编译和镜像构建的过程被称为 BuildPack。当然，在编译之前，你可能还须要做一些代码质量检查、合规性查看等，这些流程化的配置，须要有一个流程形容文件来申明。在不同的 PaaS 平台上，会有不同的申明形式。

Erda DOP 里怎么样把 IaC 做得更好

Erda 是一个以利用为核心的企业级一站式数字化 PaaS 平台。

DOP，即 DevOps Platform，是一个以利用为核心的一站式的 DevOps 平台。

一个 Erda 利用反对代码品质扫描、代码平安扫描、单元测试执行等，镜像制作好之后，还有镜像平安扫描、继续部署、接口自动化测试等。通过这些流程对利用的全生命周期进行治理。

在这个平台上，你能够应用 pipeline.yaml 来定义利用的 CI/CD 全流程。很显然，这个 pipeline.yaml 就是这个利用基础设施的一部分。

同时，你须要用一个申明式的 erda.yaml 来形容你的利用微服务架构，包含微服务之间的依赖关系、对中间件的依赖等等。

在平台设计之初，咱们就对利用做了形象，使得它能够被部署到任意平台，包含 K8s、DC/OS 等，对开发者屏蔽了具体实现细节。

因而，当利用部署在 Erda PaaS 平台上时，这两个文件是必不可少的。

值得一提的是，在平台最晚期的时候，咱们只有一个 erda.yaml 文件，外面把微服务架构和构建过程写在一起。在实际过程中，咱们逐步意识到这样的形式扩展性不够，很难进行流程定制。并且命令式和申明式的两种状态耦合在同一个文件中，使用者的心智切换老本也更高。

除此之外，咱们还反对在 .erda 目录下定义 API 形容文件来对 API 全生命周期进行治理。

当这些 Infrastructure 都被作为 Code 提交之后，Erda 平台就能够依据这些配置，进行继续集成和继续交付，最终主动把利用残缺地部署起来。
​

以 Erda 本身举例，Erda 自身的继续集成、主动版本公布等，都是在 Erda 平台上自举的。
erda.yaml 局部截图如下：

用于 CI 的 pipeline.yaml 局部截图如下：

当你的利用是一个标品时，有了 IaC，给客户交付这个利用就变得非常简单。你要做的，只是把代码仓库残缺地推送到新的利用代码仓库里，而后执行流水线。执行结束后，一个残缺的利用就被交付到了新的客户环境里。之后，开发者在这个新利用进行定制化开发，在利用的基础设施变更时，把变更提交到代码里进行版本控制治理。

总结

You build it, you run it.

​

所以咱们说，基础设施即代码（IaC）是云原生时代开发者体验的外围。

有了 IaC，作为开发者的你，终于能够更好地把握利用的全生命周期了。
​

欢送参加开源

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云治理以及快数据治理等平台级能力。点击下方链接即可参加开源 ，和泛滥开发者一起探讨、交换，共建开源社区。 欢送大家关注、奉献代码和 Star！
​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/