前言

随着现代化应用的普及和企业上云的深入，项目中会涉及越来越多的云资源使用。企业上云过程中，往往会有平台（Platform）团队和基础设施（Infra）团队：平台团队关注业务，根据业务场景进行抽象，对研发人员屏蔽基础设施；基础设施团队关注安全及成本，为平台团队规划了不同的子账号、权限策略以及网络配置。这种分层管理的必然结果导致应用和基础设施的生命周期会完全不同，因此基础设施管理员、平台管理员、研发人员关注的云资源视角也不尽相同。比如：

基础设施管理员管理整家企业的云账号，规划企业的网络配置，并为各个平台团队设置不同子账号以及访问策略；
平台管理员持有子账号，根据容灾及高可用场景划分地域、安全、流量策略；根据业务场景规划日志、存储、数据库的规格、备份配置、Quota 等；根据研发流程要求规划 CI/CD 流水线；
研发人员在使用平台过程中，仅需关注代码、数据、配置等程序相关内容：
当需要访问数据库时，向平台索要数据连接串；
当需进行日志采集时，将采集路径提交给平台，由平台操作日志服务完成日志采集配置挂载；
当需要使用持久化存储时，将本地挂载路径提交给平台，由平台操作存储服务完成文件目录挂载；
发布代码，自动触发 CI/CD 流水线的执行；

因此，随着职责边界的不同，平台团队面临着更大的挑战，既要面向研发人员消化业务，又要面向基础设施团队解释云产品的使用，无疑增加了很多沟通成本，降低了业务的迭代效率。

如果能建立一种自动化的管道，让不同团队自助化地完成各自的边界，势必会极大地提升生产力。这需要几个很重要的概念来连接 Dev 和 Ops：

服务：对代码、程序的描述，只描述跟程序相关的信息，比如函数配置、日志采集路径
对于函数型应用，服务一般描述一个函数
对于容器化应用，服务一般描述一个 Workload
环境：服务运行在不同的环境上，环境是服务运行的载体，描述了基础设施（如网络、集群、存储）的配置，以及应用运行时的运维配置（如弹性伸缩、资源规格）
流水线：对 CI/CD 的描述，完成代码到服务的构建，并将服务部署到所有的环境上
应用：一组服务、环境、流水线所有资源的集合

要实现高效的自助化操作，合理化的方案是将上述概念进行模板化，并使用如下的工作流来完成：

平台管理员将网络、日志服务、存储、数据库等基础设施资源根据测试/生产隔离的要求，封装成环境模板；将阿里云函数计算（FC）的函数、Serverless 应用引擎（SAE ）应用这些研发关注的业务资源封装成服务模板；将 CI/CD 的基础流程封装成流水线模板；
基础设施管理员审核模板，通过后为平台管理员分配对应的子账号；
平台管理员持有子账号选择环境模板创建不同的测试、预发、生产环境，然后授予研发子账号访问权限，或者授予研发写权限来自助创建环境；
研发人员选择服务模板以及关联的环境来创建服务，实现将应用程序自动部署到指定的环境上；
研发人员选择流水线模板，通过主动触发或者代码提交自动触发 CI/CD 的执行。

通过这种分边界的模板化处理方式，可以让企业不同的团队自助完成基础设施的搭建，提高生产效率的同时，又保证了权限隔离，让基础设施受到保护。

Serverless Devs 支持多环境所面临的挑战

Serverless Devs [1]是一款面向 Serverless 应用全生命周期的管理工具，其模型规范中存在应用和服务的概念，但目前缺少对环境的内在支持，代码+基础设施共同维护在一个 s.yaml 下。这种模式在多环境时的限制主要有3点：

要为不同的环境维护不同的 s.yaml，维护成本比较高。更新环境时需要重新发起部署，对接 CI/CD 服务时就要重新发起一次完整的发布上线操作。（但通常情况下环境的变化，例如升降配、更新权限，对程序来说是安全的，不需要发起一次上线）；
难以实现基础设施团队、平台团队、研发团队分层协作的场景。比如阿里云函数计算的服务描述提供了日志、网络、NAS、服务角色等平台管理员视角的配置。收到客户反馈，这些配置是干嘛的研发基本都不清楚，无疑减低了研发效率并增加了安全风险，经常出现研发改错配置导致线上服务有损的情况；
Serverless Devs 的资源操作主要由组件来实现，但对于一些资源的变更可能会引起实例重建或者不能提供服务（比如更改数据库引擎、更换了FC的服务角色、更换VPC）的风险，组件开发者未必会清楚也可能会忽略，即使清楚也需要 Case By Case 的通过很多判断代码来解决，这无疑增加了组件开发的复杂度和使用成本；

如果采用本文前言章节中描述的分层的模板化方案，以上问题就可以顺利解决：

平台团队通过封装环境模板，仅需对研发人员暴露安全的参数（比如实例规格），研发人员使用模板创建环境，填写必要的参数即可完成基础设施的搭建；通过更新环境即可自助化地完成基础设施的升级，并且不需要重新发起代码发布操作；
平台团队在环境模板中声明更加严格的访问策略，拒绝某些有风险的资源操作，可以更好地控制爆炸半径；

那么，接下来的问题就是：如何在 Serverless Devs 中定义环境模板？

当 Serverless Devs 遇见 Terraform

环境模板面向的是基础设施，也就是云资源。Serverless Devs 离不开对云资源的操作，传统的做法是在组件中直接使用云产品 SDK，但支持新资源时需要开发相应的组件代码，因此面临着资源扩张带来的开发效率降低以及代码越来越难以维护的问题，更好的方式是通过基础设施即代码（IaC）来完成云资源的创建。

