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

Merge pull request #447 from barnettZQG/main 

Docs: release 1.2 version
This commit is contained in:
barnettZQG 2022-01-15 00:28:07 +08:00 committed by GitHub
parent cfecb5e283 07b7e1a3e5
commit 3bec20d4c2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
364 changed files with 18894 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

128
docusaurus.config.js
View File

@ -1,119 +1,119 @@
/** @type {import('@docusaurus/types').DocusaurusConfig} */
module.exports = {
title: 'KubeVela',
tagline: 'Make shipping applications more enjoyable.',
url: 'https://kubevela.io',
baseUrl: '/',
onBrokenLinks: 'throw',
onBrokenMarkdownLinks: 'throw',
favicon: 'img/favicon.ico',
organizationName: 'oam-dev', // Usually your GitHub org/user name.
projectName: 'kubevela.io', // Usually your repo name.
title: "KubeVela",
tagline: "Make shipping applications more enjoyable.",
url: "https://kubevela.io",
baseUrl: "/",
onBrokenLinks: "throw",
onBrokenMarkdownLinks: "throw",
favicon: "img/favicon.ico",
organizationName: "oam-dev", // Usually your GitHub org/user name.
projectName: "kubevela.io", // Usually your repo name.
i18n: {
defaultLocale: 'en',
locales: ['en', 'zh'],
defaultLocale: "en",
locales: ["en", "zh"],
localeConfigs: {
en: {
label: 'English',
label: "English",
},
zh: {
label: '简体中文',
label: "简体中文",
},
},
},
themeConfig: {
announcementBar: {
id: 'start',
id: "start",
content:
'⭐️ If you like KubeVela, give it a star on <a target="_blank" rel="noopener noreferrer" href="https://github.com/oam-dev/kubevela">GitHub</a>! ⭐️',
},
algolia: {
apiKey: 'f19c90b8ffe16ed118dae930cd070507',
indexName: 'kubevela',
apiKey: "f19c90b8ffe16ed118dae930cd070507",
indexName: "kubevela",
},
navbar: {
title: 'KubeVela',
title: "KubeVela",
logo: {
alt: 'KubeVela',
src: 'img/logo.svg',
srcDark: 'img/logoDark.svg',
alt: "KubeVela",
src: "img/logo.svg",
srcDark: "img/logoDark.svg",
},
items: [
{
type: 'docsVersionDropdown',
position: 'right',
type: "docsVersionDropdown",
position: "right",
},
{
to: 'docs/',
activeBasePath: 'docs',
label: 'Documentation',
position: 'left',
to: "docs/",
activeBasePath: "docs",
label: "Documentation",
position: "left",
},
{
to: 'blog',
label: 'Blog',
position: 'left'
to: "blog",
label: "Blog",
position: "left",
},
{
type: 'localeDropdown',
position: 'right',
type: "localeDropdown",
position: "right",
},
{
href: 'https://github.com/oam-dev/kubevela',
className: 'header-github-link',
position: 'right',
href: "https://github.com/oam-dev/kubevela",
className: "header-github-link",
position: "right",
},
],
},
footer: {
links: [
{
title: 'Documentation',
title: "Documentation",
items: [
{
label: 'Getting Started',
to: '/docs/quick-start',
label: "Getting Started",
to: "/docs/quick-start",
},
{
label: 'Case Studies',
to: '/docs/case-studies/jenkins-cicd',
label: "Case Studies",
to: "/docs/case-studies/jenkins-cicd",
},
{
label: 'Administrator Manuals',
to: '/docs/platform-engineers/oam/oam-model',
label: "Administrator Manuals",
to: "/docs/platform-engineers/oam/oam-model",
},
],
},
{
title: 'Community',
title: "Community",
items: [
{
label: 'CNCF Slack ( #kubevela channel )',
href: 'https://slack.cncf.io/'
label: "CNCF Slack ( #kubevela channel )",
href: "https://slack.cncf.io/",
},
{
label: 'Gitter',
href: 'https://gitter.im/oam-dev/community',
label: "Gitter",
href: "https://gitter.im/oam-dev/community",
},
{
label: 'DingTalk (23310022)',
href: '.',
label: "DingTalk (23310022)",
href: ".",
},
{
html: '<div class="wechat"> <a class="wechat-label">Wechat Group(Scan code to request joining)</a> <a class="wechat-img" rel="noreferrer noopener" aria-label="Wechat Group"><img src="https://static.kubevela.net/images/barnett-wechat.jpg" alt="Broker wechat to add you into the user group."></div>',
}
},
],
},
{
title: 'More',
title: "More",
items: [
{
label: 'GitHub',
href: 'https://github.com/oam-dev/kubevela',
label: "GitHub",
href: "https://github.com/oam-dev/kubevela",
},
{
label: 'Blog',
to: 'blog',
label: "Blog",
to: "blog",
},
],
},
@ -127,37 +127,33 @@ module.exports = {
`,
},
prism: {
theme: require('prism-react-renderer/themes/dracula'),
theme: require("prism-react-renderer/themes/dracula"),
},
gtag: {
trackingID: 'G-5GLR1Y52M7',
trackingID: "G-5GLR1Y52M7",
anonymizeIP: false,
},
},
presets: [
[
'@docusaurus/preset-classic',
"@docusaurus/preset-classic",
{
docs: {
sidebarPath: require.resolve('./sidebars.js'),
editUrl: function ({
locale,
docPath,
}) {
sidebarPath: require.resolve("./sidebars.js"),
editUrl: function ({ locale, docPath }) {
return `https://github.com/oam-dev/kubevela.io/edit/main/docs/${docPath}`;
},
showLastUpdateAuthor: true,
showLastUpdateTime: true,
includeCurrentVersion: true,
lastVersion: 'v1.1',
lastVersion: "v1.2",
},
blog: {
showReadingTime: true,
editUrl:
'https://github.com/oam-dev/kubevela.io/tree/main/',
editUrl: "https://github.com/oam-dev/kubevela.io/tree/main/",
},
theme: {
customCss: require.resolve('./src/css/custom.css'),
customCss: require.resolve("./src/css/custom.css"),
},
},
],

27
versioned_docs/version-v1.2/README.md Normal file
View File

