Feat: upgrade the 1.3 version (#624)
Signed-off-by: barnettZQG <barnett.zqg@gmail.com>
This commit is contained in:
barnettZQG
GitHub
parent
b39a341fbc
commit
4249f6a5a6
|
|
@ -2,13 +2,13 @@
|
|||
title: Get More Traits
|
||||
---
|
||||
|
||||
## 1. Refer to [All Trait References](./references) for all other trait types.
|
||||
* Refer to [All Trait References](./references) for all other trait types.
|
||||
|
||||
## 2. Get more from [install addons](../../how-to/cli/addon/addon)
|
||||
* Get more from [install addons](../../how-to/cli/addon/addon)
|
||||
|
||||
## 3. Extend KubeVela by yourself
|
||||
* Extend KubeVela by yourself
|
||||
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
|
|
@ -40,4 +40,4 @@ For learning how to program KubeVela in detail, please check the `Administrator
|
|||
|
||||
## Next Step
|
||||
|
||||
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
|
||||
- View [User Guide](../tutorials/webservice) to look on more of what you can achieve with KubeVela.
|
||||
|
|
|
|||
|
|
@ -37,4 +37,3 @@ Addon is where you can freely pull in third-party capability that fulfills your
|
|||
## Next Step
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
|
||||
|
|
|
|||
|
|
@ -24,14 +24,12 @@ This is why KubeVela appears here. It can simplify the application delivery and
|
|||
|
||||
|
||||
|
||||
We mainly provide two products for different users, they're [KubeVela](./end-user/quick-start-cli) and [VelaUX](./quick-start).
|
||||
|
||||
- Platform builders for PaaS, Serverless, Application Management/Delivery systems
|
||||
- [KubeVela](./end-user/quick-start-cli) works as an application delivery engine that you could build your advanced platform with.
|
||||
- KubeVela works as an application delivery engine that you could build your advanced platform with.
|
||||
- ISV, SaaS owners, and Application Architects who need to distribute software to anywhere
|
||||
- KubeVela has full extension and integration capabilities to allow users to distribute applications with [customized addons](./platform-engineers/addon/intro) easily. Think about an App Store but on Kubernetes and clouds.
|
||||
- Application Developers, Operators, DevOps Engineers
|
||||
- [VelaUX](./quick-start) is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
|
||||
- VelaUX is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
|
||||
|
||||
|
||||
## What's the relationship between OAM, KubeVela and VelaUX?
|
||||
|
|
@ -50,7 +48,7 @@ KubeVela is a CD (Continuous Delivery) control plane that works at downstream of
|
|||
|
||||
If you already adopted GitOps practice in CD section, KubeVela is even easier to fit in as it's fully declarative by design. All KubeVela features including CD workflow and multi-cloud/cluster delivery will be immediately available in your GitOps process by simply putting a KubeVela application YAML inside your configuration repository.
|
||||
|
||||
> Feel free to check the [Best Practices](https://kubevela.io/docs/case-studies/jenkins-cicd) documentation for more details.
|
||||
> Feel free to check the [Best Practices](../tutorials/jenkins) documentation for more details.
|
||||
|
||||
### KubeVela vs. Platform-as-a-Service (PaaS)
|
||||
|
||||
|
|
@ -92,5 +90,3 @@ Welcome onboard and sail Vela!
|
|||
## What's Next
|
||||
|
||||
- Start to [install KubeVela](./install).
|
||||
- Getting started with [KubeVela core application engine](./end-user/quick-start-cli).
|
||||
- Getting started with UI console by using [VelaUX](./quick-start).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Addon management
|
||||
slug: how-to/cli/addon/addon
|
||||
slug: cli/addon/addon
|
||||
---
|
||||
|
||||
You can get more capabilities from KubeVela ecosystem by installing addons.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ title: View Application Logs
|
|||
description: View an application log by KubeVela dashboard
|
||||
---
|
||||
|
||||
## View logs via UI
|
||||
|
||||
|
||||
|
||||
|
|
@ -10,6 +11,14 @@ You can view the logs of application in the environment tab.
|
|||
|
||||
By default, the logs will refresh every 5s. If your logs didn't have timestamp, you can click the `Show timestamps` to see.
|
||||
|
||||
## View logs via CLI
|
||||
|
||||
```bash
|
||||
vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
Select a workload could view the logs.
|
||||
|
||||
### Next Step
|
||||
|
||||
* [Expose Application for Public Access](./get-application-endpoint)
|
||||
|
|
@ -2,12 +2,18 @@
|
|||
title: View Resources List Created
|
||||
---
|
||||
|
||||
If you want to learn the resources created by the applications, you can click `Check the details` text button, it will provide a window to show the resources.
|
||||
If you want to learn the resources created by the applications, you can open the environment status page.
|
||||
|
||||
|
||||
|
||||
|
||||
There're three kinds of information including `Applied Resources`,`Conditions` and `Component Status`. The `Applied Resources` are all resources created by the applications.
|
||||
|
||||
## View resources via CLI
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
### Next Step
|
||||
|
||||
* [List Application Revision](./get-application-revision)
|
||||
|
|
@ -4,6 +4,8 @@ title: Manage Targets
|
|||
|
||||
To deploy application components into different places, VelaUX provides **Target** for user to manage their deploy destinations like clusters or namespaces.
|
||||
|
||||
> This document only apply to UI.
|
||||
|
||||
## Cluster
|
||||
|
||||
First, before configuring Target, you need to ensure your clusters have been joined. You can check your clusters in the Cluster page. The **local** cluster represents the cluster that KubeVela control plane is running on. If you have other clusters, you can either connect those clusters directly to KubeVela by providing their KubeConfig, or join clusters from your cloud provider such as Alibaba Cloud.
|
||||
|
|
|
|||
|
|
@ -352,5 +352,4 @@ kubectl get crd |grep oam | awk '{print $1}' | xargs kubectl delete crd
|
|||
|
||||
## Next Step
|
||||
|
||||
- Getting started with [KubeVela core application engine](./end-user/quick-start-cli).
|
||||
- Getting started with UI console by using [VelaUX](./quick-start).
|
||||
- [Deploy your first application](./quick-start).
|
||||
|
|
|
|||
|
|
@ -146,24 +146,24 @@ spec:
|
|||
- name: topology-default
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
clusters: ['local']
|
||||
namespace: default
|
||||
- name: topology-production
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
clusters: ['local']
|
||||
namespace: production
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2default
|
||||
properties:
|
||||
policies: ["topology-default"]
|
||||
policies: ['topology-default']
|
||||
type: deploy
|
||||
- name: suspend
|
||||
type: suspend
|
||||
- name: deploy2production
|
||||
properties:
|
||||
policies: ["topology-production"]
|
||||
policies: ['topology-production']
|
||||
type: deploy
|
||||
```
|
||||
|
||||
|
|
@ -194,4 +194,5 @@ Congrats! Now you've learned how to deploy Kubernetes objects.
|
|||
|
||||
## Next step
|
||||
|
||||
- [Deploy Helm Chart](./helm)
|
||||
- [Deploy Cloud Service](./consume-cloud-services)
|
||||
- [Distributed External Kubernetes Objects](../end-user/components/ref-objects)
|
||||
|
|
|
|||
|
|
@ -1,108 +1,104 @@
|
|||
/** @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',
|
||||
},
|
||||
{
|
||||
href: "https://kubevela.net",
|
||||
label: "Mirror",
|
||||
position: "right",
|
||||
href: 'https://kubevela.net',
|
||||
label: 'Mirror',
|
||||
position: 'right',
|
||||
},
|
||||
{
|
||||
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/end-user/quick-start-cli",
|
||||
label: 'Getting Started',
|
||||
to: '/docs/quick-start',
|
||||
},
|
||||
{
|
||||
label: "Tutorials",
|
||||
to: "/docs/tutorials/webservice",
|
||||
label: 'Tutorials',
|
||||
to: '/docs/tutorials/webservice',
|
||||
},
|
||||
{
|
||||
label: "Extension",
|
||||
to: "/docs/platform-engineers/oam/oam-model",
|
||||
label: 'Extension',
|
||||
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: "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>',
|
||||
|
|
@ -110,15 +106,15 @@ module.exports = {
|
|||
],
|
||||
},
|
||||
{
|
||||
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',
|
||||
},
|
||||
],
|
||||
},
|
||||
|
|
@ -132,19 +128,19 @@ 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"),
|
||||
sidebarPath: require.resolve('./sidebars.js'),
|
||||
editUrl: function ({ locale, docPath }) {
|
||||
return `https://github.com/oam-dev/kubevela.io/edit/main/docs/${docPath}`;
|
||||
},
|
||||
|
|
@ -154,10 +150,10 @@ module.exports = {
|
|||
},
|
||||
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'),
|
||||
},
|
||||
},
|
||||
],
|
||||
|
|
|
|||
|
|
@ -39,4 +39,4 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
|
||||
## 下一步
|
||||
|
||||
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
|
||||
- 查看 [快速开始](../quick-start)，了解更多使用场景和最佳实践。
|
||||
|
|
|
|||
|
|
@ -37,5 +37,4 @@ Kubernetes 集群描述，它包括了集群通信密钥等信息，Kubernetes
|
|||
|
||||
## 下一步
|
||||
|
||||
- 查看 [架构文档](./architecture)，了解 KubeVela 的整体架构。
|
||||
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
|
||||
- 查看 [架构文档](./architecture)，了解 KubeVela 的整体架构。
|
||||
|
|
@ -29,12 +29,11 @@ KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变
|
|||
|
||||
|
||||
- 云原生应用平台的构建者、PaaS、Serverless 平台工程师、基础设施平台管理员：
|
||||
- [Vela Core](./end-user/quick-start-cli) 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
- KubeVela 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
- 第三方软件供应商（ISV）、垂直领域软件开发者、架构师：
|
||||
- Vela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](./platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
|
||||
- KubeVela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](./platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
|
||||
- 云原生时代的应用研发、运维人员、DevOps 工程师：
|
||||
- [VelaUX](./quick-start) 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
- VelaUX 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
## OAM、KubeVela 和 VelaUX 是什么关系？
|
||||
|
||||
|
|
@ -53,7 +52,7 @@ KubeVela 是一个工作在 CI 流程下游的 CD 控制平面（Continuous Deli
|
|||
|
||||
如果你已经在 CD 环节中采纳了 GitOps 实践，KubeVela 会更容易跟你的 CI/CD 系统集成，因为 KubeVela 是完全声明式的。只需要把 KubeVela 的应用部署描述文件放置在你的配置仓库当中，所有的 KubeVela 特性（包括声明式交付工作流、多云/多集群交付流程等）就会立刻在你 的 GitOps 流程中出现。
|
||||
|
||||
> 欢迎查阅 [最佳实践](case-studies/jenkins-cicd) 文档来了解更多关于 KubeVela 与各类 CI/CD 系统协作的实践.
|
||||
> 欢迎查阅 [最佳实践](../tutorials/jenkins) 文档来了解更多关于 KubeVela 与各类 CI/CD 系统协作的实践.
|
||||
|
||||
### KubeVela vs. 平台即服务 (PaaS)
|
||||
|
||||
|
|
@ -94,5 +93,3 @@ KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。
|
|||
接下来，我们推荐你：
|
||||
|
||||
- 开始 [安装使用 KubeVela](./install)。
|
||||
- 查看 [KubeVela 核心应用引擎](./end-user/quick-start-cli)的使用场景和功能。
|
||||
- 查看开箱即用的 [应用托管平台 VelaUX](./quick-start) 的使用场景和功能。
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: 插件管理
|
||||
slug: cli/addon/addon
|
||||
---
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的系统功能。
|
||||
|
|
|
|||
|
|
@ -3,12 +3,22 @@ title: 查看应用运行日志
|
|||
description: 通过查看应用的运行日志是排查故障的最直接方式。
|
||||
---
|
||||
|
||||
## 通过 UI 查看应用日志
|
||||
|
||||
|
||||
|
||||
如上图所示，交付到 Kubernetes 集群的应用支持查询容器运行日志，切换到指定环境视图下，选择日志页面，即可通过组件/实例/容器的筛选查看对应的运行日志。
|
||||
|
||||
日志查询页面默认为每 5 秒自动刷新，查看最新的日志。若你的应用日志中没有时间信息，可点击 `Show timestamps` 展示日志记录时间。
|
||||
|
||||
## 通过 CLI 查看应用日志
|
||||
|
||||
```bash
|
||||
$ vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
使用实际的应用名称，命名空间参数执行上述命令，在交互中选择你需要查询的工作负载即可查询应用日志。
|
||||
|
||||
### 下一步
|
||||
|
||||
* [暴露访问地址](./get-application-endpoint)
|
||||
|
|
@ -4,13 +4,21 @@ title: 查看应用部署的资源列表
|
|||
|
||||
如果你希望查询应用在各集群部署了哪些资源，可通过下述操作方式查询。
|
||||
|
||||
进入应用实例列表页面，点击应用状态展示区域的 `Check the details` 文字按钮，即可弹出如下页面：
|
||||
## 通过 UI 查询
|
||||
|
||||
|
||||
进入应用部署环境视图，默认进入状态展示页面，在该页面中即可查询到应用实际分发的资源列表，如果应用在更新过程中，资源列表会包括历史和当前版本。
|
||||
|
||||
弹窗中展示了应用的 `Applied Resources` `Conditions` 和 `Component Status` 三方面信息，其中 `Applied Resources` 即是应用部署的资源列表。
|
||||
|
||||
|
||||
在列表中呈现了包括资源类型、名称、所在集群和 Namespace 等信息。
|
||||
在该页面中同时展示了组件状态和整体的交付状态。
|
||||
|
||||
## 通过 CLI 查询
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
基于如上命令可以查询应用部署的资源清单。
|
||||
|
||||
### 下一步
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: 管理部署目标
|
||||
---
|
||||
|
||||
为了将应用组件部署在不同的地方，VelaUX 提供了 **部署目标（Target）** 方便用户管理要部署的具体位置，比如集群或者命名空间。
|
||||
为了将应用组件部署在不同的地方，控制台中提供了 **部署目标（Target）** 方便用户管理要部署的具体位置，比如集群或者命名空间。
|
||||
|
||||
> 此文档仅适用于 UI
|
||||
|
||||
## 集群
|
||||
|
||||
|
|
@ -10,7 +12,6 @@ title: 管理部署目标
|
|||
|
||||
|
||||
|
||||
|
||||
在向 KubeVela 添加完集群之后，你可以编辑它的基本描述信息，或者在没有应用使用它的时候将它从 KubeVela 管控平台上移除。
|
||||
|
||||
## 创建部署目标
|
||||
|
|
|
|||
|
|
@ -148,24 +148,24 @@ spec:
|
|||
- name: topology-default
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
clusters: ['local']
|
||||
namespace: default
|
||||
- name: topology-production
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
clusters: ['local']
|
||||
namespace: production
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2default
|
||||
properties:
|
||||
policies: ["topology-default"]
|
||||
policies: ['topology-default']
|
||||
type: deploy
|
||||
- name: suspend
|
||||
type: suspend
|
||||
- name: deploy2production
|
||||
properties:
|
||||
policies: ["topology-production"]
|
||||
policies: ['topology-production']
|
||||
type: deploy
|
||||
```
|
||||
|
||||
|
|
@ -196,4 +196,5 @@ $ vela workflow resume app-with-k8s-objects
|
|||
|
||||
## 下一步
|
||||
|
||||
- [学习交付云厂商服务](./consume-cloud-services)
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
- [分发已存在的 Kubernetes 对象](../end-user/components/ref-objects)
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ title: GitOps 交付
|
|||
|
||||
本案例将介绍如何在 GitOps 场景下使用 KubeVela，并介绍这样做的好处是什么。
|
||||
|
||||
> 该教程仅适用于 CLI 用户。
|
||||
|
||||
## 简介
|
||||
|
||||
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Jenkins CI 集成
|
||||
draft: true
|
||||
---
|
||||
|
||||
本文将介绍如何使用 KubeVela 同已有的 CI 工具（比如 Jenkins）共同协作来进行应用的持续交付，并解释这样集成的好处是什么。
|
||||
|
|
|
|||
|
|
@ -1,99 +0,0 @@
|
|||
---
|
||||
title: 部署 Kubernetes 资源模板
|
||||
---
|
||||
|
||||
KubeVela 可以以资源模板的方式直接部署任何 Kubernetes 对象。
|
||||
|
||||
## 如何使用
|
||||
|
||||
比如一个 Job。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-raw
|
||||
spec:
|
||||
components:
|
||||
- name: myjob
|
||||
type: k8s-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: pi
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
backoffLimit: 4
|
||||
```
|
||||
|
||||
也支持多个资源，但是要把你的主要工作负载放在第一个，KubeVela 的 traits 只会对第一个位置的 Kubernetes 对象生效。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-stateful-service
|
||||
spec:
|
||||
components:
|
||||
- name: my-sts
|
||||
type: k8s-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: web
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx # has to match .spec.template.metadata.labels
|
||||
serviceName: "nginx"
|
||||
replicas: 3 # by default is 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx # has to match .spec.selector.matchLabels
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- name: www
|
||||
mountPath: /usr/share/nginx/html
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "my-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
name: web
|
||||
clusterIP: None
|
||||
selector:
|
||||
app: nginx
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -1,9 +1,10 @@
|
|||
---
|
||||
title: 一次性任务
|
||||
title: 部署一次性或周期性任务
|
||||
---
|
||||
|
||||
* 一次性任务（Task）描述运行代码或脚本以完成的作业。
|
||||
> 此类型适用于 UI 和 CLI
|
||||
|
||||
### 一次性任务（Task）描述运行代码或脚本以完成的作业
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -20,8 +21,7 @@ spec:
|
|||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
```
|
||||
|
||||
|
||||
* 描述一个定时任务
|
||||
### 描述一个定时任务
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
|
|||
|
|
@ -1,92 +0,0 @@
|
|||
---
|
||||
title: 部署 Helm 组件
|
||||
---
|
||||
|
||||
KubeVela 的 `helm` 组件满足了用户对接 Helm Chart 的需求，你可以通过 `helm` 组件部署任意来自 Helm 仓库、Git 仓库或者 OSS bucket 的现成 Helm Chart 软件包，并对其进行参数覆盖。
|
||||
|
||||
## 部署来自 Helm 仓库的 Chart
|
||||
|
||||
来自 Helm 仓库的 Chart 包部署方式，我们以一个 redis-comp 组件为例。它是来自 [bitnami](https://charts.bitnami.com/) Helm 仓库的 Chart。Chart 类型为 `redis-cluster`，版本 `6.2.7`。
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
EOF
|
||||
```
|
||||
|
||||
请复制上面的代码块，直接部署到运行时集群：
|
||||
```shell
|
||||
application.core.oam.dev/app-delivering-chart created
|
||||
```
|
||||
|
||||
最后我们使用 `vela ls` 来查看交付成功后的应用状态：
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
app-delivering-chart redis-comp helm running healthy 2021-08-28 18:48:21 +0800 CST
|
||||
```
|
||||
|
||||
我们也看到 app-delivering-chart APP 的 PHASE 为 running，同时 STATUS 为 healthy。
|
||||
|
||||
## 部署来自 OSS bucket 的 Chart
|
||||
|
||||
1. （可选）如果你的 OSS bucket 需要身份验证, 创建 Secret 对象:
|
||||
|
||||
```shell
|
||||
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
|
||||
secret/bucket-secret created
|
||||
```
|
||||
|
||||
2. 部署 chart
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: bucket-app
|
||||
spec:
|
||||
components:
|
||||
- name: bucket-comp
|
||||
type: helm
|
||||
properties:
|
||||
repoType: oss
|
||||
# required if bucket is private
|
||||
secretRef: bucket-secret
|
||||
chart: ./chart/podinfo-5.1.3.tgz
|
||||
url: oss-cn-beijing.aliyuncs.com
|
||||
oss:
|
||||
bucketName: definition-registry
|
||||
```
|
||||
|
||||
上面的示例中，Application 中名为 bucket-comp 的组件交付了一个来自 endpoint 为 oss-cn-beijing.aliyuncs.com 的 OSS bucket definition-registry 的 chart。Chart 路径为 ./chart/podinfo-5.1.3.tgz。
|
||||
|
||||
## 部署来自 Git 仓库的 Chart
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: terraform-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/oam-dev/terraform-controller
|
||||
chart: ./chart
|
||||
git:
|
||||
branch: master
|
||||
```
|
||||
|
||||
上面的示例中，Application 中名为 terraform-controller 的组件交付了一个来自 https://github.com/oam-dev/terraform-controller 的 Github 仓库的 chart。Chart 路径为 ./chart，仓库分支为 master。
|
||||
|
|
@ -6,6 +6,8 @@ KubeVela 的 [`kustomize` 组件](https://github.com/kubernetes-sigs/kustomize)
|
|||
|
||||
除了监听文件外，该组件还能监听镜像仓库中的镜像变动并交付。
|
||||
|
||||
> 该类型仅适用于 CLI
|
||||
|
||||
## 监听文件/文件夹
|
||||
|
||||
### 监听 OSS bucket 中的文件
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
title: 获得更多组件类型？
|
||||
---
|
||||
|
||||
## 1. 查看 [所有组件参考列表](./references)。
|
||||
* 查看 [所有组件参考列表](./references)。
|
||||
|
||||
## 2. 从[插件安装](../../how-to/cli/addon/addon)中获得。
|
||||
* 从[插件安装](../../how-to/cli/addon/addon)中获得。
|
||||
|
||||
## 3. 自己动手扩展
|
||||
* 自己动手扩展
|
||||
|
||||
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
|
||||
* [构建自己的能力](../../platform-engineers/cue/advanced)
|
||||
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
|
||||
* [构建自己的插件](../../platform-engineers/addon/intro)。
|
||||
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
|
||||
* [构建自己的能力](../../platform-engineers/cue/advanced)
|
||||
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
|
||||
* [构建自己的插件](../../platform-engineers/addon/intro)。
|
||||
|
|
|
|||
|
|
@ -39,5 +39,4 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
|
||||
## 下一步
|
||||
|
||||
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
|
||||
- 查看 [操作手册](../end-user/components/helm)，一步步了解更多的功能。
|
||||
- 查看 [快速开始](../quick-start)，了解更多使用场景和最佳实践。
|
||||
|
|
|
|||
|
|
@ -37,6 +37,4 @@ Kubernetes 集群描述，它包括了集群通信密钥等信息，Kubernetes
|
|||
|
||||
## 下一步
|
||||
|
||||
- 查看 [架构文档](./architecture)，了解 KubeVela 的整体架构。
|
||||
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
|
||||
- 查看 [操作手册](../end-user/components/helm) 以便了解更多功能。
|
||||
- 查看 [架构文档](./architecture)，了解 KubeVela 的整体架构。
|
||||
|
|
@ -29,12 +29,11 @@ KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变
|
|||
|
||||
|
||||
- 云原生应用平台的构建者、PaaS、Serverless 平台工程师、基础设施平台管理员：
|
||||
- [Vela Core](./end-user/quick-start-cli) 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
- KubeVela 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
- 第三方软件供应商（ISV）、垂直领域软件开发者、架构师：
|
||||
- Vela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](./platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
|
||||
- KubeVela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](./platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
|
||||
- 云原生时代的应用研发、运维人员、DevOps 工程师：
|
||||
- [VelaUX](./quick-start) 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
- VelaUX 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
## OAM、KubeVela 和 VelaUX 是什么关系？
|
||||
|
||||
|
|
@ -53,7 +52,7 @@ KubeVela 是一个工作在 CI 流程下游的 CD 控制平面（Continuous Deli
|
|||
|
||||
如果你已经在 CD 环节中采纳了 GitOps 实践，KubeVela 会更容易跟你的 CI/CD 系统集成，因为 KubeVela 是完全声明式的。只需要把 KubeVela 的应用部署描述文件放置在你的配置仓库当中，所有的 KubeVela 特性（包括声明式交付工作流、多云/多集群交付流程等）就会立刻在你 的 GitOps 流程中出现。
|
||||
|
||||
> 欢迎查阅 [最佳实践](case-studies/jenkins-cicd) 文档来了解更多关于 KubeVela 与各类 CI/CD 系统协作的实践.
|
||||
> 欢迎查阅 [最佳实践](../tutorials/jenkins) 文档来了解更多关于 KubeVela 与各类 CI/CD 系统协作的实践.
|
||||
|
||||
### KubeVela vs. 平台即服务 (PaaS)
|
||||
|
||||
|
|
@ -94,5 +93,3 @@ KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。
|
|||
接下来，我们推荐你：
|
||||
|
||||
- 开始 [安装使用 KubeVela](./install)。
|
||||
- 查看 [KubeVela 核心应用引擎](./end-user/quick-start-cli)的使用场景和功能。
|
||||
- 查看开箱即用的 [应用托管平台 VelaUX](./quick-start) 的使用场景和功能。
|
||||
|
|
|
|||
|
|
@ -1,10 +1,25 @@
|
|||
---
|
||||
title: 安装插件
|
||||
title: 插件管理
|
||||
slug: cli/addon/addon
|
||||
---
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的系统功能。
|
||||
|
||||
## 查看所有插件
|
||||
## 通过 UI 管理插件
|
||||
|
||||
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
|
||||
|
||||
|
||||
|
||||
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
|
||||
|
||||
## 通过 CLI 管理插件
|
||||
|
||||
### 查看所有插件
|
||||
|
||||
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
|
||||
|
||||
|
|
@ -30,7 +45,7 @@ velaux KubeVela KubeVela User Experience (UX). A
|
|||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
## 安装插件
|
||||
### 安装插件
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
|
|
@ -44,7 +59,7 @@ I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-ui
|
|||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
### 安装特定版本的插件
|
||||
#### 安装特定版本的插件
|
||||
|
||||
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
|
||||
|
||||
|
|
@ -63,7 +78,7 @@ vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
|||
|
||||
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../../reference/addons/overview)中查看每个官方插件对应的能力.
|
||||
|
||||
## 删除/卸载已安装的插件
|
||||
### 删除/卸载已安装的插件
|
||||
|
||||
> 删除前请确认插件对应的能力没有被任何应用使用。
|
||||
|
||||
|
|
@ -72,7 +87,7 @@ $ vela addon disable fluxcd
|
|||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
## 查看插件的下载仓库
|
||||
### 查看插件的下载仓库
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
|
|
@ -84,7 +99,7 @@ KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](htt
|
|||
|
||||
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
|
||||
|
||||
## 添加插件包仓库
|
||||
### 添加插件包仓库
|
||||
|
||||
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
|
||||
|
||||
|
|
@ -93,14 +108,14 @@ $ vela addon registry add experimental --type OSS --endpoint=https://addons.kube
|
|||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
## 删除一个插件包仓库
|
||||
### 删除一个插件包仓库
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
## 多集群环境中启用插件包
|
||||
### 多集群环境中启用插件包
|
||||
|
||||
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
|
||||
|
||||
|
|
@ -110,7 +125,7 @@ Addon:
|
|||
enabled Successfully
|
||||
```
|
||||
|
||||
## 离线安装插件包
|
||||
### 离线安装插件包
|
||||
|
||||
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：
|
||||
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
title: 管理插件
|
||||
---
|
||||
你可以在 VelaUX 的 Addon 页面管理平台插件，以获取更多的系统功能。
|
||||
|
||||
|
||||
|
||||
## 启用/停用插件 (Enable/Disable Addon)
|
||||
|
||||
如下图所示，在某个插件页面点击 `Enable` 启用一个插件
|
||||
|
||||
|
||||
|
||||
如果某个插件需要依赖其他插件，只有当被依赖的的插件被启用之后，该插件才能被启用，如下图所示。
|
||||
|
||||
|
||||
|
||||
有些复杂的插件需要设置一些参数才能启用，如下图所示。
|
||||
|
||||
|
||||
|
||||
通过点击插件页面的 `Disable` 停用一个插件
|
||||
|
||||
> 停用前请确认插件对应的能力没有被任何应用所使用。
|
||||
|
||||
你也可以通过点击页面的 `Upgrade` 来更新插件。
|
||||
|
||||
## 多集群环境中启用插件
|
||||
|
||||
如果插件的部署目标设置为子集群部署，在启用插件时首先需要选择你希望启用的集群。如果插件启用完成后又新增了集群，你需要增加选择新的集群然后更新插件即可。
|
||||
|
||||
## 插件仓库 (Addon Registry)
|
||||
|
||||
插件仓库是一个存储、发现和下载插件的地方。 插件仓库的地址可以是一个 Git 仓库或者一个对象存储 Bucket。
|
||||
|
||||
KubeVela 社区在 Github 上维护了一个官方的[正式插件仓库](https://github.com/oam-dev/catalog/tree/master/addons) 和一个[试验阶段插件仓库](https://github.com/oam-dev/catalog/tree/master/experimental) 。
|
||||
|
||||
你也可以参考这两个仓库，自己定制一个插件仓库， 下图展示如何通过 VelaUX 来管理插件仓库，你可以在这里添加、更新或删除一个插件仓库。
|
||||
|
||||
|
||||
|
||||
需要注意的是，KubeVela 默认没有添加试验性的插件仓库，但你可以通过点击 `Add Experimental Registry` 一键将它添加进来，并使用其中的插件。
|
||||
|
||||
|
|
@ -3,12 +3,22 @@ title: 查看应用运行日志
|
|||
description: 通过查看应用的运行日志是排查故障的最直接方式。
|
||||
---
|
||||
|
||||
## 通过 UI 查看应用日志
|
||||
|
||||
|
||||
|
||||
如上图所示，交付到 Kubernetes 集群的应用支持查询容器运行日志，切换到指定环境视图下，选择日志页面，即可通过组件/实例/容器的筛选查看对应的运行日志。
|
||||
|
||||
日志查询页面默认为每 5 秒自动刷新，查看最新的日志。若你的应用日志中没有时间信息，可点击 `Show timestamps` 展示日志记录时间。
|
||||
|
||||
## 通过 CLI 查看应用日志
|
||||
|
||||
```bash
|
||||
$ vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
使用实际的应用名称，命名空间参数执行上述命令，在交互中选择你需要查询的工作负载即可查询应用日志。
|
||||
|
||||
### 下一步
|
||||
|
||||
* [暴露访问地址](./get-application-endpoint)
|
||||
|
|
@ -11,4 +11,5 @@ description: 查看应用当前部署版本和历史部署版本。
|
|||
|
||||
### 下一步
|
||||
|
||||
* [通过 CLI 进行版本管理](../../../end-user/version-control)
|
||||
* [回收应用实例](./recycle-environment)
|
||||
|
|
@ -4,13 +4,21 @@ title: 查看应用部署的资源列表
|
|||
|
||||
如果你希望查询应用在各集群部署了哪些资源，可通过下述操作方式查询。
|
||||
|
||||
进入应用实例列表页面，点击应用状态展示区域的 `Check the details` 文字按钮，即可弹出如下页面：
|
||||
## 通过 UI 查询
|
||||
|
||||
|
||||
进入应用部署环境视图，默认进入状态展示页面，在该页面中即可查询到应用实际分发的资源列表，如果应用在更新过程中，资源列表会包括历史和当前版本。
|
||||
|
||||
弹窗中展示了应用的 `Applied Resources` `Conditions` 和 `Component Status` 三方面信息，其中 `Applied Resources` 即是应用部署的资源列表。
|
||||
|
||||
|
||||
在列表中呈现了包括资源类型、名称、所在集群和 Namespace 等信息。
|
||||
在该页面中同时展示了组件状态和整体的交付状态。
|
||||
|
||||
## 通过 CLI 查询
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
基于如上命令可以查询应用部署的资源清单。
|
||||
|
||||
### 下一步
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
---
|
||||
标题: helm 仓库
|
||||
描述: 配置 helm 仓库
|
||||
title: 配置 Helm 仓库
|
||||
---
|
||||
|
||||
在本教程中，我们将会介绍如何通过集成配置，创建 helm 仓库，并在创建应用时使用该仓库。
|
||||
|
|
@ -9,7 +8,7 @@
|
|||
|
||||
## 创建一个 Helm 仓库
|
||||
|
||||
例如在本图中，你可以设置 helm 仓库的 url，并且如果你的仓库还开启了 `HTTP basic authentication` 你也可以为这个仓库设置 `username` 和 `paswword`。
|
||||
例如在本图中，你可以设置 helm 仓库的 url，并且如果你的仓库还开启了 `HTTP basic authentication` 你也可以为这个仓库设置 `username` 和 `password`。
|
||||
|
||||
在本例子中，我们使用 [azure](https://marketplace.azurecr.io/helm/v1/repo) 作为 helm 仓库。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
title: 管理部署目标
|
||||
---
|
||||
|
||||
为了将应用组件部署在不同的地方，VelaUX 提供了 **部署目标（Target）** 方便用户管理要部署的具体位置，比如集群或者命名空间。
|
||||
为了将应用组件部署在不同的地方，控制台中提供了 **部署目标（Target）** 方便用户管理要部署的具体位置，比如集群或者命名空间。
|
||||
|
||||
> 此文档仅适用于 UI
|
||||
|
||||
## 集群
|
||||
|
||||
|
|
@ -10,7 +12,6 @@ title: 管理部署目标
|
|||
|
||||
|
||||
|
||||
|
||||
在向 KubeVela 添加完集群之后，你可以编辑它的基本描述信息，或者在没有应用使用它的时候将它从 KubeVela 管控平台上移除。
|
||||
|
||||
## 创建部署目标
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: RBAC 授权
|
||||
---
|
||||
|
||||
RBAC 功能可以限制对 VelaUX 资源的访问。 VelaUX 的 UI 和 API 都会进行严格的权限校验。我们设计了平台级角色和项目级角色，每一个角色可绑定一组权限策略，用户绑定到角色即获取对应的权限。
|
||||
RBAC 功能可以限制对 KubeVela 资源的访问。UI 和 API 都会进行严格的权限校验。我们设计了平台级角色和项目级角色，每一个角色可绑定一组权限策略，用户绑定到角色即获取对应的权限。
|
||||
|
||||
## 内置权限策略
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 自定义安装
|
||||
title: 自定义安装和升级
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
|
|
|
|||
|
|
@ -1,89 +0,0 @@
|
|||
---
|
||||
title: 怎么用 helm
|
||||
---
|
||||
|
||||
在本节中，将介绍如何通过 `ComponentDefinition` 将 Helm charts 声明为应用程序组件。
|
||||
|
||||
> 在阅读本部分之前，请确保你已经了解了[定义和模板概念](../definition-and-templates)。
|
||||
|
||||
## 先决条件
|
||||
|
||||
* [fluxcd/flux2](../../install#3-optional-install-flux2)，请确保你已经在[安装指南](../../install)中安装了 flux2。
|
||||
|
||||
## 声明 `ComponentDefinition`
|
||||
|
||||
这是一个关于如何使用 Helm 作为 schematic 模块的示例 `ComponentDefinition`。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webapp-chart
|
||||
annotations:
|
||||
definition.oam.dev/description: helm chart for webapp
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
schematic:
|
||||
helm:
|
||||
release:
|
||||
chart:
|
||||
spec:
|
||||
chart: "podinfo"
|
||||
version: "5.1.4"
|
||||
repository:
|
||||
url: "http://oam.dev/catalog/"
|
||||
```
|
||||
|
||||
详细：
|
||||
- 需要`.spec.workload` 来指示这个基于 Helm 的组件的工作负载类型。 如果你将多个工作负载打包在一个 chart 中，请同时检查 [已知限制](./known-issues#=workload-type-indicator)。
|
||||
- `.spec.schematic.helm` 包含 Helm `release` 和利用 `fluxcd/flux2` 的 `repository` 的信息。
|
||||
- 即`release`的pec与[`HelmReleaseSpec`](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md) 对齐，`repository`的 spec 和[`HelmRepositorySpec`](https://github.com/fluxcd/source-controller/blob/main/docs/api/source.md#source.toolkit.fluxcd.io/v1beta1.HelmRepository)对齐。
|
||||
|
||||
## 声明一个`Application`
|
||||
|
||||
这是一个示例 `Application`。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.2"
|
||||
```
|
||||
|
||||
组件 `properties` 正是 Helm Chart 的 [overlay values](https://github.com/captainroy-hy/podinfo/blob/master/charts/podinfo/values.yaml)。
|
||||
|
||||
部署应用程序，几分钟后（获取 Helm Chart 可能需要一些时间），你可以检查 Helm 版本是否已安装。
|
||||
```shell
|
||||
$ helm ls -A
|
||||
myapp-demo-podinfo default 1 2021-03-05 02:02:18.692317102 +0000 UTC deployed podinfo-5.1.4 5.1.4
|
||||
```
|
||||
检查 Chart 中定义的工作负载是否已成功创建。
|
||||
```shell
|
||||
$ kubectl get deploy
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
myapp-demo-podinfo 1/1 1 1 66m
|
||||
```
|
||||
|
||||
检查应用程序的 `properties` 中的值（`image.tag = 5.1.2`）是否已分配给 Chart 。
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
|
||||
"ghcr.io/stefanprodan/podinfo:5.1.2"
|
||||
```
|
||||
|
||||
|
||||
### 从基于 Helm 的组件生成表单
|
||||
|
||||
KubeVela 会根据 Helm Chart 中的 [`values.schema.json`](https://helm.sh/docs/topics/charts/#schema-files) 自动生成 OpenAPI v3 JSON schema，并将其存储在一个 ` ConfigMap` 在与定义对象相同的 `namespace` 中。 此外，如果 Chart 作者未提供 `values.schema.json`，KubeVela 将根据其 `values.yaml` 文件自动生成 OpenAPI v3 JSON 模式。
|
||||
|
||||
请查看 [Generate Forms from Definitions](/docs/platform-engineers/openapi-v3-json-schema) 指南，了解有关使用此架构呈现 GUI 表单的更多详细信息。
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
---
|
||||
title: 已知限制
|
||||
---
|
||||
|
||||
## 限制
|
||||
|
||||
以下是使用 Helm 图表作为应用程序组件的一些已知限制。
|
||||
|
||||
### 工作负载类型指示器
|
||||
|
||||
遵循微服务的最佳实践，KubeVela 建议在一个 Helm 图表中只存在一种工作负载资源。 请将你的“超级”Helm 图表拆分为多个图表（即组件）。 本质上，KubeVela 依赖于组件定义中的`workload`来指示它需要注意的工作负载类型，例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
...
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps.kruise.io/v1alpha1
|
||||
kind: Cloneset
|
||||
```
|
||||
|
||||
请注意，如果多个工作负载类型打包在一个图表中，KubeVela 不会失败，问题在于进一步的操作行为，例如推出、修订和流量管理，它们只能对指定的工作负载类型生效。
|
||||
|
||||
### 始终使用完整的限定名称
|
||||
|
||||
工作负载的名称应使用 [完全限定的应用程序名称](https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/pkg/chartutil/create.go#L415) 进行模板化，并且请不要为`.Values.fullnameOverride`。作为最佳实践，Helm 还强烈建议通过 `$ helm create` 命令创建新图表，以便根据此最佳实践自动定义模板名称。
|
||||
|
||||
### 控制应用程序升级
|
||||
|
||||
对组件`properties` 所做的更改将触发 Helm 版本升级。此过程由 Flux v2 Helm 控制器处理，因此你可以定义基于 [Helm Release 文档](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md#upgraderemediation) 和 [规范](https://toolkit.fluxcd.io/components/helm/helmreleases/#configuring-failure-remediation)的修复，以防在此升级过程中发生故障。
|
||||
|
||||
例如：
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webapp-chart
|
||||
spec:
|
||||
...
|
||||
schematic:
|
||||
helm:
|
||||
release:
|
||||
chart:
|
||||
spec:
|
||||
chart: "podinfo"
|
||||
version: "5.1.4"
|
||||
upgrade:
|
||||
remediation:
|
||||
retries: 3
|
||||
remediationStrategy: rollback
|
||||
repository:
|
||||
url: "http://oam.dev/catalog/"
|
||||
|
||||
```
|
||||
|
||||
尽管目前存在一个问题，但很难获得有关 Helm 实时发布的有用信息，以了解升级失败时发生的情况。我们将增强可观察性，帮助用户在应用层面跟踪 Helm 发布的情况。
|
||||
|
||||
## 问题
|
||||
|
||||
已知问题将在后续版本中修复。
|
||||
|
||||
### 推出策略
|
||||
|
||||
目前，基于 Helm 的组件无法受益于 [应用程序级部署策略](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/rollout-design.md#applicationdeployment-workflow)。如[本示例](./trait#update-an-applicatiion)所示，如果应用更新了，只能直接 rollout，没有 canary 或者 blue-green 方式。
|
||||
|
||||
### 更新特征属性也可能导致 Pod 重启
|
||||
|
||||
特性属性的更改可能会影响组件实例，属于此工作负载实例的 Pod 将重新启动。在基于 CUE 的组件中，这是可以避免的，因为 KubeVela 可以完全控制资源的渲染过程，尽管在基于 Helm 的组件中，它目前被推迟到 Flux v2 控制器。
|
||||
|
|
@ -1,153 +0,0 @@
|
|||
---
|
||||
标题: 添加 Trait 特性
|
||||
---
|
||||
|
||||
KubeVela 中的 Trait 特性可以从基于Helm的组件无缝添加.
|
||||
|
||||
在以下应用实例中，我们将基于 Helm 组件添加两个 Trait 特性 [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml) 和 [virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/helm-module/virtual-group-td.yaml).
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.2"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 4
|
||||
- type: virtualgroup
|
||||
properties:
|
||||
group: "my-group1"
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
> 注意: 当我们使用基于 Helm 的 Trait 特性时, *请确认在你 Helm 图标中的目标负载严格按照 qualified-full-name convention in Helm 的命名方式.* [以此表为例](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/deployment.yaml#L4),
|
||||
> 负载名为[版本名和图表名](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/_helpers.tpl#L13).
|
||||
|
||||
> 这是因为 KubeVela 依赖命名去发现负载,否则将不能把 Trait 特性赋予负载. KubeVela 将会基于你的应用和组件自动生成版本名, 所以你需要保证不能超出你的 Helm 图表中命名模版格式.
|
||||
|
||||
## 验证特性工作正确
|
||||
|
||||
> 因为应用内部的调整生效需要几秒钟时间.
|
||||
|
||||
检查缩放组 `scaler` 特性生效.
|
||||
```shell
|
||||
$ kubectl get manualscalertrait
|
||||
NAME AGE
|
||||
demo-podinfo-scaler-d8f78c6fc 13m
|
||||
```
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
|
||||
4
|
||||
```
|
||||
|
||||
检查虚拟组 `virtualgroup` 特性.
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
|
||||
{
|
||||
"app.cluster.virtual.group": "my-group1",
|
||||
"app.kubernetes.io/name": "myapp-demo-podinfo"
|
||||
}
|
||||
```
|
||||
|
||||
## 更新应用
|
||||
|
||||
当应用已被部署且 workload 负载/ Trait 特性都被顺利建立时,
|
||||
你可以更新应用, 变化会被负载实例所响应.
|
||||
|
||||
让我们对实例应用的配置做几个改动.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.3" # 5.1.2 => 5.1.3
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 2 # 4 => 2
|
||||
- type: virtualgroup
|
||||
properties:
|
||||
group: "my-group2" # my-group1 => my-group2
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
在几分钟后应用新配置并检查效果.
|
||||
|
||||
检查从应用属性 `properties` 的新值 (`image.tag = 5.1.3`) 已被赋予图表.
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
|
||||
"ghcr.io/stefanprodan/podinfo:5.1.3"
|
||||
```
|
||||
实际上, Helm 更新了版本号 (revision 1 => 2).
|
||||
```shell
|
||||
$ helm ls -A
|
||||
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
|
||||
myapp-demo-podinfo default 2 2021-03-15 08:52:00.037690148 +0000 UTC deployed podinfo-5.1.4 5.1.4
|
||||
```
|
||||
|
||||
检查 `scaler` 的特性.
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
|
||||
2
|
||||
```
|
||||
|
||||
检查 `virtualgroup` 的特性.
|
||||
```shell
|
||||
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
|
||||
{
|
||||
"app.cluster.virtual.group": "my-group2",
|
||||
"app.kubernetes.io/name": "myapp-demo-podinfo"
|
||||
}
|
||||
```
|
||||
|
||||
## 去除 Trait 特性
|
||||
|
||||
让我们试试从应用中去除特性.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
settings:
|
||||
image:
|
||||
tag: "5.1.3"
|
||||
traits:
|
||||
# - name: scaler
|
||||
# properties:
|
||||
# replicas: 2
|
||||
- name: virtualgroup
|
||||
properties:
|
||||
group: "my-group2"
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
更新应用实例并检查 `manualscalertrait` 已被删除.
|
||||
```shell
|
||||
$ kubectl get manualscalertrait
|
||||
No resources found
|
||||
```
|
||||
|
||||
|
|
@ -2,16 +2,27 @@
|
|||
title: 集群管理
|
||||
---
|
||||
|
||||
KubeVela 多集群功能中的集群管理是通过 Vela CLI 的一系列相关命令完成的。
|
||||
## 通过 UI 管理集群
|
||||
|
||||
* 支持添加已存在的 Kubernetes 集群；
|
||||
* 支持添加阿里云 ACK 集群；
|
||||
|
||||
具有集群管理权限的用户可以进入集群管理页面，添加或移除托管的集群。
|
||||
|
||||
|
||||
从 ACK 添加的集群平台会获取并记录集群所在的区域、VPC、Dashboard地址等信息，用户使用该集群创建交付目标时将自动引用，这些信息用以辅助云服务的创建。
|
||||
|
||||
## 通过 CLI 管理集群
|
||||
|
||||
### vela cluster list
|
||||
|
||||
该命令可列出当前 KubeVela 正在管理的所有子集群。
|
||||
|
||||
```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
|
||||
$ vela cluster list
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
ask-beijing X509Certificate https://*.*.*.*:6443 true
|
||||
```
|
||||
|
||||
### vela cluster join
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
|
||||
# KubeVela Offline Installation Guide
|
||||
---
|
||||
title: 离线安装
|
||||
---
|
||||
|
||||
KubeVela 离线部署包含 KubeVela Core 和 KubeVela Addon 的离线部署。
|
||||
|
||||
|
|
@ -56,5 +56,4 @@ charts/vela-core/templates/defwithtemplate/nocalhost.yaml: image: "
|
|||
|
||||
重新打包上面修改好的 Helm Chart 包，直接安装或者传入离线环境的 Helm Chart 仓库。
|
||||
|
||||
|
||||
## KubeVela Addon 离线部署
|
||||
|
|
|
|||
|
|
@ -2,80 +2,93 @@
|
|||
title: 交付第一个应用
|
||||
---
|
||||
|
||||
> 在实践之前，请确保你已经按照 [快速安装](./install.mdx) 文档，在你的控制平面集群中安装了 KubeVela Core 和 VelaUX。
|
||||
>
|
||||
> 如果你希望通过使用 KubeVela CLI 来进行应用交付，请查看 Vela CLI 手册的 [交付第一个应用](./end-user/quick-start-cli)。
|
||||
> 开始之前，请确认你已完成 KubeVela 的安装，参考 [安装指导文档](./install.mdx)
|
||||
|
||||
欢迎来到 KubeVela！在本小节中，我们会向你介绍如何使用 VelaUX 来交付一个简单的应用。
|
||||
欢迎使用 KubeVela, 在该章节中你可以学习到使用 KubeVela 部署一个基础的应用。
|
||||
|
||||
你将会操作的步骤有：
|
||||
## 通过 CLI 部署应用
|
||||
|
||||
1. 准备一个服务镜像，本例中我们将使用： [crccheck/hello-world](https://hub.docker.com/r/crccheck/hello-world)，请确保你的环境可以正常下载该镜像；
|
||||
2. 基于服务镜像创建第一个 `webservice` 类型的 `Application`，这是无状态服务最简化的交付方式；
|
||||
3. 查看应用实例运行状态；
|
||||
一个基础的应用定义及部署方式如下所述：
|
||||
|
||||
你将学习到内容的有：
|
||||
|
||||
- 初步接触 [应用(Application)](./getting-started/core-concept#应用（application）)、[环境(Environment)](getting-started/core-concept#环境（Environment））) 和 [交付目标(Target)](getting-started/core-concept#交付目标（target）) 等核心概念。
|
||||
|
||||
- 通过操作 VelaUX 完整交付一个应用。
|
||||
|
||||
## 登陆到 VelaUX
|
||||
|
||||
正常安装 VelaUX 后你需要登陆。默认账号为admin，通过以下方式获取密码
|
||||
|
||||
```shell
|
||||
# 首次安装时获取
|
||||
vela logs -n vela-system --name apiserver addon-velaux | grep "initialized admin username"
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
# YAML begins
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
ports:
|
||||
- port: 8000
|
||||
expose: true
|
||||
# YAML ends
|
||||
EOF
|
||||
```
|
||||
|
||||
如果日志中已不存在信息，可查询 `vela-system` 命名空间下的 `admin` 名称的 Secret。
|
||||
复制上述命名并执行后，一个简单的应用即可完成部署，需要注意的是需要你的部署环境可以正常获取 `crccheck/hello-world` 镜像。部署完成后可以通过下述方式来访问该应用。
|
||||
|
||||
## 选择应用的部署类型/规划应用部署环境
|
||||
```
|
||||
$ vela port-forward first-vela-app 8000:8000
|
||||
<xmp>
|
||||
Hello World
|
||||
|
||||
你进入的第一个页面即应用交付管理页面，在该页面中你可以查看到有权查看的所有应用列表。管理员初次进入时你可以看到一个只读的 `addon-velaux` 应用，它是VelaUX addon的运行应用，我们仅能进行运行数据观测。
|
||||
|
||||
|
||||
## .
|
||||
## ## ## ==
|
||||
## ## ## ## ## ===
|
||||
/""""""""""""""""\___/ ===
|
||||
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
|
||||
\______ o _,/
|
||||
\ \ _,'
|
||||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
|
||||
然后点击右上角的 `New Application` 按钮开始创建应用，按照 UI 提示填写以下四个维度的信息：
|
||||
到这里，你已完成了第一个简单应用的部署，它仅包括一个组件，暂未涉及运维特征、工作流和多集群等特性。
|
||||
|
||||
- 应用的名称等基础信息；
|
||||
- 选择所属的项目，我们已为你自动生成了默认项目，你也可以点击 `New` 进行创建；
|
||||
- 选择应用的部署类型，本例中我们选择 `webservice` 类型，部署无状态服务，请注意，企业大多数业务应用都可以直接使用该类型进行部署。
|
||||
- 规划应用交付的环境，我们选择基于默认 `Default` 交付目标创建的默认 `Default` 环境；
|
||||
> 目前，通过 CLI 创建的应用会同步到 UI 进行可视化，但它是只读的。
|
||||
|
||||
|
||||
## 通过 UI 部署应用
|
||||
|
||||
## 设置应用的部署参数
|
||||
登陆到 KubeVela UI 控制后，默认你将进入应用管理页面。点击页面右上方的 `新建应用` 按钮，输入应用基础信息：
|
||||
|
||||
接下来看到应用的部署配置页面，我们需要配置的以下信息：
|
||||
1. 应用名称、别名等基础信息；
|
||||
2. 选择一个应用所属项目，平台默认生成了 `Default` 项目，你可以根据需要创建新的项目；
|
||||
3. 选择主组件类型，这里我们选择默认的 `webservice` 类型。
|
||||
4. 选择部署环境，部署环境选项由不同的项目决定。
|
||||
|
||||
- Image 地址，填入 `crccheck/hello-world`。
|
||||
### 设置部署参数
|
||||
|
||||
> 其他参数设置在当前用例中无需进行设置。
|
||||
设置完应用基础信息后进入第二步，设置主组件的部署参数，我们需要设置的参数包括：
|
||||
|
||||
|
||||
- 镜像地址： `crccheck/hello-world`
|
||||
- 端口信息：将默认的 80 端口变更为 8080 端口。
|
||||
|
||||
确认创建后即可进入应用管理页面，这时应用还没有开始进行部署，VelaUX 默认生成了默认环境的交付 [工作流](./getting-started/core-concept#工作流（workflow）) 和调整应用副本数量的 [运维特征](./getting-started/core-concept#运维特征（trait）)。
|
||||
|
||||
|
||||
|
||||
确认创建后即可完成应用配置，控制台创建的应用默认会根据所选环境生成 [工作流](./getting-started/core-concept#workflow) 和一个设置副本数的 [运维特征](./getting-started/core-concept#trait)。
|
||||
|
||||
## 执行环境的部署
|
||||
### 执行工作流部署应用
|
||||
|
||||
直接点击页面右上方的部署按钮。工作流执行完成后刷新应用部署状态页面即可查看到该应用交付的资源清单和组件状态。切换到实例页面可查询到该应用生成的实例信息。
|
||||
点击应用详情页右上方的 `部署` 按钮，选择指定环境的工作流即可开始部署应用。
|
||||
|
||||
|
||||
|
||||
## 应用删除
|
||||
### 删除应用
|
||||
|
||||
体验完成后如何你需要删除部署的应用，你需要进行如下操作：
|
||||
如果在你测试完成后需要删除该应用，操作方式如下：
|
||||
|
||||
（1）进入应用的环境页面，点击 `Recycle`，即可完成该环境的部署资源回收。
|
||||
1. 进入应用环境页面，点击 `回收` 按钮完成所有环境的资源回收。
|
||||
2. 回到应用列表页面，点击卡片中的操作按钮，点击删除选项确认删除即可。
|
||||
|
||||
（2）回到应用列表页面，点击应用卡片的操作按钮，选择删除即可。
|
||||
|
||||
通过上述操作，你已经完成了第一个应用的交付，完成了进阶。
|
||||
到此，你完成了 KubeVela 的初体验。
|
||||
|
||||
## 下一步
|
||||
|
||||
- 阅读并参考 [实践教程](./tutorials/k8s-object) 章节文章，解锁更多 KubeVela 能力。
|
||||
- 阅读 [核心概念](./getting-started/core-concept) 文档获取核心概念解读。
|
||||
- 阅读 [用户手册](./tutorials/webservice) 获取更多特性玩法。
|
||||
|
|
|
|||
|
|
@ -32,6 +32,12 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart
|
|||
|
||||
当观察到插件显示为 `enabled` 状态，即代表插件启用已经完成。可以开始交付 Helm 应用了。
|
||||
|
||||
你也可以通过 CLI 来启用插件：
|
||||
|
||||
```shell
|
||||
vale addon enable fluxcd
|
||||
```
|
||||
|
||||
## 通过 Chart 创建 Redis 应用
|
||||
|
||||
相信你通过之前的文章，已经掌握了应用的创建能力。我们需要使用 Chart 创建 Redis 应用，只需要选择应用部署类型为 `helm`，然后选择你准备好的具有默认 StorageClass 可以提供 PV 的集群 Target，然后进入部署参数配置页面。
|
||||
|
|
@ -50,10 +56,66 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart
|
|||
|
||||
## 修改部署参数
|
||||
|
||||
这里我们解锁新技能，修改应用的部署参数。对于任何应用类型，它都可以在任何时候通过点击 `Baseline Config` 页面右上方的 `Edit Properties` 按钮进入部署参数的修改页面。该页面与我们创建应用时设置应用部署参数的页面完全一致，它是由每一个应用类型的 Definition 定义的参数结合 KubeVela UISchema 规范自动生成。
|
||||
在 UI 中点击配置页面的组件名称即可进入组件的配置页面，对于 Helm Chart 部署的组件，我们能够通过设置 Values 配置项来变更部署参数，也可以支持变更 Chart 的来源。其中 Values 配置项会基于 `values.yaml` 文件中的默认值来生成配置提醒，你可以选择需要配置的行并为其设置需要的值。
|
||||
|
||||
修改部署参数后，必须执行环境的工作流才能将修改后的参数在指定的环境生效，由于版本管理的机制存在，历史配置参数会在版本中得以保存。
|
||||
|
||||
## 通过 CLI 部署
|
||||
|
||||
你也可以通过 CLI 来部署 Helm Chart 类型的应用, 基础配置如下：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: helm-redis
|
||||
spec:
|
||||
components:
|
||||
- name: redis
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://charts.bitnami.com/bitnami"
|
||||
chart: "redis"
|
||||
version: "16.8.5"
|
||||
values:
|
||||
master.persistence.size: 16Gi
|
||||
replica.persistence.size: 16Gi
|
||||
```
|
||||
|
||||
你可以通过下述命令完成部署：
|
||||
|
||||
```shell
|
||||
vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
|
||||
```
|
||||
|
||||
接下来，通过 `vela status helm-redis` 命令查询部署应用的状态，直到进入下述状态即部署成功。
|
||||
|
||||
```
|
||||
About:
|
||||
Name: helm-redis
|
||||
Namespace: default
|
||||
Created at: 2022-04-21 17:19:12 +0800 CST
|
||||
Status: running
|
||||
Workflow:
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:n1gxswwina
|
||||
name:redis
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
Services:
|
||||
- Name: redis
|
||||
Cluster: local Namespace: default
|
||||
Type: helm
|
||||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
|
||||
到此，你已经掌握了 Helm 应用的交付能力，快去交付更多的 Helm 应用吧。
|
||||
|
||||
## 下一步
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 对接 Jenkins
|
||||
title: 集成 Jenkins 进行持续交付
|
||||
---
|
||||
|
||||
### 简介
|
||||
|
|
@ -10,6 +10,8 @@ KubeVela 应用的工作流可以通过 Webhook 触发器触发。这使得诸
|
|||
|
||||
本文将详细介绍如何对接 KubeVela 与 Jenkins。
|
||||
|
||||
> 该教程仅适用于 UI 用户。
|
||||
|
||||
### 准备
|
||||
|
||||
在开始本文教程之前，需要先确认一下的事项
|
||||
|
|
|
|||
|
|
@ -86,10 +86,115 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
|
|||
|
||||
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
## 通过 CLI 交付
|
||||
|
||||
<!-- ## 参考视频 TODO v1.2 -->
|
||||
通过 CLI 部署的应用没有环境的概念，你可以通过部署多个应用来实现与控制台中类似的环境隔离。
|
||||
|
||||
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-with-k8s-objects
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: k8s-demo-service
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
strategy:
|
||||
type: Recreate
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-type: nlb
|
||||
labels:
|
||||
app: nginx
|
||||
name: nginx
|
||||
namespace: default
|
||||
spec:
|
||||
externalTrafficPolicy: Local
|
||||
ports:
|
||||
- name: http
|
||||
port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: nginx
|
||||
type: LoadBalancer
|
||||
type: k8s-objects
|
||||
policies:
|
||||
- name: topology-default
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ['local']
|
||||
namespace: default
|
||||
- name: topology-production
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ['local']
|
||||
namespace: production
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2default
|
||||
properties:
|
||||
policies: ['topology-default']
|
||||
type: deploy
|
||||
- name: suspend
|
||||
type: suspend
|
||||
- name: deploy2production
|
||||
properties:
|
||||
policies: ['topology-production']
|
||||
type: deploy
|
||||
```
|
||||
|
||||
- 关于 Topology 策略参考: [Topology](../end-user/policies/references#override)
|
||||
- 关于 Deploy 步骤参考: [Deploy](../end-user/workflow/built-in-workflow-defs#deploy)
|
||||
|
||||
通过下述命令来部署该应用：
|
||||
|
||||
- 在部署之前创建所需的命名空间 `production`
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
```
|
||||
|
||||
- 部署该应用
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
```
|
||||
|
||||
- 查询应用状态进入暂停状态后执行审核命令：
|
||||
|
||||
```shell
|
||||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
|
||||
## 下一步
|
||||
|
||||
- [学习交付云厂商服务](./consume-cloud-services)
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
- [分发已存在的 Kubernetes 对象](../end-user/components/ref-objects)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 使用单点登录
|
||||
title: 单点登录
|
||||
---
|
||||
|
||||
## 简介
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 在持续交付中集成镜像仓库
|
||||
title: 集成镜像仓库进行持续交付
|
||||
---
|
||||
|
||||
## 简介
|
||||
|
|
@ -10,6 +10,8 @@ title: 在持续交付中集成镜像仓库
|
|||
|
||||
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，Harbor 作为镜像仓库来完成演示。
|
||||
|
||||
> 该教程仅适用于 UI 用户。
|
||||
|
||||
## 创建应用
|
||||
|
||||
要使用触发器，首先我们需要在 VelaUX 上新建一个应用。在这里，我们可以新建一个 WebService 类型的应用，并使用 LoadBalancer 为其暴露 80 端口以便访问。
|
||||
|
|
|
|||
|
|
@ -9,60 +9,111 @@ description: 参考本文章，学习使用容器镜像部署企业业务应用
|
|||
|
||||
- 完成你的业务容器化，无论你的业务使用何种开发语言，请先将其通过 CI 系统或在本地完成运行镜像打包。
|
||||
|
||||
> KubeVela 未来计划提供支持多种开发语言的容器打包方案，帮助你低门槛完成业务容器化。
|
||||
|
||||
- 将你的业务镜像存放于镜像仓库中，KubeVela 管理的集群可以正常获取该镜像。
|
||||
|
||||
- 明确你的业务需要设置哪些环境变量，是否有其他中间件依赖（比如数据库、缓存等），如果有，请先部署中间件服务。
|
||||
- 启用了 VelaUX 插件，如果你仅是 CLI 用户，直接参考 [通过 CLI 部署](#deploy-via-cli)
|
||||
|
||||
## 创建应用
|
||||
|
||||
进入 KubeVela 应用管理页面（目录：Applictaions），点击 `New Application` 进入应用创建流程。首先设置应用的名称、别名和描述；选择类型 `webservice`；选择发布的环境，初始情况下已经存在 Default 环境可选，你也可以进入环境管理页面(目录：Envs) 创建新的环境。
|
||||
进入应用管理页面，点击右上方的 `新建应用` 按钮，进入应用创建弹窗页面，输入应用名称等基础信息，选择 `webservice` 主组件类型，并选择需要部署的环境。点击下一步进入组件部署属性配置页面，如图所示，填写镜像名称、启动命令，端口等信息。根据你的集群支持情况选择合适的服务暴露方式。
|
||||
|
||||
|
||||
|
||||
|
||||
点击 `Next Step` 进入部署参数设置页面。在当前页面中，我们需要设置业务应用的镜像名称（Image），如果需要设置镜像的启动命令，可以打开 `CMD` 栏目，添加启用命令，如果需要设置环境变量，可以打开 `ENV` 栏目，按照需要设置环境变量。
|
||||
|
||||
|
||||
|
||||
截图所示部署的业务是 `Wordpress`，填写了镜像名称 `wordpress` 和设置了四个环境变量，若你也使用该镜像进行测试，请设置正确的数据库地址变量。
|
||||
|
||||
点击 `Create` 完成应用的创建流程，进入应用管理页面。
|
||||
确认提交后即完成应用初始化配置。
|
||||
|
||||
## 部署应用
|
||||
|
||||
点击页面右上方的 `Deploy` 按钮，开始应用的部署。点击该按钮的含义是执行默认的工作流。请注意，KubeVela 已经为应用的每一个发布环境生成了对应的工作流。在 `Baseline Config` 的右方即为应用需要交付的环境，点击环境名称即可进入该环境页面查询应用部署状态和应用实例信息。
|
||||
应用创建后默认不会自动部署，需要点击页面右上方的部署按钮，并选择需要执行的工作流，每一个工作流对应部署一个环境。部署开始后可以点击 `基础配置` 旁边的不同 Tab 即进入不同环境的管理页面。
|
||||
|
||||
|
||||
|
||||
若该环境中包括多个交付目标，可以切换不同的交付目标查看应用实例列表。点击 `Check the details`，在弹窗中可以查看到应用的部署整体进度和创建的资源信息。
|
||||
每一个环境视图目前提供了部署资源状态、应用实例和应用日志的查询页面。部署资源状态页面展示了该应用实际分发的底层资源列表即各组件状态；应用实例页面中展示该应用部署的所有实例信息，点击实例行即可查询该实例的详细信息；日志页面可以查询该应用所有运行实例的标准输出日志。
|
||||
|
||||
在实例列表中可以查看应用实例的交付状态，若其一直处于非运行态，可点击实例行最前方的+号展开实例详情，查看详细信息。
|
||||
## 更新镜像版本
|
||||
|
||||
## 变更镜像版本
|
||||
当我们完成初始部署后，后续随着我们业务开发和升级需要变更镜像版本或其他部署参数。
|
||||
|
||||
当应用完成第一次部署后，我们的业务可能在持续开发，后续产生的新版本镜像，我们需要变更镜像版本。点击 `Baseline Config`，进入应用配置页面，点击 `Edit Properties` 按钮即可再次进入部署参数设置页面，在该页面中可以变更镜像名称，版本和环境变量等参数。
|
||||
回到基础配置页面，点击需要修改的组件名称即可进入组件设置弹窗页面，在该页面中你可以修改部署镜像、环境变量等部署参数，也可以变更组件别名或描述等基础信息。
|
||||
|
||||
## 变更应用的副本数量
|
||||
## 更新副本数
|
||||
|
||||
如果业务应用需要设置多个副本，进入应用配置页面，在运维特征管理中，已经默认挂载了名为 `Set Replicas` 的运维特征，点击设置图标按钮即可进入副本数调整设置页面，填写你需要设置的副本数量，点击 `Update` 按钮提交即可。
|
||||
如果你的业务需要扩大或减小规模，我们使用调整副本数的运维特征来设置副本数量，在控制台中创建的应用该运维特征会自动创建。点击组件卡片上的`Scaler`运维特征即可进入配置页面，你可以手动设置需要的副本数量。
|
||||
|
||||
|
||||
|
||||
## 应用升级
|
||||
## 升级应用
|
||||
|
||||
上述两个步骤分别改变了应用的部署参数和运维特征，但是它还处于草稿状态，我们需要再次点击部署按钮即可将应用完成升级。
|
||||
上述两个步骤我们只是修改了应用的配置参数，但其不是立即在部署环境中生效的，我们可以再次点击部署按钮选择需要升级的环境对应的工作流执行，即可完成指定环境的升级。
|
||||
|
||||
## 应用回收与删除
|
||||
## 通过 CLI 部署应用
|
||||
|
||||
若你测试完成需要将应用删除，需要首先回收所有部署的环境，同样点击环境名称进入环境实例列表查询页面，点击 `Recycle` 按钮即可回收应用在该环境的部署。回收完成后应用在该环境进入未部署状态。
|
||||
如果你不使用 UI，通过 CLI 也可以完成业务应用示例的部署，通过执行下述命令即可：
|
||||
|
||||
当所有环境都已回收完成后，可进行应用删除操作。目前应用删除入口在应用列表页面。点击左侧目录，回到应用列表页面，鼠标应用名称右侧的操作图标上，点击 `Remove` 选项即可。
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
# YAML begins
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webservice-app
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
ports:
|
||||
- port: 8080
|
||||
expose: true
|
||||
exposeType: LoadBalancer
|
||||
cpu: "0.5"
|
||||
memory: "512Mi"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
# YAML ends
|
||||
EOF
|
||||
```
|
||||
|
||||
|
||||
> 目前，通过 CLI 部署的应用会同步到控制台中，但其为只读状态。
|
||||
|
||||
到此，你已经基本掌握了业务应用的部署方法，更多的部署参数支持都集中在应用部署参数设置页面之中。
|
||||
你也可以复制上述的应用配置并创建一个 YAML 文件 `webservice-app.yaml`，然后使用命令 `vela up -f webservice-app.yaml` 来完成部署。
|
||||
|
||||
接下来你可以通过 `vela status webservice-app` 命令获取应用的部署状态。
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: test-app
|
||||
Namespace: default
|
||||
Created at: 2022-04-21 12:03:42 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:y4n26n7uql
|
||||
name:frontend
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: frontend
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
Traits:
|
||||
✅ scaler
|
||||
```
|
||||
|
||||
## 下一步
|
||||
|
||||
[学习基于 Helm Chart 部署中间件应用](./helm)
|
||||
[学习基于 Helm Chart 部署应用](./helm)
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ export default function Home() {
|
|||
<p className="hero__subtitle">{siteConfig.tagline}</p>
|
||||
<div
|
||||
className={clsx(styles.heroButtons, 'name', 'margin-vert--md')}>
|
||||
<Button href={useBaseUrl('docs/end-user/quick-start-cli')}><Translate>Get Started</Translate></Button>
|
||||
<Button href={useBaseUrl('docs/quick-start')}><Translate>Get Started</Translate></Button>
|
||||
<Button href={useBaseUrl('docs/')}><Translate>Learn More</Translate></Button>
|
||||
</div>
|
||||
</div>
|
||||
|
|
@ -128,4 +128,4 @@ const WhatIs = () => (
|
|||
</div>
|
||||
</div>
|
||||
</div >
|
||||
);
|
||||
);
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ title: GitOps
|
|||
|
||||
This section will introduce how to use KubeVela in GitOps environment and why.
|
||||
|
||||
> This section is only apply to CLI.
|
||||
|
||||
## 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).
|
||||
|
|
@ -19,7 +21,6 @@ KubeVela as an declarative application delivery control plane can be naturally u
|
|||
- 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:
|
||||
|
|
|
|||
|
|
@ -15,7 +15,6 @@ There are many scenarios that developers or system operators need to deploy and
|
|||
|
||||
The following guide will introduce how to manage applications across clusters on KubeVela.
|
||||
|
||||
|
||||
## Preparation
|
||||
|
||||
You can simply join an existing cluster into KubeVela by specifying its KubeConfig as below
|
||||
|
|
@ -534,4 +533,4 @@ No more add-hoc scripts or glue code, KubeVela will get the application delivery
|
|||
|
||||
## Next Step
|
||||
|
||||
* Refer to more examples about using KubeVela with [GitOps](./gitops).
|
||||
* Refer to more examples about [integrating with Jenkins](../tutorials/jenkins).
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
---
|
||||
title: Deploy Kubernetes Objects
|
||||
---
|
||||
|
||||
Use raw Kubernetes resources directly.
|
||||
|
||||
## How to use
|
||||
|
||||
For example, a Job:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-raw
|
||||
spec:
|
||||
components:
|
||||
- name: myjob
|
||||
type: k8s-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: batch/v1
|
||||
kind: Job
|
||||
metadata:
|
||||
name: pi
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: pi
|
||||
image: perl
|
||||
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
restartPolicy: Never
|
||||
backoffLimit: 4
|
||||
```
|
||||
|
||||
More than one resources, you should put your main workload in the first place, vela traits will only affect on the first object:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-stateful-service
|
||||
spec:
|
||||
components:
|
||||
- name: my-sts
|
||||
type: k8s-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
name: web
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx # has to match .spec.template.metadata.labels
|
||||
serviceName: "nginx"
|
||||
replicas: 3 # by default is 1
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx # has to match .spec.selector.matchLabels
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- name: www
|
||||
mountPath: /usr/share/nginx/html
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "my-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
ports:
|
||||
- port: 80
|
||||
name: web
|
||||
clusterIP: None
|
||||
selector:
|
||||
app: nginx
|
||||
```
|
||||
|
||||
|
||||
## Attributes
|
||||
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|---------|-------------|-----------------------|----------|---------|
|
||||
| objects | list objects of Kubernetes resource | [[]K8s-Object](#K8s-Object) | true | |
|
||||
|
||||
### K8s-Object
|
||||
|
||||
Just write the whole Kubernetes Resource in this property.
|
||||
|
|
@ -1,8 +1,10 @@
|
|||
---
|
||||
title: Deploy Container based Task and Cron Task
|
||||
title: Deploy Task or Cron Task
|
||||
---
|
||||
|
||||
* Describes jobs that run code or a script to completion
|
||||
> This type is apply to CLI and UI.
|
||||
|
||||
## Describes jobs that run code or a script to completion
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -19,8 +21,7 @@ spec:
|
|||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
```
|
||||
|
||||
|
||||
* Describes cron jobs that run code or a script to completion
|
||||
## Describes cron jobs that run code or a script to completion
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -36,4 +37,4 @@ spec:
|
|||
count: 10
|
||||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
schedule: "*/1 * * * *"
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
title: Deploy Helm Charts
|
||||
---
|
||||
|
||||
KubeVela's Helm component meets the needs of users to connect to Helm Chart. You can deploy any ready-made Helm chart software package from Helm Repo, Git Repo or OSS bucket through the Helm component, and overwrite its parameters.
|
||||
|
||||
## Deploy From Helm Repo
|
||||
|
||||
In this `Application`, we hope to deliver a component called redis-comp. It is a chart from the [bitnami](https://charts.bitnami.com/bitnami).
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
EOF
|
||||
```
|
||||
|
||||
Please copy the above code block and deploy it directly to the runtime cluster:
|
||||
```shell
|
||||
application.core.oam.dev/app-delivering-chart created
|
||||
```
|
||||
|
||||
Finally, we use `vela ls` to view the application status after successful delivery:
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
app-delivering-chart redis-comp helm running healthy 2021-08-28 18:48:21 +0800 CST
|
||||
```
|
||||
|
||||
We also see that the PHASE of the app-delivering-chart APP is running and the STATUS is healthy.
|
||||
|
||||
|
||||
## Deploy From OSS bucket
|
||||
|
||||
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
|
||||
|
||||
```shell
|
||||
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
|
||||
secret/bucket-secret created
|
||||
```
|
||||
|
||||
1. Example
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: bucket-app
|
||||
spec:
|
||||
components:
|
||||
- name: bucket-comp
|
||||
type: helm
|
||||
properties:
|
||||
repoType: oss
|
||||
# required if bucket is private
|
||||
secretRef: bucket-secret
|
||||
chart: ./chart/podinfo-5.1.3.tgz
|
||||
url: oss-cn-beijing.aliyuncs.com
|
||||
oss:
|
||||
bucketName: definition-registry
|
||||
```
|
||||
|
||||
## Deploy From Git Repo
|
||||
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: terraform-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/oam-dev/terraform-controller
|
||||
chart: ./chart
|
||||
git:
|
||||
branch: master
|
||||
```
|
||||
|
|
@ -4,6 +4,16 @@ title: Pull based Component
|
|||
|
||||
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
|
||||
|
||||
> This type is only apply to CLI.
|
||||
|
||||
## Enable the fluxcd addon
|
||||
|
||||
This component type is provided by the fluxcd addon, you must enable it firstly.
|
||||
|
||||
```shell
|
||||
vale addon enable fluxcd
|
||||
```
|
||||
|
||||
## Watch Files
|
||||
|
||||
### Deploy From OSS bucket
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
title: Needs More Component？
|
||||
---
|
||||
|
||||
## 1. Refer to [All Component References](./references) for all other component types.
|
||||
* Refer to [All Component References](./references) for all other component types.
|
||||
|
||||
## 2. Get more from [install addons](../../how-to/cli/addon/addon).
|
||||
* Get more from [install addons](../../how-to/cli/addon/addon).
|
||||
|
||||
## 3. Extend KubeVela by yourself
|
||||
* Extend KubeVela by yourself
|
||||
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ Sometimes, you may want to distribute existing Kubernetes objects. For example,
|
|||
|
||||
> This document requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../../case-studies/multi-cluster) for details.
|
||||
|
||||
> This type is only apply to CLI.
|
||||
|
||||
## Refer to Existing Kubernetes Objects in Component
|
||||
|
||||
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Aggregated Health Probe
|
||||
draft: true
|
||||
---
|
||||
|
||||
The `HealthyScope` allows you to define an aggregated health probe for all components in same application.
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
---
|
||||
title: Monitoring
|
||||
---
|
||||
|
||||
TBD, Content Overview：
|
||||
|
||||
1. We will move all installation scripts to a separate doc may be named Install Capability Providers (e.g. https://knative.dev/docs/install/install-extensions/)Install monitoring trait(along with prometheus/grafana controller).
|
||||
2. Add monitoring trait into Application.
|
||||
3. View it with grafana.
|
||||
|
|
@ -2,13 +2,13 @@
|
|||
title: Get More Traits
|
||||
---
|
||||
|
||||
## 1. Refer to [All Trait References](./references) for all other trait types.
|
||||
* Refer to [All Trait References](./references) for all other trait types.
|
||||
|
||||
## 2. Get more from [install addons](../../how-to/cli/addon/addon)
|
||||
* Get more from [install addons](../../how-to/cli/addon/addon)
|
||||
|
||||
## 3. Extend KubeVela by yourself
|
||||
* Extend KubeVela by yourself
|
||||
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
|
||||
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
|
||||
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
|
||||
* [Build your own addons](../../platform-engineers/addon/intro).
|
||||
|
|
@ -4,6 +4,14 @@ title: Built-in Workflow Steps
|
|||
|
||||
This documentation will walk through the built-in workflow steps that you can use to design an application deployment process.
|
||||
|
||||
## deploy
|
||||
|
||||
### Overview
|
||||
|
||||
### Parameter
|
||||
|
||||
### Example
|
||||
|
||||
## apply-application
|
||||
|
||||
### Overview
|
||||
|
|
|
|||
|
|
@ -40,5 +40,4 @@ For learning how to program KubeVela in detail, please check the `Administrator
|
|||
|
||||
## Next Step
|
||||
|
||||
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
|
||||
- View [How To guides](../end-user/components/helm) to check out more features.
|
||||
- View [User Guide](../tutorials/webservice) to look on more of what you can achieve with KubeVela.
|
||||
|
|
|
|||
|
|
@ -37,5 +37,3 @@ Addon is where you can freely pull in third-party capability that fulfills your
|
|||
## Next Step
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
|
||||
- View [How To guides](../end-user/components/helm) to check out more features.
|
||||
|
|
|
|||
|
|
@ -24,14 +24,12 @@ This is why KubeVela appears here. It can simplify the application delivery and
|
|||
|
||||
|
||||
|
||||
We mainly provide two products for different users, they're [KubeVela](./end-user/quick-start-cli) and [VelaUX](./quick-start).
|
||||
|
||||
- Platform builders for PaaS, Serverless, Application Management/Delivery systems
|
||||
- [KubeVela](./end-user/quick-start-cli) works as an application delivery engine that you could build your advanced platform with.
|
||||
- KubeVela works as an application delivery engine that you could build your advanced platform with.
|
||||
- ISV, SaaS owners, and Application Architects who need to distribute software to anywhere
|
||||
- KubeVela has full extension and integration capabilities to allow users to distribute applications with [customized addons](./platform-engineers/addon/intro) easily. Think about an App Store but on Kubernetes and clouds.
|
||||
- Application Developers, Operators, DevOps Engineers
|
||||
- [VelaUX](./quick-start) is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
|
||||
- VelaUX is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
|
||||
|
||||
|
||||
## What's the relationship between OAM, KubeVela and VelaUX?
|
||||
|
|
@ -50,7 +48,7 @@ KubeVela is a CD (Continuous Delivery) control plane that works at downstream of
|
|||
|
||||
If you already adopted GitOps practice in CD section, KubeVela is even easier to fit in as it's fully declarative by design. All KubeVela features including CD workflow and multi-cloud/cluster delivery will be immediately available in your GitOps process by simply putting a KubeVela application YAML inside your configuration repository.
|
||||
|
||||
> Feel free to check the [Best Practices](https://kubevela.io/docs/case-studies/jenkins-cicd) documentation for more details.
|
||||
> Feel free to check the [Best Practices](../tutorials/jenkins) documentation for more details.
|
||||
|
||||
### KubeVela vs. Platform-as-a-Service (PaaS)
|
||||
|
||||
|
|
@ -92,5 +90,3 @@ Welcome onboard and sail Vela!
|
|||
## What's Next
|
||||
|
||||
- Start to [install KubeVela](./install).
|
||||
- Getting started with [KubeVela core application engine](./end-user/quick-start-cli).
|
||||
- Getting started with UI console by using [VelaUX](./quick-start).
|
||||
|
|
|
|||
|
|
@ -1,10 +1,27 @@
|
|||
---
|
||||
title: Install Addon
|
||||
title: Addon management
|
||||
slug: cli/addon/addon
|
||||
---
|
||||
|
||||
You can get more capabilities from KubeVela ecosystem by installing addons.
|
||||
|
||||
## List Addons
|
||||
## Manage the addon via UI
|
||||
|
||||
Users with addon management permissions can enter the addon management page to enable or disable addons.
|
||||
|
||||
|
||||
|
||||
In the addon list, you can get the status of the addon and other info. Click the addon name could open the addon detail page, you can get the version list, definitions provided by the addon, and the readme message.
|
||||
|
||||
|
||||
|
||||
Select a version and deployed clusters, you can click the enable button to install this addon.
|
||||
|
||||
For enabled addons, if no applications to use definitions, you can click the disable button to uninstall it.
|
||||
|
||||
## Manage the addon via CLI
|
||||
|
||||
### List Addons
|
||||
|
||||
By default, the following command lists addons from a default addon registry (https://addons.kubevela.net) maintained by KubeVela team.
|
||||
|
||||
|
|
@ -31,7 +48,7 @@ velaux KubeVela KubeVela User Experience (UX). A
|
|||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
## Install Addon
|
||||
### Install Addon
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
|
|
@ -45,7 +62,7 @@ I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-ui
|
|||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
### Install with specified version
|
||||
#### Install with specified version
|
||||
|
||||
You can choose one special version of this addon by add `--version` flag in this command. eg:
|
||||
|
||||
|
|
@ -61,7 +78,7 @@ vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
|||
|
||||
You can view the new component or trait types added by `vela component` or `vela trait`. You can also find more details about [built-in addon docs](../../../reference/addons/overview).
|
||||
|
||||
## Uninstall Addon
|
||||
### Uninstall Addon
|
||||
|
||||
> Please make sure this addon along with the capabilities is no longer used in any of your applications.
|
||||
|
||||
|
|
@ -70,7 +87,7 @@ $ vela addon disable fluxcd
|
|||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
## List Registry
|
||||
### List Registry
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
|
|
@ -78,21 +95,21 @@ Name Type URL
|
|||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
|
||||
## Add Registry
|
||||
### Add Registry
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
## Delete Registry
|
||||
### Delete Registry
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
## Enable Addon offline
|
||||
### Enable Addon offline
|
||||
|
||||
For some reason, if your cluster network cannot request the official addon registry you can enable an addon with a local dir. eg:
|
||||
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: Overview
|
||||
---
|
||||
|
|
@ -3,6 +3,7 @@ title: View Application Logs
|
|||
description: View an application log by KubeVela dashboard
|
||||
---
|
||||
|
||||
## View logs via UI
|
||||
|
||||
|
||||
|
||||
|
|
@ -10,6 +11,14 @@ You can view the logs of application in the environment tab.
|
|||
|
||||
By default, the logs will refresh every 5s. If your logs didn't have timestamp, you can click the `Show timestamps` to see.
|
||||
|
||||
## View logs via CLI
|
||||
|
||||
```bash
|
||||
vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
Select a workload could view the logs.
|
||||
|
||||
### Next Step
|
||||
|
||||
* [Expose Application for Public Access](./get-application-endpoint)
|
||||
|
|
@ -13,4 +13,5 @@ Manually upgrade or triggered by webhooks will all list here.
|
|||
|
||||
### Next Step
|
||||
|
||||
* [Version control via CLI](../../../end-user/version-control)
|
||||
* [Recycle Application Instance](./recycle-environment)
|
||||
|
|
@ -2,12 +2,18 @@
|
|||
title: View Resources List Created
|
||||
---
|
||||
|
||||
If you want to learn the resources created by the applications, you can click `Check the details` text button, it will provide a window to show the resources.
|
||||
If you want to learn the resources created by the applications, you can open the environment status page.
|
||||
|
||||
|
||||
|
||||
|
||||
There're three kinds of information including `Applied Resources`,`Conditions` and `Component Status`. The `Applied Resources` are all resources created by the applications.
|
||||
|
||||
## View resources via CLI
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
### Next Step
|
||||
|
||||
* [List Application Revision](./get-application-revision)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Connect a kubernetes cluster
|
||||
---
|
||||
|
||||
We support connect and detach the kubernetes cluster.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Detach a kubernetes cluster
|
||||
---
|
||||
|
||||
We support connect and detach the kubernetes cluster.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Edit metadata of kubernetes cluster
|
||||
---
|
||||
|
||||
We support connect and detach the kubernetes cluster.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: Overview
|
||||
---
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Set cluster dashboard
|
||||
---
|
||||
|
||||
We support connect and detach the kubernetes cluster.
|
||||
|
|
@ -4,6 +4,8 @@ title: Manage Targets
|
|||
|
||||
To deploy application components into different places, VelaUX provides **Target** for user to manage their deploy destinations like clusters or namespaces.
|
||||
|
||||
> This document only apply to UI.
|
||||
|
||||
## Cluster
|
||||
|
||||
First, before configuring Target, you need to ensure your clusters have been joined. You can check your clusters in the Cluster page. The **local** cluster represents the cluster that KubeVela control plane is running on. If you have other clusters, you can either connect those clusters directly to KubeVela by providing their KubeConfig, or join clusters from your cloud provider such as Alibaba Cloud.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: Manage Traits
|
||||
description: Manage traits for application
|
||||
draft: true
|
||||
---
|
||||
|
||||
After deploying an application, VelaUX will automatically bind a `scaler` trait to the application. You can update, delete or bind other traits in the dashboard.
|
||||
|
|
@ -25,9 +26,7 @@ Click the gear icon to enter the edit page of the trait. You can set the number
|
|||
|
||||
## Delete traits
|
||||
|
||||
Click the trash icon to delete the trait.
|
||||
|
||||
|
||||
Open the component configuration page, and click the trash icon of the trait to delete.
|
||||
|
||||
## More
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: Manage Workflows
|
||||
description: Manager workflows for application
|
||||
draft: true
|
||||
---
|
||||
|
||||
When an application is created, it is associated with an environment. Each environment is associated with a workflow for deployment. After a workflow is created, there is only one step by default. You can enter workflow editing mode by clicking the `Edit` button.
|
||||
|
|
|
|||
|
|
@ -324,6 +324,8 @@ VelaUX need authentication. Default username is admin and get default password a
|
|||
vela logs -n vela-system --name apiserver addon-velaux | grep "initialized admin username"
|
||||
```
|
||||
|
||||
If there is no password in logs, you can get it from secret with the name `admin` in the `vela-system` namespace.
|
||||
|
||||
## 5. Uninstall
|
||||
|
||||
Before uninstalling kubevela, you must delete all applications and disable all addons.
|
||||
|
|
@ -350,5 +352,4 @@ kubectl get crd |grep oam | awk '{print $1}' | xargs kubectl delete crd
|
|||
|
||||
## Next Step
|
||||
|
||||
- Getting started with [KubeVela core application engine](./end-user/quick-start-cli).
|
||||
- Getting started with UI console by using [VelaUX](./quick-start).
|
||||
- [Deploy your first application](./quick-start).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Custom Installation
|
||||
title: Custom installation and upgrade
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Extend CRD Operator as Component Type
|
||||
draft: true
|
||||
---
|
||||
|
||||
Let's use [OpenKruise](https://github.com/openkruise/kruise) as example of extend CRD as KubeVela Component.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Overview
|
||||
draft: true
|
||||
---
|
||||
|
||||
Cloud services are important components of your application, and KubeVela allows you to provision and consume them in a consistent experience.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Crossplane
|
||||
draft: true
|
||||
---
|
||||
|
||||
In this documentation, we will use Alibaba Cloud's RDS (Relational Database Service), and Alibaba Cloud's OSS (Object Storage System) as examples to show how to enable cloud services as part of the application deployment.
|
||||
|
|
|
|||
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
title: How-to
|
||||
---
|
||||
|
||||
> ⚠️ This usage has been deprecated in version 1.2.x. Please refer to [doc](../../end-user/components/helm) for more info to use helm type component.
|
||||
|
||||
In this section, it will introduce how to declare Helm charts as components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
|
||||
|
||||
## Prerequisite
|
||||
|
||||
* Make sure you have enabled Helm support in the [installation guide](../../install#4-enable-helm-support).
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
Here is an example `ComponentDefinition` about how to use Helm as schematic module.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webapp-chart
|
||||
annotations:
|
||||
definition.oam.dev/description: helm chart for webapp
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
schematic:
|
||||
helm:
|
||||
release:
|
||||
chart:
|
||||
spec:
|
||||
chart: "podinfo"
|
||||
version: "5.1.4"
|
||||
repository:
|
||||
url: "http://oam.dev/catalog/"
|
||||
```
|
||||
|
||||
In detail:
|
||||
- `.spec.workload` is required to indicate the workload type of this Helm based component. Please also check for [known limitations](known-issues?id=workload-type-indicator) if you have multiple workloads packaged in one chart.
|
||||
- `.spec.schematic.helm` contains information of Helm `release` and `repository` which leverages `fluxcd/flux2`.
|
||||
- i.e. the spec of `release` aligns with [`HelmReleaseSpec`](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md) and spec of `repository` aligns with [`HelmRepositorySpec`](https://github.com/fluxcd/source-controller/blob/main/docs/api/source.md#source.toolkit.fluxcd.io/v1beta1.HelmRepository).
|
||||
|
||||
## Declare an `Application`
|
||||
|
||||
Here is an example `Application`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.2"
|
||||
```
|
||||
|
||||
The component `properties` is exactly the [overlay values](https://github.com/captainroy-hy/podinfo/blob/master/charts/podinfo/values.yaml) of the Helm chart.
|
||||
|
||||
Deploy the application and after several minutes (it may take time to fetch Helm chart), you can check the Helm release is installed.
|
||||
```shell
|
||||
helm ls -A
|
||||
```
|
||||
```console
|
||||
myapp-demo-podinfo default 1 2021-03-05 02:02:18.692317102 +0000 UTC deployed podinfo-5.1.4 5.1.4
|
||||
```
|
||||
Check the workload defined in the chart has been created successfully.
|
||||
```shell
|
||||
kubectl get deploy
|
||||
```
|
||||
```console
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
myapp-demo-podinfo 1/1 1 1 66m
|
||||
```
|
||||
|
||||
Check the values (`image.tag = 5.1.2`) from application's `properties` are assigned to the chart.
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
|
||||
```
|
||||
```console
|
||||
"ghcr.io/stefanprodan/podinfo:5.1.2"
|
||||
```
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
---
|
||||
title: Known Limitations
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
Here are some known limitations for using Helm chart as application component.
|
||||
|
||||
### Workload Type Indicator
|
||||
|
||||
Following best practices of microservice, KubeVela recommends only one workload resource present in one Helm chart. Please split your "super" Helm chart into multiple charts (i.e. components). Essentially, KubeVela relies on the `workload` filed in component definition to indicate the workload type it needs to take care, for example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
...
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps.kruise.io/v1alpha1
|
||||
kind: Cloneset
|
||||
```
|
||||
|
||||
Note that KubeVela won't fail if multiple workload types are packaged in one chart, the issue is for further operational behaviors such as rollout, revisions, and traffic management, they can only take effect on the indicated workload type.
|
||||
|
||||
### Always Use Full Qualified Name
|
||||
|
||||
The name of the workload should be templated with [fully qualified application name](https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/pkg/chartutil/create.go#L415) and please do NOT assign any value to `.Values.fullnameOverride`. As a best practice, Helm also highly recommend that new charts should be created via `$ helm create` command so the template names are automatically defined as per this best practice.
|
||||
|
||||
### Control the Application Upgrade
|
||||
|
||||
Changes made to the component `properties` will trigger a Helm release upgrade. This process is handled by Flux v2 Helm controller, hence you can define remediation
|
||||
strategies in the schematic based on [Helm Release
|
||||
documentation](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md#upgraderemediation)
|
||||
and [specification](https://toolkit.fluxcd.io/components/helm/helmreleases/#configuring-failure-remediation)
|
||||
in case failure happens during this upgrade.
|
||||
|
||||
For example:
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webapp-chart
|
||||
spec:
|
||||
...
|
||||
schematic:
|
||||
helm:
|
||||
release:
|
||||
chart:
|
||||
spec:
|
||||
chart: "podinfo"
|
||||
version: "5.1.4"
|
||||
upgrade:
|
||||
remediation:
|
||||
retries: 3
|
||||
remediationStrategy: rollback
|
||||
repository:
|
||||
url: "http://oam.dev/catalog/"
|
||||
|
||||
```
|
||||
|
||||
Though one issue is for now it's hard to get helpful information of a living Helm release to figure out what happened if upgrading failed. We will enhance the observability to help users track the situation of Helm release in application level.
|
||||
|
||||
## Issues
|
||||
|
||||
The known issues will be fixed in following releases.
|
||||
|
||||
### Rollout Strategy
|
||||
|
||||
For now, Helm based components cannot benefit from [rolling update API](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/rollout-design.md#applicationdeployment-workflow). As shown in [this sample](./trait#update-an-applicatiion), if the application is updated, it can only be rollouted directly without canary or blue-green approach.
|
||||
|
||||
### Updating Traits Properties may Also Lead to Pods Restart
|
||||
|
||||
Changes on traits properties may impact the component instance and Pods belonging to this workload instance will restart. In CUE based components this is avoidable as KubeVela has full control on the rendering process of the resources, though in Helm based components it's currently deferred to Flux v2 controller.
|
||||
|
|
@ -1,169 +0,0 @@
|
|||
---
|
||||
title: Attach Traits
|
||||
---
|
||||
|
||||
Traits in KubeVela can be attached to Helm based component seamlessly.
|
||||
|
||||
In this sample application below, we add two traits, [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml)
|
||||
and [virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/helm-module/virtual-group-td.yaml) to a Helm based component.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.2"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 4
|
||||
- type: virtualgroup
|
||||
properties:
|
||||
group: "my-group1"
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
> Note: when use traits with Helm based component, please *make sure the target workload in your Helm chart strictly follows the qualified-full-name convention in Helm.* [For example in this chart](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/deployment.yaml#L4), the workload name is composed of [release name and chart name](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/_helpers.tpl#L13).
|
||||
|
||||
> This is because KubeVela relies on the name to discovery the workload, otherwise it cannot apply traits to the workload. KubeVela will generate a release name based on your `Application` name and component name automatically, so you need to make sure never override the full name template in your Helm chart.
|
||||
|
||||
## Verify traits work correctly
|
||||
|
||||
> You may need to wait a few seconds to check the trait attached because of reconciliation interval.
|
||||
|
||||
Check the `scaler` trait takes effect.
|
||||
```shell
|
||||
kubectl get manualscalertrait
|
||||
```
|
||||
```console
|
||||
NAME AGE
|
||||
demo-podinfo-scaler-d8f78c6fc 13m
|
||||
```
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
|
||||
```
|
||||
```console
|
||||
4
|
||||
```
|
||||
|
||||
Check the `virtualgroup` trait.
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
|
||||
```
|
||||
```console
|
||||
{
|
||||
"app.cluster.virtual.group": "my-group1",
|
||||
"app.kubernetes.io/name": "myapp-demo-podinfo"
|
||||
}
|
||||
```
|
||||
|
||||
## Update Application
|
||||
|
||||
After the application is deployed and workloads/traits are created successfully,
|
||||
you can update the application, and corresponding changes will be applied to the
|
||||
workload instances.
|
||||
|
||||
Let's make several changes on the configuration of the sample application.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
properties:
|
||||
image:
|
||||
tag: "5.1.3" # 5.1.2 => 5.1.3
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 2 # 4 => 2
|
||||
- type: virtualgroup
|
||||
properties:
|
||||
group: "my-group2" # my-group1 => my-group2
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
Apply the new configuration and check the results after several minutes.
|
||||
|
||||
Check the new values (`image.tag = 5.1.3`) from application's `properties` are assigned to the chart.
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
|
||||
```
|
||||
```console
|
||||
"ghcr.io/stefanprodan/podinfo:5.1.3"
|
||||
```
|
||||
Under the hood, Helm makes an upgrade to the release (revision 1 => 2).
|
||||
```shell
|
||||
helm ls -A
|
||||
```
|
||||
```console
|
||||
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
|
||||
myapp-demo-podinfo default 2 2021-03-15 08:52:00.037690148 +0000 UTC deployed podinfo-5.1.4 5.1.4
|
||||
```
|
||||
|
||||
Check the `scaler` trait.
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
|
||||
```
|
||||
```console
|
||||
2
|
||||
```
|
||||
|
||||
Check the `virtualgroup` trait.
|
||||
```shell
|
||||
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
|
||||
```
|
||||
```console
|
||||
{
|
||||
"app.cluster.virtual.group": "my-group2",
|
||||
"app.kubernetes.io/name": "myapp-demo-podinfo"
|
||||
}
|
||||
```
|
||||
|
||||
## Detach Trait
|
||||
|
||||
Let's have a try detach a trait from the application.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: demo-podinfo
|
||||
type: webapp-chart
|
||||
settings:
|
||||
image:
|
||||
tag: "5.1.3"
|
||||
traits:
|
||||
# - name: scaler
|
||||
# properties:
|
||||
# replicas: 2
|
||||
- name: virtualgroup
|
||||
properties:
|
||||
group: "my-group2"
|
||||
type: "cluster"
|
||||
```
|
||||
|
||||
Apply the application and check `manualscalertrait` has been deleted.
|
||||
```shell
|
||||
kubectl get manualscalertrait
|
||||
```
|
||||
```console
|
||||
No resources found
|
||||
```
|
||||
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: 平台环境初始化
|
||||
---
|
||||
|
|
@ -2,7 +2,18 @@
|
|||
title: Managing Clusters
|
||||
---
|
||||
|
||||
Users could manage clusters in KubeVela through a list of Vela CLI commands.
|
||||
## Manage the cluster via UI
|
||||
|
||||
* Support connecting the exist kubernetes cluster.
|
||||
* Support connecting the ACK cluster.
|
||||
|
||||
Users with cluster management permissions can enter the cluster management page to add or detach managed clusters.
|
||||
|
||||
|
||||
|
||||
For connecting the ACK clusters, the platform will save some cloud info, Region, VPC, Dashboard Address, etc. When users use the cluster to create a Target, the cloud information is automatically assigned to the Target, which the cloud service applications can use.
|
||||
|
||||
## Manage the cluster via CLI
|
||||
|
||||
### vela cluster list
|
||||
|
||||
|
|
@ -10,8 +21,9 @@ This command 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
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
ask-beijing X509Certificate https://*.*.*.*:6443 true
|
||||
```
|
||||
|
||||
### vela cluster join
|
||||
|
|
@ -36,4 +48,4 @@ This command can rename cluster managed by KubeVela.
|
|||
|
||||
```shell script
|
||||
$ vela cluster rename cluster-prod cluster-production
|
||||
```
|
||||
```
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
# Air-gapped Installation
|
||||
---
|
||||
title: Air-gapped Installation
|
||||
---
|
||||
|
||||
Air-gapped Installation of KubeVela includes the installation of KubeVela core and addons, they all contain the configuration files and images.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,72 +3,83 @@ title: Deploy First Application
|
|||
---
|
||||
|
||||
> Before starting, please confirm that you've installed KubeVela Core and VelaUX in the control plane cluster based on [Installation](./install.mdx)
|
||||
>
|
||||
> If you want to use KubeVela CLI for application delivery, please check [Deliver First Application](./end-user/quick-start-cli) in the Vela CLI manual.
|
||||
|
||||
Welcome to KubeVela! In this section, we show you how to deliver your first app via VelaUX.
|
||||
Welcome to KubeVela! In this section, we show you how to deliver your first app.
|
||||
|
||||
Follow these steps:
|
||||
## Deploy a simple application via CLI
|
||||
|
||||
1. Prepare a Docker image. we use [crccheck/hello-world](https://hub.docker.com/r/crccheck/hello-world) for this time. Double-check if you're able to download it properly.
|
||||
2. Create the first `Application` of `webservice` which is the common way to deploy stateless service.
|
||||
3. Check out the status of the Application's instance.
|
||||
A simple deployment definition in KubeVela looks as below:
|
||||
|
||||
You'll get to know:
|
||||
|
||||
- Get familiar with core concepts as [Application](./getting-started/core-concept#application), [Environment](getting-started/core-concept#environment) and [Target](getting-started/core-concept#target)
|
||||
- Finished an application delivery by operating VelaUX
|
||||
|
||||
## Get password and login
|
||||
|
||||
After install VelaUX, you need to log in. Default username is "admin" and you can get the password using command below
|
||||
```shell
|
||||
vela logs -n vela-system --name apiserver addon-velaux | grep "initialized admin username"
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
# YAML begins
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
ports:
|
||||
- port: 8000
|
||||
expose: true
|
||||
# YAML ends
|
||||
EOF
|
||||
```
|
||||
|
||||
If there is no password in logs, you can get it from secret with the name `admin` in the `vela-system` namespace.
|
||||
This command will deploy a web service component to target environment, which in our case is the Kubernetes cluster that KubeVela itself is installed.
|
||||
|
||||
|
||||
```
|
||||
$ vela port-forward first-vela-app 8000:8000
|
||||
<xmp>
|
||||
Hello World
|
||||
|
||||
## Choosing deployment type and Environment
|
||||
|
||||
After login, the first page you enter is for managing the app:
|
||||
## .
|
||||
## ## ## ==
|
||||
## ## ## ## ## ===
|
||||
/""""""""""""""""\___/ ===
|
||||
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
|
||||
\______ o _,/
|
||||
\ \ _,'
|
||||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
|
||||
|
||||
Great! You have finished deploying your first KubeVela application, the simplest component can only have one component, the rest fields are all optional including trait, policies and workflow.
|
||||
|
||||
> Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
|
||||
## Deploy a simple application via UI
|
||||
|
||||
After logging into the UI, the first page you enter is for managing the applications:
|
||||
|
||||
Then click the button of `New Application` on the upper-right, type in these things:
|
||||
|
||||
1. Name and other basic Infos.
|
||||
<!-- 2. Choose the Project. We've created a default Project for you to use or you can click `New` to create your own. -->
|
||||
2. Choose the deployment type. In this case, we use `webservice` to deploy Stateless Application.
|
||||
3. Choose your environment. We select the `Default` Environment based on the `Default` Target.
|
||||
2. Choose the Project. We've created a default Project for you to use or you can click `New` to create your own.
|
||||
3. Choose the main component type. In this case, we use `webservice` to deploy Stateless Application.
|
||||
4. Choose your environment. We select the `Default` Environment based on the `Default` Target.
|
||||
|
||||
|
||||
|
||||
## Setting up properties
|
||||
### Setting up properties
|
||||
|
||||
Next step, we see the page of properties. Configure following:
|
||||
|
||||
- Image address `crccheck/hello-world`
|
||||
|
||||
> Other properties can be left blank for this case
|
||||
|
||||
|
||||
|
||||
Confirmed. Notice that this application is only created but not deployed yet. VelaUX default generates [Workflow](./getting-started/core-concept#workflow) and a scaler [Trait](./getting-started/core-concept#trait).
|
||||
|
||||
Confirmed. Notice that this application is only created but not deployed yet. VelaUX defaultly generates [Workflow](./getting-started/core-concept#workflow) and replicas of [Trait](./getting-started/core-concept#trait).
|
||||
|
||||
|
||||
|
||||
## Executing Workflow to deploy
|
||||
### Executing Workflow to deploy
|
||||
|
||||
Click the deploy button on the upper-right. When the workflow is finished, you'll get to see the list of status lying within.
|
||||
|
||||
|
||||
|
||||
In the process of deploying, you can click `Check the details` to view the status of the application:
|
||||
|
||||
|
||||
|
||||
## Deleting Application
|
||||
|
||||
If you want to delete the application when it's no longer used, simply:
|
||||
|
|
@ -80,5 +91,5 @@ That's it! You succeed at the first application delivery. Congratulation!
|
|||
|
||||
## Next Step
|
||||
|
||||
- View [Tutorials](./tutorials/webservice) to look on more of what you can achieve with KubeVela.
|
||||
- View [How To guides](./how-to/dashboard/application/create-application) to check out more features.
|
||||
- View [Core Concepts](./getting-started/core-concept) to look on more concepts.
|
||||
- View [User Guide](./tutorials/webservice) to look on more of what you can achieve with KubeVela.
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ Starting from here, you will learn to use the KubeVela Addons to install plug-in
|
|||
|
||||
- Choose a Helm Chart you needed. Or in this case, we take [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) as an example.
|
||||
- Ensure that the cluster you deliver has a usable default StorageClass. Most of our delivery middleware requires data persistence, and the default StorageClass is needed to allocate PV.
|
||||
- Enable the VelaUX addon, If you are only CLI users, go to [Deploy via CLI](#deploy-via-cli)
|
||||
|
||||
## Enable fluxcd addon
|
||||
|
||||
|
|
@ -31,6 +32,12 @@ We can click the `Enable` button. After the fluxcd addon is enabled, it will be
|
|||
|
||||
When the addon is `enabled`, it means that it's ready to. You can start to deploy Helm Chart.
|
||||
|
||||
You can also enable the addon via CLI:
|
||||
|
||||
```shell
|
||||
vale addon enable fluxcd
|
||||
```
|
||||
|
||||
## Creating Redis application
|
||||
|
||||
You've must have mastered creating applications through the previous sections. When it comes to creating Redis with Helm Chart, all you need is to select type as `helm`, Then select the Target which has the default StorageClass that provides PV, and at last enter the deployment parameter configuration page.
|
||||
|
|
@ -41,21 +48,83 @@ As shown, you need to do the following configuration:
|
|||
|
||||
- Repo Type: Git and Helm are supported. In this example, we choose Helm.
|
||||
- Repo URL: Fill in the repo address you needed. we type in: https://charts.bitnami.com/bitnami. If you have configured the helm repo in [Integration](../how-to/dashboard/config/helm-repo) you can choose the repo directly.
|
||||
- Chart: After fill Helm repo URL, will list all available chart in this field. You can choose one from the list, here we choose: redis.
|
||||
- Version: After choose the helm chart, will list all available version of it. Choose one version of this chart, here we choose: 16.8.5.
|
||||
- Values: Custom parameters of Chart. Since we are using ACK cluster in the example, PV has a minimum capacity requirement, 15Gi. In the same way, other parameters can also be configured according to your cluster's status.
|
||||
- Chart: After fill Helm repo URL, will list all available charts in this field. You can choose one from the list, here we choose: redis.
|
||||
- Version: After choose the helm chart, will list all available versions in this field. Choose one version of this chart, here we choose: 16.8.5.
|
||||
- Values: After choose the version, will list all parameters of this helm Chart. Since we are using ACK cluster in the example, PV has a minimum capacity requirement, 15Gi. In the same way, other parameters can also be configured according to your cluster's status.
|
||||
|
||||
After filling in the above parameters, click `Create` to complete the application creation and enter the application configuration page. The following steps will stay the same as you've learned in [Deploy First Application](../quick-start).
|
||||
|
||||
## Modify deployment parameters
|
||||
|
||||
Here we're unlocking new skills! Modify the parameters of the application. For any type of application, he can enter the application configuration page at any time by clicking the `Edit Properties` button at the top right of the `Baseline Config` page. This page is the same as the page when we created the application. It is automatically generated by combining the parameters defined by the Definition of each application type and the KubeVela UISchema specification.
|
||||
Clicking the component name, you can open the component configuration page. For the Helm Chart component, we can set the Values configuration options to change the application deployment parameters. the Values configuration options are generated by `values.yaml`, you can set the custom value for every option.
|
||||
|
||||
After modifying the deployment parameters, the workflow of the environment must be executed to make the modified parameters take effect in the specified environment. Due to the existence of Revision, the configuration parameters will be saved in each historical version.
|
||||
|
||||
## Deploy via CLI
|
||||
|
||||
You can also create the application with helm component via CLI:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: helm-redis
|
||||
spec:
|
||||
components:
|
||||
- name: redis
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://charts.bitnami.com/bitnami"
|
||||
chart: "redis"
|
||||
version: "16.8.5"
|
||||
values:
|
||||
master.persistence.size: 16Gi
|
||||
replica.persistence.size: 16Gi
|
||||
```
|
||||
|
||||
Deploy this application：
|
||||
|
||||
```shell
|
||||
vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
|
||||
```
|
||||
|
||||
> Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
|
||||
Next, check the deployment status of the application through `vela status helm-redis`
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: helm-redis
|
||||
Namespace: default
|
||||
Created at: 2022-04-21 17:19:12 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:n1gxswwina
|
||||
name:redis
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: redis
|
||||
Cluster: local Namespace: default
|
||||
Type: helm
|
||||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
|
||||
At this point, Helm Chart in KubeVela is no stranger to you, go ahead and try more!
|
||||
|
||||
<!--
|
||||
## Next step
|
||||
TODO v1.2
|
||||
- [Deploy Cloud Services](./consume-cloud-services) -->
|
||||
|
||||
- [Deploy Kubernetes Objects](./k8s-object)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Working with Jenkins
|
||||
title: Integrating with Jenkins
|
||||
---
|
||||
|
||||
### Introduction
|
||||
|
|
@ -13,7 +13,7 @@ In this section, we will demonstrate how to integrate KubeVela with Jenkins in d
|
|||
### Prerequisite
|
||||
|
||||
The following requirements are needed to be ensured before starting this tutorial
|
||||
- KubeVela v1.2.0 with VelaUX installed.
|
||||
- KubeVela v1.2.0+ with VelaUX installed.
|
||||
- Jenkins installed.
|
||||
- VelaUX can be accessed by Jenkins. (If KubeVela is installed in an offline environment, you need to check this condition.)
|
||||
|
||||
|
|
|
|||
|
|
@ -85,12 +85,114 @@ If continued, the deployment goes on. In the list of instances, you can check ou
|
|||
|
||||
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
## Deploy kubernetes objects via CLI.
|
||||
|
||||
<!-- ## Video tutorial TODO v1.2 -->
|
||||
This is a demo application with a kubernetes objects, the most kubernetes app are consists of Deployment and Service.
|
||||
There are two policies and three workflow steps, this means deploying the app to two namespaces and waiting for human review after the first step is successful.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-with-k8s-objects
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: k8s-demo-service
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
strategy:
|
||||
type: Recreate
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-type: nlb
|
||||
labels:
|
||||
app: nginx
|
||||
name: nginx
|
||||
namespace: default
|
||||
spec:
|
||||
externalTrafficPolicy: Local
|
||||
ports:
|
||||
- name: http
|
||||
port: 80
|
||||
protocol: TCP
|
||||
targetPort: 80
|
||||
selector:
|
||||
app: nginx
|
||||
type: LoadBalancer
|
||||
type: k8s-objects
|
||||
policies:
|
||||
- name: topology-default
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ['local']
|
||||
namespace: default
|
||||
- name: topology-production
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ['local']
|
||||
namespace: production
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2default
|
||||
properties:
|
||||
policies: ['topology-default']
|
||||
type: deploy
|
||||
- name: suspend
|
||||
type: suspend
|
||||
- name: deploy2production
|
||||
properties:
|
||||
policies: ['topology-production']
|
||||
type: deploy
|
||||
```
|
||||
|
||||
- About the topology policy, refence: [Topology](../end-user/policies/references#override)
|
||||
- About the deploy workflow step, refence: [Deploy](../end-user/workflow/built-in-workflow-defs#deploy)
|
||||
|
||||
Deploy this application by the following command:
|
||||
|
||||
- create the namespace with the name `production` before deploying the application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
```
|
||||
|
||||
- deploy the demo application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
```
|
||||
|
||||
- review and resume the workflow after the workflow becomes suspended.
|
||||
|
||||
```shell
|
||||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
## Next step
|
||||
|
||||
<!-- 1. [Getting into more of Workflow](./multi-cluster) TODO v1.2 -->
|
||||
|
||||
- [Deploy Helm Chart](./helm)
|
||||
- [Deploy Cloud Service](./consume-cloud-services)
|
||||
- [Distributed External Kubernetes Objects](../end-user/components/ref-objects)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Continuous Delivery from Image Registry
|
||||
title: Integrating with Image registries
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
|
|
|||
|
|
@ -8,33 +8,26 @@ This article introduces how companies deliver business applications based on Kub
|
|||
## Before starting
|
||||
|
||||
- Containerize your business. No matter what language you're using, first to build an image via CI or locally.
|
||||
|
||||
> In the future, KubeVela plans to provide the image-build-up solution for multi-langs
|
||||
|
||||
- Place your business image at a hub that KubeVela can access to
|
||||
- Make it clear what environment variables your business needs to set, and whether there are other middleware dependencies (such as databases, caches, etc.). If so, please deploy the middleware service first.
|
||||
- Place your business image at a hub that KubeVela can access to.
|
||||
- Enable the VelaUX addon, If you are only CLI users, go to [Deploy via CLI](#deploy-via-cli)
|
||||
|
||||
## Creating an application
|
||||
|
||||
Enter the page of Application on the left, click `New Application` to create. Pick your name, alias, and description; Select type of `webservice`; Decide your environment, Default ENV is already available in the first place. You could also enter the page of Envs to set up new.
|
||||
Enter the page of Application on the left, click `New Application` to create. Pick your name, alias, and description; Select type of `webservice`; Decide your environment, Default environment is already available in the first place. You could also enter the page of Environments to set up new.
|
||||
|
||||
|
||||
Click `Next Step` so to the configuration page. We need to set up the Image address and resources limit. If you want to set up a command for the image, open up the row `CMD`.
|
||||
|
||||
Click `Next Step` so to the configuration page. We need to set up the Image address. If you want to set up a command for the image, open up the row `CMD`. Also, set up Environment Variable in `ENV`.
|
||||
|
||||
|
||||
|
||||
As the screenshot shows, we're deploying a `Wordpress` app, filling in the name and setting up four Environment Variables. Ensure to have the right address of your database.
|
||||
|
||||
|
||||
Done by clicking `Create` and then we enter the management page.
|
||||
|
||||
## Deploying the application
|
||||
|
||||
Click the `Deploy` button on the upper right, it executes the default Workflow. Note that each Environment of the application has its workflow. On the right of the `Baseline Config` tab is the environments. Check out the status of the environment and its instance information as you wish.
|
||||
Click the `Deploy` button on the upper right and select a workflow. Note that each Environment of the application has its workflow. On the right of the `Baseline Config` tab is the environments. Check out the status of the environment and its instance information as you wish.
|
||||
|
||||
|
||||
|
||||
When it has several Targets in this ENV, you may find them all in the `Instances` list. If you want to look at the process of application deployment, click `Check the details` to reveal.
|
||||
When it has several targets in this environment, you may find them all in the `Instances` list. If you want to look at the process of application deployment, click `Check the details` to reveal.
|
||||
|
||||
In the `Instances` list, you may find some of them are in pending status. Click `+` in the beginning to figure out the reason in more detail.
|
||||
|
||||
|
|
@ -42,11 +35,11 @@ In the `Instances` list, you may find some of them are in pending status. Click
|
|||
|
||||
After the first deployment, our business keeps evolving and the following updates come along.
|
||||
|
||||
Click `Baseline Config` and you can see the button `Edit Properties` on the right. Then again we're on the configuration page to update your latest requirements for image, version, and environment variable.
|
||||
Click `Baseline Config` and you can see the all components. Then click the component name and open the configuration page, you can update your latest requirements for image, version, and environment variable.
|
||||
|
||||
## Update replicas
|
||||
|
||||
If your business requires more than one replicas, enter the `Properties` page. By default, you have a `Set Replicas` trait. Click the gear so that you can update the replicas.
|
||||
If your business requires more than one replicas, enter the `Properties` page. By default, The component have a `Set Replicas` trait. Click it so that you can update the replicas.
|
||||
|
||||
|
||||
|
||||
|
|
@ -64,6 +57,75 @@ After all of the environments have been recycled, the application can be deleted
|
|||
|
||||
At this point, you have basically mastered the deployment method of Docker image.
|
||||
|
||||
## Deploy via CLI
|
||||
|
||||
You also can deploy the application via CLI.
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
# YAML begins
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webservice-app
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
ports:
|
||||
- port: 8080
|
||||
expose: true
|
||||
exposeType: LoadBalancer
|
||||
cpu: "0.5"
|
||||
memory: "512Mi"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
# YAML ends
|
||||
EOF
|
||||
```
|
||||
|
||||
> Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
|
||||
You can also save the YAML file as webservice-app.yaml and use the `vela up -f webservice-app.yaml` command to deploy.
|
||||
|
||||
Next, check the deployment status of the application through `vela status webservice-app`
|
||||
|
||||
```
|
||||
About:
|
||||
|
||||
Name: test-app
|
||||
Namespace: default
|
||||
Created at: 2022-04-21 12:03:42 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:y4n26n7uql
|
||||
name:frontend
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: frontend
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:1/1
|
||||
Traits:
|
||||
✅ scaler
|
||||
```
|
||||
|
||||
## Next Step
|
||||
|
||||
[Learn to deploy Helm Chart](./helm)
|
||||
|
|
|
|||
|
|
@ -5,92 +5,93 @@
|
|||
"id": "version-v1.3/getting-started/introduction"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/install"
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "Getting Started",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/install"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/quick-start"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/getting-started/core-concept"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/getting-started/architecture"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "Vela-Core",
|
||||
"label": "User Guide",
|
||||
"items": [
|
||||
{
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "Getting Started",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/quick-start-cli"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/case-studies/multi-cluster"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/case-studies/gitops"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/case-studies/initialize-env"
|
||||
}
|
||||
]
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/webservice"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/helm"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/k8s-object"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/consume-cloud-services"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Basics",
|
||||
"label": "Deploy with more workload type",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/getting-started/core-concept"
|
||||
"id": "version-v1.3/end-user/components/cue/task"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/getting-started/architecture"
|
||||
"id": "version-v1.3/end-user/components/kustomize"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/ref-objects"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/more"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/case-studies/multi-cluster"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/jenkins"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/trigger"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/case-studies/gitops"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "How-to Guides",
|
||||
"items": [
|
||||
{
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "Deploy Components",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/helm"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/cue/webservice"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/cue/task"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/cue/raw"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/kustomize"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/ref-objects"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/components/more"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
|
|
@ -117,144 +118,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Multi-Cluster Delivery",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/managing-clusters"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/ingress"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/service-binding"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/sidecar"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/health"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/workflow/webhook-notification"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Day-2 Operations",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/rollout"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/more"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Advanced Features",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/workflow/component-dependency-parameter"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/version-control"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/apply-once"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/gc"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "VelaUX",
|
||||
"items": [
|
||||
{
|
||||
"collapsed": false,
|
||||
"type": "category",
|
||||
"label": "Getting Started",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/quick-start"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/webservice"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/helm"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/consume-cloud-services"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/k8s-object"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/jenkins"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/trigger"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/workflows"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/sso"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Basics",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/getting-started/velaux-concept"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "How-to Guides",
|
||||
"items": [
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage applications",
|
||||
"label": "Deploy applications",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -264,6 +128,10 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/application/bind-new-environment"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/tutorials/workflows"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/application/deploy-application"
|
||||
|
|
@ -305,59 +173,46 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage workflows",
|
||||
"label": "Day-2 Operations",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/workflow/overview"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage traits",
|
||||
"items": [
|
||||
"id": "version-v1.3/end-user/traits/rollout"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/trait/overview"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage triggers",
|
||||
"items": [
|
||||
"id": "version-v1.3/end-user/traits/ingress"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/service-binding"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/traits/sidecar"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/health"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/workflow/webhook-notification"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/service-account-integration"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/trigger/overview"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage resource",
|
||||
"items": [
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/target/overview"
|
||||
"id": "version-v1.3/end-user/traits/more"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/user/user"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/user/rbac"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/user/project"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
|
|
@ -374,142 +229,32 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/addon/overview"
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Advanced Features",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/workflow/component-dependency-parameter"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/version-control"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/apply-once"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/policies/gc"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"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",
|
||||
"label": "Learning CUE",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/basic"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/definition-edit"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/advanced"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Addons",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/cli/addon/addon"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/addon/intro"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/components/custom-component"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Cloud Resources",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/addon/terraform"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/components/component-terraform"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Traits System",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/customize-trait"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/patch-trait"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/status"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/advanced"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Workflow System",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/workflow"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/cue-actions"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/working-mechanism"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/velaql"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/debug/dry-run"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/x-def-version"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
|
|
@ -517,15 +262,57 @@
|
|||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/bootstrap-parameters"
|
||||
"id": "version-v1.3/tutorials/sso"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/end-user/service-account-integration"
|
||||
"id": "version-v1.3/how-to/dashboard/user/user"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/offline-installation"
|
||||
"id": "version-v1.3/how-to/dashboard/user/rbac"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/user/project"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Manage resource",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/managing-clusters"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/dashboard/target/overview"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/how-to/addon"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Install or upgrade",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/bootstrap-parameters"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/advanced-install"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/offline-installation"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -534,6 +321,131 @@
|
|||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/performance-finetuning"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"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",
|
||||
"label": "Learning CUE",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/basic"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/definition-edit"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/cue/advanced"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Addons",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/addon/intro"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/components/custom-component"
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Cloud Resources",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/addon/terraform"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/components/component-terraform"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Traits System",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/customize-trait"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/patch-trait"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/status"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/traits/advanced"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Workflow System",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/workflow"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/cue-actions"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/workflow/working-mechanism"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/system-operation/velaql"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/debug/dry-run"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.3/platform-engineers/x-def-version"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue