stackctl
- manage CloudFormation Stacks through specifications
stackctl
[options] command arguments
-d
, --directory
=PATH
.
.--filter
=PATTERN[,PATTERN]
--color
=auto|always|never
auto
(the default) will colorize output when
connected to a terminal.-v
, --verbose
--auto-sso
=WHEN
aws sso login
in response to AWS SSO
authorization errors. always
, ask
, or never
. Default is to ask
.cat
capture
changes
deploy
ls
version
Run man stackctl <command>
for more details.
A Stack Specification is a file format and file-system structure used to fully describe a deployed (or deployable) CloudFormation Stack. stackctl is your way of creating, displaying, and using such files.
Specification files ("specs") have the following path structure:
stacks/{account-id}.{account-name}/{region}/{stack-name}.yaml
Its constituent parts are used as follows:
{account-id}
{account-name}
{region}
{stack-name}
{stack/name}
.yaml is also supported, so that directories can be used for
your own organization. Such paths will have directory-separators replaced by
hyphens when used.
These files' contents should be:
Description: <string>
Template: <path>
Depends:
- <name>
Actions:
- on: <event>
run:
<action>: <argument...>
Parameters: Object<string, string|number>
Capabilities:
- <capability>
Tags: Object<string, string>
And these constituent parts are used as follows:
{.Description}
This value will be inserted as the Description key in the template body on deployment, which becomes the deployed Stack's description. If the template already contains a description, the specification value will be ignored.
{.Template}
templates/
.{.Depends}
{.Actions}
{.Actions[].on}
PostDeploy: run the action after a successful deployment.
{.Actions[].run}
InvokeLambdaByStackOutput: output name: invoke the function whose name is found in the given Output of the deployed Stack.
InvokeLambdaByName: function name: invoke the given function.
Exec: [command,
Shell: argument: execute the given argument via sh -c
.
Executed processes will inherit any environment variables and print their
own stdout
and stderr
. If they do not exit 0, an exception is thrown and
stackctl
itself exits.
{.Parameters}
The Parameters key can be specified in any of 3 forms:
# Natural (recommended)
Parameters:
Foo: Bar
Baz: Bat
# CloudFormation
Parameters:
- ParameterKey: Foo
ParameterValue: Bar
- ParameterKey: Baz
ParameterValue: Bat
# CloudGenesis
Parameters:
- Key: Foo
Value: Bar
- Key: Baz
Value: Bat
{.Capabilities}
Valid Capabilities are CAPABILITY_AUTO_EXPAND, CAPABILITY_IAM, and CAPABILITY_NAMED_IAM.
{.Tags}
The Tags key can be specified in either of 2 forms:
# Natural (recommended)
Tags:
Foo: Bar
Baz: Bat
# CloudFormation / CloudGenesis
Parameters:
- Key: Foo
Value: Bar
- Key: Baz
Value: Bat
The following example shares a single Template between two deployments in two regions of a single account.
stacks/
111111111111.prod/
us-east-1/
my-app.yaml
| Template: web.yaml
| Parameters:
| ...
us-west-2/
my-app.yaml
| Template: web.yaml
| Parameters:
| ...
templates/
web.yaml
| Parameters:
| ...
| Resources:
| ...
Once we have a specification, deployment is conceptually simple:
aws configure # for {account-id}
aws --region {region} cloudformation deploy \
--stack-name {stack-name} \
--template-file templates/{.Template} \
--parameter-overrides {.Parameters} \
--capabilities {.Capabilities} \
--tags {.Tags}
In reality, we create changesets, optionally present them for review, execute them, wait, stream events, and finally clean up.
See stackctl-changes(1) and stackctl-deploy(1).
STACKCTL_DIRECTORY
--directory
.STACKCTL_FILTER
--filter
.STACKCTL_AUTO_SSO
--auto-sso
.LOG_*
AWS_PROFILE
Freckle Engineering freckle-engineering@renaissance.com
stackctl-cat(1), stackctl-capture(1), stackctl-changes(1), stackctl-deploy(1), stackctl-ls(1), stackctl-version(1).
The specification format and semantics is a minor extension of that used by the CloudGenesis project, capturing more of a CloudFormation Stack's deployed state statically is terraform-inspired, and GitOps as an approach was pioneered for Kubernetes by Flux CD.