Configuration Management and Tokenised Properties

Following the Twelve-Factor principle of configuration separation from the artifact, it is common to have developer centric representations of configuration, for example XML, JSON or YAML, and while these are native to developers, they can be obscure to business or operational users.

With CDAF being Enterprise oriented, a business centric approach is followed. A single file of tabular properties is more consumable than a group of native language files, i.e. can be easily imported into a spreadsheet or document. Additional to this, multiple files can drift in structure over time, making environment comparisons more and more difficult.

context  target  name_space  openshift_token  api_ip        ui_ip
local    dev     kot-dev     $KOT_DEV_TOKEN   10.240.10.10  10.240.10.20
local    test    kot-test    $KOT_TEST_TOKEN  10.240.10.11  10.240.10.21
local    prod    kot-prod    $KOT_PROD_TOKEN  10.240.10.10  10.240.10.20

It is then a case of having a single, tokenised, native file as part of the build output, which is then detokenised at deploy time.

variable "openshift_token"   { default = %openshift_token%" }
variable "api_ip"            { default = "%api_ip%" }
variable "ui_ip"             { default = "%ui_ip%" }