关于serverless:最全即学即会-Serverless-Devs-基础入门下

103次阅读

共计 7986 个字符，预计需要花费 20 分钟才能阅读完成。

简介：在上篇《最全！即学即会 Serverless Devs 根底入门》中，咱们论述了工具链的重要性，并对装置形式 & 密钥配置进行了解说。然而在 Serverless Devs 的规定中，一个 Yaml 能够被认为是一个 Serverless 利用，因而本文将持续率领各位理解下 Yaml 的应用标准。

作者 | 刘宇（阿里云 Serverless 产品经理）

在上篇《最全！即学即会 Serverless Devs 根底入门》中，咱们论述了工具链的重要性，并对装置形式 & 密钥配置进行了解说。然而在 Serverless Devs 的规定中，一个 Yaml 能够被认为是一个 Serverless 利用，因而本文将持续率领各位理解下 Yaml 的应用标准。

Yaml 的应用标准

Serverless Devs 能够通过指定格局的 Yaml 对 Serverless 利用进行形容，在 Serverless Devs 的规定中，一个 Yaml 能够被认为是一个 Serverless 利用。

Yaml 的格局须要依照 Serverless Devs 的标准，提供绝对应的资源 / 行为形容文件，且该文件还须要合乎以下条件：

拓展名能够是.yaml 或.yml
格局必须合乎 Yaml 标准（https://yaml.org/spec/1.2.2/）
对于须要通过形容文件进行环境隔离的我的项目，倡议将文件命名为 s-${ENV}.yaml 或 s-${ENV}.yml 格局。例如：s-prod.yaml。

在默认状况下，Serverless Devs 开发者工具会默认该形容文件的名称为 s.yaml 或 s.yml，且 s.yaml 的优先级大于 s.yml，即在一个 Serverless 利用下，同时呈现 s.yaml 与 s.yml 时，零碎会优先辨认和应用 s.yaml。

当然，开发者也能够通过 -t,–template [templatePath]进行指定，例如，在某利用在生产环境下的形容文件名为 s -prod.yml，则能够在执行相干命令时，减少参数 -ts-prod.yml 或者 –templates-prod.yml。

形容文件格式 / 标准

对于 ServerlessDevs 所反对的资源 / 行为形容文件根本格局为：

edition: 1.0.0 # 命令行 YAML 标准版本，遵循语义化版本（Semantic Versioning）标准
name: applicationName # 利用名称
access: xxx-account1 # 秘钥别名

vars: # [全局变量，提供给各个服务应用]
Key: Value

Service: # 能够包含多个服务
ServiceName: # 服务名称

access: xxx-account1      #  秘钥别名，如果和我的项目的 access 雷同，可省略
component: componentName  #  组件名称
props: serviceProp        #  组件的属性值
actions: serviceActions   #  自定义执行逻辑

例如，一个绝对残缺的 Yaml 案例能够是：

edition: 1.0.0 # 命令行 YAML 标准版本，遵循语义化版本（Semantic Versioning）标准
name: FullStack # 项目名称
access: xxx-account1 # 秘钥别名

vars: # [全局变量，提供给各个服务应用]
logo: https://image.aliyun.com/xxxx…

services:
nextjs-portal: # 服务名称

access: xxx-account1  #  秘钥别名，如果和我的项目的 access 雷同，可省略
component: vue-component  # 组件名称
props: #  组件的属性值
  src: ./frontend_src
  url: url
actions: # 自定义执行逻辑
  pre-deploy: # 在 deploy 之前运行
    - run: s exec -- publish  # 要运行的命令行
      path: ./backend_src # 命令行运行的门路
    - run: s build  # 要运行的命令行
      path: ./backend_src # 命令行运行的门路
  post-deploy: # 在 deploy 之后运行
    - run: s clean
      path: ./frontend_src

assets:

component: static
props:
  cache-control: "public, max-age=604800, immutable"
  www: "./public"

express-blog:

component: express
props:
  app: ./express-blog
  url: ${vars.domain}
actions:
  pre-deploy:
    - run: npm run build
      path: ./express-blog

gateway:

