vlambda博客
学习文章列表

即学即会 Serverless | Serverless Devs 基础入门


在上篇中，我们阐述了工具链的重要性，那么本文将带领各位快速实现 Serverless Devs 入门。
01



安装工具

Cloud Native


  • 第一步：请先安装 Node.js(>=10.8.0) 与 NPM 包管理工具；
  • 第二步：安装 Serverless Devs 开发者工具；具体的安装方式参考文档：
https://help.aliyun.com/document_detail/195474.html； 

 
   
   
 

  
    
    
  
     
   
  •  
  

  
    
    
  
$ npminstall @serverless-devs/s -g
  • 第三步：可以通过 s -v 判断工具是否安装成功，如果安装成功可以看到相对应的版本信息，例如： 


@serverless-devs/s:2.0.89, @serverless-devs/core: 0.1.7, darwinarwin-x64, node-v12.15.0
02



配置密钥

Cloud Native

1
 获取密钥


配置 Serverless Devs 的阿里云密钥，一般需要密钥信息，获取页面为：
https://usercenter.console.aliyun.com/#/manage/ak

  • AccessKeyID：用户的 AK 信息
    AccessKeySecret：用户的 SK 信息

关于密钥信息的获取流程如下：打开获取密钥页面（ https://usercenter.console.aliyun.com/#/manage/ak ），并获取密钥信息 ：

即学即会 Serverless | Serverless Devs 基础入门


2
 引导式密钥配置


通过引导式进行密钥配置：可以通过 s config add 命令，进行引导式创建：

执行 s config add，并选择 Alibaba Cloud (alibaba)： 

$ s config add? Please select a template: Alibaba Cloud(alibaba)🧭Refer to the document for alibaba key: http://config.devsapp.net/account/alibaba? AccountID ()
此时，可以按照引导，进行密钥的配置： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
  

  
    
    
  
? Please select a template: Alibaba Cloud(alibaba)🧭Refer to the document for alibaba key: http://config.devsapp.net/account/alibaba? AccessKeyID 此处填写AccessKeyID? AccessKeySecret 此处填写AccessKeySecret? Please create alias for key pair. Ifnot, please enter to skip alibaba-access
 Alias: alibaba-access AccountID:此处填写AccountID AccessKeyID: 此处填写AccessKeyID AccessKeySecret: 此处填写AccessKeySecret
Configuration successful
为了验证密钥是否正确配置，可以通过 s config get -a alibaba-access 进行指定密钥的查看： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
  

  
    
    
  
$ s config get -a alibaba-accessalibaba-access: AccountID: 此处填*******tID AccessKeyID: 此处填*********yID AccessKeySecret: 此处填*************ret
致此，通过引导式，我们完成了密钥配置信息。
3
 命令式密钥配置


为了在一些自动化流程中可以更好的使用 Serverless Devs，所以除了通过引导式进行密钥的配置， Serverless Devs 还支持通过命令行非交互式进行密钥的配置。


同样以阿里云密钥配置为例，可以直接通过参数将密钥信息传入： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
  

  
    
    
  
$ s configadd --AccessKeyID myAccessKeyID --AccessKeySecret myAccessKeySecret -a demo

Alias: demoAccountID: myAccountIDAccessKeyID: myAccessKeyIDAccessKeySecret: myAccessKeySecret
Configurationsuccessful
如果需要配置更多格式的密钥信息，可以通过自定义 Key-Value 实现，例如： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
  

  
    
    
  
$ s config add--AccessKeyID ****** -kl key1,key2,key3 -il info1,info2,info3 -a demo-2
Alias: demo-2key1: info1key2: info2key3: info3AccessKeyID: code
Configurationsuccessful
4
 通过环境变量配置


有相当一部分的开发者会将密钥信息放在环境变量中，这样在使用工具的时候，就需要从环境变量中读取密钥信息，此时，通过环境变量配置密钥的方法就显得尤为重要，为此，Serverless Devs 提供了两种通过环境变量配置密钥的方法：


  • 方法 1: 直接通过 config add 进行配置


