前言随着现代应用的普及和企业上云的深入，越来越多的云资源会被用到项目中。在企业上云的过程中，往往会有平台团队和基础架构团队：平台团队关注业务，根据业务场景抽象，为R&D人员屏蔽基础架构；基础架构团队注重安全性和成本，为平台团队规划不同的子账户、权限策略和网络配置。这种分级管理的必然结果将导致应用和基础设施的生命周期完全不同，因此基础设施管理员、平台管理员和R&D人员对云资源的看法也不同。例如：
基础架构管理员管理整个企业的云账户，规划企业的网络配置，为每个平台团队设置不同的子账户和访问策略；平台管理员持有子账户，根据容灾和高可用场景划分区域、安全和流量策略；规划日志、存储、数据库规格、备份配置、配额等。根据业务场景；根据R&D工艺要求规划CI/CD装配线；R&D人员在使用平台的过程中，只需要关注代码、数据、配置等与程序相关的内容：需要访问数据库时，需要来自平台的数据连接字符串；当需要采集日志时，采集路径提交给平台，平台运行日志服务完成日志采集配置和挂载；当需要持久存储时，将本地挂载路径提交给平台，平台运行存储服务挂载文件目录；发布代码以自动触发CI/CD管道的执行；因此，随着职责的不同，平台团队面临着更大的挑战。需要为R&D人员消化业务，为基础架构团队讲解云产品的使用，这无疑增加了很多沟通成本，降低了业务的迭代效率。
如果能建立一个自动化的流水线，让不同的团队自己完成他们的边界，那肯定会大大提高生产力。这需要几个重要的概念来连接开发和运营：
服务：代码和程序的描述只描述与程序相关的信息，如功能配置、日志收集路径等。对于功能性应用程序，服务通常描述一个功能。对于容器化的应用，服务一般描述一个工作负载环境：服务运行在不同的环境中，环境是服务运行的载体，描述了基础设施(如网络、集群、存储)的配置。以及应用运行时的运维配置(如弹性伸缩、资源规范)管道：描述CI/CD，完成代码到服务的构建，将服务部署到应用的所有环境：一组服务、环境、管道所有资源的集合。
为了实现高效的自助操作，合理的方案是将上述概念模板化，并使用以下工作流来完成：
平台管理员根据测试/生产隔离的要求，将网络、日志服务、存储、数据库等基础设施资源打包成环境模板；将R&D关注的业务资源阿里云函数计算(FC)功能和无服务器应用引擎(SAE)应用封装成服务模板；将CI/CD的基本流程封装成管道模板；基础架构管理员审核模板，通过后将对应的子账号分配给平台管理员；平台管理员持有子账户选择环境模板，创建不同的测试、预览和生产环境，然后授予R&D子账户访问权限或R&D写权限，自行创建环境；R&D人员选择服务模板和相关联的环境来创建服务，以便自动地将应用部署到指定的环境；R&D人员选择流水线模板，通过主动触发或代码提交自动触发CI/CD的执行。通过这种划分边界的模板处理方法，企业中的不同团队可以构建基础设施
无服务器开发人员在支持多种环境时面临的挑战无服务器开发人员[1]是无服务器应用程序整个生命周期的管理工具。其模型规范中有应用和服务的概念，但目前缺乏对环境的内部支持，代码基础设施在一个s.yaml下共同维护，这种模式在多环境下主要有三个局限性：
要针对不同的环境维护不同的s.yaml，维护成本比较高。在更新环境时，需要重新启动部署，在对接CI/CD服务时，需要重新启动一个完整的发布和在线操作。(但是，通常情况下，环境的变化，比如升降、更新权限，对程序来说是安全的，不需要发起在线启动)；难以实现基础架构团队、平台团队和R&D团队之间的分层协作。比如阿里云功能计算的服务描述，提供了日志、网络、NAS、服务角色等平台管理员视角的配置。收到客户反馈后，基本不清楚这些配置的R&D是多少，这无疑降低了R&D效率，增加了安全隐患，而且往往会因为R&D和配置纠错导致在线服务丢失；无服务器Devs的资源操作主要是通过组件来实现的，但是一些资源的改变可能会造成实例重构或者无法提供服务的风险(比如改变数据库引擎、改变FC的服务角色、改变VPC)，这一点组件开发者可能并不清楚，也可能被忽略。即使明确，也需要通过很多判断代码来解决，这无疑增加了组件开发的复杂度和成本。如果采用本文前言中描述的分层模板化方案，可以顺利解决上述问题：
通过封装环境模板，平台只需要将安全参数(如实例规范)暴露给R&D人员，由他们使用模板创建环境，并填写必要的参数，完成基础设施的搭建；通过更新环境，可以自助升级基础设施，无需重启代码发布操作；平台在环境模板中声明更严格的访问策略，拒绝一些有风险的资源操作，可以更好的控制爆炸半径；那么，接下来的问题就是：如何在无服务器Devs中定义环境模板？
当无服务器Devs遇到Terraform环境模板，针对的是基础设施，也就是云资源。无服务器的Devs离不开云资源的运营。传统的方式是在组件中直接使用云产品的SDK，但在支持新资源时，需要开发相应的组件代码。因此面临着资源膨胀带来的开发效率降低、代码维护越来越困难的问题。更好的方法是通过基础设施，即代码(IaC)来完成云资源的创建。
无服务器开发人员在前面的实践中使用了Pulumi，并通过单个组件封装了Pulumi堆栈。然而，在实践之后，人们发现使用GPLs来定义IaC仍然需要模型级的良好抽象。所以把Pulumi扩展到组件开发者，从生态成熟度和灵活性上来说都不是很好。
目前IaC生态最有力的工具是Terraform，它已经成为事实上的标准。Terraform HCL本身就是一个DSL，可以很好的兼容任何生态，尤其是极其丰富的提供商。如果阿里云的云产品与POP对接，可以自动生成Terraform Provider，可靠性和访问便利性已经相当高了。
如果环境模板的定义由Terraform IaC完成，并能在无服务器Devs的系统内很好的衔接，可以大大拓宽用户领域。用户可以通过编写Terraform文件来定义自己的基础设施，并将所有工作流与无服务器dev串联起来。
操作案例遵循无服务器Devs的组件开发规范，将多个环境的操作封装到env命令中。通过使用s env命令，可以实现以下工作流程：
通过基础设施即代码(IaC)的功能定义可重用的环境模板。基于模板，构建不同的隔离环境，如测试、预发布、生产等。并自动完成基础设施建设。将相同的功能代码部署到不同的环境中。让我们通过一个实际的c来演示整个操作过程
在函数中读写OSS文件，日志文件写入NAS，前端实时显示函数日志写入SLS，做系统分析。作为平台管理员，R&D有必要：
创建OSS Bucket，Bucket名研发可以自己指定，但是ACL策略必须是私有创建NAS挂载点。所涉及的VPC、VSwitch、NAS文件系统、访问组和装载点完全由管理员指定，以创建SLS项目和日志存储。名称研发可以自己指定，但是自动拆分和最大拆分数量完全由管理员指定. 01平台管理员：开发环境模板
模板使用IaC来定义资源。目前，仅支持Terraform模板。模板的代码目录应该包含两种类型的文件：
IaC文件。地形的tf文件。IaC文件的核心元素有：变量：定义模板的参数。当用户使用模板创建环境时，他们输入参数的值。资源：定义模板的资源。当部署环境时，它完成了资源的创建。输出：定义模板的输出。成功部署环境后，将显示相应的输出，其他服务可以访问这些输出。
policy . JSON:RAM的权限策略数组，支持自定义策略和系统策略，声明使用该模板创建资源所需的权限。信用对象是函数计算。部署环境时，函数计算将通过角色扮演访问模板中定义的资源。编写IaC来定义环境模板的变量、资源和输出。
完整代码示例：https://github . com/devs app/fc/blob/main/examples/multi-envs/infra/main . TF
为上述资源定义权限策略，保持最小权限原则，只释放必要的写权限。Terraform在创建资源时会依赖于很多资源的读取权限，所以建议添加常用的读取权限，如AliyunECSReadOnlyAccess、AliyunVPCReadOnlyAccess和AliyunNASReadOnlyAccess。
完整代码示例：https://github . com/devs app/fc/blob/main/examples/multi-envs/infra/policy . JSON
02平台管理员：发布环境模板
通过环境应用模板发布环境模板
s env apply-template-name testing-description \’这是一个演示\’-代码。/infra
参数具有以下含义：
参数全名
需要吗？
参数含义
名字
真实的
模板名称
描述
错误的
模板描述
密码
错误的
模板代码目录
操作成功后，返回当前模板的变量、输出、状态、策略、文本内容、版本等信息。
03 R&D:使用环境模板创建环境
环境需要权限来操作相应的云资源，授予函数以角色扮演的方式计算访问的云资源，所以需要：
创建一个普通的服务角色，信用服务选择函数为这个角色计算环境所需的权限。通过s env init命令进入交互操作，输入环境名称、区域、角色、环境模板和模板参数，完成环境的部署：
成功执行后，将在本地创建env/fc-env-testing.yaml描述文件。的目录，可以查看和编辑。
04 R&D:将功能部署到指定的环境
开发人员编写s.yaml，并将基础设施配置与指定的环境相关联。可以通过以下方式完成：
通过environment.outputs关联环境模板中定义的输出FC的服务通常映射到环境。通常，在创建服务时，服务名应该带有环境的后缀。可以通过environment.name自动将服务与环境关联起来，在指定环境时，不需要在props中指定区域，组件会自动保证服务部署到环境所在的区域。
通过sdeploy-env将函数部署到指定的环境中。
部署-环境fc-环境测试
在执行指令之后，组件将首先确定环境是否已经被部署，如果环境状态是就绪，它将把服务部署到环境。否则，环境将在服务之前部署。
本文通过分析企业全面上云对应用和基础设施管理的挑战，提出以分层模板的方式组织不同团队的工作流程，通过环境、服务和管道定义一个现代化的应用，通过环境模板、服务模板和管道模板屏蔽基础设施的复杂性，提高运营安全性。核心是需要一个管道把整个工作流程串联起来，让DevOps的每一个阶段都能自助完成，安全完成。作者希望无服务器Devs可以充当这个管道，其应用程序、组件和插件的思想为开发者构建现代应用程序提供了良好的基础。无服务器Devs已经有了服务和服务模板的抽象，需要扩展环境和管道的能力。
本文重点讨论了如何使用无服务器Devs来管理多个环境，并分析了关键挑战是代码和基础设施的解耦，并使用IaC来完成基础设施的定义。Terraform是最适合IaC生态的，所以选择Terraform HCL来定义环境模板，环境的资源安排由后端的Terraform服务完成。这样就可以通过无服务器的Devs完成‘发布环境模板’-‘部署环境’-‘部署到指定环境’的完整工作流程。
当然，要实现上述最终愿景，还有很长的路要走。未来规划的主要路线图是：
不断打磨体验，输出更多开箱即用的模板，解决应用运行时访问环境的问题，比如在函数代码中安全高效地访问环境的资源的能力。本文介绍了无服务器Devs多环境函数的使用，在下一篇文章中，我将详细解释一些常见问题。
文本中的链接：
无服务器开发：https://www.serverless-devs.com/
普卢米：https://www.pulumi.com/
地形：https://www.terraform.io/
RAM:https://www . aliyun . com/product/RAM？冲程/分钟（Strokes per Minute的缩写）
阿里云计算(FC):https://www.aliyun.com/product/fc?
原文链接：http://click.aliyun.com/m/1000347184/
本文为阿里云原创内容，未经允许不得转载。
