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

 作者 ｜ 林俊（万念） 来源 ｜[尔达 Erda 公众号](https://mp.weixin.qq.com/s/kAvxNJi3fKWu6Cd0ePTTaA) ## 从一个小故事开始 你是一个高级开发工程师。 某天，你自信地写好了`自动煮咖啡`功能的代码，并在本地调试通过。代码合并入主干分支后，你准备把服务发布到测试环境，进入提测流程。 你熟练地打开项目协同，新建了一个发布工单给运维同学，详细备注了需要发布的代码分支，并特别强调这次需要专门新增一个环境变量开关 `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_](https://github.com/erda-project/erda) - **Erda Cloud 官网：**[_https://www.erda.cloud/_](https://www.erda.cloud/)

标签：原生,erda,代码,IaC,开发者,应用,Erda
来源： https://blog.51cto.com/u_15269973/2962228