github/kubevela
1
0
Fork 0
mirror of https://github.com/kubevela/kubevela.git synced 2026-08-19 04:26:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

Focus on appfile in docs (part 2)

Browse Source
This commit is contained in:
Harry Zhang
2020-11-10 17:36:56 -08:00
parent 1681fe7de2
commit 36d2b9e761
12 changed files with 487 additions and 333 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/_sidebar.md
+19 -16
View File
@@ -3,31 +3,34 @@
- [Getting Started](/en/quick-start.md)
- Using KubeVela
- [Setting Up Deployment Environment](/en/developers/config-enviroments.md)
- [Initializing Application](/en/developers/app-init.md)
- [Setting Routes](/en/developers/set-route.md)
- [Setting Auto-scaling Policy](/en/developers/set-autoscale.md)
- [Setting Rollout Strategy](/en/developers/set-rollout.md)
- [Monitoring Application](/en/developers/set-metrics.md)
- [Using Appfile](/en/developers/devex/appfile.md)
- [Check Application Logs](/en/developers/check-logs.md)
- [Execute Commands in Container](/en/developers/exec-cmd.md)
- [Port Forward to Container](/en/developers/port-forward.md)
- [Configuring data/env in Application](/en/developers/config-app.md)
- [Consuming Cloud Services](/en/developers/cloud-service.md)
- [Managing Capabilities](/en/developers/cap-center.md)
- [Capability References](/en/developers/references/README.md)
- Appfile
- [Learning Appfile](/en/developers/devex/appfile.md)
- Operating
- [Port Forwarding](/en/developers/port-forward.md)
- [Setting Routes](/en/developers/set-route.md)
- [Setting Auto-scaling Policy](/en/developers/set-autoscale.md)
- [Setting Rollout Strategy](/en/developers/set-rollout.md)
- [Monitoring Application](/en/developers/set-metrics.md)
- Debugging
- [Check Application Logs](/en/developers/check-logs.md)
- [Execute Commands in Container](/en/developers/exec-cmd.md)
- Extensibility
- [Managing Capabilities](/en/developers/cap-center.md)
- Configuring
- [Setting Up Deployment Environment](/en/developers/config-enviroments.md)
- [Configuring data/env in Application](/en/developers/config-app.md)
- [Alternative Commands](/en/developers/alternative-cmd.md)
- Extending KubeVela
- [Add Trait](/en/platform-engineers/trait.md)
- [Add Workload Type](/en/platform-engineers/workload-type.md)
- [Add Cloud Resource](/en/platform-engineers/cloud-resource.md)
- [Add Cloud Services](/en/platform-engineers/cloud-resource.md)
- Roadmap
- [KubeVela Roadmap](/en/roadmap.md)
- Reference
- [Concepts and Glossaries](/en/concepts.md)
- [Capability Documentation](/en/developers/references/README.md)
- CLI
- General
- [vela config](/en/cli/vela_config.md)
docs/en/developers/alternative-cmd.md
+286
View File
@@ -0,0 +1,286 @@
# Alternatives Commands
Besides Appfile, KubeVela also provides a set of alternatives commands to deploy the application. Think about "shortcuts" that could generate and apply Appfile without the need to write YAML file manually.
> NOTE: These shortcuts are based on Appfile and designed for quick demo purpose only, we would recommend using Appfile instead for serious usage of KubeVela.
## `vela init`
A shortcut to initialize and deploy an application with one service, run:
> If you only want to initialize the Appfile only (i.e. dry run), add `--render-only` flag
```bash
$ vela init
Welcome to use KubeVela CLI! We're going to help you run applications through a couple of questions.
Environment: default, namespace: default
? What is the domain of your application service (optional): example.com
? What is your email (optional, used to generate certification):
? What would you like to name your application (required): testapp
? Choose the workload type for your application (required, e.g., webservice): webservice
? What would you like to name this webservice (required): testsvc
? specify app image crccheck/hello-world
? specify port for container 8000
...
✅ Application Deployed Successfully!
- Name: testsvc
Type: webservice
HEALTHY Ready: 1/1
Routes:
Last Deployment:
Created at: ...
Updated at: ...
```
Check the application:
```bash
$ vela show testapp
About:
Name: testapp
Created at: ...
Updated at: ...
Environment:
Namespace: default
Services:
- Name: testsvc
WorkloadType: webservice
Arguments:
image: crccheck/hello-world
port: 8000
Traits:
```
## `vela svc deploy`
A shortcut to initialize and deploy service one by one.
Firstly, check the available workload types.
```bash
$ vela workloads
NAME DESCRIPTION
worker Backend worker without ports exposed
webservice Long running service with network routes
```
Deploy the first service named `frontend` with `Web Service` type:
```bash
$ vela svc deploy frontend --app testapp -t webservice --image crccheck/hello-world
App testapp deployed
```
Deploy the second service named `backend` with "Backend Worker" type:
```bash
$ vela svc deploy backend --app testapp2 -t worker --image crccheck/hello-world
App testapp2 deployed
```
```bash
$ vela ls
SERVICE APP TYPE TRAITS STATUS CREATED-TIME
frontend testapp ...
backend testapp ...
```
## `vela route`
A shortcut to add route config.
```bash
$ vela route testapp --domain frontend.mycustom.domain
Adding route for app frontend
Rendering configs for service (frontend)...
⠋ Deploying ...
✅ Application Deployed Successfully!
Showing status of service(type: webservice) frontend deployed in Environment myenv
Service frontend Status: HEALTHY Ready: 1/1
route: Visiting URL: http://frontend.mycustom.domain IP: 123.57.10.233
Last Deployment:
Created at: 2020-10-29 15:45:13 +0800 CST
Updated at: 2020-10-29T16:12:45+08:00
```
Then you will be able to visit by:
```shell script
$ curl -H "Host:frontend.mycustom.domain" 123.57.10.233
```
If you have domain set in deployment environment
```bash
$ vela route testapp
Adding route for app frontend
Rendering configs for service (frontend)...
⠋ Deploying ...
✅ Application Deployed Successfully!
Showing status of service(type: webservice) frontend deployed in Environment default
Service frontend Status: HEALTHY Ready: 1/1
route: Visiting URL: https://frontend.123.57.10.233.xip.io IP: 123.57.10.233
Last Deployment:
Created at: 2020-10-29 11:26:46 +0800 CST
Updated at: 2020-10-29T11:28:01+08:00
```
## `vela autoscale`
A shortcut to autoscale the service.
```console
$ vela autoscale helloworld --svc frontend --min 1 --max 5 --cpu 5
Adding autoscale for app frontend
⠋ Checking Status ...
✅ Application Deployed Successfully!
- Name: frontend
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cpu cpu-utilization(target/current): 5%/0% replicas(min/max/current): 1/5/0
Last Deployment:
Created at: 2020-11-06 16:10:54 +0800 CST
Updated at: 2020-11-06T16:19:04+08:0
```
## `vela metric`
A shortcut to add metrics config.
If your application has exposed metrics, you can easily setup monitoring system
with the help of `metric` capability.
Let's run [`christianhxc/gorandom:1.0`](https://github.com/christianhxc/prometheus-tutorial) as an example app.
The app will emit random latencies as metrics.
```bash
$ vela svc deploy metricapp -t webservice --image christianhxc/gorandom:1.0 --port 8080
```
Then add metric by:
```bash
$ vela metric metricapp
Adding metric for app metricapp
⠋ Deploying ...
✅ Application Deployed Successfully!
- Name: metricapp
Type: webservice
HEALTHY Ready: 1/1
Routes:
- ✅ metric: Monitoring port: 8080, path: /metrics, format: prometheus, schema: http.
Last Deployment:
Created at: 2020-11-02 14:31:56 +0800 CST
Updated at: 2020-11-02T14:32:00+08:00
```
The metrics trait will automatically discover port and label to monitor if no parameters specified.
If more than one ports found, it will choose the first one by default.
Verify that the metrics are collected on prometheus
<details>
```shell script
$ kubectl --namespace monitoring port-forward `k -n monitoring get pods -l prometheus=oam -o name` 9090
```
Then access the prometheus dashboard via http://localhost:9090/targets
</details>
## `vela rollout`
A shortcut to add rollout config.
Firstly, deploy your app by:
```shell script
$ vela svc deploy testapp -t webservice --image oamdev/testapp:v1 --port 8080
App testapp deployed
```
Add route for visit:
```shell script
$ vela route testapp --domain myhost.com
Adding route for app testapp
⠋ Checking Status ...
✅ Application Deployed Successfully!
- Name: testapp
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ route: Visiting URL: http://myhost.com IP: <your-ingress-IP-address>
Last Deployment:
Created at: 2020-11-09 12:50:30 +0800 CST
Updated at: 2020-11-09T12:51:19+08:00
```
```shell script
$ curl -H "Host:myhost.com" http://<your-ingress-IP-address>/
Hello World%
```
Secondly, add rollout policy for your app:
```shell script
$ vela rollout testapp --replica 5 --step-weight 20 --interval 5s
```
Then update your app by:
```shell script
$ vela svc deploy testapp -t webservice --image oamdev/testapp:v2 --port 8080
```
Then it will rolling update your instance, you could try `curl` your app multiple times:
```shell script
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World -- Updated Version Two!%
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World%
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World%
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World -- Updated Version Two!%
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World%
$ curl -H "Host:myhost.com" http://39.97.232.19/
Hello World -- Updated Version Two!%
```
It will return both version of output info as both instances are all existing.
<details>
<summary>Under the hood, it was flagger canary running.</summary>
```shell script
$ kubectl get canaries.flagger.app testapp-trait-76fc76fddc -w
NAME STATUS WEIGHT LASTTRANSITIONTIME
testapp-trait-76fc76fddc Progressing 0 2020-11-10T09:06:10Z
testapp-trait-76fc76fddc Progressing 20 2020-11-10T09:06:30Z
testapp-trait-76fc76fddc Progressing 40 2020-11-10T09:06:40Z
testapp-trait-76fc76fddc Progressing 60 2020-11-10T09:07:31Z
testapp-trait-76fc76fddc Promoting 0 2020-11-10T09:08:00Z
testapp-trait-76fc76fddc Promoting 100 2020-11-10T09:08:10Z
testapp-trait-76fc76fddc Finalising 0 2020-11-10T09:08:20Z
testapp-trait-76fc76fddc Succeeded 0 2020-11-10T09:08:30Z
```
</details>
docs/en/developers/app-init.md
-94
View File
@@ -1,94 +0,0 @@
# Initializating Application
## `vela init`
To initialize and deploy an application with one service, run:
> If you only want to initialize without deploying the app, add `--render-only` flag
```bash
$ vela init
Welcome to use KubeVela CLI! We're going to help you run applications through a couple of questions.
Environment: default, namespace: default
? What is the domain of your application service (optional): example.com
? What is your email (optional, used to generate certification):
? What would you like to name your application (required): testapp
? Choose the workload type for your application (required, e.g., webservice): webservice
? What would you like to name this webservice (required): testsvc
? specify app image crccheck/hello-world
? specify port for container 8000
...
✅ Application Deployed Successfully!
- Name: testsvc
Type: webservice
HEALTHY Ready: 1/1
Routes:
Last Deployment:
Created at: ...
Updated at: ...
```
Check the application:
```bash
$ vela show testapp
About:
Name: testapp
Created at: ...
Updated at: ...
Environment:
Namespace: default
Services:
- Name: testsvc
WorkloadType: webservice
Arguments:
image: crccheck/hello-world
port: 8000
Traits:
```
## Deploy Multiple Services
You can also use KubeVela CLI to deploy multiple services for an application.
Check the available workload types.
```bash
$ vela workloads
NAME DESCRIPTION
worker Backend worker without ports exposed
webservice Long running service with network routes
```
Deploy the first service named `frontend` with `Web Service` type:
```bash
$ vela svc deploy frontend --app testapp -t webservice --image crccheck/hello-world
App testapp deployed
```
> TODO auto generate a random application name, so --app testapp becomes optional
Deploy the second service named `backend` with "Backend Worker" type:
```bash
$ vela svc deploy backend --app testapp2 -t worker --image crccheck/hello-world
App testapp2 deployed
```
```bash
$ vela ls
SERVICE APP TYPE TRAITS STATUS CREATED-TIME
frontend testapp ...
backend testapp ...
```
docs/en/developers/cap-center.md
+6 -6
View File
@@ -1,8 +1,8 @@
# Managing Capabilities
This tutorial talks about how to install capabilities (caps) from remote centers.
Developers can install more capabilities (workload types and traits) from any GitHub repo that contains OAM definition objects (i.e. capability center).
## Add Cap Center
## Add Capability Center
Add and sync a remote center:
@@ -16,7 +16,7 @@ successfully sync 1/1 from my-center remote center
sync finished
```
## List Cap Centers
## List Capability Centers
```bash
$ vela cap center ls
@@ -30,7 +30,7 @@ my-center https://github.com/oam-dev/catalog/tree/master/registry
$ vela cap center remove my-center
```
## List Caps
## List Capabilities
```bash
$ vela cap ls my-center
@@ -38,7 +38,7 @@ NAME CENTER TYPE DEFINITION STATUS APPLIES-TO
kubewatch my-center trait kubewatches.labs.bitnami.com uninstalled []
```
## Install Cap
## Install Capability
```bash
$ vela cap install my-center/kubewatch
@@ -61,7 +61,7 @@ kubewatch trait Add a watch for resource
...
```
## Uninstall Cap
## Uninstall Capability
> Note: make sure no apps are using the capability before uninstalling.
docs/en/developers/cloud-service.md
-68
View File
@@ -1,68 +0,0 @@
# Cloud service
In this demo, we will add an RDS database from Alibaba Cloud to our application.
## What is cloud service
Cloud service refers to the managed cloud resources. For example, you can buy a PostgreSql database from a cloud vendor instead of setting up your own. Cloud service are normally outside of your Kubernetes cluster, but logically they are still part of your application. KubeVela provides application centric view of your applications. It will treat every service the same.
## Crossplane
Crossplane is an open source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. The benefit of using Crossplane is it will provide centralized control plane disregard where your cluster is.
KubeVela will delegate the lifecycle management of cloud service to Crossplane.
## Install Crossplane (This demo uses crossplane version 0.13)
You will need a Kubernetes cluster ver> 1.16 (Minikube and Kind clusters are fine).
Also you will need to have KubeVela installed on the cluster.
The folder that containes all the demo scripts are under [examples/kubecondemo/](https://github.com/oam-dev/kubevela.io/tree/master/examples/kubecondemo). For your convience, cd to that folder first:
`cd examples/kubecondemo/`
To provision a cloud resource, you need to have the Access Key and Secret to your Alibaba cloud account.
* Create crossplane namespace: `kubectl create ns crossplane-system`
* Install crossplane helm chart: `helm install crossplane charts/crossplane/ --namespace crossplane-system`
* Install crossplane cli: `curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/install.sh | sh`
* Add crossplane to `PATH`: `sudo mv kubectl-crossplane /usr/local/bin`
* Configure cloud provider(Alibaba Cloud)
* Add cloud provider: `kubectl crossplane install provider crossplane/provider-alibaba:v0.3.0`
* Create provider secret: `kubectl create secret generic alibaba-creds --from-literal=accessKeyId=<change here> --from-literal=accessKeySecret=<change here> -n crossplane-system`
* Configure the provider: `kubectl apply -f script/provider.yaml`
* Configure infrastructure: `kubectl crossplane install configuration crossplane/getting-started-with-alibaba:v0.13`
So far we have configured Crossplane on the cluster.
## Import the database workload definition
First, register the db workload definition:
`kubectl apply -f script/def_db.yaml`
The webservice workload is different from the default version so we have to overwrite it.
`kubectl apply -f cript/webservice.yaml`
Don't forget to update vela:
`vela system update`
## Apply the appfile
In the Appfile, we claim an RDS instance just like other services:
``` yaml
database:
type: rds
name: alibabaRds
...
```
Next, we start the application:
`vela up`
## Verify the database status
Under the hood, we can verify the status of database(usually takes >6 min to be ready):
`kubectl get postgresqlinstance`
When the database is ready, you can see the `READY: True` output.
## Access the web-ui
In the Appfile we added a route trait. To access the web-ui, please check out the [route](set-route.md) documentation.
docs/en/developers/config-enviroments.md
+21 -1
View File
@@ -1,6 +1,6 @@
# Setting Up Deployment Environment
Before working with your application, you need to prepare a deployment environment (e.g. test, staging, prod etc) which will configure the workspace, email for certificate issuer and domain for your application.
A deployment environment is where you could configure the workspace, email for certificate issuer and domain for your applications globally. A typical set of deployment environment is `test`, `staging`, `prod`, etc.
## Create environment
@@ -67,4 +67,24 @@ $ vela env init demo --domain 123.57.10.233.xip.io
environment demo updated, Namespace: demo, Email: my@email.com
```
### Using domain in Appfile
Since you now have domain configured globally in deployment environment, you don't need to specify the domain in route configuration anymore.
```yaml
# in demo environment
servcies:
express-server:
...
route:
rules:
- path: /testapp
rewriteTarget: /
```
```
$ curl http://123.57.10.233.xip.io/testapp
Hello World
```
docs/en/developers/devex/appfile.md
+8 -79
View File
@@ -1,7 +1,6 @@
# Using Appfile for More Flexible Configuration
# Learning Appfile Step by Step
Appfile supports more flexible options than CLI/UI to configure appliation deployment on Vela.
A detailed design doc could be found [here](https://github.com/oam-dev/kubevela/blob/master/docs/design/appfile-design.md).
Appfile is the main user interface to configure application deployment on Vela.
In this tutorial, we will build and deploy an example NodeJS app under [examples/testapp/](https://github.com/oam-dev/kubevela.io/tree/master/examples/testapp).
@@ -111,7 +110,7 @@ Then deploy the app to kind:
$ vela up
```
### [Optional] Check rendered manifests
<details><summary>(Advanced) Check rendered manifests</summary>
By default, Vela renders the final manifests in `.vela/deploy.yaml`:
@@ -146,81 +145,9 @@ metadata:
spec:
...
```
</details>
## 3. Add routing
Add routing config under `express-server`:
```yaml
servcies:
express-server:
...
route:
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
```
Apply again:
```bash
$ vela up
```
Check the status until we see route trait ready:
```bash
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: ...
Updated at: ...
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: ...
Updated at: ...
Routes:
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
```
**In [kind cluster setup](../../install.md#kind)**, you can visit the service via localhost:
> If not in kind cluster, replace localhost with ingress address
```
$ curl -H "Host:example.com" http://localhost/testapp
Hello World
```
## 4. Add auto scaling
```yaml
name: testapp
services:
express-server:
...
autoscale:
minReplicas: 1
maxReplicas: 4
cron:
startAt: "14:00"
duration: "2h"
days: "Monday, Thursday"
replicas: "2"
timezone: "America/Seattle"
```
## [Optional] Configure "task" workload type
## [Optional] Configure another workload type
By now we have deployed a *webservice* workload. We can also add a *task* workload in appfile:
@@ -236,12 +163,14 @@ services:
...
```
Then deploy appfile again:
Then deploy appfile again to update the application:
```bash
$ vela up
```
> Interested in the design of Appfile? A detailed design doc could be found [here](https://github.com/oam-dev/kubevela/blob/master/docs/design/appfile-design.md).
## What's Next?
Congratulations! You have just deployed an app using Vela.
docs/en/developers/port-forward.md
+14 -5
View File
@@ -1,12 +1,21 @@
# Port Forward to Container
# Port Forwarding
Run:
Once your web services of the application deployed, you can access it locally via `port-forward`.
```bash
$ vela svc ls
NAME APP WORKLOAD TRAITS STATUS CREATED-TIME
express-server testapp webservice Deployed 2020-09-18 22:42:04 +0800 CST
```
It will directly open browser for you.
```bash
$ vela port-forward testapp
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
```
Handling connection for 8080
```
docs/en/developers/references/README.md
+5 -6
View File
@@ -1,9 +1,8 @@
# KubeVela Capability References
# Capability Documentation
- [workload types](https://github.com/oam-dev/kubevela.io/tree/master/en/developers/references/workload-types)
- [trait](https://github.com/oam-dev/kubevela.io/tree/master/en/developers/references/traits)
> Note: All the contents under this directory are designed to be referenced by other documentations as the full schema or usage of specific workload types or traits.
Learning the detailed schema of every [workload type](https://github.com/oam-dev/kubevela/tree/master/docs/en/developers/references/workload-types)
and [trait](https://github.com/oam-dev/kubevela/tree/master/docs/en/developers/references/traits) supported in KubeVela.
Note: All the contents under this directory are designed to be referenced by other documentations as the full schema or usage of specific workload types or traits.
In the upcoming releases, we plan to auto-generate all these reference documentations from the CUE templates in KubeVela's definition objects.
> In the upcoming releases, we plan to auto-generate all these reference documentations from the CUE templates in KubeVela's definition objects, and developers could read them by simply `$ vela show <trait_name>`.
docs/en/developers/set-route.md
+40 -58
View File
@@ -1,72 +1,54 @@
# Setting Routes
Once your web services of the application deployed, you can visit it locally via `port-forward` or
from outside world via `route` feature.
The `route` section is used to configure the access to your app.
Add routing config under `express-server`:
```yaml
servcies:
express-server:
...
route:
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
```
Apply again:
```bash
$ vela svc ls
NAME APP WORKLOAD TRAITS STATUS CREATED-TIME
frontend testapp webservice Deployed 2020-09-18 22:42:04 +0800 CST
$ vela up
```
## `port-forward`
It will directly open browser for you.
Check the status until we see route trait ready:
```bash
$ vela port-forward testapp
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
$ vela status testapp
About:
Forward successfully! Opening browser ...
Handling connection for 8080
Handling connection for 8080
Name: testapp
Namespace: default
Created at: ...
Updated at: ...
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: ...
Updated at: ...
Routes:
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
```
## `route`
**In [kind cluster setup](../../install.md#kind)**, you can visit the service via localhost:
`route` is mainly used for public visiting your app.
> If not in kind cluster, replace localhost with ingress address
### If you have didn't configure domain in environment
You can manually configure it by setting domain parameter.
```bash
$ vela route testapp --domain frontend.mycustom.domain
Adding route for app frontend
Rendering configs for service (frontend)...
⠋ Deploying ...
✅ Application Deployed Successfully!
Showing status of service(type: webservice) frontend deployed in Environment myenv
Service frontend Status: HEALTHY Ready: 1/1
route: Visiting URL: http://frontend.mycustom.domain IP: 123.57.10.233
Last Deployment:
Created at: 2020-10-29 15:45:13 +0800 CST
Updated at: 2020-10-29T16:12:45+08:00
```
Then you will be able to visit by:
```shell script
$ curl -H "Host:frontend.mycustom.domain" 123.57.10.233
```
### If you have domain set in environment
```bash
$ vela route testapp
Adding route for app frontend
Rendering configs for service (frontend)...
⠋ Deploying ...
✅ Application Deployed Successfully!
Showing status of service(type: webservice) frontend deployed in Environment default
Service frontend Status: HEALTHY Ready: 1/1
route: Visiting URL: https://frontend.123.57.10.233.xip.io IP: 123.57.10.233
Last Deployment:
Created at: 2020-10-29 11:26:46 +0800 CST
Updated at: 2020-10-29T11:28:01+08:00
$ curl -H "Host:example.com" http://localhost/testapp
Hello World
```
docs/en/platform-engineers/cloud-resource.md
View File
docs/en/platform-engineers/cloud-services.md
+88
View File
@@ -0,0 +1,88 @@
# Cloud service
In this tutorial, we will add a Alibaba Cloud's RDS service as a new workload type in KubeVela.
## Step 1: Install and configure Crossplane (v0.13)
In this tutorial, we use Crossplane as the cloud resource operator for Kubernetes.
<details>
To make this process more easier, we provide all the needed scripts in [this folder](https://github.com/oam-dev/kubevela.io/tree/master/examples/kubecondemo).
Please do:
```console
$ cd examples/kubecondemo/
```
You also need to have the Access Key and Secret to your Alibaba Cloud account by hand and then follow the steps below.
* Create crossplane namespace: `kubectl create ns crossplane-system`
* Install crossplane helm chart: `helm install crossplane charts/crossplane/ --namespace crossplane-system`
* Install crossplane cli: `curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-0.13/install.sh | sh`
* Add crossplane to `PATH`: `sudo mv kubectl-crossplane /usr/local/bin`
* Configure cloud provider(Alibaba Cloud)
* Add cloud provider: `kubectl crossplane install provider crossplane/provider-alibaba:v0.3.0`
* Create provider secret: `kubectl create secret generic alibaba-creds --from-literal=accessKeyId=<change here> --from-literal=accessKeySecret=<change here> -n crossplane-system`
* Configure the provider: `kubectl apply -f script/provider.yaml`
* Configure infrastructure: `kubectl crossplane install configuration crossplane/getting-started-with-alibaba:v0.13`
So far we have configured Crossplane on the cluster.
</details>
## Step 2: Add Workload Definition
First, register the `rds` workload type to KubeVela:
```console
kubectl apply -f script/def_db.yaml
```
Check the new workload type is added:
```console
$ vela workloads
```
## Step 3: Verify RDS workload type in Appfile
Now in the Appfile, we claim an RDS instance with workload type of `rds`:
``` yaml
name: lab3
services:
...
database:
type: rds
name: alibabaRds
...
```
> Please check the full application sample in [tutorial folder](https://github.com/oam-dev/kubevela.io/blob/master/examples/kubecondemo/vela.yaml).
Next, we could deploy the application with `$ vela up`
**(Optional) Verify the database status**
<details>
We can verify the status of database (usually takes 6 min to be ready):
```console
$ kubectl get postgresqlinstance`
```
When the database is ready, you can see the `READY: True` output.
</details>
### Access the application
In the Appfile we added a route trait with domain of `kubevela.kubecon.demo`.
So the application should be accessable via:
```
$ curl -H "Host:kubevela.kubecon.demo" http://localhost:8080
```