Configuration Promotion Caveats and Advisory
TSB configuration mostly consists of a number of
Kubernetes Objects, e.g.
Tenant is an object of
Kind and so on.
As such, the main recommendation is to treat TSB configuration just like any other k8s resouce definition, i.e.
- define resources declaratively.
- use GitOps for resource application.
kustomizeor similar tools for config templating and rendering.
The main caveat when it comes to applying resources from one TSB installation to another is the way TSB stores configuration data when calculating and evaluating NGAC access rules, cluster/service parametrs etc. Service Bridge uses the persistent storage (e.g. Postgres) as the Source of Truth and chooses the resource fully-qualified name as the
As such, "promoting" a configuration between two independent (not sharing the same persistent state) TSB installations MUST take into account the configuration resource naming to avoid
primary key conflicts.
In other words, to reliably promote configuration between independent instances, one should:
- Name all TSB resources in both instances exactly the same, including the resource path (i.e.
Clusters of the same name in one instance must belong to the same
Tenantas in the other and so on).
- Avoid imperative configuration changes (e.g. adding a
Clustervia UI/CLI in one environment and not the other), rather using declarative definitions.
- Always have a fresh persistent storage backup to be able to quickly roll back in case of data model conflicts.