【Serverless Devs 3.0】工具链升级探索讨论

[anycodes]

背景

随着时间发展，Serverless Devs 从诞生至今已经走过了三年的时间，三年期间，我们收获到了很多小伙伴们的支持和反馈，我们也在不断努力的自我批评，自我探索：什么样的工具才是一个好用的工具，什么样的工具才是 Serverless 领域好用的工具。

在做 Serverless Devs 之前，自己一直想要做一个具有足够灵活度又有足够好体验的开发者工具，但是往往这两者又回存在“一定的矛盾”，在过去的三年时间，我们也逐渐的认识到现有版本的不足：

1. 部署逻辑存在缺陷：
   • 对待同一份工程，部署到不同项目，会存在重复打包、构建、上传的操作；虽然有全局 Action 做一些优化，但是不够优雅；
   • 大量函数部署时，缺少足够的编排能力，纯粹的串行严重影响效率；
   • Yaml 中的 services 概念不清不白，尤其和部分云厂商的概念比较冲突，难以理解；
2. 虽然 Serverless CD 还有 Serverless 应用中心基于 Serverless Devs 实现，但是两者还是非常割裂，需要有更多联动能力；
3. 应用通用功能/通用能力抽象不足；
4. .....

所以在2023年，打算联合社区一起对 Serverless Devs 进行一次大规模升级，即 Serverless Devs 3.0。

设想中，3.0的特点：

1. 更优秀的性能：无论是构建性能还是部署发布性能，都将会得到大规模的提升；
2. 更一致的体验：Serverless 应用中心/Serverless CD 将会与工具进行更为紧密的联动；
3. 对 Yaml 和规范的抽象将会更为科学和规范，提供更多的通用能力和表达能力；

重大变更：

1. 概念变更，取消掉services概念与application概念，替换成project概念和resources概念
2. 范式变更，去掉namesapce与application一对一关系，service与function一对一关系，以资源形势独立部署
3. 新增全局能力，包括全局变量，全局action
4. 加强模板能力

命令

设想中的命令：

🚀  Welcome to the Serverless Devs.

Options
  --debug                             Debug model, print more logs                                      
  --skip-actions                      Skip the actions(global actions and project actions)  
  -t, --template <path>               Specify the template file, default: s.yaml, s.yml
  -a, --access <aliasName>            Specify the access alias name
  -o, --output <outputFormat>         Specify the output format: json, yaml, raw
  -v, --version                       Output the version number
  -h, --help                          Display help for command

Commands
   config                      👤 Configure venders account              
   init                        💞 Initializing a serverless project     
   cli                         🐚 Command line operation without yaml mode
   verify                      🔎 Verify the correctness of Yaml format
   edit                        🙌 Visual editing of Yaml files                     
   set                         🔧 Settings for the tool            
   clean                       💥 Clean up the Serverless Devs environment and  cahce
   component                   🔌 View installed component information
   preview                     👀 Preview Yaml render results
   center                      🙆 Serverless project management platform
   registry                    🚢 Serverless registry platform
   <custom>                    🧭 Custom Commands

Custom Commands：
    Can be used in projects with Serverless Devs Yaml. Usage：
     - s <componentCommand>：Operate on the application, E.x: s deploy
     - s <projectName> <componentCommand>：Operate on the project, E.x: s website deploy

    Build & Deploy
      deploy                      Deploy local resources online   
      build                       Build the dependencies.         
      remove                      The ability to delete resources 

🌟  Github Repo: https://github.com/Serverless-Devs/Serverless-Devs
🌈  More information: https://www.serverless-devs.com
🚀  More applications: https://registry.serverless-devs.com

• config：配置密钥，与现行版本保持一致
• init：初始化项目，与现行版本保持一致
• cli：命令行形式使用，提供新的使用规范；
• verify：部署前的校验，用于校验Yaml格式正确与否，与现行版本保持一致
• edit：可视化编辑，与现行版本保持一致
• set：系统配置，与现行版本保持一致
• clean：清理资源/缓存，与现行版本保持一致
• component：查看已经安装的组件信息，与现行版本保持一致
• preview：查看渲染结果
• center：项目中心
• registry：社区registry

新增命令逻辑：

• preview：查看渲染结果
• center：应用中心
• registry：社区registry

Yaml 更新

# 一个 Yaml 表示一个项目 

# 规范版本，【必填】
edition: 3.0.0/1.0.0

# 基础信息，与项目中心联动，如果无需同步到项目中心，可【选填】
name: project_name               # 项目名称
description: project_description # 项目描述

# 全局密钥，【选填】
access:  密钥信息

# 部署前验证 Yaml 格式，默认执行 s verify，如果失败了默认停止，【选填】
validation: true