component: serverless-gateway # 路由组件：HTTP URL 和服务之间的映射规定
props:
  routes:
    - route: /~assets
      value: ${assets.output.url}
    - route: /
      value: ${nextjs-portal.output.url}
      index: index.html
    - route: /~portal
      value: ${nextjs-portal.output.url}
      inex: index.html
    - route: /~blog
      value: ${express-blog.output.url}

元数据相干形容

在该格局中：

参数名

代表含意

edition

命令行 YAML 标准版本，遵循语义化版本（Semantic Versioning）标准

name

利用名称

access

秘钥别名，能够应用通过 config 命令配置的密钥信息，以及配置到环境变量的密钥信息

vars

全局变量，提供给各个服务应用，是一个 Key-Value 的模式

Service

利用所蕴含的服务，是一个 Key-Value 的模式

对于 Service 参数：

参数名

代表含意

access

秘钥别名，如果和我的项目的 access 雷同，可省略

component

组件名称

actions

自定义执行逻辑

props

组件的属性值

变量赋值

Serverless Devs 的 Yaml 文件反对多种变量格局：

获取以后机器中的环境变量：${env(环境变量)}，例如 ${env(secretId)}
获取内部文档的变量：${file(门路)}，例如 ${file(./path)}
获取全局变量：${vars.*}
获取其余我的项目的变量：${projectName.props.*}
获取 Yaml 中其余我的项目的后果变量：${projectName.output.*}
服务程序
如果一个 ServerlessApplication 模型对应的 Yaml 文件中有过多的服务，零碎会默认剖析部署程序，该部署程序分为两个步骤：

剖析我的项目中的依赖关系
有依赖关系的依照依赖关系从前到后部署，无依赖关系的按 Yaml 配置的从上到下部署
行为形容

在 ServerlessApplication 模型对应的 Yaml 文件中，能够针对服务，提供对应的行为操作，其根本格局是：

actions: # 自定义执行逻辑
pre- 命令: # 在命令之前运行

- run: command  # 要运行的操作
  path: ./path # 运行操作的门路

post- 命令: # 在命令之后运行

- run: command  # 要运行的操作
  path: ./path # 运行操作的门路

例如：

actions: # 自定义执行逻辑
pre-deploy: # 在 deploy 之前运行

- run: s exec -- publish  # 要运行的命令行
  path: ./backend_src # 命令行运行的门路
- run: s build  # 要运行的命令行
  path: ./backend_src # 命令行运行的门路

post-deploy: # 在 deploy 之后运行

- run: s clean
  path: ./frontend_src

当 ServerlessDevs 开发者工具执行到该服务时，会在进行相干的命令之行之前，优先依照程序执行 pre- 命令的操作，所有内容实现执行之后，再执行 post- 命令的操作。

以上面的 Yaml 为例：

edition: 1.0.0 # 命令行 YAML 标准版本，遵循语义化版本（Semantic Versioning）标准
name: FullStack # 项目名称

services:
nextjs-portal: # 服务名称

access: xxx-account1  #  秘钥别名，如果和我的项目的 access 雷同，可省略
component: vue-component  # 组件名称
props: #  组件的属性值
  src: ./frontend_src
  url: url
actions: # 自定义执行逻辑
  pre-deploy: # 在 deploy 之前运行
    - run: s exec -- publish  # 要运行的命令行
      path: ./backend_src # 命令行运行的门路
    - run: s build  # 要运行的命令行
      path: ./backend_src # 命令行运行的门路
  post-deploy: # 在 deploy 之后运行
    - run: s clean
      path: ./frontend_src

当开发者在以后利用下执行了 deploy 命令，零碎将会依照以下程序进行操作：

在./backend_src 目录下执行 s exec — publish
在./backend_src 目录下执行 s build
调用组件 vue-component 的 deploy 办法，并将 props 和我的项目的根本信息传入到组件 vue-component 的 deploy 办法中
在./frontend_src 目录下执行 s clean
以上程序仅实用于整个流程没有出错的前提下，如果流程呈现谬误，零碎将会进行报错，并终止后续流程的执行。

通过命令操作利用
所谓的自定义命令指的是由组件决定的命令。因为 ServerlessDevs 开发者工具，自身并不具备任何业务相干的能力（值得包含不限于函数的部署、利用的构建、我的项目的测试等），所以，这些能力都将会由组件提供，通过 ServerlessDevs 开发者工具进行透出。

