Files
kubevela/docs/en/helm/component.md
Yue Wang baa8d87e71 implemente kube schematic (#1298)
* implemente kube schematic

generate schema for kube schematic parameters

add e2e test

Signed-off-by: roywang <seiwy2010@gmail.com>

* add unit test

Signed-off-by: roy wang <seiwy2010@gmail.com>

* add doc

Signed-off-by: roy wang <seiwy2010@gmail.com>
2021-03-26 23:02:58 +08:00

4.0 KiB

Use Helm To Extend a Component type

This documentation explains how to use Helm chart to define an application component.

Before reading this part, please make sure you've learned the definition and template concepts.

Prerequisite

Write ComponentDefinition

Here is an example ComponentDefinition about how to use Helm as schematic module.

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: webapp-chart
  annotations:
    definition.oam.dev/description: helm chart for webapp
spec:
  workload:
    definition:
      apiVersion: apps/v1
      kind: Deployment
  schematic:
    helm:
      release:
        chart:
          spec:
            chart: "podinfo"
            version: "5.1.4"
      repository:
        url: "http://oam.dev/catalog/"

Just like using CUE as schematic module, we also have some rules and contracts to use helm chart as schematic module.

  • .spec.workload is required to indicate the main workload(apiVersion/Kind) in your Helm chart. Only one workload allowed in one helm chart. For example, in our sample chart, the core workload is deployments.apps/v1, other resources will also be deployed but mechanism of KubeVela won't work for them.
  • .spec.schematic.helm contains information of Helm release & repository.

There are two fields release and repository in the .spec.schematic.helm section, these two fields align with the APIs of fluxcd/flux2. Spec of release aligns with HelmReleaseSpec and spec of repository aligns with HelmRepositorySpec. In a word, just like the fields shown in the sample, the helm schematic module describes a specific Helm chart release and its repository.

Create an Application using the helm based ComponentDefinition

Here is an example Application.

apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
  name: myapp
  namespace: default
spec:
  components:
    - name: demo-podinfo 
      type: webapp-chart 
      properties: 
        image:
          tag: "5.1.2"

Helm module workload will use data in properties as Helm chart values. You can learn the schema of settings by reading the README.md of the Helm chart, and the schema are totally align with values.yaml of the chart.

Helm v3 has support to validate values in a chart's values.yaml file with JSON schemas.
Vela will try to fetch the values.schema.json file from the Chart archive and save the schema into a ConfigMap which can be consumed latter through UI or CLI.
If values.schema.json is not provided by the Chart author, Vela will generate a OpenAPI-v3 JSON schema based on the values.yaml file automatically.

Deploy the application and after several minutes (it takes time to fetch Helm chart from the repo, render and install), you can check the Helm release is installed.

$ helm ls -A
myapp-demo-podinfo	default  	1 	2021-03-05 02:02:18.692317102 +0000 UTC	deployed	podinfo-5.1.4   	5.1.4

Check the deployment defined in the chart has been created successfully.

$ kubectl get deploy
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
myapp-demo-podinfo   1/1     1            1           66m

Check the values(image.tag = 5.1.2) from application's settings are assigned to the chart.

$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
"ghcr.io/stefanprodan/podinfo:5.1.2"