Templating

Michael Delzer Updated by Michael Delzer

A Stack and its Components require input parameters for correct deployment and operation. These might be values such as: cluster size, cloud region to deploy to, admin password, reference to shared filesystem or network security group, etc.

Automation Hub use

  • user-defined high-level parameters and preferences,
  • Environment settings and preferences,
  • tech-level parameters inferred from output variables of the stack components

to populate input parameters of the Stack and its Components by templating config files using selected template engines. Convention over Configuration dictates that configuration files are located in directories named config up to 3 levels deep. For example:

Root of the Stack
hub.yaml
/config - templated
/cloud
/config - templated
/terraform
/modules
/config - not templated
/apps
/postgresql
/config - templated

All files that are found to contain substitution placeholders (see below) are replaced with processed content and the original file is saved as original-filename.template. If we see filename.template then filename is created with processed content.

We support JavaScript / Groovy-like string interpolation placeholders such as ${cloud.aws.region}, ${apps.postgresql.url}, Mustache `` and template-is-a-valid-config friendly Commentary that performs substitutions by searching for template markers in native comments:

const zone = 'us-east-1a' // hub-template: us-east-1 => cloud.deployment.region
deployment:
zone: us-east-1a # hub-template: us-east-1 => cloud.deployment.region

The default template engine is curly for ${}, the others are mustache and commentary, respectively.

A warning is issued if an unknown placeholder is found - ie. the placeholder cannot be mapped to an existing parameter or output variable, thus substitution is not performed.

It is possible to process additional directories in recursive search, add exact files by name, and change template engine in hub.yaml:

templates:
kind: curly
directories:
- config
- app/config
files:
- "*.template"
extra:
- kind: mustache
directories:
- terraform
files:
- cloud/config.js
- app/main.js
- kind: curly
files:
- os/etcd/services/etcd.service

In the future, we may provide an educated guess of default template engine based on the file type being processed.

The value of the parameter is plain text in most cases, it is substituted literally. In the future, we may allow substitutions (evaluations) in output values before they become parameters, ie. double layer of template processing. We may implement substitution of structured data, for example - an output variable provides JSON array:

[ "us-east-1a", "us-east-1b"]

which is placed into YAML file using the native syntax:

zones:                      zones:
- ${cloud.zones} - us-east-1a
- us-east-1b

How did we do?

Managing Kubernetes in the CLI with kubectl

Toolbox - The CLI Swiss Army Knife

Contact