Resolvers¶
Sceptre implements resolvers, which can be used to resolve a value of a
CloudFormation parameter
or sceptre_user_data
value at runtime. This is
most commonly used to chain the outputs of one Stack to the inputs of another.
If required, users can create their own resolvers, as described in the section on Custom Resolvers.
Syntax:
parameters:
<parameter_name>: !<resolver_name> <resolver_value>
sceptre_user_data:
<name>: !<resolver_name> <resolver_value>
Available Resolvers¶
environment_variable¶
Fetches the value from an environment variable.
Syntax:
parameter|sceptre_user_data:
<name>: !environment_variable ENVIRONMENT_VARIABLE_NAME
Example:
parameters:
database_password: !environment_variable DATABASE_PASSWORD
file¶
A Sceptre resolver to get file contents. The returned value can be passed into a parameter as a string, json, or yaml object.
Refer to sceptre-file-resolver for documentation.
no_value¶
This resolver “resolves to nothing”, functioning just as if it was not set at all. This works just like the “AWS::NoValue” special variable that you can reference on a CloudFormation template. It can help simplify Stack and StackGroup config Jinja logic in cases where, if a condition is met, a value is passed, otherwise no value is passed.
For example, you could use this resolver like this:
parameters:
my_parameter: {{ var.some_value_that_might_not_be_set | default('!no_value') }}
In this example, if var.some_value_that_might_not_be_set
is set, my_parameter
will be set to
that value. But if var.some_value_that_might_not_be_set
is not actually set, my_parameter
won’t even be passed to CloudFormation at all. This might be desired if there is a default value on
the CloudFormation template for my_parameter
and we’d want to fall back to that default.
stack_attr¶
This resolver resolves to the values of other fields on the same Stack Config or those inherited from StackGroups in which the current Stack Config exists, even when those other fields are also resolvers.
To understand why this is useful, consider a stack’s template_bucket_name
. This is usually set on
the highest level StackGroup Config. Normally, you could reference the template_bucket_name that was
set in an outer StackGroup Config with Jinja using {{template_bucket_name}}
or, more explicitly, with
{{stack_group_config.template_bucket_name}}
.
However, if the value of template_bucket_name
is set with a resolver, using Jinja won’t work.
This is due to the Resolution order of values on a Stack Config. Jinja configs are rendered before
resolvers are constructed or resolved, so you can’t resolve a resolver from a StackGroup Config via
Jinja. That’s where !stack_attr is useful. It’s a resolver that resolves to the value of another stack
attribute (which could be another resolver).
template:
type: sam
path: path/from/my/cwd/template.yaml
# template_bucket_name could be set by a resolver in the StackGroup.
artifact_bucket_name: !stack_attr template_bucket_name
The argument to this resolver is the full attribute “path” from the Stack Config. You can access nested values in dicts and lists using “.” to separate key/index segments. For example:
sceptre_user_data:
key:
- "some random value"
- "the value we want to select"
sceptre_role: !stack_output roles.yaml::RoleArn
parameters:
# This will pass the value of "the value we want to select" for my_parameter
my_parameter: !stack_attr sceptre_user_data.key.1
# You can also access the value of another resolvable property like this:
use_role: !stack_attr sceptre_role
stack_output¶
Fetches the value of an output from a different Stack controlled by Sceptre.
Syntax:
parameters | sceptre_user_data:
<name>: !stack_output <stack_name>.yaml::<output_name>
Example:
parameters:
VpcIdParameter: !stack_output shared/vpc.yaml::VpcIdOutput
Sceptre infers that the Stack to fetch the output value from is a dependency, adding that stack to the current stack’s list of dependencies. This instructs Sceptre to build that Stack before the current one.
Warning
Be careful when using the stack_output resolver that you do not create circular dependencies. This is especially true when using this on StackGroup Configs to create configurations to be inherited by all stacks in that group. If the !stack_output resolver would be “inherited” from a StackGroup Config by the stack it references, this will lead to a circular dependency. The correct way to work around this is to move that stack outside that StackGroup so that it doesn’t “inherit” that resolver.
stack_output_external¶
Fetches the value of an output from a different Stack in the same account and region. You can specify a optional AWS profile to connect to a different account/region.
If the Stack whose output is being fetched is in the same StackGroup, the basename of that Stack can be used.
Syntax:
parameters/sceptre_user_data:
<name>: !stack_output_external <full_stack_name>::<output_name> <optional-aws-profile-name>
Example:
parameters:
VpcIdParameter: !stack_output_external prj-network-vpc::VpcIdOutput prod
Custom Resolvers¶
Users can define their own resolvers which are used by Sceptre to resolve the value of a parameter before it is passed to the CloudFormation template.
A resolver is a Python class which inherits from abstract base class
Resolver
found in the sceptre.resolvers module
.
Resolvers are require to implement a resolve()
function that takes no
parameters and to call the base class initializer on initialisation.
Resolvers may have access to argument
, stack_config
,
stack_group_config
and connection_manager
as an attribute of self
.
For example self.stack_config
.
Sceptre uses the sceptre.resolvers
entry point to locate resolver classes.
Your custom resolver can be written anywhere and is installed as Python
package.
In case you are not familiar with python packaging, this is great place to start.
Example¶
The following python module template can be copied and used:
custom_resolver
├── custom_resolver.py
└── setup.py
The following python module template can be copied and used:
custom_resolver.py¶
from sceptre.resolvers import Resolver
class CustomResolver(Resolver):
"""
The following instance attributes are inherited from the parent class Resolver.
Parameters
----------
argument: Any
The argument of the resolver. This can be any value able to be defined in yaml.
stack: sceptre.stack.Stack
The associated stack of the resolver. This will normally be None when the resolver is
instantiated, but will be set before the resolver is resolved.
"""
def __init__(self, argument, stack=None):
super(CustomResolver, self).__init__(argument, stack)
def setup(self):
"""
Setup is invoked after the stack has been set on the resolver, whether or not the
resolver is ever resolved.
Implement this method for any setup behavior you want (such as adding to stack dependencies).
"""
def resolve(self):
"""
resolve is the method called by Sceptre. It should carry out the work
intended by this resolver. It should return a string to become the
final value.
To use instance attribute self.<attribute_name>.
Examples
--------
self.argument
self.stack
Returns
-------
str
Resolved value
"""
return self.argument
setup.py¶
from setuptools import setup
setup(
name='<custom_resolver_package_name>',
py_modules=['<custom_resolver_module_name>'],
entry_points={
'sceptre.resolvers': [
'<custom_resolver_command_name> = <custom_resolver_module_namef>:CustomResolver',
],
}
)
Then install using python setup.py install
or pip install .
commands.
This resolver can be used in a Stack config file with the following syntax:
template:
path: <...>
type: <...>
parameters:
param1: !<custom_resolver_command_name> <value> <optional-aws-profile>
Calling AWS services in your custom resolver¶
For details on calling AWS services or invoking AWS-related third party tools in your resolver, see How do I call AWS services or use AWS-based tools in my custom hook/resolver/template handler?
Resolver arguments¶
Resolver arguments can be a simple string or a complex data structure.
template:
path: <...>
type: <...>
parameters:
Param1: !ssm "/dev/DbPassword"
Param2: !ssm {"name": "/dev/DbPassword"}
Param3: !ssm
name: "/dev/DbPassword"
Resolving to nothing¶
When a resolver returns None
, this means that it resolves to “nothing”. For resolvers set for
single values (such as for template_bucket_name
or cloudformation_service_role
), this just means the value is
None
and treated like those values aren’t actually set. But for resolvers inside of containers
like lists or dicts, when they resolve to “nothing”, that item gets completely removed from their
containing list or dict.
This feature would be useful if you wanted to define a resolver that sometimes would resolve to be a given stack parameter and sometimes would be not defined at all and use the template’s default value for that parameter. The resolver could just return None in those cases it wants to resolve to nothing, similar to the AWS::NoValue pseudo-parameter that can be referenced in a CloudFormation template.
Resolver placeholders¶
Resolvers (especially the !stack_output resolver) often express dependencies on other stacks and
their outputs. However, there are times when those stacks or outputs will not exist yet because they
have not yet been deployed. During normal deployment operations (using the launch
, create
,
update
, and delete
commands), Sceptre knows the correct order to resolve dependencies in and will
ensure that order is followed, so everything works as expected.
But there are other commands that will not actually deploy dependencies of a stack config before
operating on that Stack Config. These commands include generate
, validate
, and diff
.
If you have used resolvers to reverence other stacks, it is possible that a resolver might not be able
to be resolved when performing that command’s operations and will trigger an error. This is not likely
to happen when you have only used resolvers in a stack’s parameters
, but it is much more likely
if you have used them in sceptre_user_data
with a Jinja or Python template. At those times (and
only when a resolver cannot be resolved), a best-attempt placeholder value will be supplied in to
allow the command to proceed. Depending on how your template or Stack Config is configured, the
command may or may not actually succeed using that placeholder value.
A few examples…
If you have a stack parameter referencing
!stack_output other_stack.yaml::OutputName
, and you run thediff
command before other_stack.yaml has been deployed, the diff output will show the value of that parameter to be"{ !StackOutput(other_stack.yaml::OutputName) }"
.If you have a
sceptre_user_data
value used in a Jinja template referencing!stack_output other_stack.yaml::OutputName
and you run thegenerate
command, the generated template will replace that value with"StackOutputotherstackyamlOutputName"
. This isn’t as “pretty” as the sort of placeholder used for stack parameters, but the use of sceptre_user_data is broader, so it placeholder values can only be alphanumeric to reduce chances of it breaking the template.Resolvable properties that are always used when performing template operations (like
sceptre_role
andtemplate_bucket_name
) will resolve toNone
and not be used for those operations if they cannot be resolved.
Any command that allows these placeholders can have them disabled with the --no-placeholders
ClI
option.