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

作者：封崇

前语

跟着现代化运用的普及和企业上云的深入，项目中会触及越来越多的云资源运用。企业上云过程中，往往会有渠道（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 点：

1. 要为不同的环境保护不同的 s.yaml，保护本钱比较高。更新环境时需求重新发起布置，对接 CI/CD 服务时就要重新发起一次完好的发布上线操作。（但通常情况下环境的变化，例如升降配、更新权限，对程序来说是安全的，不需求发起一次上线）；
2. 难以完成基础设施团队、渠道团队、研制团队分层协作的场景。比方阿里云函数核算的服务描绘供给了日志、网络、NAS、服务人物等渠道办理员视角的装备。收到客户反应，这些装备是干嘛的研制根本都不清楚，无疑减低了研制功率并添加了安全危险，经常出现研制改错装备导致线上服务有损的情况；
3. Serverless Devs 的资源操作主要由组件来完成，但对于一些资源的变更可能会引起实例重建或者不能供给服务（比方更改数据库引擎、替换了 FC 的服务人物、替换VPC）的危险，组件开发者未必会清楚也可能会疏忽，即使清楚也需求 Case By Case 的经过许多判别代码来处理，这无疑添加了组件开发的复杂度和运用本钱；\

假如选用本文前语章节中描绘的分层的模板化计划，以上问题就能够顺畅处理：

1. 渠道团队经过封装环境模板，仅需对研制人员暴露安全的参数（比方实例标准），研制人员运用模板创立环境，填写必要的参数即可完结基础设施的建立；经过更新环境即可自助化地完结基础设施的升级，而且不需求重新发起代码发布操作；
2. 渠道团队在环境模板中声明更加严厉的拜访战略，拒绝某些有危险的资源操作，能够更好地操控爆破半径；

那么，接下来的问题就是：怎么在 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 指令，能够完成如下的作业流：

1. 经过基础设施即代码（IaC）的才能界说可复用的环境模板
2. 根据模板构建不同的测试、预发、出产等相互隔离的环境，并主动完结基础设施的建立
3. 将函数的同一份代码布置到不同的环境上

下面我们经过一个实践事例演示整个操作流程。假设事务场景需求：

• 在函数中读写 OSS 文件
• 日志文件写入 NAS，前端做实时展示
• 函数日志写入 SLS，做体系剖析

作为渠道办理员，需求为研制：

• 创立 OSS Bucket，Bucket 名字研制能够自己指定，可是 ACL战略必须是私有
• 创立 NAS 挂载点，触及的VPC、VSwitch、NAS 文件体系、拜访组、挂载点彻底由办理员指定
• 创立 SLS Project 、Logstore，名字研制能够自己指定，可是主动割裂、最大割裂数彻底由办理员指定

渠道办理员：开发环境模板

环境模板选用 IaC 来界说资源，现在只支撑Terraform类型的模板。环境模板的代码目录要包含两类文件：

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

• • variable：界说模板的参数，用户运用该模板创立环境时输入参数的值
  • resource：界说模板的资源，环境布置时完结资源的创立
  • output：界说模板的输出，环境布置成功后透出相应输出，能够被其他服务所拜访

• policy.json：RAM的权限战略数组，支撑自界说战略和体系战略，声明晰运用该模板创立资源所需求的权限，授信对象是函数核算。布置环境时，函数核算会经过人物扮演的方法拜访模板中界说的资源。

编写 IaC，界说环境模板的 variable、resource、output。完好代码示例：

github.com/devsapp/fc/…

为上述资源界说权限战略，坚持权限最小准则，仅放开必要的写权限。因为 Terraform 在创立资源时会依靠许多资源的读权限，因而引荐再添加这些常用的读权限：

• AliyunECSReadOnlyAccess

• AliyunVPCReadOnlyAccess

• AliyunNASReadOnlyAccess

• AliyunOSSReadOnlyAccess

• AliyunLogReadOnlyAccess 完好代码示例：

github.com/devsapp/fc/…

渠道办理员：发布环境模板

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

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

参数意义如下：

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

研制：运用环境模板创立环境

环境需求操作对应云资源的权限，颁发函数核算以人物扮演的方法拜访的云资源，因而需求：

1. 创立一般的服务人物，授信服务挑选函数核算
2. 为该人物颁发环境所需求的权限

经过 s env init 指令进入交互式操作，输入环境名、地域、人物、环境模板以及模板参数，完结环境的布置：

点击检查操作视频：

developer.aliyun.com/live/249417

执行成功后，会在本地 .s 目录下创立 env/fc-env-testing.yaml 描绘文件，能够检查并编辑该文件。

研制：布置函数到指定环境

开发人员编写 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 是：

• 持续打磨体会，输出更多开箱即用的模板
• 处理运用运转时拜访环境的问题，比方在函数代码中经过某种方法安全、高效地拜访环境的资源
• 输出流水线模板、流水线的才能

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

参考链接：

Serverless Devs：

www.serverless-devs.com/

Pulumi：

www.pulumi.com/

Terraform：

www.terraform.io/

RAM：

www.aliyun.com/product/ram…

阿里云函数核算（FC）：

www.aliyun.com/product/fc

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

自建真网盘：developer.aliyun.com/adc/series/…

点击此处，1 分钟 Serverless 极速布置个人网盘！