Terminology

Runway

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 (Runway)

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).

Module

A module is a directory containing a single infrastructure-as-code tool configuration of an application, a component, or some infrastructure (eg. 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.

Parameters

A mapping of key: value that is passed to a module. Through the use of a Lookup (Runway), 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.

Runway’s CFngin

Blueprint

A python class that is responsible for creating a CloudFormation template. Usually this is built using troposphere.

context

Context is responsible for translating the values passed in via the command line and specified in the config to stacks.

graph

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

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

Example

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

stack1 depends on nothing.
stack2 depends on stack1

lookup

A method for expanding values in the config at runtime. By default lookups are used to reference Output values from other stacks within the same namespace.

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 simple to pull outputs from one stack and then use them in the variables of another stack.