Skip to content

Clone Config

One reason why software configuration gets complex is because the same software is often deployed in many different variations. It is common to have several development, testing, staging and production deployments.

ConfigHub helps you manage this with a powerful set of tools. One of them is cloning.

Create a clone for production

The chatapp-dev unit is a development deployment. Now we create a unit for production deployment by cloning chatapp-dev:

cub unit create chatapp-prod --upstream-unit chatapp-dev

This creates a new unit as a clone of the chatapp-dev unit. In a simple scenario, a clone starts out as just a copy of the original. But thanks to post-clone triggers, it can also be modified automatically after creation.

Propagate changes

First let's change the Chat title in chatapp-prod to a more appropriate one. We do it like last time:

cub run set-env-var \
        --unit chatapp-prod \
        --container-name backend \
        --env-var CHAT_TITLE \
        --env-value "Rock-solid Production Chat"

Now, let's say that our most recent code changes requires more memory, so we need to bump the memory in chatapp-dev:

cub run set-container-resources \
        --unit chatapp-dev \
        --container-name backend \
        --memory 1Gi \
        --cpu "" \
        --operation floor \
        --limit-factor 1

This is a mouthful of a function invocation. But it basically boils down to setting the memory request and limit for the backend container to 1Gi. Now check the unit list (with just the columns we care about):

cub unit list --columns Name,UpgradeNeeded,UnappliedChanges

You should see something like:

NAME            UPGRADE-NEEDED    UNAPPLIED-CHANGES 
chatapp-dev                       Yes                  
chatapp-prod    Yes               Yes

You will notice that chatapp-prod needs an upgrade. Upgrade refers merging in changes from upstream. Think of it like upgrading to a newer version. Because we made changes to chatapp-dev after we created the clone, it now needs an upgrade. Let's upgrade chatapp-prod:

cub unit update chatapp-prod --upgrade

This creates a new revision with the changes from the upstream. But importantly, it does not overwrite your own changes to the Chat title. Check the diff:

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

which should look something like:

--- tumble-cub/chatapp-prod/2
+++ tumble-cub/chatapp-prod/3
@@ -92,9 +96,2 @@
          value: "development"
        resources:
          requests:
-            memory: "100Mi"
+            memory: "1Gi"
          limits:
-            memory: "200Mi"
+            memory: 1Gi
---
apiVersion: v1
kind: Service

Only the memory setting was upgraded because ConfigHub tracks which fields were directly modified in the downstream chatapp-prod unit and will not overwrite them during an upgrade.

This is a key feature that makes it possible to manage many configuration variants even though each variant maintains a full, literal copy of its config data.

Summary

  • Variants of an existing deployment can be created as a cloned unit of the existing, upstream unit.
  • ConfigHub tracks changes to upstream units and report when an upgrade is available to the downstream unit
  • ConfigHub tracks changes made directly in the downstream unit so changes from the upstream can be merged without clobbering local changes.

Next

Validate configurations

Further reading