# 全局 Action，【选填】
actions: 
  pre-deploy:      # xxx操作之前
      - action
  complete-deploy: # xxx操作完成
      - action
  success-deploy:  # xxx操作成功
      - action
  fail-deploy:     # xxx操作失败
      - component:  组件名 组件命令 组件参数
        allow_failure: true/false # 允许失败条件
      - plugin: 插件名
        args:                     # 插件的参数
          key: value 
        allow_failure: true/false # 允许失败条件
      - run: 运行的命令
        path: 执行命令的路径
        allow_failure:       # 允许失败条件
          exit_code:         # 允许失败/退出code
            - 100
            - 101

# 全局变量，【选填】
vars: 
  key: value

# 可被继承的模板，【选填】
template: 
  demo: 
    name: my-name
    description: my description

# 操作顺序，高级配置【选填】
sort:
    deploy:
        - [project_a]
        - [project_b, project_c]

# 具体的业务模块
resources:
  project_a:
    component: website      # 组件名称
    access: access          # 密钥信息 
    extend: 
       name: demo            # 继承template中的指定key对应的结构，与props内容进行合并
       ignore:     # 忽略的属性
          - name
    actions:                # 行为描述配置
      pre-xxx:              # xxx操作之前
          - action
      complete-xxx:         # xxx操作完成
          - action
      success-xxx:          # xxx操作成功
          - action
      fail-xxx:             # xxx操作失败
          - action
    allow_failure:          # 允许失败条件，可以直接true/false，也可以是具体的结构
      exit_code:            # 允许失败/退出code
        - 100
        - 101
      command:              # 允许失败/退出code
        - deploy
    props:                  # 业务逻辑具体的属性
      key: value
  project_b:
    component: website      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      key_url: ${url(url地址)}
      key_env: ${env(环境变量)}
      key_file: ${file(文件路径)}
      key_file_json: ${json(file(文件路径)).demo}
      key_vars: ${vars.全局变量}
      key_spec: ${projects.project_a.component}
      key_output: ${projects.project_a.output}

以函数计算和应用引擎为例，一个完整的函数配置：

# 规范版本，【必填】
edition: 3.0.0/1.0.0

extend: demo.yaml                    # 模板继承

# 基础信息，与应用中心联动，如果无需同步到应用中心，可【选填】
name: application_name               # 项目名称
description: application_description # 项目描述

# 全局密钥，【选填】
access:  密钥信息

# 部署前验证 Yaml 格式，默认执行 s verify，如果失败了默认停止，【选填】
validation: true

# 全局 Action，【选填】
actions: 
  pre-deploy:      # xxx操作之前
      - component: fc build --use-docker --codeUri ./code
      - plugin: zipCode
        args:
          codeUri: ./code
          targetUri: ./upload.zip

# 全局变量，【选填】
vars: 
  region: cn-hangzhou


# 具体的业务模块
resources:
  service_anycodes:
    component: fc-service      # 组件名称
    props:                     # 业务逻辑具体的属性
      region: ${vars.region}
      name: anycodes
      description: 这是 anycodes service
  service_anyenv:
    component: fc-service      # 组件名称
    props:                     # 业务逻辑具体的属性
      name: anyenv
      description: 这是 anyenv service
      logConfig: auto
  function_server:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anyenv
      name: server
      description: 这是 anyenv server
      runtime: python3.9
      codeUri: ./upload.zip
      handler: index.test
  function_start:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anycodes
      name: start-function
      description: 这是 anycodes start_function
      runtime: python3.9
      codeUri: ./upload.zip
      handler: index.demo
  function_callback:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anycodes
      name: oss-callback
      description: 这是 anycodes start_function
      runtime: custom
      codeUri: ./oss_code
  test:
    component: sae-ns      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      name: oss-callback
  backend:
    component: sae-application      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      namespace:  oss-callback
      name: oss-callback

如何配置应用中心？
新增插件，通过插件上报到应用中心，例如：
plugin: alibaba-project-center
muti_env: # 项目环境
name: env_name # 项目环境名称
type: dev/test/prod # 项目环境类别

顺序逻辑

命令行配置 > Yaml Project 配置 > Yaml 全局配置 > 全局配置 > 环境变量配置 > 默认配置

[rsonghuster]

1. 全局 action 那块有点奇怪， 是不是这样更好? 从程序员的角度来看， 我觉的这样优雅点

actions: 
  pre-deploy:      # xxx操作之前
      - action
  post-deploy: # xxx操作完成
      - action
      - onSuccess:  # xxx操作成功
          - action
      - onFailure:     # xxx操作失败
          - component:  组件名 组件命令 组件参数
             allow_failure: true/false # 允许失败条件
          - plugin: 插件名
             args:                     # 插件的参数
             key: value 
             allow_failure: true/false # 允许失败条件
          - run: 运行的命令
            path: 执行命令的路径
            allow_failure:       # 允许失败条件
            exit_code:         # 允许失败/退出code
               - 100
               - 101

