kubevela
/
kubevela.github.io
mirror of https://github.com/kubevela/kubevela.github.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Docs: version control (#603) 

Signed-off-by: Yin Da <yd219913@alibaba-inc.com>
This commit is contained in:
Somefive 2022-04-14 17:42:28 +08:00 committed by GitHub
parent 6a76923f7e
commit 59661d5ae3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 778 additions and 686 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

370
docs/end-user/version-control.md
View File

@ -1,208 +1,228 @@
---
title: Revisioning
title: Version Control
---
## Component Revision
## Introduction
You can specify a generated component instance revision with field `spec.components[*].externalRevision` in Application like below:
![overall-arch](../resources/application-revision-arch.jpg)
In KubeVela, ApplicationRevision keeps the snapshot of the application and all its runtime dependencies such as ComponentDefinition, external Policy or referred objects.
This revision can be used to review the application changes and rollback to past configurations.
In KubeVela v1.3, for application which uses the `PublishVersion` feature, we support viewing the history revisions, checking the differences across revisions, rolling back to the latest succeeded revision and re-publishing past revisions.
For application with the `app.oam.dev/publishVersion` annotation, the workflow runs are strictly controlled.
The annotation, which is noted as *publishVersion* in the following paragraphs, is used to identify a static version of the application and its dependencies.
When the annotation is updated to a new value, the application will generate a new revision no matter if the application spec or the dependencies are changed.
It will then trigger a fresh new run of workflow after terminating the previous run.
During the running of workflow, all related data are retrieved from the ApplicationRevision, which means the changes to the application spec or the dependencies will not take effects until a newer `publishVerison` is annotated.
## Use Guide
Fo example, let's start with an application with external workflow and policies to deploy podinfo in managed clusters.
> For external workflow and policies, please refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for more details.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
name: podinfo
namespace: examples
annotations:
app.oam.dev/publishVersion: alpha1
spec:
components:
- name: express-server
- name: podinfo
type: webservice
externalRevision: express-server-v1
properties:
image: stefanprodan/podinfo:4.0.3
```
If the field is not specified, it will generated by the name rule `<component-name>-<revision-number>`.
After the Application created, it will generate a ControllerRevision object for each component.
* Get the revision for component instance
```shell
$ kubectl get controllerrevision -l controller.oam.dev/component=express-server
NAME CONTROLLER REVISION AGE
express-server-v1 application.core.oam.dev/myapp 1 2m40s
express-server-v2 application.core.oam.dev/myapp 2 2m12s
```
You can specify the component revision for [component rolling update](./traits/rollout).
## Application Revision
When updating an application entity except workflow, KubeVela will create a new revision as a snapshot for this change.
```shell
$ kubectl get apprev -l app.oam.dev/name=myapp
NAME AGE
myapp-v1 54m
myapp-v2 53m
myapp-v3 18s
```
You can get all the information related with the application in the application revision, including the application spec,
and all related definitions.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ApplicationRevision
image: stefanprodan/podinfo:6.0.1
workflow:
ref: make-release-in-hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
labels:
app.oam.dev/app-revision-hash: a74b4a514ba2fc08
app.oam.dev/name: myapp
name: myapp-v3
namespace: default
...
spec:
application:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
...
spec:
components:
- name: express-server
properties:
image: stefanprodan/podinfo:5.0.3
type: webservice@v1
...
componentDefinitions:
webservice:
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webservice
namespace: vela-system
...
spec:
schematic:
cue:
...
traitDefinitions:
...
```
## Live-Diff the `Application`
Live-diff helps you to have a preview of what would change if you're going to upgrade an application without making any changes
to the living cluster.
This feature is extremely useful for serious production deployment, and make the upgrade under control
It basically generates a diff between the specific revision of running instance and the local candidate application.
The result shows the changes (added/modified/removed/no_change) of the application as well as its sub-resources,
such as components and traits.
Assume we're going to upgrade the application like below.
```yaml
# new-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
spec:
name: override-high-availability
namespace: examples
type: override
properties:
components:
- name: express-server
type: webservice@v1
properties:
image: crccheck/hello-world # change the image
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- name: deploy-hangzhou
type: deploy
properties:
policies: ["topology-hangzhou-clusters", "override-high-availability"]
```
Run live-diff like this:
You can check the application status by running `vela status podinfo -n examples` and view all the related real-time resources by `vela status podinfo -n examples --tree --detail`.
```shell
vela live-diff -f new-app.yaml -r myapp-v1
$ vela status podinfo -n examples
vela status podinfo -n examples
About:
Name: podinfo
Namespace: examples
Created at: 2022-04-13 19:32:02 +0800 CST
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:auqaxnbix2
name:deploy-hangzhou
type:deploy
phase:running
message:wait healthy
Services:
- Name: podinfo
Cluster: velad-003 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
- Name: podinfo
Cluster: velad-002 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
$ vela status podinfo -n examples --tree --detail
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
```
`-r` or `--revision` is a flag that specifies the name of a living ApplicationRevision with which you want to compare the updated application.
This application should be successful after a while.
Now if we edit the component image and set it to an invalid value, such as `stefanprodan/podinfo:6.0.xxx`.
The application will not re-run the workflow to make this change take effect automatically.
But the application spec changes, it means the next workflow run will update the deployment image.
`-c` or `--context` is a flag that specifies the number of lines shown around a change. The unchanged lines
which are out of the context of a change will be omitted. It's useful if the diff result contains a lot of unchanged content
while you just want to focus on the changed ones.
<details><summary> Click to view the details of diff result </summary>
### Inspect Changes across Revisions
Now let's run `vela live-diff podinfo -n examples` to check this diff
```bash
---
# Application (myapp) has been modified(*)
---
$ vela live-diff podinfo -n examples
* Application (podinfo) has been modified(*)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
creationTimestamp: null
- finalizers:
- - app.oam.dev/resource-tracker-finalizer
name: myapp
namespace: default
annotations:
app.oam.dev/publishVersion: alpha1
name: podinfo
namespace: examples
spec:
components:
- - externalRevision: express-server-v1
- name: express-server
+ - name: express-server
- name: podinfo
properties:
- image: stefanprodan/podinfo:4.0.3
- type: webservice
+ image: crccheck/hello-world
+ type: webservice@v1
status:
rollout:
batchRollingState: ""
currentBatch: 0
lastTargetAppRevision: ""
rollingState: ""
upgradedReadyReplicas: 0
upgradedReplicas: 0
---
## Component (express-server) has been modified(*)
---
apiVersion: apps/v1
kind: Deployment
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
+ annotations: {}
labels:
app.oam.dev/appRevision: ""
app.oam.dev/component: express-server
app.oam.dev/name: myapp
app.oam.dev/resourceType: WORKLOAD
- workload.oam.dev/type: webservice
+ workload.oam.dev/type: webservice-v1
name: express-server
namespace: default
spec:
selector:
matchLabels:
app.oam.dev/component: express-server
template:
metadata:
labels:
app.oam.dev/component: express-server
app.oam.dev/revision: KUBEVELA_COMPONENT_REVISION_PLACEHOLDER
spec:
containers:
- - image: stefanprodan/podinfo:4.0.3
+ - image: crccheck/hello-world
name: express-server
ports:
- containerPort: 80
- image: stefanprodan/podinfo:6.0.1
+ image: stefanprodan/podinfo:6.0.xxx
type: webservice
workflow:
ref: make-release-in-hangzhou
status: {}
* External Policy (topology-hangzhou-clusters) has no change
* External Policy (override-high-availability) has no change
* External Workflow (make-release-in-hangzhou) has no change
```
</details>
We can see all the changes of the application spec and the dependencies.
Now let's make this change take effects.
There are two ways to make it take effects. You can choose any one of them.
1. Update the `publishVersion` annotation in the application to `alpha2` to trigger the re-run of workflow.
2. Run `vela up podinfo -n examples --publish-version alpha2` to publish the new version.
We will find the application stuck at `runningWorkflow` as the deployment cannot finish the update progress due to the invalid image.
Now we can run `vela revision list podinfo -n examples` to list all the available revisions.
```bash
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 19:32:02 Succeeded 23.7 KiB
podinfo-v2 alpha2 false 44124fb1a5146a4d 2022-04-13 19:46:50 Executing 23.7 KiB
```
### Rollback to Last Successful Revision
Before rolling back, we need to suspend the workflow of the application first. Run `vela workflow suspend podinfo -n examples`.
After the application workflow is suspended, run `vela workflow rollback podinfo -n examples`, the workflow will be rolled back and the application resources will restore to the succeeded state.
```shell
$ vela workflow suspend podinfo -n examples
Successfully suspend workflow: podinfo
$ vela workflow rollback podinfo -n examples
Find succeeded application revision podinfo-v1 (PublishVersion: alpha1) to rollback.
Application spec rollback successfully.
Application status rollback successfully.
Application rollback completed.
Application outdated revision cleaned up.
```
Now if we return back to see all the resources, we will find the resources have been turned back to use the valid image again.
```shell
$ vela status podinfo -n examples --tree --detail --detail-format wide
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
```
### Re-publish a History Revision
> This feature is introduced after v1.3.1.
VelaUX uses database for version record, we also recommend you to use a database instead of relying on Kubernetes etcd for versioning.
Rolling back revision allows you to directly go back to the latest successful state. An alternative way is to re-publish an old revision, which will re-run the workflow but can go back to any revision that is still available.
For example, you might have 2 successful revisions available to use.
```shell
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Executing 23.7 KiB
```
Alternatively, you can directly use `vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1` to re-publish the earliest version. This process will let the application to use the past revision and re-run the whole workflow. A new revision that is totally same with the specified one will be generated.
```shell
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Failed 23.7 KiB
podinfo-v4 beta1 true 65844934c2d07288 2022-04-13 20:46:49 Succeeded 23.7 KiB
```
You can find that the *beta1* version shares the same hash with *alpha1* version.
> By default, application will hold at most 10 revisions. If you want to modify this number, you can set it in the `--application-revision-limit` bootstrap parameter of KubeVela controller.

