多种操作模式下的工具体系
众所周之,目前大部分的 Serverless 开发者工具均是通过 Yaml 等进行资源描述,少部分的 Serverless 开发者工具是通过命令行直接操作,无论是通过 Yaml 进行资源描述,还是通过纯命令行的操作,可以说两者各有各的好处。而在 Serverless Devs 开发者工具中,这两者均得以有效的支持。
Serverless Devs 开发者工具从根本上提供了两种使用方法。
Yaml 模式:需要依赖资源描述文档进行操作的模式
Cli 模式:可以在任何目录下直接执行,而不需要依赖资源描述文档;
这两者的核心区别是:
如果想要使用 Yaml 模式,在当前目录下,必须要有
s.yaml
/s.yml
文件,或通过-t
/--template
指定的资源部描述文件;如果想要试用 Cli 模式,则必须是
s cli 组件名 方法 参数
的格式进行,此时不需要 Yaml 文件;
举一个非常简单的例子,如果有一个应用的资源描述文件s.yaml
如下:
此时,可以执行s deploy
进行myApp
应用部署,如果执行s backend-starter deploy
则可以进行myApp
应用下的backend-starter
项目/服务部署。
此时,部署过程中,所需要的相关参数,可以通过该 Yaml 文件进行读取。
但是,在某些情况下,并不方便直接使用 Serverless Devs 规范的 Yaml 文件(例如,将线上资源同步到本地,或者要将 Funcraft 的 Yaml 转换成为 Serverless Devs 的 Yaml),此时可以选择纯命令行形式,即s cli
模式。
在 s cli
模式下,由于不会读取 Yaml 等资源描述文件,所以很多参数都需要自行填写,这时的填写方法有两种:
通过
s cli
天然支持的-p
/--prop
参数,进行相关 Yaml 参数的赋值,例如上述案例的s backend-starter deploy
,此时可以改写成:
通过 demo 组件本身所支持的一些参数,例如通过
s cli devsapp/demo -h
,可以得到帮助信息,部分内容如下:
特点对比
设计思路
❓ 为什么要同时存在 Yaml 模式和 Cli 模式?
💬 因为在长期的实践过程中,我们发现通过 Yaml 进行资源描述会相对来说更简单和方便,例如 K8S 等也都是通过 Yaml 进行资源描述的;但是,在某些情况下,Yaml 文件也可能成为一种负担,例如想要查看某个服务下的函数列表,查看某个地区下的服务列表,因为这样一个简单的事情要额外的去完成一个 Yaml 文件,就显得过于臃肿,所以,在 Serverless Devs 项目中,同时保留了两种使用方法。
版权声明: 本文为 InfoQ 作者【刘宇】的原创文章。
原文链接:【http://xie.infoq.cn/article/843907a70de0c779add2dd9dd】。文章转载请联系作者。
评论