Deploy environments are used for selecting the options/variables/parameters to be used with each Module.
They can be defined by the name of a directory (if its not a git repo), git branch, or environment variable (
Standard deploy environments would be something like prod, dev, and test.
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).
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.
A python class that is responsible for creating a CloudFormation template. Usually this is built using troposphere.
A YAML config file that defines the stack definitions for all of the stacks you want CFNgin to manage.
A set of variables that can be used inside the config, allowing you to slightly adjust configs based on which environment you are launching.
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.
stack1 depends on nothing.
stack2 depends on stack1
These are python functions/methods that are executed before or after the action is taken.
A way to uniquely identify a stack. Used to determine the naming of many things, such as the S3 bucket where compiled templates are stored, as well as the prefix for stack names.
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 as a variable in another stack.
Provider that supports provisioning rendered blueprints. By default, an AWS provider is used.