例如，某利用的资源 / 行为形容文件如下：

edition: 1.0.0 # 命令行 YAML 标准版本，遵循语义化版本（Semantic Versioning）标准
name: FullStack # 项目名称
access: xxx-account1

services:
backend: # 服务名称

component: django-component  # 组件名称
props: #  组件的属性值
  src: ./backend_src
  url: url

user—frontend: # 服务名称

component: vue-component  # 组件名称
props: #  组件的属性值
  src: ./frontend_src_user
  url: url

admin-frontend: # 服务名称

component: vue-component  # 组件名称
props: #  组件的属性值
  src: ./frontend_src_admin
  url: url

通过该 Yaml 文件能够看出以下信息：

该利用的名字是 FullStack，将会应用密钥 xxx-account1;
该利用领有三个服务：
backend 服务：应用了 django-component 组件
user—frontend 服务：应用了 vue-component 组件
admin-frontend 服务：应用了 vue-component 组件

如果此时 django-component 组件和 vue-component 组件反对的自定义命令为：

django-component

vue-component

deploy

反对

反对

remove

反对

反对

test

反对

不反对

则能够通过自定义命令实现利用级操作和服务级操作。

1）利用级操作

在以后我的项目下，能够执行 s [自定义命令]实现利用纬度的操作。

执行 s deploy 或者 s remove 时，因为 backend、user—frontend、admin-frontend 三个服务对应的组件，均反对 deploy 和 remove 办法，所以此时零碎会依照服务的部署程序，进行三个服务别离对应的组件的 deploy 或 remove 操作；此时，零碎的 exit code 为 0；

执行 s test 时，因为 user—frontend、admin-frontend 两个服务对应的组件并不反对 test 办法，所以此时零碎会执行 backend 对应组件（django-component）的 test 操作；此时，零碎会对 user—frontend、admin-frontend 两个服务进行正告，然而并不会报错，最终的 exit code 为 0；

如果在执行相干的命令时，backend、user—frontend、admin-frontend 三个服务任何一个服务在执行过程中呈现了谬误，零碎则会报错，并终止下一步的操作，此时，零碎的 exit code 为 101；
2）服务级操作

在以后我的项目下，能够执行 s [服务名] [自定义命令]实现服务级操作。

执行 s backend deploy 等，能够针对服务 backend 进行 deploy 相干的操作，如果顺利完成与其操作，零碎的 exit code 为 0；否则，呈现谬误，零碎的 exit code 为 101；
执行 s admin-frontend test 是，因为服务 admin-frontend 对应的 test 办法是不存在的，此时零碎将会认为是未找到组件办法，零碎的 exit code 为 100；
多种操作模式下的工具体系

众所周之，目前大部分的 Serverless 开发者工具均是通过 Yaml 等进行资源形容，少部分的 Serverless 开发者工具是通过命令行间接操作，无论是通过 Yaml 进行资源形容，还是通过纯命令行的操作，能够说两者各有各的益处。而在 ServerlessDevs 开发者工具中，这两者均得以无效的反对。

Serverless Devs 开发者工具从根本上提供了两种应用办法。

Yaml 模式：须要依赖资源形容文档进行操作的模式
Cli 模式：能够在任何目录下间接执行，而不须要依赖资源形容文档；

这两者的外围区别是：

如果想要应用 Yaml 模式，在当前目录下，必须要有 s.yaml/s.yml 文件，或通过 -t/–template 指定的资源部形容文件；
如果想要试用 Cli 模式，则必须是 s cli 组件名办法参数的格局进行，此时不须要 Yaml 文件；

举一个非常简单的例子，如果有一个利用的资源形容文件 s.yaml 如下：

name: myApp
edition: 1.0.0
access: “myaccess”

services:
website-starter:

component: devsapp/website
props:
  bucket: testbucket

backend-starter:

component: devsapp/demo
props:
  service:
    name: serviceName
  function:
    name: functionName
  region: cn-hangzhou

