Skip to content

Create 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 — an application, a service, an operator — together with the configuration that describes how it runs. The software in this tutorial is CubbyChat, a small chat app.

Create the component

cub component create cubbychat

A component holds no configuration of its own. It is the thing that the configuration belongs to, and the handle you will use to find it, open it in the web UI, and later set rules for how changes to it are allowed to flow. List what you have:

cub component list

One row, cubbychat, with an empty VARIANTS column. That is the part to fill in next.

Load the base

A component is never deployed as such. It is made up of variants: complete copies of the component's configuration, each adapted to a purpose. The first variant every component needs is its base: the shared configuration everything else is cloned from. Load the base from a published bundle of CubbyChat's Kubernetes manifests:

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 — and the command reads as what it does: upload a bundle into the base variant of the cubbychat component. Nothing is running yet. ConfigHub stores configuration; making it live is a separate, deliberate step.

Look again:

cub component list

The VARIANTS column now says base. From here on, this variant is named cubbychat/base, the component and then the variant, wherever a command takes one.

You can view the component in the web UI with:

cub component open cubbychat

This opens the component view for cubbychat on hub.confighub.com, where the variants are drawn as a tree. The CLI draws the same tree:

cub component tree cubbychat

So far it is a tree of one.

Why the base is not deployable

The base is the complete configuration for CubbyChat, with one thing deliberately missing: every resource's namespace is a placeholder, the literal value confighubplaceholder. The base doesn't know where it will run. Each deployment made from it fills in its own namespace, and that is the first thing you will see happen on the next page.

Summary

  • cub component create makes the component; cub component list shows it and its variants.
  • cub variant upload --component <c> --variant base <bundle> loads a bundle of rendered manifests into the component's base. Nothing deploys.
  • A base is deliberately incomplete: placeholders mark what each deployment must decide for itself.

Next

Go Live

Further reading