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 --granularity per-file \
    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 four — backend, frontend, postgres, and namespace — one per file in the bundle (--granularity per-file), so the package's layout defines how the component's configuration is organized. Inspect one:

cub unit data --space cubbychat-base backend

This is ordinary Kubernetes YAML: a Deployment and a Service. Notice the namespace fields say 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