随着现代化应用的普及和企业上云的深入,项目中会涉及越来越多的云资源使用。企业上云过程中,往往会有平台(Platform)团队和基础设施(Infra)团队:平台团队关注业务,根据业务场景进行抽象,对研发人员屏蔽基础设施;基础设施团队关注安全及成本,为平台团队规划了不同的子账号、权限策略以及网络配置。 这种分层管理的必然结果导致应用和基础设施的生命周期会完全不同,因此基础设施管理员、平台管理员、研发人员关注的云资源视角也不尽相同。比如:
因此,随着职责边界的不同,平台团队面临着更大的挑战,既要面向研发人员消化业务,又要面向基础设施团队解释云产品的使用,无疑增加了很多沟通成本,降低了业务的迭代效率。
如果能建立一种自动化的管道,让不同团队自助化地完成各自的边界,势必会极大地提升生产力。这需要几个很重要的概念来连接 Dev 和 Ops:
要实现高效的自助化操作,合理化的方案是将上述概念进行模板化,并使用如下的工作流来完成:
环境模板
;将阿里云函数计算(FC)的函数、Serverless 应用引擎(SAE )应用这些研发关注的业务资源封装成服务模板
;将 CI/CD 的基础流程封装成流水线模板
;环境模板
创建不同的测试、预发、生产环境
,然后授予研发子账号访问权限,或者授予研发写权限来自助创建环境;服务模板
以及关联的环境来创建服务
,实现将应用程序自动部署到指定的环境
上;流水线模板
,通过主动触发或者代码提交自动触发 CI/CD 的执行。通过这种分边界的模板化处理方式,可以让企业不同的团队自助完成基础设施的搭建,提高生产效率的同时,又保证了权限隔离,让基础设施受到保护。
Serverless Devs [1]是一款面向 Serverless 应用全生命周期的管理工具,其模型规范中存在应用和服务的概念,但目前缺少对环境的内在支持,代码+基础设施共同维护在一个 s.yaml 下。这种模式在多环境时的限制主要有3点:
如果采用本文前言章节中描述的分层的模板化方案,以上问题就可以顺利解决:
那么,接下来的问题就是:如何在 Serverless Devs 中定义环境模板?
环境模板面向的是基础设施,也就是云资源。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 来定义资源,目前只支持 Terraform 类型的模板。环境模板的代码目录要包含两类文件:
编写 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
通过 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
、文本内容
、版本
等信息。
环境需要操作对应云资源的权限,授予函数计算以角色扮演的方式访问的云资源,因此需要:
通过 s env init
命令进入交互式操作,输入环境名、地域、角色、环境模板以及模板参数,完成环境的部署:
执行成功后,会在本地 .s
目录下创建 env/fc-env-testing.yaml
描述文件,可以查看并编辑该文件。
开发人员编写s.yaml,并将基础设施配置关联到指定环境。可以通过如下方式:
environment.outputs
来关联环境模板中定义的输出environment.name
让服务和环境自动关联通过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/product/ram?spm 阿里云函数计算(FC):https://www.aliyun.com/product/fc?
更多内容关注 Serverless 微信公众号(ID:serverlessdevs),汇集 Serverless 技术最全内容,定期举办 Serverless 活动、直播,用户最佳实践。
|