lowkeyrd comments

Results 14 comments of


                                            lowkeyrd

access支持设置region

> 1. access是一个全局的配置，region放在access语义也不太妥当。region一般是跟随项目来的。可以这样做哈 > > ``` > edition: 1.0.0 > access: 'default' > vars: > region: cn-hangzhou > > services: > website-starter: > component: apigateway > props: > bucket: 'aidankun'...

access支持设置region

放到环境变量里是可以的，我的意思是region同ak/sk一样应该是系统的关键字，放到access中可以更方便用户进行cicd。因为测试、生产环境往往使用的是不同的子账号，所以连同region一起放到testing.access、production.access，使用不同的access就能进行环境级的隔离了。我的proposal： 1. access增加region属性，默认传递到组件中 2. 如果env中指定了region，则覆盖access的这样region可以结合access和env使用，满足多种场景

S yaml 命令讨论

> s yaml config ==> s edit s yaml check ==> s verify 理由： 1. 没必要增加yaml参数，直接用edit和verify表达更直接，除非之后打算提供json格式。另外如果要提供yaml和json两种模式，应该用s edit --output=yaml/json 2. 没必要单独check yaml格式，这个意义不大。s verify表示check 用户配置是否跟schema要求一致

Serverless Devs 需要增加 `cloud` 操作模式

### 分析我们可以先把云端部署的定义明确下：我理解的就是本地完成构建后触发云厂商自己的Pipeline完成整个CD过程。这不光是利用云厂商的计算资源完成s deploy，还可能是利用云服务去完成应用托管。这个场景太多样了，很难抽出通用的模式，举几个例子： 1. 阿里云：目的是将本地工程托管到应用中心，组件要和应用中心的OpenApi交互，组件仅需要完成代码构建和打包，上传功能应该交由OpenApi来完成(应用中心自己将代码上传到OSS，类似FC)。组件不可能把代码包上传到应用中心的OSS上，只能上传到用户自己的，但是要用户提供OSS这个条件太苛刻了。另外部署时，还需要指定应用名 3. AWS：触发CodePipeline执行CodeBuild以及CodeDeploy 4. 华为云、百度云：没有类似的应用中心产品，只能触发自己的CI/CD流水线 ### 再试着给出几种模式的区别本地部署：代码包直接上传到Serverless平台，完成函数的部署云端部署：本地编译CI，云服务进行CD CI/CD：触发云服务的CI/CD Pipeline，由云服务完成s build && s deploy ### Proposal 从这个边界来看，云端部署不是一个通用的模式，基本是云厂商根据自身产品特点量身定制的，所以我的建议是这个cloud命令还是放到云厂商的部署组件内(**做成一个插件甚至更好**)，单独抽出一个组件会让流程非常复杂，要考虑和已有部署组件能力的结合

生态规范兼容

这个命令的行为预期是什么？我理解的兼容生态，不是单纯的命令兼容，举两个例子： 1. 兼容K8s生态：是要把 S 进行K8s controller化，这样用户可以通过kubectl 直接apply 一个 S 的CR出去。用户交互的不再是s.yaml，而是一个K8s的CRD，基于GitOps + Kustomize能够很好的把这些yaml管理起来 2. 兼容Terraform生态：是用户上传一个Terraform的HCL文件或者指定一个Terraform Module源，S能够自动生成相应的组件，这样在 S 里可以直接通过Terraform来编排云资源，用于后续的操作这两个生态是有一些差异的： 1. K8s的生态是围绕CRD建立的，可以很容易扩展出一个服务化的能力，所以融入K8s是要把S 变成一个Controller，用户用的是kubectl 2. Terraform的生态是围绕Terraform这个工具本身的，扩展的都是其Provider和Module，所以融入Terraform是要把其变成S的一个组件，用户用的还是S

封装完整的发布能力

这个功能一个很大的意义，在于应用中心进行CI/CD时，具备灰度发布的能力，这点我们应该做出来

关于fc组件service字段问题讨论

service独立出来是有很多好处的： 1. service的变更是比较小的，特别是在多人协同开发的时候，service的权限范围跟function是不太一样的。开发人员甚至都不应该具有变更service的权限 2. service独立出一个组件，可以把版本、别名的操作都以声明式进行描述，流水线可以单独操作service进行版本发布。service和function是完全不同的关注点，fc组件的version、alias命令跟function是完全无关的 3. service和function耦合，如何解决回滚的问题？如果我有多个函数关联相同的service，那应该操作哪个devs service进行回滚呢？ 4. service和function耦合，这个设计本身已经受到很多挑战了，通过工具是可以把这个问题化解的，因为工具有组件间依赖编排的能力。