Serverless Devs 在之前的实践中采用 Pulumi ，通过一个单独组件完成对 Pulumi Stack 的封装，但实践下来发现，用 GPLs 来定义 IaC 还是需要模型层面良好的抽象，因此将 Pulumi 推广到组件开发者，在生态成熟度以及灵活性上都不是太好。

目前 IaC 生态最强大的工具是 Terraform，已成为事实标准。Terraform HCL 本身是一种 DSL，任何生态都能很好地兼容，特别是 Provider 极其丰富。阿里云的云产品如果对接 POP，能够自动生成 Terraform 的 Provider，其可靠性和接入便捷程度已经相当之高。

如果将环境模板的定义通过 Terraform IaC 来完成，并且在 Serverless Devs 的体系内能够良好地衔接，这样可以极大拓宽用户领域，用户可以通过编写 Terraform 文件来定义自己的基础设施，用 Serverless Devs 完成所有工作流的串联。

操作案例

遵循 Serverless Devs 的组件开发规范，将多环境的操作封装成 env 命令，通过利用 s env 命令，可以实现如下的工作流：

通过基础设施即代码（IaC）的能力定义可复用的环境模板
基于模板构建不同的测试、预发、生产等互相隔离的环境，并自动完成基础设施的搭建
将函数的同一份代码部署到不同的环境上

下面我们通过一个实际案例演示整个操作流程。

假设业务场景需要：

在函数中读写OSS文件
日志文件写入NAS，前端做实时展现
函数日志写入SLS，做系统分析

作为平台管理员，需要为研发：

创建 OSS Bucket，Bucket 名字研发可以自己指定，但是ACL策略必须是私有
创建 NAS 挂载点，涉及的VPC、VSwitch、NAS文件系统、访问组、挂载点完全由管理员指定
创建SLS Project 、Logstore，名字研发可以自己指定，但是自动分裂、最大分裂数完全由管理员指定

01 平台管理员：开发环境模板

环境模板采用 IaC 来定义资源，目前只支持 Terraform 类型的模板。环境模板的代码目录要包含两类文件：

IaC文件：即 Terraform 的 .tf 文件，IaC 文件的核心要素为：
variable：定义模板的参数，用户使用该模板创建环境时输入参数的值
resource：定义模板的资源，环境部署时完成资源的创建
output：定义模板的输出，环境部署成功后透出相应输出，可以被其他服务所访问

policy.json：RAM 的权限策略数组，支持自定义策略和系统策略，声明了使用该模板创建资源所需要的权限，授信对象是函数计算。部署环境时，函数计算会通过角色扮演的方式访问模板中定义的资源。

编写 IaC，定义环境模板的 variable、resource、output。

完整代码示例：
https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/main.tf

为上述资源定义权限策略，保持权限最小原则，仅放开必要的写权限。由于 Terraform 在创建资源时会依赖很多资源的读权限，因此推荐再增加 AliyunECSReadOnlyAccess、AliyunVPCReadOnlyAccess、AliyunNASReadOnlyAccess 这些常用的读权限。

完整代码示例：
https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/policy.json

02 平台管理员：发布环境模板

通过 s env apply-template 发布环境模板

s env apply-template --name testing --description 'it is a demo' --code ./infra

参数含义如下：

参数全称	是否必填	参数含义
name	True	环境模板名字
description	False	环境模板描述
code	False	模板代码目录

操作成功后，会返回当前模板的 varibale、outputs、状态、 policy、文本内容、版本等信息。

03 研发：使用环境模板创建环境

环境需要操作对应云资源的权限，授予函数计算以角色扮演的方式访问的云资源，因此需要：

创建普通的服务角色，授信服务选择函数计算
为该角色授予环境所需要的权限

通过 s env init 命令进入交互式操作，输入环境名、地域、角色、环境模板以及模板参数，完成环境的部署：

执行成功后，会在本地 .s 目录下创建 env/fc-env-testing.yaml 描述文件，可以查看并编辑该文件。

04 研发：部署函数到指定环境

开发人员编写s.yaml，并将基础设施配置关联到指定环境。可以通过如下方式：

通过environment.outputs来关联环境模板中定义的输出
FC 的服务往往和一个环境相映射，通常在创建服务时服务名要带上环境的后缀，可以通过environment.name让服务和环境自动关联
指定环境时，无需在 props 中指定 region，组件会自动保证将服务部署到环境所在的 region

通过s deploy --env将函数部署到指定的环境中。

s deploy --env fc-env-testing

执行指令后，组件会先判断环境是否已经部署，如果环境状态为 ready ，则会将服务部署到该环境上；否则会先部署环境，再部署服务。

总结

本文通过分析企业全面上云时，遇到的应用和基础设施管理的挑战，提出采用分层的模板化方式来组织不同团队的工作流，通过环境、服务、流水线来定义一个现代化的应用，通过环境模板、服务模板、流水线模板来屏蔽基础设施的复杂性并提升操作安全性，核心是需要一个管道来串联整个工作流，让 DevOps 的各个阶段可以自助化并安全的完成。作者希望 Serverless Devs 可以充当这个管道，其应用、组件、插件的思路为开发者提供了良好的构建现代化应用的基础，并且 Serverless Devs 已经具备了服务及服务模板的抽象，需要扩展的是环境、流水线的能力。

本文关注点是如何利用 Serverless Devs 管理多环境，分析了关键的挑战是要解耦代码和基础设施，利用 IaC 来完成基础设施的定义，而 IaC 生态下最适合引入的是 Terraform，因此选择用 Terraform HCL 来定义环境模板，环境的资源编排通过后端的 Terraform 服务来完成。这样就可以通过 Serverless Devs 来完成 "发布环境模板" -> "部署环境" -> "部署应用到指定环境" 的完整工作流。

当然，要实现上述终态的愿景还有很长的路要走，未来规划主要的 Roadmap 是：