In my last post of this series, we covered how we store and retrieve configuration information in AWS System Manager SSM parameters. In this post, we will look at how the configuration information is organized by environment and how it serves as a basic service registry.
SSM Path Structure
First off we have two accounts in AWS to separate our live (production) and development environments. This is a common best practice from AWS to control security and costs more easily at the appropriate levels.
Next is the environment. We use 4 different environments CI, QA and DEMO in the development account and PROD in the live account. CI is used for continuous integration builds and developer testing. QA is used for peer reviews and acceptance criteria validation. DEMO is used for final UAT and by customers for demo/training purposes.
We can also segregate environments by the repository branch. Master is the default primary branch but, when needed, we will create development branches in CI for individual stories work or as a proof of concept before eventually merging back into master.
Lastly we include the service name.
We use this structure to name our CloudFormation stacks and also path our SSM parameters. We use the following path structure for SSM parameters for a given service/environment/branch.
[Account].[Environment].[Branch].[Service]
For example:
dev.ci.master.shipping
This has worked out really nicely to organize our SSM parameters in a standardized way for all our services. We can easily see all the SSM parameters for a given service by filtering down to its path.
We use CloudFormation templates to create the SSM parameters along with all the other infrastructure configuration automation. This allows us to delete and recreate stacks with their full configuration as part of our release pipeline.
Versioning
In the situation where we need to maintain multiple versions of a service and store different SSM parameters for each version, we append the version number at the end of the path. For example:
dev.ci.master.shipping020000
Hierarchical Parameters
Another reason we use this path structure is so we can store and load SSM parameters at multiple levels. So for every service instance we actually load 3 levels of SSM parameters: account, environment and service. For example, we would load parameters from the following paths for dev.ci.master.shipping:
- Account level – dev
- Environment – dev.ci.master
- Service – dev.ci.master.shipping
This allows us to set/store parameters once at a higher level and share those parameters to multiple environments/services.
Basic Service Registry
This isn’t nearly as fleshed out as other portions of our architecture but it has provided value. Specifically knowing what versions of services are deployed in each environment and having the links for all the services, contracts and documentation in one place:
Each service adds a path/parameter at the environment level to report its latest version and that it exists at the environment level, dev.ci.master/services path for example. Then we query the services path to build the UI above and list all the services and corresponding links for each service.
If you found this post or series of posts helpful OR if you have further questions please leave a comment below to continue the conversation.
Happy Configuring!