BIN
docs/resources/application-revision-arch.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 249 KiB

362
i18n/zh/docusaurus-plugin-content-docs/current/end-user/version-control.md
View File

@ -2,202 +2,228 @@
title: 版本管理
---
## 组件版本
## 简介
![overall-arch](../../../../../docs/resources/application-revision-arch.jpg)
在 KubeVela 中，ApplicationRevision 保持了应用在发布时刻的快照，包括所有 Application 的配置以及依赖的外部项（如组件定义、外置策略或是引用对象）。
这个版本可以用来比对应用的变化，并在应用的发布出故障时进行回滚。
在 KubeVela v1.3 中，对于使用 `PublishVersion` 特性的应用，支持浏览历史版本、跨版本配置比对、版本回滚以及版本重新发布。
对于带有 `app.oam.dev/publishVersion` annotation 的应用，工作流的运行会被严格限制在版本快照的范围内。
这个 annotation（在下文中简称为 *publishVersion*），可被用来代表应用的一个静态版本快照。
当这个 annotation 被更新时，应用会为当前的配置和依赖项生成一个静态版本，然后针对这个静态版本触发相应的工作流从头开始运行，已有的工作流会被中止。
在工作流运行的过程中，所有相关数据都会从版本快照中取出，这代表着直到应用的 `publishVersion` 被更新为止，应用配置或依赖项的变化都不会生效。
## 使用指南
我们以一个带有外置工作流和策略的应用为例，该应用将会将 podinfo 服务部署在子集群中。
> 对于外置工作流和策略，请参考 [多集群应用交付](../case-studies/multi-cluster) 以获取更多信息。
你可以通过字段 `spec.components[*].externalRevision` 在 Application 中指定即将生成的组件实例版本名称。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
name: podinfo
namespace: examples
annotations:
app.oam.dev/publishVersion: alpha1
spec:
components:
- name: express-server
- name: podinfo
type: webservice
externalRevision: express-server-v1
properties:
image: stefanprodan/podinfo:4.0.3
```
如果没有主动指定版本名称，会根据规则 `<component-name>-<revision-number>` 自动生成。
应用创建以后，你就可以看到系统中生成了 ControllerRevision 对象来记录组件版本。
* 获取组件实例的版本记录
```shell
$ kubectl get controllerrevision -l controller.oam.dev/component=express-server
NAME CONTROLLER REVISION AGE
express-server-v1 application.core.oam.dev/myapp 1 2m40s
express-server-v2 application.core.oam.dev/myapp 2 2m12s
```
你可以在[灰度发布](./traits/rollout)功能中进一步利用组件实例版本化以后的功能。
## 应用版本
除了工作流字段，应用中的每个字段更新都会生成一个对应的版本快照。
* 查看版本快照
```shell
$ kubectl get apprev -l app.oam.dev/name=myapp
NAME AGE
myapp-v1 54m
myapp-v2 53m
myapp-v3 18s
```
你可以在版本快照中获得应用所关联的所有信息，包括应用的字段以及对应的组件类型、运维能力等。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ApplicationRevision
image: stefanprodan/podinfo:6.0.1
workflow:
ref: make-release-in-hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
labels:
app.oam.dev/app-revision-hash: a74b4a514ba2fc08
app.oam.dev/name: myapp
name: myapp-v3
namespace: default
...
spec:
application:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
...
spec:
components:
- name: express-server
properties:
image: stefanprodan/podinfo:5.0.3
type: webservice@v1
...
componentDefinitions:
webservice:
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webservice
namespace: vela-system
...
spec:
schematic:
cue:
...
traitDefinitions:
...
```
## 应用版本对比
部署前版本对比（Live-diff）功能可以让你不用真的对运行时集群进行操作，在本地预览即将部署的版本和线上版本的差异性，并进行确认。
预览所提供的信息，会包括应用部署计划的新增、修改和移除等信息，同时也包括其中的组件和运维特征的相关信息。
假设你的新应用部署计划如下，包含镜像的变化：
```yaml
# new-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
spec:
name: override-high-availability
namespace: examples
type: override
properties:
components:
- name: express-server
type: webservice@v1
properties:
image: crccheck/hello-world # 变更镜像
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- name: deploy-hangzhou
type: deploy
properties:
policies: ["topology-hangzhou-clusters", "override-high-availability"]
```
然后运行 `版本对比` 功能，使用如下命令：
你可以运行 `vela status podinfo -n examples` 来查看应用的部署状态，也可以运行 `vela status podinfo -n examples --tree --detail` 来查看所有相关资源的实时状态。
```shell
vela live-diff -f new-app.yaml -r vela-app-v1
$ vela status podinfo -n examples
vela status podinfo -n examples
About:
Name: podinfo
Namespace: examples
Created at: 2022-04-13 19:32:02 +0800 CST
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:auqaxnbix2
name:deploy-hangzhou
type:deploy
phase:running
message:wait healthy
Services:
- Name: podinfo
Cluster: velad-003 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
- Name: podinfo
Cluster: velad-002 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
$ vela status podinfo -n examples --tree --detail
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
```
* 通过 `-r` 或 `--revision` 参数，指定要比较的版本名称。
* 通过 `-c` 或 `--context` 指定对比差异的上下文行数。
这个应用会在一段时间后进入正常运行的状态。
现在我们修改组件的镜像，并把它设置成一个不合法的镜像，如 `stefanprodan/podinfo:6.0.xxx`。
因为 `publishVersion` 的存在，这个应用不会自动地重新运行工作流。
但由于应用的配置发生了变化，这意味着下一次工作流的运行会更新部署的 Deployment 的镜像。
通过 `vela live-diff -h` 查看更多参数用法。
### 查看版本变化
<details><summary> 点击查看对比结果 </summary>
现在，应用正在运行的版本和当前环境中应用的配置（也就是下一次要运行的配置）产生了差异，我们可以运行 `vela live-diff podinfo -n examples` 来查看这一变化。
```bash
---
# Application (myapp) has been modified(*)
---
$ vela live-diff podinfo -n examples
* Application (podinfo) has been modified(*)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
creationTimestamp: null
- finalizers:
- - app.oam.dev/resource-tracker-finalizer
name: myapp
namespace: default
annotations:
app.oam.dev/publishVersion: alpha1
name: podinfo
namespace: examples
spec:
components:
- - externalRevision: express-server-v1
- name: express-server
+ - name: express-server
- name: podinfo
properties:
- image: stefanprodan/podinfo:4.0.3
- type: webservice
+ image: crccheck/hello-world
+ type: webservice@v1
status:
rollout:
batchRollingState: ""
currentBatch: 0
lastTargetAppRevision: ""
rollingState: ""
upgradedReadyReplicas: 0
upgradedReplicas: 0
---
## Component (express-server) has been modified(*)
---
apiVersion: apps/v1
kind: Deployment
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
+ annotations: {}
labels:
app.oam.dev/appRevision: ""
app.oam.dev/component: express-server
app.oam.dev/name: myapp
app.oam.dev/resourceType: WORKLOAD
- workload.oam.dev/type: webservice
+ workload.oam.dev/type: webservice-v1
name: express-server
namespace: default
spec:
selector:
matchLabels:
app.oam.dev/component: express-server
template:
metadata:
labels:
app.oam.dev/component: express-server
app.oam.dev/revision: KUBEVELA_COMPONENT_REVISION_PLACEHOLDER
spec:
containers:
- - image: stefanprodan/podinfo:4.0.3
+ - image: crccheck/hello-world
name: express-server
ports:
- containerPort: 80
- image: stefanprodan/podinfo:6.0.1
+ image: stefanprodan/podinfo:6.0.xxx
type: webservice
workflow:
ref: make-release-in-hangzhou
status: {}
* External Policy (topology-hangzhou-clusters) has no change
* External Policy (override-high-availability) has no change
* External Workflow (make-release-in-hangzhou) has no change
```
</details>
我们可以看到所有关于应用配置以及依赖项的变化。
现在我们来更新一下应用的版本。
有两种方式可以更新应用版本，你可以任选其一。
1. 更新应用中的 `publishVersion` annotation 到 `alpha2` 来触发工作流的重新运行。
2. 运行 `vela up podinfo -n examples --publish-version alpha2` 来发布新版本。
VelaUI 中独立在数据库中记录了应用版本，我们也推荐在数据库中记录元数据历史。
我们会发现，由于 Deployment 的镜像不合法，应用卡在了 `runningWorkflow` 状态。
现在我们可以运行 `vela revision list podinfo -n examples` 来列出所有可用的版本。
```bash
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 19:32:02 Succeeded 23.7 KiB
podinfo-v2 alpha2 false 44124fb1a5146a4d 2022-04-13 19:46:50 Executing 23.7 KiB
```
### 回滚到最近成功的版本
在回滚应用之前，我们需要先停下应用工作流。运行 `vela workflow suspend podinfo -n examples`。
在应用的工作流被暂停后，运行 `vela workflow rollback podinfo -n examples`，工作流会被撤销，同时应用会恢复到最近一次的成功状态。
```shell
$ vela workflow suspend podinfo -n examples
Successfully suspend workflow: podinfo
$ vela workflow rollback podinfo -n examples
Find succeeded application revision podinfo-v1 (PublishVersion: alpha1) to rollback.
Application spec rollback successfully.
Application status rollback successfully.
Application rollback completed.
Application outdated revision cleaned up.
```
现在我们可以看到所有的资源都已经被恢复到了原有的镜像状态。
```shell
$ vela status podinfo -n examples --tree --detail --detail-format wide
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
```
### 重新发布历史版本
> 这个功能在 KubeVela v1.3.1 之后被引入。
版本回滚可以让你直接回退到上一次成功的状态。另一种方式是重新发布一个旧版本，这种方式的区别在于它可以回退到任一可用的历史版本中（不只是最近成功的），但是会触发工作流的重新运行。
例如，你可能保存了多个历史版本可供恢复
```shell
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Executing 23.7 KiB
```
这种情况下，你可以使用 `vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1` 来重新发布最早的版本。这个过程会让应用使用过去的历史版本来重跑整个工作流。新的版本会和声明使用的历史版本完全一致。
```shell
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Failed 23.7 KiB
podinfo-v4 beta1 true 65844934c2d07288 2022-04-13 20:46:49 Succeeded 23.7 KiB
```
你会发现 *beta1* 版本和 *alpha1* 版本的哈希值完全一致。
> 默认情况下，应用最多能持有 10 个历史版本。如果你想要修改这个数字，可以在控制器启动参数中设置 `--application-revision-limit`。

