App Config
Application Configuration Management
One of the biggest challenges when dealing with multiple environments is managing the differences in configuration between them. This is especially problematic when promoting changes between environments. Some of the configuration is expected to change (for example the code version) but others are not (the database connection string in the target environment should not change.) Promoting configuration changes is often done by comparing the configuration of the source and target environments. However it is not always clear which bits of configuration need to be updated in the target environment. Detailed knowledge of the configuration and the change being promoted are needed to know how to correctly update the target environment.
Configuration is often an area of shared responsibility. This is especially true in Kubernetes applications. Developers configure the code their apps run, SRE teams want to configure metrics and how workloads run in the cluster, database administrators want to control access database credentials and infrastructure teams want to ensure cloud resources run in the right virtual networks, are correctly sized and property tagged.
Humanitec tackles this problem by separating configuration into two main types: Environment Agnostic and Environment Specific configuration. These represent configuration that should be the same across environments once rolled out and configuration that is expected to vary between environments. Each of these types is further split into developer owned and platformed owned.
This results in application configuration being divided into 4 quadrants. Humanitec addresses each quadrant with a specific object.
App Overview Screen
This is configuration that should be the same for each environment it is rolled out to. For example, the tag of a container image in a particular workload should be not be different between environments. If a workload is tested in a development environment, when it is promoted to the staging environments, the tag of the container image should be the same as it was in the development environment.
Another way to think about Environment Agnostic configuration is as configuration that if different between 2 environments represents a material change. For example, if a workload depends on a MongDB database, it would be expected that the connection string would be different in the development environment than in production. This is not a material change as we expect to have different database instances in these two environments. However, if the workload in production does not have a dependency on MongoDB but the workload in development does then this would be a material change as we would expect these environments to have the same architecture.
Developer owned Environment Agnostic configuration is stored in a Deployment Set.
Platform owned Environment Agnostic configuration is defined through a Workload Profile.
This is configuration that is expected to vary between environments. For example, a production workload that uses managed service like Twillio might use a production API key to access the service. In the dev environment, a development API key might be used to avoid incurring cost with test traffic. We would not be surprised to see different API keys in different environments.
Last modified 1yr ago