Skip to content

Managing Environments

Most organizations have multiple "environments" that they deploy to. These are typically infrastructures for distinct deployment stages or purposes that are isolated from one another in some way(s), often physically and by ownership and permissions.

Typical dimensions of isolation include:

  • Deployment Stage or Realm: development, staging, production
  • Region: us-east, us-west, europe, etc.
  • Kubernetes Cluster

In ConfigHub's two-level authorization model, you'd isolate distinct environments by space and by worker (and therefore by targets).

We recommend that you use different spaces for different environments. You can add an Environment label to each space to identify the environment to which it belongs.

With the CLI you can do that like this:

cub space create --label Environment=development app-dev

You may also choose to further subdivide spaces by application/service or team in order to facilitate self service, in which case we recommend adding labels, such as Application, to identify which application/service the spaces correspond to.

If you do that, you may also want to create a space for each environment to contain shared entities, such as workers, targets, views, and filters.

cub space create --label Environment=development platform-dev

Triggers are used to enforce constraint-based policies on configuration data. Triggers are registered at the space level, either by creating them in the space or by specifying which triggers apply to the space using a where filter.

For example:

platformSpaceID="$(cub space get platform-prod --jq '.Space.SpaceID')"
cub space create app-prod --label Environment=production --where-trigger "SpaceID = '$platformSpaceID'"