关于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: ValueService: # 能够包含多个服务  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.pngservices:  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-account1services:  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: myAppedition: 1.0.0access: "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 流动、直播，用户最佳实际。