其他分享
首页 > 其他分享> > 为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(上)

为 Serverless Devs 插上 Terraform 的翅膀,实现企业级多环境部署(上)

作者:互联网

简介: Serverless Devs 离不开对云资源的操作,但支持新资源时需要开发相应的组件代码;​如果将环境模板的定义通过 Terraform IaC 来完成,在 Serverless Devs 的体系内不仅能良好地衔接,还能够极大拓宽用户领域;​用户可以通过编写 Terraform 文件来定义自己的基础设施,用 Serverless Devs 完成所有工作流的串联。​

前言

随着现代化应用的普及和企业上云的深入,项目中会涉及越来越多的云资源使用。企业上云过程中,往往会有平台(Platform)团队和基础设施(Infra)团队:平台团队关注业务,根据业务场景进行抽象,对研发人员屏蔽基础设施;基础设施团队关注安全及成本,为平台团队规划了不同的子账号、权限策略以及网络配置。 这种分层管理的必然结果导致应用和基础设施的生命周期会完全不同,因此基础设施管理员、平台管理员、研发人员关注的云资源视角也不尽相同。比如:

 

 

因此,随着职责边界的不同,平台团队面临着更大的挑战,既要面向研发人员消化业务,又要面向基础设施团队解释云产品的使用,无疑增加了很多沟通成本,降低了业务的迭代效率。

 

如果能建立一种自动化的管道,让不同团队自助化地完成各自的边界,势必会极大地提升生产力。这需要几个很重要的概念来连接 Dev 和 Ops:

 

 

要实现高效的自助化操作,合理化的方案是将上述概念进行模板化,并使用如下的工作流来完成:

 

 

通过这种分边界的模板化处理方式,可以让企业不同的团队自助完成基础设施的搭建,提高生产效率的同时,又保证了权限隔离,让基础设施受到保护。

 

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. 将函数的同一份代码部署到不同的环境上

 

下面我们通过一个实际案例演示整个操作流程。

 

假设业务场景需要:

 

作为平台管理员,需要为研发:

01 平台管理员:开发环境模板

 

环境模板采用 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

02 平台管理员:发布环境模板

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

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

参数含义如下:

参数全称

是否必填

参数含义

name

True

环境模板名字

description

False

环境模板描述

code

False

模板代码目录

 

 

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

 

03 研发:使用环境模板创建环境

 

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

  1. 创建普通的服务角色,授信服务选择函数计算
  2. 为该角色授予环境所需要的权限

 

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

 

 

执行成功后,会在本地 .s 目录下创建 env/fc-env-testing.yaml 描述文件,可以查看并编辑该文件。

 

04 研发:部署函数到指定环境

 

开发人员编写s.yaml,并将基础设施配置关联到指定环境。可以通过如下方式:

 

通过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?

原文链接:http://click.aliyun.com/m/1000347184/

本文为阿里云原创内容,未经允许不得转载。

标签:Serverless,服务,基础设施,环境,企业级,Devs,模板
来源: https://www.cnblogs.com/yunqishequ/p/16420479.html