#The scaffold code

If it finds one, it attempts to use KMS to decrypt the contents into an array and then process each line as a key=value set of variables. Scaffold achieves this by maintaining variables specific to an environment in the file etc/. All components in a production enviroment are likely to share the 'envirornment' variable value 'production'.

For example, the CIDR block defining a primary VPC for a production environment is needed by the component that creates the VPC, it may also be needed by components in other VPCs or accounts. What provides consistency across these components, and therefore defines the environment, are the variables shared between the components. The Scaffold is built around the concept that a logical 'environment' may consist of any number of independent components across independent AWS accounts. source for lambda functions zipped up into artefacts inside componentsĬoncepts & Assumptions Multi-Component Environment Concept The optional location for source files, e.g. The default directory used for caching plugin downloads The optional location for terraform modules called by components Optional useful libraries, such as Jenkins pipeline groovy script The location for environment-specific terraform variables files:

#The scaffold code

Terraform code intended to be run directly as a root module. The bootstrap terraform code used for creating the terraformscaffold S3 bucket

Terraform scaffold consists of a terraform wrapper bash script, a bootstrap script and a set of directories providing the locations to store terraform code and variables. A framework for controlling multi-environment multi-component terraform-managed AWS infrastructure Overview