Skip to content

Bulk Changes

Inevitably, most software deployments end up having many different variants, e.g. multiple development environments, production environments in different regions, different test and staging environments, etc.

At that point, it becomes challenging to safely and consistently make changes to a specific set of environments.

ConfigHub helps you manage this with a combination of flexible labeling, function invocation, clone relationships and bulk operations.

Make bulk changes to specific environments

Let's say that we are deploying our chat app in production in multiple different regions. We start by creating these new regional units:

cub unit create chatapp-prod-us --upstream-unit chatapp-dev --label EnvClass=prod
cub unit create chatapp-prod-eu --upstream-unit chatapp-dev --label EnvClass=prod
cub unit create chatapp-prod-ap --upstream-unit chatapp-dev --label EnvClass=prod

Notice that we are adding a label to these new units. Now we can run a cub command that targets all these units, and only these units, by using bulk command execution with a where clause. Let's scale up the backend of just these production units:

cub run set-replicas \
        --replicas=4 \
        --where "Labels.EnvClass='prod'" \
        --resource-type apps/v1/Deployment \
        --where-data "metadata.name='backend'"

In addition to filtering on the label, we also filter on the resource type (Deployment) and resource name ("backend"). The CLI should respond with a message for each of the units and whether the function invocation resulted in a change. You can check the change with, e.g:

cub unit diff -u chatapp-prod-us --from=-1

You can confirm that replicas have not been changed in the latest revision of the original chatapp-prod (which doesn't have the label):

cub run get-replicas --unit chatapp-prod

This should print something like:

Function(s) succeeded on unit dcfdbe73-340d-40e0-99e5-bcc4e8287c28
OUTPUT
------
1 int spec.replicas /backend apps/v1/Deployment
1 int spec.replicas /frontend apps/v1/Deployment
1 int spec.replicas /postgres apps/v1/StatefulSet
Awaiting triggers...

chatapp-prod was not affected because it does not have the label EnvClass set to "prod". Labeling is a powerful mechanism to specify "dimensions" of your software deployment.

Sometimes you want to target a specific component across dev/stage/prod. For example you want to add a new environment variable to a component. Other times you want to target environments of a specific class. For example, you want to scale up in production to ensure stability or you want to scale all dev environments to 1 to save cost.

Labeling, filtering and function invocations make this easy in ConfigHub.

Summary

  • A single piece of software often ends up being deployed in many variants and it becomes important to be able to make targeted changes to specific selections of those variants
  • ConfigHub makes this possible with the combination of labels, mutating functions and bulk operations. Clone relationships is another powerful mechanism for this which we already looked at previously in the tutorial.
  • ConfigHub does not dictate a specific topology. Using labels and a clone hierarchy of your choice, you can set everything up the way that suits your needs.

Next

Check out the Guides for deeper dives into getting stuff done with ConfigHub.

Further reading