关于阿里云:为-Serverless-Devs-插上-Terraform-的翅膀解耦代码和基础设施实现企业级多环境部署下

3次阅读

共计 3082 个字符，预计需要花费 8 分钟才能阅读完成。

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

可能有些用户会问，既然你们曾经反对了 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 是个人版的工具，须要本地治理 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 工作的执行

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….

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

https://docs.serverless-devs….

往期回顾

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

为了让开发者疾速定位 Serverless 开发问题，找到对应解决办法，阿里云云原生 Serverless 团队推出 2022 《Serverless 开发速查手册》，目前已凋谢下载，咱们心愿给 Serverless 开发者提供一本可能速查、速懂的工具书，实实在在帮忙开发者疾速解决 Serverless 开发遇到的理论问题，让大家可能踏踏实实享受 Serverless 带来的技术红利！ 点击浏览原文，即刻下载手册！

正文完