Skip to content

Install a Component

With a cluster running, let's get some software ready to run on it. In ConfigHub, configuration is organized around components: a component is a logical piece of software together with the configuration that describes how it runs. A component is never deployed itself — it is made up of variants: a base holding the shared configuration, and deployments, one per place the component runs. A deployment is what you deploy.

In this step you'll install a component — CubbyChat, a small chat app — from a config bundle, then look at what was created.

Install CubbyChat

cub variant upload --component cubbychat --variant base \
    oci://ghcr.io/confighub/configs/cubbychat

The bundle is a plain package of Kubernetes YAML — no templates, just literal configuration. cub variant upload pulls it and stores its contents in ConfigHub as the component's base. Nothing is running yet — ConfigHub stores configuration; making it live is a separate, deliberate step.

What got created

The new base variant is now part of the component "cubbychat". You can list components with:

cub component list

You can view this new component in the web UI with:

cub component open cubbychat

This will open up your browser on the component view page for cubbychat on hub.confighub.com.

Each variant of a component is stored as a space, grouped into the component by labels. List the component's spaces:

cub space list --where "Labels.Component = 'cubbychat'"

There's one so far — cubbychat-base, the base: the complete configuration for CubbyChat, labeled Component=cubbychat and Variant=base. It has no target; it exists to create deployments from. The base records where it came from in an ExternalSource annotation (the bundle reference and its digest):

cub space get cubbychat-base -o jq='.Space.Annotations'

The configuration itself lives in units inside the base space:

cub unit list --space cubbychat-base

There are seven — backend, backend-service, frontend, frontend-service, postgres, postgres-service, and namespace. Every resource in the bundle becomes its own unit, named for the resource rather than for the file it came from: a workload keeps its bare name, and everything else takes its kind. So the resources define how the component's configuration is organized, not the package's file layout. Inspect one:

cub unit data --space cubbychat-base backend

This is ordinary Kubernetes YAML: the Deployment on its own, since its Service is the separate backend-service unit. Notice the namespace field says confighubplaceholder. The base doesn't know where it will run; each deployment fills in its own namespace. This is a placeholder — a value that must be replaced before the configuration is deployable.

Summary

  • cub variant upload stores a config bundle's contents as a component's base. Nothing deploys.
  • A component's variants are implemented as labeled spaces full of units — useful to know, but you mostly operate at the component and variant level.
  • The base is deliberately incomplete: placeholders mark what each deployment must decide for itself.

Next

Go Live

Further reading