Deploying Cloudformation templates via the CLI is a complex process that lack repeatability. Typing out long command lines, and then having to execute other commands either before or after the stack runs results in lots of custom scripting. Rather than go down that route, I created a tool that takes a yaml manifest file that allows you to specify all the details around your stack deployment in one data-driven place.
If you’re deploying a cloudformation stack via the CLI, there is a lot that goes into it. Here are the options in the AWS CLI:
--stack-name [--template-body ] [--template-url ] [--parameters ] [--disable-rollback | --no-disable-rollback] [--timeout-in-minutes ] [--notification-arns ] [--capabilities ] [--resource-types ] [--role-arn ] [--on-failure ] [--stack-policy-body ] [--stack-policy-url ] [--tags ]
The Parameters are passed in via a string that looks like this:
ParameterKey=key1,ParameterValue=value1,UsePreviousValue=boolean ParameterKey=key2,ParameterValue=value2,UsePreviousValue=boolean ParameterKey=key3,ParameterValue=value3,UsePreviousValue=boolean
There are Stack Policies that you probably want to apply to protect important stateful resources from mistaken Replacement or Deletions.
You might want to reference resources across stacks (this is better now that stacks can export values, but you might not want to do that in every case).
So I created deploy_stack.rb. It takes as its input a Manifest file that contains:
- Template Location (file or S3)
- Region to deploy to
- Stack Tags
- Stack Policy
- Pre and Post install scripts that can be used to do things like zip up a lambda or execute an AWS CLI command that’s not available via Cloudformation
In its most simple form you want to:
deploy_stack.rb -g CloudformationTemplateFile.yaml | tee Something-Manifest.yaml
Edit Something-Manifest.yaml to set the parameters
deploy_stack.rb -m Something-Manifest.yaml
With the manifest files, you can store those in revision control, so you can easily reproduce the command line you used to deploy the stack. It will auto-detect if the stack needs to be created or updated.
The Manifest can also specify parameters that are pulled from other stacks. SourcedParameters are specified as StackName.Section.LogicalID, Where section is either Parameter, Resource or Output. So even if a stack doesn’t specify a resource as an output, you can still use the logical ID to get the resource’s ID.