作者 | 封崇

• 基础设施管理员管理整家企业的云账号，规划企业的网络配置，并为各个平台团队设置不同子账号以及访问策略；
  
  
• 平台管理员持有子账号，根据容灾及高可用场景划分地域、安全、流量策略；根据业务场景规划日志、存储、数据库的规格、备份配置、Quota 等；根据研发流程要求规划 CI/CD 流水线；
  
  
• 研发人员在使用平台过程中，仅需关注代码、数据、配置等程序相关内容：

  
  

• 当需要访问数据库时，向平台索要数据连接串；
  

• 当需进行日志采集时，将采集路径提交给平台，由平台操作日志服务完成日志采集配置挂载；
• 当需要使用持久化存储时，将本地挂载路径提交给平台，由平台操作存储服务完成文件目录挂载；
• 发布代码，自动触发 CI/CD 流水线的执行；
  
  

• 服务：对代码、程序的描述，只描述跟程序相关的信息，比如函数配置、日志采集路径

  
  

• 对于容器化应用， 服务一般描述一个 Workload

• 对于函数型应用，服务一般描述一个函数

  
  

• 环境：服务运行在不同的环境上，环境是服务运行的载体，描述了基础设施（如网络、集群、存储）的配置，以及应用运行时的运维配置（如弹性伸缩、资源规格）
  
  
• 流水线：对 CI/CD 的描述，完成代码到服务的构建，并将服务部署到所有的环境上

  
  

• 应用：一组服务、环境、流水线所有资源的集合
  
  

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

  
  

• 研发人员选择流水线模板，通过主动触发或者代码提交自动触发 CI/CD 的执行。
  
  

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

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

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

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

  
  

• 创建 SLS Project 、Logstore，名字研发可以自己指定，但是自动分裂、最大分裂数完全由管理员指定
  
  

• IaC 文件：即 Terraform 的 .tf 文件，IaC 文件的核心要素为：

      

  
  

• resource：定义模板的资源，环境部署时完成资源的创建
• output：定义模板的输出，环境部署成功后透出相应输出，可以被其他服务所访问
•  variable：定义模板的参数，用户使用该模板创建环境时输入参数的值
  
  

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

完整代码示例：

https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/main.tf

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

• AliyunECSReadOnlyAccess
• AliyunVPCReadOnlyAccess
• AliyunNASReadOnlyAccess 
• AliyunOSSReadOnlyAccess
• AliyunLogReadOnlyAccess

完整代码示例：

https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/policy.json

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

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

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

1、创建普通的服务角色，授信服务选择函数计算

2、为该角色授予环境所需要的权限

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

• 通过 environment.outputs 来关联环境模板中定义的输出
  
  
• FC 的服务往往和一个环境相映射，通常在创建服务时服务名要带上环境的后缀，可以通过 environment.name 让服务和环境自动关联

  
  

• 指定环境时，无需在 props 中指定 region，组件会自动保证将服务部署到环境所在的 region

s deploy --env fc-env-testing

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

本文通过分析企业全面上云时，遇到的应用和基础设施管理的挑战，提出采用分层的模板化方式来组织不同团队的工作流，通过环境、服务、流水线来定义一个现代化的应用，通过环境模板、服务模板、流水线模板来屏蔽基础设施的复杂性并提升操作安全性，核心是需要一个管道来串联整个工作流，让 DevOps 的各个阶段可以自助化并安全的完成。

作者希望 Serverless Devs 可以充当这个管道，其应用、组件、插件的思路为开发者提供了良好的构建现代化应用的基础，并且 Serverless Devs 已经具备了服务及服务模板的抽象，需要扩展的是环境、流水线的能力。

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

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

1、持续打磨体验，输出更多开箱即用的模板

2、解决应用运行时访问环境的问题，比如在函数代码中通过某种方式安全、高效地访问环境的资源

3、输出流水线模板、流水线的能力

本篇介绍了 Serverless Devs 多环境功能的使用，在下一篇中我会就一些常见问题，进行详细解读。

Serverless Devs：https://www.serverless-devs.com/Pulumi：https://www.pulumi.com/Terraform：https://www.terraform.io/RAM：https://www.aliyun.com/product/ram?spm阿里云函数计算（FC）：https://www.aliyun.com/product/fc

本场景基于 Serverless 应用中心 + 阿里云函数计算 + 开源企业级在线文件管理系统 KodBox 打造，让你仅用 “几次” 点击，即可拥有一个可随意保存资源、不限速下载、多端使用、与朋友共享资源……的专属个人网盘。

戳原文，立即部署个人网盘！