Terminology¶

Blueprint¶

A python class that is responsible for creating a CloudFormation template using troposphere. Blueprints are deploying using CFNgin.

CFNgin¶

Runway’s CloudFormation engine used to deploy CloudFormation Templates (JSON or YAML) and Blueprints written using troposphere.

Deploy Environment¶

Deploy Environments are used for selecting the options/variables/parameters to be used with each Module. The Deploy Environment is derived from the current directory (if its not a git repo), active git branch, or environment variable (DEPLOY_ENVIRONMENT). Standard Deploy Environments would be something like prod, dev, and test.

When using a git branch, Runway expects the branch to be prefixed with ENV-. If this is found, Runway knows that it should always use the value that follows the prefix. If it’s the master branch, Runway will use the Deploy Environment name of common. If the branch name does not follow either of these schemas and Runway is being run interactively from the CLI, it will prompt of confirmation of the Deploy Environment that should be used.

When using a directory, Runway expects the directory’s name to be prefixed with ENV-. If this is found, Runway knows that it should always use the value that follows the prefix.

Deployment¶

A Deployment contains a list of Modules and options for all the Modules in the Deployment. A Runway Config File can contain multiple Deployments and a Deployment can contain multiple Modules.

Lookup¶

In the context of Runway, a Lookup is a method for expanding values in the Runway Config File file when processing a Deployment/Module. These are only supported in select areas of the Runway Config File (see the config docs for more details).

In the context of CFNgin, a Lookup is method for expanding values in the config at runtime.

Module¶

A Module is a directory containing a single Infrastructure-as-Code tool configuration of an application, a component, or some infrastructure (e.g. a set of CloudFormation Templates). It is defined in a Deployment by path. Modules can also contain granular options that only pertain to it based on its module.type.

Output¶

A CloudFormation Template concept. Stacks can output values allowing easy access to those values. Often used to export the unique ID’s of resources that Templates create.

CFNgin makes it easy to pull Outputs from one stack and then use them in the variables of another stack.

Parameters¶

A mapping of key: value that is passed to a Module. Through the use of a Lookup, the value can be changed per region or Deploy Environment. The value can be any data type but, support for complex data types depends on the module.type.

graph¶

A mapping of object name to set/list of dependencies.

A graph is constructed for each execution of CFNgin from the contents of a config file.

Example

{
    "stack1": [],
    "stack2": [
        "stack1"
    ]
}

stack1 depends on nothing.
stack2 depends on stack1