refine gitops and workflow (#773)
* refine docs for gitops Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com> * refine gitops and workflow Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
f4f9f927a0
commit
6b35d2ed1b
|
|
@ -1,410 +1,25 @@
|
|||
---
|
||||
title: FluxCD
|
||||
title: Overview
|
||||
---
|
||||
|
||||
This section will introduce how to use KubeVela in GitOps environment and why.
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
|
||||
> This section is only apply to CLI, you need to enable the [FluxCD](../reference/addons/fluxcd) addon.
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with "git-centric" operations such as PR and commit. For detailed benefits of GitOps, you can refer to [this blog](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
## Introduction
|
||||
KubeVela as a declarative application delivery control plane can be naturally used in GitOps approach, and this will provide below extra bonus to end users alongside with GitOps benefits:
|
||||
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with Git-centric operations such as PR and commit. For detailed benefits of GitOps, please check [this article](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
KubeVela as an declarative application delivery control plane can be naturally used in GitOps approach, and this will provide below extra bonus to end users alongside with GitOps benefits:
|
||||
- application delivery workflow (CD pipeline)
|
||||
- i.e. KubeVela supports pipeline style application delivery process in GitOps, instead of simply declaring final status;
|
||||
- handling deployment dependencies and designing typologies (DAG);
|
||||
- unified higher level abstraction atop various GitOps tools' primitives;
|
||||
- declare, provision and consume cloud resources in unified application definition;
|
||||
- handling deployment [dependencies and designing typologies (DAG)](../end-user/workflow/component-dependency-parameter);
|
||||
- [unified higher level abstraction](../getting-started/core-concept) atop various GitOps tools' primitives;
|
||||
- declare, provision and consume [cloud resources](../tutorials/consume-cloud-services) in unified application definition;
|
||||
- various out-of-box deployment strategies (Canary, Blue-Green ...);
|
||||
- various out-of-box hybrid/multi-cloud deployment policies (placement rule, cluster selectors etc.);
|
||||
- Kustomize-style patch for multi-env deployment without the need to learn Kustomize at all;
|
||||
- ... and much more.
|
||||
|
||||
In this section, we will introduce steps of using KubeVela directly in GitOps approach.
|
||||
In the following sections, we will introduce steps of using KubeVela directly in GitOps approach. You can choose any of the following addons for the whole GitOps process:
|
||||
|
||||
This article will separate into two perspectives:
|
||||
- [GitOps with FluxCD](../end-user/gitops/fluxcd)
|
||||
|
||||
1. For platform administrators/SREs, they can update the config in Git repo. It will trigger automated re-deployment.
|
||||
|
||||
2. For developers, they can update the app source code and then push it to Git. It will trigger building latest image and re-deployment.
|
||||
|
||||
> Note: you can also use it with existing tools such as ArgoCD with similar steps, detailed guides will be added in following releases.
|
||||
|
||||
## For platform administrators/SREs
|
||||
|
||||
Platform administrators/SREs prepares the Git repo for operational config. Every config change will be traceable by that. KubeVela will watch the repo and apply changes to the clusters.
|
||||
|
||||
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
> The configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs).
|
||||
|
||||
In this example, we will deploy an application and a database, the application uses the database to store data.
|
||||
|
||||
The structure of the config repository looks below:
|
||||
|
||||
* The `clusters/` contains the GitOps config. It will command KubeVela to watch the specified repo and apply latest changes.
|
||||
* The `apps/` contains the Application yaml for deploying the user-facing app.
|
||||
* The `infrastructure/` contains infrastructure tools, i.e. MySQL database.
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela recommends using the directory structure above to manage your GitOps repository. `clusters/` holds the associated KubeVela GitOps configuration that need to be applied to cluster manually, `apps/` holds your application and `infrastructure/` holds your base configuration. By separating applications from basic configurations, you can manage your deployment environment more reasonably and isolate application changes.
|
||||
|
||||
#### Directory `clusters/`
|
||||
|
||||
The `clusters/` is the initialize configuration directory for KubeVela GitOps.
|
||||
|
||||
Below is how the `clusters/infra.yaml` looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# replace it with your repo url
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# replace it with your git secret if it's a private repo
|
||||
# secretRef: git-secret
|
||||
# the pull interval time, set to 10m since the infrastructure is steady
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# the branch name
|
||||
branch: main
|
||||
# the path to sync
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` and `infra.yaml` in `clusters/` are similar. Their difference is to watch different directories. In `apps.yaml`, the `properties.path` will be `./apps`.
|
||||
|
||||
Apply the files in `clusters/` manually. They will sync the files in `infrastructure/` and `apps/` dir of the Git repo.
|
||||
|
||||
#### Directory `apps/`
|
||||
|
||||
The file in `apps/` is a simple application with database information and Ingress. The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: <your image address> # {"$imagepolicy": "default:apps"}
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### Directory `infrastructure/`
|
||||
|
||||
The `infrastructure/` contains the config of some infrastructures like database. In the following, we will use [MySQL operator](https://github.com/bitpoke/mysql-operator) to deploy a MySQL cluster.
|
||||
|
||||
> Notice that there must be a secret in your cluster with MySQL password specified in key `ROOT_PASSWORD`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# replace it with your secret
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### Apply the files in `clusters/`
|
||||
|
||||
After storing bellow files in the Git config repo, we need to apply the GitOps config files in `clusters/` manually.
|
||||
|
||||
First, apply the `clusters/infra.yaml` to cluster, we can see that the MySQL in `infrastructure/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
Apply the `clusters/apps.yaml` to cluster, we can see that the application in `apps/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
By deploying the KubeVela GitOps config files, we now automatically apply the application and database in cluster.
|
||||
|
||||
`curl` the Ingress of the app, we can see that the current version is `0.1.5` and the application is connected to the database successfully:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
## Modify the config for GitOps trigger
|
||||
|
||||
After the first deployment, we can modify the files in config repo to update the applications in the cluster.
|
||||
|
||||
Modify the domain of the application's Ingress:
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
Check the Ingress in cluster after a while:
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
The host of the Ingress has been updated successfully!
|
||||
|
||||
In this way, we can edit the files in the Git repo to update the cluster.
|
||||
|
||||
## For developers
|
||||
|
||||
Developers writes the application source code and push it to a Git repo (aka app repo). Once app repo updates, the CI will build the image and push it to the image registry. KubeVela watches the image registry, and updates the image in config repo. Finally, it will apply the config to the cluster.
|
||||
|
||||
User can update the configuration in the cluster automatically when the code is updated.
|
||||
|
||||
|
||||
|
||||
### Setup App Code Repository
|
||||
|
||||
Setup a Git repository with source code and Dockerfile.
|
||||
|
||||
The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
In this tutorial, we will setup a CI pipeline using GitHub Actions to build the image and push it to a registry. The code and configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code).
|
||||
|
||||
## Create Git Secret for KubeVela committing to Config Repo
|
||||
|
||||
After the new image is pushed to the image registry, KubeVela will be notified and update the `Application` file in the Git repository and cluster. Therefore, we need a secret with Git information for KubeVela to commit to the Git repository. Fill the following yaml files with your password and apply it to the cluster:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: my-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
The configuration repository is almost the same as the previous configuration, you only need to add the image registry config to the file. For more details, please refer to [Example Repository](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config).
|
||||
|
||||
Add the config of image registry in `clusters/apps.yaml`, it listens for image updates in the image registry:
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
image: <your image>
|
||||
# if it's a private image registry, use `kubectl create secret docker-registry` to create the secret
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# filter the image tag
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# use the policy to sort the latest image tag and update
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# add more commit message
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
Modify the image field in `apps/my-app.yaml` and add annotation `# {"$imagepolicy": "default:apps"}`.
|
||||
Notice that KubeVela will only be able to modify the image field if the annotation is added after the field. `default:apps` is `namespace:name` of the GitOps config file above.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
After update the files in `clusters/` to cluster, we can then update the application by modifying the code.
|
||||
|
||||
## Modify the code
|
||||
|
||||
Change the `Version` to `0.1.6` and modify the data in database:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Commit the change to the Git Repository, we can see that our CI pipelines has built the image and push it to the image registry.
|
||||
|
||||
KubeVela will listen to the image registry and update the `apps/my-app.yaml` in Git Repository with the latest image tag.
|
||||
|
||||
We can see that there is a commit form `kubevelabot`, the commit message is always with a prefix `Update image automatically.` You can use format like `{{range .Updated.Images}}{{println .}}{{end}}` to specify the image name in the `commitMessage` field.
|
||||
|
||||
|
||||
|
||||
> Note that if you want to put the code and config in the same repository, you need to filter out the commit from KubeVela in CI configuration like below to avoid the repeat build of pipeline.
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
Re-check the `Application` in cluster, we can see that the image of the `my-app` has been updated after a while.
|
||||
|
||||
> KubeVela polls the latest information from the code and image repo periodically (at an interval that can be customized):
|
||||
> * When the `Application` file in the Git repository is updated, KubeVela will update the `Application` in the cluster based on the latest configuration.
|
||||
> * When a new tag is added to the image registry, KubeVela will filter out the latest tag based on your policy and update it to Git repository. When the files in the repository are updated, KubeVela repeats the first step and updates the files in the cluster, thus achieving automatic deployment.
|
||||
|
||||
We can `curl` to `Ingress` to see the current version and data:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
The `Version` has been updated successfully! Now we're done with everything from changing the code to automatically applying to the cluster.
|
||||
|
||||
## Summary
|
||||
|
||||
For platform admins/SREs, they update the config repo to operate the application and infrastructure. KubeVela will synchronize the config to the cluster, simplifying the deployment process.
|
||||
|
||||
For end users/developers, they write the source code, push it to Git, and then re-deployment will happen. It will make CI to build the image. KubeVela will then update the image field and apply the deployment config.
|
||||
|
||||
By integrating with GitOps, KubeVela helps users speed up deployment and simplify continuous deployment.
|
||||
Besides these addons, the end user can use any GitOps tools they want to watch the Git repo for KubeVela applications as configuration.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Introduction
|
||||
title: Overview
|
||||
---
|
||||
|
||||
The developer guide including two parts:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ There're many out-of-box capabilities installed along with KubeVela controller,
|
|||
- [Built-in Policy Reference](../policies/references)
|
||||
- [Built-in Workflow Step Reference](../workflow/built-in-workflow-defs)
|
||||
|
||||
## Manage Addons
|
||||
## Extend by Managing Addons
|
||||
|
||||
Installing addon from the community is also one of the most important way to discover more capabilities.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Addon: velaux enabled Successfully
|
|||
|
||||
Please notice that, while an addon installing cluster maybe still need pull some images or helm charts.If your cluster cannot reach these resources please refer [docs](../../platform-engineers/system-operation/enable-addon-offline) to do complete installation without internet.
|
||||
|
||||
### Manage the addon with VelaUX
|
||||
### Manage the addon with UI Console
|
||||
|
||||
If you have installed [VelaUX](../../reference/addons/velaux) which is also one of the addon, you can manage it directly on the UI console with admin privileges.
|
||||
|
||||
|
|
@ -194,11 +194,13 @@ In the addon list, you can get the status of the addon and other info. Click the
|
|||
|
||||
|
||||
|
||||
Select a version and deployed clusters, you can click the enable button to install this addon.
|
||||
Select a version and deployed clusters, you can click the enable button to install this addon. You can check detail information in this section include:
|
||||
|
||||
- Definitions: The extension capabilities provided by the addon may include component, trait, etc.
|
||||
- README: Addon description, explain the capabilities and related information.
|
||||
|
||||
For enabled addons, if no applications to use definitions, you can click the disable button to uninstall it.
|
||||
|
||||
|
||||
### Make your own addon
|
||||
|
||||
If you're a system infra or operator, you can refer to extension documents to learn how to [make your own addon and registry](../../platform-engineers/addon/intro), including [extend cloud resources by addon](../../platform-engineers/addon/terraform).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,391 @@
|
|||
---
|
||||
title: GitOps with FluxCD
|
||||
---
|
||||
|
||||
> You need to enable the [fluxcd](../../reference/addons/fluxcd) addon.
|
||||
|
||||
As a best practice, this article will separate into two perspectives simulating to the real scenarios:
|
||||
|
||||
1. For platform administrators/SREs, they can update the config in Git repo. It will trigger automated re-deployment.
|
||||
|
||||
2. For developers, they can update the app source code and then push it to Git. It will trigger building latest image and re-deployment.
|
||||
|
||||
## For platform administrators/SREs
|
||||
|
||||
Platform administrators/SREs prepares the Git repo for operational config. There will have a gitops agent watch the git server events, every changes of the configuration will be traceable by that.
|
||||
|
||||
In this scenario, KubeVela will watch the repo and apply changes to the clusters.
|
||||
|
||||
|
||||
|
||||
### Setup Config Repository to watch
|
||||
|
||||
> The configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs).
|
||||
|
||||
In this example, we will deploy an application and a database, the application uses the database to store data.
|
||||
|
||||
The structure of the config repository looks below:
|
||||
|
||||
* The `clusters/` contains the GitOps config. It will command KubeVela to watch the specified repo and apply latest changes.
|
||||
* The `apps/` contains the Application yaml for deploying the user-facing app.
|
||||
* The `infrastructure/` contains infrastructure tools, i.e. MySQL database.
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela recommends using the directory structure above to manage your GitOps repository. `clusters/` holds the associated KubeVela GitOps configuration that need to be applied to cluster manually, `apps/` holds your application and `infrastructure/` holds your base configuration. By separating applications from basic configurations, you can manage your deployment environment more reasonably and isolate application changes.
|
||||
|
||||
#### Directory `clusters/`
|
||||
|
||||
The `clusters/` is the initialize configuration directory for KubeVela GitOps.
|
||||
|
||||
Below is how the `clusters/infra.yaml` looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# replace it with your repo url
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# replace it with your git secret if it's a private repo
|
||||
# secretRef: git-secret
|
||||
# the pull interval time, set to 10m since the infrastructure is steady
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# the branch name
|
||||
branch: main
|
||||
# the path to sync
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` and `infra.yaml` in `clusters/` are similar. Their difference is to watch different directories. In `apps.yaml`, the `properties.path` will be `./apps`.
|
||||
|
||||
Apply the files in `clusters/` manually. They will sync the files in `infrastructure/` and `apps/` dir of the Git repo.
|
||||
|
||||
#### Directory `apps/`
|
||||
|
||||
The file in `apps/` is a simple application with database information and Ingress. The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: <your image address> # {"$imagepolicy": "default:apps"}
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### Directory `infrastructure/`
|
||||
|
||||
The `infrastructure/` contains the config of some infrastructures like database. In the following, we will use [MySQL operator](https://github.com/bitpoke/mysql-operator) to deploy a MySQL cluster.
|
||||
|
||||
> Notice that there must be a secret in your cluster with MySQL password specified in key `ROOT_PASSWORD`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# replace it with your secret
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### Apply the files in `clusters/`
|
||||
|
||||
After storing bellow files in the Git config repo, we need to apply the GitOps config files in `clusters/` manually.
|
||||
|
||||
First, apply the `clusters/infra.yaml` to cluster, we can see that the MySQL in `infrastructure/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
Apply the `clusters/apps.yaml` to cluster, we can see that the application in `apps/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
By deploying the KubeVela GitOps config files, we now automatically apply the application and database in cluster.
|
||||
|
||||
`curl` the Ingress of the app, we can see that the current version is `0.1.5` and the application is connected to the database successfully:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### Modify the config for GitOps trigger
|
||||
|
||||
After the first deployment, we can modify the files in config repo to update the applications in the cluster.
|
||||
|
||||
Modify the domain of the application's Ingress:
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
Check the Ingress in cluster after a while:
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
The host of the Ingress has been updated successfully!
|
||||
|
||||
In this way, we can edit the files in the Git repo to update the cluster.
|
||||
|
||||
## For developers
|
||||
|
||||
Developers writes the application source code and push it to a Git repo (aka app repo). Once app repo updates, the CI will build the image and push it to the image registry. KubeVela watches the image registry, and updates the image in config repo. Finally, it will apply the config to the cluster.
|
||||
|
||||
User can update the configuration in the cluster automatically when the code is updated.
|
||||
|
||||
|
||||
|
||||
### Setup App Code Repository
|
||||
|
||||
Setup a Git repository with source code and Dockerfile.
|
||||
|
||||
The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
In this tutorial, we will setup a CI pipeline using GitHub Actions to build the image and push it to a registry. The code and configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code).
|
||||
|
||||
## Create Git Secret for KubeVela committing to Config Repo
|
||||
|
||||
After the new image is pushed to the image registry, KubeVela will be notified and update the `Application` file in the Git repository and cluster. Therefore, we need a secret with Git information for KubeVela to commit to the Git repository. Fill the following yaml files with your password and apply it to the cluster:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: my-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
The configuration repository is almost the same as the previous configuration, you only need to add the image registry config to the file. For more details, please refer to [Example Repository](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config).
|
||||
|
||||
Add the config of image registry in `clusters/apps.yaml`, it listens for image updates in the image registry:
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
image: <your image>
|
||||
# if it's a private image registry, use `kubectl create secret docker-registry` to create the secret
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# filter the image tag
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# use the policy to sort the latest image tag and update
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# add more commit message
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
Modify the image field in `apps/my-app.yaml` and add annotation `# {"$imagepolicy": "default:apps"}`.
|
||||
Notice that KubeVela will only be able to modify the image field if the annotation is added after the field. `default:apps` is `namespace:name` of the GitOps config file above.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
After update the files in `clusters/` to cluster, we can then update the application by modifying the code.
|
||||
|
||||
## Modify the code
|
||||
|
||||
Change the `Version` to `0.1.6` and modify the data in database:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Commit the change to the Git Repository, we can see that our CI pipelines has built the image and push it to the image registry.
|
||||
|
||||
KubeVela will listen to the image registry and update the `apps/my-app.yaml` in Git Repository with the latest image tag.
|
||||
|
||||
We can see that there is a commit form `kubevelabot`, the commit message is always with a prefix `Update image automatically.` You can use format like `{{range .Updated.Images}}{{println .}}{{end}}` to specify the image name in the `commitMessage` field.
|
||||
|
||||
|
||||
|
||||
> Note that if you want to put the code and config in the same repository, you need to filter out the commit from KubeVela in CI configuration like below to avoid the repeat build of pipeline.
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
Re-check the `Application` in cluster, we can see that the image of the `my-app` has been updated after a while.
|
||||
|
||||
> KubeVela polls the latest information from the code and image repo periodically (at an interval that can be customized):
|
||||
> * When the `Application` file in the Git repository is updated, KubeVela will update the `Application` in the cluster based on the latest configuration.
|
||||
> * When a new tag is added to the image registry, KubeVela will filter out the latest tag based on your policy and update it to Git repository. When the files in the repository are updated, KubeVela repeats the first step and updates the files in the cluster, thus achieving automatic deployment.
|
||||
|
||||
We can `curl` to `Ingress` to see the current version and data:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
The `Version` has been updated successfully! Now we're done with everything from changing the code to automatically applying to the cluster.
|
||||
|
||||
## Summary
|
||||
|
||||
For platform admins/SREs, they update the config repo to operate the application and infrastructure. KubeVela will synchronize the config to the cluster, simplifying the deployment process.
|
||||
|
||||
For end users/developers, they write the source code, push it to Git, and then re-deployment will happen. It will make CI to build the image. KubeVela will then update the image field and apply the deployment config.
|
||||
|
||||
By integrating with GitOps, KubeVela helps users speed up deployment and simplify continuous deployment.
|
||||
|
|
@ -2,43 +2,4 @@
|
|||
title: VelaUX Concept
|
||||
---
|
||||
|
||||
VelaUX is an addon on top of KubeVela, it works as an out-of-box platform which also brings some more concepts.
|
||||
|
||||
|
||||
|
||||
## Project
|
||||
|
||||
Project is where you manage all the applications and collaborate with your team member. Project is one stand alone scope that separates it from other project.
|
||||
|
||||
## Environment
|
||||
|
||||
Environment refers to the environment for development, testing, and production and it can include multiple Delivery Targets. Only applications in the same environment can visit and share resource with each other.
|
||||
|
||||
- <b>Bind Application with Environment</b> The application can be bound to multiple Environments, and for each environment, you can set the unique parameter difference for each environment.
|
||||
|
||||
## Delivery Target
|
||||
|
||||
Delivery Target describes the space where the application resources actually delivered. One target describes one Kubernetes cluster and namespace, it can also describe a region or VPC for cloud providers which includes shared variables and machine resources.
|
||||
|
||||
Kubernetes cluster and Cloud resources are currently the main way for KubeVela application delivery. In one target, credentials of cloud resources created will automatically delievered to the Kubernetes cluster.
|
||||
|
||||
## Application
|
||||
|
||||
An application in VelaUX is a bit different with KubeVela, we add lifecycle includes:
|
||||
|
||||
- <b>Create</b> an application is just create a metadata records, it won't run in real cluster.
|
||||
- <b>Deploy</b> an application will bind with specified environment and instantiate application resource into Kubernetes clusters.
|
||||
- <b>Recycle</b> an application will delete the instance of the application and reclaim its resources from Kubernetes clusters.
|
||||
- <b>Delete</b> an application is actually delete the metadata.
|
||||
|
||||
The rest concept in VelaUX Application are align with KubeVela Core.
|
||||
|
||||
### Revision
|
||||
|
||||
Revision generates each time when the application deployed and holds all infos in one snapshot. You use it for rolling back to whichever version whenever you needed.
|
||||
|
||||
|
||||
## 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.
|
||||
This doc has migrated to [velaux addon introdution](../reference/addons/velaux#concept-of-velaux).
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Manage Clusters with UX
|
||||
title: Manage Clusters on UI Console
|
||||
---
|
||||
|
||||
> This docs requires you to have [velaux](../../../reference/addons/velaux) installed.
|
||||
|
|
@ -20,7 +20,7 @@ For connecting the ACK clusters, the platform will save some cloud info, Region,
|
|||
|
||||
## Manage Delivery Target
|
||||
|
||||
To deploy application components into different places, VelaUX provides a new concept **Delivery Target** for user to manage their deploy destinations not only clusters or namespaces, but also cloud provider information such as region, vpc and so on.
|
||||
To deploy application components into different places, VelaUX provides a new concept **[Delivery Target](../../../reference/addons/velaux#delivery-target)** for user to manage their deploy destinations not only clusters or namespaces, but also cloud provider information such as region, vpc and so on.
|
||||
|
||||
## Cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Introduction
|
||||
title: Overview
|
||||
---
|
||||
|
||||
Once VelaUX is installed, there's a built-in administrator user with full access to the system. It is recommended to use the admin user only for the initial configuration, then switch to another user or configure the SSO integration.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Choose `> Cluster: local | Namespace: vela-system | Component: velaux | Kind: Se
|
|||
|
||||
If you are installing it in a remote environment such as a virtual machine, you can refer to [VelaUX addon](./reference/addons/velaux) document to expose an endpoint or other advanced installation arguments.
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
It requires you to override with a new password for the first login, please make sure to remember the new password.
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ After finished [the installation of VelaUX](./install#2-install-velaux), you can
|
|||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
|
||||
* VelaUX need authentication, default username is `admin` and the password is `VelaUX12345`.
|
||||
* VelaUX need authentication, default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
It requires you to override with a new password for the first login, please make sure to remember the new password.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ expected output:
|
|||
Addon: velaux enabled Successfully.
|
||||
```
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`. Please must set and remember the new password after the first login.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**. Please must set and remember the new password after the first login.
|
||||
|
||||
By default, VelaUX didn't have any exposed port.
|
||||
|
||||
|
|
@ -104,4 +104,39 @@ vela addon enable velaux repo=acr.kubevela.net
|
|||
|
||||
You can try to specify the `acr.kubevela.net` image registry as an alternative, It's maintained by KubeVela team, and we will upload/sync the built-in addon image for convenience.
|
||||
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
|
||||
## Concept of VelaUX
|
||||
|
||||
VelaUX is an addon on top of KubeVela, it works as UI console for KubeVela, while it's also an out-of-box platform for end-user.
|
||||
|
||||
We add some more concepts for enterprise integration.
|
||||
|
||||
|
||||
|
||||
### Project
|
||||
|
||||
Project is where you manage all the applications and collaborate with your team member. Project is one stand alone scope that separates it from other project.
|
||||
|
||||
### Environment
|
||||
|
||||
Environment refers to the environment for development, testing, and production and it can include multiple Delivery Targets. Only applications in the same environment can visit and share resource with each other.
|
||||
|
||||
- <b>Bind Application with Environment</b> The application can be bound to multiple Environments, and for each environment, you can set the unique parameter difference for each environment.
|
||||
|
||||
### Delivery Target
|
||||
|
||||
Delivery Target describes the space where the application resources actually delivered. One target describes one Kubernetes cluster and namespace, it can also describe a region or VPC for cloud providers which includes shared variables and machine resources.
|
||||
|
||||
Kubernetes cluster and Cloud resources are currently the main way for KubeVela application delivery. In one target, credentials of cloud resources created will automatically delievered to the Kubernetes cluster.
|
||||
|
||||
### Application
|
||||
|
||||
An application in VelaUX is a bit different with KubeVela, we add lifecycle includes:
|
||||
|
||||
- <b>Create</b> an application is just create a metadata records, it won't run in real cluster.
|
||||
- <b>Deploy</b> an application will bind with specified environment and instantiate application resource into Kubernetes clusters.
|
||||
- <b>Recycle</b> an application will delete the instance of the application and reclaim its resources from Kubernetes clusters.
|
||||
- <b>Delete</b> an application is actually delete the metadata.
|
||||
|
||||
The rest concept in VelaUX Application are align with KubeVela Core.
|
||||
|
|
|
|||
|
|
@ -16,27 +16,12 @@ Starting from here, you will learn to use the KubeVela Addons to install plug-in
|
|||
|
||||
## Enable fluxcd addon
|
||||
|
||||
Helm Chart delivery relies on addon in KubeVela, you need to enable `fluxcd` addon before start.
|
||||
Helm Chart delivery relies on addon in KubeVela, you need to enable `fluxcd` addon before start. You can refer to [addon management doc](../end-user/components/more) for more detail information about addon.
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
You can also enable the addon from UI console with more detail information. After `velaux` addon enabled, you can get into the page of `Addon`.
|
||||
This page will automatically list the community Addons that can be installed.
|
||||
They are all from [Community Repo](https://github.com/kubevela/catalog/tree/master/addons).
|
||||
You can check detail information of this addon by clicking the `fluxcd` UI section.
|
||||
|
||||
Details will include:
|
||||
|
||||
- Definitions: The extension capabilities provided by the addon may include component, trait, etc. For the fluxcd addon, it provides two component types, `helm` and `kustomize`, among which `helm` is the type we need to pay attention to and use here.
|
||||
|
||||
- README: Addon description, explain the capabilities and related information.
|
||||
|
||||
We can click the `Enable` button. After the fluxcd addon is enabled, it will be installed on all clusters connected to KubeVela, so it will take a certain amount of time.
|
||||
|
||||
|
||||
|
||||
When the addon status become `enabled`, it means it's ready for helm chart delivery.
|
||||
|
||||
## Creating Redis application
|
||||
|
|
|
|||
|
|
@ -13,82 +13,16 @@ KubeVela supports you to render, orchestrate and deploy Kubernetes objects. The
|
|||
|
||||
## Before starting
|
||||
|
||||
- Prepare a Deployment+Service yaml config resource.
|
||||
- Prepare Kubernetes Resources you want to deploy. In this guide, we'll use a composition of Deployment and Service as example.
|
||||
|
||||
<!-- - For setting up two and more runtime clusters, check out: [Manage Runtime Cluster](./manage-cluster) TODO v1.2-->
|
||||
## Deploy with CLI
|
||||
|
||||
## Scheduling and creating Targets
|
||||
Below is a demo application with Kubernetes objects consist of Deployment and Service.
|
||||
|
||||
[Target](../getting-started/core-concept#target) defines the namespace in runtime cluster for application delivery. Once Target created, namespace in runtime cluster created accordingly.
|
||||
There are two policies and three workflow steps in it:
|
||||
|
||||
Clicking `New Target` into the creating process. Type in necessary Infos as Project, Cluster, Namespace to create. We create targets for 2 clusters. We create targets for 2 clusters. If you only have 1 cluster you can also use its namespaces to create several targets. For now, we at least give it to 3 Targets: 1 for test and 2 for prod environments.
|
||||
|
||||
## Creating Kubernetes application
|
||||
|
||||
After Target was created, we begin to create an application. Same to [Deploy First Application](../quick-start), we need to submit basic Infos:
|
||||
|
||||
(1) Select type: k8s-objects; NOTE that in one application please maintain at most one Workload type of resource, meaning without more than a Deployment or Statefulset.
|
||||
|
||||
(2) We schedule two environments, test and prod. Test environment links to the target for dev and prod environment select the other two targets.
|
||||
|
||||
|
||||
|
||||
(3) Upload your Yaml file. Note that, the name of the resource you specified must not conflict with existing ones. Also, the editor automatically formats the Yaml file.
|
||||
|
||||
|
||||
|
||||
After above, click `Create` to finish.
|
||||
|
||||
## Deploying test environment
|
||||
|
||||
|
||||
|
||||
Enter the further page, the application has automatically generated 2 environments and 2 workflows. Each environment has its workflow by default. A workflow consists of one or more steps such as `deploy2env`.
|
||||
|
||||
Firstly let's switch to the Tab of the test environment, click Deploy on the page. Since we only assigned one target for the test environment, there's one step for workflow. Looking at the status of its execution in the upper-right, it turns green when succeeded. If it shows red means that workflow went into trouble, you can click on the red sign to look through the detailed reason. Fix it accordingly and the deployment will continue to be regained.
|
||||
|
||||
After deployment is finished, refresh the list of instances to see Pods. Click for more if Pod shows abnormality.
|
||||
|
||||
|
||||
|
||||
As for the test environment, it sure can be updated at any time. When we update the parameters(image, instance), execute the workflow for an upgrade. Note that, choose the workflow for the test environment.
|
||||
|
||||
|
||||
|
||||
## Deploying prod environment
|
||||
|
||||
Let's switch to the Tab of the prod environment. It shows that it's not deployed yet. So now you can understand one basic thing for KubeVela, different environments in one application are completely dependant on each other, of each is an individual Application CR.
|
||||
|
||||
As we have two targets for the prod environment, it'll execute in sequence. If you hope to set up a manual approval before it gets into the second target, this is where workflow comes in.
|
||||
|
||||
|
||||
|
||||
we can see two generated workflow. Now we click the `Edit` in the workflow of the prod environment, drag out the `suspend` into the board at the right. Set up the configuration you needed.
|
||||
|
||||
Then we need to orchestrate their sequence. First disconnect existing steps (by clicking the line + delete button), connect the suspend step in the middle. After editing, you need to click the Save button on the upper right to save.
|
||||
|
||||
|
||||
|
||||
Back to the page of prod environment, click Deploy.
|
||||
|
||||
|
||||
|
||||
Monitoring the status on the upper right. When the first target finished deploying, a window pops up for you to give out a command.
|
||||
|
||||
`suspend` has three operations:
|
||||
|
||||
- Rollback: the revision reverts to the latest one in history, even with the first Target.
|
||||
- Terminate: stop the deployment process but it will not change the first Target that already deployed.
|
||||
- Continue: enter the execution of the next step.
|
||||
|
||||
If continued, the deployment goes on. In the list of instances, you can check out all the details.
|
||||
|
||||
|
||||
|
||||
## Deploy kubernetes objects via CLI.
|
||||
|
||||
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.
|
||||
- The policy means we're going to deploy into two namespaces as different environments.
|
||||
- The workflow step means, we will deploy to one environment first, wait for human review after the first step succeeded, then finish the rest step.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -167,27 +101,117 @@ spec:
|
|||
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)
|
||||
- More about the topology policy, refer to [the detail guide](../end-user/policies/references#override).
|
||||
- More about the deploy workflow step, refer to [the detail guide](../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.
|
||||
- You may need to create the namespace with the name `production` before deploying the application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
```
|
||||
|
||||
- deploy the demo application.
|
||||
- Deploy the demo application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
```
|
||||
|
||||
- review and resume the workflow after the workflow becomes suspended.
|
||||
- Check the status of the application.
|
||||
|
||||
```
|
||||
vela status app-with-k8s-objects
|
||||
```
|
||||
|
||||
You can also check the deployment and service with the `kubectl` or any other tools you familiar to check the deployment.
|
||||
|
||||
- Approve the workflow if everything looks good.
|
||||
|
||||
```shell
|
||||
$ vela workflow resume app-with-k8s-objects
|
||||
vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
The delivery process can be powerful if you're [distributing resources across multi-clusters](../end-user/components/ref-objects).
|
||||
|
||||
|
||||
## Deploy with UI Console
|
||||
|
||||
We can do the same process in KubeVela UI Console if you have enabled [`velaux`](../reference/addons/velaux) addon.
|
||||
|
||||
### Create Delivery Target
|
||||
|
||||
In VelaUX, we use [Delivery Target](../reference/addons/velaux#delivery-target) to describe the space where the application resources actually delivered.
|
||||
It's like syntax sugar to `topology policy` in UI console.
|
||||
|
||||
Refer to [targets management doc](../how-to/dashboard/target/overview#manage-delivery-target) for details and make sure
|
||||
you have 3 targets: 1 for test and 2 for prod environments for our below example.
|
||||
|
||||
### Creating Kubernetes application
|
||||
|
||||
After Target was created, we begin to create an application. Same to [Deploy First Application](../quick-start), we need to submit basic Infos:
|
||||
|
||||
(1) Select type: k8s-objects; NOTE that in one application please maintain at most one Workload type of resource, meaning without more than a Deployment or Statefulset.
|
||||
|
||||
(2) We schedule two environments, test and prod. Test environment links to the target for dev and prod environment select the other two targets.
|
||||
|
||||
|
||||
|
||||
(3) Upload your Yaml file. Note that, the name of the resource you specified must not conflict with existing ones. Also, the editor automatically formats the Yaml file.
|
||||
|
||||
|
||||
|
||||
After above, click `Create` to finish.
|
||||
|
||||
### Deploying test environment
|
||||
|
||||
|
||||
|
||||
Enter the further page, the application has automatically generated 2 environments and 2 workflows. Each environment has its workflow by default. A workflow consists of one or more steps such as `deploy2env`.
|
||||
|
||||
Firstly let's switch to the Tab of the test environment, click Deploy on the page. Since we only assigned one target for the test environment, there's one step for workflow. Looking at the status of its execution in the upper-right, it turns green when succeeded. If it shows red means that workflow went into trouble, you can click on the red sign to look through the detailed reason. Fix it accordingly and the deployment will continue to be regained.
|
||||
|
||||
After deployment is finished, refresh the list of instances to see Pods. Click for more if Pod shows abnormality.
|
||||
|
||||
|
||||
|
||||
As for the test environment, it sure can be updated at any time. When we update the parameters(image, instance), execute the workflow for an upgrade. Note that, choose the workflow for the test environment.
|
||||
|
||||
|
||||
|
||||
### Deploying prod environment
|
||||
|
||||
Let's switch to the Tab of the prod environment. It shows that it's not deployed yet. So now you can understand one basic thing for KubeVela, different environments in one application are completely dependant on each other, of each is an individual Application CR.
|
||||
|
||||
As we have two targets for the prod environment, it'll execute in sequence. If you hope to set up a manual approval before it gets into the second target, this is where workflow comes in.
|
||||
|
||||
|
||||
|
||||
we can see two generated workflow. Now we click the `Edit` in the workflow of the prod environment, drag out the `suspend` into the board at the right. Set up the configuration you needed.
|
||||
|
||||
Then we need to orchestrate their sequence. First disconnect existing steps (by clicking the line + delete button), connect the suspend step in the middle. After editing, you need to click the Save button on the upper right to save.
|
||||
|
||||
|
||||
|
||||
Back to the page of prod environment, click Deploy.
|
||||
|
||||
|
||||
|
||||
Monitoring the status on the upper right. When the first target finished deploying, a window pops up for you to give out a command.
|
||||
|
||||
`suspend` has three operations:
|
||||
|
||||
- Rollback: the revision reverts to the latest one in history, even with the first Target.
|
||||
- Terminate: stop the deployment process but it will not change the first Target that already deployed.
|
||||
- Continue: enter the execution of the next step.
|
||||
|
||||
If continued, the deployment goes on. In the list of instances, you can check out all the details.
|
||||
|
||||
|
||||
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
## Next
|
||||
|
||||
* Learn how to [distribute resources across multi-clusters](../end-user/components/ref-objects).
|
||||
|
|
@ -3,8 +3,7 @@ title: Deploy Container Image
|
|||
description: deploy the business application by kubevela
|
||||
---
|
||||
|
||||
In this section, we will introduce how to deploy a container based application with KubeVela. The main process will be shown with UI console,
|
||||
if you're using CLI, jump to [Deploy via CLI](#deploy-via-cli) part.
|
||||
In this section, we will introduce how to deploy a container based application with KubeVela. The guide will run the whole process with UI console as it's quite the same with the [quick start](../quick-start) if you're using CLI.
|
||||
|
||||
## Before starting
|
||||
|
||||
|
|
@ -23,7 +22,6 @@ After inputting the Image address, the system will load the Image info from the
|
|||
|
||||
You could refer to their information to configure the `Service Ports` and `Persistent Storage`.
|
||||
|
||||
|
||||
|
||||
|
||||
Done by clicking `Create` and then we enter the management page.
|
||||
|
|
|
|||
|
|
@ -311,5 +311,8 @@
|
|||
},
|
||||
"sidebar.docs.category.UX Customization": {
|
||||
"message": "定制 UI"
|
||||
},
|
||||
"sidebar.docs.category.Declarative Workflow": {
|
||||
"message": "声明式工作流"
|
||||
}
|
||||
}
|
||||
|
|
@ -1,407 +1,22 @@
|
|||
---
|
||||
title: 集成 FluxCD 进行 GitOps
|
||||
title: 概览
|
||||
---
|
||||
|
||||
本文将介绍使用 KubeVela 结合 FluxCD 的仓库源监控能力，执行增强的 GitOps 持续发布的用法。
|
||||
|
||||
> 该教程仅适用于 CLI 用户。
|
||||
|
||||
## 简介
|
||||
|
||||
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。
|
||||
|
||||
KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用，并且这样做会在 GitOps 的基础上为用户提供更多的益处和端到端的体验，包括：
|
||||
- 应用交付工作流（CD 流水线）
|
||||
- 即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
|
||||
- 处理部署过程中的各种依赖关系和拓扑结构；
|
||||
- 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
|
||||
- 统一进行云服务的声明、部署和服务绑定；
|
||||
- 处理部署过程中的各种[依赖关系](../end-user/workflow/component-dependency-parameter)和拓扑结构；
|
||||
- 在现有各种 GitOps 工具的语义之上提供[统一的上层抽象](../getting-started/core-concept)，简化应用交付与管理过程；
|
||||
- 统一进行[云服务的声明](../tutorials/consume-cloud-services)、部署和服务绑定；
|
||||
- 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
|
||||
- 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
|
||||
- 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节；
|
||||
- …… 以及更多。
|
||||
|
||||
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
|
||||
在接下来的章节中，我们会介绍使用 KubeVela 做 GitOps 的流程，有可以选择下面的插件之一来做 GitOps：
|
||||
|
||||
交付的面向人员有以下两种，我们将分别介绍：
|
||||
- [使用 FluxCD 做 GitOps](../end-user/gitops/fluxcd)
|
||||
|
||||
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
|
||||
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
|
||||
|
||||
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
|
||||
|
||||
## 面向平台管理员/运维人员的交付
|
||||
|
||||
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
|
||||
|
||||
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
> 具体的配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs)。
|
||||
|
||||
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
|
||||
|
||||
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
|
||||
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
|
||||
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
|
||||
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
|
||||
|
||||
#### `clusters/` 目录
|
||||
|
||||
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
|
||||
|
||||
以 `clusters/infra.yaml` 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# 将此处替换成你需要监听的 git 配置仓库地址
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# 如果是私有仓库，还需要关联 git secret
|
||||
# secretRef: git-secret
|
||||
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# 监听变动的分支
|
||||
branch: main
|
||||
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
|
||||
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
|
||||
|
||||
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
|
||||
|
||||
#### `apps/` 目录
|
||||
|
||||
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### `infrastructure/` 目录
|
||||
|
||||
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
|
||||
|
||||
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# 关联 secret 名称
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### 部署 `clusters/` 目录下的文件
|
||||
|
||||
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
|
||||
|
||||
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
|
||||
|
||||
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### 修改配置
|
||||
|
||||
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
|
||||
|
||||
修改应用 Ingress 的 Domain：
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
经过一段时间后，重新查看集群中的 Ingress：
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
可以看到，Ingress 的 Host 地址已被成功更新。
|
||||
|
||||
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
|
||||
|
||||
## 面向终端开发者的交付
|
||||
|
||||
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
|
||||
|
||||
|
||||
|
||||
### 准备代码仓库
|
||||
|
||||
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
|
||||
|
||||
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code)。
|
||||
|
||||
### 配置秘钥信息
|
||||
|
||||
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: git-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config)。
|
||||
|
||||
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
# 镜像地址
|
||||
image: <your image>
|
||||
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# 可对镜像 tag 进行过滤
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# 追加提交信息
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
|
||||
|
||||
### 修改代码
|
||||
|
||||
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
|
||||
|
||||
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
|
||||
|
||||
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
|
||||
|
||||
|
||||
|
||||
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
|
||||
|
||||
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
|
||||
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
|
||||
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
|
||||
|
||||
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
|
||||
|
||||
## 总结
|
||||
|
||||
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
|
||||
|
||||
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
|
||||
|
||||
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。
|
||||
除了使用上述插件，最终用户也可以自己集成任意的 GitOps 工具来监听 Git 仓库中的 KubeVela Application 配置。
|
||||
|
|
@ -0,0 +1,388 @@
|
|||
---
|
||||
title: 使用 FluxCD 做 GitOps
|
||||
---
|
||||
|
||||
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
|
||||
|
||||
交付的面向人员有以下两种，我们将分别介绍：
|
||||
|
||||
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
|
||||
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
|
||||
|
||||
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
|
||||
|
||||
## 面向平台管理员/运维人员的交付
|
||||
|
||||
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
|
||||
|
||||
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
> 具体的配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs)。
|
||||
|
||||
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
|
||||
|
||||
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
|
||||
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
|
||||
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
|
||||
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
|
||||
|
||||
#### `clusters/` 目录
|
||||
|
||||
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
|
||||
|
||||
以 `clusters/infra.yaml` 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# 将此处替换成你需要监听的 git 配置仓库地址
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# 如果是私有仓库，还需要关联 git secret
|
||||
# secretRef: git-secret
|
||||
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# 监听变动的分支
|
||||
branch: main
|
||||
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
|
||||
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
|
||||
|
||||
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
|
||||
|
||||
#### `apps/` 目录
|
||||
|
||||
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### `infrastructure/` 目录
|
||||
|
||||
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
|
||||
|
||||
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# 关联 secret 名称
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### 部署 `clusters/` 目录下的文件
|
||||
|
||||
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
|
||||
|
||||
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
|
||||
|
||||
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### 修改配置
|
||||
|
||||
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
|
||||
|
||||
修改应用 Ingress 的 Domain：
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
经过一段时间后，重新查看集群中的 Ingress：
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
可以看到，Ingress 的 Host 地址已被成功更新。
|
||||
|
||||
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
|
||||
|
||||
## 面向终端开发者的交付
|
||||
|
||||
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
|
||||
|
||||
|
||||
|
||||
### 准备代码仓库
|
||||
|
||||
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
|
||||
|
||||
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code)。
|
||||
|
||||
### 配置秘钥信息
|
||||
|
||||
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: git-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config)。
|
||||
|
||||
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
# 镜像地址
|
||||
image: <your image>
|
||||
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# 可对镜像 tag 进行过滤
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# 追加提交信息
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
|
||||
|
||||
### 修改代码
|
||||
|
||||
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
|
||||
|
||||
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
|
||||
|
||||
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
|
||||
|
||||
|
||||
|
||||
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
|
||||
|
||||
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
|
||||
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
|
||||
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
|
||||
|
||||
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
|
||||
|
||||
## 总结
|
||||
|
||||
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
|
||||
|
||||
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
|
||||
|
||||
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。
|
||||
|
|
@ -2,43 +2,4 @@
|
|||
title: 核心概念
|
||||
---
|
||||
|
||||
VelaUX 是 KubeVela 的插件，它是一个企业可以开箱即用的云原生应用交付和管理平台。与此同时，也加入了一些企业使用中需要的概念。
|
||||
|
||||
|
||||
|
||||
## 项目（Project）
|
||||
|
||||
项目作为在 KubeVela 平台组织人员和资源的业务承载，项目中可以设定成员、权限、应用和分配环境。在项目维度集成外部代码库、制品库，呈现完整 CI/CD Pipeline；集成外部需求管理平台，呈现项目需求管理；集成微服务治理，提供多环境业务联调和统一治理能力。项目提供了业务级的资源隔离能力。
|
||||
|
||||
## 环境（Environment）
|
||||
|
||||
环境指通常意义的开发、测试、生产的环境业务描述，它可以包括多个交付目标。环境协调上层应用和底层基础设施的匹配关系，不同的环境对应管控集群的不同 Kubernetes Namespace。处在同一个环境中的应用才能具备内部互访和资源共享能力。
|
||||
|
||||
- <b>应用环境绑定</b> 应用可绑定多个环境进行发布，对于每一个环境可设置环境级部署差异。
|
||||
|
||||
|
||||
## 交付目标（Target）
|
||||
|
||||
交付目标用于描述应用的相关资源实际部署的物理空间，对应 Kubernetes 集群或者云的区域（Region）和专有网络（VPC）。对于普通应用，组件渲染生成的资源会在交付目标指定的 Kubernetes 集群中创建（可以精确到指定集群的 Namespace）；对于云服务，资源创建时会根据交付目标中指定的云厂商的参数创建到对应的区域和专有网络中，然后将生成的云资源信息分发到交付目标指定的 Kubernetes 集群中。单个环境可关联多个交付目标，代表该环境需要多集群交付。单个交付目标只能对应一个环境。
|
||||
|
||||
## 应用（Application）
|
||||
|
||||
应用是定义了一个微服务业务单元所包括的制品（二进制、Docker 镜像、Helm Chart...）或云服务的交付和管理需求，它由[组件](#组件（component）)、[运维特征](#运维特征（Trait）)、[工作流](#工作流（workflow）)、[应用策略](#应用策略（Policy）)四部分组成，应用的生命周期操作包括：
|
||||
|
||||
|
||||
- <b>创建(Create)</b> 应用是创建元信息，并不会实际部署和运行资源。
|
||||
- <b>部署(Deploy)</b> 指执行指定的工作流， 将应用在某一个环境中完成实例化。
|
||||
- <b>回收(Recycle)</b> 删除应用部署到某一个环境的实例，回收其占用的资源。
|
||||
- <b>删除</b> 应用会删除元数据，前提是应用实例已经完全被回收后才能删除。
|
||||
|
||||
VelaUX 应用中其他概念均与 KubeVela 控制器中的概念完全一致。
|
||||
|
||||
### 版本记录 （Revision）
|
||||
|
||||
应用每进行一次部署，生成一个版本记录，版本中快照了应用的完整配置。用户可以在任意时候将应用在某个环境的部署实例回滚到任意部署完成的历史版本。
|
||||
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 [实践教程](../tutorials/webservice)，了解更多使用场景和最佳实践。
|
||||
- 查看 [操作手册](../how-to/dashboard/application/create-application)，一步步了解更多的功能。
|
||||
文档内容已经迁移至 [velaux 插件](../reference/addons/velaux).
|
||||
|
|
@ -92,7 +92,7 @@ Choose `> Cluster: local | Namespace: vela-system | Component: velaux | Kind: Se
|
|||
|
||||
如果你是在远程主机安装或希望使用更稳固的访问方式，请参考 [VelaUX 高级安装说明](./reference/addons/velaux)。
|
||||
|
||||
VelaUX 是需要登陆认证的，默认管理员账号为 `admin` 密码为 `VelaUX12345`。请首次登陆成功后修改管理员密码并谨记。
|
||||
VelaUX 是需要登陆认证的，默认管理员账号为 `admin` 密码为 **`VelaUX12345`**。请首次登陆成功后修改管理员密码并谨记。
|
||||
|
||||
## 3. 卸载
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ expected output:
|
|||
Addon: velaux enabled Successfully.
|
||||
```
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`. Please must set and remember the new password after the first login.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**. Please must set and remember the new password after the first login.
|
||||
|
||||
By default, VelaUX didn't have any exposed port.
|
||||
|
||||
|
|
@ -103,4 +103,37 @@ vela addon enable velaux repo=acr.kubevela.net
|
|||
|
||||
You can try to specify the `acr.kubevela.net` image registry as an alternative, It's maintained by KubeVela team, and we will upload/sync the built-in addon image for convenience.
|
||||
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
|
||||
## VelaUX 概念
|
||||
|
||||
VelaUX 是 KubeVela 的插件，它是一个企业可以开箱即用的云原生应用交付和管理平台。与此同时，也加入了一些企业使用中需要的概念。
|
||||
|
||||
|
||||
|
||||
### 项目（Project）
|
||||
|
||||
项目作为在 KubeVela 平台组织人员和资源的业务承载，项目中可以设定成员、权限、应用和分配环境。在项目维度集成外部代码库、制品库，呈现完整 CI/CD Pipeline；集成外部需求管理平台，呈现项目需求管理；集成微服务治理，提供多环境业务联调和统一治理能力。项目提供了业务级的资源隔离能力。
|
||||
|
||||
### 环境（Environment）
|
||||
|
||||
环境指通常意义的开发、测试、生产的环境业务描述，它可以包括多个交付目标。环境协调上层应用和底层基础设施的匹配关系，不同的环境对应管控集群的不同 Kubernetes Namespace。处在同一个环境中的应用才能具备内部互访和资源共享能力。
|
||||
|
||||
- <b>应用环境绑定</b> 应用可绑定多个环境进行发布，对于每一个环境可设置环境级部署差异。
|
||||
|
||||
|
||||
### 交付目标（Target）
|
||||
|
||||
交付目标用于描述应用的相关资源实际部署的物理空间，对应 Kubernetes 集群或者云的区域（Region）和专有网络（VPC）。对于普通应用，组件渲染生成的资源会在交付目标指定的 Kubernetes 集群中创建（可以精确到指定集群的 Namespace）；对于云服务，资源创建时会根据交付目标中指定的云厂商的参数创建到对应的区域和专有网络中，然后将生成的云资源信息分发到交付目标指定的 Kubernetes 集群中。单个环境可关联多个交付目标，代表该环境需要多集群交付。单个交付目标只能对应一个环境。
|
||||
|
||||
### 应用（Application）
|
||||
|
||||
应用是定义了一个微服务业务单元所包括的制品（二进制、Docker 镜像、Helm Chart...）或云服务的交付和管理需求，它由[组件](#组件（component）)、[运维特征](#运维特征（Trait）)、[工作流](#工作流（workflow）)、[应用策略](#应用策略（Policy）)四部分组成，应用的生命周期操作包括：
|
||||
|
||||
|
||||
- <b>创建(Create)</b> 应用是创建元信息，并不会实际部署和运行资源。
|
||||
- <b>部署(Deploy)</b> 指执行指定的工作流， 将应用在某一个环境中完成实例化。
|
||||
- <b>回收(Recycle)</b> 删除应用部署到某一个环境的实例，回收其占用的资源。
|
||||
- <b>删除</b> 应用会删除元数据，前提是应用实例已经完全被回收后才能删除。
|
||||
|
||||
VelaUX 应用中其他概念均与 KubeVela 控制器中的概念完全一致。
|
||||
|
|
@ -215,8 +215,8 @@
|
|||
"message": "资源管理",
|
||||
"description": "管理集群和交付目标等资源"
|
||||
},
|
||||
"sidebar.docs.category.Official Addons": {
|
||||
"message": "官方插件",
|
||||
"sidebar.docs.category.Community Verified Addons": {
|
||||
"message": "社区认证插件",
|
||||
"description": "内置插件说明"
|
||||
},
|
||||
"sidebar.docs.category.Cloud Resources": {
|
||||
|
|
@ -312,8 +312,7 @@
|
|||
"sidebar.docs.category.UX Customization": {
|
||||
"message": "定制 UI"
|
||||
},
|
||||
"sidebar.docs.category.Community Verified Addons": {
|
||||
"message": "社区认证插件",
|
||||
"description": "内置插件说明"
|
||||
"sidebar.docs.category.Declarative Workflow": {
|
||||
"message": "声明式工作流"
|
||||
}
|
||||
}
|
||||
|
|
@ -1,407 +1,22 @@
|
|||
---
|
||||
title: 集成 FluxCD 进行 GitOps
|
||||
title: 概览
|
||||
---
|
||||
|
||||
本文将介绍使用 KubeVela 结合 FluxCD 的仓库源监控能力，执行增强的 GitOps 持续发布的用法。
|
||||
|
||||
> 该教程仅适用于 CLI 用户。
|
||||
|
||||
## 简介
|
||||
|
||||
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。
|
||||
|
||||
KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用，并且这样做会在 GitOps 的基础上为用户提供更多的益处和端到端的体验，包括：
|
||||
- 应用交付工作流（CD 流水线）
|
||||
- 即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
|
||||
- 处理部署过程中的各种依赖关系和拓扑结构；
|
||||
- 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
|
||||
- 统一进行云服务的声明、部署和服务绑定；
|
||||
- 处理部署过程中的各种[依赖关系](../end-user/workflow/component-dependency-parameter)和拓扑结构；
|
||||
- 在现有各种 GitOps 工具的语义之上提供[统一的上层抽象](../getting-started/core-concept)，简化应用交付与管理过程；
|
||||
- 统一进行[云服务的声明](../tutorials/consume-cloud-services)、部署和服务绑定；
|
||||
- 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
|
||||
- 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
|
||||
- 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节；
|
||||
- …… 以及更多。
|
||||
|
||||
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
|
||||
在接下来的章节中，我们会介绍使用 KubeVela 做 GitOps 的流程，有可以选择下面的插件之一来做 GitOps：
|
||||
|
||||
交付的面向人员有以下两种，我们将分别介绍：
|
||||
- [使用 FluxCD 做 GitOps](../end-user/gitops/fluxcd)
|
||||
|
||||
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
|
||||
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
|
||||
|
||||
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
|
||||
|
||||
## 面向平台管理员/运维人员的交付
|
||||
|
||||
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
|
||||
|
||||
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
> 具体的配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs)。
|
||||
|
||||
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
|
||||
|
||||
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
|
||||
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
|
||||
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
|
||||
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
|
||||
|
||||
#### `clusters/` 目录
|
||||
|
||||
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
|
||||
|
||||
以 `clusters/infra.yaml` 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# 将此处替换成你需要监听的 git 配置仓库地址
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# 如果是私有仓库，还需要关联 git secret
|
||||
# secretRef: git-secret
|
||||
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# 监听变动的分支
|
||||
branch: main
|
||||
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
|
||||
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
|
||||
|
||||
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
|
||||
|
||||
#### `apps/` 目录
|
||||
|
||||
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### `infrastructure/` 目录
|
||||
|
||||
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
|
||||
|
||||
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# 关联 secret 名称
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### 部署 `clusters/` 目录下的文件
|
||||
|
||||
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
|
||||
|
||||
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
|
||||
|
||||
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### 修改配置
|
||||
|
||||
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
|
||||
|
||||
修改应用 Ingress 的 Domain：
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
经过一段时间后，重新查看集群中的 Ingress：
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
可以看到，Ingress 的 Host 地址已被成功更新。
|
||||
|
||||
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
|
||||
|
||||
## 面向终端开发者的交付
|
||||
|
||||
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
|
||||
|
||||
|
||||
|
||||
### 准备代码仓库
|
||||
|
||||
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
|
||||
|
||||
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code)。
|
||||
|
||||
### 配置秘钥信息
|
||||
|
||||
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: git-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config)。
|
||||
|
||||
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
# 镜像地址
|
||||
image: <your image>
|
||||
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# 可对镜像 tag 进行过滤
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# 追加提交信息
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
|
||||
|
||||
### 修改代码
|
||||
|
||||
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
|
||||
|
||||
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
|
||||
|
||||
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
|
||||
|
||||
|
||||
|
||||
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
|
||||
|
||||
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
|
||||
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
|
||||
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
|
||||
|
||||
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
|
||||
|
||||
## 总结
|
||||
|
||||
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
|
||||
|
||||
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
|
||||
|
||||
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。
|
||||
除了使用上述插件，最终用户也可以自己集成任意的 GitOps 工具来监听 Git 仓库中的 KubeVela Application 配置。
|
||||
|
|
@ -0,0 +1,388 @@
|
|||
---
|
||||
title: 使用 FluxCD 做 GitOps
|
||||
---
|
||||
|
||||
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
|
||||
|
||||
交付的面向人员有以下两种，我们将分别介绍：
|
||||
|
||||
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
|
||||
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
|
||||
|
||||
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
|
||||
|
||||
## 面向平台管理员/运维人员的交付
|
||||
|
||||
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
|
||||
|
||||
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
> 具体的配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs)。
|
||||
|
||||
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
|
||||
|
||||
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
|
||||
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
|
||||
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
|
||||
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
|
||||
|
||||
#### `clusters/` 目录
|
||||
|
||||
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
|
||||
|
||||
以 `clusters/infra.yaml` 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# 将此处替换成你需要监听的 git 配置仓库地址
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# 如果是私有仓库，还需要关联 git secret
|
||||
# secretRef: git-secret
|
||||
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# 监听变动的分支
|
||||
branch: main
|
||||
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
|
||||
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
|
||||
|
||||
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
|
||||
|
||||
#### `apps/` 目录
|
||||
|
||||
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### `infrastructure/` 目录
|
||||
|
||||
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
|
||||
|
||||
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# 关联 secret 名称
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### 部署 `clusters/` 目录下的文件
|
||||
|
||||
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
|
||||
|
||||
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
|
||||
|
||||
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### 修改配置
|
||||
|
||||
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
|
||||
|
||||
修改应用 Ingress 的 Domain：
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
经过一段时间后，重新查看集群中的 Ingress：
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
可以看到，Ingress 的 Host 地址已被成功更新。
|
||||
|
||||
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
|
||||
|
||||
## 面向终端开发者的交付
|
||||
|
||||
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
|
||||
|
||||
|
||||
|
||||
### 准备代码仓库
|
||||
|
||||
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
|
||||
|
||||
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code)。
|
||||
|
||||
### 配置秘钥信息
|
||||
|
||||
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: git-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
### 准备配置仓库
|
||||
|
||||
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config)。
|
||||
|
||||
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
# 镜像地址
|
||||
image: <your image>
|
||||
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# 可对镜像 tag 进行过滤
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# 追加提交信息
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
|
||||
|
||||
### 修改代码
|
||||
|
||||
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
|
||||
|
||||
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
|
||||
|
||||
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
|
||||
|
||||
|
||||
|
||||
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
|
||||
|
||||
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
|
||||
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
|
||||
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
|
||||
|
||||
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
|
||||
|
||||
## 总结
|
||||
|
||||
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
|
||||
|
||||
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
|
||||
|
||||
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。
|
||||
|
|
@ -2,43 +2,4 @@
|
|||
title: 核心概念
|
||||
---
|
||||
|
||||
VelaUX 是 KubeVela 的插件，它是一个企业可以开箱即用的云原生应用交付和管理平台。与此同时，也加入了一些企业使用中需要的概念。
|
||||
|
||||
|
||||
|
||||
## 项目（Project）
|
||||
|
||||
项目作为在 KubeVela 平台组织人员和资源的业务承载，项目中可以设定成员、权限、应用和分配环境。在项目维度集成外部代码库、制品库，呈现完整 CI/CD Pipeline；集成外部需求管理平台，呈现项目需求管理；集成微服务治理，提供多环境业务联调和统一治理能力。项目提供了业务级的资源隔离能力。
|
||||
|
||||
## 环境（Environment）
|
||||
|
||||
环境指通常意义的开发、测试、生产的环境业务描述，它可以包括多个交付目标。环境协调上层应用和底层基础设施的匹配关系，不同的环境对应管控集群的不同 Kubernetes Namespace。处在同一个环境中的应用才能具备内部互访和资源共享能力。
|
||||
|
||||
- <b>应用环境绑定</b> 应用可绑定多个环境进行发布，对于每一个环境可设置环境级部署差异。
|
||||
|
||||
|
||||
## 交付目标（Target）
|
||||
|
||||
交付目标用于描述应用的相关资源实际部署的物理空间，对应 Kubernetes 集群或者云的区域（Region）和专有网络（VPC）。对于普通应用，组件渲染生成的资源会在交付目标指定的 Kubernetes 集群中创建（可以精确到指定集群的 Namespace）；对于云服务，资源创建时会根据交付目标中指定的云厂商的参数创建到对应的区域和专有网络中，然后将生成的云资源信息分发到交付目标指定的 Kubernetes 集群中。单个环境可关联多个交付目标，代表该环境需要多集群交付。单个交付目标只能对应一个环境。
|
||||
|
||||
## 应用（Application）
|
||||
|
||||
应用是定义了一个微服务业务单元所包括的制品（二进制、Docker 镜像、Helm Chart...）或云服务的交付和管理需求，它由[组件](#组件（component）)、[运维特征](#运维特征（Trait）)、[工作流](#工作流（workflow）)、[应用策略](#应用策略（Policy）)四部分组成，应用的生命周期操作包括：
|
||||
|
||||
|
||||
- <b>创建(Create)</b> 应用是创建元信息，并不会实际部署和运行资源。
|
||||
- <b>部署(Deploy)</b> 指执行指定的工作流， 将应用在某一个环境中完成实例化。
|
||||
- <b>回收(Recycle)</b> 删除应用部署到某一个环境的实例，回收其占用的资源。
|
||||
- <b>删除</b> 应用会删除元数据，前提是应用实例已经完全被回收后才能删除。
|
||||
|
||||
VelaUX 应用中其他概念均与 KubeVela 控制器中的概念完全一致。
|
||||
|
||||
### 版本记录 （Revision）
|
||||
|
||||
应用每进行一次部署，生成一个版本记录，版本中快照了应用的完整配置。用户可以在任意时候将应用在某个环境的部署实例回滚到任意部署完成的历史版本。
|
||||
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 [实践教程](../tutorials/webservice)，了解更多使用场景和最佳实践。
|
||||
- 查看 [操作手册](../how-to/dashboard/application/create-application)，一步步了解更多的功能。
|
||||
文档内容已经迁移至 [velaux 插件](../reference/addons/velaux).
|
||||
|
|
@ -92,7 +92,7 @@ Choose `> Cluster: local | Namespace: vela-system | Component: velaux | Kind: Se
|
|||
|
||||
如果你是在远程主机安装或希望使用更稳固的访问方式，请参考 [VelaUX 高级安装说明](./reference/addons/velaux)。
|
||||
|
||||
VelaUX 是需要登陆认证的，默认管理员账号为 `admin` 密码为 `VelaUX12345`。请首次登陆成功后修改管理员密码并谨记。
|
||||
VelaUX 是需要登陆认证的，默认管理员账号为 `admin` 密码为 **`VelaUX12345`**。请首次登陆成功后修改管理员密码并谨记。
|
||||
|
||||
## 3. 卸载
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ expected output:
|
|||
Addon: velaux enabled Successfully.
|
||||
```
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`. Please must set and remember the new password after the first login.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**. Please must set and remember the new password after the first login.
|
||||
|
||||
By default, VelaUX didn't have any exposed port.
|
||||
|
||||
|
|
@ -103,4 +103,37 @@ vela addon enable velaux repo=acr.kubevela.net
|
|||
|
||||
You can try to specify the `acr.kubevela.net` image registry as an alternative, It's maintained by KubeVela team, and we will upload/sync the built-in addon image for convenience.
|
||||
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
|
||||
## VelaUX 概念
|
||||
|
||||
VelaUX 是 KubeVela 的插件，它是一个企业可以开箱即用的云原生应用交付和管理平台。与此同时，也加入了一些企业使用中需要的概念。
|
||||
|
||||
|
||||
|
||||
### 项目（Project）
|
||||
|
||||
项目作为在 KubeVela 平台组织人员和资源的业务承载，项目中可以设定成员、权限、应用和分配环境。在项目维度集成外部代码库、制品库，呈现完整 CI/CD Pipeline；集成外部需求管理平台，呈现项目需求管理；集成微服务治理，提供多环境业务联调和统一治理能力。项目提供了业务级的资源隔离能力。
|
||||
|
||||
### 环境（Environment）
|
||||
|
||||
环境指通常意义的开发、测试、生产的环境业务描述，它可以包括多个交付目标。环境协调上层应用和底层基础设施的匹配关系，不同的环境对应管控集群的不同 Kubernetes Namespace。处在同一个环境中的应用才能具备内部互访和资源共享能力。
|
||||
|
||||
- <b>应用环境绑定</b> 应用可绑定多个环境进行发布，对于每一个环境可设置环境级部署差异。
|
||||
|
||||
|
||||
### 交付目标（Target）
|
||||
|
||||
交付目标用于描述应用的相关资源实际部署的物理空间，对应 Kubernetes 集群或者云的区域（Region）和专有网络（VPC）。对于普通应用，组件渲染生成的资源会在交付目标指定的 Kubernetes 集群中创建（可以精确到指定集群的 Namespace）；对于云服务，资源创建时会根据交付目标中指定的云厂商的参数创建到对应的区域和专有网络中，然后将生成的云资源信息分发到交付目标指定的 Kubernetes 集群中。单个环境可关联多个交付目标，代表该环境需要多集群交付。单个交付目标只能对应一个环境。
|
||||
|
||||
### 应用（Application）
|
||||
|
||||
应用是定义了一个微服务业务单元所包括的制品（二进制、Docker 镜像、Helm Chart...）或云服务的交付和管理需求，它由[组件](#组件（component）)、[运维特征](#运维特征（Trait）)、[工作流](#工作流（workflow）)、[应用策略](#应用策略（Policy）)四部分组成，应用的生命周期操作包括：
|
||||
|
||||
|
||||
- <b>创建(Create)</b> 应用是创建元信息，并不会实际部署和运行资源。
|
||||
- <b>部署(Deploy)</b> 指执行指定的工作流， 将应用在某一个环境中完成实例化。
|
||||
- <b>回收(Recycle)</b> 删除应用部署到某一个环境的实例，回收其占用的资源。
|
||||
- <b>删除</b> 应用会删除元数据，前提是应用实例已经完全被回收后才能删除。
|
||||
|
||||
VelaUX 应用中其他概念均与 KubeVela 控制器中的概念完全一致。
|
||||
17
sidebars.js
17
sidebars.js
|
|
@ -76,14 +76,25 @@ module.exports = {
|
|||
type: 'category',
|
||||
label: 'GitOps',
|
||||
collapsed: true,
|
||||
items: ['case-studies/gitops'],
|
||||
items: [
|
||||
'case-studies/gitops',
|
||||
'end-user/gitops/fluxcd',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Declarative Workflow',
|
||||
collapsed: true,
|
||||
items: [
|
||||
'tutorials/workflows',
|
||||
'end-user/workflow/component-dependency-parameter',
|
||||
'end-user/workflow/webhook-notification',
|
||||
],
|
||||
},
|
||||
{
|
||||
'General CD Features': [
|
||||
'how-to/dashboard/application/create-application',
|
||||
'end-user/version-control',
|
||||
'tutorials/workflows',
|
||||
'end-user/workflow/component-dependency-parameter',
|
||||
'end-user/policies/apply-once',
|
||||
'end-user/policies/gc',
|
||||
],
|
||||
|
|
|
|||
|
|
@ -1,410 +1,25 @@
|
|||
---
|
||||
title: FluxCD
|
||||
title: Overview
|
||||
---
|
||||
|
||||
This section will introduce how to use KubeVela in GitOps environment and why.
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
|
||||
> This section is only apply to CLI, you need to enable the [FluxCD](../reference/addons/fluxcd) addon.
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with "git-centric" operations such as PR and commit. For detailed benefits of GitOps, you can refer to [this blog](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
## Introduction
|
||||
KubeVela as a declarative application delivery control plane can be naturally used in GitOps approach, and this will provide below extra bonus to end users alongside with GitOps benefits:
|
||||
|
||||
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with Git-centric operations such as PR and commit. For detailed benefits of GitOps, please check [this article](https://www.weave.works/blog/what-is-gitops-really).
|
||||
|
||||
KubeVela as an declarative application delivery control plane can be naturally used in GitOps approach, and this will provide below extra bonus to end users alongside with GitOps benefits:
|
||||
- application delivery workflow (CD pipeline)
|
||||
- i.e. KubeVela supports pipeline style application delivery process in GitOps, instead of simply declaring final status;
|
||||
- handling deployment dependencies and designing typologies (DAG);
|
||||
- unified higher level abstraction atop various GitOps tools' primitives;
|
||||
- declare, provision and consume cloud resources in unified application definition;
|
||||
- handling deployment [dependencies and designing typologies (DAG)](../end-user/workflow/component-dependency-parameter);
|
||||
- [unified higher level abstraction](../getting-started/core-concept) atop various GitOps tools' primitives;
|
||||
- declare, provision and consume [cloud resources](../tutorials/consume-cloud-services) in unified application definition;
|
||||
- various out-of-box deployment strategies (Canary, Blue-Green ...);
|
||||
- various out-of-box hybrid/multi-cloud deployment policies (placement rule, cluster selectors etc.);
|
||||
- Kustomize-style patch for multi-env deployment without the need to learn Kustomize at all;
|
||||
- ... and much more.
|
||||
|
||||
In this section, we will introduce steps of using KubeVela directly in GitOps approach.
|
||||
In the following sections, we will introduce steps of using KubeVela directly in GitOps approach. You can choose any of the following addons for the whole GitOps process:
|
||||
|
||||
This article will separate into two perspectives:
|
||||
- [GitOps with FluxCD](../end-user/gitops/fluxcd)
|
||||
|
||||
1. For platform administrators/SREs, they can update the config in Git repo. It will trigger automated re-deployment.
|
||||
|
||||
2. For developers, they can update the app source code and then push it to Git. It will trigger building latest image and re-deployment.
|
||||
|
||||
> Note: you can also use it with existing tools such as ArgoCD with similar steps, detailed guides will be added in following releases.
|
||||
|
||||
## For platform administrators/SREs
|
||||
|
||||
Platform administrators/SREs prepares the Git repo for operational config. Every config change will be traceable by that. KubeVela will watch the repo and apply changes to the clusters.
|
||||
|
||||
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
> The configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs).
|
||||
|
||||
In this example, we will deploy an application and a database, the application uses the database to store data.
|
||||
|
||||
The structure of the config repository looks below:
|
||||
|
||||
* The `clusters/` contains the GitOps config. It will command KubeVela to watch the specified repo and apply latest changes.
|
||||
* The `apps/` contains the Application yaml for deploying the user-facing app.
|
||||
* The `infrastructure/` contains infrastructure tools, i.e. MySQL database.
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela recommends using the directory structure above to manage your GitOps repository. `clusters/` holds the associated KubeVela GitOps configuration that need to be applied to cluster manually, `apps/` holds your application and `infrastructure/` holds your base configuration. By separating applications from basic configurations, you can manage your deployment environment more reasonably and isolate application changes.
|
||||
|
||||
#### Directory `clusters/`
|
||||
|
||||
The `clusters/` is the initialize configuration directory for KubeVela GitOps.
|
||||
|
||||
Below is how the `clusters/infra.yaml` looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# replace it with your repo url
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# replace it with your git secret if it's a private repo
|
||||
# secretRef: git-secret
|
||||
# the pull interval time, set to 10m since the infrastructure is steady
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# the branch name
|
||||
branch: main
|
||||
# the path to sync
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` and `infra.yaml` in `clusters/` are similar. Their difference is to watch different directories. In `apps.yaml`, the `properties.path` will be `./apps`.
|
||||
|
||||
Apply the files in `clusters/` manually. They will sync the files in `infrastructure/` and `apps/` dir of the Git repo.
|
||||
|
||||
#### Directory `apps/`
|
||||
|
||||
The file in `apps/` is a simple application with database information and Ingress. The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: <your image address> # {"$imagepolicy": "default:apps"}
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### Directory `infrastructure/`
|
||||
|
||||
The `infrastructure/` contains the config of some infrastructures like database. In the following, we will use [MySQL operator](https://github.com/bitpoke/mysql-operator) to deploy a MySQL cluster.
|
||||
|
||||
> Notice that there must be a secret in your cluster with MySQL password specified in key `ROOT_PASSWORD`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# replace it with your secret
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### Apply the files in `clusters/`
|
||||
|
||||
After storing bellow files in the Git config repo, we need to apply the GitOps config files in `clusters/` manually.
|
||||
|
||||
First, apply the `clusters/infra.yaml` to cluster, we can see that the MySQL in `infrastructure/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
Apply the `clusters/apps.yaml` to cluster, we can see that the application in `apps/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
By deploying the KubeVela GitOps config files, we now automatically apply the application and database in cluster.
|
||||
|
||||
`curl` the Ingress of the app, we can see that the current version is `0.1.5` and the application is connected to the database successfully:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
## Modify the config for GitOps trigger
|
||||
|
||||
After the first deployment, we can modify the files in config repo to update the applications in the cluster.
|
||||
|
||||
Modify the domain of the application's Ingress:
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
Check the Ingress in cluster after a while:
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
The host of the Ingress has been updated successfully!
|
||||
|
||||
In this way, we can edit the files in the Git repo to update the cluster.
|
||||
|
||||
## For developers
|
||||
|
||||
Developers writes the application source code and push it to a Git repo (aka app repo). Once app repo updates, the CI will build the image and push it to the image registry. KubeVela watches the image registry, and updates the image in config repo. Finally, it will apply the config to the cluster.
|
||||
|
||||
User can update the configuration in the cluster automatically when the code is updated.
|
||||
|
||||
|
||||
|
||||
### Setup App Code Repository
|
||||
|
||||
Setup a Git repository with source code and Dockerfile.
|
||||
|
||||
The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
In this tutorial, we will setup a CI pipeline using GitHub Actions to build the image and push it to a registry. The code and configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code).
|
||||
|
||||
## Create Git Secret for KubeVela committing to Config Repo
|
||||
|
||||
After the new image is pushed to the image registry, KubeVela will be notified and update the `Application` file in the Git repository and cluster. Therefore, we need a secret with Git information for KubeVela to commit to the Git repository. Fill the following yaml files with your password and apply it to the cluster:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: my-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
The configuration repository is almost the same as the previous configuration, you only need to add the image registry config to the file. For more details, please refer to [Example Repository](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config).
|
||||
|
||||
Add the config of image registry in `clusters/apps.yaml`, it listens for image updates in the image registry:
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
image: <your image>
|
||||
# if it's a private image registry, use `kubectl create secret docker-registry` to create the secret
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# filter the image tag
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# use the policy to sort the latest image tag and update
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# add more commit message
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
Modify the image field in `apps/my-app.yaml` and add annotation `# {"$imagepolicy": "default:apps"}`.
|
||||
Notice that KubeVela will only be able to modify the image field if the annotation is added after the field. `default:apps` is `namespace:name` of the GitOps config file above.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
After update the files in `clusters/` to cluster, we can then update the application by modifying the code.
|
||||
|
||||
## Modify the code
|
||||
|
||||
Change the `Version` to `0.1.6` and modify the data in database:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Commit the change to the Git Repository, we can see that our CI pipelines has built the image and push it to the image registry.
|
||||
|
||||
KubeVela will listen to the image registry and update the `apps/my-app.yaml` in Git Repository with the latest image tag.
|
||||
|
||||
We can see that there is a commit form `kubevelabot`, the commit message is always with a prefix `Update image automatically.` You can use format like `{{range .Updated.Images}}{{println .}}{{end}}` to specify the image name in the `commitMessage` field.
|
||||
|
||||
|
||||
|
||||
> Note that if you want to put the code and config in the same repository, you need to filter out the commit from KubeVela in CI configuration like below to avoid the repeat build of pipeline.
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
Re-check the `Application` in cluster, we can see that the image of the `my-app` has been updated after a while.
|
||||
|
||||
> KubeVela polls the latest information from the code and image repo periodically (at an interval that can be customized):
|
||||
> * When the `Application` file in the Git repository is updated, KubeVela will update the `Application` in the cluster based on the latest configuration.
|
||||
> * When a new tag is added to the image registry, KubeVela will filter out the latest tag based on your policy and update it to Git repository. When the files in the repository are updated, KubeVela repeats the first step and updates the files in the cluster, thus achieving automatic deployment.
|
||||
|
||||
We can `curl` to `Ingress` to see the current version and data:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
The `Version` has been updated successfully! Now we're done with everything from changing the code to automatically applying to the cluster.
|
||||
|
||||
## Summary
|
||||
|
||||
For platform admins/SREs, they update the config repo to operate the application and infrastructure. KubeVela will synchronize the config to the cluster, simplifying the deployment process.
|
||||
|
||||
For end users/developers, they write the source code, push it to Git, and then re-deployment will happen. It will make CI to build the image. KubeVela will then update the image field and apply the deployment config.
|
||||
|
||||
By integrating with GitOps, KubeVela helps users speed up deployment and simplify continuous deployment.
|
||||
Besides these addons, the end user can use any GitOps tools they want to watch the Git repo for KubeVela applications as configuration.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Introduction
|
||||
title: Overview
|
||||
---
|
||||
|
||||
The developer guide including two parts:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ There're many out-of-box capabilities installed along with KubeVela controller,
|
|||
- [Built-in Policy Reference](../policies/references)
|
||||
- [Built-in Workflow Step Reference](../workflow/built-in-workflow-defs)
|
||||
|
||||
## Manage Addons
|
||||
## Extend by Managing Addons
|
||||
|
||||
Installing addon from the community is also one of the most important way to discover more capabilities.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Addon: velaux enabled Successfully
|
|||
|
||||
Please notice that, while an addon installing cluster maybe still need pull some images or helm charts.If your cluster cannot reach these resources please refer [docs](../../platform-engineers/system-operation/enable-addon-offline) to do complete installation without internet.
|
||||
|
||||
### Manage the addon with VelaUX
|
||||
### Manage the addon with UI Console
|
||||
|
||||
If you have installed [VelaUX](../../reference/addons/velaux) which is also one of the addon, you can manage it directly on the UI console with admin privileges.
|
||||
|
||||
|
|
@ -194,11 +194,13 @@ In the addon list, you can get the status of the addon and other info. Click the
|
|||
|
||||
|
||||
|
||||
Select a version and deployed clusters, you can click the enable button to install this addon.
|
||||
Select a version and deployed clusters, you can click the enable button to install this addon. You can check detail information in this section include:
|
||||
|
||||
- Definitions: The extension capabilities provided by the addon may include component, trait, etc.
|
||||
- README: Addon description, explain the capabilities and related information.
|
||||
|
||||
For enabled addons, if no applications to use definitions, you can click the disable button to uninstall it.
|
||||
|
||||
|
||||
### Make your own addon
|
||||
|
||||
If you're a system infra or operator, you can refer to extension documents to learn how to [make your own addon and registry](../../platform-engineers/addon/intro), including [extend cloud resources by addon](../../platform-engineers/addon/terraform).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,391 @@
|
|||
---
|
||||
title: GitOps with FluxCD
|
||||
---
|
||||
|
||||
> You need to enable the [fluxcd](../../reference/addons/fluxcd) addon.
|
||||
|
||||
As a best practice, this article will separate into two perspectives simulating to the real scenarios:
|
||||
|
||||
1. For platform administrators/SREs, they can update the config in Git repo. It will trigger automated re-deployment.
|
||||
|
||||
2. For developers, they can update the app source code and then push it to Git. It will trigger building latest image and re-deployment.
|
||||
|
||||
## For platform administrators/SREs
|
||||
|
||||
Platform administrators/SREs prepares the Git repo for operational config. There will have a gitops agent watch the git server events, every changes of the configuration will be traceable by that.
|
||||
|
||||
In this scenario, KubeVela will watch the repo and apply changes to the clusters.
|
||||
|
||||
|
||||
|
||||
### Setup Config Repository to watch
|
||||
|
||||
> The configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs).
|
||||
|
||||
In this example, we will deploy an application and a database, the application uses the database to store data.
|
||||
|
||||
The structure of the config repository looks below:
|
||||
|
||||
* The `clusters/` contains the GitOps config. It will command KubeVela to watch the specified repo and apply latest changes.
|
||||
* The `apps/` contains the Application yaml for deploying the user-facing app.
|
||||
* The `infrastructure/` contains infrastructure tools, i.e. MySQL database.
|
||||
|
||||
```shell
|
||||
├── apps
|
||||
│ └── my-app.yaml
|
||||
├── clusters
|
||||
│ ├── apps.yaml
|
||||
│ └── infra.yaml
|
||||
└── infrastructure
|
||||
└── mysql.yaml
|
||||
```
|
||||
|
||||
> KubeVela recommends using the directory structure above to manage your GitOps repository. `clusters/` holds the associated KubeVela GitOps configuration that need to be applied to cluster manually, `apps/` holds your application and `infrastructure/` holds your base configuration. By separating applications from basic configurations, you can manage your deployment environment more reasonably and isolate application changes.
|
||||
|
||||
#### Directory `clusters/`
|
||||
|
||||
The `clusters/` is the initialize configuration directory for KubeVela GitOps.
|
||||
|
||||
Below is how the `clusters/infra.yaml` looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: infra
|
||||
spec:
|
||||
components:
|
||||
- name: database-config
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
# replace it with your repo url
|
||||
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
|
||||
# replace it with your git secret if it's a private repo
|
||||
# secretRef: git-secret
|
||||
# the pull interval time, set to 10m since the infrastructure is steady
|
||||
pullInterval: 10m
|
||||
git:
|
||||
# the branch name
|
||||
branch: main
|
||||
# the path to sync
|
||||
path: ./infrastructure
|
||||
```
|
||||
|
||||
`apps.yaml` and `infra.yaml` in `clusters/` are similar. Their difference is to watch different directories. In `apps.yaml`, the `properties.path` will be `./apps`.
|
||||
|
||||
Apply the files in `clusters/` manually. They will sync the files in `infrastructure/` and `apps/` dir of the Git repo.
|
||||
|
||||
#### Directory `apps/`
|
||||
|
||||
The file in `apps/` is a simple application with database information and Ingress. The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: my-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: <your image address> # {"$imagepolicy": "default:apps"}
|
||||
port: 8088
|
||||
env:
|
||||
- name: DB_HOST
|
||||
value: mysql-cluster-mysql.default.svc.cluster.local:3306
|
||||
- name: DB_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: mysql-secret
|
||||
key: ROOT_PASSWORD
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8088
|
||||
```
|
||||
|
||||
#### Directory `infrastructure/`
|
||||
|
||||
The `infrastructure/` contains the config of some infrastructures like database. In the following, we will use [MySQL operator](https://github.com/bitpoke/mysql-operator) to deploy a MySQL cluster.
|
||||
|
||||
> Notice that there must be a secret in your cluster with MySQL password specified in key `ROOT_PASSWORD`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: mysql
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: mysql-controller
|
||||
type: helm
|
||||
properties:
|
||||
repoType: helm
|
||||
url: https://presslabs.github.io/charts
|
||||
chart: mysql-operator
|
||||
version: "0.4.0"
|
||||
- name: mysql-cluster
|
||||
type: raw
|
||||
dependsOn:
|
||||
- mysql-controller
|
||||
properties:
|
||||
apiVersion: mysql.presslabs.org/v1alpha1
|
||||
kind: MysqlCluster
|
||||
metadata:
|
||||
name: mysql-cluster
|
||||
spec:
|
||||
replicas: 1
|
||||
# replace it with your secret
|
||||
secretName: mysql-secret
|
||||
```
|
||||
|
||||
#### Apply the files in `clusters/`
|
||||
|
||||
After storing bellow files in the Git config repo, we need to apply the GitOps config files in `clusters/` manually.
|
||||
|
||||
First, apply the `clusters/infra.yaml` to cluster, we can see that the MySQL in `infrastructure/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/infra.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ vela ls
|
||||
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
Apply the `clusters/apps.yaml` to cluster, we can see that the application in `apps/` is automatically deployed:
|
||||
|
||||
```shell
|
||||
vela up -f clusters/apps.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
|
||||
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
|
||||
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
|
||||
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
|
||||
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
|
||||
```
|
||||
|
||||
By deploying the KubeVela GitOps config files, we now automatically apply the application and database in cluster.
|
||||
|
||||
`curl` the Ingress of the app, we can see that the current version is `0.1.5` and the application is connected to the database successfully:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> testsvc.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
|
||||
Version: 0.1.5
|
||||
|
||||
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
```
|
||||
|
||||
### Modify the config for GitOps trigger
|
||||
|
||||
After the first deployment, we can modify the files in config repo to update the applications in the cluster.
|
||||
|
||||
Modify the domain of the application's Ingress:
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: kubevela.example.com
|
||||
http:
|
||||
/: 8089
|
||||
```
|
||||
|
||||
Check the Ingress in cluster after a while:
|
||||
|
||||
```shell
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
```
|
||||
|
||||
The host of the Ingress has been updated successfully!
|
||||
|
||||
In this way, we can edit the files in the Git repo to update the cluster.
|
||||
|
||||
## For developers
|
||||
|
||||
Developers writes the application source code and push it to a Git repo (aka app repo). Once app repo updates, the CI will build the image and push it to the image registry. KubeVela watches the image registry, and updates the image in config repo. Finally, it will apply the config to the cluster.
|
||||
|
||||
User can update the configuration in the cluster automatically when the code is updated.
|
||||
|
||||
|
||||
|
||||
### Setup App Code Repository
|
||||
|
||||
Setup a Git repository with source code and Dockerfile.
|
||||
|
||||
The app serves HTTP service and connects to a MySQL database. In the '/' path, it will display the version in the code; in the `/db` path, it will list the data in database.
|
||||
|
||||
```go
|
||||
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
|
||||
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
|
||||
})
|
||||
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
|
||||
rows, err := db.Query("select * from userinfo;")
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
|
||||
}
|
||||
for rows.Next() {
|
||||
var username string
|
||||
var desc string
|
||||
err = rows.Scan(&username, &desc)
|
||||
if err != nil {
|
||||
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
|
||||
}
|
||||
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
|
||||
}
|
||||
})
|
||||
|
||||
if err := http.ListenAndServe(":8088", nil); err != nil {
|
||||
panic(err.Error())
|
||||
}
|
||||
```
|
||||
|
||||
In this tutorial, we will setup a CI pipeline using GitHub Actions to build the image and push it to a registry. The code and configuration files are from the [Example Repo](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code).
|
||||
|
||||
## Create Git Secret for KubeVela committing to Config Repo
|
||||
|
||||
After the new image is pushed to the image registry, KubeVela will be notified and update the `Application` file in the Git repository and cluster. Therefore, we need a secret with Git information for KubeVela to commit to the Git repository. Fill the following yaml files with your password and apply it to the cluster:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: my-secret
|
||||
type: kubernetes.io/basic-auth
|
||||
stringData:
|
||||
username: <your username>
|
||||
password: <your password>
|
||||
```
|
||||
|
||||
## Setup Config Repository
|
||||
|
||||
The configuration repository is almost the same as the previous configuration, you only need to add the image registry config to the file. For more details, please refer to [Example Repository](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config).
|
||||
|
||||
Add the config of image registry in `clusters/apps.yaml`, it listens for image updates in the image registry:
|
||||
|
||||
```yaml
|
||||
...
|
||||
imageRepository:
|
||||
image: <your image>
|
||||
# if it's a private image registry, use `kubectl create secret docker-registry` to create the secret
|
||||
# secretRef: imagesecret
|
||||
filterTags:
|
||||
# filter the image tag
|
||||
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
|
||||
extract: '$ts'
|
||||
# use the policy to sort the latest image tag and update
|
||||
policy:
|
||||
numerical:
|
||||
order: asc
|
||||
# add more commit message
|
||||
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
|
||||
```
|
||||
|
||||
Modify the image field in `apps/my-app.yaml` and add annotation `# {"$imagepolicy": "default:apps"}`.
|
||||
Notice that KubeVela will only be able to modify the image field if the annotation is added after the field. `default:apps` is `namespace:name` of the GitOps config file above.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
components:
|
||||
- name: my-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
|
||||
```
|
||||
|
||||
After update the files in `clusters/` to cluster, we can then update the application by modifying the code.
|
||||
|
||||
## Modify the code
|
||||
|
||||
Change the `Version` to `0.1.6` and modify the data in database:
|
||||
|
||||
```go
|
||||
const VERSION = "0.1.6"
|
||||
|
||||
...
|
||||
|
||||
func InsertInitData(db *sql.DB) {
|
||||
stmt, err := db.Prepare(insertInitData)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer stmt.Close()
|
||||
|
||||
_, err = stmt.Exec("KubeVela2", "It's another test user")
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Commit the change to the Git Repository, we can see that our CI pipelines has built the image and push it to the image registry.
|
||||
|
||||
KubeVela will listen to the image registry and update the `apps/my-app.yaml` in Git Repository with the latest image tag.
|
||||
|
||||
We can see that there is a commit form `kubevelabot`, the commit message is always with a prefix `Update image automatically.` You can use format like `{{range .Updated.Images}}{{println .}}{{end}}` to specify the image name in the `commitMessage` field.
|
||||
|
||||
|
||||
|
||||
> Note that if you want to put the code and config in the same repository, you need to filter out the commit from KubeVela in CI configuration like below to avoid the repeat build of pipeline.
|
||||
>
|
||||
> ```shell
|
||||
> jobs:
|
||||
> publish:
|
||||
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
|
||||
> ```
|
||||
|
||||
Re-check the `Application` in cluster, we can see that the image of the `my-app` has been updated after a while.
|
||||
|
||||
> KubeVela polls the latest information from the code and image repo periodically (at an interval that can be customized):
|
||||
> * When the `Application` file in the Git repository is updated, KubeVela will update the `Application` in the cluster based on the latest configuration.
|
||||
> * When a new tag is added to the image registry, KubeVela will filter out the latest tag based on your policy and update it to Git repository. When the files in the repository are updated, KubeVela repeats the first step and updates the files in the cluster, thus achieving automatic deployment.
|
||||
|
||||
We can `curl` to `Ingress` to see the current version and data:
|
||||
|
||||
```shell
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
my-server <none> kubevela.example.com <ingress-ip> 80 162m
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
|
||||
Version: 0.1.6
|
||||
|
||||
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
|
||||
User: KubeVela
|
||||
Description: It's a test user
|
||||
|
||||
User: KubeVela2
|
||||
Description: It's another test user
|
||||
```
|
||||
|
||||
The `Version` has been updated successfully! Now we're done with everything from changing the code to automatically applying to the cluster.
|
||||
|
||||
## Summary
|
||||
|
||||
For platform admins/SREs, they update the config repo to operate the application and infrastructure. KubeVela will synchronize the config to the cluster, simplifying the deployment process.
|
||||
|
||||
For end users/developers, they write the source code, push it to Git, and then re-deployment will happen. It will make CI to build the image. KubeVela will then update the image field and apply the deployment config.
|
||||
|
||||
By integrating with GitOps, KubeVela helps users speed up deployment and simplify continuous deployment.
|
||||
|
|
@ -2,43 +2,4 @@
|
|||
title: VelaUX Concept
|
||||
---
|
||||
|
||||
VelaUX is an addon on top of KubeVela, it works as an out-of-box platform which also brings some more concepts.
|
||||
|
||||
|
||||
|
||||
## Project
|
||||
|
||||
Project is where you manage all the applications and collaborate with your team member. Project is one stand alone scope that separates it from other project.
|
||||
|
||||
## Environment
|
||||
|
||||
Environment refers to the environment for development, testing, and production and it can include multiple Delivery Targets. Only applications in the same environment can visit and share resource with each other.
|
||||
|
||||
- <b>Bind Application with Environment</b> The application can be bound to multiple Environments, and for each environment, you can set the unique parameter difference for each environment.
|
||||
|
||||
## Delivery Target
|
||||
|
||||
Delivery Target describes the space where the application resources actually delivered. One target describes one Kubernetes cluster and namespace, it can also describe a region or VPC for cloud providers which includes shared variables and machine resources.
|
||||
|
||||
Kubernetes cluster and Cloud resources are currently the main way for KubeVela application delivery. In one target, credentials of cloud resources created will automatically delievered to the Kubernetes cluster.
|
||||
|
||||
## Application
|
||||
|
||||
An application in VelaUX is a bit different with KubeVela, we add lifecycle includes:
|
||||
|
||||
- <b>Create</b> an application is just create a metadata records, it won't run in real cluster.
|
||||
- <b>Deploy</b> an application will bind with specified environment and instantiate application resource into Kubernetes clusters.
|
||||
- <b>Recycle</b> an application will delete the instance of the application and reclaim its resources from Kubernetes clusters.
|
||||
- <b>Delete</b> an application is actually delete the metadata.
|
||||
|
||||
The rest concept in VelaUX Application are align with KubeVela Core.
|
||||
|
||||
### Revision
|
||||
|
||||
Revision generates each time when the application deployed and holds all infos in one snapshot. You use it for rolling back to whichever version whenever you needed.
|
||||
|
||||
|
||||
## 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.
|
||||
This doc has migrated to [velaux addon introdution](../reference/addons/velaux#concept-of-velaux).
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Manage Clusters with UX
|
||||
title: Manage Clusters on UI Console
|
||||
---
|
||||
|
||||
> This docs requires you to have [velaux](../../../reference/addons/velaux) installed.
|
||||
|
|
@ -20,7 +20,7 @@ For connecting the ACK clusters, the platform will save some cloud info, Region,
|
|||
|
||||
## Manage Delivery Target
|
||||
|
||||
To deploy application components into different places, VelaUX provides a new concept **Delivery Target** for user to manage their deploy destinations not only clusters or namespaces, but also cloud provider information such as region, vpc and so on.
|
||||
To deploy application components into different places, VelaUX provides a new concept **[Delivery Target](../../../reference/addons/velaux#delivery-target)** for user to manage their deploy destinations not only clusters or namespaces, but also cloud provider information such as region, vpc and so on.
|
||||
|
||||
## Cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Introduction
|
||||
title: Overview
|
||||
---
|
||||
|
||||
Once VelaUX is installed, there's a built-in administrator user with full access to the system. It is recommended to use the admin user only for the initial configuration, then switch to another user or configure the SSO integration.
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ Choose `> Cluster: local | Namespace: vela-system | Component: velaux | Kind: Se
|
|||
|
||||
If you are installing it in a remote environment such as a virtual machine, you can refer to [VelaUX addon](./reference/addons/velaux) document to expose an endpoint or other advanced installation arguments.
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
It requires you to override with a new password for the first login, please make sure to remember the new password.
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ After finished [the installation of VelaUX](./install#2-install-velaux), you can
|
|||
vela port-forward addon-velaux -n vela-system 8080:80
|
||||
```
|
||||
|
||||
* VelaUX need authentication, default username is `admin` and the password is `VelaUX12345`.
|
||||
* VelaUX need authentication, default username is `admin` and the password is **`VelaUX12345`**.
|
||||
|
||||
It requires you to override with a new password for the first login, please make sure to remember the new password.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ expected output:
|
|||
Addon: velaux enabled Successfully.
|
||||
```
|
||||
|
||||
VelaUX needs authentication. The default username is `admin` and the password is `VelaUX12345`. Please must set and remember the new password after the first login.
|
||||
VelaUX needs authentication. The default username is `admin` and the password is **`VelaUX12345`**. Please must set and remember the new password after the first login.
|
||||
|
||||
By default, VelaUX didn't have any exposed port.
|
||||
|
||||
|
|
@ -104,4 +104,39 @@ vela addon enable velaux repo=acr.kubevela.net
|
|||
|
||||
You can try to specify the `acr.kubevela.net` image registry as an alternative, It's maintained by KubeVela team, and we will upload/sync the built-in addon image for convenience.
|
||||
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
This feature can also help you to build your private installation, just upload all images to your private image registry.
|
||||
|
||||
## Concept of VelaUX
|
||||
|
||||
VelaUX is an addon on top of KubeVela, it works as UI console for KubeVela, while it's also an out-of-box platform for end-user.
|
||||
|
||||
We add some more concepts for enterprise integration.
|
||||
|
||||
|
||||
|
||||
### Project
|
||||
|
||||
Project is where you manage all the applications and collaborate with your team member. Project is one stand alone scope that separates it from other project.
|
||||
|
||||
### Environment
|
||||
|
||||
Environment refers to the environment for development, testing, and production and it can include multiple Delivery Targets. Only applications in the same environment can visit and share resource with each other.
|
||||
|
||||
- <b>Bind Application with Environment</b> The application can be bound to multiple Environments, and for each environment, you can set the unique parameter difference for each environment.
|
||||
|
||||
### Delivery Target
|
||||
|
||||
Delivery Target describes the space where the application resources actually delivered. One target describes one Kubernetes cluster and namespace, it can also describe a region or VPC for cloud providers which includes shared variables and machine resources.
|
||||
|
||||
Kubernetes cluster and Cloud resources are currently the main way for KubeVela application delivery. In one target, credentials of cloud resources created will automatically delievered to the Kubernetes cluster.
|
||||
|
||||
### Application
|
||||
|
||||
An application in VelaUX is a bit different with KubeVela, we add lifecycle includes:
|
||||
|
||||
- <b>Create</b> an application is just create a metadata records, it won't run in real cluster.
|
||||
- <b>Deploy</b> an application will bind with specified environment and instantiate application resource into Kubernetes clusters.
|
||||
- <b>Recycle</b> an application will delete the instance of the application and reclaim its resources from Kubernetes clusters.
|
||||
- <b>Delete</b> an application is actually delete the metadata.
|
||||
|
||||
The rest concept in VelaUX Application are align with KubeVela Core.
|
||||
|
|
|
|||
|
|
@ -16,27 +16,12 @@ Starting from here, you will learn to use the KubeVela Addons to install plug-in
|
|||
|
||||
## Enable fluxcd addon
|
||||
|
||||
Helm Chart delivery relies on addon in KubeVela, you need to enable `fluxcd` addon before start.
|
||||
Helm Chart delivery relies on addon in KubeVela, you need to enable `fluxcd` addon before start. You can refer to [addon management doc](../end-user/components/more) for more detail information about addon.
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
You can also enable the addon from UI console with more detail information. After `velaux` addon enabled, you can get into the page of `Addon`.
|
||||
This page will automatically list the community Addons that can be installed.
|
||||
They are all from [Community Repo](https://github.com/kubevela/catalog/tree/master/addons).
|
||||
You can check detail information of this addon by clicking the `fluxcd` UI section.
|
||||
|
||||
Details will include:
|
||||
|
||||
- Definitions: The extension capabilities provided by the addon may include component, trait, etc. For the fluxcd addon, it provides two component types, `helm` and `kustomize`, among which `helm` is the type we need to pay attention to and use here.
|
||||
|
||||
- README: Addon description, explain the capabilities and related information.
|
||||
|
||||
We can click the `Enable` button. After the fluxcd addon is enabled, it will be installed on all clusters connected to KubeVela, so it will take a certain amount of time.
|
||||
|
||||
|
||||
|
||||
When the addon status become `enabled`, it means it's ready for helm chart delivery.
|
||||
|
||||
## Creating Redis application
|
||||
|
|
|
|||
|
|
@ -13,82 +13,16 @@ KubeVela supports you to render, orchestrate and deploy Kubernetes objects. The
|
|||
|
||||
## Before starting
|
||||
|
||||
- Prepare a Deployment+Service yaml config resource.
|
||||
- Prepare Kubernetes Resources you want to deploy. In this guide, we'll use a composition of Deployment and Service as example.
|
||||
|
||||
<!-- - For setting up two and more runtime clusters, check out: [Manage Runtime Cluster](./manage-cluster) TODO v1.2-->
|
||||
## Deploy with CLI
|
||||
|
||||
## Scheduling and creating Targets
|
||||
Below is a demo application with Kubernetes objects consist of Deployment and Service.
|
||||
|
||||
[Target](../getting-started/core-concept#target) defines the namespace in runtime cluster for application delivery. Once Target created, namespace in runtime cluster created accordingly.
|
||||
There are two policies and three workflow steps in it:
|
||||
|
||||
Clicking `New Target` into the creating process. Type in necessary Infos as Project, Cluster, Namespace to create. We create targets for 2 clusters. We create targets for 2 clusters. If you only have 1 cluster you can also use its namespaces to create several targets. For now, we at least give it to 3 Targets: 1 for test and 2 for prod environments.
|
||||
|
||||
## Creating Kubernetes application
|
||||
|
||||
After Target was created, we begin to create an application. Same to [Deploy First Application](../quick-start), we need to submit basic Infos:
|
||||
|
||||
(1) Select type: k8s-objects; NOTE that in one application please maintain at most one Workload type of resource, meaning without more than a Deployment or Statefulset.
|
||||
|
||||
(2) We schedule two environments, test and prod. Test environment links to the target for dev and prod environment select the other two targets.
|
||||
|
||||
|
||||
|
||||
(3) Upload your Yaml file. Note that, the name of the resource you specified must not conflict with existing ones. Also, the editor automatically formats the Yaml file.
|
||||
|
||||
|
||||
|
||||
After above, click `Create` to finish.
|
||||
|
||||
## Deploying test environment
|
||||
|
||||
|
||||
|
||||
Enter the further page, the application has automatically generated 2 environments and 2 workflows. Each environment has its workflow by default. A workflow consists of one or more steps such as `deploy2env`.
|
||||
|
||||
Firstly let's switch to the Tab of the test environment, click Deploy on the page. Since we only assigned one target for the test environment, there's one step for workflow. Looking at the status of its execution in the upper-right, it turns green when succeeded. If it shows red means that workflow went into trouble, you can click on the red sign to look through the detailed reason. Fix it accordingly and the deployment will continue to be regained.
|
||||
|
||||
After deployment is finished, refresh the list of instances to see Pods. Click for more if Pod shows abnormality.
|
||||
|
||||
|
||||
|
||||
As for the test environment, it sure can be updated at any time. When we update the parameters(image, instance), execute the workflow for an upgrade. Note that, choose the workflow for the test environment.
|
||||
|
||||
|
||||
|
||||
## Deploying prod environment
|
||||
|
||||
Let's switch to the Tab of the prod environment. It shows that it's not deployed yet. So now you can understand one basic thing for KubeVela, different environments in one application are completely dependant on each other, of each is an individual Application CR.
|
||||
|
||||
As we have two targets for the prod environment, it'll execute in sequence. If you hope to set up a manual approval before it gets into the second target, this is where workflow comes in.
|
||||
|
||||
|
||||
|
||||
we can see two generated workflow. Now we click the `Edit` in the workflow of the prod environment, drag out the `suspend` into the board at the right. Set up the configuration you needed.
|
||||
|
||||
Then we need to orchestrate their sequence. First disconnect existing steps (by clicking the line + delete button), connect the suspend step in the middle. After editing, you need to click the Save button on the upper right to save.
|
||||
|
||||
|
||||
|
||||
Back to the page of prod environment, click Deploy.
|
||||
|
||||
|
||||
|
||||
Monitoring the status on the upper right. When the first target finished deploying, a window pops up for you to give out a command.
|
||||
|
||||
`suspend` has three operations:
|
||||
|
||||
- Rollback: the revision reverts to the latest one in history, even with the first Target.
|
||||
- Terminate: stop the deployment process but it will not change the first Target that already deployed.
|
||||
- Continue: enter the execution of the next step.
|
||||
|
||||
If continued, the deployment goes on. In the list of instances, you can check out all the details.
|
||||
|
||||
|
||||
|
||||
## Deploy kubernetes objects via CLI.
|
||||
|
||||
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.
|
||||
- The policy means we're going to deploy into two namespaces as different environments.
|
||||
- The workflow step means, we will deploy to one environment first, wait for human review after the first step succeeded, then finish the rest step.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -167,27 +101,117 @@ spec:
|
|||
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)
|
||||
- More about the topology policy, refer to [the detail guide](../end-user/policies/references#override).
|
||||
- More about the deploy workflow step, refer to [the detail guide](../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.
|
||||
- You may need to create the namespace with the name `production` before deploying the application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
vela up -f https://kubevela.io/example/applications/create-namespace.yaml
|
||||
```
|
||||
|
||||
- deploy the demo application.
|
||||
- Deploy the demo application.
|
||||
|
||||
```shell
|
||||
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
||||
```
|
||||
|
||||
- review and resume the workflow after the workflow becomes suspended.
|
||||
- Check the status of the application.
|
||||
|
||||
```
|
||||
vela status app-with-k8s-objects
|
||||
```
|
||||
|
||||
You can also check the deployment and service with the `kubectl` or any other tools you familiar to check the deployment.
|
||||
|
||||
- Approve the workflow if everything looks good.
|
||||
|
||||
```shell
|
||||
$ vela workflow resume app-with-k8s-objects
|
||||
vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
The delivery process can be powerful if you're [distributing resources across multi-clusters](../end-user/components/ref-objects).
|
||||
|
||||
|
||||
## Deploy with UI Console
|
||||
|
||||
We can do the same process in KubeVela UI Console if you have enabled [`velaux`](../reference/addons/velaux) addon.
|
||||
|
||||
### Create Delivery Target
|
||||
|
||||
In VelaUX, we use [Delivery Target](../reference/addons/velaux#delivery-target) to describe the space where the application resources actually delivered.
|
||||
It's like syntax sugar to `topology policy` in UI console.
|
||||
|
||||
Refer to [targets management doc](../how-to/dashboard/target/overview#manage-delivery-target) for details and make sure
|
||||
you have 3 targets: 1 for test and 2 for prod environments for our below example.
|
||||
|
||||
### Creating Kubernetes application
|
||||
|
||||
After Target was created, we begin to create an application. Same to [Deploy First Application](../quick-start), we need to submit basic Infos:
|
||||
|
||||
(1) Select type: k8s-objects; NOTE that in one application please maintain at most one Workload type of resource, meaning without more than a Deployment or Statefulset.
|
||||
|
||||
(2) We schedule two environments, test and prod. Test environment links to the target for dev and prod environment select the other two targets.
|
||||
|
||||
|
||||
|
||||
(3) Upload your Yaml file. Note that, the name of the resource you specified must not conflict with existing ones. Also, the editor automatically formats the Yaml file.
|
||||
|
||||
|
||||
|
||||
After above, click `Create` to finish.
|
||||
|
||||
### Deploying test environment
|
||||
|
||||
|
||||
|
||||
Enter the further page, the application has automatically generated 2 environments and 2 workflows. Each environment has its workflow by default. A workflow consists of one or more steps such as `deploy2env`.
|
||||
|
||||
Firstly let's switch to the Tab of the test environment, click Deploy on the page. Since we only assigned one target for the test environment, there's one step for workflow. Looking at the status of its execution in the upper-right, it turns green when succeeded. If it shows red means that workflow went into trouble, you can click on the red sign to look through the detailed reason. Fix it accordingly and the deployment will continue to be regained.
|
||||
|
||||
After deployment is finished, refresh the list of instances to see Pods. Click for more if Pod shows abnormality.
|
||||
|
||||
|
||||
|
||||
As for the test environment, it sure can be updated at any time. When we update the parameters(image, instance), execute the workflow for an upgrade. Note that, choose the workflow for the test environment.
|
||||
|
||||
|
||||
|
||||
### Deploying prod environment
|
||||
|
||||
Let's switch to the Tab of the prod environment. It shows that it's not deployed yet. So now you can understand one basic thing for KubeVela, different environments in one application are completely dependant on each other, of each is an individual Application CR.
|
||||
|
||||
As we have two targets for the prod environment, it'll execute in sequence. If you hope to set up a manual approval before it gets into the second target, this is where workflow comes in.
|
||||
|
||||
|
||||
|
||||
we can see two generated workflow. Now we click the `Edit` in the workflow of the prod environment, drag out the `suspend` into the board at the right. Set up the configuration you needed.
|
||||
|
||||
Then we need to orchestrate their sequence. First disconnect existing steps (by clicking the line + delete button), connect the suspend step in the middle. After editing, you need to click the Save button on the upper right to save.
|
||||
|
||||
|
||||
|
||||
Back to the page of prod environment, click Deploy.
|
||||
|
||||
|
||||
|
||||
Monitoring the status on the upper right. When the first target finished deploying, a window pops up for you to give out a command.
|
||||
|
||||
`suspend` has three operations:
|
||||
|
||||
- Rollback: the revision reverts to the latest one in history, even with the first Target.
|
||||
- Terminate: stop the deployment process but it will not change the first Target that already deployed.
|
||||
- Continue: enter the execution of the next step.
|
||||
|
||||
If continued, the deployment goes on. In the list of instances, you can check out all the details.
|
||||
|
||||
|
||||
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
## Next
|
||||
|
||||
* Learn how to [distribute resources across multi-clusters](../end-user/components/ref-objects).
|
||||
|
|
@ -3,8 +3,7 @@ title: Deploy Container Image
|
|||
description: deploy the business application by kubevela
|
||||
---
|
||||
|
||||
In this section, we will introduce how to deploy a container based application with KubeVela. The main process will be shown with UI console,
|
||||
if you're using CLI, jump to [Deploy via CLI](#deploy-via-cli) part.
|
||||
In this section, we will introduce how to deploy a container based application with KubeVela. The guide will run the whole process with UI console as it's quite the same with the [quick start](../quick-start) if you're using CLI.
|
||||
|
||||
## Before starting
|
||||
|
||||
|
|
@ -23,7 +22,6 @@ After inputting the Image address, the system will load the Image info from the
|
|||
|
||||
You could refer to their information to configure the `Service Ports` and `Persistent Storage`.
|
||||
|
||||
|
||||
|
||||
|
||||
Done by clicking `Create` and then we enter the management page.
|
||||
|
|
|
|||
|
|
@ -157,6 +157,29 @@
|
|||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/case-studies/gitops"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/gitops/fluxcd"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Declarative Workflow",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/tutorials/workflows"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/workflow/component-dependency-parameter"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/workflow/webhook-notification"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -173,14 +196,6 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/version-control"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/tutorials/workflows"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/workflow/component-dependency-parameter"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/policies/apply-once"
|
||||
|
|
|
|||
Loading…
Reference in New Issue