云原生时代，为什么基础设施即代码（IaC）是开发者体验的核心？

Posted 2021-07-02 尔达 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，作为开发者的你，终于可以更好地掌握应用的全生命周期了。