Stack Config¶
A Stack config stores configurations related to a particular Stack, such as the path to that Stack’s Template, and any parameters that Stack may require. Many of these configuration keys support resolvers and can be inherited from parent StackGroup configs.
Structure¶
A Stack config file is a yaml
object of key-value pairs configuring a
particular Stack. The available keys are listed below.
template_path or template (required)
dependencies (optional)
hooks (optional)
ignore (optional)
notifications (optional)
obsolete (optional)
on_failure (optional)
disable_rollback (optional)
parameters (optional)
protected (optional)
role_arn (optional)
cloudformation_service_role (optional)
iam_role (optional)
sceptre_role (optional)
iam_role_session_duration (optional)
sceptre_role_session_duration (optional)
sceptre_user_data (optional)
stack_name (optional)
stack_tags (optional)
stack_timeout (optional)
It is not possible to define both template_path and template. If you do so, you will receive an error when deploying the stack.
template_path¶
Resolvable: No
Can be inherited from StackGroup: No
The path to the CloudFormation, Jinja2 or Python template to build the Stack from. The path can either be absolute or relative to the Sceptre Directory. Sceptre treats the template as CloudFormation, Jinja2 or Python depending on the template’s file extension. Note that the template filename may be different from the Stack config filename.
Warning
This key is deprecated in favor of the template key. It will be removed in version 5.0.0.
template¶
Resolvable: Yes
Can be inherited from StackGroup: No
Configuration for a template handler. Template handlers can take in parameters and resolve that to a CloudFormation template. This enables you to not only load templates from disk, but also from third-party storage or AWS services.
Example for loading from S3 bucket:
template:
type: s3
path: infra-templates/s3/v1/bucket.yaml
parameters:
<parameter1_name>: "value"
sceptre_user_data:
It is possible to write your own template handlers should you need to. You can find a list of currently supported template handlers and guidance for developing your own in the Template Handlers section.
dependencies¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Appended to parent’s dependencies
A list of other Stacks in the environment that this Stack depends on. Note that
if a Stack fetches an output value from another Stack using the
stack_output
resolver, that Stack is automatically added as a dependency,
and that Stack need not be added as an explicit dependency.
Warning
Be careful about how you structure dependencies. It is possible to create circular
dependencies accidentally, where multiple stacks depend on each other. Sceptre
will detect this and raise an error, blocking this sort of setup. You must be especially careful
when specifying dependencies
on a StackGroup config. These dependencies will then be
“inherited” by every stack within that StackGroup. If one of those dependencies inherits that
list of dependencies, it will cause a circular dependency. If this happens, you can resolve the
situation by either (a) setting those dependencies
on individual Stack Configs rather than the
the StackGroup Config, or (b) moving those dependency stacks outside of the StackGroup.
hooks¶
Resolvable: No (but you can use resolvers _in_ hook arguments!)
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
A list of arbitrary shell or Python commands or scripts to run. Find out more in the Hooks section.
ignore¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This configuration should be set with a boolean value of True
or False
. By default, this is
set to False
on all stacks.
ignore
determines how the stack should be handled when running sceptre launch
. A stack
marked with ignore: True
will be completely ignored by the launch command. If the stack does NOT
exist on AWS, it won’t be created. If it DOES exist, it will neither be updated nor deleted.
You can mark a stack with ignore: True
that other non-ignored stacks depend on, but the launch
will fail if dependent stacks require resources or outputs that don’t exist because the stack has not been
launched. Therefore, only ignore dependencies of other stacks if you are aware of the risks of
launch failure.
This setting can be especially useful when combined with Jinja logic to exclude certain stacks from launch based upon conditional Jinja-based template logic.
For Example:
template:
path: "my/test/resources.yaml"
# Configured this way, if the var "use_test_resources" is not true, the stack will not be launched
# and instead excluded from the launch. But if "use_test_resources" is true, the stack will be
# deployed along with the rest of the resources being deployed.
{% if not var.use_test_resources %}
ignore: True
{% endif %}
Note
The ignore
configuration only applies to the launch command. You can still run
create
, update
, or delete
commands on a stack marked with ignore: True
;
these commands will ignore the ignore
setting and act upon the stack the same as any other.
notifications¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
List of SNS topic ARNs to publish Stack related events to. A maximum of 5 ARNs
can be specified per Stack. This configuration will be used by the create
,
update
, and delete
commands. More information about Stack notifications
can found under the relevant section in the AWS CloudFormation API
documentation.
obsolete¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This configuration should be set with a boolean value of True
or False
. By default, this is
set to False
on all stacks.
The obsolete
configuration should be used to mark stacks to be deleted via prune
actions,
if they currently exist on AWS. (If they don’t exist on AWS, pruning does nothing).
There are two ways to prune obsolete stacks:
sceptre prune
will delete all obsolete stacks in the project.sceptre launch --prune [command path]
will delete all obsolete stacks in the command path before continuing with the launch.
In practice, the obsolete
configuration operates identically to ignore
with the extra prune
effects. When the launch
command is invoked without the --prune
flag, obsolete stacks will
be ignored and not launched, just as if ignore: True
was on the Stack Config.
Important: You cannot have non-obsolete stacks dependent upon obsolete stacks. Both the
prune
and launch --prune
will reject such configurations and will not continue if this sort
of dependency structure is detected. Only obsolete stacks can depend on obsolete stacks.
Note
The obsolete
configuration only applies to the launch and prune commands. You can
still run create
, update
, or delete
commands on a stack marked with obsolete: True
;
these commands will ignore the obsolete
setting and act upon the stack the same as any other.
on_failure¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This parameter describes the action taken by CloudFormation when a Stack fails to create. For more information and valid values see the AWS Documentation.
Examples include:
on_failure: "DO_NOTHING"
on_failure: "ROLLBACK"
on_failure: "DELETE"
disable_rollback¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This parameter describes the action taken by CloudFormation when a Stack fails to create or update, default is False. This option can be set from the stack config or from the Sceptre CLI commands to deploy stacks. The disable_rollback CLI option (i.e. sceptre launch –disable-rollback) disables cloudformation rollback globally for all stacks. This option overrides on_failure since Cloudformation does not allow setting both on deployment. For more information and valid values see the AWS Documentation.
Examples:
disable_rollback: "True"
parameters¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Warning
Sensitive data such as passwords or secret keys should not be stored in plaintext in Stack config files. Instead, they should be passed in from the CLI with User Variables, or set via an environment variable with the environment variable resolver.
A dictionary of key-value pairs to be supplied to a template as parameters. The keys must match up with the name of the parameter, and the value must be of the type as defined in the template.
Note
Note that Boto3 throws an exception if parameters are supplied to a template that are not required by that template. Resolvers can be used to add functionality to this key. Find out more in the Resolvers section.
Warning
In case the same parameter key is supplied more than once, the last definition silently overrides the earlier definitions.
A parameter can be specified either as a single value/resolver or a list of
values/resolvers. Lists of values/resolvers will be formatted into an AWS
compatible comma separated string e.g. value1,value2,value3
. Lists can
contain a mixture of values and resolvers.
Syntax:
parameters:
<parameter1_name>: "value"
<parameter2_name>: !<resolver_name> <resolver_value>
<parameter3_name>:
- "value1"
- "value2"
<parameter4_name>:
- !<resolver_name> <resolver_value>
- !<resolver_name> <resolver_value>
<parameter5_name>:
- !<resolver_name> <resolver_value>
- "value1"
Example:
parameters:
database_username: "mydbuser"
database_password: !environment_variable DATABASE_PASSWORD
subnet_ids:
- "subnet-12345678"
- "subnet-87654321"
security_group_ids:
- "sg-12345678"
- !stack_output security-groups.yaml::BaseSecurityGroupId
- !file_contents /file/with/security_group_id.txt
protected¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Stack protection against execution of the following commands:
launch
create
update
delete
execute
If a user tries to run one of these commands on a protected Stack, Sceptre will throw an error.
role_arn¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Warning
This field is deprecated as of v4.0.0 and will be removed in v5.0.0. It has been renamed to cloudformation_service_role as a clearer name for its purpose.
cloudformation_service_role¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
The ARN of a CloudFormation Service Role that is assumed by CloudFormation (not Sceptre) to create, update or delete resources. For more information on this configuration, its implications, and its uses see Sceptre and IAM: cloudformation_service_role.
iam_role¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Warning
This field is deprecated as of v4.0.0 and will be removed in v5.0.0. It has been renamed to sceptre_role as a clearer name for its purpose.
sceptre_role¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This is the IAM Role ARN that Sceptre should assume using AWS STS when executing any actions on the Stack.
This is different from the cloudformation_service_role
option, which sets a CloudFormation
service role for the stack. The sceptre_role
configuration does not configure anything on the
stack itself.
Warning
If you set the value of sceptre_role
with !stack_output
, that sceptre_role
will not actually be used to obtain the stack_output, but it WILL be used for all subsequent stack
actions. Therefore, it is important that the user executing the stack action have permissions to get
stack outputs for the stack outputting the sceptre_role
.
For more information on this configuration, its implications, and its uses, see Sceptre and IAM: sceptre_role.
iam_role_session_duration¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Warning
This field is deprecated as of v4.0.0 and will be removed in v5.0.0. It has been renamed to sceptre_role_session_duration as a clearer name for its purpose.
sceptre_role_session_duration¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
This is the session duration when Sceptre assumes the sceptre_role IAM Role using AWS STS when executing any actions on the Stack.
Warning
If you set the value of sceptre_role_session_duration
to a number that GREATER than 3600, you
will need to make sure that the sceptre_role
has a configuration of MaxSessionDuration
, and
its value is GREATER than or equal to the value of sceptre_role_session_duration
.
sceptre_user_data¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
Represents data to be passed to the sceptre_handler(sceptre_user_data)
function in Python templates or accessible under sceptre_user_data
variable
key within Jinja2 templates.
stack_name¶
Resolvable: No
Can be inherited from StackGroup: No
A custom name to use instead of the Sceptre default.
Outputs from Stacks with custom names can’t be resolved using the standard stack output resolver. Outputs should be resolved using the stack output external resolver. An explicit dependency should be added, using the dependencies parameter, to make sure the Stacks are launched in the correct order.
e.g:
parameters:
VpcID: !stack_output_external <custom-named-vpc-stack>::VpcID
dependencies:
- <environment>/<Stack>
You can also pass an optional argument to stack_output_external
specifying
the profile you want to use. This is especially useful if the Template you’re
referring to is in a different AWS account or region.
parameters:
VpcID: !stack_output_external <custom-named-vpc-stack>::VpcID my-aws-prod-profile
dependencies:
- <environment>/<Stack>
stack_tags¶
Resolvable: Yes
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
A dictionary of CloudFormation Tags to be applied to the Stack.
stack_timeout¶
Resolvable: No
Can be inherited from StackGroup: Yes
Inheritance strategy: Overrides parent if set
A timeout in minutes before considering the Stack deployment as failed. After the specified timeout, the Stack will be rolled back. Specifiyng zero, as well as ommiting the field, will result in no timeout. Supports only positive integer value.
Cascading Config¶
Stack config can be cascaded in the same way StackGroup config can be, as described in the section in StackGroup Config on Cascading Config.
Templating¶
Stack config supports templating in the same way StackGroup config can be, as described in the section in StackGroup Config on Templating.
Stack config makes StackGroup config available to template.
StackGroup config¶
StackGroup config properties are available via the stack_group_config variable when using templating.
parameters:
sceptre-project-code: {{ stack_group_config.project-code }}
Environment Variables¶
It is possible to replace values in Stack config files with environment variables in two ways. For an explanation on why this is the case, see the FAQ.
Sceptre User Data¶
Python or Jinja templates can contain data which should be parameterised, but can’t be parameterised using CloudFormation parameters. An example of this is if a Python template which creates an IAM Role reads in the policy from a JSON file. The file path must be hard-coded in the Python template.
Sceptre user data allows users to store arbitrary key-value pairs in their
<stack-name>.yaml
file. This data is then passed as a Python dict
to
the sceptre_handler(sceptre_user_data)
function in Python templates.
Syntax:
sceptre_user_data:
iam_policy_file_path: /path/to/policy.json
When compiled, sceptre_user_data
would be the dictionary
{"iam_policy_file": "/path/to/policy.json"}
.
Resolution order of values¶
Stack Configs allow you to pull together values from a variety of sources to configure a CloudFormation stack. These values are retrieved and applied in phases. Understanding these phases can be very helpful when designing your Stack Configs.
When launching a stack (or performing other stack actions), values are gathered and accessed in this order:
User variables (from
--var
and--var-file
arguments) are gathered when the CLI first runs.StackGroup Configs are read from the highest level downward, rendered with Jinja and then loaded into yaml. The key/value pairs from these configs are layered on top of each other, with more nested configs overriding higher-level ones. These key/value pairs will be “inherited” by the Stack Config. These variables are made available when rendering a StackGroup Config:
User variables (via
{{ var }}
)Environment variables (via
{{ environment_variable }}
)StackGroup configurations from higher level StackGroup Configs are available by name. Note: more nested configuration values will overshadow higher-level ones by the same key.
With the layered StackGroup Config variables, the Stack Config file will be read and then rendered with Jinja. These variables are made available when the Stack Config is being rendered with Jinja:
User variables (via
{{ var }}
)Environment variables (via
{{ environment_variable }}
)All StackGroup configurations are available by name directly as well as via
{{ stack_group_config }}
Important: If any StackGroup configuration values were set with resolvers, accessing them via Jinja will not resolve them, since resolvers require a Stack object, which has not yet been assembled yet. Resolvers will not be accessible until a later phase.
Once rendered via Jinja into a string, the Stack Config will be loaded into yaml. This is when the resolver instances on the Stack config will be constructed (not resolved).
The Stack instance will be constructed with the key/value pairs from the loaded yaml layered on top of the key/value pairs from the StackGroup configurations. This is when all resolver instances, both those inherited from StackGroup Configs and those from the present Stack Config, will be connected to the Stack instance and thus ready to be resolved.
The first time a resolvable configuration is accessed is when the resolver(s) at that configuration will be resolved and replaced with their resolved value. This is normally done at the very last moment, right when it is needed (and not before).
“Render Time” vs. “Resolve Time”¶
A common point of confusion tends to be around the distinction between “render time” (phase 3, when
Jinja logic is applied) and “resolve time” (phase 6, when resolvers are resolved). You cannot use
a resolver via Jinja during “render time”, since the resolver won’t exist or be ready to use yet. You can,
however, use Jinja logic to indicate whether, which, or how a resolver is configured. You can
also use resolvers like !sub
to interpolate resolved values when Jinja isn’t available.
For example, you can do something like this:
parameters:
{% if var.use_my_parameter %}
my_parameter: !stack_output {{ var.stack_name }}::{{ var.output_name }}
{% endif %}
# !sub will let you combine outputs of multiple resolvers into a single string
my_combined_parameter: !sub
- "{fist_part} - {second_part}"
- first_part: !stack_output my/stack/name.yaml::Output
- second_part: {{ var.second_part }}
Accessing resolved values in other fields¶
Sometimes you might want to reference the resolved value of one field in another field. Since you cannot use Jinja to access resolved values, there is another way to this. The stack_attr resolver is meant for addressing just this need. It’s a resolver that will resolve to the value of another Stack Config field value. See the linked documentation for more details on that resolver and its use.
Examples¶
template:
path: templates/example.py
type: file
parameters:
param_1: value_1
param_2: value_2
template:
path: templates/example.yaml
type: file
dependencies:
- dev/vpc.yaml
hooks:
before_create:
- !cmd "echo creating..."
after_create:
- !cmd "echo created"
- !cmd "echo done"
after_update:
- !cmd "mkdir example"
- !cmd "touch example.txt"
parameters:
param_1: !stack_output stack_name.yaml::output_name
param_2: !stack_output_external full_stack_name::output_name
param_3: !environment_variable VALUE_3
param_4:
{{ var.value4 }}
param_5:
{{ command_path.3 }}
param_6:
{{ environment_variable.VALUE_6 }}
sceptre_user_data:
thing_1: value_1
thing_2: !file_contents path/to/file.txt
stack_tags:
tag_1: value_1
tag_2: value_2