muckamuck/stackility

Simple tool to create CloudFormation stacks

Stackility

Description: a utility for creating, updating, listing and deleting AWS CloudFormation stacks. Also, the utility can be used for determining the drift status of CloudFormation stacks.

Usage:

stackility upsert [OPTIONS]

  The main reason we have arrived here. This is the entry-point for the
  utility to create/update a CloudFormation stack.

Options:
  -v, --version TEXT         code version
  -s, --stack TEXT           stack name
  -i, --ini TEXT             INI file with needed information  [required]
  -d, --dryrun               dry run, generate a change set report
  -y, --yaml                 YAML template (deprecated - YAMLness is now
                             detected at run-time)
  --no-poll                  Start the stack work but do not poll
  -w, --work-directory TEXT  Start in the given working directory
  --help                     Show this message and exit.

See the *Properties* section below for a description of the INI file format.

stackility delete [OPTIONS]

  Delete the given CloudFormation stack.

Options:
  -s, --stack TEXT    [required]
  -r, --region TEXT
  -f, --profile TEXT
  --help              Show this message and exit.

 stackility list [OPTIONS]

  List all the CloudFormation stacks in the given region.

Options:
  -r, --region TEXT
  -f, --profile TEXT
  --help              Show this message and exit.

stackility drift [OPTIONS]

  Produce a CloudFormation drift report for the given stack.

Options:
  -s, --stack TEXT    stack name  [required]
  -r, --region TEXT   region where the stack lives
  -f, --profile TEXT  AWS profile to access resources
  --help              Show this message and exit.

Properties:

The INI file fed to the upsert command has the followning sections:

[environment]: The environment for the creation/update of a CloudFormation stack. These are the following elements of this section:

• bucket - an S3 bucket where the template can be uploaded [required]
• template - the name of the CloudFormation to be used in the operation [required]
• stack_name - the name of the stack. If this element is not present then the --stack argument must be given [optional]
• region - specify the target region for this stack [optional]
• profile - the credentials profile to be used [optional]

[tags]: - key/value pairs that will be created as tags on the stack and supported resources.

[parameters]: - key/value pairs that will be injected as parameter(s) for the stack. You can, of course, enter the values as text. However, there are two special ways to specify the value in this section:

• [ask] - this will ask for (and not echo) the values when a stack upsert is done (example below).
• [ssm:] - specify a parameter key that will be used to retrieve the value from AWS Systems Manager Parameter Store

[meta-parameters]: - (optional) if this section exists in the INI file it is assumed that the template file given in the [environment] section is a Jinja2 template file. The given template is rendered with the key/value pairs injected before the upload to the S3 bucket.

[analysis]: - (experimental) if this section exists in the INI file then CloudFormation Validator is used to perform static analysis on the given template. Items in this section:

• enforced - true | false, if true then stack create/update is aborted when errors are found else if false the analysis is only advisory.

Example parameters file:

[environment]
template=template.json
bucket=account-cf-artifacts-bucket
stack_name=example-stack
region=us-west-2

[tags]
[email protected]
PROJECT=Stackility Examples
THE_DATA=important
Name=example-stack

[parameters]
theCIDR=10.22.0.0/16
subnetCIDROne=10.22.10.0/24
bar=some value
db_password=[ask]
api_key=[ssm:api_key]

[meta-parameters]
food=pizza
drink=beer

[analysis]
enforced=false

Example invocations:

stackility upsert --ini vpc_stack.ini --region us-east-2

• use the template in vpc_stack.ini to create a VPC in the us-east-2 region.

stackility delete --stack example-stack --region us-east-2

• tear down the example-stack stack from us-east-2

stackility list --region us-east-2

• list the CloudFormation stacks in us-east-2

stackility drift --stack example-stack --region us-east-2

• Generate a CloudFormation drift report in us-east-2

Environment notes:

By default the utility polls the status of stack operation every 30 seconds. If needed CSU_POLL_INTERVAL can be set to a number of seconds to override the poll interval

---

Development notes:

Do some work on the thing:

virtualenv stkvenv
. stkenv/bin/activate
pip install --editable .

Publish the thing:

python setup.py sdist bdist_wheel
twine upload dist/*

TODO:

• print CloudFormation Outputs at the end of the upsert command
• investigate giving an IAM role, something like the profile selection

stackility's Issues

Do not echo NoEcho parameters

At the completion of a stackility upsert, an INFO message is printed regarding the stack being created successfully, and the parameters/environment/tags/etc that were submitted for the run. All parameters are printed out, even the ones marked as "NoEcho": "True".

Requesting that the values for "NoEcho": "True" parameters be printed as ***** or similar.

Need to run in parallel

Need to deploy all cloud formations in parallel.

Could Stackset deployments be part of this tool?

Question on how to integrate a pre-existing template

Hello there,
I am fairly new to Stackility and have a CloudFormation json template for a 3rd party vendor application we use from the Amazon market for an sftp gateway that I am wanting to integrate into our Stackility setup. I just wanted to try and get some clarification on how to go about this. I am assuming I make a folder under vpc, and call it sftpgateway and then create a _template.json file in there and paste in the template, but then I imagine things within there need to be changed. Then It looks like the config.ini for that particular environment under the second vpc folder needs to have parameters added to it from the original template but then need to be modified?

Once those things are done, is there other places things are referenced that would need to be added?

I appreciate any assistance,
Thanks!

Need to be able to have both json and yaml templates

Would like to have both json and yaml templates so those familiar with yaml can edit the yaml file, and those familiar with json can edit the json file, and the template with the most current modified time will deploy and update the corresponding yaml or json file.

Get stack name for delete command from ini

It would be nice if the delete command accepted -i/--ini as a parameter and pulled the stack name out of the configuration file. That way the upsert and delete commands would have similar usage patterns.