362
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/version-control.md
View File

@ -2,202 +2,228 @@
title: 版本管理
---
## 组件版本
## 简介
![overall-arch](../../../../../docs/resources/application-revision-arch.jpg)
在 KubeVela 中，ApplicationRevision 保持了应用在发布时刻的快照，包括所有 Application 的配置以及依赖的外部项（如组件定义、外置策略或是引用对象）。
这个版本可以用来比对应用的变化，并在应用的发布出故障时进行回滚。
在 KubeVela v1.3 中，对于使用 `PublishVersion` 特性的应用，支持浏览历史版本、跨版本配置比对、版本回滚以及版本重新发布。
对于带有 `app.oam.dev/publishVersion` annotation 的应用，工作流的运行会被严格限制在版本快照的范围内。
这个 annotation（在下文中简称为 *publishVersion*），可被用来代表应用的一个静态版本快照。
当这个 annotation 被更新时，应用会为当前的配置和依赖项生成一个静态版本，然后针对这个静态版本触发相应的工作流从头开始运行，已有的工作流会被中止。
在工作流运行的过程中，所有相关数据都会从版本快照中取出，这代表着直到应用的 `publishVersion` 被更新为止，应用配置或依赖项的变化都不会生效。
## 使用指南
我们以一个带有外置工作流和策略的应用为例，该应用将会将 podinfo 服务部署在子集群中。
> 对于外置工作流和策略，请参考 [多集群应用交付](../case-studies/multi-cluster) 以获取更多信息。
你可以通过字段 `spec.components[*].externalRevision` 在 Application 中指定即将生成的组件实例版本名称。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
name: podinfo
namespace: examples
annotations:
app.oam.dev/publishVersion: alpha1
spec:
components:
- name: express-server
- name: podinfo
type: webservice
externalRevision: express-server-v1
properties:
image: stefanprodan/podinfo:4.0.3
```
如果没有主动指定版本名称，会根据规则 `<component-name>-<revision-number>` 自动生成。
应用创建以后，你就可以看到系统中生成了 ControllerRevision 对象来记录组件版本。
* 获取组件实例的版本记录
```shell
$ kubectl get controllerrevision -l controller.oam.dev/component=express-server
NAME CONTROLLER REVISION AGE
express-server-v1 application.core.oam.dev/myapp 1 2m40s
express-server-v2 application.core.oam.dev/myapp 2 2m12s
```
你可以在[灰度发布](./traits/rollout)功能中进一步利用组件实例版本化以后的功能。
## 应用版本
除了工作流字段，应用中的每个字段更新都会生成一个对应的版本快照。
* 查看版本快照
```shell
$ kubectl get apprev -l app.oam.dev/name=myapp
NAME AGE
myapp-v1 54m
myapp-v2 53m
myapp-v3 18s
```
你可以在版本快照中获得应用所关联的所有信息，包括应用的字段以及对应的组件类型、运维能力等。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ApplicationRevision
image: stefanprodan/podinfo:6.0.1
workflow:
ref: make-release-in-hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
labels:
app.oam.dev/app-revision-hash: a74b4a514ba2fc08
app.oam.dev/name: myapp
name: myapp-v3
namespace: default
...
spec:
application:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
...
spec:
components:
- name: express-server
properties:
image: stefanprodan/podinfo:5.0.3
type: webservice@v1
...
componentDefinitions:
webservice:
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webservice
namespace: vela-system
...
spec:
schematic:
cue:
...
traitDefinitions:
...
```
## 应用版本对比
部署前版本对比（Live-diff）功能可以让你不用真的对运行时集群进行操作，在本地预览即将部署的版本和线上版本的差异性，并进行确认。
预览所提供的信息，会包括应用部署计划的新增、修改和移除等信息，同时也包括其中的组件和运维特征的相关信息。
假设你的新应用部署计划如下，包含镜像的变化：
```yaml
# new-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
spec:
name: override-high-availability
namespace: examples
type: override
properties:
components:
- name: express-server
type: webservice@v1
properties:
image: crccheck/hello-world # 变更镜像
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- name: deploy-hangzhou
type: deploy
properties:
policies: ["topology-hangzhou-clusters", "override-high-availability"]
```
然后运行 `版本对比` 功能，使用如下命令：
你可以运行 `vela status podinfo -n examples` 来查看应用的部署状态，也可以运行 `vela status podinfo -n examples --tree --detail` 来查看所有相关资源的实时状态。
```shell
vela live-diff -f new-app.yaml -r vela-app-v1
$ vela status podinfo -n examples
vela status podinfo -n examples
About:
Name: podinfo
Namespace: examples
Created at: 2022-04-13 19:32:02 +0800 CST
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:auqaxnbix2
name:deploy-hangzhou
type:deploy
phase:running
message:wait healthy
Services:
- Name: podinfo
Cluster: velad-003 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
- Name: podinfo
Cluster: velad-002 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
$ vela status podinfo -n examples --tree --detail
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
```
* 通过 `-r` 或 `--revision` 参数，指定要比较的版本名称。
* 通过 `-c` 或 `--context` 指定对比差异的上下文行数。
这个应用会在一段时间后进入正常运行的状态。
现在我们修改组件的镜像，并把它设置成一个不合法的镜像，如 `stefanprodan/podinfo:6.0.xxx`。
因为 `publishVersion` 的存在，这个应用不会自动地重新运行工作流。
但由于应用的配置发生了变化，这意味着下一次工作流的运行会更新部署的 Deployment 的镜像。
通过 `vela live-diff -h` 查看更多参数用法。
### 查看版本变化
<details><summary> 点击查看对比结果 </summary>
现在，应用正在运行的版本和当前环境中应用的配置（也就是下一次要运行的配置）产生了差异，我们可以运行 `vela live-diff podinfo -n examples` 来查看这一变化。
```bash
---
# Application (myapp) has been modified(*)
---
$ vela live-diff podinfo -n examples
* Application (podinfo) has been modified(*)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
creationTimestamp: null
- finalizers:
- - app.oam.dev/resource-tracker-finalizer
name: myapp
namespace: default
annotations:
app.oam.dev/publishVersion: alpha1
name: podinfo
namespace: examples
spec:
components:
- - externalRevision: express-server-v1
- name: express-server
+ - name: express-server
- name: podinfo
properties:
- image: stefanprodan/podinfo:4.0.3
- type: webservice
+ image: crccheck/hello-world
+ type: webservice@v1
status:
rollout:
batchRollingState: ""
currentBatch: 0
lastTargetAppRevision: ""
rollingState: ""
upgradedReadyReplicas: 0
upgradedReplicas: 0
---
## Component (express-server) has been modified(*)
---
apiVersion: apps/v1
kind: Deployment
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
+ annotations: {}
labels:
app.oam.dev/appRevision: ""
app.oam.dev/component: express-server
app.oam.dev/name: myapp
app.oam.dev/resourceType: WORKLOAD
- workload.oam.dev/type: webservice
+ workload.oam.dev/type: webservice-v1
name: express-server
namespace: default
spec:
selector:
matchLabels:
app.oam.dev/component: express-server
template:
metadata:
labels:
app.oam.dev/component: express-server
app.oam.dev/revision: KUBEVELA_COMPONENT_REVISION_PLACEHOLDER
spec:
containers:
- - image: stefanprodan/podinfo:4.0.3
+ - image: crccheck/hello-world
name: express-server
ports:
- containerPort: 80
- image: stefanprodan/podinfo:6.0.1
+ image: stefanprodan/podinfo:6.0.xxx
type: webservice
workflow:
ref: make-release-in-hangzhou
status: {}
* External Policy (topology-hangzhou-clusters) has no change
* External Policy (override-high-availability) has no change
* External Workflow (make-release-in-hangzhou) has no change
```
</details>
我们可以看到所有关于应用配置以及依赖项的变化。
现在我们来更新一下应用的版本。
有两种方式可以更新应用版本，你可以任选其一。
1. 更新应用中的 `publishVersion` annotation 到 `alpha2` 来触发工作流的重新运行。
2. 运行 `vela up podinfo -n examples --publish-version alpha2` 来发布新版本。
VelaUI 中独立在数据库中记录了应用版本，我们也推荐在数据库中记录元数据历史。
我们会发现，由于 Deployment 的镜像不合法，应用卡在了 `runningWorkflow` 状态。
现在我们可以运行 `vela revision list podinfo -n examples` 来列出所有可用的版本。
```bash
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 19:32:02 Succeeded 23.7 KiB
podinfo-v2 alpha2 false 44124fb1a5146a4d 2022-04-13 19:46:50 Executing 23.7 KiB
```
### 回滚到最近成功的版本
在回滚应用之前，我们需要先停下应用工作流。运行 `vela workflow suspend podinfo -n examples`。
在应用的工作流被暂停后，运行 `vela workflow rollback podinfo -n examples`，工作流会被撤销，同时应用会恢复到最近一次的成功状态。
```shell
$ vela workflow suspend podinfo -n examples
Successfully suspend workflow: podinfo
$ vela workflow rollback podinfo -n examples
Find succeeded application revision podinfo-v1 (PublishVersion: alpha1) to rollback.
Application spec rollback successfully.
Application status rollback successfully.
Application rollback completed.
Application outdated revision cleaned up.
```
现在我们可以看到所有的资源都已经被恢复到了原有的镜像状态。
```shell
$ vela status podinfo -n examples --tree --detail --detail-format wide
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
```
### 重新发布历史版本
> 这个功能在 KubeVela v1.3.1 之后被引入。
版本回滚可以让你直接回退到上一次成功的状态。另一种方式是重新发布一个旧版本，这种方式的区别在于它可以回退到任一可用的历史版本中（不只是最近成功的），但是会触发工作流的重新运行。
例如，你可能保存了多个历史版本可供恢复
```shell
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Executing 23.7 KiB
```
这种情况下，你可以使用 `vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1` 来重新发布最早的版本。这个过程会让应用使用过去的历史版本来重跑整个工作流。新的版本会和声明使用的历史版本完全一致。
```shell
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Failed 23.7 KiB
podinfo-v4 beta1 true 65844934c2d07288 2022-04-13 20:46:49 Succeeded 23.7 KiB
```
你会发现 *beta1* 版本和 *alpha1* 版本的哈希值完全一致。
> 默认情况下，应用最多能持有 10 个历史版本。如果你想要修改这个数字，可以在控制器启动参数中设置 `--application-revision-limit`。

