为 Serverless Devs 插上 Terraform 的翅膀，解耦代码和基础设施，实现企业级多环境部署（下）

简介：在上篇《为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）》中，主要介绍了 Serverless Devs 多环境功能的使用，用户读完可能会些疑问，本文会就一些常见问题进行回答。

在上篇《为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）》中，主要介绍了 Serverless Devs 多环境功能的使用，用户读完可能会些疑问，本文会就一些常见问题进行回答。

Serverless Devs 和 Terraform 的关系

可能有些用户会问，既然你们已经支持了 Terraform，那 Serverless Devs 还有什么作用，是不是直接用 Terraform 就可以了？

Serverless Devs 和 Terraform 的定位还是明显不同的。Serverless Devs 面向应用管理及 DevOps，Terraform 面向云资源，是两个不同的领域，但并不表示不能在某些层面有交集或者不能集成，集成和被集成能力本来就是开源工具是否标准化的一个衡量标准。

Terraform 解决的是云资源的 Provisioning，这个领域是有非常清晰的方法论的。而 Serverless Devs 更应该强调如何使用好云资源，两者的关系可以用几个场景说明：

Serverless Devs 更多关注如何把代码或者安装依赖分片上传到 NAS 上，更少关注 VPC/交换机/安全组/NAS 挂载点如何创建出来；
Serverless Devs 更多关注如何把文件上传到 OSS，并且自动触发函数完成报表的生成，更少关注 OSS Bucket 如何创建；
Serverless Devs 更多关注如何构建代码/镜像、制作 Layer、部署代码、发布版本、灰度放量来构造完整的 CI/CD 体验，更少关注 FC 的网络、日志仓库、ACR 实例如何创建出来；
Serverless Devs 更多关注如何远程调试代码，如何登陆到线上实例，如何通过日志以及监控快速发现业务的异常；

可以看到 Serverless Devs 更加重点关注的是应用运行态以及运维态的操作，这也是 Serverless 架构的工具最重要的使命，但 Serverless Devs 负责的是 Serverless 应用全生命周期管理，必然少不了资源的管理，我们在实践过程中发现，无论是用云产品 SDK 还是 Pulumi 这类 GPLs 都需要投入很大精力在资源生命周期的对接上，这对于组件开发者对接更多云产品来说是非常低效的。而 Terraform 在这方面是最专业的，无论是标准化程度、受认可程度以及资源的丰富度都能很好满足终端用户及开发者的需求，因此才触发 Serverless Devs 和 Terraform 结合这一想法。

Serverless Devs 没有和 Terraform 耦合，相反的是让 Terraform 的 HCL 语言自然的在 Serverless Devs 的组件规范里玩转起来，可以认为是 Serverless Devs 支持多语言的一种能力。对开发者的价值是可以比较低代码的完成基础设施的搭建，把精力投入到和 Serverless 应用生命周期管理相关的开发上，不然就得开发大量的资源 CRUD 代码，这个是非常低效的。

多环境功能和直接用 Terraform 有什么不同

既然多环境部署也走的是 Terraform，那和我直接用 Terraform 部署资源有什么区别？

Terraform 是个人版的工具，需要本地管理ak/sk、本地安装 Provider；而多环境是个多租的服务，不需要用户自己来维护这些；

多环境功能重要的是"管理"的能力，比如模板有版本管理能力，当模板发布了新版本并且 IaC 的变更是不兼容的，此时用户如果更新环境会导致未知问题，这种情况下系统会自动识别并且保证存量环境的变更还使用旧版本，不受不兼容变更带来的影响；

Terraform 是纯面向资源的编排工具，和应用的关联很弱；而环境和服务、流水线可以天然地形成连接关系，比如通过环境可以感知到资源被哪些服务所使用、服务可以通过环境的授权来获取访问资源的权限、可以在流水线中将服务一次性部署到所有环境上，而这些是 Terraform 做不了的；

Terraform 只是多环境实现 IaC 的一个技术选型，未来还计划对接 ROS、Pulumi 等 IaC 项目。

多环境和环境变量的关系

在 CI/CD 中使用环境变量，环境变量中配置 VPC、NAS 啥的，s.yaml 中引用环境变量似乎就可以了，为什么还要造一个环境概念？

环境和环境变量从名字就能区分出定位的差异，环境变量就是一组静态配置，虽然可以将一些资源配置写到环境变量内并在 CI/CD 流水线中引用，但这种方式不具备资源纳管的能力。

而环境是个实体资源，具备基础设施的生命周期管理能力，通过环境可以完成基础设施的增删改查，并可以通过访问控制的方式授予用户的操作权限，更新环境时还可以对接一些安全检查的能力。

通过环境可以让基础设施受到保护，比如当多个服务共享环境时，如果发起环境删除，系统会自动发现环境被其他服务所依赖，此时删除会被拒绝。

只能企业用户使用吗？个人开发者怎么用？

我是个人开发者，不懂 Terraform，文章中各种模板定义看的有点晕，那我还适合用这个功能么？

个人开发者一样适用，但不应该让这部分用户承担写模板的工作，而是由平台提供各种业务场景化的模板，开发者开箱即用，这也是我们后续的主要工作。

对个人用户来说，上阿里云最复杂的某过于 RAM、VPC、ECS、SLB、NAS 这些复杂的概念，学习曲线太长。在 Serverless 架构下这个问题尤为明显，Serverless 宣称低门槛、低成本、低运维，但是上手 Serverless 需要了解一大堆概念，配置一大堆东西，很多用户在这过程中就被"劝退"了，而环境模板和环境可以极大地简化云产品的上手成本，同时又能很安全地操作。举个例子，用户选择一个模板部署环境，就可以一键拉起所有云资源，这样才算是真正的 Serverless。

实现原理

遵循 Serverless Devs 组件开发规范，通过实现一个组件来完成和后端服务的对接

后端服务采用 Serverless + K8s 的架构，通过消息触发函数，来完成模板的渲染以及部署任务的执行

采用 KubeVela[1] 来完成 K8s 资源的管理以及 Terraform 任务的执行

多环境为什么是组件级的能力而不是 CLI 的能力

Serverless Devs 分为 CLI[2] 和组件[3]：

CLI 提供最通用的能力，不依赖任何组件，比如：s init、s config、s verify、--template、--debug

组件提供特定的功能，比如 s deploy、s build、s invoke 这些是 fc 组件的能力

从 env 命令的通用性以及要解决的问题上看，做到 CLI 内也是合适的。但从实现上看，因为需要一个服务端的控制平面来完成用户资源的部署，出于安全性考虑必须要特定的云服务来完成，所以才通过一个组件来完成。

参考链接：

[1] KubeVela ：

https://kubevela.io/

[2] CLI：

https://docs.serverless-devs.com/serverless-devs/command/readme

[3] 阿里云函数计算组件：

https://docs.serverless-devs.com/fc/readme

往期回顾为 Serverless Devs 插上 Terraform 的翅膀，实现企业级多环境部署（上）

极速上手 Serverless

为了让开发者快速定位 Serverless 开发问题，找到对应解决办法，阿里云云原生 Serverless 团队推出 2022《Serverless 开发速查手册》，目前已开放下载，我们希望给 Serverless 开发者提供一本能够速查、速懂的工具书，实实在在帮助开发者快速解决 Serverless 开发遇到的实际问题，让大家能够踏踏实实享受 Serverless 带来的技术红利！点击阅读原文，即刻下载手册！

原文链接：http://click.aliyun.com/m/1000348898/

本文为阿里云原创内容，未经允许不得转载。