CUE Components
In this section, it will introduce how to use CUE to declare app components via ComponentDefinition
.
Before reading this part, please make sure you've learned the Definition CRD in KubeVela.
ComponentDefinition
#
Declare First, generate ComponentDefinition
scaffolds via vela def init
with existed YAML file.
The YAML file:
Generate ComponentDefinition
based on the YAML file:
It generates a file:
In detail:
.spec.workload
is required to indicate the workload type of this component..spec.schematic.cue.template
is a CUE template, specifically:- The
output
filed defines the template for the abstraction. - The
parameter
filed defines the template parameters, i.e. the configurable properties exposed in theApplication
abstraction (and JSON schema will be automatically generated based on them).
- The
Add parameters in this auto-generated custom component file :
You can use vela def vet
to validate the format:
Declare another component named task
which is an abstraction for run-to-completion workload.
It generates a file:
Edit the generated component file:
Apply above ComponentDefinition
files to your Kubernetes cluster:
Application
#
Declare an The ComponentDefinition
can be instantiated in Application
abstraction as below:
#
Under The HoodAbove application resource will generate and manage following Kubernetes resources in your target cluster based on the output
in CUE template and user input in Application
properties.
Context
#
CUE KubeVela allows you to reference the runtime information of your application via context
keyword.
The most widely used context is application name(context.appName
) component name(context.name
).
For example, let's say you want to use the component name filled in by users as the container name in the workload instance:
Note that
context
information are auto-injected before resources are applied to target cluster.
context
#
Full available information in CUE Context Variable | Description |
---|---|
context.appRevision | The revision of the application |
context.appRevisionNum | The revision number(int type) of the application, e.g., context.appRevisionNum will be 1 if context.appRevision is app-v1 |
context.appName | The name of the application |
context.name | The name of the component of the application |
context.namespace | The namespace of the application |
context.output | The rendered workload API resource of the component, this usually used in trait |
context.outputs.<resourceName> | The rendered trait API resource of the component, this usually used in trait |
#
CompositionIt's common that a component definition is composed by multiple API resources, for example, a webserver
component that is composed by a Deployment and a Service. CUE is a great solution to achieve this in simplified primitives.
Another approach to do composition in KubeVela of course is using Helm.
#
How-toKubeVela requires you to define the template of workload type in output
section, and leave all the other resource templates in outputs
section with format as below:
The reason for this requirement is KubeVela needs to know it is currently rendering a workload so it could do some "magic" like patching annotations/labels or other data during it.
Below is the example for webserver
definition:
Apply to your Kubernetes cluster:
The user could now declare an Application
with it:
It will generate and manage below API resources in target cluster:
#
What's NextPlease check the Learning CUE documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.