简介：Serverless Devs 离不开对云资源的操作，但反对新资源时须要开发相应的组件代码；如果将环境模板的定义通过 Terraform IaC 来实现，在 Serverless Devs 的体系内不仅能良好地连接，还可能极大拓宽用户畛域；用户能够通过编写 Terraform 文件来定义本人的基础设施，用 Serverless Devs 实现所有工作流的串联。
前言
随着现代化利用的遍及和企业上云的深刻，我的项目中会波及越来越多的云资源应用。企业上云过程中，往往会有平台（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…
为上述资源定义权限策略，放弃权限最小准则，仅放开必要的写权限。因为 Terraform 在创立资源时会依赖很多资源的读权限，因而举荐再减少 AliyunECSReadOnlyAccess、AliyunVPCReadOnlyAccess、AliyunNASReadOnlyAccess 这些罕用的读权限。
残缺代码示例：https://github.com/devsapp/fc…
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 是：
继续打磨体验，输入更多开箱即用的模板
解决利用运行时拜访环境的问题，比方在函数代码中通过某种形式平安、高效地拜访环境的资源
输入流水线模板、流水线的能力
本篇介绍了 Serverless Devs 多环境性能的应用，在下一篇中我会就一些常见问题，进行具体解读。
文中链接：
Serverless Devs：https://www.serverless-devs.com/
Pulumi：https://www.pulumi.com/
Terraform：https://www.terraform.io/
RAM:https://www.aliyun.com/produc…
阿里云函数计算（FC）：https://www.aliyun.com/produc…
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。