# vela cli

## Workload 的分类

$ vela init // 一个单组件应用的快捷入口，未来可以进化成为 app template（引入一个新的 OAM 对象）功能

  What would you like to name your application? [? for help] demo
  
  Which workload type best represents your service's architecture? [? for help]
  > Web Service
  Backend Worker
  One-off Task // 未来再做一个 Cron Trait 配合这个使用

  Serverless Container // 未来
  
  // 以下问题，先暂时写死。输入 ? 直接打开帮助网站。
  What would you like to name your Public Service? [? for help] frontend
  
  // domain scope
  What is your preferred domain for frontend [? for help] (on-oam.io) alibaba-inc.com
  
  What container image would you like to use for frontend? [? for help] nginx
  
  // 不需要 expose trait，这个能力作为 workload 的一部分（见后面 -p 80 的例子）
  Which port do you want customer traffic sent to? [? for help] (80)
  
  // scale trait
  How many instances do you want to run for frontend? [? for help] (1) 10
  
  Do you want to enable in-place update? [? for help] (n/Y)
  
  // 未来：Do you want to add more services to demo?

### 这个工作负载的实现可以考虑“多态 ContainerizedWorkload”：

Web Service 和 Backend Worker 背后的实现是完全一样的，只是 workload type label 不同。Inplace 作为 Component CR 上的一个 annotation （它会 propagate 到 worklaod）用来选择是否最终生成 CloneSet

## 如果借鉴 AWS Copilot 的话

$ vela app init -n demo --domain alibaba-inc.com
// 创建一个空应用

$ vela svc init -t webservice -i nginx -p 80 -n frontend
// 创建一个组件，80 端口自动创建 K8s Service，创建规则见：https://github.com/oam-dev/catalog/issues/53

> 这个命令等价于：vela run --staging

$ vela svc deploy frontend

整体来看，Copilot 是我们要透出多组件应用的最佳流程，并且相比之下，Heroku 风格输入冒号有点费劲。

它的不好处：
- 必须 -n/--name，这个设计的原因不是很清楚
- svc 必须先 init 再 deploy
- 这个问题可以把下面这个作为主要命令，把 init 当做 --staging 用，配合 deploy：

  $ vela svc run -t webservice -i nginx -p 80 -n frontend

## 关于 Traffic Split

$ vela svc init -t webservice -i nginx:1.7.9 -p 80 -n frontend

$ vela svc show frontend --revisions
SERVICE
frontend

INSTANCE        REVISION   
frontend-x89a0v v1       
frontend-809v2z v2,latest

$ vela traffic -n frontend --split v1=90 v2=10

$ vela svc deploy -n frontend # 这个必须的执行，有点麻烦

OAM Runtime 还是把 v1,v2 这样面向用户的索引建立出来比较好，方便 cli/dashboard 去用。
注意：用 SMI 做的话，流量这边首先需要每个 revision 的 workload instance 都需要有一个 Service 挂 TrafficSplit，然后还需要一个Component 对应的 Service 作为访问入口（跟 domain 是对应的）

## 关于 logs 和 status 命令：

$ vela svc logs -n frontend // 为什么 AWS 一定要有 -n 参数？
$ vela logs -n frontend // short cut

logs 和 status 作为一级命令挺好，因为他们本身都还可以做成 traits 能力