Package: sceptre-sam-handler
READMEWhat is this?sceptre-sam-handleris a TemplateHandler for Sceptre (versions 2.7 and up) that lets you use an
AWS SAM template (and its associated project) as a stack's template.This template handler will runsam buildand thensam packagefrom the indicated SAM Template's
directory in order to compile and generate a CloudFormation-ready template. Additionally, if you
define your SAM template with a.j2extension, you can utilizeJinja2 templating syntax and logicto render the SAM template prior to the build.By using the SAM Handler, you are letting SAM build your application, compile a SAM template, and
upload artifacts to S3, and then using Sceptre to actually do the deployment of the template to a stack.In other words, by using this handler with Sceptre,you skip ever usingsam deploy; It's not needed.
You also shouldn't need a sam config file with deployment defaults, since you'll be using Sceptre to
deploy rather than SAM.By using this handler, you can now use SAM templates with all your favorite Sceptre commands, likelaunch,validate,generate, anddiff(along with all the rest)!How to install sceptre-sam-handlerSimplypip install scepre-sam-handler.Additionally, you need SAM CLI installed and accessibleon
the PATH for the handler to invoke as a subprocess.There are three main ways you can install SAM CLI:You can followAWS's own documentationon how to install SAM for your operating system. (Note: at least on Linux, this requires the ability
to usesudo; If you need to install SAM where permissions escalation is not possible, this won't
work.)You can usepipxto installaws-sam-cliinto an isolated virtual
environment where it can have exclusive claim to its dependency versions. This can be done without
privilege escalations.If you want to installaws-sam-clialong with this handler usingpip, you can use the "extra"
likepip install sceptre-sam-handler[sam]. However,using pip to install SAM is generally not
recommended, according to SAM's own documentation.This can lead to dependency conflicts, since
SAM CLI is particular about dependency versions.How to use sceptre-sam-handlerThe template "type" for this handler issam. There are two file extensions supported by this
handler:.yaml: Use this for a "normal" SAM template according to the SAM specification. This template
will be directly sent to the SAM CLI for building and packaging..j2: Use this if you need to useJinja2 templating syntax and logicin order to render a SAM template, such as
to interpolate values into the template prior to building it. See the section below on Jinja SAM
templates for more details.This handler takes several arguments, two of which are required.Arguments:path(string, required): The pathfrom the current working directory(NOT the
project path) to the SAM Template. The pathmustend in either ".yaml" or ".j2".artifact_bucket_name(string, required): The bucket name where artifacts should be uploaded to
on S3 during the packaging process. If your project has atemplate_bucket_name, you can set this
to{{ template_bucket_name }}.artifact_prefix(string, optional): The prefix to apply to artifacts uploaded to S3. This can be
the project's{{ template_key_prefix }}.build_args(dict, optional): Additional key/value pairs to supply tosam build. For
flag-type arguments that have no value, set the value to "True".package_args(dict, optional): Additional key/value pairs to apply tosam package. The
same is true here as forbuild_argsfor flag-type arguments.skip_jinja_cleanup(bool): Can be set to True to retain the jinja file after processing. This
can be used to troubleshoot issues.How does this handler work?When usingonlysam CLI (not Sceptre) to deploy usingsam deploy, SAM CLI effectively performs
3 steps:SAM CLI builds the all the various resources special SAM resources, resolving dependencies. These would
include Lambda functions and Lambda layers. It copies any locally-referenced files and resolves any
dependencies into a directory called.aws-sam. This is the same behavior as runningsam build.SAM CLI then transforms all SAM template URIs that reference local filepaths to S3 keys (among other)
transformations it applies, uploads any built artifacts to those s3 keys, and saves the transformed
template. This is the same behavior as runningsam package.SAM CLI finally takes that transformed template (along with a local sam config and any other CLI
arguments) and performs CloudFormation stack create/update with them.When you use Sceptre with this handler, the SAM handler performs steps 1-2 above to create a template
that Sceptre can use,but it does not use SAM to deploy it!. Instead, Sceptre can use that template
produced in step 2 above (viasam package) to perform all it's usual commands with all it's usual
magic!In other words, using this handler lets you use resolvers, put your SAM stack into StackGroups, let
you name your stack according to Sceptre's naming conventions,validate,diff, and more! Basically,
the SAM stack can be managed using Sceptre just like any other.Default behaviorSAM commands are invoked using the system shell in a subprocess, with stdout redirected to stderr.
Artifacts will be uploaded using theartifact_bucket_nameandartifact_prefixarguments, theproject_code, and the Sceptre stack name.For example, given anartifact_bucket_nameof "bucket",artifact_prefixof "prefix", aproject_codeof "project" and a stack config located at "config/indigo/sam-application.yaml", SAM
artifacts will be uploaded to:s3://bucket/prefix/project/indigo/sam-application/sam_artifacts/By default, these will be the sam commands that are runfrom the template's directory:sambuild--cached--template-file[pathasabsolutepath]sampackage\--s3-bucket[artifact_bucket_nameargument]\--region[thestackregion]\--s3-prefix[theprefixdescribedabove]\--template-file[pathasabsolutepath]If any additional arguments are desired for to be passed to SAM, you can specify those with dicts for
thebuild_argsandpackage_argstemplate handler arguments. These key/value pairs will
override the defaults. For any flag-type arguments, set the value toTrue. If you want to remove
a default argument (such as the--cachedflag forsam build), set the value toNone.IAM and authenticationThis handler uses the stack's connection information to generate AWS environment variables and sets
those on the sam process, ensuring that the AWS authentication configuration on the stack config and
project is carried over to SAM without any need for additional arguments.If you desire to use a different profile or region when invokingsam packagethan what is set on
the stack, you should specify "profile" and/or "region" values for "package_args".Important:SAM creates CloudFormation-ready templates viasam package, which uploads built
artifacts to S3 in the process. This means that Sceptre commands that do not normally require S3
actions (such asgenerate,validate,diff, and others) will require them when using this
handler. You will need to ensure that any user or role executing these commands has proper
permissions for these operations. For more information on required permissions, see thedocumentation for SAM permissions.Jinja SAM TemplatesThe SAM Handler supports using SAM templates that have Jinja logic in them. These Jinja templates
will have access to thesceptre_user_datajust like Jinja templates via the normal file handler
do. This can be useful for implementing additional template logic (such as loops and other actions)
in the template.If you need to pass variables into the Jinja template for reference via Jinja syntax,
you should pass those variables viasceptre_user_data. Remember, resolvers can be used withsceptre_user_data, so this can be a powerful tool to pre-render your templates or reference values
in areas that a SAM Template cannot use parameters (such as in Transforms).Resolvers in the SAM Handler parametersIt's likely that you'll want to use your template_bucket_name as your artifact_bucket_name, so you
don't need to have a separate bucket for your sam artifacts. However, since template_bucket_name is
technically a resolvable property that could be set via!stack_outputon your StackGroup config,
you cannot directly reference it in your Stack Config with{{ template_bucket_name }}if you defined
it on the StackGroup Config using a resolver. For more information onwhyyou can't do this, you
should read about theResolution order of valuesfor Sceptre
Stack Configs on Sceptre's documentation.Nonetheless, the bottom line is this:{{ template_bucket_name }}may or may not actually work for
you, but!stack_attr template_bucket_namewillalwayswork for you, no matter how you've set
up your project.Example Stack Config (simple .yaml)# By using the SAM handler, you let SAM build and package the template and upload artifacts to S3# and Sceptre will use the packaged template to create the CloudFormation stack, using the stack# config.template:type:sampath:path/from/my/cwd/template.yaml# If your template_bucket_name is inherited from your StackGroup as a resolver, you cannot use# {{ template_bucket_name }} to reference it, so you need to use the !stack_attr resolver. But# using !stack_attr will always work for you anyway, so you might as well configure the SAM# handler that way.artifact_bucket_name:!stack_attrtemplate_bucket_name# It makes the most sense to use the same prefix as your template_key_prefix so that your SAM# artifacts are foldered similar to your other templates... but it's not strictly necessary.artifact_prefix:!stack_attrtemplate_key_prefixbuild_args:use-container:True# You can use resolvers to pass parameters, just like any other Sceptre stack!parameters:long_parameter:!filemy/file/pathmy_template_parameter:!stack_outputsome/other/stack.yaml::SomeOutput# The SAM Handler will work with all the other stack parameters you might want to use too!profile:my_profileiam_role:arn:aws:iam::1111111111:role/My-Deployment-Roleregion:us-east-1stack_tags:SomeTag:SomeValueExample Stack Config (Using Jinja2 .j2 template)template:type:sampath:path/from/my/cwd/template.j2artifact_bucket_name:!stack_attrtemplate_bucket_nameartifact_prefix:!stack_attrtemplate_key_prefix# Remember, Jinja logic cannot access parameter values; Those are accessed via CloudFormation functions# like !Ref and !Sub when the stack is being deployed. If you need values to use with your Jinja logic,# use sceptre_user_data instead.parameters:my_template_parameter:!stack_outputsome/other/stack.yaml::SomeOutput# sceptre_user_data is resolved PRIOR TO building and deploying the template and it is passed to# Jinja. So you can use sceptre_user_data to control Jinja logic or render values into the template.# And because sceptre_user_data is resolvable, you can use resolvers to pass values and even whole# template segments to render into the final SAM template before SAM build is ever invoked.sceptre_user_data:template_segmant:!filemy/template/segment