这种方法很简单，基本和上面所描述的命令式密钥配置是类似的，只不过传入的不是固定值，而是环境变量，例如在环境变量中有 ALIBABA_CLOUD_ACCESS_KEY_ID、ALIBABA_CLOUD_ACCESS_KEY_SECRET 等相关内容，此时可以通过 s configadd 命令进行添加： 
 
   
   
 

  
    
    
  

 
   
   
 
$ s config add -adefault-aliyun -kl AccessKeyID,AccessKeySecret -il${ALIBABA_CLOUD_ACCESS_KEY_ID},${ALIBABA_CLOUD_ACCESS_KEY_SECRET}


  • 方法 2: 通过指定名称使用环境变量密钥

通过指定环境变量的名字进行配置：例如当前有阿里云密钥对： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
  

  
    
    
  
AccountID:temp_accountidAccessKeyID:temp_accesskeyidAccessKeySecret:temp_accesskeysecret
此时可以在环境变量中可以命名 key 为*********_serverless_devs_access，例如 default_serverless_devs_access，value 为 JSON 字符串，例如： 

Key：default_serverless_devs_accessValue：{\"AccessKeyID\":\"temp_accesskeyid\",\"AccessKeySecret\":\"temp_accesskeysecret\"}
03



密钥使用的注意事项

Cloud Native

1
 安全相关


云账号 AccessKey 是您访问阿里云 API 的密钥，具有该账户完全的权限，请您务必妥善保管！不要通过任何方式（e.g. Github）将 AccessKey 公开到外部渠道，以避免被他人利用而造成安全威胁 。强烈建议开发者遵循阿里云安全最佳实践 ，使用 RAM 子用户 AccessKey 来进行 API 调用。


2
 关于密钥配置中 Alias 的设计思路


在 Serverless Devs 中，除了配置云厂商所提供的密钥信息之外，还需要额外进行 Alias 的设置，这里所谓的 Alias 是指对密钥进行的别名设置。由于 Serverless Devs 支持多密钥的配置和管理，所以一般情况下，一个别名对应一个密钥对。相关的最佳实践可以是：


  • 有两个账号，分别是阿里云账号和腾讯云账号，那么配置密钥的时候就可以设置别名 alibaba、tencent，在使用的时候，通过引用不同别名使用不同的密钥，以防止每次切换密钥的时候，进行密钥重新配置；
  • 自己拥有两个环境的密钥，一个是测试环境密钥 test，一个是线上环境密钥 release，当开发完成之后需要把业务部署到不同的环境下，可以通过指定密钥的形式，直接进行部署，而无需因为密钥的切换反复进行密钥的重新配置；

3
 密钥使用方法


在 Serverless Devs 中，密钥的使用主要在两个层面：


  • 命令行层面： 在命令行中使用的时候，可以直接通过-a/--access 参数进行使用，例如在部署某业务的时候，可以通过 s deploy-a demo 指定使用 demo 密钥对；
  • Yaml 配置文件层面： 可以通过在 Yaml 中进行密钥对的指定，例如：

即学即会 Serverless | Serverless Devs 基础入门

在 Yaml 的中直接指定access，表示整个应用都通过当前密钥对进行部署，也可以在某个模块/业务下指定当前模块/业务使用某指定的密钥对进行部署。


4
 密钥使用顺序相关


密钥支持多种形式的使用，也就会出现密钥的使用的顺序问题：

  • 通过-a/--access 参数指定的密钥信息
  • 使用已经配置的 default 密钥信息
  • 使用通过环境变量配置的``default_serverless_devs_access`密钥信息
  • 不使用密钥信息 / 进入密钥信息配置引导


具体的流程图为：

即学即会 Serverless | Serverless Devs 基础入门

Tips 密钥的其他相关操作


在 Serverless Devs 中，除了配置密钥之外还包括密钥的修改、删除和查看，此时可以通过 s config -h 进行相关功能的查看：

  • 密钥的查看，可以通过 s config get -h 查看帮助
  • 密钥的修改，可以重新进行指定别名的密钥的创建，并通过-f 参数，强行覆盖；
  • 密钥的删除，可以通过 s config delete-h 查看帮助

04

Yaml 的使用规范

Cloud Native


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。


1
 描述文件格式/规范


关于 Serverless Devs 所支持的资源/行为描述文件基本格式为： 

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}

2
 元数据相关描述


在该格式中：

即学即会 Serverless | Serverless Devs 基础入门
关于 Service 参数：

即学即会 Serverless | Serverless Devs 基础入门


3
 变量赋值


Serverless Devs 的 Yaml 文件支持多种变量格式：


  • 获取当前机器中的环境变量：${env(环境变量)}，例如 ${env(secretId)}
  • 获取外部文档的变量：${file(路径)}，例如 ${file(./path)}
  • 获取全局变量：${vars.*}
  • 获取其他项目的变量：${projectName.props.*}
  • 获取 Yaml 中其他项目的结果变量：${projectName.output.*}


4
 服务顺序


如果一个 Serverless App lication 模型对应的 Yaml 文件中有过多的服务，系统会默认分析部署顺序，该部署顺序分为两个步骤：


  1. 分析项目中的依赖关系
  2. 有依赖关系的按照依赖关系从前到后部署，无依赖关系的按Yaml配置的从上到下部署
5
 行为描述


在 Serverless App lication 模型对应的 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
当 Serverless Devs 开发者工具执行到该服务时，会在进行相关的命令之行之前，优先按照顺序执行 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

以上顺序仅适用于整个流程没有出错的前提下，如果流程出现错误，系统将会进行报错，并终止后续流程的执行。


6
 通过命令操作应用


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


例如，某应用的资源/行为描述文件如下： 

 
   
   
 

  
    
    
  
     
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
   
  •  
  

  
    
    
  
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 组件支持的自定义命令为：


即学即会 Serverless | Serverless Devs 基础入门


则可以通过自定义命令实现应用级操作和服务级操作。

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；

7
 多种操作模式下的工具体系


众所周之，目前大部分的 Serverless 开发者工具均是通过 Yaml 等进行资源描述，少部分的 Serverless 开发者工具是通过命令行直接操作，无论是通过 Yaml 进行资源描述，还是通过纯命令行的操作，可以说两者各有各的好处。而在 Serverless Devs 开发者工具中，这两者均得以有效的支持。


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 文件进行读取。


但是，在某些情况下，并不方便直接使用 Serverless Devs 规范的 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 进行资源描述会相对来说更简单和方便，例如 Kubernetes 等也都是通过 Yaml 进行资源描述的；但是，在某些情况下，Yaml 文件也可能成为一种负担，例如想要查看某个服务下的函数列表，查看某个地区下的服务列表，因为这样一个简单的事情要额外的去完成一个 Yaml 文件，就显得过于臃肿，所以，在 Serverless Devs 项目中，同时保留了两种使用方法。

05

附录

Cloud Native


[1] 社区官网

http://www.serverless-devs.com/

[2] 桌面客户端

https://serverlessdevs.resume.net.cn/zh-cn/desktop/index.html


[3] Serverless 应用开发者套件

http://serverless-dk.oss.devsapp.net/docs/tutorial-dk/intro/react


[4] Serverless Devs CLI

https://serverlessdevs.resume.net.cn/zh-cn/cli/index.html


[5] Serverless Hub 应用中心

https://serverlesshub.resume.net.cn/#/hubs/special-view



近期热门

HOT TOPIC

# 极速上手 Serverless#

为了让开发者快速定位 Serverless 开发问题，找到对应解决办法，阿里云云原生 Serverless 团队，发布 2022 全新版本《Serverless 开发速查手册》，目前已开放下载，我们希望给 Serverless 开发者提供一本能够速查、速懂的工具书，实实在在帮助开发者快速解决 Serverless 开发遇到的实际问题，让大家能够踏踏实实享受 Serverless 带来的技术红利！后台回复 手册 即可下载阅读。



往期推荐







点击 阅读原文 ， 了解 Serverless Devs 官网更多资讯！

推荐阅读

真女神转生5：复仇 正式版替换包 试玩版游玩完整游戏方法 真女神转生5：复仇 正式版替换包 试玩版游玩完整游戏方法
中小企业如何来思考Cloud native 中小企业如何来思考Cloud native

相关文章