@ -0,0 +1,27 @@
![alt](resources/KubeVela-03.png)
*Make shipping applications more enjoyable.*
# KubeVela
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
## Community
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel
- Gitter: [Discussion](https://gitter.im/oam-dev/community)
- Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
## Installation
Installation guide is available on [this section](install).
## Quick Start
Quick start is available on [this section](quick-start).
## Contributing
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
## Code of Conduct
KubeVela adopts the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

209
versioned_docs/version-v1.2/case-studies/canary-blue-green.md Normal file
View File

@ -0,0 +1,209 @@
---
title: Progressive Rollout with Istio
---
## Introduction
The application deployment model in KubeVela is designed and implemented with extreme level of extensibility at heart. Hence, KubeVela can be easily integrated with any existing tools to superpower your application delivery with modern technologies such as Service Mesh immediately, without writing dirty glue code/scripts.
This guide will introduce how to use KubeVela and [Istio](https://istio.io/latest/) to do an advanced canary release process. In this process, KubeVela will help you to:
- ship Istio capabilities to end users without asking them to become an Istio expert (i.e. KubeVela will provide you a rollout trait as abstraction);
- design canary release steps and do rollout/rollback in a declarative workflow, instead managing the whole process manually or with ugly scripts.
We will use the well-known [bookinfo](https://istio.io/latest/docs/examples/bookinfo/?ie=utf-8&hl=en&docs-search=Canary) application as the sample.
## Preparation
If your cluster haven't installed Istio. Install the Istio cluster plugin.
```shell
vela addon enable istio
```
Otherwise, you just need apply these 4 YAML files under this [path](https://github.com/oam-dev/kubevela/tree/master/vela-templates/addons/istio/definitions)
The default namespace needs to be labeled so that Istio will auto-inject sidecar.
```shell
kubectl label namespace default istio-injection=enabled
```
## Initial deployment
Deploy the Application of `bookinfo`:
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/first-deploy.yaml
```
The component architecture and relationship of the application are as follows:
![book-info-struct](../resources/book-info-struct.jpg)
This Application has four Components, `productpage`, `ratings`, `details` components configured with an`expose` Trait to expose cluster-level service.
And `reviews` component have a canary-traffic Trait.
The `productpage` component is also configured with an `istio-gateway` Trait, allowing the Component to receive traffic coming from outside the cluster. The example below show that it sets `gateway:ingressgateway` to use Istio's default gateway, and `hosts: "*"` to specify that any request can enter the gateway.
```shell
...
- name: productpage
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-productpage-v1:1.16.2
port: 9080
traits:
- type: expose
properties:
port:
- 9080
- type: istio-gateway
properties:
hosts:
- "*"
gateway: ingressgateway
match:
- exact: /productpage
- prefix: /static
- exact: /login
- prefix: /api/v1/products
port: 9080
...
```
You can port-forward to the gateway as follows:
```shell
kubectl port-forward service/istio-ingressgateway -n istio-system 19082:80
```
Visit http://127.0.0.1:19082/productpage through the browser and you will see the following page.
![pic-v2](../resources/canary-pic-v2.jpg)
## Canary Release
Next, we take the `reviews` Component as an example to simulate the complete process of a canary release, and first upgrade a part of the component instances, and adjust the traffic at the same time, so as to achieve the purpose of progressive canary release.
Execute the following command to update the application.
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/rollout-v2.yaml
```
This operation updates the mirror of the `reviews` Component from the previous v2 to v3. At the same time, the Rollout Trait of the `reviews` Component specifies that the number of target instances to be upgraded is two, which are upgraded in two batches, with one instance in each batch.
In addition, a canary-traffic Trait has been added to the Component.
```shell
...
- name: reviews
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-reviews-v3:1.16.2
port: 9080
volumes:
- name: wlp-output
type: emptyDir
mountPath: /opt/ibm/wlp/output
- name: tmp
type: emptyDir
mountPath: /tmp
traits:
- type: expose
properties:
port:
- 9080
- type: rollout
properties:
targetSize: 2
rolloutBatches:
- replicas: 1
- replicas: 1
- type: canary-traffic
properties:
port: 9080
...
```
This update also adds an upgraded execution Workflow to the Application, which contains three steps.
The first step is to upgrade only the first batch of instances by specifying `batchPartition` equal to 0. And use `traffic.weightedTargets` to switch 10% of the traffic to the new version of the instance.
After completing the first step, the execution of the second step of the Workflow will enter a pause state, waiting for the user to verify the service status.
The third step of the Workflow is to complete the upgrade of the remaining instances and switch all traffic to the new component version.
```shell
...
workflow:
steps:
- name: rollout-1st-batch
type: canary-rollout
properties:
# just upgrade first batch of component
batchPartition: 0
traffic:
weightedTargets:
- revision: reviews-v1
weight: 90 # 90% shift to new version
- revision: reviews-v2
weight: 10 # 10% shift to new version
# give user time to verify part of traffic shifting to newRevision
- name: manual-approval
type: suspend
- name: rollout-rest
type: canary-rollout
properties:
# upgrade all batches of component
batchPartition: 1
traffic:
weightedTargets:
- revision: reviews-v2
weight: 100 # 100% shift to new version
...
```
After the update is complete, visit the previous URL multiple times in the browser. There is about 10% probability that you will see the new page below,
![pic-v3](../resources/canary-pic-v3.jpg)
It can be seen that the new version of the page has changed from the previous black five-pointed star to a red five-pointed star.
### Continue with Full Release
If the service is found to meet expectations during manual verification, the Workflow needs to be continued to complete the full release. You can do that by executing the following command.
```shell
vela workflow resume book-info
```
If you continue to verify the webpage several times on the browser, you will find that the five-pointed star will always be red.
### Rollback to The Old Version
During the manual verification, if the service does not meet the expectations, you can terminate the pre-defined release workflow and rollback the instances and the traffic to the previous version.
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/rollback.yaml
```
This is basically updates the workflow to rollback step:
```yaml
...
workflow:
steps:
- name: rollback
type: canary-rollback
```
Under the hood, it changes:
- the Rollout spec to target to the old version, which rolls replicas of new versions to the old version and keeps replicas of old version as is.
- the VirtualService spec to shift all traffic to the old version.
- the DestinationRule spec to update the subsets to only the old version.
You see?! All the complexity of the work is kept away from users and provided in a simple step!
Continue to visit the website on the browser, you will find that the five-pointed star has changed back to black.

409
versioned_docs/version-v1.2/case-studies/gitops.md Normal file
View File

@ -0,0 +1,409 @@
---
title: GitOps
---
This section will introduce how to use KubeVela in GitOps environment and why.
## Introduction
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, please check [this article](https://www.weave.works/blog/what-is-gitops-really).
KubeVela as an declarative application delivery control plane can be naturally used in GitOps approach, and this will provide below extra bonus to end users alongside with GitOps benefits:
- application delivery workflow (CD pipeline)
- i.e. KubeVela supports pipeline style application delivery process in GitOps, instead of simply declaring final status;
- handling deployment dependencies and designing typologies (DAG);
- unified higher level abstraction atop various GitOps tools' primitives;
- declare, provision and consume cloud resources in unified application definition;
- various out-of-box deployment strategies (Canary, Blue-Green ...);
- various out-of-box hybrid/multi-cloud deployment policies (placement rule, cluster selectors etc.);
- Kustomize-style patch for multi-env deployment without the need to learn Kustomize at all;
- ... and much more.
In this section, we will introduce steps of using KubeVela directly in GitOps approach.
This article will separate into two perspectives:
1. For platform administrators/SREs, they can update the config in Git repo. It will trigger automated re-deployment.
2. For developers, they can update the app source code and then push it to Git. It will trigger building latest image and re-deployment.
> Note: you can also use it with existing tools such as ArgoCD with similar steps, detailed guides will be added in following releases.
## For platform administrators/SREs
Platform administrators/SREs prepares the Git repo for operational config. Every config change will be traceable by that. KubeVela will watch the repo and apply changes to the clusters.
![alt](../resources/ops-flow.jpg)
## Setup Config Repository
> The configuration files are from the [Example Repo](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-SREs).
In this example, we will deploy an application and a database, the application uses the database to store data.
The structure of the config repository looks below:
* The `clusters/` contains the GitOps config. It will command KubeVela to watch the specified repo and apply latest changes.
* The `apps/` contains the Application yaml for deploying the user-facing app.
* The `infrastructure/` contains infrastructure tools, i.e. MySQL database.
```shell
├── apps
│   └── my-app.yaml
├── clusters
│   ├── apps.yaml
│   └── infra.yaml
└── infrastructure
└── mysql.yaml
```
> KubeVela recommends using the directory structure above to manage your GitOps repository. `clusters/` holds the associated KubeVela GitOps configuration that need to be applied to cluster manually, `apps/` holds your application and `infrastructure/` holds your base configuration. By separating applications from basic configurations, you can manage your deployment environment more reasonably and isolate application changes.
#### Directory `clusters/`
The `clusters/` is the initialize configuration directory for KubeVela GitOps.
Below is how the `clusters/infra.yaml` looks like:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: infra
spec:
components:
- name: database-config
type: kustomize
properties:
repoType: git
# replace it with your repo url
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
# replace it with your git secret if it's a private repo
# secretRef: git-secret
# the pull interval time, set to 10m since the infrastructure is steady
pullInterval: 10m
git:
# the branch name
branch: main
# the path to sync
path: ./infrastructure
```
`apps.yaml` and `infra.yaml` in `clusters/` are similar. Their difference is to watch different directories. In `apps.yaml`, the `properties.path` will be `./apps`.
Apply the files in `clusters/` manually. They will sync the files in `infrastructure/` and `apps/` dir of the Git repo.
#### Directory `apps/`
The file in `apps/` is a simple application with database information and Ingress. The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-app
namespace: default
spec:
components:
- name: my-server
type: webservice
properties:
image: <your image address> # {"$imagepolicy": "default:apps"}
port: 8088
env:
- name: DB_HOST
value: mysql-cluster-mysql.default.svc.cluster.local:3306
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: ROOT_PASSWORD
traits:
- type: ingress
properties:
domain: testsvc.example.com
http:
/: 8088
```
#### Directory `infrastructure/`
The `infrastructure/` contains the config of some infrastructures like database. In the following, we will use [MySQL operator](https://github.com/bitpoke/mysql-operator) to deploy a MySQL cluster.
> Notice that there must be a secret in your cluster with MySQL password specified in key `ROOT_PASSWORD`.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: mysql
namespace: default
spec:
components:
- name: mysql-controller
type: helm
properties:
repoType: helm
url: https://presslabs.github.io/charts
chart: mysql-operator
version: "0.4.0"
- name: mysql-cluster
type: raw
dependsOn:
- mysql-controller
properties:
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
spec:
replicas: 1
# replace it with your secret
secretName: mysql-secret
```
#### Apply the files in `clusters/`
After storing bellow files in the Git config repo, we need to apply the GitOps config files in `clusters/` manually.
First, apply the `clusters/infra.yaml` to cluster, we can see that the MySQL in `infrastructure/` is automatically deployed:
```shell
vela up -f clusters/infra.yaml
```
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
Apply the `clusters/apps.yaml` to cluster, we can see that the application in `apps/` is automatically deployed:
```shell
vela up -f clusters/apps.yaml
```
```shell
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
By deploying the KubeVela GitOps config files, we now automatically apply the application and database in cluster.
`curl` the Ingress of the app, we can see that the current version is `0.1.5` and the application is connected to the database successfully:
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> testsvc.example.com <ingress-ip> 80 162m
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
Version: 0.1.5
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
```
## Modify the config for GitOps trigger
After the first deployment, we can modify the files in config repo to update the applications in the cluster.
Modify the domain of the application's Ingress:
```yaml
...
traits:
- type: ingress
properties:
domain: kubevela.example.com
http:
/: 8089
```
Check the Ingress in cluster after a while:
```shell
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
```
The host of the Ingress has been updated successfully!
In this way, we can edit the files in the Git repo to update the cluster.
## For developers
Developers writes the application source code and push it to a Git repo (aka app repo). Once app repo updates, the CI will build the image and push it to the image registry. KubeVela watches the image registry, and updates the image in config repo. Finally, it will apply the config to the cluster.
User can update the configuration in the cluster automatically when the code is updated.
![alt](../resources/dev-flow.jpg)
### Setup App Code Repository
Setup a Git repository with source code and Dockerfile.
The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
```go
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
})
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("select * from userinfo;")
if err != nil {
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
}
for rows.Next() {
var username string
var desc string
err = rows.Scan(&username, &desc)
if err != nil {
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
}
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
}
})
if err := http.ListenAndServe(":8088", nil); err != nil {
panic(err.Error())
}
```
In this tutorial, we will setup a CI pipeline using GitHub Actions to build the image and push it to a registry. The code and configuration files are from the [Example Repo](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-developers/app-code).
## Create Git Secret for KubeVela committing to Config Repo
After the new image is pushed to the image registry, KubeVela will be notified and update the `Application` file in the Git repository and cluster. Therefore, we need a secret with Git information for KubeVela to commit to the Git repository. Fill the following yaml files with your password and apply it to the cluster:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: kubernetes.io/basic-auth
stringData:
username: <your username>
password: <your password>
```
## Setup Config Repository
The configuration repository is almost the same as the previous configuration, you only need to add the image registry config to the file. For more details, please refer to [Example Repository](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-developers/kubevela-config).
Add the config of image registry in `clusters/apps.yaml`, it listens for image updates in the image registry:
```yaml
...
imageRepository:
image: <your image>
# if it's a private image registry, use `kubectl create secret docker-registry` to create the secret
# secretRef: imagesecret
filterTags:
# filter the image tag
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
extract: '$ts'
# use the policy to sort the latest image tag and update
policy:
numerical:
order: asc
# add more commit message
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
```
Modify the image field in `apps/my-app.yaml` and add annotation `# {"$imagepolicy": "default:apps"}`.
Notice that KubeVela will only be able to modify the image field if the annotation is added after the field. `default:apps` is `namespace:name` of the GitOps config file above.
```yaml
spec:
components:
- name: my-server
type: webservice
properties:
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
```
After update the files in `clusters/` to cluster, we can then update the application by modifying the code.
## Modify the code
Change the `Version` to `0.1.6` and modify the data in database:
```go
const VERSION = "0.1.6"
...
func InsertInitData(db *sql.DB) {
stmt, err := db.Prepare(insertInitData)
if err != nil {
panic(err)
}
defer stmt.Close()
_, err = stmt.Exec("KubeVela2", "It's another test user")
if err != nil {
panic(err)
}
}
```
Commit the change to the Git Repository, we can see that our CI pipelines has built the image and push it to the image registry.
KubeVela will listen to the image registry and update the `apps/my-app.yaml` in Git Repository with the latest image tag.
We can see that there is a commit form `kubevelabot`, the commit message is always with a prefix `Update image automatically.` You can use format like `{{range .Updated.Images}}{{println .}}{{end}}` to specify the image name in the `commitMessage` field.
![alt](../resources/gitops-commit.png)
> Note that if you want to put the code and config in the same repository, you need to filter out the commit from KubeVela in CI configuration like below to avoid the repeat build of pipeline.
>
> ```shell
> jobs:
> publish:
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
> ```
Re-check the `Application` in cluster, we can see that the image of the `my-app` has been updated after a while.
> KubeVela polls the latest information from the code and image repo periodically (at an interval that can be customized):
> * When the `Application` file in the Git repository is updated, KubeVela will update the `Application` in the cluster based on the latest configuration.
> * When a new tag is added to the image registry, KubeVela will filter out the latest tag based on your policy and update it to Git repository. When the files in the repository are updated, KubeVela repeats the first step and updates the files in the cluster, thus achieving automatic deployment.
We can `curl` to `Ingress` to see the current version and data:
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
Version: 0.1.6
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
User: KubeVela2
Description: It's another test user
```
The `Version` has been updated successfully! Now we're done with everything from changing the code to automatically applying to the cluster.
## Summary
For platform admins/SREs, they update the config repo to operate the application and infrastructure. KubeVela will synchronize the config to the cluster, simplifying the deployment process.
For end users/developers, they write the source code, push it to Git, and then re-deployment will happen. It will make CI to build the image. KubeVela will then update the image field and apply the deployment config.
By integrating with GitOps, KubeVela helps users speed up deployment and simplify continuous deployment.

226
versioned_docs/version-v1.2/case-studies/initialize-env.md Normal file
View File

@ -0,0 +1,226 @@
---
title: Initialize environment
---
This case will introduce what is environment and how to initialize an environment.
## What is environment
An Application development team usually needs to initialize some shared environment for users. An environment is a logical concept that represents a set of common resources for Applications.
For example, a team usually wants two environments: one for development, and one for production.
In general, the resource types that can be initialized include the following types:
1. One or more Kubernetes clusters. Different environments may need different sizes and versions of Kubernetes clusters. Environment initialization can also manage multiple clusters .
2. Any type of Kubernetes custom resources (CRDS) and system plug-ins can be set up in environment initialization.
3. All kinds of shared resources and services. For example. shared resources in microservices. These shared resources can be a microservice component, cloud database, cache, load balancer, API gateway, and so on.
4. Various management policies and processes. An environment may have different global policies. The policy can be chaos test, security scan, SLO and son on; the process can be initializing a database table, registering an automatic discovery configuration, and so on.
KubeVela allows you to use different resources to initialize the environment.
You can use the `Policy` and `Workflow` in your `Application`. Note that there may be dependencies between initializations, we can use `depends-on-app` in workflow to do it.
The initialization of different environments has dependencies. Common resources can be separated as dependencies. In this way, reusable initialization modules can be formed.
For example, if both the test and develop environments rely on the same controllers, these controllers can be pulled out and initialized as separate environments, specifying dependency initialization in both the development and test environments.
## How to use
### Directly use Application for initialization
> Make sure your KubeVela version is `v1.1.6+`.
If we want to use some CRD controller like [OpenKruise](https://github.com/openkruise/kruise) in cluster, we can use `Helm` to initialize `kruise`.
We can directly use Application to initialize a kruise environment. The application below will deploy a kruise controller in cluster.
We have to enable `fluxcd` in cluster since we use `Helm` to deploy kruise.
We can use `depends-on-app` to make sure `fluxcd` is deployed before kruise.
> `depends-on-app` will check if the cluster has the application with `name` and `namespace` defines in `properties`.
> If the application exists, the next step will be executed after the application is running.
> If the application do not exists, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster.
> For more information, please refer to [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app).
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kruise
namespace: vela-system
spec:
components:
- name: kruise
type: helm
properties:
branch: master
chart: ./charts/kruise/v0.9.0
version: "*"
repoType: git
url: https://github.com/openkruise/kruise
workflow:
steps:
- name: check-flux
type: depends-on-app
properties:
name: fluxcd
namespace: vela-system
- name: apply-kruise
type: apply-component
properties:
component: kruise
EOF
```
Check the application in cluster:
```shell
$ vela ls -n vela-system
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
kruise ... raw running healthy 2021-09-24 20:59:06 +0800 CST
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
```
Kruise is running successfully! Then you can use kruise in your cluster. If you need to set up a new environment, the only thing you need to do is to apply the files like above.
### Add initialize workflow in application
Some Kubernetes native resources like ConfigMap/PVC are commonly used in the environment.
If you want to apply those resources before deploying your application, you can add an initialization workflow to your application.
KubeVela provides a built-in workflow step `apply-object` to fill in native Kubernetes resources.
In this way, by filling in Kubernetes native resources, we can avoid writing redundant component definitions.
Apply the following application, it will initialize an environment with ConfigMap/PVC. There is two components in this application, the first one will write data to PVC, the second on will read the data from PVC:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: server-with-pvc-and-cm
namespace: default
spec:
components:
- name: log-gen-worker
type: worker
properties:
image: busybox
cmd:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /test-pvc/date.log;
i=$((i+1));
sleep 1;
done
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
- name: log-read-worker
type: worker
properties:
name: count-log
image: busybox
cmd:
- /bin/sh
- -c
- 'tail -n+1 -f /test-pvc/date.log'
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
workflow:
steps:
- name: apply-pvc
type: apply-object
properties:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-claim
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
storageClassName: standard
- name: apply-cm
type: apply-object
properties:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-cm
namespace: default
data:
test-key: test-value
- name: apply-remaining
type: apply-remaining
```
Check the PVC and ConfigMap in cluster：
```shell
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-claim Bound pvc-2621d7d7-453c-41df-87fb-58e6b3a8e136 8Gi RWO standard 2m53s
$ kubectl get cm
NAME DATA AGE
my-cm 1 3m8s
```
Check the application in cluster：
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
server-with-pvc-and-cm log-gen-worker worker running healthy 2021-10-11 20:42:38 +0800 CST
└─ log-read-worker worker running 2021-10-11 20:42:38 +0800 CST
```
Check the logs of the second component:
```shell
$ kubectl logs -f log-read-worker-774b58f565-ch8ch
0: Mon Oct 11 12:43:01 UTC 2021
1: Mon Oct 11 12:43:02 UTC 2021
2: Mon Oct 11 12:43:03 UTC 2021
3: Mon Oct 11 12:43:04 UTC 2021
4: Mon Oct 11 12:43:05 UTC 2021
5: Mon Oct 11 12:43:06 UTC 2021
6: Mon Oct 11 12:43:07 UTC 2021
7: Mon Oct 11 12:43:08 UTC 2021
```
We can see that both components is running. The two components share the same PVC and use the same ConfigMap.

148
versioned_docs/version-v1.2/case-studies/jenkins-cicd.md Normal file
View File

@ -0,0 +1,148 @@
---
title: Jenkins CI/CD
---
This section will introduce how to use KubeVela with existing CI/CD tools such as Jenkins and why.
## Introduction
With a simple integration effort, KubeVela as a universal application delivery control plane can then supercharge existing CI/CD tools with modern application deployment capabilities such as:
- hybrid/multi-cloud delivery;
- cross-environments promotion;
- service mesh based application rollout/rollback;
- handling deployment dependencies and topology (DAG);
- declare, provision and consume cloud resources alongside with your application;
- enjoy benefits of [GitOps](https://www.weave.works/blog/what-is-gitops-really) delivery without the need to introduce full GitOps transformation to your team;
- ... and much more.
The following guide will use Jenkins as an example to release a sample HTTP server application step by step. The application code can be found in [this GitHub repo](https://github.com/Somefive/KubeVela-demo-CICD-app).
## Preparation
Before combining KubeVela and Jenkins, you need to ensure the following environments have already been set up.
1. Deploy Jenkins service with Docker support, including related plugins and credentials which will be used to access image repository.
2. A git repository with Webhook enabled. Ensure commits to the target branch will trigger the running of the Jenkins pipeline.
3. Get Kubernetes for deployment. Install KubeVela and enable its apiserver. Ensure the KubeVela apiserver can be accessed from external environment.
## Combining Jenkins with KubeVela apiserver
Deploy Jenkins pipeline with the following Groovy script. You can change the git repository address, image address, apiserver address and other environment configurations on demand. Your git repository should contain the `Dockerfile` and `app.yaml` configuration file to tell how to build the target image and which component the application contains.
```groovy
pipeline {
agent any
environment {
GIT_BRANCH = 'prod'
GIT_URL = 'https://github.com/Somefive/KubeVela-demo-CICD-app.git'
DOCKER_REGISTRY = 'https://registry.hub.docker.com'
DOCKER_CREDENTIAL = 'DockerHubCredential'
DOCKER_IMAGE = 'somefive/kubevela-demo-cicd-app'
APISERVER_URL = 'http://47.88.24.19'
APPLICATION_YAML = 'app.yaml'
APPLICATION_NAMESPACE = 'kubevela-demo-namespace'
APPLICATION_NAME = 'cicd-demo-app'
}
stages {
stage('Prepare') {
steps {
script {
def checkout = git branch: env.GIT_BRANCH, url: env.GIT_URL
env.GIT_COMMIT = checkout.GIT_COMMIT
env.GIT_BRANCH = checkout.GIT_BRANCH
echo "env.GIT_BRANCH=${env.GIT_BRANCH},env.GIT_COMMIT=${env.GIT_COMMIT}"
}
}
}
stage('Build') {
steps {
script {
docker.withRegistry(env.DOCKER_REGISTRY, env.DOCKER_CREDENTIAL) {
def customImage = docker.build(env.DOCKER_IMAGE)
customImage.push()
}
}
}
}
stage('Deploy') {
steps {
sh 'wget -q "https://github.com/mikefarah/yq/releases/download/v4.12.1/yq_linux_amd64"'
sh 'chmod +x yq_linux_amd64'
script {
def app = sh (
script: "./yq_linux_amd64 eval -o=json '.spec' ${env.APPLICATION_YAML} | sed -e 's/GIT_COMMIT/$GIT_COMMIT/g'",
returnStdout: true
)
echo "app: ${app}"
def response = httpRequest acceptType: 'APPLICATION_JSON', contentType: 'APPLICATION_JSON', httpMode: 'POST', requestBody: app, url: "${env.APISERVER_URL}/v1/namespaces/${env.APPLICATION_NAMESPACE}/applications/${env.APPLICATION_NAME}"
println('Status: '+response.status)
println('Response: '+response.content)
}
}
}
}
}
```
Push commits to the target branch in the git repository, which the Jenkins pipeline focuses on. The webhook of git repo will trigger the newly created Jenkins pipeline. This pipeline will automatically build container images and push it to the image repository. Then it will send POST request to KubeVela apiserver, which will deploy `app.yaml` to Kubernetes cluster. An example of `app.yaml` is shown below.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kubevela-demo-app
spec:
components:
- name: kubevela-demo-app-web
type: webservice
properties:
image: somefive/kubevela-demo-cicd-app
imagePullPolicy: Always
port: 8080
traits:
- type: rollout
properties:
rolloutBatches:
- replicas: 2
- replicas: 3
batchPartition: 0
targetSize: 5
- type: labels
properties:
jenkins-build-commit: GIT_COMMIT
- type: ingress
properties:
domain: <your domain>
http:
"/": 8088
```
THe *GIT_COMMIT* identifier will be replaced by the current git commit id in Jenkins pipeline. You can check the deployment status in Kubernetes through `kubectl`.
```bash
$ kubectl get app -n kubevela-demo-namespace
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
cicd-demo-app kubevela-demo-app-web webservice running true 102s
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 2/2 2 2 111s
$ kubectl get ingress -n kubevela-demo-namespace
NAME CLASS HOSTS ADDRESS PORTS AGE
kubevela-demo-app-web <none> <your domain> 198.11.175.125 80 117s
```
In the deployed application, we use the `rollout` trait, which enables us to release 2 pods first for canary validation. After validation succeed, remove `batchPatition: 0` in application configuration in the `rollout` trait. After that, a complete release will be fired. This mechanism greatly improves the security and stability of the releasing process. You can adjust the rollout strategy depending on your scenario.
```bash
$ kubectl edit app -n kubevela-demo-namespace
application.core.oam.dev/cicd-demo-app edited
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 5/5 5 5 4m16s
$ curl http://<your domain>/
Version: 0.1.2
```
## More
Refer to the [blog post](/blog/2021/09/02/kubevela-jenkins-cicd) for more details about deploying Jenkins + KubeVela and more comprehensive demo for application rolling update.

3
versioned_docs/version-v1.2/case-studies/li-auto-inc.md Normal file
View File

@ -0,0 +1,3 @@
---
title: Practical Case
---

305
versioned_docs/version-v1.2/case-studies/multi-cluster.md Normal file
View File

@ -0,0 +1,305 @@
---
title: Multi-Cluster App Delivery
---
This section will introduce how to use KubeVela for multi-cluster application delivery and why.
## Introduction
There are more and more situations come out that organizations need multi-cluster technology for application delivery:
* For scalability, a single Kubernetes cluster has its limit around 5K nodes or less, it is unable to handle the large scale application load.
* For stability/availability, application can deploy in multi-cluster for backup which provides more stability and availability.
* For security, you may need to deploy in different zones/areas as government policy requires.
The following guide will the multi-cluster that helps you easily deploy an application to different environments.
## Preparation
You can simply join an existing cluster into KubeVela by specify its KubeConfig like below.
```shell script
vela cluster join <your kubeconfig path>
```
It will use field `context.cluster` in KubeConfig as the cluster name automatically,
you can also specify the name by `--name` parameter. For example:
```shell
vela cluster join stage-cluster.kubeconfig --name cluster-staging
vela cluster join prod-cluster.kubeconfig --name cluster-prod
```
After clusters joined, you could list all clusters managed by KubeVela currently.
```bash
$ vela cluster list
CLUSTER TYPE ENDPOINT
cluster-prod tls https://47.88.4.97:6443
cluster-staging tls https://47.88.7.230:6443
```
You can also detach a cluster if you're not using it any more.
```shell script
$ vela cluster detach cluster-prod
```
If there's still any application running in the cluster, the command will be rejected.
## Deploy Application to multi cluster
KubeVela regards a Kubernetes cluster as an environment, so you can deploy an application into
one or more environments.
Below is an example, deploy to a staging environment first, check the application running well,
and finally promote to production environment.
For different environments, the deployment configuration can also have some nuance. In the staging environment, we only need one replica for the webservice and do not need the worker. In the production environment, we setup 3 replicas for the webservice and enable the worker.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: example-app
namespace: default
spec:
components:
- name: hello-world-server
type: webservice
properties:
image: crccheck/hello-world
port: 8000
traits:
- type: scaler
properties:
replicas: 1
- name: data-worker
type: worker
properties:
image: busybox
cmd:
- sleep
- '1000000'
policies:
- name: example-multi-env-policy
type: env-binding
properties:
envs:
- name: staging
placement: # selecting the cluster to deploy to
clusterSelector:
name: cluster-staging
selector: # selecting which component to use
components:
- hello-world-server
- name: prod
placement:
clusterSelector:
name: cluster-prod
patch: # overlay patch on above components
components:
- name: hello-world-server
type: webservice
traits:
- type: scaler
properties:
replicas: 3
- name: health-policy-demo
type: health
properties:
probeInterval: 5
probeTimeout: 10
workflow:
steps:
# deploy to staging env
- name: deploy-staging
type: deploy2env
properties:
policy: example-multi-env-policy
env: staging
# manual check
- name: manual-approval
type: suspend
# deploy to prod env
- name: deploy-prod
type: deploy2env
properties:
policy: example-multi-env-policy
env: prod
```
After the application deployed, it will run as the workflow steps.
> You can refer to [Env Binding](../end-user/policies/envbinding) and [Health Check](../end-user/policies/health) policy user guide for parameter details.
It will deploy application to staging environment first, you can check the `Application` status by:
```shell
> kubectl get application example-app
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
example-app hello-world-server webservice workflowSuspending true Ready:1/1 10s
```
We can see that the workflow is suspended at `manual-approval`:
```yaml
...
status:
workflow:
appRevision: example-app-v1:44a6447e3653bcc2
contextBackend:
apiVersion: v1
kind: ConfigMap
name: workflow-example-app-context
uid: 56ddcde6-8a83-4ac3-bf94-d19f8f55eb3d
mode: StepByStep
steps:
- id: wek2b31nai
name: deploy-staging
phase: succeeded
type: deploy2env
- id: 7j5eb764mk
name: manual-approval
phase: succeeded
type: suspend
suspend: true
terminated: false
waitCount: 0
```
You can also check the health status in the `status.service` field below.
```yaml
...
status:
services:
- env: staging
healthy: true
message: 'Ready:1/1 '
name: hello-world-server
scopes:
- apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
name: health-policy-demo
namespace: test
uid: 6e6230a3-93f3-4dba-ba09-dd863b6c4a88
traits:
- healthy: true
type: scaler
workloadDefinition:
apiVersion: apps/v1
kind: Deployment
```
You can use `resume` command after everything verified in statging cluster:
```shell
> vela workflow resume example-app
Successfully resume workflow: example-app
```
Recheck the `Application` status:
```shell
> kubectl get application example-app
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
example-app hello-world-server webservice running true Ready:1/1 62s
```
```yaml
status:
services:
- env: staging
healthy: true
message: 'Ready:1/1 '
name: hello-world-server
scopes:
- apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
name: health-policy-demo
namespace: default
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
traits:
- healthy: true
type: scaler
workloadDefinition:
apiVersion: apps/v1
kind: Deployment
- env: prod
healthy: true
message: 'Ready:3/3 '
name: hello-world-server
scopes:
- apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
name: health-policy-demo
namespace: default
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
traits:
- healthy: true
type: scaler
workloadDefinition:
apiVersion: apps/v1
kind: Deployment
- env: prod
healthy: true
message: 'Ready:1/1 '
name: data-worker
scopes:
- apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
name: health-policy-demo
namespace: default
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
workloadDefinition:
apiVersion: apps/v1
kind: Deployment
```
All the step status in workflow is succeeded:
```yaml
...
status:
workflow:
appRevision: example-app-v1:44a6447e3653bcc2
contextBackend:
apiVersion: v1
kind: ConfigMap
name: workflow-example-app-context
uid: e1e7bd2d-8743-4239-9de7-55a0dd76e5d3
mode: StepByStep
steps:
- id: q8yx7pr8wb
name: deploy-staging
phase: succeeded
type: deploy2env
- id: 6oxrtvki9o
name: manual-approval
phase: succeeded
type: suspend
- id: uk287p8c31
name: deploy-prod
phase: succeeded
type: deploy2env
suspend: false
terminated: false
waitCount: 0
```
## More use cases
KubeVela can provide many strategies to deploy an application to multiple clusters by composing env-binding policy and workflow steps.
You can have a glimpse of how does it work as below:
![alt](../resources/workflow-multi-env.png)
More use cases about the multi cluster application deployment are coming soon.

5
versioned_docs/version-v1.2/case-studies/workflow-with-ocm.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Practical Case
---
TBD

45
versioned_docs/version-v1.2/cli/vela.md Normal file
View File

@ -0,0 +1,45 @@
---
title: CLI Commands
---
## Getting Started
* [vela env](vela_env) - Manage environments for vela applications to run.
* [vela init](vela_init) - Create scaffold for vela application.
* [vela up](vela_up) - Create or update vela application from file or URL, both appfile or application object format are supported.
* [vela show](vela_show) - Show the reference doc for component or trait types.
## Managing Applications
* [vela ls](vela_ls) - List all vela applications.
* [vela status](vela_status) - Show status of vela application.
* [vela delete](vela_delete) - Delete an application.
* [vela exec](vela_exec) - Execute command inside container based vela application.
* [vela port-forward](vela_port-forward) - Forward local ports to container/service port of vela application.
* [vela logs](vela_logs) - Tail logs for vela application.
* [vela live-diff](vela_live-diff) - Dry-run application locally, and diff with a deployed application version.
* [vela dry-run](vela_dry-run) - Dry-run application locally, render the Kubernetes resources as result to stdout.
## Continuous Delivery
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters for Continuous Delivery.
* [vela workflow](vela_workflow) - Operate the Workflow during Application Delivery.
## Managing Extension
* [vela addon](vela_addon) - Manage addons for extension.
* [vela uischema](vela_uischema) - Manage UI schema for addons.
* [vela def](vela_def) - Manage X-Definitions for extension.
* [vela registry](vela_registry) - Manage Registry of X-Definitions for extension.
* [vela component](vela_component) - List component types installed and discover more in registry.
* [vela trait](vela_trait) - List trait types installed and discover more in registry.
## Others
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
* [vela export](vela_export) - Export deploy manifests from appfile or application.
* [vela version](vela_version) - Prints vela build version information.
###### Auto generated by [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

30
versioned_docs/version-v1.2/cli/vela_addon.md Normal file
View File

@ -0,0 +1,30 @@
---
title: vela addon
---
Manage addons for extension.
### Synopsis
Manage addons for extension.
### Options
```
-h, --help help for addon
```
### SEE ALSO
* [vela addon disable](vela_addon_disable) - disable an addon
* [vela addon enable](vela_addon_enable) - enable an addon
* [vela addon list](vela_addon_list) - List addons
* [vela addon registry](vela_addon_registry) - Manage addon registry.
* [vela addon status](vela_addon_status) - get an addon's status.
* [vela addon upgrade](vela_addon_upgrade) - upgrade an addon
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_disable.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon disable
---
disable an addon
### Synopsis
disable an addon in cluster.
```
vela addon disable [flags]
```
### Examples
```
vela addon disable <addon-name>
```
### Options
```
-h, --help help for disable
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_enable.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon enable
---
enable an addon
### Synopsis
enable an addon in cluster.
```
vela addon enable [flags]
```
### Examples
```
vela addon enable <addon-name>
```
### Options
```
-h, --help help for enable
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_addon_list.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela addon list
---
List addons
### Synopsis
List addons in KubeVela
```
vela addon list [flags]
```
### Options
```
-h, --help help for list
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

29
versioned_docs/version-v1.2/cli/vela_addon_registry.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela addon registry
---
Manage addon registry.
### Synopsis
Manage addon registry.
### Options
```
-h, --help help for registry
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
* [vela addon registry add](vela_addon_registry_add) - Add an addon registry.
* [vela addon registry delete](vela_addon_registry_delete) - Delete an addon registry
* [vela addon registry get](vela_addon_registry_get) - Get an addon registry.
* [vela addon registry list](vela_addon_registry_list) - List addon registries.
* [vela addon registry update](vela_addon_registry_update) - Update an addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_addon_registry_add.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela addon registry add
---
Add an addon registry.
### Synopsis
Add an addon registry.
```
vela addon registry add [flags]
```
### Examples
```
"vela addon registry add <my-registry-name> --type OSS --endpoint=<URL> --bucket=<bukect-name> or vela addon registry add my-repo --type git --endpoint=<URL> --path=<OSS-ptah> --gitToken=<git token>"
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for add
--path string specify the addon registry OSS path
--type string specify the addon registry type
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_registry_delete.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon registry delete
---
Delete an addon registry
### Synopsis
Delete an addon registry
```
vela addon registry delete [flags]
```
### Examples
```
vela addon registry delete <registry-name>
```
### Options
```
-h, --help help for delete
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_registry_get.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon registry get
---
Get an addon registry.
### Synopsis
Get an addon registry.
```
vela addon registry get [flags]
```
### Examples
```
vela addon registry get <registry name>
```
### Options
```
-h, --help help for get
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_registry_list.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon registry list
---
List addon registries.
### Synopsis
List addon registries.
```
vela addon registry list [flags]
```
### Examples
```
vela addon registry list
```
### Options
```
-h, --help help for list
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_addon_registry_update.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela addon registry update
---
Update an addon registry.
### Synopsis
Update an addon registry.
```
vela addon registry update [flags]
```
### Examples
```
vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=<bucket name>
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for update
--path string specify the addon registry OSS path
--type string specify the addon registry type
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_status.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon status
---
get an addon's status.
### Synopsis
get an addon's status from cluster.
```
vela addon status [flags]
```
### Examples
```
vela addon status <addon-name>
```
### Options
```
-h, --help help for status
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_addon_upgrade.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon upgrade
---
upgrade an addon
### Synopsis
upgrade an addon in cluster.
```
vela addon upgrade [flags]
```
### Examples
```
vela addon upgrade <addon-name>
```
### Options
```
-h, --help help for upgrade
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

29
versioned_docs/version-v1.2/cli/vela_cluster.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela cluster
---
Manage Kubernetes Clusters
### Synopsis
Manage Kubernetes Clusters for Continuous Delivery.
### Options
```
-h, --help help for cluster
```
### SEE ALSO
* [vela cluster detach](vela_cluster_detach) - detach managed cluster.
* [vela cluster join](vela_cluster_join) - join managed cluster.
* [vela cluster list](vela_cluster_list) - list managed clusters
* [vela cluster probe](vela_cluster_probe) - health probe managed cluster.
* [vela cluster rename](vela_cluster_rename) - rename managed cluster.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

29
versioned_docs/version-v1.2/cli/vela_cluster_detach.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela cluster detach
---
detach managed cluster.
### Synopsis
detach managed cluster.
```
vela cluster detach [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for detach
-p, --kubeconfig-path string Specify the kubeconfig path of managed cluster. If you use ocm to manage your cluster, you must set the kubeconfig-path.
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_cluster_join.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela cluster join
---
join managed cluster.
### Synopsis
join managed cluster by kubeconfig.
```
vela cluster join [KUBECONFIG] [flags]
```
### Examples
```
# Join cluster declared in my-child-cluster.kubeconfig
> vela cluster join my-child-cluster.kubeconfig --name example-cluster
```
### Options
```
--create-namespace string Specifies the namespace need to create in managedCluster
-t, --engine string Specify the cluster management engine. If empty, it will use cluster-gateway cluster management solution. Default to be empty.
-h, --help help for join
--in-cluster-boostrap If true, the registering managed cluster will use the internal endpoint prescribed in the hub cluster's configmap "kube-public/cluster-info to register "itself to the hub cluster. Otherwise use the original endpoint from the hub kubeconfig. (default true)
-n, --name string Specify the cluster name. If empty, it will use the cluster name in config file. Default to be empty.
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_cluster_list.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela cluster list
---
list managed clusters
### Synopsis
list worker clusters managed by KubeVela.
```
vela cluster list [flags]
```
### Options
```
-h, --help help for list
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_cluster_probe.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela cluster probe
---
health probe managed cluster.
### Synopsis
health probe managed cluster.
```
vela cluster probe [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for probe
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_cluster_rename.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela cluster rename
---
rename managed cluster.
### Synopsis
rename managed cluster.
```
vela cluster rename [OLD_NAME] [NEW_NAME] [flags]
```
### Options
```
-h, --help help for rename
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

27
versioned_docs/version-v1.2/cli/vela_completion.md Normal file
View File

@ -0,0 +1,27 @@
---
title: vela completion
---
Output shell completion code for the specified shell (bash or zsh)
### Synopsis
Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
### Options
```
-h, --help help for completion
```
### SEE ALSO
* [vela completion bash](vela_completion_bash) - generate autocompletions script for bash
* [vela completion zsh](vela_completion_zsh) - generate autocompletions script for zsh
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

38
versioned_docs/version-v1.2/cli/vela_completion_bash.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela completion bash
---
generate autocompletions script for bash
### Synopsis
Generate the autocompletion script for Vela for the bash shell.
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
vela completion bash
```
### Options
```
-h, --help help for bash
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
versioned_docs/version-v1.2/cli/vela_completion_zsh.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela completion zsh
---
generate autocompletions script for zsh
### Synopsis
Generate the autocompletion script for Vela for the zsh shell.
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```
vela completion zsh
```
### Options
```
-h, --help help for zsh
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_component.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela component
---
List/get components
### Synopsis
List component types installed and discover more in registry.
```
vela component [flags]
```
### Examples
```
vela comp
```
### Options
```
--discover discover traits in registries
-h, --help help for component
--label --label type=terraform a label to filter components, the format is --label type=terraform
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### SEE ALSO
* [vela component get](vela_component_get) - get component from registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
versioned_docs/version-v1.2/cli/vela_component_get.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela component get
---
get component from registry
### Synopsis
get/download/install component from registry.
```
vela component get <component> [flags]
```
### Examples
```
vela comp get <component>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### SEE ALSO
* [vela component](vela_component) - List/get components
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

33
versioned_docs/version-v1.2/cli/vela_def.md Normal file
View File

@ -0,0 +1,33 @@
---
title: vela def
---
Manage Definitions
### Synopsis
Manage X-Definitions for extension.
### Options
```
-h, --help help for def
```
### SEE ALSO
* [vela def apply](vela_def_apply) - Apply X-Definition.
* [vela def del](vela_def_del) - Delete X-Definition.
* [vela def doc-gen](vela_def_doc-gen) - Generate documentation of definitions (Only Terraform typed definitions are supported)
* [vela def edit](vela_def_edit) - Edit X-Definition.
* [vela def get](vela_def_get) - Get definition
* [vela def init](vela_def_init) - Init a new definition
* [vela def list](vela_def_list) - List definitions.
* [vela def render](vela_def_render) - Render X-Definition.
* [vela def vet](vela_def_vet) - Validate X-Definition.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_def_apply.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela def apply
---
Apply X-Definition.
### Synopsis
Apply X-Definition from local storage to kubernetes cluster. It will apply file to vela-system namespace by default.
```
vela def apply DEFINITION.cue [flags]
```
### Examples
```
# Command below will apply the local my-webservice.cue file to kubernetes vela-system namespace
> vela def apply my-webservice.cue
# Command below will apply the ./defs/my-trait.cue file to kubernetes default namespace
> vela def apply ./defs/my-trait.cue --namespace default# Command below will convert the ./defs/my-trait.cue file to kubernetes CRD object and print it without applying it to kubernetes
> vela def apply ./defs/my-trait.cue --dry-run
```
### Options
```
--dry-run only build definition from CUE into CRB object without applying it to kubernetes clusters
-h, --help help for apply
-n, --namespace string Specify which namespace to apply. (default "vela-system")
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
versioned_docs/version-v1.2/cli/vela_def_del.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela def del
---
Delete X-Definition.
### Synopsis
Delete X-Definition in kubernetes cluster.
```
vela def del DEFINITION_NAME [flags]
```
### Examples
```
# Command below will delete TraitDefinition of annotations in default namespace
> vela def del annotations -t trait -n default
```
### Options
```
-h, --help help for del
-n, --namespace string Specify which namespace the definition locates.
-t, --type string Specify the definition type of target. Valid types: workload, scope, workflow-step, component, trait, policy
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
versioned_docs/version-v1.2/cli/vela_def_doc-gen.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela def doc-gen
---
Generate documentation of definitions (Only Terraform typed definitions are supported)
### Synopsis
Generate documentation of definitions
```
vela def doc-gen NAME [flags]
```
### Examples
```
1. Generate documentation for ComponentDefinition alibaba-vpc:
> vela def doc-gen alibaba-vpc -n vela-system
```
### Options
```
-h, --help help for doc-gen
-n, --namespace string Specify the namespace of the definition.
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_def_edit.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela def edit
---
Edit X-Definition.
### Synopsis
Edit X-Definition in kubernetes. If type and namespace are not specified, the command will automatically search all possible results.
By default, this command will use the vi editor and can be altered by setting EDITOR environment variable.
```
vela def edit NAME [flags]
```
### Examples
```
# Command below will edit the ComponentDefinition (and other definitions if exists) of webservice in kubernetes
> vela def edit webservice
# Command below will edit the TraitDefinition of ingress in vela-system namespace
> vela def edit ingress --type trait --namespace vela-system
```
### Options
```
-h, --help help for edit
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: workload, scope, workflow-step, component, trait, policy
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_def_get.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela def get
---
Get definition
### Synopsis
Get definition from kubernetes cluster
```
vela def get NAME [flags]
```
### Examples
```
# Command below will get the ComponentDefinition(or other definitions if exists) of webservice in all namespaces
> vela def get webservice
# Command below will get the TraitDefinition of annotations in namespace vela-system
> vela def get annotations --type trait --namespace vela-system
```
### Options
```
-h, --help help for get
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: component, trait, policy, workload, scope, workflow-step
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

52
versioned_docs/version-v1.2/cli/vela_def_init.md Normal file
View File

@ -0,0 +1,52 @@
---
title: vela def init
---
Init a new definition
### Synopsis
Init a new definition with given arguments or interactively
* We support parsing a single YAML file (like kubernetes objects) into the cue-style template.
However, we do not support variables in YAML file currently, which prevents users from directly feeding files like helm chart directly.
We may introduce such features in the future.
```
vela def init DEF_NAME [flags]
```
### Examples
```
# Command below initiate an empty TraitDefinition named my-ingress
> vela def init my-ingress -t trait --desc "My ingress trait definition." > ./my-ingress.cue
# Command below initiate a definition named my-def interactively and save it to ./my-def.cue
> vela def init my-def -i --output ./my-def.cue
# Command below initiate a ComponentDefinition named my-webservice with the template parsed from ./template.yaml.
> vela def init my-webservice -i --template-yaml ./template.yaml
# Command below initiate a typed ComponentDefinition named vswitch from Alibaba Cloud.
> vela def init vswitch --type component --provider alibaba --desc xxx --git https://github.com/kubevela-contrib/terraform-modules.git --path alibaba/vswitch
```
### Options
```
-d, --desc string Specify the description of the new definition.
--git string Specify which git repository the configuration(HCL) is stored in. Valid when --provider/-p is set.
-h, --help help for init
-i, --interactive Specify whether use interactive process to help generate definitions.
-o, --output string Specify the output path of the generated definition. If empty, the definition will be printed in the console.
--path string Specify which path the configuration(HCL) is stored in the Git repository. Valid when --git is set.
-p, --provider alibaba Specify which provider the cloud resource definition belongs to. Only alibaba, `aws`, `azure` are supported.
-y, --template-yaml string Specify the template yaml file that definition will use to build the schema. If empty, a default template for the given definition type will be used.
-t, --type string Specify the type of the new definition. Valid types: scope, workflow-step, component, trait, policy, workload
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_def_list.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela def list
---
List definitions.
### Synopsis
List definitions in kubernetes cluster.
```
vela def list [flags]
```
### Examples
```
# Command below will list all definitions in all namespaces
> vela def list
# Command below will list all definitions in the vela-system namespace
> vela def get annotations --type trait --namespace vela-system
```
### Options
```
-h, --help help for list
-n, --namespace string Specify which namespace to list. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to list. If empty, all types will be searched. Valid types: component, trait, policy, workload, scope, workflow-step
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_def_render.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela def render
---
Render X-Definition.
### Synopsis
Render X-Definition with cue format into kubernetes YAML format. Could be used to check whether the cue format definition is working as expected. If a directory is used as input, all cue definitions in the directory will be rendered.
```
vela def render DEFINITION.cue [flags]
```
### Examples
```
# Command below will render my-webservice.cue into YAML format and print it out.
> vela def render my-webservice.cue
# Command below will render my-webservice.cue and save it in my-webservice.yaml.
> vela def render my-webservice.cue -o my-webservice.yaml# Command below will render all cue format definitions in the ./defs/cue/ directory and save the YAML objects in ./defs/yaml/.
> vela def render ./defs/cue/ -o ./defs/yaml/
```
### Options
```
-h, --help help for render
--message string Specify the header message of the generated YAML file. For example, declaring author information.
-o, --output string Specify the output path of the rendered definition YAML. If empty, the definition will be printed in the console. If input is a directory, the output path is expected to be a directory as well.
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_def_vet.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela def vet
---
Validate X-Definition.
### Synopsis
Validate definition file by checking whether it has the valid cue format with fields set correctly
* Currently, this command only checks the cue format. This function is still working in progress and we will support more functional validation mechanism in the future.
```
vela def vet DEFINITION.cue [flags]
```
### Examples
```
# Command below will validate the my-def.cue file.
> vela def vet my-def.cue
```
### Options
```
-h, --help help for vet
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_delete.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela delete
---
Delete an application
### Synopsis
Delete an application.
```
vela delete APP_NAME
```
### Examples
```
vela delete frontend
```
### Options
```
-e, --env string specify environment name for application
-f, --force force to delete the application
-h, --help help for delete
-n, --namespace string specify the Kubernetes namespace to use
--svc string delete only the specified service in this app
-w, --wait wait util the application is deleted completely
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

38
versioned_docs/version-v1.2/cli/vela_dry-run.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela dry-run
---
Dry Run an application, and output the K8s resources as result to stdout
### Synopsis
Dry-run application locally, render the Kubernetes resources as result to stdout.
```
vela dry-run
```
### Examples
```
vela dry-run
```
### Options
```
-d, --definition string specify a definition file or directory, it will only be used in dry-run rather than applied to K8s cluster
-e, --env string specify environment name for application
-f, --file string application file name (default "./app.yaml")
-h, --help help for dry-run
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_env.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela env
---
Manage environments for vela applications to run.
### Synopsis
Manage environments for vela applications to run.
### Options
```
-h, --help help for env
```
### SEE ALSO
* [vela env delete](vela_env_delete) - Delete an environment.
* [vela env init](vela_env_init) - Create environment for vela applications to run.
* [vela env ls](vela_env_ls) - List environments for vela applications to run.
* [vela env set](vela_env_set) - Set an environment.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_env_delete.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela env delete
---
Delete an environment.
### Synopsis
Delete an environment.
```
vela env delete
```
### Examples
```
vela env delete test
```
### Options
```
-h, --help help for delete
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
versioned_docs/version-v1.2/cli/vela_env_init.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela env init
---
Create environment for vela applications to run.
### Synopsis
Create environment for vela applications to run.
```
vela env init <envName>
```
### Examples
```
vela env init test --namespace test
```
### Options
```
-h, --help help for init
--namespace string specify K8s namespace for env
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_env_ls.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela env ls
---
List environments for vela applications to run.
### Synopsis
List all environments for vela applications to run.
```
vela env ls
```
### Examples
```
vela env ls [env-name]
```
### Options
```
-h, --help help for ls
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_env_set.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela env set
---
Set an environment.
### Synopsis
Set an environment as the default one for running vela applications.
```
vela env set
```
### Examples
```
vela env set test
```
### Options
```
-h, --help help for set
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
versioned_docs/version-v1.2/cli/vela_exec.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela exec
---
Execute command in a container
### Synopsis
Execute command inside container based vela application.
```
vela exec [flags] APP_NAME -- COMMAND [args...]
```
### Examples
```
# Get output from running 'date' command from app pod, using the first container by default
vela exec my-app -- date
# Switch to raw terminal mode, sends stdin to 'bash' in containers of application my-app
# and sends stdout/stderr from 'bash' back to the client
vela exec my-app -i -t -- bash -il
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for exec
-n, --namespace string specify the Kubernetes namespace to use
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
-i, --stdin Pass stdin to the container (default true)
-t, --tty Stdin is a TTY (default true)
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

31
versioned_docs/version-v1.2/cli/vela_export.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela export
---
Export deploy manifests from appfile
### Synopsis
Export deploy manifests from appfile or application.
```
vela export
```
### Options
```
-e, --env string specify environment name for application
-f, --file string specify file path for appfile
-h, --help help for export
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

24
versioned_docs/version-v1.2/cli/vela_help.md Normal file
View File

@ -0,0 +1,24 @@
---
title: vela help
---
Help about any command
```
vela help [command]
```
### Options
```
-h, --help help for help
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
versioned_docs/version-v1.2/cli/vela_init.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela init
---
Create scaffold for an application.
### Synopsis
Create scaffold for vela application.
```
vela init
```
### Examples
```
vela init
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for init
-n, --namespace string specify the Kubernetes namespace to use
--render-only Rendering vela.yaml in current dir and do not deploy
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_live-diff.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela live-diff
---
Dry-run application locally, and diff with a deployed application version
### Synopsis
Dry-run application locally, and diff with a deployed application version.
```
vela live-diff
```
### Examples
```
vela live-diff -f app-v2.yaml -r app-v1 --context 10
```
### Options
```
-r, --Revision string specify an application Revision name, by default, it will compare with the latest Revision
-c, --context int output number lines of context around changes, by default show all unchanged lines (default -1)
-d, --definition string specify a file or directory containing capability definitions, they will only be used in dry-run rather than applied to K8s cluster
-e, --env string specify environment name for application
-f, --file string application file name (default "./app.yaml")
-h, --help help for live-diff
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

31
versioned_docs/version-v1.2/cli/vela_logs.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela logs
---
Tail logs for application.
### Synopsis
Tail logs for vela application.
```
vela logs APP_NAME [flags]
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for logs
-n, --namespace string specify the Kubernetes namespace to use
-o, --output string output format for logs, support: [default, raw, json] (default "default")
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_ls.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela ls
---
List applications
### Synopsis
List all vela applications.
```
vela ls
```
### Examples
```
vela ls
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for ls
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
versioned_docs/version-v1.2/cli/vela_port-forward.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela port-forward
---
Forward local ports to container/service port of vela application.
### Synopsis
Forward local ports to container/service port of vela application.
```
vela port-forward APP_NAME [flags]
```
### Examples
```
port-forward APP_NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]
```
### Options
```
--address strings Addresses to listen on (comma separated). Only accepts IP addresses or localhost as a value. When localhost is supplied, vela will try to bind on both 127.0.0.1 and ::1 and will fail if neither of these addresses are available to bind. (default [localhost])
-e, --env string specify environment name for application
-h, --help help for port-forward
-n, --namespace string specify the Kubernetes namespace to use
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
--route forward ports from route trait service
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

27
versioned_docs/version-v1.2/cli/vela_registry.md Normal file
View File

@ -0,0 +1,27 @@
---
title: vela registry
---
Manage Registry
### Synopsis
Manage Registry of X-Definitions for extension.
### Options
```
-h, --help help for registry
```
### SEE ALSO
* [vela registry config](vela_registry_config) - Configure (add if not exist) a registry, default is local (built-in capabilities)
* [vela registry ls](vela_registry_ls) - List all registry
* [vela registry remove](vela_registry_remove) - Remove specified registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
versioned_docs/version-v1.2/cli/vela_registry_config.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela registry config
---
Configure (add if not exist) a registry, default is local (built-in capabilities)
### Synopsis
Configure (add if not exist) a registry, default is local (built-in capabilities)
```
vela registry config <registryName> <centerURL> [flags]
```
### Examples
```
vela registry config my-registry https://github.com/oam-dev/catalog/tree/master/registry
```
### Options
```
-h, --help help for config
-t, --token string Github Repo token
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_registry_ls.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela registry ls
---
List all registry
### Synopsis
List all configured registry
```
vela registry ls [flags]
```
### Examples
```
vela registry ls
```
### Options
```
-h, --help help for ls
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
versioned_docs/version-v1.2/cli/vela_registry_remove.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela registry remove
---
Remove specified registry
### Synopsis
Remove specified registry
```
vela registry remove <centerName> [flags]
```
### Examples
```
vela registry remove mycenter
```
### Options
```
-h, --help help for remove
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
versioned_docs/version-v1.2/cli/vela_show.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela show
---
Show the reference doc for a component type or trait.
### Synopsis
Show the reference doc for component or trait types.
```
vela show [flags]
```
### Examples
```
show webservice
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for show
-n, --namespace string specify the Kubernetes namespace to use
--web start web doc site
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

38
versioned_docs/version-v1.2/cli/vela_status.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela status
---
Show status of an application.
### Synopsis
Show status of vela application.
```
vela status APP_NAME [flags]
```
### Examples
```
vela status APP_NAME
```
### Options
```
-p, --endpoint show all service endpoints of the application
-e, --env string specify environment name for application
-h, --help help for status
-n, --namespace string specify the Kubernetes namespace to use
-s, --svc string service name
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
versioned_docs/version-v1.2/cli/vela_trait.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela trait
---
List/get traits.
### Synopsis
List trait types installed and discover more in registry.
```
vela trait [flags]
```
### Examples
```
vela trait
```
### Options
```
--discover discover traits in registries
-h, --help help for trait
--label --label type=terraform a label to filter components, the format is --label type=terraform
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### SEE ALSO
* [vela trait get](vela_trait_get) - get trait from registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
versioned_docs/version-v1.2/cli/vela_trait_get.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela trait get
---
get trait from registry
### Synopsis
get trait from registry
```
vela trait get <trait> [flags]
```
### Examples
```
vela trait get <trait>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### SEE ALSO
* [vela trait](vela_trait) - List/get traits.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

25
versioned_docs/version-v1.2/cli/vela_uischema.md Normal file
View File

@ -0,0 +1,25 @@
---
title: vela uischema
---
Manage UI schema for addons.
### Synopsis
Manage UI schema for addons.
### Options
```
-h, --help help for uischema
```
### SEE ALSO
* [vela uischema apply](vela_uischema_apply) - apply <ui schema file/dir path>
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_uischema_apply.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela uischema apply
---
apply <ui schema file/dir path>
### Synopsis
apply UI schema from a file or dir
```
vela uischema apply [flags]
```
### Options
```
-h, --help help for apply
```
### SEE ALSO
* [vela uischema](vela_uischema) - Manage UI schema for addons.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

31
versioned_docs/version-v1.2/cli/vela_up.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela up
---
Apply an appfile or application from file
### Synopsis
Create or update vela application from file or URL, both appfile or application object format are supported.
```
vela up
```
### Options
```
-e, --env string specify environment name for application
-f, --file string specify file path for appfile or application, it could be a remote url.
-h, --help help for up
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

28
versioned_docs/version-v1.2/cli/vela_version.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela version
---
Prints vela build version information
### Synopsis
Prints vela build version information.
```
vela version [flags]
```
### Options
```
-h, --help help for version
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

29
versioned_docs/version-v1.2/cli/vela_workflow.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela workflow
---
Operate application delivery workflow.
### Synopsis
Operate the Workflow during Application Delivery.
### Options
```
-h, --help help for workflow
```
### SEE ALSO
* [vela workflow restart](vela_workflow_restart) - Restart an application workflow.
* [vela workflow resume](vela_workflow_resume) - Resume a suspend application workflow.
* [vela workflow rollback](vela_workflow_rollback) - Rollback an application workflow to the latest revision.
* [vela workflow suspend](vela_workflow_suspend) - Suspend an application workflow.
* [vela workflow terminate](vela_workflow_terminate) - Terminate an application workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_workflow_restart.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela workflow restart
---
Restart an application workflow.
### Synopsis
Restart an application workflow in cluster.
```
vela workflow restart [flags]
```
### Examples
```
vela workflow restart <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for restart
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_workflow_resume.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela workflow resume
---
Resume a suspend application workflow.
### Synopsis
Resume a suspend application workflow in cluster.
```
vela workflow resume [flags]
```
### Examples
```
vela workflow resume <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for resume
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_workflow_rollback.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela workflow rollback
---
Rollback an application workflow to the latest revision.
### Synopsis
Rollback an application workflow to the latest revision.
```
vela workflow rollback [flags]
```
### Examples
```
vela workflow rollback <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for rollback
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_workflow_suspend.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela workflow suspend
---
Suspend an application workflow.
### Synopsis
Suspend an application workflow in cluster.
```
vela workflow suspend [flags]
```
### Examples
```
vela workflow suspend <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for suspend
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
versioned_docs/version-v1.2/cli/vela_workflow_terminate.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela workflow terminate
---
Terminate an application workflow.
### Synopsis
Terminate an application workflow in cluster.
```
vela workflow terminate [flags]
```
### Examples
```
vela workflow terminate <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for terminate
-n, --namespace string specify the Kubernetes namespace to use
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 12-Jan-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

134
versioned_docs/version-v1.2/developers/cap-center.md Normal file
View File

@ -0,0 +1,134 @@
---
title: Managing Capabilities
---
In KubeVela, developers can install more capabilities (i.e. new component types and traits) from any GitHub repo that contains OAM definition files. We call these GitHub repos as _Capability Centers_.
KubeVela is able to discover OAM definition files in this repo automatically and sync them to your own KubeVela platform.
## Add a capability center
Add a registry in KubeVela:
```bash
vela registry config my-center https://github.com/oam-dev/catalog/tree/master/registry
```
```console
Successfully configured registry my-center
```
Now, this registry `my-center` is ready to use.
## List capability centers
You are allowed to add more capability centers and list them.
```bash
vela registry ls
```
```console
NAME URL
default oss://registry.kubevela.net/
my-center https://github.com/oam-dev/catalog/tree/master/registry
```
## [Optional] Remove a capability center
Or, remove one.
```bash
vela registry remove my-center
```
## List all available capabilities in capability center
Or, list all available ComponentDefinition/TraitDefinition in certain registry.
```bash
vela trait --discover --registry=my-center
vela comp --discover --registry=my-center
## Install a capability from capability center
Now let's try to install the new component named `clonesetservice` from `my-center` to your own KubeVela platform.
You need to install OpenKruise first.
```shell
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
```
Install `clonesetservice` component from `my-center`.
```bash
vela comp get clonesetservice --registry=my-center
```
## Use the newly installed capability
Let's check the `clonesetservice` appears in your platform firstly:
```bash
vela components
```
```console
NAME NAMESPACE WORKLOAD DESCRIPTION
clonesetservice vela-system clonesets.apps.kruise.io Describes long-running, scalable, containerized services
that have a stable network endpoint to receive external
network traffic from customers. If workload type is skipped
for any service defined in Appfile, it will be defaulted to
`webservice` type.
```
Great! Now let's deploy an app via Appfile.
```bash
cat << EOF > vela.yaml
name: testapp
services:
testsvc:
type: clonesetservice
image: crccheck/hello-world
port: 8000
EOF
```
```bash
vela up
```
```console
Parsing vela appfile ...
Load Template ...
Rendering configs for service (testsvc)...
Writing deploy config to (.vela/deploy.yaml)
Applying application ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
Updating: core.oam.dev/v1alpha2, Kind=HealthScope in default
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc testsvc
```
then you can Get a cloneset in your environment.
```shell
kubectl get clonesets.apps.kruise.io
```
```console
NAME DESIRED UPDATED UPDATED_READY READY TOTAL AGE
testsvc 1 1 1 1 1 46s
```
## Uninstall a capability
> NOTE: make sure no apps are using the capability before uninstalling.
```bash
kubectl delete componentdefinition -n vela-system clonesetservice
```

9
versioned_docs/version-v1.2/developers/check-logs.md Normal file
View File

@ -0,0 +1,9 @@
---
title: Check Application Logs
---
```bash
vela logs testapp
```
It will let you select the container to get logs from. If there is only one container it will select automatically.

103
versioned_docs/version-v1.2/developers/check-ref-doc.md Normal file
View File

@ -0,0 +1,103 @@
---
title: The Reference Documentation Guide of Capabilities
---
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform platform-engineerss to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
## Using Browser
Actually, as a important part of its "extensibility" design, KubeVela will always **automatically generate** reference documentation for every workload type or trait registered in your Kubernetes cluster, based on its template in definition of course. This feature works for any capability: either built-in ones or your own workload types/traits.
Thus, as an end user, the only thing you need to do is:
```console
$ vela show WORKLOAD_TYPE or TRAIT --web
```
This command will automatically open the reference documentation for given workload type or trait in your default browser.
### For Workload Types
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` workload type will show up immediately as below:
![](../resources/vela_show_webservice.jpg)
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
### For Traits
Similarly, we can also do `$ vela show autoscale --web`:
![](../resources/vela_show_autoscale.jpg)
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
```yaml
name: helloworld
services:
backend: # copy-paste from the webservice ref doc above
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
cpu: "0.1"
autoscale: # copy-paste and modify from autoscaler ref doc above
min: 1
max: 8
cron:
startAt: "19:00"
duration: "2h"
days: "Friday"
replicas: 4
timezone: "America/Los_Angeles"
```
## Using Terminal
This reference doc feature also works for terminal-only case. For example:
```shell
$ vela show webservice
# Properties
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
| cmd | Commands to run in the container | []string | false | |
| env | Define arguments by using environment variables | [[]env](#env) | false | |
| image | Which image would you like to use for your service | string | true | |
| port | Which port do you want customer traffic sent to | int | true | 80 |
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
## env
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
| name | Environment variable name | string | true | |
| value | The value of the environment variable | string | false | |
| valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false | |
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
### valueFrom
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
| secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true | |
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
#### secretKeyRef
+------+------------------------------------------------------------------+--------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+------+------------------------------------------------------------------+--------+----------+---------+
| name | The name of the secret in the pod's namespace to select from | string | true | |
| key | The key of the secret to select from. Must be a valid secret key | string | true | |
+------+------------------------------------------------------------------+--------+----------+---------+
```
> Note that for all the built-in capabilities, we already published their reference docs [here](https://kubevela.io/#/en/developers/references/) based on the same doc generation mechanism.

97
versioned_docs/version-v1.2/developers/config-app.md Normal file
View File

@ -0,0 +1,97 @@
---
title: Configuring data/env in Application
---
`vela` provides a `config` command to manage config data.
## `vela config set`
```bash
vela config set test a=b c=d
```
```console
reading existing config data and merging with user input
config data saved successfully ✅
```
## `vela config get`
```bash
vela config get test
```
```console
Data:
a: b
c: d
```
## `vela config del`
```bash
vela config del test
```
```console
config (test) deleted successfully
```
## `vela config ls`
```bash
vela config set test a=b
vela config set test2 c=d
vela config ls
```
```console
NAME
test
test2
```
## Configure env in application
The config data can be set as the env in applications.
```bash
vela config set demo DEMO_HELLO=helloworld
```
Save the following to `vela.yaml` in current directory:
```yaml
name: testapp
services:
env-config-demo:
image: heroku/nodejs-hello-world
config: demo
```
Then run:
```bash
vela up
```
```console
Parsing vela.yaml ...
Loading templates ...
Rendering configs for service (env-config-demo)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc env-config-demo
```
Check env var:
```
vela exec testapp -- printenv | grep DEMO_HELLO
```
```console
DEMO_HELLO=helloworld
```

107
versioned_docs/version-v1.2/developers/config-enviroments.md Normal file
View File

@ -0,0 +1,107 @@
---
title: Setting Up Deployment Environment
---
A deployment environment is where you could configure the workspace, email for contact and domain for your applications globally.
A typical set of deployment environment is `test`, `staging`, `prod`, etc.
## Create environment
```bash
vela env init demo --email my@email.com
```
```console
environment demo created, Namespace: default, Email: my@email.com
```
## Check the deployment environment metadata
```bash
vela env ls
```
```console
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * default my@email.com
```
By default, the environment will use `default` namespace in K8s.
## Configure changes
You could change the config by executing the environment again.
```bash
vela env init demo --namespace demo
```
```console
environment demo created, Namespace: demo, Email: my@email.com
```
```bash
vela env ls
```
```console
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * demo my@email.com
```
**Note that the created apps won't be affected, only newly created apps will use the updated info.**
## [Optional] Configure Domain if you have public IP
If your K8s cluster is provisioned by cloud provider and has public IP for ingress.
You could configure your domain in the environment, then you'll be able to visit
your app by this domain with an mTLS supported automatically.
For example, you could get the public IP from ingress service.
```bash
kubectl get svc -A | grep LoadBalancer
```
```console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-lb LoadBalancer 172.21.2.174 123.57.10.233 80:32740/TCP,443:32086/TCP 41d
```
The fourth column is public IP. Configure 'A' record for your custom domain.
```
*.your.domain => 123.57.10.233
```
You could also use `123.57.10.233.xip.io` as your domain, if you don't have a custom one.
`xip.io` will automatically route to the prefix IP `123.57.10.233`.
```bash
vela env init demo --domain 123.57.10.233.xip.io
```
```console
environment demo updated, Namespace: demo, Email: my@email.com
```
### Using domain in Appfile
Since you now have domain configured globally in deployment environment, you don't need to specify the domain in route configuration anymore.
```yaml
# in demo environment
services:
express-server:
...
route:
rules:
- path: /testapp
rewriteTarget: /
```
```
curl http://123.57.10.233.xip.io/testapp
```
```console
Hello World
```

10
versioned_docs/version-v1.2/developers/exec-cmd.md Normal file
View File

@ -0,0 +1,10 @@
---
title: Execute Commands in Container
---
Run:
```
vela exec testapp -- /bin/sh
```
This open a shell within the container of testapp.

238
versioned_docs/version-v1.2/developers/extensions/set-autoscale.md Normal file
View File

@ -0,0 +1,238 @@
---
title: Automatically scale workloads by resource utilization metrics and cron
---
## Prerequisite
Make sure auto-scaler trait controller is installed in your cluster
Install auto-scaler trait controller with helm
1. Add helm chart repo for autoscaler trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install autoscaler trait controller
```shell script
helm install --create-namespace -n vela-system autoscalertrait oam.catalog/autoscalertrait
Autoscale depends on metrics server, please [enable it in your Kubernetes cluster](../references/devex/faq#autoscale-how-to-enable-metrics-server-in-various-kubernetes-clusters) at the beginning.
> Note: autoscale is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting cron auto-scaling policy
Introduce how to automatically scale workloads by cron.
1. Prepare Appfile
```yaml
name: testapp
services:
express-server:
# this image will be used in both build and deploy steps
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
autoscale:
min: 1
max: 4
cron:
startAt: "14:00"
duration: "2h"
days: "Monday, Thursday"
replicas: 2
timezone: "America/Los_Angeles"
```
> The full specification of `autoscale` could show up by `$ vela show autoscale`.
2. Deploy an application
```
$ vela up
Parsing vela.yaml ...
Loading templates ...
Rendering configs for service (express-server)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc express-server
```
3. Check the replicas and wait for the scaling to take effect
Check the replicas of the application, there is one replica.
```
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-05 17:09:02.426632 +0800 CST
Updated at: 2020-11-05 17:09:02.426632 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cron replicas(min/max/current): 1/4/1
Last Deployment:
Created at: 2020-11-05 17:09:03 +0800 CST
Updated at: 2020-11-05T17:09:02+08:00
```
Wait till the time clocks `startAt`, and check again. The replicas become to two, which is specified as
`replicas` in `vela.yaml`.
```
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-10 10:18:59.498079 +0800 CST
Updated at: 2020-11-10 10:18:59.49808 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 2/2
Traits:
- ✅ autoscale: type: cron replicas(min/max/current): 1/4/2
Last Deployment:
Created at: 2020-11-10 10:18:59 +0800 CST
Updated at: 2020-11-10T10:18:59+08:00
```
Wait after the period ends, the replicas will be one eventually.
## Setting auto-scaling policy of CPU resource utilization
Introduce how to automatically scale workloads by CPU resource utilization.
1. Prepare Appfile
Modify `vela.yaml` as below. We add field `services.express-server.cpu` and change the auto-scaling policy
from cron to cpu utilization by updating filed `services.express-server.autoscale`.
```yaml
name: testapp
services:
express-server:
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
cpu: "0.01"
autoscale:
min: 1
max: 5
cpuPercent: 10
```
2. Deploy an application
```bash
$ vela up
```
3. Expose the service entrypoint of the application
```
$ vela port-forward helloworld 80
Forwarding from 127.0.0.1:80 -> 80
Forwarding from [::1]:80 -> 80
Forward successfully! Opening browser ...
Handling connection for 80
Handling connection for 80
Handling connection for 80
Handling connection for 80
```
On your macOS, you might need to add `sudo` ahead of the command.
4. Monitor the replicas changing
Continue to monitor the replicas changing when the application becomes overloaded. You can use Apache HTTP server
benchmarking tool `ab` to mock many requests to the application.
```
$ ab -n 10000 -c 200 http://127.0.0.1/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
```
The replicas gradually increase from one to four.
```
$ vela status helloworld --svc frontend
About:
Name: helloworld
Namespace: default
Created at: 2020-11-05 20:07:21.830118 +0800 CST
Updated at: 2020-11-05 20:50:42.664725 +0800 CST
Services:
- Name: frontend
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cpu cpu-utilization(target/current): 5%/10% replicas(min/max/current): 1/5/2
Last Deployment:
Created at: 2020-11-05 20:07:23 +0800 CST
Updated at: 2020-11-05T20:50:42+08:00
```
```
$ vela status helloworld --svc frontend
About:
Name: helloworld
Namespace: default
Created at: 2020-11-05 20:07:21.830118 +0800 CST
Updated at: 2020-11-05 20:50:42.664725 +0800 CST
Services:
- Name: frontend
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cpu cpu-utilization(target/current): 5%/14% replicas(min/max/current): 1/5/4
Last Deployment:
Created at: 2020-11-05 20:07:23 +0800 CST
Updated at: 2020-11-05T20:50:42+08:00
```
Stop `ab` tool, and the replicas will decrease to one eventually.

107
versioned_docs/version-v1.2/developers/extensions/set-metrics.md Normal file
View File

@ -0,0 +1,107 @@
---
title: Monitoring Application
---
If your application has exposed metrics, you can easily tell the platform how to collect the metrics data from your app with `metrics` capability.
## Prerequisite
Make sure metrics trait controller is installed in your cluster
Install metrics trait controller with helm
1. Add helm chart repo for metrics trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install metrics trait controller
```shell script
helm install --create-namespace -n vela-system metricstrait oam.catalog/metricstrait
> Note: metrics is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting metrics policy
Let's run [`christianhxc/gorandom:1.0`](https://github.com/christianhxc/prometheus-tutorial) as an example app.
The app will emit random latencies as metrics.
1. Prepare Appfile:
```bash
$ cat <<EOF > vela.yaml
name: metricapp
services:
metricapp:
type: webservice
image: christianhxc/gorandom:1.0
port: 8080
metrics:
enabled: true
format: prometheus
path: /metrics
port: 0
scheme: http
EOF
```
> The full specification of `metrics` could show up by `$ vela show metrics`.
2. Deploy the application:
```bash
$ vela up
```
3. Check status:
```bash
$ vela status metricapp
About:
Name: metricapp
Namespace: default
Created at: 2020-11-11 17:00:59.436347573 -0800 PST
Updated at: 2020-11-11 17:01:06.511064661 -0800 PST
Services:
- Name: metricapp
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ metrics: Monitoring port: 8080, path: /metrics, format: prometheus, schema: http.
Last Deployment:
Created at: 2020-11-11 17:00:59 -0800 PST
Updated at: 2020-11-11T17:01:06-08:00
```
The metrics trait will automatically discover port and label to monitor if no parameters specified.
If more than one ports found, it will choose the first one by default.
**(Optional) Verify that the metrics are collected on Prometheus**
<details>
Expose the port of Prometheus dashboard:
```bash
kubectl --namespace monitoring port-forward `kubectl -n monitoring get pods -l prometheus=oam -o name` 9090
```
Then access the Prometheus dashboard via http://localhost:9090/targets
![Prometheus Dashboard](../../resources/metrics.jpg)
</details>

163
versioned_docs/version-v1.2/developers/extensions/set-rollout.md Normal file
View File

@ -0,0 +1,163 @@
---
title: Setting Rollout Strategy
---
> Note: rollout is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
The `rollout` section is used to configure Canary strategy to release your app.
Add rollout config under `express-server` along with a `route`.
```yaml
name: testapp
services:
express-server:
type: webservice
image: oamdev/testapp:rolling01
port: 80
rollout:
replicas: 5
stepWeight: 20
interval: "30s"
route:
domain: "example.com"
```
> The full specification of `rollout` could show up by `$ vela show rollout`.
Apply this `appfile.yaml`:
```bash
$ vela up
```
You could check the status by:
```bash
$ vela status testapp
About:
Name: testapp
Namespace: myenv
Created at: 2020-11-09 17:34:38.064006 +0800 CST
Updated at: 2020-11-10 17:05:53.903168 +0800 CST
Services:
- Name: testapp
Type: webservice
HEALTHY Ready: 5/5
Traits:
- ✅ rollout: interval=5s
replicas=5
stepWeight=20
- ✅ route: Visiting URL: http://example.com IP: <your-ingress-IP-address>
Last Deployment:
Created at: 2020-11-09 17:34:38 +0800 CST
Updated at: 2020-11-10T17:05:53+08:00
```
Visiting this app by:
```bash
$ curl -H "Host:example.com" http://<your-ingress-IP-address>/
Hello World -- Rolling 01
```
In day 2, assuming we have make some changes on our app and build the new image and name it by `oamdev/testapp:v2`.
Let's update the appfile by:
```yaml
name: testapp
services:
express-server:
type: webservice
- image: oamdev/testapp:rolling01
+ image: oamdev/testapp:rolling02
port: 80
rollout:
replicas: 5
stepWeight: 20
interval: "30s"
route:
domain: example.com
```
Apply this `appfile.yaml` again:
```bash
$ vela up
```
You could run `vela status` several times to see the instance rolling:
```shell script
$ vela status testapp
About:
Name: testapp
Namespace: myenv
Created at: 2020-11-12 19:02:40.353693 +0800 CST
Updated at: 2020-11-12 19:02:40.353693 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY express-server-v2:Ready: 1/1 express-server-v1:Ready: 4/4
Traits:
- ✅ rollout: interval=30s
replicas=5
stepWeight=20
- ✅ route: Visiting by using 'vela port-forward testapp --route'
Last Deployment:
Created at: 2020-11-12 17:20:46 +0800 CST
Updated at: 2020-11-12T19:02:40+08:00
```
You could then try to `curl` your app multiple times and and see how the app being rollout following Canary strategy:
```bash
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
```
**How `Rollout` works?**
<details>
`Rollout` trait implements progressive release process to rollout your app following [Canary strategy](https://martinfowler.com/bliki/CanaryRelease.html).
In detail, `Rollout` controller will create a canary of your app , and then gradually shift traffic to the canary while measuring key performance indicators like HTTP requests success rate at the same time.
![alt](../../resources/traffic-shifting-analysis.png)
In this sample, for every `10s`, `5%` traffic will be shifted to canary from the primary, until the traffic on canary reached `50%`. At the mean time, the instance number of canary will automatically scale to `replicas: 2` per configured in Appfile.
Based on analysis result of the KPIs during this traffic shifting, a canary will be promoted or aborted if analysis is failed. If promoting, the primary will be upgraded from v1 to v2, and traffic will be fully shifted back to the primary instances. So as result, canary instances will be deleted after the promotion finished.
![alt](../../resources/promotion.png)
> Note: KubeVela's `Rollout` trait is implemented with [Weaveworks Flagger](https://flagger.app/) operator.
</details>

82
versioned_docs/version-v1.2/developers/extensions/set-route.md Normal file
View File

@ -0,0 +1,82 @@
---
title: Setting Routes
---
The `route` section is used to configure the access to your app.
## Prerequisite
Make sure route trait controller is installed in your cluster
Install route trait controller with helm
1. Add helm chart repo for route trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install route trait controller
```shell script
helm install --create-namespace -n vela-system routetrait oam.catalog/routetrait
> Note: route is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting route policy
Add routing config under `express-server`:
```yaml
services:
express-server:
...
route:
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
```
> The full specification of `route` could show up by `$ vela show route`.
Apply again:
```bash
$ vela up
```
Check the status until we see route is ready:
```bash
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-04 16:34:43.762730145 -0800 PST
Updated at: 2020-11-11 16:21:37.761158941 -0800 PST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: 2020-11-11 16:21:37 -0800 PST
Updated at: 2020-11-11T16:21:37-08:00
Routes:
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
```
**In [kind cluster setup](../../install#kind)**, you can visit the service via localhost:
> If not in kind cluster, replace 'localhost' with ingress address
```
$ curl -H "Host:example.com" http://localhost/testapp
Hello World
```

255
versioned_docs/version-v1.2/developers/learn-appfile.md Normal file
View File

@ -0,0 +1,255 @@
---
title: Learning Appfile
---
A sample `Appfile` is as below:
```yaml
name: testapp
services:
frontend: # 1st service
image: oamdev/testapp:v1
build:
docker:
file: Dockerfile
context: .
cmd: ["node", "server.js"]
port: 8080
route: # trait
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
backend: # 2nd service
type: task # workload type
image: perl
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
Under the hood, `Appfile` will build the image from source code, and then generate `Application` resource with the image name.
## Schema
> Before learning about Appfile's detailed schema, we recommend you to get familiar with [core concepts](../getting-started/core-concept)) in KubeVela.
```yaml
name: _app-name_
services:
_service-name_:
# If `build` section exists, this field will be used as the name to build image. Otherwise, KubeVela will try to pull the image with given name directly.
image: oamdev/testapp:v1
build:
docker:
file: _Dockerfile_path_ # relative path is supported, e.g. "./Dockerfile"
context: _build_context_path_ # relative path is supported, e.g. "."
push:
local: kind # optionally push to local KinD cluster instead of remote registry
type: webservice (default) | worker | task
# detailed configurations of workload
... properties of the specified workload ...
_trait_1_:
# properties of trait 1
_trait_2_:
# properties of trait 2
... more traits and their properties ...
_another_service_name_: # more services can be defined
...
```
> To learn about how to set the properties of specific workload type or trait, please use `vela show <TYPE | TRAIT>`.
## Example Workflow
In the following workflow, we will build and deploy an example NodeJS app under [examples/testapp/](https://github.com/oam-dev/kubevela/tree/master/docs/examples/testapp).
### Prerequisites
- [Docker](https://docs.docker.com/get-docker/) installed on the host
- KubeVela] installed and configured
### 1. Download test app code
git clone and go to the testapp directory:
```bash
git clone https://github.com/oam-dev/kubevela.git
cd kubevela/docs/examples/testapp
```
The example contains NodeJS app code, Dockerfile to build the app.
### 2. Deploy app in one command
In the directory there is a [vela.yaml](https://github.com/oam-dev/kubevela/tree/master/docs/examples/testapp/vela.yaml) which follows Appfile format supported by Vela.
We are going to use it to build and deploy the app.
> NOTE: please change `oamdev` to your own registry account so you can push. Or, you could try the alternative approach in `Local testing without pushing image remotely` section.
```yaml
image: oamdev/testapp:v1 # change this to your image
```
Run the following command:
```bash
vela up
```
```console
Parsing vela.yaml ...
Loading templates ...
Building service (express-server)...
Sending build context to Docker daemon 71.68kB
Step 1/10 : FROM mhart/alpine-node:12
---> 9d88359808c3
...
pushing image (oamdev/testapp:v1)...
...
Rendering configs for service (express-server)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc express-server
```
Check the status of the service:
```bash
vela status testapp
```
```console
About:
Name: testapp
Namespace: default
Created at: 2020-11-02 11:08:32.138484 +0800 CST
Updated at: 2020-11-02 11:08:32.138485 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: 2020-11-02 11:08:33 +0800 CST
Updated at: 2020-11-02T11:08:32+08:00
Routes:
```
#### Alternative: Local testing without pushing image remotely
If you have local kind cluster running, you may try the local push option. No remote container registry is needed in this case.
Add local option to `build`:
```yaml
build:
# push image into local kind cluster without remote transfer
push:
local: kind
docker:
file: Dockerfile
context: .
```
Then deploy the app to kind:
```bash
vela up
```
<details><summary>(Advanced) Check rendered manifests</summary>
By default, Vela renders the final manifests in `.vela/deploy.yaml`:
```yaml
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: testapp
namespace: default
spec:
components:
- componentName: express-server
---
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: express-server
namespace: default
spec:
workload:
apiVersion: apps/v1
kind: Deployment
metadata:
name: express-server
...
---
apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
metadata:
name: testapp-default-health
namespace: default
spec:
...
```
</details>
### [Optional] Configure another workload type
By now we have deployed a *[Web Service](../end-user/components/cue/webservice)*, which is the default workload type in KubeVela. We can also add another service of *[Task](../end-user/components/cue/task)* type in the same app:
```yaml
services:
pi:
type: task
image: perl
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
express-server:
...
```
Then deploy Appfile again to update the application:
```bash
vela up
```
Congratulations! You have just deployed an app using `Appfile`.
## What's Next?
Play more with your app:
- [Check Application Logs](./check-logs)
- [Execute Commands in Application Container](./exec-cmd)
- [Access Application via Route](./port-forward)

27
versioned_docs/version-v1.2/developers/port-forward.md Normal file
View File

@ -0,0 +1,27 @@
---
title: Port Forwarding
---
Once your web services of the application deployed, you can access it locally via `port-forward`.
```bash
vela ls
```
```console
NAME APP WORKLOAD TRAITS STATUS CREATED-TIME
express-server testapp webservice Deployed 2020-09-18 22:42:04 +0800 CST
```
It will directly open browser for you.
```bash
vela port-forward testapp
```
```console
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
Handling connection for 8080
```

28
versioned_docs/version-v1.2/developers/references/devex/cli.md Normal file
View File

@ -0,0 +1,28 @@
---
title: KubeVela CLI
---
### Auto-completion
#### bash
```bash
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
#### zsh
```bash
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```

10
versioned_docs/version-v1.2/developers/references/devex/dashboard.md Normal file
View File

@ -0,0 +1,10 @@
# 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.

337
versioned_docs/version-v1.2/developers/references/devex/faq.md Normal file
View File

@ -0,0 +1,337 @@
---
title: FAQ
---
- [Compare to X](#Compare-to-X)
* [What is the difference between KubeVela and Helm?](#What-is-the-difference-between-KubeVela-and-Helm?)
- [Issues](#issues)
* [Error: unable to create new content in namespace cert-manager because it is being terminated](#error-unable-to-create-new-content-in-namespace-cert-manager-because-it-is-being-terminated)
* [Error: ScopeDefinition exists](#error-scopedefinition-exists)
* [You have reached your pull rate limit](#You-have-reached-your-pull-rate-limit)
* [Warning: Namespace cert-manager exists](#warning-namespace-cert-manager-exists)
* [How to fix issue: MutatingWebhookConfiguration mutating-webhook-configuration exists?](#how-to-fix-issue-mutatingwebhookconfiguration-mutating-webhook-configuration-exists)
- [Operating](#operating)
* [Autoscale: how to enable metrics server in various Kubernetes clusters?](#autoscale-how-to-enable-metrics-server-in-various-kubernetes-clusters)
## Compare to X
### What is the difference between KubeVela and Helm?
KubeVela is a platform builder tool to create easy-to-use yet extensible app delivery/management systems with Kubernetes. KubeVela relies on Helm as templating engine and package format for apps. But Helm is not the only templating module that KubeVela supports. Another first-class supported approach is CUE.
Also, KubeVela is by design a Kubernetes controller (i.e. works on server side), even for its Helm part, a Helm operator will be installed.
## Issues
### Error: unable to create new content in namespace cert-manager because it is being terminated
Occasionally you might hit the issue as below. It happens when the last KubeVela release deletion hasn't completed.
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: serviceaccounts "cert-manager-cainjector" is forbidden: unable to create new content in namespace cert-manager because it is being terminated
failed to create resource
helm.sh/helm/v3/pkg/kube.(*Client).Update.func1
/home/runner/go/pkg/mod/helm.sh/helm/v3@v3.2.4/pkg/kube/client.go:190
...
Error: failed to create resource: serviceaccounts "cert-manager-cainjector" is forbidden: unable to create new content in namespace cert-manager because it is being terminated
```
Take a break and try again in a few seconds.
```
vela install
```
```console
- Installing Vela Core Chart:
Vela system along with OAM runtime already exist.
Automatically discover capabilities successfully ✅ Add(0) Update(0) Delete(8)
TYPE CATEGORY DESCRIPTION
-task workload One-off task to run a piece of code or script to completion
-webservice workload Long-running scalable service with stable endpoint to receive external traffic
-worker workload Long-running scalable backend worker without network endpoint
-autoscale trait Automatically scale the app following certain triggers or metrics
-metrics trait Configure metrics targets to be monitored for the app
-rollout trait Configure canary deployment strategy to release the app
-route trait Configure route policy to the app
-scaler trait Manually scale the app
- Finished successfully.
```
And manually apply all WorkloadDefinition and TraitDefinition manifests to have all capabilities back.
```
vela up -f charts/vela-core/templates/defwithtemplate
```
```console
traitdefinition.core.oam.dev/autoscale created
traitdefinition.core.oam.dev/scaler created
traitdefinition.core.oam.dev/metrics created
traitdefinition.core.oam.dev/rollout created
traitdefinition.core.oam.dev/route created
workloaddefinition.core.oam.dev/task created
workloaddefinition.core.oam.dev/webservice created
workloaddefinition.core.oam.dev/worker created
```
```
vela workloads
```
```console
Automatically discover capabilities successfully ✅ Add(8) Update(0) Delete(0)
TYPE CATEGORY DESCRIPTION
+task workload One-off task to run a piece of code or script to completion
+webservice workload Long-running scalable service with stable endpoint to receive external traffic
+worker workload Long-running scalable backend worker without network endpoint
+autoscale trait Automatically scale the app following certain triggers or metrics
+metrics trait Configure metrics targets to be monitored for the app
+rollout trait Configure canary deployment strategy to release the app
+route trait Configure route policy to the app
+scaler trait Manually scale the app
NAME DESCRIPTION
task One-off task to run a piece of code or script to completion
webservice Long-running scalable service with stable endpoint to receive external traffic
worker Long-running scalable backend worker without network endpoint
```
### Error: ScopeDefinition exists
Occasionally you might hit the issue as below. It happens when there is an old OAM Kubernetes Runtime release, or you applied `ScopeDefinition` before.
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: ScopeDefinition "healthscopes.core.oam.dev" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "kubevela": current value is "oam"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "vela-system": current value is "oam-system"
rendered manifests contain a resource that already exists. Unable to continue with install
helm.sh/helm/v3/pkg/action.(*Install).Run
/home/runner/go/pkg/mod/helm.sh/helm/v3@v3.2.4/pkg/action/install.go:274
...
Error: rendered manifests contain a resource that already exists. Unable to continue with install: ScopeDefinition "healthscopes.core.oam.dev" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "kubevela": current value is "oam"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "vela-system": current value is "oam-system"
```
Delete `ScopeDefinition` "healthscopes.core.oam.dev" and try again.
```
kubectl delete ScopeDefinition "healthscopes.core.oam.dev"
```
```console
scopedefinition.core.oam.dev "healthscopes.core.oam.dev" deleted
```
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Successfully installed the chart, status: deployed, last deployed time = 2020-12-03 16:26:41.491426 +0800 CST m=+4.026069452
WARN: handle workload template `containerizedworkloads.core.oam.dev` failed: no template found, you will unable to use this workload capabilityWARN: handle trait template `manualscalertraits.core.oam.dev` failed
: no template found, you will unable to use this trait capabilityAutomatically discover capabilities successfully ✅ Add(8) Update(0) Delete(0)
TYPE CATEGORY DESCRIPTION
+task workload One-off task to run a piece of code or script to completion
+webservice workload Long-running scalable service with stable endpoint to receive external traffic
+worker workload Long-running scalable backend worker without network endpoint
+autoscale trait Automatically scale the app following certain triggers or metrics
+metrics trait Configure metrics targets to be monitored for the app
+rollout trait Configure canary deployment strategy to release the app
+route trait Configure route policy to the app
+scaler trait Manually scale the app
- Finished successfully.
```
### You have reached your pull rate limit
When you look into the logs of Pod kubevela-vela-core and found the issue as below.
```
kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core
```
```console
NAME READY STATUS RESTARTS AGE
kubevela-vela-core-f8b987775-wjg25 0/1 - 0 35m
```
>Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by
>authenticating and upgrading: https://www.docker.com/increase-rate-limit
You can use github container registry instead.
```
docker pull ghcr.io/oam-dev/kubevela/vela-core:latest
```
### Warning: Namespace cert-manager exists
If you hit the issue as below, an `cert-manager` release might exist whose namespace and RBAC related resource conflict
with KubeVela.
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: Namespace "cert-manager" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
rendered manifests contain a resource that already exists. Unable to continue with install
helm.sh/helm/v3/pkg/action.(*Install).Run
/home/runner/go/pkg/mod/helm.sh/helm/v3@v3.2.4/pkg/action/install.go:274
...
/opt/hostedtoolcache/go/1.14.12/x64/src/runtime/asm_amd64.s:1373
Error: rendered manifests contain a resource that already exists. Unable to continue with install: Namespace "cert-manager" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
```
Try these steps to fix the problem.
- Delete release `cert-manager`
- Delete namespace `cert-manager`
- Install KubeVela again
```
helm delete cert-manager -n cert-manager
```
```console
release "cert-manager" uninstalled
```
```
kubectl delete ns cert-manager
```
```console
namespace "cert-manager" deleted
```
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Successfully installed the chart, status: deployed, last deployed time = 2020-12-04 10:46:46.782617 +0800 CST m=+4.248889379
Automatically discover capabilities successfully ✅ (no changes)
TYPE CATEGORY DESCRIPTION
task workload One-off task to run a piece of code or script to completion
webservice workload Long-running scalable service with stable endpoint to receive external traffic
worker workload Long-running scalable backend worker without network endpoint
autoscale trait Automatically scale the app following certain triggers or metrics
metrics trait Configure metrics targets to be monitored for the app
rollout trait Configure canary deployment strategy to release the app
route trait Configure route policy to the app
scaler trait Manually scale the app
- Finished successfully.
```
### How to fix issue: MutatingWebhookConfiguration mutating-webhook-configuration exists?
If you deploy some other services which will apply MutatingWebhookConfiguration mutating-webhook-configuration, installing
KubeVela will hit the issue as below.
```shell
- Installing Vela Core Chart:
install chart vela-core, version v0.2.1, desc : A Helm chart for Kube Vela core, contains 36 file
Failed to install the chart with error: MutatingWebhookConfiguration "mutating-webhook-configuration" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
rendered manifests contain a resource that already exists. Unable to continue with install
helm.sh/helm/v3/pkg/action.(*Install).Run
/home/runner/go/pkg/mod/helm.sh/helm/v3@v3.2.4/pkg/action/install.go:274
github.com/oam-dev/kubevela/pkg/commands.InstallOamRuntime
/home/runner/work/kubevela/kubevela/pkg/commands/system.go:259
github.com/oam-dev/kubevela/pkg/commands.(*initCmd).run
/home/runner/work/kubevela/kubevela/pkg/commands/system.go:162
github.com/oam-dev/kubevela/pkg/commands.NewInstallCommand.func2
/home/runner/work/kubevela/kubevela/pkg/commands/system.go:119
github.com/spf13/cobra.(*Command).execute
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:850
github.com/spf13/cobra.(*Command).ExecuteC
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:958
github.com/spf13/cobra.(*Command).Execute
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:895
main.main
/home/runner/work/kubevela/kubevela/references/cmd/cli/main.go:16
runtime.main
/opt/hostedtoolcache/go/1.14.13/x64/src/runtime/proc.go:203
runtime.goexit
/opt/hostedtoolcache/go/1.14.13/x64/src/runtime/asm_amd64.s:1373
Error: rendered manifests contain a resource that already exists. Unable to continue with install: MutatingWebhookConfiguration "mutating-webhook-configuration" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
```
To fix this issue, please upgrade KubeVela Cli `vela` version to be higher than `v0.2.2` from [KubeVela releases](https://github.com/oam-dev/kubevela/releases).
## Operating
### Autoscale: how to enable metrics server in various Kubernetes clusters?
Operating Autoscale depends on metrics server, so it has to be enabled in various clusters. Please check whether metrics server
is enabled with command `kubectl top nodes` or `kubectl top pods`.
If the output is similar as below, the metrics is enabled.
```shell
kubectl top nodes
```
```console
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
cn-hongkong.10.0.1.237 288m 7% 5378Mi 78%
cn-hongkong.10.0.1.238 351m 8% 5113Mi 74%
```
```
kubectl top pods
```
```console
NAME CPU(cores) MEMORY(bytes)
php-apache-65f444bf84-cjbs5 0m 1Mi
wordpress-55c59ccdd5-lf59d 1m 66Mi
```
Or you have to manually enable metrics server in your Kubernetes cluster.
- ACK (Alibaba Cloud Container Service for Kubernetes)
Metrics server is already enabled.
- ASK (Alibaba Cloud Serverless Kubernetes)
Metrics server has to be enabled in `Operations/Add-ons` section of [Alibaba Cloud console](https://cs.console.aliyun.com/) as below.
![](../../../resources/install-metrics-server-in-ASK.jpg)
Please refer to [metrics server debug guide](https://help.aliyun.com/document_detail/176515.html) if you hit more issue.
- Kind
Install metrics server as below, or you can install the [latest version](https://github.com/kubernetes-sigs/metrics-server#installation).
```shell
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml
```
Also add the following part under `.spec.template.spec.containers` in the yaml file loaded by `kubectl edit deploy -n kube-system metrics-server`.
Noted: This is just a walk-around, not for production-level use.
```
command:
- /metrics-server
- --kubelet-insecure-tls
```
- MiniKube
Enable it with following command.
```shell
minikube addons enable metrics-server
```
Have fun to [set autoscale](../../extensions/set-autoscale) on your application.

10
versioned_docs/version-v1.2/developers/references/restful-api/rest.mdx Normal file
View File

@ -0,0 +1,10 @@
---
title: Restful API
---
import useBaseUrl from '@docusaurus/useBaseUrl';
<a
target="_blank"
href={useBaseUrl('/restful-api')}>
KubeVela Restful API
</a>

5
versioned_docs/version-v1.2/end-user/component-observability.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Component Observability
---
WIP

158
versioned_docs/version-v1.2/end-user/components/cloud-services/provider-and-consume-cloud-services.md Normal file
View File

@ -0,0 +1,158 @@
---
title: Provision and Binding Cloud Resources
---
Cloud-oriented development is now becoming the norm, there is an urgent need to integrate cloud resources from different
sources and types. Whether it is the most basic object storage, cloud database, or load balancing, it is all faced with
the challenges of hybrid cloud, multi-cloud and other complex environments. KubeVela is perfect to satisfy the needs.
KubeVela efficiently and securely integrates different types of cloud resources through resource binding capabilities in
cloud resource Components and Traits. At present, you can directly use the default components of those cloud resources below.
At the same time, more new cloud resources will gradually become the default option under the support of the community in the future.
You can use cloud resources of various manufacturers in a standardized and unified way.
This tutorial will talk about how to provision and consume Cloud Resources by Terraform.
> ⚠️ This section requires your platform engineers have already enabled [add-on 'terraform/provider-alicloud'](../../../install#4-optional-enable-addons).
## Supported Cloud Resource list
Orchestration Type | Cloud Provider | Cloud Resource | Description
------------ | ------------- | ------------- | -------------
Terraform | Alibaba Cloud | [ACK](./terraform/alibaba-ack) | Terraform configuration for Alibaba Cloud ACK cluster
| | | [EIP](./terraform/alibaba-eip) | Terraform configuration for Alibaba Cloud EIP
| | | [OSS](./terraform/alibaba-oss) | Terraform configuration for Alibaba Cloud OSS
| | | [RDS](./terraform/alibaba-rds) | Terraform configuration for Alibaba Cloud RDS
| | | [Redis](./terraform/alibaba-redis) | Terraform configuration for Alibaba Cloud Redis
| | | [VPC](./terraform/alibaba-vpc) | Terraform configuration for Alibaba Cloud VPC
| | Azure | [Mariadb](./terraform/azure-database-mariadb) | Terraform configuration for Azure Database Mariadb
| | Azure | [Storage Account](./terraform/azure-storage-account) | Terraform configuration for Azure Storage Account
| | AWS | [S3](./terraform/aws-s3) | Terraform configuration for AWS S3 bucket
## Terraform
All supported Terraform cloud resources can be seen in the list above. You can also filter them by command by `vela components --label type=terraform`.
### Provision cloud resources
Use the following Application to provision an OSS bucket:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: provision-cloud-resource-sample
spec:
components:
- name: sample-oss
type: alibaba-oss
properties:
bucket: vela-website-0911
acl: private
writeConnectionSecretToRef:
name: oss-conn
```
The above `alibaba-oss` component will create an OSS bucket named `vela-website-0911`, with private acl, with connection information stored in a secreted named `oss-conn`.
description, whether it's compulsory, and default value.
Apply the above application, then check the status:
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
provision-cloud-resource-sample sample-oss alibaba-oss running healthy Cloud resources are deployed and ready to use 2021-09-11 12:55:57 +0800 CST
```
After the phase becomes `running` and `healthy`, you can then check the OSS bucket in Alibaba Cloud console or by [ossutil](https://partners-intl.aliyun.com/help/doc-detail/50452.htm)
command.
```shell
$ ossutil ls oss://
CreationTime Region StorageClass BucketName
2021-09-11 12:56:17 +0800 CST oss-cn-beijing Standard oss://vela-website-0911
```
### Bind cloud resources
Let's deploy
the [application](https://github.com/oam-dev/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.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webapp
spec:
components:
- name: express-server
type: webservice
properties:
image: zzxwill/flask-web-application:v0.3.1-crossplane
port: 80
traits:
- type: service-binding
properties:
envMappings:
# environments refer to db-conn secret
DB_PASSWORD:
secret: db-conn # 1) If the env name is the same as the secret key, secret key can be omitted.
endpoint:
secret: db-conn
key: DB_HOST # 2) If the env name is different from secret key, secret key has to be set.
username:
secret: db-conn
key: DB_USER
# environments refer to oss-conn secret
BUCKET_NAME:
secret: oss-conn
- name: sample-db
type: alibaba-rds
properties:
instance_name: sample-db
account_name: oamtest
password: U34rfwefwefffaked
writeConnectionSecretToRef:
name: db-conn
- name: sample-oss
type: alibaba-oss
properties:
bucket: vela-website-0911
acl: private
writeConnectionSecretToRef:
name: oss-conn
```
The component `sample-db` will generate secret `db-conn` with [these keys](./terraform/alibaba-rds#outputs), and the component
`sample-oss` will generate secret `oss-conn`. These secrets are binded to the Envs of component `express-server` by trait
[Service Binding](../../traits/service-binding). Then the component can consume instances of OSS and RDS.
Deploy and verify the application.
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
webapp express-server webservice service-binding running healthy 2021-09-08 16:50:41 +0800 CST
├─ sample-db alibaba-rds running healthy 2021-09-08 16:50:41 +0800 CST
└─ sample-oss alibaba-oss running healthy 2021-09-08 16:50:41 +0800 CST
```
```shell
$ vela port-forward webapp
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
```
![](../../../resources/crossplane-visit-application-v3.jpg)
## Next
- [Component Observability](../../component-observability)
- [Data Pass Between Components ](../../workflow/component-dependency-parameter)
- [Multi-Cluster and Environment](../../../case-studies/multi-cluster)

76
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-ack.md Normal file
View File

@ -0,0 +1,76 @@
---
title: Alibaba Cloud ACK
---
## Description
Terraform configuration for Alibaba Cloud ACK cluster
## Sample
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: ack-cloud-source
spec:
components:
- name: ack-cluster
type: alibaba-ack
properties:
writeConnectionSecretToRef:
name: ack-conn
namespace: vela-system
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
k8s_worker_number | The number of worker nodes in kubernetes cluster. | number | false |
zone_id | Availability Zone ID | string | false |
node_cidr_mask | The node cidr block to specific how many pods can run on single node. Valid values: [24-28]. | number | false |
proxy_mode | Proxy mode is option of kube-proxy. Valid values: 'ipvs','iptables'. Default to 'iptables'. | string | false |
password | The password of ECS instance. | string | false |
k8s_version | The version of the kubernetes version. Valid values: '1.16.6-aliyun.1','1.14.8-aliyun.1'. Default to '1.16.6-aliyun.1'. | string | false |
memory_size | Memory size used to fetch instance types. | number | false |
vpc_cidr | The cidr block used to launch a new vpc when 'vpc_id' is not specified. | string | false |
vswitch_cidrs | List of cidr blocks used to create several new vswitches when 'vswitch_ids' is not specified. | list | false |
master_instance_types | The ecs instance types used to launch master nodes. | list | false |
worker_instance_types | The ecs instance types used to launch worker nodes. | list | false |
install_cloud_monitor | Install cloud monitor agent on ECS. | bool | false |
k8s_service_cidr | The kubernetes service cidr block. It cannot be equals to vpc's or vswitch's or pod's and cannot be in them. | string | false |
cpu_core_count | CPU core count is used to fetch instance types. | number | false |
vpc_name | The vpc name used to create a new vpc when 'vpc_id' is not specified. Default to variable `example_name` | string | false |
vswitch_name_prefix | The vswitch name prefix used to create several new vswitches. Default to variable 'example_name'. | string | false |
number_format | The number format used to output. | string | false |
vswitch_ids | List of existing vswitch id. | list | false |
k8s_name_prefix | The name prefix used to create several kubernetes clusters. Default to variable `example_name` | string | false |
new_nat_gateway | Whether to create a new nat gateway. In this template, a new nat gateway will create a nat gateway, eip and server snat entries. | bool | false |
enable_ssh | Enable login to the node through SSH. | bool | false |
cpu_policy | kubelet cpu policy. Valid values: 'none','static'. Default to 'none'. | string | false |
k8s_pod_cidr | The kubernetes pod cidr block. It cannot be equals to vpc's or vswitch's and cannot be in them. | string | false |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | false |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
## Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
name | ACK Kubernetes cluster name |
kubeconfig | The KubeConfig string for the ACK Kubernetes cluster |

51
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-eip.md Normal file
View File

@ -0,0 +1,51 @@
---
title: Alibaba Cloud EIP
---
## Description
Terraform configuration for Alibaba Cloud Elastic IP
## Samples
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: provision-cloud-resource-eip
spec:
components:
- name: sample-eip
type: alibaba-eip
properties:
writeConnectionSecretToRef:
name: eip-conn
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | Name to be used on all resources as prefix. Default to 'TF-Module-EIP'. | string | true |
bandwidth | Maximum bandwidth to the elastic public network, measured in Mbps (Mega bit per second). | number | true |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | true |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
## Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
EIP_ADDRESS | EIP address |

53
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-oss.md Normal file
View File

@ -0,0 +1,53 @@
---
title: Alibaba Cloud OSS
---
## Description
Terraform configuration for Alibaba Cloud OSS object
## Samples
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: oss-cloud-source
spec:
components:
- name: sample-oss
type: alibaba-oss
properties:
bucket: vela-website
acl: private
writeConnectionSecretToRef:
name: oss-conn
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
bucket | OSS bucket name | string | true |
acl | OSS bucket ACL, supported 'private', 'public-read', 'public-read-write' | string | true |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | true |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
## Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
BUCKET_NAME | OSS bucket name |

66
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-rds.md Normal file
View File

@ -0,0 +1,66 @@
---
title: Alibaba Cloud RDS
---
## Description
Terraform configuration for Alibaba Cloud RDS object
## Samples
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: rds-cloud-source
spec:
components:
- name: sample-db
type: alibaba-rds
properties:
instance_name: sample-db
account_name: oamtest
password: U34rfwefwefffaked
writeConnectionSecretToRef:
name: db-conn
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
allocate_public_connection | Whether to allocate public connection for a RDS instance. | bool | true |
security_ips | List of IP addresses allowed to access all databases of an instance | list | true |
database_name | Database name | string | true |
privilege | The privilege of one account access database. | string | true |
instance_name | RDS instance name | string | true |
account_name | RDS instance user account name | string | true |
password | RDS instance account password | string | true |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | true |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
### Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
DB_NAME | RDS Instance Name
DB_USER | RDS Instance User
DB_PORT | RDS Instance Port
DB_HOST | RDS Instance Host
DB_PASSWORD | RDS Instance Password
DB_PUBLIC_HOST | RDS Instance Public Host
DATABASE_NAME | RDS Database Name
DB_ID | RDS Instance ID

55
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-redis.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Alibaba Cloud Redis
---
## Description
Terraform configuration for Alibaba Cloud Redis object
## Sample
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: redis-cloud-source
spec:
components:
- name: sample-redis
type: alibaba-redis
properties:
instance_name: oam-redis
account_name: oam
password: Xyfff83jfewGGfaked
writeConnectionSecretToRef:
name: redis-conn
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
password | Redis instance account password | string | true |
instance_name | Redis instance name | string | true |
account_name | Redis instance user account name | string | true |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | true |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
## Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
REDIS_NAME | redis instance name |
REDIS_USER | redis instance username |
REDIS_PASSWORD | redis instance password |
REDIS_REDIS_CONNECT_ADDRESS | redis connect address |

54
versioned_docs/version-v1.2/end-user/components/cloud-services/terraform/alibaba-vpc.md Normal file
View File

@ -0,0 +1,54 @@
---
title: Alibaba Cloud VPC
---
## Description
Terraform configuration for Alibaba Cloud VPC
## Samples
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-vpc-sample
spec:
components:
- name: sample-vpc
type: alibaba-vpc
properties:
vpc_cidr: "172.16.0.0/12"
writeConnectionSecretToRef:
name: vpc-conn
```
## Specification
### Properties
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
vpc_name | The vpc name used to launch a new vpc. | string | true |
vpc_description | The vpc description used to launch a new vpc. | string | true |
vpc_cidr | The cidr block used to launch a new vpc. | string | true |
writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false |
#### writeConnectionSecretToRef
Name | Description | Type | Required | Default
------------ | ------------- | ------------- | ------------- | -------------
name | The secret name which the cloud resource connection will be written to | string | true |
namespace | The secret namespace which the cloud resource connection will be written to | string | false |
### Outputs
If `writeConnectionSecretToRef` is set, a secret will be generated with these keys as below:
Name | Description
------------ | -------------
VPC_ID | The vpc id of the newly created vpc.

Some files were not shown because too many files have changed in this diff Show More