https://github.com/brettswift/cdk-git-config

Store configs from a git directory in AWS
https://github.com/brettswift/cdk-git-config

aws aws-cdk aws-cdk-constructs aws-ssm cdk ssm

Last synced: about 2 months ago
JSON representation

Store configs from a git directory in AWS

• Host: GitHub
• URL: https://github.com/brettswift/cdk-git-config
• Owner: brettswift
• Created: 2019-11-20T17:53:49.000Z (about 5 years ago)
• Default Branch: master
• Last Pushed: 2023-06-13T13:20:12.000Z (over 1 year ago)
• Last Synced: 2024-10-31T06:03:17.303Z (2 months ago)
• Topics: aws, aws-cdk, aws-cdk-constructs, aws-ssm, cdk, ssm
• Language: TypeScript
• Size: 1.72 MB
• Stars: 2
• Watchers: 3
• Forks: 0
• Open Issues: 3
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md

Awesome Lists containing this project

README

        
# CDK Git Config

An AWS CDK construct that will replicate a directory structure of yaml files into AWS SSM. (Or other providers like DynamoDB / S3 in the future).

## Motivation

In Continuous Delivery, you need to tweak configuration in production at runtime, quickly, without flowing through your entire dev --> staging --> prod pipeline.  This can be called "out of band" configuration.  Alternative to "in-band" configuration which is committed to your software git repo, and updates when the software is deployed.

One popular way of storing out of band configuration is SSM.  However this can get out of hand quickly.

Having configuration stored in git, with a simple interface (yaml) is nice.  So lets do that, and replicate the directory via CDK / Cloudformation into AWS SSM!

Key advantages:

* history of out of band configuration

* easy to revert to previous configuration

* Pull Requests, added options for reviewing configuration (prod & dev)

* Easy to replicate into new accounts.

## Example

See the examples folder for a deployable stack you can use to evaluate.

## Deficiencies / TODO

* Secure parameters - currently not supported

* Include a CodePipeline construct, as automating this is critical.

## Releasing

1. Merge PR to master

2. Run the release script according to what type of release this should be

    * `npm run release-[major|minor|patch]`

    * This will:

        * create the appropriate release number in package.json

        * create the tag, and commit

        * Finally push the tag and commit up

        * Travis will run the build and release to NPM.

## Contributing

PR's welcome.  Issues / requests welcome.