Skip to content

Go Live

The base exists, but a base is never deployed. To run CubbyChat you create a deployment: a variant cloned from the base, adapted to a concrete place to run — your dev cluster.

Create the dev deployment

cub variant create dev cubbychat/base \
    --target dev/target \
    --namespace cubbychat

The two arguments are the new variant's name and the variant to clone it from, as <component>/<variant>. One command did four things:

  • Cloned the base into a new variant, cubbychat/dev — the whole configuration copied, and the copy remembers exactly which revision of the base it came from. That memory is what lets changes to the base flow into deployments later, while preserving each deployment's own customizations.
  • Attached the target, making this variant a deployment of the dev cluster: releases published from it go to that target.
  • Filled the placeholder: --namespace cubbychat replaced confighubplaceholder throughout, so this deployment lands in its own namespace.
  • Told the cluster about the deployment. Because the target is a cub cluster up cluster, ConfigHub created the Argo CD Application that makes this deployment live, pointing Argo at this deployment's releases. From now on, Argo is watching for CubbyChat releases — there just aren't any yet. (Pass --no-argo-app to skip this and wire the Application yourself.)
cub component tree cubbychat

cubbychat
└── base
    └── dev    → dev/target

Two variants now, and the beginnings of a tree: dev hangs under the base it was cloned from, and the arrow says where its releases go.

Publish a release

Configuration in ConfigHub never goes live implicitly. To make the deployment live, publish a release: an immutable bundle of the deployment's configuration, served from ConfigHub's OCI endpoint, which Argo pulls and reconciles.

cub release publish cubbychat/dev

Argo CD in your cluster notices the new release on its next sync and applies it. Watch it come up:

kubectl get pods -n cubbychat --watch

The pods appear in the cubbychat namespace: the placeholder the base left open, filled by this deployment.

What just happened

You just experienced ConfigHub's deployment model. Let's summarize:

  • You never pushed anything at the cluster. ConfigHub published a bundle; the operator inside the cluster pulled it. ConfigHub needs no credentials to your infrastructure.
  • Releases are immutable and deliberate. Editing configuration in ConfigHub does not change what's running. Only publishing a release does. This separation — change config, then release it — is the foundation for everything later in this tutorial: review, promotion, and controlled rollout.
  • The live state is accounted for. Each release records exactly which revision of the configuration it contains, so "what is running in this cluster?" always has a precise answer.

Check

cub release list --variant cubbychat/dev
kubectl get pods -n cubbychat

One release published; pods Running. A variant is always named the same way, <component>/<variant>: as an argument where a command takes one, and as --variant where a command takes a flag. The flag form can also be split in two, --component cubbychat --variant dev, which means the same thing.

Summary

  • A deployment is a clone of the base: cub variant create <name> <component>/base --target <target> --namespace <ns>.
  • cub release publish <component>/<deployment> makes it live by publishing an immutable OCI bundle that the cluster pulls.
  • Changing config and releasing it are separate steps. Nothing goes live implicitly.

Next

Make a Change

Further reading