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

作者 | 刘宇（阿里云 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.png

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}

元数据相干形容

在该格局中：

对于 Service 参数：

变量赋值

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

• 获取以后机器中的环境变量：${env(环境变量)}，例如 ${env(secretId)}
• 获取内部文档的变量：${file(门路)}，例如 ${file(./path)}
• 获取全局变量：${vars.*}
• 获取其余我的项目的变量：${projectName.props.*}

• 获取 Yaml 中其余我的项目的后果变量：${projectName.output.*}

  服务程序

  如果一个 ServerlessApplication 模型对应的 Yaml 文件中有过多的服务，零碎会默认剖析部署程序，该部署程序分为两个步骤：

1. 剖析我的项目中的依赖关系

2. 有依赖关系的依照依赖关系从前到后部署，无依赖关系的按 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 命令，零碎将会依照以下程序进行操作：

1. 在./backend_src 目录下执行 s exec — publish
2. 在./backend_src 目录下执行 s build
3. 调用组件 vue-component 的 deploy 办法，并将 props 和我的项目的根本信息传入到组件 vue-component 的 deploy 办法中
4. 在./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 文件能够看出以下信息：

1. 该利用的名字是 FullStack，将会应用密钥 xxx-account1;

2. 该利用领有三个服务：

   • backend 服务：应用了 django-component 组件
   • user—frontend 服务：应用了 vue-component 组件
   • admin-frontend 服务：应用了 vue-component 组件

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

|

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

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 模式和 Cli 模式？

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

附录

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

更多内容关注 Serverless 微信公众号（ID：serverlessdevs），会集 Serverless 技术最全内容，定期举办 Serverless 流动、直播，用户最佳实际。