refine workflow docs
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
dc1a430398
commit
81008672b1
|
|
@ -55,10 +55,10 @@ See [this document](https://kubevela.net/docs/install#1-install-velad) for more
|
|||
- Enable related addon
|
||||
|
||||
```shell
|
||||
$ vela addon enable fluxcd
|
||||
$ vela addon enable ingress-nginx
|
||||
$ vela addon enable kruise-rollout
|
||||
$ vela addon enable velaux
|
||||
vela addon enable fluxcd
|
||||
vela addon enable ingress-nginx
|
||||
vela addon enable kruise-rollout
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
In this step, the following addons are started:
|
||||
|
|
@ -70,7 +70,7 @@ In this step, the following addons are started:
|
|||
- Map the Nginx ingress-controller port to local
|
||||
|
||||
```shell
|
||||
$ vela port-forward addon-ingress-nginx -n vela-system
|
||||
vela port-forward addon-ingress-nginx -n vela-system
|
||||
```
|
||||
|
||||
### First Deployment
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Overview of GitOps
|
||||
---
|
||||
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
:::note
|
||||
This section will introduce how to use KubeVela in GitOps area and why.
|
||||
:::
|
||||
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with "git-centric" operations such as PR and commit. For detailed benefits of GitOps, you can refer to [this blog](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true
|
|||
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true
|
||||
```
|
||||
|
||||
> By default, the hub cluster where KubeVela locates is registered as the `local` cluster. You can use it like a managed cluster in spite that you cannot detach it or modify it.
|
||||
:::note
|
||||
By default, the hub cluster where KubeVela locates is registered as the `local` cluster. You can use it like a managed cluster in spite that you cannot detach it or modify it.
|
||||
:::
|
||||
|
||||
## Deliver Application to Clusters
|
||||
|
||||
|
|
@ -197,8 +199,9 @@ spec:
|
|||
namespace: examples-alternative
|
||||
```
|
||||
|
||||
> Sometimes, for security issues, you might want to disable this behavior and retrict the resources to be deployed within the same namespace of the application. This can be done by setting `--allow-cross-namespace-resource=false` in the bootstrap parameter of the KubeVela controller.
|
||||
|
||||
:::tip
|
||||
Sometimes, for security issues, you might want to disable this behavior and retrict the resources to be deployed within the same namespace of the application. This can be done by setting `--allow-cross-namespace-resource=false` in the [bootstrap parameter](../platform-engineers/system-operation/bootstrap-parameters) of the KubeVela controller.
|
||||
:::
|
||||
|
||||
### Control the deploy workflow
|
||||
|
||||
|
|
@ -336,7 +339,9 @@ spec:
|
|||
policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
|
||||
```
|
||||
|
||||
> NOTE: The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
|
||||
:::note
|
||||
The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
|
||||
:::
|
||||
|
||||
The override policy has many advanced capabilities, such as adding new component or selecting components to use.
|
||||
The following example will first deploy an nginx webservice with `nginx:1.20` image to local cluster. Then two nginx webservices with `nginx` and `nginx:stable` images will be deployed to hangzhou clusters respectively.
|
||||
|
|
@ -399,7 +404,9 @@ spec:
|
|||
Sometimes, you may want to use the same policy across multiple applications or reuse previous workflow to deploy different resources.
|
||||
To reduce the repeated code, you can leverage the external policies and workflow and refer to them in your applications.
|
||||
|
||||
> NOTE: you can only refer to Policy and Workflow within your application's namespace.
|
||||
:::caution
|
||||
You can only refer to Policy and Workflow within your application's namespace.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
|
|
@ -455,7 +462,11 @@ spec:
|
|||
ref: make-release-in-hangzhou
|
||||
```
|
||||
|
||||
> NOTE: The internal policies will be loaded first. External policies will only be used when there is no corresponding policy inside the application. In the following example, we can reuse `topology-hangzhou-clusters` policy and `make-release-in-hangzhou` workflow but modify the `override-high-availability-webservice` policy by injecting the same-named policy inside the new application.
|
||||
:::note
|
||||
The internal policies will be loaded first. External policies will only be used when there is no corresponding policy inside the application.
|
||||
:::
|
||||
|
||||
In the following example, we can reuse `topology-hangzhou-clusters` policy and `make-release-in-hangzhou` workflow but modify the `override-high-availability-webservice` policy by injecting the same-named policy inside the new application.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
|
|||
|
|
@ -167,7 +167,9 @@ To run vela-core locally for debugging with kubevela installed in the remote clu
|
|||
|
||||
Finally, you can use the commands in the above [Build](#build) and [Testing](#Testing) sections, such as `make run`, to code and debug in your local machine.
|
||||
|
||||
> Note you will not be able to test features relate with validating/mutating webhooks in this way.
|
||||
:::caution
|
||||
Note you will not be able to test features relate with validating/mutating webhooks in this way.
|
||||
:::
|
||||
|
||||
## Run VelaUX Locally
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ contains the following attributes: name, character_set, description.
|
|||
|
||||
Applying the following application can create more than one database in an RDS instance.
|
||||
|
||||
> ⚠️ This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::caution
|
||||
This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@ title: Provision and Binding Database
|
|||
|
||||
This tutorial will talk about how to provision and consume Alibaba Cloud RDS (and OSS) by Terraform.
|
||||
|
||||
> ⚠️ This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::caution
|
||||
This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::
|
||||
|
||||
Let's deploy the [application](https://github.com/kubevela/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/application.yaml)
|
||||
below to provision Alibaba Cloud OSS and RDS cloud resources, and consume them by the web component.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,9 @@ Once addon installed, end user can discover and use these capabilities immediate
|
|||
|
||||
### Uninstall Addon
|
||||
|
||||
> Please make sure the addon along with its capabilities is no longer used in any of your applications before uninstalling it.
|
||||
:::danger
|
||||
Please make sure the addon along with its capabilities is no longer used in any of your applications before uninstalling it.
|
||||
:::
|
||||
|
||||
```shell
|
||||
vela addon disable fluxcd
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Distribute Reference Objects
|
||||
---
|
||||
|
||||
> This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
:::note
|
||||
This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
:::
|
||||
|
||||
You can reference and distribute existing Kubernetes objects with KubeVela in the following scenarios:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: One-time Delivery(Working With Other Controllers)
|
||||
title: One-time Delivery (Coordinate with Multi-Controllers)
|
||||
---
|
||||
|
||||
By default, the KubeVela controller will prevent configuration drift for applied resources by reconciling them routinely. This is useful if you want to keep your application always having the desired configuration to avoid some unintentional changes by external modifiers.
|
||||
|
|
|
|||
|
|
@ -10,8 +10,10 @@ In garbage-collect policy, there are two major capabilities you can use.
|
|||
|
||||
Suppose you want to keep the resources created by the old version of the application. Use the garbage-collect policy and enable the option `keepLegacyResource`.
|
||||
|
||||
```yaml
|
||||
# app.yaml
|
||||
1. create app
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
@ -24,9 +26,10 @@ spec:
|
|||
image: oamdev/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
class: traefik
|
||||
domain: 47.251.8.82.nip.io
|
||||
http:
|
||||
"/": 8000
|
||||
policies:
|
||||
|
|
@ -34,24 +37,31 @@ spec:
|
|||
type: garbage-collect
|
||||
properties:
|
||||
keepLegacyResource: true
|
||||
EOF
|
||||
```
|
||||
|
||||
1. create app
|
||||
|
||||
``` shell
|
||||
vela up -f app.yaml
|
||||
```
|
||||
Check the status:
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
first-vela-app express-server webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST
|
||||
vela status first-vela-app --tree
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
local ─── default ─┬─ Service/express-server updated
|
||||
├─ Deployment/express-server updated
|
||||
└─ Ingress/express-server updated
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
2. update the app
|
||||
|
||||
```yaml
|
||||
# app1.yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
@ -64,9 +74,10 @@ spec:
|
|||
image: oamdev/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
class: traefik
|
||||
domain: 47.251.8.82.nip.io
|
||||
http:
|
||||
"/": 8000
|
||||
policies:
|
||||
|
|
@ -74,50 +85,30 @@ spec:
|
|||
type: garbage-collect
|
||||
properties:
|
||||
keepLegacyResource: true
|
||||
EOF
|
||||
```
|
||||
|
||||
``` shell
|
||||
vela up -f app1.yaml
|
||||
```
|
||||
Check the status again:
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
first-vela-app express-server-1 webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST
|
||||
vela status first-vela-app --tree
|
||||
```
|
||||
|
||||
check whether legacy resources are reserved.
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
> In the following steps, we'll use `kubectl` command to do some verification. You can also use `vela status first-vela-app` to check the aggregated application status and see if components are healthy.
|
||||
```shell
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
local ─── default ─┬─ Service/express-server outdated
|
||||
├─ Service/express-server-1 updated
|
||||
├─ Deployment/express-server outdated
|
||||
├─ Deployment/express-server-1 updated
|
||||
├─ Ingress/express-server outdated
|
||||
└─ Ingress/express-server-1 updated
|
||||
```
|
||||
</details>
|
||||
|
||||
```
|
||||
$ kubectl get deploy
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 10m
|
||||
express-server-1 1/1 1 1 40s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
express-server ClusterIP 10.96.102.249 <none> 8000/TCP 10m
|
||||
express-server-1 ClusterIP 10.96.146.10 <none> 8000/TCP 46s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 10m
|
||||
express-server-1 <none> testsvc.example.com 80 50s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get resourcetracker
|
||||
NAME AGE
|
||||
first-vela-app-default 12m
|
||||
first-vela-app-v1-default 12m
|
||||
first-vela-app-v2-default 2m56s
|
||||
```
|
||||
You can see the legacy resources are reserved but the status is outdated, it will not be synced by periodically reconciliation.
|
||||
|
||||
3. delete the app
|
||||
|
||||
|
|
@ -127,20 +118,21 @@ $ vela delete first-vela-app
|
|||
|
||||
> If you hope to delete resources in one specified version, you can run `kubectl delete resourcetracker first-vela-app-v1-default`.
|
||||
|
||||
## Persist resources
|
||||
## Persist partial resources
|
||||
|
||||
You can also persist some resources, which skips the normal garbage-collect process when the application is updated.
|
||||
You can also persist part of the resources, which skips the normal garbage-collect process when the application is updated.
|
||||
|
||||
Take the following app as an example, in the garbage-collect policy, a rule is added which marks all the resources created by the `expose` trait to use the `onAppDelete` strategy. This will keep those services until application is deleted.
|
||||
|
||||
```shell
|
||||
$ cat <<EOF | vela up -f -
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: garbage-collect-app
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world
|
||||
- name: demo-gc
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/hello-world
|
||||
|
|
@ -161,6 +153,7 @@ EOF
|
|||
```
|
||||
|
||||
You can find deployment and service created.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
|
|
@ -171,8 +164,9 @@ hello-world ClusterIP 10.96.160.208 <none> 8000/TCP 78s
|
|||
```
|
||||
|
||||
If you upgrade the application and use a different component, you will find the old versioned deployment is deleted but the service is kept.
|
||||
|
||||
```shell
|
||||
$ cat <<EOF | vela up -f -
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -105,6 +105,7 @@ Hello World
|
|||
</xmp>
|
||||
```
|
||||
|
||||
> ⚠️ This section requires your runtime cluster has a working ingress controller.
|
||||
|
||||
:::caution
|
||||
This section requires your runtime cluster has a working ingress controller.
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ In this section, we will introduce how to canary rollout a container service.
|
|||
|
||||
1. Enable [`kruise-rollout`](../../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your cluster.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,10 @@ And check the logging output of sidecar.
|
|||
```shell
|
||||
vela logs vela-app-with-sidecar -c count-log
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```console
|
||||
0: Fri Apr 16 11:08:45 UTC 2021
|
||||
1: Fri Apr 16 11:08:46 UTC 2021
|
||||
|
|
@ -80,3 +84,4 @@ vela logs vela-app-with-sidecar -c count-log
|
|||
9: Fri Apr 16 11:08:54 UTC 2021
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -9,7 +9,7 @@ title: Application Version Control
|
|||
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.
|
||||
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.
|
||||
|
|
@ -17,13 +17,15 @@ The annotation, which is noted as *publishVersion* in the following paragraphs,
|
|||
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.
|
||||
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 `publishVersion` 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.
|
||||
:::tip
|
||||
We use reference of external workflow and policies, it works the same. You can refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for more details.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -78,10 +80,16 @@ steps:
|
|||
policies: ["topology-hangzhou-clusters", "override-high-availability"]
|
||||
```
|
||||
|
||||
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`.
|
||||
You can check the application status by:
|
||||
|
||||
```shell
|
||||
$ vela status podinfo -n examples
|
||||
vela status podinfo -n examples
|
||||
vela status podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: podinfo
|
||||
|
|
@ -116,23 +124,43 @@ Services:
|
|||
Unhealthy Ready:0/3
|
||||
Traits:
|
||||
✅ scaler
|
||||
```
|
||||
</details>
|
||||
|
||||
$ vela status podinfo -n examples --tree --detail
|
||||
View all the related real-time resources by:
|
||||
|
||||
```
|
||||
vela status podinfo -n examples --tree --detail
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
</details>
|
||||
|
||||
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.
|
||||
|
||||
### Inspect Changes across Revisions
|
||||
|
||||
Now let's run `vela live-diff podinfo -n examples` to check this diff
|
||||
```bash
|
||||
$ vela live-diff podinfo -n examples
|
||||
You can run `vela live-diff` to check revision difference:
|
||||
|
||||
```
|
||||
vela live-diff podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```yaml
|
||||
* Application (podinfo) has been modified(*)
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
|
|
@ -156,64 +184,129 @@ $ vela live-diff podinfo -n examples
|
|||
* 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.
|
||||
|
||||
### Publish a new app with specified revision
|
||||
|
||||
There are two ways to publish an app with specified revision. 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.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: podinfo
|
||||
namespace: examples
|
||||
annotations:
|
||||
- app.oam.dev/publishVersion: alpha1
|
||||
+ app.oam.dev/publishVersion: alpha2
|
||||
...
|
||||
```
|
||||
2. Run `vela up --publish-version <revision-name` to publish the new version.
|
||||
```
|
||||
vela up podinfo -n examples --publish-version alpha2
|
||||
```
|
||||
|
||||
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.
|
||||
Now we can run `vela revision list` to list all the available revisions.
|
||||
|
||||
```
|
||||
vela revision list podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 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`.
|
||||
Before rolling back, we need to suspend the workflow of the application first.
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
```
|
||||
vela workflow rollback podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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.
|
||||
```
|
||||
</details>
|
||||
|
||||
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
|
||||
vela status podinfo -n examples --tree --detail --detail-format wide
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
</details>
|
||||
|
||||
### Re-publish a History Revision
|
||||
|
||||
> This feature is introduced after v1.3.1.
|
||||
|
||||
:::note
|
||||
This feature is introduced after v1.3+.
|
||||
:::
|
||||
|
||||
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.
|
||||
|
||||
Let's list the history revision by:
|
||||
|
||||
```shell
|
||||
vela revision list podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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.
|
||||
</details>
|
||||
|
||||
Alternatively, you can directly run the following command to rollback to a specified revision:
|
||||
|
||||
```
|
||||
vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1
|
||||
```
|
||||
|
||||
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
|
||||
|
|
@ -225,4 +318,6 @@ podinfo-v4 beta1 true 65844934c2d07288 2022-04-
|
|||
|
||||
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.
|
||||
:::info
|
||||
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](../platform-engineers/system-operation/bootstrap-parameters) of KubeVela controller.
|
||||
:::
|
||||
|
|
@ -4,7 +4,9 @@ title: Component Orchestration
|
|||
|
||||
This section will introduce the dependencies in components and how to pass data between components.
|
||||
|
||||
> We use `helm` component type in the following examples, make sure you have the `fluxcd` addon enabled (`vela addon enable fluxcd`).
|
||||
:::tip
|
||||
We use `helm` component type in the following examples, make sure you have the `fluxcd` addon enabled (`vela addon enable fluxcd`).
|
||||
:::
|
||||
|
||||
## Dependency
|
||||
|
||||
|
|
@ -99,9 +101,9 @@ mysql mysql-secret raw running healthy 2021-10-14 12:09:55 +0
|
|||
|
||||
After a while, all components is running successfully. The `mysql-cluster` will be deployed after `mysql-controller` and `mysql-secret` is `healthy`.
|
||||
|
||||
> `dependsOn` use `healthy` to check status. If the component is `healthy`, then KubeVela will deploy the next component.
|
||||
> If you want to customize the healthy status of the component, please refer to [Status Write Back](../../platform-engineers/traits/status)
|
||||
|
||||
:::info
|
||||
`dependsOn` use `healthy` to check status. If the component is `healthy`, then KubeVela will deploy the next component. If you want to customize the healthy status of the component, please refer to [Status Write Back](../../platform-engineers/traits/status)
|
||||
:::
|
||||
|
||||
## Inputs and Outputs
|
||||
|
||||
|
|
|
|||
|
|
@ -10,13 +10,18 @@ In KubeVela, you can choose to use the `vela` command to manually suspend the ex
|
|||
|
||||
### Suspend Manually
|
||||
|
||||
If you have a running application and you want to suspend its execution, you can use `vela workflow suspend` to suspend the workflow.
|
||||
If you have an application in `runningWorkflow` state, you want to stop the execution of the workflow, you can use `vela workflow suspend` to stop the workflow and use `vela workflow resume` to continue it.
|
||||
|
||||
* Suspend the application
|
||||
|
||||
```bash
|
||||
$ vela workflow suspend my-app
|
||||
Successfully suspend workflow: my-app
|
||||
vela workflow suspend my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
Nothing will happen if you suspend an application that has already finished running workflow, which is in `running` status.
|
||||
:::
|
||||
|
||||
### Use Suspend Step
|
||||
|
||||
Apply the following example:
|
||||
|
|
@ -25,7 +30,7 @@ Apply the following example:
|
|||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: suspend
|
||||
name: suspend-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
|
|
@ -56,10 +61,16 @@ spec:
|
|||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
|
@ -75,12 +86,10 @@ Workflow:
|
|||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:running
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
|
|
@ -90,6 +99,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, when the first step is completed, the `suspend` step will be executed and this step will suspend the workflow.
|
||||
|
||||
|
|
@ -102,17 +112,22 @@ Once the workflow is suspended, you can use the `vela workflow resume` command t
|
|||
Take the above suspended application as an example:
|
||||
|
||||
```bash
|
||||
$ vela workflow resume suspend
|
||||
Successfully resume workflow: suspend
|
||||
vela workflow resume suspend-demo
|
||||
```
|
||||
|
||||
After successfully continuing the workflow, view the status of the app:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: running
|
||||
|
|
@ -154,6 +169,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, the workflow has continued to execute.
|
||||
|
||||
|
|
@ -161,11 +177,28 @@ As you can see, the workflow has continued to execute.
|
|||
|
||||
If you want to terminate a workflow while it is suspended, you can use the `vela workflow terminate` command to terminate the workflow.
|
||||
|
||||
* Terminate the application workflow
|
||||
|
||||
```bash
|
||||
$ vela workflow terminate my-app
|
||||
Successfully terminate workflow: my-app
|
||||
vela workflow terminate my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
Different from suspend, the terminated application workflow can't be resumed, you can only restart the workflow. This means restart the workflow will execute the workflow steps from scratch while resume workflow only continue the unfinished steps.
|
||||
:::
|
||||
|
||||
* Restart the application workflow
|
||||
|
||||
```bash
|
||||
vela workflow restart my-app
|
||||
```
|
||||
|
||||
:::caution
|
||||
Once application is terminated, KubeVela controller won't reconcile the application resources. It can also be used in some cases when you want to manually operate the underlying resources, please caution the configuration drift.
|
||||
:::
|
||||
|
||||
Once application come into `running` status, it can't be terminated or restarted.
|
||||
|
||||
### Resume the Workflow Automatically
|
||||
|
||||
If you want the workflow to be continued automatically after a period of time has passed. Then, you can add a `duration` parameter to the `suspend` step. When the `duration` time elapses, the workflow will automatically continue execution.
|
||||
|
|
@ -209,7 +242,13 @@ spec:
|
|||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status auto-resume
|
||||
vela status auto-resume
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: auto-resume
|
||||
|
|
@ -254,5 +293,6 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, the `suspend` step is automatically executed successfully after five seconds, and the workflow is executed successfully.
|
||||
|
|
|
|||
|
|
@ -164,7 +164,9 @@ Application is also one kind of Kubernetes CRD, you can also use `kubectl apply`
|
|||
|
||||
### Customize
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
:::caution
|
||||
In most cases, you don't need to customize any definitions **unless you're going to extend the capability of KubeVela**. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.
|
||||
:::
|
||||
|
||||
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ description: Configure a helm repository
|
|||
|
||||
In this guide, we will introduce how to use Integration create a private helm repository and create a helm type application to use this repo.
|
||||
|
||||
Notice: You must enable the `fluxcd` addon firstly.
|
||||
:::note
|
||||
You must enable the `fluxcd` addon firstly.
|
||||
:::
|
||||
|
||||
## Create a helm repo
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,9 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
## Upgrade
|
||||
|
||||
> If you're trying to upgrade from a big version later (e.g. from 1.2.x to 1.4.x), please refer to [version migration](./system-operation/migration-from-old-version) for more guides.
|
||||
:::caution
|
||||
If you're trying to upgrade from a big version later (e.g. from 1.2.x to 1.4.x), please refer to [version migration](./system-operation/migration-from-old-version) for more guides.
|
||||
:::
|
||||
|
||||
### 1. Upgrade CLI
|
||||
|
||||
|
|
@ -30,7 +32,9 @@ curl -fsSl https://kubevela.io/script/install.sh | bash
|
|||
|
||||
**Windows**
|
||||
|
||||
> Only the official release version is supported.
|
||||
:::tip
|
||||
Pre-release versions will not be listed.
|
||||
:::
|
||||
|
||||
```shell script
|
||||
powershell -Command "iwr -useb https://kubevela.io/script/install.ps1 | iex"
|
||||
|
|
@ -63,10 +67,12 @@ brew install kubevela
|
|||
sudo mv ./vela /usr/local/bin/vela
|
||||
```
|
||||
|
||||
> [Installation Tips](https://github.com/kubevela/kubevela/issues/625):
|
||||
> If you are using a Mac system, it will pop up a warning that "vela" cannot be opened because the package from the developer cannot be verified.
|
||||
>
|
||||
> MacOS imposes stricter restrictions on the software that can run in the system. You can temporarily solve this problem by opening `System Preference ->Security & Privacy -> General` and clicking on `Allow Anyway`.
|
||||
:::caution
|
||||
[Installation Tips](https://github.com/kubevela/kubevela/issues/625):
|
||||
If you are using a Mac system, it will pop up a warning that "vela" cannot be opened because the package from the developer cannot be verified.
|
||||
|
||||
MacOS imposes stricter restrictions on the software that can run in the system. You can temporarily solve this problem by opening `System Preference ->Security & Privacy -> General` and clicking on `Allow Anyway`.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
@ -83,7 +89,9 @@ docker pull oamdev/vela-cli:latest
|
|||
|
||||
### 2. Upgrade Vela Core
|
||||
|
||||
> Please make sure you already upgraded the Vela CLI to latest stable version.
|
||||
:::note
|
||||
Please make sure you already upgraded the Vela CLI to latest stable version.
|
||||
:::
|
||||
|
||||
```shell
|
||||
vela install
|
||||
|
|
@ -95,7 +103,9 @@ vela install
|
|||
vela addon enable velaux
|
||||
```
|
||||
|
||||
> If you set custom parameters during installation, be sure to include the corresponding parameters.
|
||||
:::tip
|
||||
You can use advanced parameters provided by [addons](../reference/addons/overview).
|
||||
:::
|
||||
|
||||
## Uninstall
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ KubeVela has [release cadence](../../contributor/release-process) for every 2-3
|
|||
|
||||
## From v1.4.x to v1.5.x
|
||||
|
||||
> ⚠️ Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
:::caution
|
||||
Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -42,7 +44,9 @@ vela addon upgrade velaux --version 1.5.5
|
|||
|
||||
## From v1.3.x to v1.4.x
|
||||
|
||||
> ⚠️ Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -83,7 +87,9 @@ Please note if you're using terraform addon, you should upgrade the `terraform`
|
|||
|
||||
## From v1.2.x to v1.3.x
|
||||
|
||||
> ⚠️ Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -123,7 +129,9 @@ Please note if you're using terraform addon, you should upgrade the `terraform`
|
|||
|
||||
## From v1.1.x to v1.2.x
|
||||
|
||||
> ⚠️ Note: It will cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It will cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Check the service running normally
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Deploy First Application
|
||||
---
|
||||
|
||||
> Before starting, please confirm that you've installed KubeVela and enabled the VelaUX addon according to [the installation guide](./install).
|
||||
:::note
|
||||
Before starting, please confirm that you've installed KubeVela and enabled the VelaUX addon according to [the installation guide](./install).
|
||||
:::
|
||||
|
||||
Welcome to KubeVela! This section will guide you to deliver your first app.
|
||||
|
||||
|
|
@ -217,10 +219,9 @@ Great! You have finished deploying your first KubeVela application, you can also
|
|||
After finished [the installation of VelaUX](./install#2-install-velaux), you can view and manage the application created.
|
||||
|
||||
* Port forward the UI if you don't have endpoint for access:
|
||||
|
||||
```
|
||||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
```
|
||||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
|
||||
* VelaUX need authentication, default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,14 +9,13 @@ For more details, please refer to: [Kruise Rollout](https://github.com/openkruis
|
|||
## Installation
|
||||
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
## Uninstallation
|
||||
|
||||
```shell
|
||||
$ vela addon disable kruise-rollout
|
||||
vela addon disable kruise-rollout
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ title: Nginx Ingress Controller
|
|||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
**Notice: If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.**
|
||||
:::note
|
||||
If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.
|
||||
:::
|
||||
|
||||
## Install
|
||||
|
||||
|
|
|
|||
|
|
@ -259,7 +259,10 @@ EOF
|
|||
```
|
||||
|
||||
This Rollout Trait represents it will scale workload up to 7. You also can set every batch's number by setting `rolloutBatches`.
|
||||
Notice: A known issue exists if you scale up/down the workload twice or more times by not setting the `rolloutBatches`.So please set the `rolloutBatches` when scale up/down.
|
||||
|
||||
:::danger
|
||||
A known issue exists if you scale up/down the workload twice or more times by not setting the `rolloutBatches`.So please set the `rolloutBatches` when scale up/down.
|
||||
:::
|
||||
|
||||
Check the status after expansion has been succeed.
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Please access first-vela-app from the following endpoints:
|
|||
|
||||
</details>
|
||||
|
||||
-- `vela status --tree --detail` can list resources of your application.
|
||||
- `vela status --tree --detail` can list resources of your application.
|
||||
|
||||
```
|
||||
vela status first-vela-app --tree --detail
|
||||
|
|
@ -143,10 +143,8 @@ vela logs first-vela-app
|
|||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
+ nginx-basic-dfb6dcf8d-km5vk › nginx-basic
|
||||
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540430392Z /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
|
||||
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
|
||||
+ express-server-b768d95b7-qnwb4 › express-server
|
||||
express-server 2022-10-09T12:10:33.785549770+08:00 httpd started
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -156,17 +154,14 @@ nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-e
|
|||
- `vela exec` helps you execute commands in pods in managed clusters.
|
||||
|
||||
```bash
|
||||
vela exec basic-topology -n examples -it -- ls
|
||||
vela exec first-vela-app -it -- ls
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
bin docker-entrypoint.d home media proc sbin tmp
|
||||
boot docker-entrypoint.sh lib mnt root srv usr
|
||||
dev etc lib64 opt run sys var
|
||||
bin dev etc home proc root sys tmp usr var www
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -175,23 +170,11 @@ dev etc lib64 opt run sys var
|
|||
|
||||
- `vela port-forward` can discover and forward ports of pods or services in managed clusters to your local endpoint.
|
||||
|
||||
```bash
|
||||
vela port-forward basic-topology -n examples 8080:80
|
||||
```
|
||||
vela port-forward first-vela-app 8001:8000
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 4 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
Forwarding from 127.0.0.1:8080 -> 80
|
||||
Forwarding from [::1]:8080 -> 80
|
||||
|
||||
Forward successfully! Opening browser ...
|
||||
Handling connection for 8080
|
||||
```
|
||||
|
||||
</details>
|
||||
You can curl this app by `curl http://127.0.0.1:8001/`.
|
||||
|
||||
## More CLI Details
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ title: Canary Rollout
|
|||
|
||||
2. Make sure you have already enabled the [`kruise-rollout`](../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,9 @@ vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
|
|||
|
||||
Then check the deployment status of the application through `vela status helm-redis`
|
||||
|
||||
<details>
|
||||
<summary>expected output of vela status </summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
|
|
@ -96,6 +99,7 @@ Services:
|
|||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
> You can also check the application on UI, application created by CLI will be synced automatically but readonly.
|
||||
|
||||
|
|
@ -224,6 +228,8 @@ spec:
|
|||
version: '6.1.*'
|
||||
```
|
||||
|
||||
> Notice: your fluxcd addon version must be `>=1.3.1`.
|
||||
:::note
|
||||
Your fluxcd addon version must be `1.3.1+`.
|
||||
:::
|
||||
|
||||
Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -8,8 +8,7 @@ title: Canary Rollout
|
|||
|
||||
2. Make sure you have already enabled the [`kruise-rollout`](../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Delivery across Multi Environments
|
||||
title: Deploy across Multi Environments
|
||||
---
|
||||
|
||||
Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ EOF
|
|||
```
|
||||
|
||||
:::note
|
||||
Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
The application created by CLI will be synced to UI automatically.
|
||||
:::
|
||||
|
||||
You can also save the YAML file as webservice-app.yaml and use the `vela up -f webservice-app.yaml` command to deploy.
|
||||
|
|
|
|||
|
|
@ -310,7 +310,7 @@
|
|||
"sidebar.docs.category.Kubernetes Manifest CD": {
|
||||
"message": "Kubernetes 资源交付"
|
||||
},
|
||||
"sidebar.docs.category.Delivery Policies": {
|
||||
"sidebar.docs.category.CD Policies": {
|
||||
"message": "资源交付策略"
|
||||
},
|
||||
"sidebar.docs.category.UX Customization": {
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
# KubeVela Dashboard (WIP)
|
||||
|
||||
KubeVela has a simple client side dashboard for you to interact with. The functionality is equivalent to the vela cli.
|
||||
|
||||
```bash
|
||||
$ vela dashboard
|
||||
```
|
||||
|
||||
> NOTE: this feature is still under development.
|
||||
|
|
@ -9,8 +9,7 @@ title: 金丝雀发布
|
|||
1. 通过如下命令启用 [`kruise-rollout`](../../reference/addons/kruise-rollout) 插件，金丝雀发布依赖于 [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
2. 请确保在集群中至少安装一种 [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/)。
|
||||
|
|
|
|||
|
|
@ -10,13 +10,18 @@ title: 暂停和继续
|
|||
|
||||
### 手动暂停
|
||||
|
||||
如果你有一个正在运行的应用，并且你希望暂停它的执行，你可以使用 `vela workflow suspend` 来暂停该工作流。
|
||||
如果你有一个正在运行工作流的应用，并且你希望暂停它的执行，你可以使用 `vela workflow suspend` 来暂停该工作流，在未来可以通过 `vela workflow resume` 继续工作流。
|
||||
|
||||
* 暂停工作流
|
||||
|
||||
```bash
|
||||
$ vela workflow suspend my-app
|
||||
Successfully suspend workflow: my-app
|
||||
vela workflow suspend my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
如果工作流已经执行完毕，对应用使用 `vela workflow suspend` 命令不会产生任何效果。
|
||||
:::
|
||||
|
||||
### 使用暂停步骤
|
||||
|
||||
部署如下例子：
|
||||
|
|
@ -25,7 +30,7 @@ Successfully suspend workflow: my-app
|
|||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: suspend
|
||||
name: suspend-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
|
|
@ -56,10 +61,16 @@ spec:
|
|||
使用 vela status 命令查看应用状态：
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
|
@ -75,12 +86,10 @@ Workflow:
|
|||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:running
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
|
|
@ -102,17 +111,22 @@ Services:
|
|||
以上面处于暂停状态的应用为例：
|
||||
|
||||
```bash
|
||||
$ vela workflow resume suspend
|
||||
Successfully resume workflow: suspend
|
||||
vela workflow resume suspend-demo
|
||||
```
|
||||
|
||||
成功继续工作流后，查看应用的状态：
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: running
|
||||
|
|
@ -154,6 +168,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
可以看到，工作流已经继续执行完毕。
|
||||
|
||||
|
|
@ -161,11 +176,28 @@ Services:
|
|||
|
||||
当工作流处于暂停状态时，如果你想终止它，你可以使用 `vela workflow terminate` 命令来终止工作流。
|
||||
|
||||
* 终止工作流
|
||||
|
||||
```bash
|
||||
$ vela workflow terminate my-app
|
||||
Successfully terminate workflow: my-app
|
||||
vela workflow terminate my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
区别于暂停，终止的工作流不能继续执行，只能重新运行工作流。重新运行意味着工作流会重新开始执行所有工作流步骤，而继续工作流则是从暂停的步骤后面继续执行。
|
||||
:::
|
||||
|
||||
* 重新运行工作流
|
||||
|
||||
```bash
|
||||
vela workflow restart my-app
|
||||
```
|
||||
|
||||
:::caution
|
||||
一旦应用被终止，KubeVela 控制器不会再对资源做状态维持，你可以对底层资源做手动修改但请注意防止配置漂移。
|
||||
:::
|
||||
|
||||
工作流执行完毕进入正常运行状态的应用无法被终止或重新运行。
|
||||
|
||||
### 自动继续工作流
|
||||
|
||||
如果你希望经过了一段时间后，工作流能够自动被继续。那么，你可以在 `suspend` 步骤中加上 `duration` 参数。当 `duration` 时间超过后，工作流将自动继续执行。
|
||||
|
|
@ -209,7 +241,13 @@ spec:
|
|||
查看应用状态：
|
||||
|
||||
```bash
|
||||
$ vela status auto-resume
|
||||
vela status auto-resume
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: auto-resume
|
||||
|
|
@ -254,5 +292,6 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
可以看到，`suspend` 步骤在五秒后自动执行成功，继续了工作流。
|
||||
|
|
|
|||
|
|
@ -310,7 +310,7 @@
|
|||
"sidebar.docs.category.Kubernetes Manifest CD": {
|
||||
"message": "Kubernetes 资源交付"
|
||||
},
|
||||
"sidebar.docs.category.Delivery Policies": {
|
||||
"sidebar.docs.category.CD Policies": {
|
||||
"message": "资源交付策略"
|
||||
},
|
||||
"sidebar.docs.category.UX Customization": {
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
# KubeVela Dashboard (WIP)
|
||||
|
||||
KubeVela has a simple client side dashboard for you to interact with. The functionality is equivalent to the vela cli.
|
||||
|
||||
```bash
|
||||
$ vela dashboard
|
||||
```
|
||||
|
||||
> NOTE: this feature is still under development.
|
||||
|
|
@ -9,8 +9,7 @@ title: 金丝雀发布
|
|||
1. 通过如下命令启用 [`kruise-rollout`](../../reference/addons/kruise-rollout) 插件，金丝雀发布依赖于 [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
2. 请确保在集群中至少安装一种 [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/)。
|
||||
|
|
|
|||
|
|
@ -10,13 +10,18 @@ title: 暂停和继续
|
|||
|
||||
### 手动暂停
|
||||
|
||||
如果你有一个正在运行的应用，并且你希望暂停它的执行，你可以使用 `vela workflow suspend` 来暂停该工作流。
|
||||
如果你有一个正在运行工作流的应用，并且你希望暂停它的执行，你可以使用 `vela workflow suspend` 来暂停该工作流，在未来可以通过 `vela workflow resume` 继续工作流。
|
||||
|
||||
* 暂停工作流
|
||||
|
||||
```bash
|
||||
$ vela workflow suspend my-app
|
||||
Successfully suspend workflow: my-app
|
||||
vela workflow suspend my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
如果工作流已经执行完毕，对应用使用 `vela workflow suspend` 命令不会产生任何效果。
|
||||
:::
|
||||
|
||||
### 使用暂停步骤
|
||||
|
||||
部署如下例子：
|
||||
|
|
@ -25,7 +30,7 @@ Successfully suspend workflow: my-app
|
|||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: suspend
|
||||
name: suspend-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
|
|
@ -56,10 +61,16 @@ spec:
|
|||
使用 vela status 命令查看应用状态：
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
|
@ -75,12 +86,10 @@ Workflow:
|
|||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:running
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
|
|
@ -102,17 +111,22 @@ Services:
|
|||
以上面处于暂停状态的应用为例：
|
||||
|
||||
```bash
|
||||
$ vela workflow resume suspend
|
||||
Successfully resume workflow: suspend
|
||||
vela workflow resume suspend-demo
|
||||
```
|
||||
|
||||
成功继续工作流后，查看应用的状态：
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: running
|
||||
|
|
@ -154,6 +168,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
可以看到，工作流已经继续执行完毕。
|
||||
|
||||
|
|
@ -161,11 +176,28 @@ Services:
|
|||
|
||||
当工作流处于暂停状态时，如果你想终止它，你可以使用 `vela workflow terminate` 命令来终止工作流。
|
||||
|
||||
* 终止工作流
|
||||
|
||||
```bash
|
||||
$ vela workflow terminate my-app
|
||||
Successfully terminate workflow: my-app
|
||||
vela workflow terminate my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
区别于暂停，终止的工作流不能继续执行，只能重新运行工作流。重新运行意味着工作流会重新开始执行所有工作流步骤，而继续工作流则是从暂停的步骤后面继续执行。
|
||||
:::
|
||||
|
||||
* 重新运行工作流
|
||||
|
||||
```bash
|
||||
vela workflow restart my-app
|
||||
```
|
||||
|
||||
:::caution
|
||||
一旦应用被终止，KubeVela 控制器不会再对资源做状态维持，你可以对底层资源做手动修改但请注意防止配置漂移。
|
||||
:::
|
||||
|
||||
工作流执行完毕进入正常运行状态的应用无法被终止或重新运行。
|
||||
|
||||
### 自动继续工作流
|
||||
|
||||
如果你希望经过了一段时间后，工作流能够自动被继续。那么，你可以在 `suspend` 步骤中加上 `duration` 参数。当 `duration` 时间超过后，工作流将自动继续执行。
|
||||
|
|
@ -209,7 +241,13 @@ spec:
|
|||
查看应用状态：
|
||||
|
||||
```bash
|
||||
$ vela status auto-resume
|
||||
vela status auto-resume
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>期望输出</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: auto-resume
|
||||
|
|
@ -254,5 +292,6 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
可以看到，`suspend` 步骤在五秒后自动执行成功，继续了工作流。
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ module.exports = {
|
|||
items: ['end-user/gitops/fluxcd'],
|
||||
},
|
||||
{
|
||||
'Delivery Policies': [
|
||||
'CD Policies': [
|
||||
'end-user/policies/shared-resource',
|
||||
'end-user/policies/apply-once',
|
||||
'end-user/policies/gc',
|
||||
|
|
@ -307,8 +307,11 @@ module.exports = {
|
|||
{
|
||||
type: 'category',
|
||||
label: 'Community Verified Addons',
|
||||
link: {
|
||||
type: "doc",
|
||||
id: 'reference/addons/overview'
|
||||
},
|
||||
items: [
|
||||
'reference/addons/overview',
|
||||
'reference/addons/velaux',
|
||||
'reference/addons/rollout',
|
||||
'reference/addons/fluxcd',
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ description: Configure a helm repository
|
|||
|
||||
In this guide, we will introduce how to use Integration create a private helm repository and create a helm type application to use this repo.
|
||||
|
||||
Notice: You must enable the `fluxcd` addon firstly.
|
||||
:::note
|
||||
You must enable the `fluxcd` addon firstly.
|
||||
:::
|
||||
|
||||
## Create a helm repo
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Overview of GitOps
|
||||
---
|
||||
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
:::note
|
||||
This section will introduce how to use KubeVela in GitOps area and why.
|
||||
:::
|
||||
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with "git-centric" operations such as PR and commit. For detailed benefits of GitOps, you can refer to [this blog](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true
|
|||
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true
|
||||
```
|
||||
|
||||
> By default, the hub cluster where KubeVela locates is registered as the `local` cluster. You can use it like a managed cluster in spite that you cannot detach it or modify it.
|
||||
:::note
|
||||
By default, the hub cluster where KubeVela locates is registered as the `local` cluster. You can use it like a managed cluster in spite that you cannot detach it or modify it.
|
||||
:::
|
||||
|
||||
## Deliver Application to Clusters
|
||||
|
||||
|
|
@ -197,8 +199,9 @@ spec:
|
|||
namespace: examples-alternative
|
||||
```
|
||||
|
||||
> Sometimes, for security issues, you might want to disable this behavior and retrict the resources to be deployed within the same namespace of the application. This can be done by setting `--allow-cross-namespace-resource=false` in the bootstrap parameter of the KubeVela controller.
|
||||
|
||||
:::tip
|
||||
Sometimes, for security issues, you might want to disable this behavior and retrict the resources to be deployed within the same namespace of the application. This can be done by setting `--allow-cross-namespace-resource=false` in the [bootstrap parameter](../platform-engineers/system-operation/bootstrap-parameters) of the KubeVela controller.
|
||||
:::
|
||||
|
||||
### Control the deploy workflow
|
||||
|
||||
|
|
@ -336,7 +339,9 @@ spec:
|
|||
policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
|
||||
```
|
||||
|
||||
> NOTE: The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
|
||||
:::note
|
||||
The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
|
||||
:::
|
||||
|
||||
The override policy has many advanced capabilities, such as adding new component or selecting components to use.
|
||||
The following example will first deploy an nginx webservice with `nginx:1.20` image to local cluster. Then two nginx webservices with `nginx` and `nginx:stable` images will be deployed to hangzhou clusters respectively.
|
||||
|
|
@ -399,7 +404,9 @@ spec:
|
|||
Sometimes, you may want to use the same policy across multiple applications or reuse previous workflow to deploy different resources.
|
||||
To reduce the repeated code, you can leverage the external policies and workflow and refer to them in your applications.
|
||||
|
||||
> NOTE: you can only refer to Policy and Workflow within your application's namespace.
|
||||
:::caution
|
||||
You can only refer to Policy and Workflow within your application's namespace.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
|
|
@ -455,7 +462,11 @@ spec:
|
|||
ref: make-release-in-hangzhou
|
||||
```
|
||||
|
||||
> NOTE: The internal policies will be loaded first. External policies will only be used when there is no corresponding policy inside the application. In the following example, we can reuse `topology-hangzhou-clusters` policy and `make-release-in-hangzhou` workflow but modify the `override-high-availability-webservice` policy by injecting the same-named policy inside the new application.
|
||||
:::note
|
||||
The internal policies will be loaded first. External policies will only be used when there is no corresponding policy inside the application.
|
||||
:::
|
||||
|
||||
In the following example, we can reuse `topology-hangzhou-clusters` policy and `make-release-in-hangzhou` workflow but modify the `override-high-availability-webservice` policy by injecting the same-named policy inside the new application.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
|
|||
|
|
@ -167,7 +167,9 @@ To run vela-core locally for debugging with kubevela installed in the remote clu
|
|||
|
||||
Finally, you can use the commands in the above [Build](#build) and [Testing](#Testing) sections, such as `make run`, to code and debug in your local machine.
|
||||
|
||||
> Note you will not be able to test features relate with validating/mutating webhooks in this way.
|
||||
:::caution
|
||||
Note you will not be able to test features relate with validating/mutating webhooks in this way.
|
||||
:::
|
||||
|
||||
## Run VelaUX Locally
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ contains the following attributes: name, character_set, description.
|
|||
|
||||
Applying the following application can create more than one database in an RDS instance.
|
||||
|
||||
> ⚠️ This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::caution
|
||||
This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@ title: Provision and Binding Database
|
|||
|
||||
This tutorial will talk about how to provision and consume Alibaba Cloud RDS (and OSS) by Terraform.
|
||||
|
||||
> ⚠️ This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::caution
|
||||
This section requires your platform engineers have already enabled [cloud resources addon](../../../reference/addons/terraform).
|
||||
:::
|
||||
|
||||
Let's deploy the [application](https://github.com/kubevela/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/application.yaml)
|
||||
below to provision Alibaba Cloud OSS and RDS cloud resources, and consume them by the web component.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,9 @@ Once addon installed, end user can discover and use these capabilities immediate
|
|||
|
||||
### Uninstall Addon
|
||||
|
||||
> Please make sure the addon along with its capabilities is no longer used in any of your applications before uninstalling it.
|
||||
:::danger
|
||||
Please make sure the addon along with its capabilities is no longer used in any of your applications before uninstalling it.
|
||||
:::
|
||||
|
||||
```shell
|
||||
vela addon disable fluxcd
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Distribute Reference Objects
|
||||
---
|
||||
|
||||
> This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
:::note
|
||||
This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
:::
|
||||
|
||||
You can reference and distribute existing Kubernetes objects with KubeVela in the following scenarios:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: One-time Delivery(Working With Other Controllers)
|
||||
title: One-time Delivery (Coordinate with Multi-Controllers)
|
||||
---
|
||||
|
||||
By default, the KubeVela controller will prevent configuration drift for applied resources by reconciling them routinely. This is useful if you want to keep your application always having the desired configuration to avoid some unintentional changes by external modifiers.
|
||||
|
|
|
|||
|
|
@ -10,8 +10,10 @@ In garbage-collect policy, there are two major capabilities you can use.
|
|||
|
||||
Suppose you want to keep the resources created by the old version of the application. Use the garbage-collect policy and enable the option `keepLegacyResource`.
|
||||
|
||||
```yaml
|
||||
# app.yaml
|
||||
1. create app
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
@ -24,9 +26,10 @@ spec:
|
|||
image: oamdev/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
class: traefik
|
||||
domain: 47.251.8.82.nip.io
|
||||
http:
|
||||
"/": 8000
|
||||
policies:
|
||||
|
|
@ -34,24 +37,31 @@ spec:
|
|||
type: garbage-collect
|
||||
properties:
|
||||
keepLegacyResource: true
|
||||
EOF
|
||||
```
|
||||
|
||||
1. create app
|
||||
|
||||
``` shell
|
||||
vela up -f app.yaml
|
||||
```
|
||||
Check the status:
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
first-vela-app express-server webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST
|
||||
vela status first-vela-app --tree
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
local ─── default ─┬─ Service/express-server updated
|
||||
├─ Deployment/express-server updated
|
||||
└─ Ingress/express-server updated
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
2. update the app
|
||||
|
||||
```yaml
|
||||
# app1.yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
@ -64,9 +74,10 @@ spec:
|
|||
image: oamdev/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
class: traefik
|
||||
domain: 47.251.8.82.nip.io
|
||||
http:
|
||||
"/": 8000
|
||||
policies:
|
||||
|
|
@ -74,50 +85,30 @@ spec:
|
|||
type: garbage-collect
|
||||
properties:
|
||||
keepLegacyResource: true
|
||||
EOF
|
||||
```
|
||||
|
||||
``` shell
|
||||
vela up -f app1.yaml
|
||||
```
|
||||
Check the status again:
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
first-vela-app express-server-1 webservice ingress-1-20 running healthy Ready:1/1 2022-04-06 16:20:25 +0800 CST
|
||||
vela status first-vela-app --tree
|
||||
```
|
||||
|
||||
check whether legacy resources are reserved.
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
> In the following steps, we'll use `kubectl` command to do some verification. You can also use `vela status first-vela-app` to check the aggregated application status and see if components are healthy.
|
||||
```shell
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
local ─── default ─┬─ Service/express-server outdated
|
||||
├─ Service/express-server-1 updated
|
||||
├─ Deployment/express-server outdated
|
||||
├─ Deployment/express-server-1 updated
|
||||
├─ Ingress/express-server outdated
|
||||
└─ Ingress/express-server-1 updated
|
||||
```
|
||||
</details>
|
||||
|
||||
```
|
||||
$ kubectl get deploy
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 10m
|
||||
express-server-1 1/1 1 1 40s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
express-server ClusterIP 10.96.102.249 <none> 8000/TCP 10m
|
||||
express-server-1 ClusterIP 10.96.146.10 <none> 8000/TCP 46s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com 80 10m
|
||||
express-server-1 <none> testsvc.example.com 80 50s
|
||||
```
|
||||
|
||||
```
|
||||
$ kubectl get resourcetracker
|
||||
NAME AGE
|
||||
first-vela-app-default 12m
|
||||
first-vela-app-v1-default 12m
|
||||
first-vela-app-v2-default 2m56s
|
||||
```
|
||||
You can see the legacy resources are reserved but the status is outdated, it will not be synced by periodically reconciliation.
|
||||
|
||||
3. delete the app
|
||||
|
||||
|
|
@ -127,20 +118,21 @@ $ vela delete first-vela-app
|
|||
|
||||
> If you hope to delete resources in one specified version, you can run `kubectl delete resourcetracker first-vela-app-v1-default`.
|
||||
|
||||
## Persist resources
|
||||
## Persist partial resources
|
||||
|
||||
You can also persist some resources, which skips the normal garbage-collect process when the application is updated.
|
||||
You can also persist part of the resources, which skips the normal garbage-collect process when the application is updated.
|
||||
|
||||
Take the following app as an example, in the garbage-collect policy, a rule is added which marks all the resources created by the `expose` trait to use the `onAppDelete` strategy. This will keep those services until application is deleted.
|
||||
|
||||
```shell
|
||||
$ cat <<EOF | vela up -f -
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: garbage-collect-app
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world
|
||||
- name: demo-gc
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/hello-world
|
||||
|
|
@ -161,6 +153,7 @@ EOF
|
|||
```
|
||||
|
||||
You can find deployment and service created.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
|
|
@ -171,8 +164,9 @@ hello-world ClusterIP 10.96.160.208 <none> 8000/TCP 78s
|
|||
```
|
||||
|
||||
If you upgrade the application and use a different component, you will find the old versioned deployment is deleted but the service is kept.
|
||||
|
||||
```shell
|
||||
$ cat <<EOF | vela up -f -
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -105,6 +105,7 @@ Hello World
|
|||
</xmp>
|
||||
```
|
||||
|
||||
> ⚠️ This section requires your runtime cluster has a working ingress controller.
|
||||
|
||||
:::caution
|
||||
This section requires your runtime cluster has a working ingress controller.
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ In this section, we will introduce how to canary rollout a container service.
|
|||
|
||||
1. Enable [`kruise-rollout`](../../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your cluster.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,10 @@ And check the logging output of sidecar.
|
|||
```shell
|
||||
vela logs vela-app-with-sidecar -c count-log
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```console
|
||||
0: Fri Apr 16 11:08:45 UTC 2021
|
||||
1: Fri Apr 16 11:08:46 UTC 2021
|
||||
|
|
@ -80,3 +84,4 @@ vela logs vela-app-with-sidecar -c count-log
|
|||
9: Fri Apr 16 11:08:54 UTC 2021
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -9,7 +9,7 @@ title: Application Version Control
|
|||
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.
|
||||
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.
|
||||
|
|
@ -17,13 +17,15 @@ The annotation, which is noted as *publishVersion* in the following paragraphs,
|
|||
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.
|
||||
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 `publishVersion` 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.
|
||||
:::tip
|
||||
We use reference of external workflow and policies, it works the same. You can refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for more details.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -78,10 +80,16 @@ steps:
|
|||
policies: ["topology-hangzhou-clusters", "override-high-availability"]
|
||||
```
|
||||
|
||||
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`.
|
||||
You can check the application status by:
|
||||
|
||||
```shell
|
||||
$ vela status podinfo -n examples
|
||||
vela status podinfo -n examples
|
||||
vela status podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: podinfo
|
||||
|
|
@ -116,23 +124,43 @@ Services:
|
|||
Unhealthy Ready:0/3
|
||||
Traits:
|
||||
✅ scaler
|
||||
```
|
||||
</details>
|
||||
|
||||
$ vela status podinfo -n examples --tree --detail
|
||||
View all the related real-time resources by:
|
||||
|
||||
```
|
||||
vela status podinfo -n examples --tree --detail
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
</details>
|
||||
|
||||
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.
|
||||
|
||||
### Inspect Changes across Revisions
|
||||
|
||||
Now let's run `vela live-diff podinfo -n examples` to check this diff
|
||||
```bash
|
||||
$ vela live-diff podinfo -n examples
|
||||
You can run `vela live-diff` to check revision difference:
|
||||
|
||||
```
|
||||
vela live-diff podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```yaml
|
||||
* Application (podinfo) has been modified(*)
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
|
|
@ -156,64 +184,129 @@ $ vela live-diff podinfo -n examples
|
|||
* 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.
|
||||
|
||||
### Publish a new app with specified revision
|
||||
|
||||
There are two ways to publish an app with specified revision. 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.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: podinfo
|
||||
namespace: examples
|
||||
annotations:
|
||||
- app.oam.dev/publishVersion: alpha1
|
||||
+ app.oam.dev/publishVersion: alpha2
|
||||
...
|
||||
```
|
||||
2. Run `vela up --publish-version <revision-name` to publish the new version.
|
||||
```
|
||||
vela up podinfo -n examples --publish-version alpha2
|
||||
```
|
||||
|
||||
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.
|
||||
Now we can run `vela revision list` to list all the available revisions.
|
||||
|
||||
```
|
||||
vela revision list podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
### 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`.
|
||||
Before rolling back, we need to suspend the workflow of the application first.
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
```
|
||||
vela workflow rollback podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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.
|
||||
```
|
||||
</details>
|
||||
|
||||
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
|
||||
vela status podinfo -n examples --tree --detail --detail-format wide
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
</details>
|
||||
|
||||
### Re-publish a History Revision
|
||||
|
||||
> This feature is introduced after v1.3.1.
|
||||
|
||||
:::note
|
||||
This feature is introduced after v1.3+.
|
||||
:::
|
||||
|
||||
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.
|
||||
|
||||
Let's list the history revision by:
|
||||
|
||||
```shell
|
||||
vela revision list podinfo -n examples
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```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.
|
||||
</details>
|
||||
|
||||
Alternatively, you can directly run the following command to rollback to a specified revision:
|
||||
|
||||
```
|
||||
vela up podinfo -n examples --revision podinfo-v1 --publish-version beta1
|
||||
```
|
||||
|
||||
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
|
||||
|
|
@ -225,4 +318,6 @@ podinfo-v4 beta1 true 65844934c2d07288 2022-04-
|
|||
|
||||
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.
|
||||
:::info
|
||||
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](../platform-engineers/system-operation/bootstrap-parameters) of KubeVela controller.
|
||||
:::
|
||||
|
|
@ -4,7 +4,9 @@ title: Component Orchestration
|
|||
|
||||
This section will introduce the dependencies in components and how to pass data between components.
|
||||
|
||||
> We use `helm` component type in the following examples, make sure you have the `fluxcd` addon enabled (`vela addon enable fluxcd`).
|
||||
:::tip
|
||||
We use `helm` component type in the following examples, make sure you have the `fluxcd` addon enabled (`vela addon enable fluxcd`).
|
||||
:::
|
||||
|
||||
## Dependency
|
||||
|
||||
|
|
@ -99,9 +101,9 @@ mysql mysql-secret raw running healthy 2021-10-14 12:09:55 +0
|
|||
|
||||
After a while, all components is running successfully. The `mysql-cluster` will be deployed after `mysql-controller` and `mysql-secret` is `healthy`.
|
||||
|
||||
> `dependsOn` use `healthy` to check status. If the component is `healthy`, then KubeVela will deploy the next component.
|
||||
> If you want to customize the healthy status of the component, please refer to [Status Write Back](../../platform-engineers/traits/status)
|
||||
|
||||
:::info
|
||||
`dependsOn` use `healthy` to check status. If the component is `healthy`, then KubeVela will deploy the next component. If you want to customize the healthy status of the component, please refer to [Status Write Back](../../platform-engineers/traits/status)
|
||||
:::
|
||||
|
||||
## Inputs and Outputs
|
||||
|
||||
|
|
|
|||
|
|
@ -10,13 +10,18 @@ In KubeVela, you can choose to use the `vela` command to manually suspend the ex
|
|||
|
||||
### Suspend Manually
|
||||
|
||||
If you have a running application and you want to suspend its execution, you can use `vela workflow suspend` to suspend the workflow.
|
||||
If you have an application in `runningWorkflow` state, you want to stop the execution of the workflow, you can use `vela workflow suspend` to stop the workflow and use `vela workflow resume` to continue it.
|
||||
|
||||
* Suspend the application
|
||||
|
||||
```bash
|
||||
$ vela workflow suspend my-app
|
||||
Successfully suspend workflow: my-app
|
||||
vela workflow suspend my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
Nothing will happen if you suspend an application that has already finished running workflow, which is in `running` status.
|
||||
:::
|
||||
|
||||
### Use Suspend Step
|
||||
|
||||
Apply the following example:
|
||||
|
|
@ -25,7 +30,7 @@ Apply the following example:
|
|||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: suspend
|
||||
name: suspend-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
|
|
@ -56,10 +61,16 @@ spec:
|
|||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
|
@ -75,12 +86,10 @@ Workflow:
|
|||
name:apply1
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xvmda4he5e
|
||||
name:suspend
|
||||
type:suspend
|
||||
phase:running
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
|
|
@ -90,6 +99,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, when the first step is completed, the `suspend` step will be executed and this step will suspend the workflow.
|
||||
|
||||
|
|
@ -102,17 +112,22 @@ Once the workflow is suspended, you can use the `vela workflow resume` command t
|
|||
Take the above suspended application as an example:
|
||||
|
||||
```bash
|
||||
$ vela workflow resume suspend
|
||||
Successfully resume workflow: suspend
|
||||
vela workflow resume suspend-demo
|
||||
```
|
||||
|
||||
After successfully continuing the workflow, view the status of the app:
|
||||
|
||||
```bash
|
||||
$ vela status suspend
|
||||
vela status suspend-demo
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: suspend
|
||||
Name: suspend-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-27 17:36:58 +0800 CST
|
||||
Status: running
|
||||
|
|
@ -154,6 +169,7 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, the workflow has continued to execute.
|
||||
|
||||
|
|
@ -161,11 +177,28 @@ As you can see, the workflow has continued to execute.
|
|||
|
||||
If you want to terminate a workflow while it is suspended, you can use the `vela workflow terminate` command to terminate the workflow.
|
||||
|
||||
* Terminate the application workflow
|
||||
|
||||
```bash
|
||||
$ vela workflow terminate my-app
|
||||
Successfully terminate workflow: my-app
|
||||
vela workflow terminate my-app
|
||||
```
|
||||
|
||||
:::tip
|
||||
Different from suspend, the terminated application workflow can't be resumed, you can only restart the workflow. This means restart the workflow will execute the workflow steps from scratch while resume workflow only continue the unfinished steps.
|
||||
:::
|
||||
|
||||
* Restart the application workflow
|
||||
|
||||
```bash
|
||||
vela workflow restart my-app
|
||||
```
|
||||
|
||||
:::caution
|
||||
Once application is terminated, KubeVela controller won't reconcile the application resources. It can also be used in some cases when you want to manually operate the underlying resources, please caution the configuration drift.
|
||||
:::
|
||||
|
||||
Once application come into `running` status, it can't be terminated or restarted.
|
||||
|
||||
### Resume the Workflow Automatically
|
||||
|
||||
If you want the workflow to be continued automatically after a period of time has passed. Then, you can add a `duration` parameter to the `suspend` step. When the `duration` time elapses, the workflow will automatically continue execution.
|
||||
|
|
@ -209,7 +242,13 @@ spec:
|
|||
Use `vela status` to check the status of the Application:
|
||||
|
||||
```bash
|
||||
$ vela status auto-resume
|
||||
vela status auto-resume
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: auto-resume
|
||||
|
|
@ -254,5 +293,6 @@ Services:
|
|||
Healthy Ready:1/1
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
As you can see, the `suspend` step is automatically executed successfully after five seconds, and the workflow is executed successfully.
|
||||
|
|
|
|||
|
|
@ -164,7 +164,9 @@ Application is also one kind of Kubernetes CRD, you can also use `kubectl apply`
|
|||
|
||||
### Customize
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
:::caution
|
||||
In most cases, you don't need to customize any definitions **unless you're going to extend the capability of KubeVela**. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.
|
||||
:::
|
||||
|
||||
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ description: Configure a helm repository
|
|||
|
||||
In this guide, we will introduce how to use Integration create a private helm repository and create a helm type application to use this repo.
|
||||
|
||||
Notice: You must enable the `fluxcd` addon firstly.
|
||||
:::note
|
||||
You must enable the `fluxcd` addon firstly.
|
||||
:::
|
||||
|
||||
## Create a helm repo
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,9 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
## Upgrade
|
||||
|
||||
> If you're trying to upgrade from a big version later (e.g. from 1.2.x to 1.4.x), please refer to [version migration](./system-operation/migration-from-old-version) for more guides.
|
||||
:::caution
|
||||
If you're trying to upgrade from a big version later (e.g. from 1.2.x to 1.4.x), please refer to [version migration](./system-operation/migration-from-old-version) for more guides.
|
||||
:::
|
||||
|
||||
### 1. Upgrade CLI
|
||||
|
||||
|
|
@ -30,7 +32,9 @@ curl -fsSl https://kubevela.io/script/install.sh | bash
|
|||
|
||||
**Windows**
|
||||
|
||||
> Only the official release version is supported.
|
||||
:::tip
|
||||
Pre-release versions will not be listed.
|
||||
:::
|
||||
|
||||
```shell script
|
||||
powershell -Command "iwr -useb https://kubevela.io/script/install.ps1 | iex"
|
||||
|
|
@ -63,10 +67,12 @@ brew install kubevela
|
|||
sudo mv ./vela /usr/local/bin/vela
|
||||
```
|
||||
|
||||
> [Installation Tips](https://github.com/kubevela/kubevela/issues/625):
|
||||
> If you are using a Mac system, it will pop up a warning that "vela" cannot be opened because the package from the developer cannot be verified.
|
||||
>
|
||||
> MacOS imposes stricter restrictions on the software that can run in the system. You can temporarily solve this problem by opening `System Preference ->Security & Privacy -> General` and clicking on `Allow Anyway`.
|
||||
:::caution
|
||||
[Installation Tips](https://github.com/kubevela/kubevela/issues/625):
|
||||
If you are using a Mac system, it will pop up a warning that "vela" cannot be opened because the package from the developer cannot be verified.
|
||||
|
||||
MacOS imposes stricter restrictions on the software that can run in the system. You can temporarily solve this problem by opening `System Preference ->Security & Privacy -> General` and clicking on `Allow Anyway`.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
@ -83,7 +89,9 @@ docker pull oamdev/vela-cli:latest
|
|||
|
||||
### 2. Upgrade Vela Core
|
||||
|
||||
> Please make sure you already upgraded the Vela CLI to latest stable version.
|
||||
:::note
|
||||
Please make sure you already upgraded the Vela CLI to latest stable version.
|
||||
:::
|
||||
|
||||
```shell
|
||||
vela install
|
||||
|
|
@ -95,7 +103,9 @@ vela install
|
|||
vela addon enable velaux
|
||||
```
|
||||
|
||||
> If you set custom parameters during installation, be sure to include the corresponding parameters.
|
||||
:::tip
|
||||
You can use advanced parameters provided by [addons](../reference/addons/overview).
|
||||
:::
|
||||
|
||||
## Uninstall
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ KubeVela has [release cadence](../../contributor/release-process) for every 2-3
|
|||
|
||||
## From v1.4.x to v1.5.x
|
||||
|
||||
> ⚠️ Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
:::caution
|
||||
Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -42,7 +44,9 @@ vela addon upgrade velaux --version 1.5.5
|
|||
|
||||
## From v1.3.x to v1.4.x
|
||||
|
||||
> ⚠️ Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -83,7 +87,9 @@ Please note if you're using terraform addon, you should upgrade the `terraform`
|
|||
|
||||
## From v1.2.x to v1.3.x
|
||||
|
||||
> ⚠️ Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It may cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
||||
|
|
@ -123,7 +129,9 @@ Please note if you're using terraform addon, you should upgrade the `terraform`
|
|||
|
||||
## From v1.1.x to v1.2.x
|
||||
|
||||
> ⚠️ Note: It will cause application workflow rerun when controller upgrade.
|
||||
:::danger
|
||||
Note: It will cause application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Check the service running normally
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: Deploy First Application
|
||||
---
|
||||
|
||||
> Before starting, please confirm that you've installed KubeVela and enabled the VelaUX addon according to [the installation guide](./install).
|
||||
:::note
|
||||
Before starting, please confirm that you've installed KubeVela and enabled the VelaUX addon according to [the installation guide](./install).
|
||||
:::
|
||||
|
||||
Welcome to KubeVela! This section will guide you to deliver your first app.
|
||||
|
||||
|
|
@ -217,10 +219,9 @@ Great! You have finished deploying your first KubeVela application, you can also
|
|||
After finished [the installation of VelaUX](./install#2-install-velaux), you can view and manage the application created.
|
||||
|
||||
* Port forward the UI if you don't have endpoint for access:
|
||||
|
||||
```
|
||||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
```
|
||||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
|
||||
* VelaUX need authentication, default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,14 +9,13 @@ For more details, please refer to: [Kruise Rollout](https://github.com/openkruis
|
|||
## Installation
|
||||
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
## Uninstallation
|
||||
|
||||
```shell
|
||||
$ vela addon disable kruise-rollout
|
||||
vela addon disable kruise-rollout
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ title: Nginx Ingress Controller
|
|||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
**Notice: If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.**
|
||||
:::note
|
||||
If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.
|
||||
:::
|
||||
|
||||
## Install
|
||||
|
||||
|
|
|
|||
|
|
@ -259,7 +259,10 @@ EOF
|
|||
```
|
||||
|
||||
This Rollout Trait represents it will scale workload up to 7. You also can set every batch's number by setting `rolloutBatches`.
|
||||
Notice: A known issue exists if you scale up/down the workload twice or more times by not setting the `rolloutBatches`.So please set the `rolloutBatches` when scale up/down.
|
||||
|
||||
:::danger
|
||||
A known issue exists if you scale up/down the workload twice or more times by not setting the `rolloutBatches`.So please set the `rolloutBatches` when scale up/down.
|
||||
:::
|
||||
|
||||
Check the status after expansion has been succeed.
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Please access first-vela-app from the following endpoints:
|
|||
|
||||
</details>
|
||||
|
||||
-- `vela status --tree --detail` can list resources of your application.
|
||||
- `vela status --tree --detail` can list resources of your application.
|
||||
|
||||
```
|
||||
vela status first-vela-app --tree --detail
|
||||
|
|
@ -143,10 +143,8 @@ vela logs first-vela-app
|
|||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
+ nginx-basic-dfb6dcf8d-km5vk › nginx-basic
|
||||
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540430392Z /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
|
||||
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
|
||||
+ express-server-b768d95b7-qnwb4 › express-server
|
||||
express-server 2022-10-09T12:10:33.785549770+08:00 httpd started
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -156,17 +154,14 @@ nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-e
|
|||
- `vela exec` helps you execute commands in pods in managed clusters.
|
||||
|
||||
```bash
|
||||
vela exec basic-topology -n examples -it -- ls
|
||||
vela exec first-vela-app -it -- ls
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
bin docker-entrypoint.d home media proc sbin tmp
|
||||
boot docker-entrypoint.sh lib mnt root srv usr
|
||||
dev etc lib64 opt run sys var
|
||||
bin dev etc home proc root sys tmp usr var www
|
||||
```
|
||||
|
||||
</details>
|
||||
|
|
@ -175,23 +170,11 @@ dev etc lib64 opt run sys var
|
|||
|
||||
- `vela port-forward` can discover and forward ports of pods or services in managed clusters to your local endpoint.
|
||||
|
||||
```bash
|
||||
vela port-forward basic-topology -n examples 8080:80
|
||||
```
|
||||
vela port-forward first-vela-app 8001:8000
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
? You have 4 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
|
||||
Forwarding from 127.0.0.1:8080 -> 80
|
||||
Forwarding from [::1]:8080 -> 80
|
||||
|
||||
Forward successfully! Opening browser ...
|
||||
Handling connection for 8080
|
||||
```
|
||||
|
||||
</details>
|
||||
You can curl this app by `curl http://127.0.0.1:8001/`.
|
||||
|
||||
## More CLI Details
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ title: Canary Rollout
|
|||
|
||||
2. Make sure you have already enabled the [`kruise-rollout`](../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,9 @@ vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
|
|||
|
||||
Then check the deployment status of the application through `vela status helm-redis`
|
||||
|
||||
<details>
|
||||
<summary>expected output of vela status </summary>
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
|
|
@ -96,6 +99,7 @@ Services:
|
|||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
</details>
|
||||
|
||||
> You can also check the application on UI, application created by CLI will be synced automatically but readonly.
|
||||
|
||||
|
|
@ -224,6 +228,8 @@ spec:
|
|||
version: '6.1.*'
|
||||
```
|
||||
|
||||
> Notice: your fluxcd addon version must be `>=1.3.1`.
|
||||
:::note
|
||||
Your fluxcd addon version must be `1.3.1+`.
|
||||
:::
|
||||
|
||||
Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -8,8 +8,7 @@ title: Canary Rollout
|
|||
|
||||
2. Make sure you have already enabled the [`kruise-rollout`](../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
vela addon enable kruise-rollout
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Delivery across Multi Environments
|
||||
title: Deploy across Multi Environments
|
||||
---
|
||||
|
||||
Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Targets as you need.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ EOF
|
|||
```
|
||||
|
||||
:::note
|
||||
Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
The application created by CLI will be synced to UI automatically.
|
||||
:::
|
||||
|
||||
You can also save the YAML file as webservice-app.yaml and use the `vela up -f webservice-app.yaml` command to deploy.
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"Delivery Policies": [
|
||||
"CD Policies": [
|
||||
"end-user/policies/shared-resource",
|
||||
"end-user/policies/apply-once",
|
||||
"end-user/policies/gc"
|
||||
|
|
@ -316,8 +316,11 @@
|
|||
{
|
||||
"type": "category",
|
||||
"label": "Community Verified Addons",
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "reference/addons/overview"
|
||||
},
|
||||
"items": [
|
||||
"reference/addons/overview",
|
||||
"reference/addons/velaux",
|
||||
"reference/addons/rollout",
|
||||
"reference/addons/fluxcd",
|
||||
|
|
|
|||
Loading…
Reference in New Issue