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:

• Component
• Provider
• Config

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 the hostgroup label "default"
• exports: The interfaces exported by the component, defined by the namespace, package, and interfaces of the wit as well as the target 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 the hostgroup label "default"
• configFrom: The name 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 and value) 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.

note

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.