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

update v1.3 docs 

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun 2022-05-18 15:30:35 +08:00
parent 4a483c022e
commit b1e0332cb4
13 changed files with 294 additions and 164 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/getting-started/introduction.md
View File

@ -71,4 +71,4 @@ Welcome onboard and sail Vela!
## What's Next
- Start to [install KubeVela](./install).
- Learn [Core Concepts](./core-concept) to know more about how it works.
- Learn [Core Concepts](./getting-started/core-concept) to know more about how it works.

2
versioned_docs/version-v1.3/getting-started/architecture.md
View File

@ -14,7 +14,7 @@ For easy integration with upstream CI pipelines and GitOps tools, KubeVela API (
`Application` for designing application deployment plan.
`X-Definitions` for managing the abstraction and capabilities of KubeVela with CUE.
`Definitions` for managing the abstraction and capabilities of KubeVela with CUE.
- e.g. `ComponentDefinition`, `TraitDefinition`, etc.

83
versioned_docs/version-v1.3/getting-started/core-concept.md
View File

@ -1,39 +1,76 @@
---
title: Core Concept
title: Application
---
KubeVela revolves around cloud-native application delivery and management scenarios. The application delivery model behind it is [Open Application Model](../platform-engineers/oam/oam-model), or OAM for short. It describes various components and operational traits required for application as a unified, and infrastructure-independent "deployment plan". As a result, we can achieve standardized and efficient application delivery in a multi-cloud/hybrid-cloud environment. KubeVela includes the following core concepts:
KubeVela revolves around cloud-native application delivery scenarios. The application delivery model behind it is [Open Application Model](https://oam.dev/), or OAM for short.
## An Abstraction to Model Application Deployment Process
OAM allows end users to work with a simple artifact to capture the complete application deployment workflow with easier primitives. This provides a simpler path for on-boarding end users to the platform without leaking low level details in runtime infrastructure and allows users to fully focus on the application delivery itself.
![alt](../resources/model.png)
Every application deployment plan can be composed by multiple components with attachable operational behaviors (traits), deployment policy and workflow. It works in the following format:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: <name>
spec:
components:
- name: <component name>
type: <component type>
properties:
<parameter values>
traits:
- type: <trait type>
properties:
<traits parameter values>
- name: <component name>
type: <component type>
properties:
<parameter values>
policies:
- name: <policy name>
type: <policy type>
properties:
<policy parameter values>
workflow:
- name: <step name>
type: <step type>
properties:
<step parameter values>
```
This `Application` entity will reference `component`, `trait`, `policy` and `workflow step` types which are essentially programmable modules that are maintained by platform team. Hence, this abstraction is highly extensible and can be customized in-place at ease.
* **Component**: A Component defines the delivery artifact (binary, Docker image, Helm Chart...) or cloud service included in one application. As we will regard an application as a microservice business unit, the best practice is to having one component as the core and the others are dependencies with a maximum number under control.
* **Trait**: Traits are management requirements of an artifact that can be declared with each Component. For example: scale and rollout strategy, persistent storage claim, gateway endpoint and so on.
* **Policy**: Policy defines a strategy of certain aspect for application as to multi-cluster topology, configuration overrides, security/firewall rules, SLO and etc. It's a bit similar with traits but take affects to the whole application instead of one component.
* **Workflow Step**: Workflow step allows you to define every steps in the delivery process, typical steps are manual approval, partial deploy, notification.
The modules that make up the application are all extensible, they are defined by a bunch of programmable configurations called [Definitions](../platform-engineers/oam/x-definition). Under the hood, KubeVela will glue and leverage Kubernetes API to drive the infrastructure capabilities. You can check the following picture to see their relationships:
![alt](../resources/oam-concept.png)
## Application
## Package for programmable capabilities
An application defines the delivery and management requirements of an artifact (binary, Docker image, Helm Chart...) or cloud service included in a microservice business unit. It consists of four parts: [Component](#component), [Trait](#trait), [Workflow](#workflow) and [Policy](#policy).
A package of OAM Definitions and [Kubernetes CRD Controller](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) is called an `Addon`. KubeVela has a large and growing [catalog](https://github.com/kubevela/catalog) of addons to support modern application delivery, such as [terraform](https://github.com/kubevela/catalog/tree/master/addons/terraform) for cloud resource provisioning, [OCM](https://github.com/kubevela/catalog/tree/master/addons/ocm-hub-control-plane) for multi-cluster management, [fluxcd](https://github.com/kubevela/catalog/tree/master/addons/fluxcd) for gitops, and etc.
### Component
With these addons, KubeVela provides a unified and good experience for developers to deliver modern application in a multi-cloud/hybrid-cloud environment.
Component defines the artifact of application，The best practice is to having one core component and subordinate components around it. Its type decided by [Component Definition](../platform-engineers/oam/x-definition#componentdefinition) .
## No Configuration Drift
### Trait
Despite the efficiency and extensibility in abstracting application deployment, programmable (Infrastructure-as-Code) approach may lead to an issue called *Infrastructure/Configuration Drift*, i.e. the rendered component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes. This makes them can be barely used as a platform level building block.
Traits are plugable operations that can attach to Component, for example: scaler for replicas(manual and auto), PVC, gateway, DNS and so on. You can draw out-of-box Trait from the ecosystem or simply customize by [Trait Definition](../platform-engineers/oam/x-definition#traitdefinition).
Hence, KubeVela is designed to maintain all these programmable capabilities with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, while still keeps the flexibly and velocity enabled by IaC.
### Workflow
Workflow allows you to define critical step in the process of application delivery, typical steps will be manual approve, data passing, release across multi-cluster, notification and etc. Its type can be defined and customized by [Workflow Step Definition](../platform-engineers/oam/x-definition#workflowstepdefinition).
### Policy
Policy defines a strategy of certain aspect for application as to quality assurance, security, firewall rules, SLO and etc. Its type can be defined and customized by [Policy Definition](../platform-engineers/oam/x-definition#policydefinition).
## Cluster
Import and manage your Kubernetes cluster in KubeVela。Kubernetes cluster is one of the main way for KubeVela application delivery.
## Addon
Addon is where you can freely pull in third-party capability that fulfills your need. This relies on the highly scalable design pattern of KubeVela. Each Addon will have its own [X-Definition](../platform-engineers/oam/x-definition).
## Next Step
- Learn [Definition](./definition) concept to understand how the extension mechanism works.
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.

179
versioned_docs/version-v1.3/getting-started/definition.md Normal file
View File

@ -0,0 +1,179 @@
---
title: Definition
---
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
## Sources of Definitions
There're two sources of definitions:
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
- [Component Definition](../end-user/components/references)
- [Trait Definition](../end-user/traits/references)
- [Policy Definition](../end-user/policies/references)
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
* Installation of addons will install definitions if there're new capabilities contained. You can refer to [the official addon registry](../reference/addons/overview) for more details.
## Lifecycle of a Definition
A definition's lifecycle usually has 3 stages:
### Discovery
When definitions installed in the system, they can be discovered by end user immediately.
* Check the list:
```
$ vela def list
NAME TYPE NAMESPACE DESCRIPTION
task ComponentDefinition vela-system Describes jobs that run code or a script to completion.
webservice ComponentDefinition vela-system Describes long-running, scalable, containerized services
that have a stable network endpoint to receive external
network traffic from customers.
gateway TraitDefinition vela-system Enable public web traffic for the component, the ingress API
matches K8s v1.20+.
labels TraitDefinition vela-system Add labels on K8s pod for your workload which follows the
pod spec in path 'spec.template'.
health PolicyDefinition vela-system Apply periodical health checking to the application.
deploy WorkflowStepDefinition vela-system Deploy components with policies.
notification WorkflowStepDefinition vela-system Send message to webhook
...snip...
```
* Show the details:
```
$ 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 | |
| labels | Specify the labels in the workload | map[string]string | false | |
| annotations | Specify the annotations in the workload | map[string]string | false | |
| image | Which image would you like to use for your service | string | true | |
| ports | Which ports do you want customer traffic sent to, defaults to 80 | [[]ports](#ports) | false | |
+------------------+-------------------------------------------------------------------------------------------+-----------------------------------+----------+---------+
...snip...
```
You can also view the details with a browser, the following command will launch a server and invoke your browser automatically:
```
vela show webservice --web
```
* Discover in UI console
![alt](../resources/definition-ui.png)
These definitions can also be discovered by the UI console, the more important thing is they can be displayed very well with [ui schema](../reference/ui-schema) defined.
### Use
If you're a fan of our UI console, the usage of definition is very straight forward, just click along with the creation of the deployment process.
![alt](../resources/usage-of-def.png)
Finally, the UI console will compose the whole deployment plan in the format of OAM like below, then KubeVela controller will take care of the rest things:
```
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: express-server
type: webservice
properties:
image: oamdev/hello-world
ports:
- port: 8000
expose: true
traits:
- type: scaler
properties:
replicas: 1
policies:
- name: target-default
type: topology
properties:
clusters: ["local"]
namespace: "default"
- name: target-prod
type: topology
properties:
clusters: ["local"]
namespace: "prod"
- name: deploy-ha
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 2
workflow:
steps:
- name: deploy2default
type: deploy
properties:
policies: ["target-default"]
- name: manual-approval
type: suspend
- name: deploy2prod
type: deploy
properties:
policies: ["target-prod", "deploy-ha"]
```
Use the definition in command works the same, you can compose the application yaml manually and use `vela` command line tool to deploy.
```
vela up -f https://kubevela.net/example/applications/first-app.yaml
```
### Customize
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
A definition describes the module's inputs, outputs, operations, and the wiring between them. Here is an example of a simple component definition:
```
webserver: {
type: "component"
attributes: {}
}
template: {
parameter: {
name: string
image: string
}
output: {
apiVersion: "apps/v1"
kind: "Deployment"
spec: {
containers: [{
name: parameter.name
image: parameter.image
}]
}
}
}
```
The `type` defines what kind of definition it is, the `parameter` defines the inputs, while the `output` section defines the outputs.
You can refer to detail docs about [how to manage definition](../platform-engineers/cue/definition-edit) or learn the [definition protocol](../platform-engineers/oam/x-definition).
## Next Step
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.

26
versioned_docs/version-v1.3/getting-started/introduction.md
View File

@ -5,33 +5,31 @@ slug: /
## What is KubeVela?
KubeVela is a modern software delivery platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments.
Using KubeVela, software teams can build cloud native applications per needs as they grow, then deliver them anywhere.
KubeVela is a modern software delivery control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.
![](../resources/what-is-kubevela.png)
## Key Features
* **Unified Application Delivery Experience**
* **Deployment as Code**
KubeVela introduces a [unified and cross-platform delivery model(OAM)](https://oam.dev/) that allows you to deploy any workload type, including containers, databases, or even VM instances to any cloud or Kubernetes clusters. It helps you to just write application once, and deliver it the same everywhere, no more re-writing everything from scratch for any new delivery target.
Declare your deployment plan as workflow, run it automatically with any CI/CD or GitOps system, extend or re-program the workflow steps with CUE. No add-hoc scripts, no dirty glue code, just deploy. The deployment workflow in KubeVela is powered by [Open Application Model](https://oam.dev/).
* **Automated Deployment across Clusters**
* **Built-in security and compliance building blocks**
KubeVela natively supports rich continuous delivery strategies in various multi-cluster/hybrid-cloud scenarios or mixed environments. These strategies provides efficiency and safety to the distributed delivery process. The centralized management reduces the burden of looking over each clusters and gives unified experience across platforms. With KubeVela, you don't need to have any Ph.D. degree in Kubernetes to run automatic deployments.
Choose from the wide range of LDAP integrations we provided out-of-box, enjoy multi-cluster authorization that is fully automated, pick and apply fine-grained RBAC modules and customize them per your own supply chain requirements.
* **Declarative and Highly Extensible Workflow**
* **Multi-cloud/hybrid-environments app delivery as first-class citizen**
The application delivery process is driven by declarative workflow. Executed by reconciliation loops with limited privileges, the workflow is both robust and secure enough to prevent any unexpected configuration drifts. Users can also make arbitrary reusable customizations to the workflow through writing CUE definitions. The extensibility will always satisfy your growing business demands while keeping your production safe with continuous enforcement at the same time.
Progressive rollout across test/staging/production environments, automatic canary, blue-green and continuous verification, rich placement strategy across clusters and clouds, fully managed cloud environments provision.
## KubeVela vs. Other Software
### KubeVela vs. CI/CD (GitHub Actions, GitLab, CircleCI, Jenkins, etc.)
KubeVela is a continuous delivery platform that works at downstream of your CI process. So you will reuse the CI process you already adopted, and KubeVela will take over CD process by empowering it with modern application delivery best practices, such as hybrid/multi-cloud promotion workflow, unified cloud resource provision/binding, and much more. KubeVela is fully declarative by design, it natively supports GitOps if you want.
KubeVela is a continuous delivery platform that works at downstream of your CI process. So you will reuse the CI process you already adopted, and KubeVela will take over CD process by empowering it with modern application delivery best practices, such as declarative deployment plan as workflow, hybrid/multi-cloud resource provision/binding, security and compliance, and much more. It natively supports GitOps if you want.
> Feel free to check the [Integrating with Jenkins](./tutorials/jenkins) or [GitOps](./case-studies/gitops) documentation for more details.
@ -39,9 +37,8 @@ KubeVela is a continuous delivery platform that works at downstream of your CI p
KubeVela adopts your GitOps process and improves it by adding multi-cluster/hybrid-cloud capabilities:
* KubeVela has a user-friendly and programable workflow that allows you to integrate any of your delivery steps, including approval and notification flows.
* With the help of the workflow, KubeVela can provide cross-environment promotion for your multi-cluster/hybrid-cloud applications.
* KubeVela has a user-friendly workflow that allows you to extend, re-program or share any of your delivery process, including security and compliance flows.
* KubeVela regards multi-cloud/hybrid-environments app delivery as first-class citizen, it provides rich deployment strategies across clusters and clouds with fully managed cloud environments provision.
### KubeVela vs. PaaS (Heroku, Cloud Foundry, etc.)
@ -58,7 +55,7 @@ Using KubeVela is a good way to get many of the benefits of a PaaS (developer pr
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit.
KubeVela as a modern delivery system can naturally deploy Helm charts. For example, you could use KubeVela to define an application that is composed by a WordPress chart and a AWS RDS Terraform module, orchestrate the components' topology, and then deploy them to multiple environments following certain strategy.
KubeVela as a modern software delivery control plane can naturally deploy Helm charts. For example, you could use KubeVela to define an application that is composed by a WordPress chart and a AWS RDS Terraform module, orchestrate the components' topology, and then deploy them to multiple environments following certain strategy.
Of course, KubeVela also supports other encapsulation formats including Kustomize etc.
@ -74,3 +71,4 @@ Welcome onboard and sail Vela!
## What's Next
- Start to [install KubeVela](./install).
- Learn [Core Concepts](./getting-started/core-concept) to know more about how it works.

4
versioned_docs/version-v1.3/platform-engineers/cue/definition-edit.md
View File

@ -1,8 +1,8 @@
---
title: Manage X-Definition
title: Manage Definition
---
In KubeVela CLI (>= v1.1.0), `vela def` command group provides a series of convenient definition writing tools. With these commands, users only need to write CUE files to generate and edit definitions, instead of composing Kubernetes YAML object with mixed CUE string.
In KubeVela CLI, `vela def` command group provides a series of convenient definition writing tools. With these commands, users only need to write CUE files to generate and edit definitions, instead of composing Kubernetes YAML object with mixed CUE string.
## init

51
versioned_docs/version-v1.3/platform-engineers/oam/oam-model.md
View File

@ -2,53 +2,4 @@
title: Introduction
---
This and next documentation will explain Open Application Model (OAM) and how to extend this model in detail.
## An Abstraction to Model Application Deployment Process
OAM allows end users to work with a simple artifact to capture the complete application deployment workflow with easier primitives. This provides a simpler path for on-boarding end users to the platform without leaking low level details in runtime infrastructure and allows users to fully focus on the application delivery itself.
![alt](../../resources/model.png)
Every application deployment plan can be composed by multiple components with attachable operational behaviors (traits), the deployment policy and workflow. For example:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: <name>
spec:
components:
- name: <component name>
type: <component type>
properties:
<parameter values>
traits:
- type: <trait type>
properties:
<traits parameter values>
- name: <component name>
type: <component type>
properties:
<parameter values>
policies:
- name: <policy name>
type: <policy type>
properties:
<policy parameter values>
workflow:
- name: <step name>
type: <step type>
properties:
<step parameter values>
```
This `Application` entity will reference component, trait, policy and workflow step types which are essentially programmable modules that are maintained by platform team. Hence, this abstraction is highly extensible and can be customized in-place at ease.
Please check the next section ([X-Definition](./x-definition.md)) to learn how this programmable capability is achieved.
## No Configuration Drift
Despite the efficiency and extensibility in abstracting application deployment, programmable (Infrastructure-as-Code) approach may lead to an issue called *Infrastructure/Configuration Drift*, i.e. the rendered component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes. This makes them can be barely used as a platform level building block.
Hence, KubeVela is designed to maintain all these programmable capabilities with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, while still keeps the flexibly and velocity enabled by IaC.
This doc has been migrated, please refer to [Application Concept](../../getting-started/core-concept).

44
versioned_docs/version-v1.3/platform-engineers/oam/x-definition.md
View File

@ -1,10 +1,11 @@
---
title: X-Definition
title: Definition Protocol
---
KubeVela is fully programmable via [CUE](https://cuelang.org).
KubeVela is fully programmable via [CUE](https://cuelang.org), while it leverage Kubernetes as control plane and align with the API in yaml.
You can [manage the definition](../cue/definition-edit) in CUE and the `vela def` command will render it into Kubernetes API with the following protocol.
This is achieved by implementing its [application model][1] as programmable entities (named `X-Definition`) include `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition` etc as shown below.
## ComponentDefinition
@ -329,29 +330,6 @@ spec:
```
## WorkloadDefinition
WorkloadDefinition is a system-level feature. It's not a field that users should care about but as metadata checked, verified, and used by the OAM system itself.
The format is as follows:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: WorkloadDefinition
metadata:
name: <WorkloadDefinition name>
spec:
definitionRef:
name: <corresponding Kubernetes resource group>
version: <corresponding Kubernetes resource version>
podSpecPath: <path to the Pod field in the Workload>
childResourceKinds:
- apiVersion: <resource group>
kind: <resource type>
```
In addition, other Kubernetes resource type that need to be introduced into OAM model in the future will also be added as fields to the workload definition.
## The Standard Protocol Behind Abstraction
Once the application is created, KubeVela will tag the created resources with a series of tags, which include the version, name, type, etc. of the application. Through these standard protocols, application components, traits and policies can be coordinated. The specific metadata list is as follows:
@ -365,9 +343,9 @@ Once the application is created, KubeVela will tag the created resources with a
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
| `app.oam.dev/appRevision` | Application Revision Name |
## X-Definition Runtime Context
## Definition Runtime Context
In the X-Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
In the Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
| Context Variable | Description | Scope |
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
@ -391,12 +369,4 @@ At the same time, in the Workflow system, because the `context` has to act on th
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
Please note that all the X-Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
[1]: ./oam-model
[2]: ../cue/basic
[3]: ../kube/component
[4]: ../traits/customize-trait
[5]: ../traits/advanced.md
[6]: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
[7]: ../cue/basic.md
Please note that all the Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.

2
versioned_docs/version-v1.3/quick-start.md
View File

@ -209,5 +209,5 @@ That's it! You succeed at the first application delivery. Congratulation!
## Next Step
- View [Core Concepts](./getting-started/core-concept) to look on more concepts.
- View [Core Concepts](./getting-started/core-concept) to learn more about how it works.
- View [User Guide](./tutorials/webservice) to look on more of what you can achieve with KubeVela.

4
versioned_docs/version-v1.3/reference/addons/overview.md
View File

@ -1,7 +1,9 @@
---
title: Built-in Addons
title: Overview
---
There's an official addon registry (https://addons.kubevela.net) maintained by KubeVela team. It contains following addons:
* [VelaUX](./velaux): The KubeVela User Experience (UX ) addon. It will launch a dashboard and an APIServer for better user experience.
* [Addon Cloud Resources](./terraform): Provide a bunch of addons to provision cloud resources for different cloud providers.
* [Machine Learning Addon](./ai): Machine learning addon is divided into model-training addon and model-serving addon.

BIN
versioned_docs/version-v1.3/resources/definition-ui.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 242 KiB

BIN
versioned_docs/version-v1.3/resources/usage-of-def.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 274 KiB

61
versioned_sidebars/version-v1.3-sidebars.json
View File

@ -20,7 +20,7 @@
]
},
{
"collapsed": true,
"collapsed": false,
"type": "category",
"label": "Core Concepts",
"items": [
@ -28,6 +28,10 @@
"type": "doc",
"id": "version-v1.3/getting-started/core-concept"
},
{
"type": "doc",
"id": "version-v1.3/getting-started/definition"
},
{
"type": "doc",
"id": "version-v1.3/getting-started/architecture"
@ -322,21 +326,6 @@
"type": "category",
"label": "Extension",
"items": [
{
"collapsed": false,
"type": "category",
"label": "Learning OAM",
"items": [
{
"type": "doc",
"id": "version-v1.3/platform-engineers/oam/oam-model"
},
{
"type": "doc",
"id": "version-v1.3/platform-engineers/oam/x-definition"
}
]
},
{
"collapsed": true,
"type": "category",
@ -461,10 +450,30 @@
"type": "doc",
"id": "version-v1.3/cli/vela"
},
{
"type": "doc",
"id": "version-v1.3/platform-engineers/oam/x-definition"
},
{
"type": "doc",
"id": "version-v1.3/end-user/components/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/traits/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/policies/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/workflow/built-in-workflow-defs"
},
{
"collapsed": true,
"type": "category",
"label": "Built-in Addons",
"label": "Official Addons",
"items": [
{
"type": "doc",
@ -492,22 +501,6 @@
"type": "doc",
"id": "version-v1.3/end-user/components/cloud-services/cloud-resources-list"
},
{
"type": "doc",
"id": "version-v1.3/end-user/components/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/traits/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/policies/references"
},
{
"type": "doc",
"id": "version-v1.3/end-user/workflow/built-in-workflow-defs"
},
{
"type": "doc",
"id": "version-v1.3/reference/ui-schema"
@ -539,4 +532,4 @@
"id": "version-v1.3/developers/references/devex/faq"
}
]
}
}