外汇网站模版,网站开发和网站制作的区别,网站建设总结 优帮云,吉林市做网站的公司前言
随着现代化应用的普及和企业上云的深入#xff0c;项目中会涉及越来越多的云资源使用。企业上云过程中#xff0c;往往会有平台#xff08;Platform#xff09;团队和基础设施#xff08;Infra#xff09;团队#xff1a;平台团队关注业务#xff0c;根据业务场景…前言
随着现代化应用的普及和企业上云的深入项目中会涉及越来越多的云资源使用。企业上云过程中往往会有平台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 BucketBucket 名字研发可以自己指定但是ACL策略必须是私有创建 NAS 挂载点涉及的VPC、VSwitch、NAS文件系统、访问组、挂载点完全由管理员指定创建SLS Project 、Logstore名字研发可以自己指定但是自动分裂、最大分裂数完全由管理员指定
01 平台管理员开发环境模板
环境模板采用 IaC 来定义资源目前只支持 Terraform 类型的模板。环境模板的代码目录要包含两类文件
IaC文件即 Terraform 的 .tf 文件IaC 文件的核心要素为variable定义模板的参数用户使用该模板创建环境时输入参数的值resource定义模板的资源环境部署时完成资源的创建output定义模板的输出环境部署成功后透出相应输出可以被其他服务所访问policy.jsonRAM 的权限策略数组支持自定义策略和系统策略声明了使用该模板创建资源所需要的权限授信对象是 函数计算。部署环境时函数计算会通过角色扮演的方式访问模板中定义的资源。
编写 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 模板代码目录
操作成功后会返回当前模板的 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 Devshttps://www.serverless-devs.com/
Pulumihttps://www.pulumi.com/
Terraformhttps://www.terraform.io/
RAM:https://www.aliyun.com/product/ram?spm
阿里云函数计算FC https://www.aliyun.com/product/fc?
原文链接
本文为阿里云原创内容未经允许不得转载。