2. plan 指令能不能从 s 层面依赖 tf 上去支持？ 依赖组件自己去支持， 不可持续
3. projects 感觉有点奇怪，既然这个yaml 文件表示一个 application，下面的内容应该是一个个目标或者任务的集合， 我个人觉的使用 Object 或者 Task 可能比较好，你 s xxx deploy 部署某个函数，对应部署 application 中的一个 object 或者 task

[anycodes]

未来部署一个应用到函数计算可能是这样的 Yaml：

# 规范版本，【必填】
edition: 3.0.0/1.0.0

extend: demo.yaml                    # 模板继承

# 基础信息，与应用中心联动，如果无需同步到应用中心，可【选填】
name: application_name               # 应用名称
description: application_description # 应用描述
muti_env:                            # 应用环境
  name: env_name                     # 应用环境名称
  type: dev/test/prod                # 应用环境类别

# 全局密钥，【选填】
access:  密钥信息

# 部署前验证 Yaml 格式，默认执行 s verify，如果失败了默认停止，【选填】
validation: true

# 全局 Action，【选填】
actions: 
  pre-deploy:      # xxx操作之前
      - component: fc build --use-docker --codeUri ./code
      - plugin: zipCode
        args:
          codeUri: ./code
          targetUri: ./upload.zip

# 全局变量，【选填】
vars: 
  region: cn-hangzhou


# 具体的业务模块
projects:
  service_anycodes:
    component: fc-service      # 组件名称
    props:                     # 业务逻辑具体的属性
      region: ${vars.region}
      name: anycodes
      description: 这是 anycodes service
  service_anyenv:
    component: fc-service      # 组件名称
    props:                     # 业务逻辑具体的属性
      name: anyenv
      description: 这是 anyenv service
      logConfig: auto
  function_server:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anyenv
      name: server
      description: 这是 anyenv server
      runtime: python3.9
      codeUri: ./upload.zip
      handler: index.test
  function_start:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anycodes
      name: start-function
      description: 这是 anycodes start_function
      runtime: python3.9
      codeUri: ./upload.zip
      handler: index.demo
  function_callback:
    component: fc-function      # 组件名称
    props:                  # 业务逻辑具体的属性，外部的变量用()获取，呢不的变量用.获取，增加json参数，可以将外部字符串变为json格式
      region: ${vars.region}
      serviceName: anycodes
      name: oss-callback
      description: 这是 anycodes start_function
      runtime: custom
      codeUri: ./oss_code

整体：

1. 上面的例子是两个服务，三个函数的例子；
2. 其中有两个函数共用了一个代码，只是不同的入口，所以会做统一的依赖安装和打包；
3. 阿里云函数计算fc服务和函数配置可以解耦（兼容性变更），防止一个服务下多个函数部署时，服务被多次部署；
4. 服务开启了部署前的校验，如果yaml格式错误，部署前会自动终止；
5. 部署后，应用可以在线上的应用中心查看到；

[rsonghuster]

这里做一个补充，对于 code 不变， zip 文件的 md5 值需要不要发生改变， 从而 deploy 的时候可以自动 filter code 或者 layer 部署， 这个是最影响部署速度的， 而且部署的非常没有意义， codechecksum 发生变化， 其实函数代码根本没有发生变化

[wuyeguangming]

这个建议很实用

阿里云函数计算fc服务和函数配置可以解耦（兼容性变更），防止一个服务下多个函数部署时，服务被多次部署；

[heimanba]

name 的字段代表是应用中心的名称，这个字段是否是必填？因为有些应用在本地无需 和cloud应用中心对应上

[anycodes]

如果上报应用中心，这个字段必填，如果不上报这个选填。这个上报有一个全局开关

[heimanba]

s center作为全局指令，代表和应用中心关联，这里的应用中心包括下面几个

• fc控制台的应用中心，他的身份是aliyun account
• Serverless Devs应用中心，这里他的身份是 应用中心的身份，
• 如果是用户使用开源自建的应用中心，这里他的身份也是 应用中心的身份

这里主要在本地和应用中心感知的基础信息是 用户的身份以及感知的EndPoint，所以 s center这个指令的会不会有些子指令来满足这样的需求呢?

[anycodes]

有子指令对应。包括开启是否上报的能力，配置endpoint，选择开源中心类型

[heimanba]

这里的 子指令，是准备做成内置的子指令吗，还是动态指令呢（类似 s cli fc xx）

[anycodes]

内置。
例如：s center login

