Manage Drift
Sometimes, the live systems are modified directly without using ConfigHub. This creates drift between the config in ConfigHub and what's live.
ConfigHub gives you options for what to do about drift. It starts with simply bringing the reality back into ConfigHub and then decide what to do.
Refresh from live
Handling drift starts with refreshing ConfigHub with what is currently live. To try this out, let's first perform a refresh from live before we make any changes:
cub unit refresh chatapp-dev
This ensures that our most recent revision in ConfigHub matches live and we can focus on just the changes we introduce. Now let's make a change directly to the live system by, for example, scaling up the backend container:
kubectl --context kind-confighub scale deployment backend --replicas=2
Now the live deployment has drifted from what is in ConfigHub. If you were to perform an apply from ConfigHub it would overwrite the new replica count which sometimes is what you want, but not always.
With ConfigHub, you can bring this change in the live system back into ConfigHub with a refresh:
cub unit refresh chatapp-dev
You can see the changes with:
cub unit diff -u chatapp-dev --from=-1
The refresh command creates a new revision containing the config that is live right now. This allows you to decide what to do next: You can inspect the difference. Then you can decide if you want to keep what is currently live. If you want to revert to what was in ConfigHub, you simply restore the previous revision and apply it:
cub unit update chatapp-dev --restore <previous-revision-number>
cub unit apply chatapp-dev
Parity with standard GitOps
Reverting to what was previously in ConfigHub corresponds to the standard GitOps scenario where changes to live environments will be overwritten by the specified config. As you can see, this approach is fully supported by ConfigHub and it is easily automated if you want to achieve parity with standard GitOps.
With ConfigHub you have choice. Because you can easily choose to make the current live state the desired state, it allows you to "break glass" and make changes directly in the live systems without having to worry about the changes being overwritten on the next sync.
A key reason why this is possible is that ConfigHub stores literal config. There is no generator step between what is stored in ConfigHub and what is live. When you have generator steps, you can't go backwards and move config from the live system back to your config store.
Summary
- Unlike typical GitOps, ConfigHub does not automatically reconcile drift. It offers options.
- Because ConfigHub stores config in its literal form, it is possible to bring live state back into ConfigHub and perform detailed reconciliation using ConfigHub's many tools
- This makes "break glass" operations, where live systems are updated directly, less of a problem. Reconcilliation from live back to the config store is easy.
- However, because ConfigHub makes it much faster, easier and less error-prone to edit and then apply config, break glass should be less necessary.