此时，能够执行 s deploy 进行 myApp 利用部署，如果执行 s backend-starter deploy 则能够进行 myApp 利用下的 backend-starter 我的项目 / 服务部署。

此时，部署过程中，所须要的相干参数，能够通过该 Yaml 文件进行读取。

然而，在某些状况下，并不不便间接应用 ServerlessDevs 标准的 Yaml 文件（例如，将线上资源同步到本地，或者要将 Funcraft 的 Yaml 转换成为 Serverless Devs 的 Yaml），此时能够抉择纯命令行模式，即 s cli 模式。

在 s cli 模式下，因为不会读取 Yaml 等资源形容文件，所以很多参数都须要自行填写，这时的填写办法有两种：

通过 s cli 人造反对的 -p/–prop 参数，进行相干 Yaml 参数的赋值，例如上述案例的 s backend-starter deploy，此时能够改写成：
$ s cli devsapp/demo -p “{\”service\”:{\”name\”:\”serviceName\”},\”function\”:{\”name\”:\”functionName\”},\”region\”:\”cn-hangzhou\”}”
通过 demo 组件自身所反对的一些参数，例如通过 s clidevsapp/demo -h，能够失去帮忙信息，局部内容如下：
–region [region] [C-Required] Specify the fc region, value: cn-hangzhou/cn-beijing/cn-beijing/cn-hangzhou/cn-shanghai/cn-qingdao/cn-zhangjiakou/cn-huhehaote/cn-shenzhen/cn-chengdu/cn-hongkong/ap-southeast-1/ap-southeast-2/ap-southeast-3/ap-southeast-5/ap-northeast-1/eu-central-1/eu-west-1/us-west-1/us-east-1/ap-south-1
–service-name [serviceName] [C-Required] Specify the fc service name
–function-name [functionName] [Optional] Specify the fc function name
此时，就可与通过上面的命令实现上述性能：

$ s cli devsapp/demo –region cn-hangzhou –service-name serviceName –function-name functionName
特点比照

模式

应用办法

劣势

劣势

实用场景

Yaml 模式

在具备合乎 Serverless Devs 标准，且存在资源 / 行为形容的 Yaml 文件的利用目录下，执行组件对应的命令，即可间接应用，例如 s deploy，s servicename build 等

能够一键部署一个残缺的利用（例如，某个利用中规定了多个 Service，能够通过该命令一键部署）；同时，通过资源 / 行为形容文档，能够更佳简略，清晰的对利用进行形容；

须要学习 Yaml 的标准，且在某些时候与一些自动化流程进行联合，会比较复杂；

部署、运维等操作，尤其是批量操作时更为适合；

纯 Cli 模式

在任何目录下，通过子命令 cli 进行触发，同样实用全副组件，例如 s cli deploy -p “{/”function/”: /”function-name/”}”，s cli fc-api listFunctions –service-name my-service

相对来说能够更加简略，疾速上手工具，并且能够非常简单的与自动化流程进行联合，升高了 Yaml 格局 / 标准的学习难度

对于一些简单我的项目而言，须要在命令行中写过多的参数，出错的概率会比拟高；

更适宜我的项目的治理，源自化操作

设计思路
为什么要同时存在 Yaml 模式和 Cli 模式？

因为在长期的实际过程中，发现通过 Yaml 进行资源形容会相对来说更简略和不便，例如 K8S 等也都是通过 Yaml 进行资源形容的；然而，在某些状况下，Yaml 文件也可能成为一种累赘，例如想要查看某个服务下的函数列表，查看某个地区下的服务列表，因为这样一个简略的事件要额定的去实现一个 Yaml 文件，就显得过于臃肿，所以，在 Serverless Devs 我的项目中，同时保留了两种应用办法。

附录
[1]Serverless Devs 社区 GitHub：
https://github.com/serverless…

若有播种，就点个赞吧

原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。

正文完
serverless
发表至： serverless
2022-06-15
 0
关于serverless:打破-Serverless-落地边界阿里云-SAE-发布-5-大新特性
关于serverless:1分钟-Serverless-极速搭建真网站-领猫超卡之极速搭建-Zblog-博客系统场景体验
关于serverless:为什么-Serverless-能提升资源利用率
关于serverless:高德-Serverless-平台建设及实践