[hanxie-crypto]

规范中 涉及全局的内容有vars, actions, access, 考虑是否统一收敛到类似 global的属性中，整体规范从顶层设计上收敛为基础信息, 全局引用 以及 project（或者application）,另外本次设计希望引入全局插件， 用来处理全局状态设置以及安全层面的问题。

[lowkeyrd]

# 全局 Action倾向如下描述
# 先聚焦到action行为，而不是具体条件，这样一个action更容易被复用
actions: 
  - run: make clean
    phases:
      - pre-deploy
  - component: fc alias publish
    phases:
      - success-deploy
  - plugin: dingTalkNotify
    args: xxx
    phases:
      - pre-deploy
      - success-deploy
      - fail-deploy
   

[lowkeyrd]

直接透出应用中心特性不太合适，破坏了no-vendor-lock-in原则。可以考虑两个思路

1. 增加remote字段，用于适配云厂商或者自建应用管理平台

remote:
  backend: alicloud/serverless #阿里云应用中心
  args:
    name: application_name               # 应用名称
    description: application_description # 应用描述
    environment:                         # 应用环境
      name: env_name                     # 应用环境名称
      type: dev/test/prod                # 应用环境类别

2. 将应用中心的特性封装成plugin，挪到action中

[anycodes]

应用中心，将会对标开源。

[QWQyyy]

我的idea是能不能实现一个接口，可以实时的在不同的无感计算框架之间切换，就比如一个应用的前几个函数在阿里云计算，后面的函数都在华为云上计算，实现函数粒度的最优化。

[heimanba]

Serverless-Devs 2.0还有个痛点就是大家用的都是deploy的能力， 像层(layer)的管理，灰度发布，实例登录，日志查询， 等都是偏命令式的操作。期望是以 可视化的方式进行管理。

[QWQyyy]

是的，可视化是一个很大的工程

[iugo]

我们在使用阿里云函数计算应用时遇到问题, 但不知道是否是 Serverless Devs 造成的.

问题是: 在 actions->pre-deploy 中, run: export TEST=1 后, run: echo $TEST 无法得到预期值.

[heimanba]

这个问题是因为每个 run 指令 本身是一个单独进程，如果您需要使用环境变量，建议先 export 到系统本地。在执行s deploy。比如上面的case可以这样来work

s.yaml配置

actions:  
      pre-deploy: # 在deploy之前运行
        - run: echo ${env.TEST}
          path: ./src 

export export TEST=1 && s deploy, 或者您可以在项目目录下建立 .env文件。${env.xx} 不但会读取系统的环境变量还会读取和s.yaml平级的.env文件内容作为环境变量。

当然您的使用方式是绝大部分开发者的习惯。以及记录ISSUE在跟踪哈：#665

[JasonLamv-t]

我有个问题，现在的 repo 跟功能太多难以管理了，我一段时间不接触之后感觉很难再参与进来了

[DevDengChao]

我这边还发现了另外两个问题.

1. s 大规模的使用 esbuild 来打包, 导致开发者在调试下游的组件时难以参考 node_modules 里上游组件的源码.
2. 发布到 npm 上的组件经常缺少仓库地址, 或者仓库地址是错的, 导致根据包来反向找仓库很麻烦, 进一步加大了参考上游组件源码的难度.

例如:

• https://www.npmjs.com/package/@serverless-devs/utils 在 npm 上就没有声明仓库地址
  
• https://www.npmjs.com/package/@serverless-devs/credentials 的仓库地址甚至写的是 https://github.com/aliyun/credentials-nodejs
  

[heimanba]

第二个问题，我们集中排查下哈

[DevDengChao]

第一个呢 =-=?

[heimanba]

使用Esbuild压缩，主要是S工具加载和依赖比较多。因为要做本地寻址，所以执行s命令启动速度非常慢。能感受到非常明显的延时。当然FC组件调试的时候一个麻烦点就是 组件拆分的比较细。在V3版本只会通过存在一个FC组件。其他的fc-deploy，都会收敛到FC代码中。这样调试就会顺畅不少。

[DevDengChao]

是否考虑用其他编程语言开发 s v3 ? Rust ? Go ?

[heimanba]

暂时没有计划哈 发自我的iPhone

…

------------------ 原始邮件 ------------------ 发件人: 邓超 ***@***.***> 发送时间: 2023年8月18日 16:47 收件人: Serverless-Devs/Serverless-Devs ***@***.***> 抄送: mamba ***@***.***>, Comment ***@***.***> 主题: Re: [Serverless-Devs/Serverless-Devs] 【Serverless Devs 3.0】工具链升级探索讨论 (Discussion #651) 是否考虑用其他编程语言开发 s v3 ? Rust ? Go ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>