Deploying to Cosmonic Control
Cosmonic Control separates operator and developer concerns: Wasm component developers adopt their own tooling to create Wasm binaries, while operators use standard cloud-native pipelines and tooling to manage deployments.
In this section for operators, you'll learn...
- What are Cosmonic Control deployment manifests?
- What is a Component CRD?
- What is a Provider CRD?
- What is a Config CRD?
- How to deploy CRD manifests manually
What are Cosmonic Control deployment manifests?
Deploying a workload to Cosmonic Control is the same as deploying any other resource to Kubernetes, using declarative Custom Resource Definition (CRD) manifests written in YAML.
Workload manifests can be deployed manually with kubectl
and used in pipelines with tools like Argo CD. Manifests are composed according to the runtime.wasmcloud.dev/v1alpha1
API.
In order to explain the deployment model, we will examine the CRD manifests for our HTTP Server template. These manifests include the three core user-facing CRDs for workloads:
What is a Component CRD?
The Component CRD defines the deployment for the Wasm component comprising our workload's core logic.
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: Component
metadata:
name: http-server
spec:
image: ghcr.io/cosmonic-labs/components/http-server:0.1.0
concurrency: 100
replicas: 1
hostSelector:
matchLabels:
"hostgroup": "default"
exports:
- wit:
namespace: wasi
package: http
interfaces:
- incoming-handler
target:
provider:
name: http-server
namespace: default
The Component spec
for the HTTP Server template defines the following fields:
image
: The registry address for the OCI artifact containing the Wasm component.concurrency
: The per-replica invocation rate limit (per second) for the component.replicas
: The number of hosts that should be running this component.hostSelector
: Define the Host Group(s) to which the component should be deployed—in this case, Host Groups with thehostgroup
label "default
"exports
: The interfaces exported by the component, defined by thenamespace
,package
, andinterfaces
of thewit
as well as thetarget
linked entity.
A Component deployment owns and manages ComponentReplica CRDs, which are generated by the system upon deployment. ComponentReplicas represent an individual instantiation of a component on a host. In this sense, you can think of the Component resource as analogous to a Kubernetes Deployment, which owns and manages individual Pods.
What is a Provider CRD?
The Provider CRD defines the deployment for the swappable, reusable wasmCloud capability provider responsible for basic HTTP functionality.
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: Config
metadata:
name: http-server
spec:
config:
- name: default_address
value: "0.0.0.0:9092"
- name: routing_mode
value: host
The Provider spec
for the HTTP Server template defines the following fields:
image
: The registry address for the OCI artifact containing the provider.replicas
: The number of hosts that should be running this provider.hostSelector
: Define the Host Group(s) to which the provider should be deployed—in this case, Host Groups with thehostgroup
label "default
"configFrom
: Thename
of the Config to use for the provider.
A Provider deployment owns and manages ProviderReplica CRDs, which are generated by the system upon deployment. ProviderReplicas represent an individual instantiation of a provider on a host. In this sense, you can think of the Provider resource as analogous to a Kubernetes Deployment, which owns and manages individual Pods.
What is a Config CRD?
In this template, the Config CRD contains configuration data utilized by the provider. Configs may be referenced by both Components and Providers.
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: Config
metadata:
name: http-server
spec:
config:
- name: default_address
value: "0.0.0.0:9092"
The Config for the HTTP Server template defines the following field:
config
: Paired keys and values (name
andvalue
) that can be passed to a component or provider for runtime configuration.
How to deploy CRD manifests manually
From the root of the http-server
directory, you can deploy the manifest with kubectl
(or other tools that interact with the Kubernetes API):
kubectl apply -f ./manifests
Further reading
You can find other examples of CRD manifests in our Template Catalog.
Many existing wasmCloud applications include OAM-formatted YAML manifests designed for vanilla wasmCloud deployments. These OAM manifests are not Kubernetes-native and are not to be confused with the CRD manifests used by Cosmonic Control. (OAM manifests can be identified by the API version core.oam.dev/v1beta1
.)
A wash
plugin for easily converting OAM manifests to CRDs will be released soon.