To avoid a configuration file for each environment, and the inevitable drift between those files, a single, tokenised definition is used.
variable "aks_work_space" { default = "%aks_work_space%" }
variable "name_space" { default = "%name_space%" }
variable "REGISTRY_KEY" { default = "@REGISTRY_KEY@" }
variable "REGISTRY_KEY_SHA { default = "@REGISTRY_KEY_SHA@" }
To De-tokenise this definition at deploy time, name/value pair files are used. This allows the settings to be decoupled from the complexity of configuration file format.
If these were to be stored in source control, they would suffer the same drift challenge, so in source control, the settings are stored in a tabular format, which is compiled into the name/value files during the Continuous Integration process.
target aks_work_space name_space REGISTRY_KEY REGISTRY_KEY_SHA
PLANB_DEV aks_dev openshift-dev $env:REGISTRY_KEY 9DC6A1DD986364D2A2574F607D9E23085846AE4052E7D460C5FB617E9CAFB6E4
PLANB_PREPROD aks_prep openshift-prep $env:REGISTRY_KEY FD6346C8432462ED2DBA60A0ED2FA40DA0FA95F66EAA8730FC70782384DBDC46
PLANB_PROD aks_prod openshift-prod $env:REGISTRY_KEY CA3CBB1998E86F3237CA1257FEFF4296196BFBFDEFC0161D85469EF07D905512
Note: environment variables can be used for dynamic value replacement, most commonly used for secrets.
These human readable configuration management tables are transformed to computer friendly format and included in the release package (release.ps1).