370
versioned_docs/version-v1.3/end-user/version-control.md
View File

@ -1,208 +1,228 @@
---
title: Revisioning
title: Version Control
---
## Component Revision
## Introduction
You can specify a generated component instance revision with field `spec.components[*].externalRevision` in Application like below:
![overall-arch](../resources/application-revision-arch.jpg)
In KubeVela, ApplicationRevision keeps the snapshot of the application and all its runtime dependencies such as ComponentDefinition, external Policy or referred objects.
This revision can be used to review the application changes and rollback to past configurations.
In KubeVela v1.3, for application which uses the `PublishVersion` feature, we support viewing the history revisions, checking the differences across revisions, rolling back to the latest succeeded revision and re-publishing past revisions.
For application with the `app.oam.dev/publishVersion` annotation, the workflow runs are strictly controlled.
The annotation, which is noted as *publishVersion* in the following paragraphs, is used to identify a static version of the application and its dependencies.
When the annotation is updated to a new value, the application will generate a new revision no matter if the application spec or the dependencies are changed.
It will then trigger a fresh new run of workflow after terminating the previous run.
During the running of workflow, all related data are retrieved from the ApplicationRevision, which means the changes to the application spec or the dependencies will not take effects until a newer `publishVerison` is annotated.
## Use Guide
Fo example, let's start with an application with external workflow and policies to deploy podinfo in managed clusters.
> For external workflow and policies, please refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for more details.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
name: podinfo
namespace: examples
annotations:
app.oam.dev/publishVersion: alpha1
spec:
components:
- name: express-server
- name: podinfo
type: webservice
externalRevision: express-server-v1
properties:
image: stefanprodan/podinfo:4.0.3
```
If the field is not specified, it will generated by the name rule `<component-name>-<revision-number>`.
After the Application created, it will generate a ControllerRevision object for each component.
* Get the revision for component instance
```shell
$ kubectl get controllerrevision -l controller.oam.dev/component=express-server
NAME CONTROLLER REVISION AGE
express-server-v1 application.core.oam.dev/myapp 1 2m40s
express-server-v2 application.core.oam.dev/myapp 2 2m12s
```
You can specify the component revision for [component rolling update](./traits/rollout).
## Application Revision
When updating an application entity except workflow, KubeVela will create a new revision as a snapshot for this change.
```shell
$ kubectl get apprev -l app.oam.dev/name=myapp
NAME AGE
myapp-v1 54m
myapp-v2 53m
myapp-v3 18s
```
You can get all the information related with the application in the application revision, including the application spec,
and all related definitions.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ApplicationRevision
image: stefanprodan/podinfo:6.0.1
workflow:
ref: make-release-in-hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
labels:
app.oam.dev/app-revision-hash: a74b4a514ba2fc08
app.oam.dev/name: myapp
name: myapp-v3
namespace: default
...
spec:
application:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
...
spec:
components:
- name: express-server
properties:
image: stefanprodan/podinfo:5.0.3
type: webservice@v1
...
componentDefinitions:
webservice:
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webservice
namespace: vela-system
...
spec:
schematic:
cue:
...
traitDefinitions:
...
```
## Live-Diff the `Application`
Live-diff helps you to have a preview of what would change if you're going to upgrade an application without making any changes
to the living cluster.
This feature is extremely useful for serious production deployment, and make the upgrade under control
It basically generates a diff between the specific revision of running instance and the local candidate application.
The result shows the changes (added/modified/removed/no_change) of the application as well as its sub-resources,
such as components and traits.
Assume we're going to upgrade the application like below.
```yaml
# new-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
spec:
name: override-high-availability
namespace: examples
type: override
properties:
components:
- name: express-server
type: webservice@v1
properties:
image: crccheck/hello-world # change the image
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- name: deploy-hangzhou
type: deploy
properties:
policies: ["topology-hangzhou-clusters", "override-high-availability"]
```
Run live-diff like this:
You can check the application status by running `vela status podinfo -n examples` and view all the related real-time resources by `vela status podinfo -n examples --tree --detail`.
```shell
vela live-diff -f new-app.yaml -r myapp-v1
$ vela status podinfo -n examples
vela status podinfo -n examples
About:
Name: podinfo
Namespace: examples
Created at: 2022-04-13 19:32:02 +0800 CST
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:auqaxnbix2
name:deploy-hangzhou
type:deploy
phase:running
message:wait healthy
Services:
- Name: podinfo
Cluster: velad-003 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
- Name: podinfo
Cluster: velad-002 Namespace: examples
Type: webservice
Unhealthy Ready:0/3
Traits:
✅ scaler
$ vela status podinfo -n examples --tree --detail
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 4m16s
```
`-r` or `--revision` is a flag that specifies the name of a living ApplicationRevision with which you want to compare the updated application.
This application should be successful after a while.
Now if we edit the component image and set it to an invalid value, such as `stefanprodan/podinfo:6.0.xxx`.
The application will not re-run the workflow to make this change take effect automatically.
But the application spec changes, it means the next workflow run will update the deployment image.
`-c` or `--context` is a flag that specifies the number of lines shown around a change. The unchanged lines
which are out of the context of a change will be omitted. It's useful if the diff result contains a lot of unchanged content
while you just want to focus on the changed ones.
<details><summary> Click to view the details of diff result </summary>
### Inspect Changes across Revisions
Now let's run `vela live-diff podinfo -n examples` to check this diff
```bash
---
# Application (myapp) has been modified(*)
---
$ vela live-diff podinfo -n examples
* Application (podinfo) has been modified(*)
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
creationTimestamp: null
- finalizers:
- - app.oam.dev/resource-tracker-finalizer
name: myapp
namespace: default
annotations:
app.oam.dev/publishVersion: alpha1
name: podinfo
namespace: examples
spec:
components:
- - externalRevision: express-server-v1
- name: express-server
+ - name: express-server
- name: podinfo
properties:
- image: stefanprodan/podinfo:4.0.3
- type: webservice
+ image: crccheck/hello-world
+ type: webservice@v1
status:
rollout:
batchRollingState: ""
currentBatch: 0
lastTargetAppRevision: ""
rollingState: ""
upgradedReadyReplicas: 0
upgradedReplicas: 0
---
## Component (express-server) has been modified(*)
---
apiVersion: apps/v1
kind: Deployment
metadata:
- annotations:
- kubectl.kubernetes.io/last-applied-configuration: |
- {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"myapp","namespace":"default"},"spec":{"components":[{"externalRevision":"express-server-v1","name":"express-server","properties":{"image":"stefanprodan/podinfo:4.0.3"},"type":"webservice"}]}}
+ annotations: {}
labels:
app.oam.dev/appRevision: ""
app.oam.dev/component: express-server
app.oam.dev/name: myapp
app.oam.dev/resourceType: WORKLOAD
- workload.oam.dev/type: webservice
+ workload.oam.dev/type: webservice-v1
name: express-server
namespace: default
spec:
selector:
matchLabels:
app.oam.dev/component: express-server
template:
metadata:
labels:
app.oam.dev/component: express-server
app.oam.dev/revision: KUBEVELA_COMPONENT_REVISION_PLACEHOLDER
spec:
containers:
- - image: stefanprodan/podinfo:4.0.3
+ - image: crccheck/hello-world
name: express-server
ports:
- containerPort: 80
- image: stefanprodan/podinfo:6.0.1
+ image: stefanprodan/podinfo:6.0.xxx
type: webservice
workflow:
ref: make-release-in-hangzhou
status: {}
* External Policy (topology-hangzhou-clusters) has no change
* External Policy (override-high-availability) has no change
* External Workflow (make-release-in-hangzhou) has no change
```
</details>
We can see all the changes of the application spec and the dependencies.
Now let's make this change take effects.
There are two ways to make it take effects. You can choose any one of them.
1. Update the `publishVersion` annotation in the application to `alpha2` to trigger the re-run of workflow.
2. Run `vela up podinfo -n examples --publish-version alpha2` to publish the new version.
We will find the application stuck at `runningWorkflow` as the deployment cannot finish the update progress due to the invalid image.
Now we can run `vela revision list podinfo -n examples` to list all the available revisions.
```bash
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 19:32:02 Succeeded 23.7 KiB
podinfo-v2 alpha2 false 44124fb1a5146a4d 2022-04-13 19:46:50 Executing 23.7 KiB
```
### Rollback to Last Successful Revision
Before rolling back, we need to suspend the workflow of the application first. Run `vela workflow suspend podinfo -n examples`.
After the application workflow is suspended, run `vela workflow rollback podinfo -n examples`, the workflow will be rolled back and the application resources will restore to the succeeded state.
```shell
$ vela workflow suspend podinfo -n examples
Successfully suspend workflow: podinfo
$ vela workflow rollback podinfo -n examples
Find succeeded application revision podinfo-v1 (PublishVersion: alpha1) to rollback.
Application spec rollback successfully.
Application status rollback successfully.
Application rollback completed.
Application outdated revision cleaned up.
```
Now if we return back to see all the resources, we will find the resources have been turned back to use the valid image again.
```shell
$ vela status podinfo -n examples --tree --detail --detail-format wide
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
hangzhou1 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
hangzhou2 ─── examples ─── Deployment/podinfo updated 2022-04-13 19:32:03 Ready: 3/3 Up-to-date: 3 Available: 3 Age: 17m Containers: podinfo Images: stefanprodan/podinfo:6.0.1 Selector: app.oam.dev/component=podinfo
```
### Re-publish a History Revision
> This feature is introduced after v1.3.1.
VelaUX uses database for version record, we also recommend you to use a database instead of relying on Kubernetes etcd for versioning.
Rolling back revision allows you to directly go back to the latest successful state. An alternative way is to re-publish an old revision, which will re-run the workflow but can go back to any revision that is still available.
For example, you might have 2 successful revisions available to use.
```shell
$ vela revision list podinfo -n examples
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Executing 23.7 KiB
```
Alternatively, you can directly use `vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1` to re-publish the earliest version. This process will let the application to use the past revision and re-run the whole workflow. A new revision that is totally same with the specified one will be generated.
```shell
NAME PUBLISH_VERSION SUCCEEDED HASH BEGIN_TIME STATUS SIZE
podinfo-v1 alpha1 true 65844934c2d07288 2022-04-13 20:45:19 Succeeded 23.7 KiB
podinfo-v2 alpha2 true 4acae1a66013283 2022-04-13 20:45:45 Succeeded 23.7 KiB
podinfo-v3 alpha3 false 44124fb1a5146a4d 2022-04-13 20:46:28 Failed 23.7 KiB
podinfo-v4 beta1 true 65844934c2d07288 2022-04-13 20:46:49 Succeeded 23.7 KiB
```
You can find that the *beta1* version shares the same hash with *alpha1* version.
> By default, application will hold at most 10 revisions. If you want to modify this number, you can set it in the `--application-revision-limit` bootstrap parameter of KubeVela controller.

BIN
versioned_docs/version-v1.3/resources/application-revision-arch.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 249 KiB