StackMaster 3.0 Proposal: Environments

[patrobinson]

Hello one and all,

In October StackMaster will turn three and we've decided the next major goal should be a 2.0 release. This is an opportunity to put all options on the table, including those that break the API. This issue is a place to discuss the proposal to solve the hottest topic in StackMaster today, Environments and their current implementation, Region Aliases. Feel free to comment here on this proposal as well as potential alternatives.

Problem Statement

It’s common to have other environments in addition to Production, which replicate all or some of Production stacks. We can share Parameters between environments, but it may also be beneficial to share Parameters within an environment (i.e. log server address).

The current method of using region aliases is limited. Users cannot create multiple environments in the same region and conflating the concept of an environment and region can make it difficult for multi-region services.

For the past year or more I've encouraged we defer any decision on this problem until we understood it better. Having found this problem in many seperate implementations across the Envato business I feel we have enough experience with the problem to make a well informed decision, but I'd love to hear from others who have also felt this pain including @johnf @rbayerl @nitehawk @berniedurfee-ge @flyinbutrs .

Relevant Issues and PRs:
#109
#180
#221
#115

Current Solutions

As discussed we can use region-aliases to deploy environments to different regions.

Alternatively you can have a seperate StackMaster path, with a different stack_master.yml file and parameter files, while linking to a shared template path. This makes it possible to have a directory structure like so:

- production/
-- stack_master.yml
-- parameters/
- staging/
-- stack_master.yml
-- parameters/
- templates/

However it introduces duplication between the stack_master.yml files.

Proposed Solution

Instead of using a region to delineate an environment, I propose we use an AWS Account. While this is again prescriptive, it’s at least best practice as recommended by Amazon. We can either fetch the account number (list-account-aliases) or take an environment variable to tell us what account we are in. Each “environment” would have a directory (similar to that described above) and it’s own stack_master.yml file, which contained stack_defaults such as tags and stacks that are specific to that environment. There would also be a "master" stack_master.yml file defining stacks that are applicable to both environments, which would be merged with the environment configuration at run time.

- production/
-- stack_master.yml
-- parameters/
- stack_master.yml
- staging/
-- stack_master.yml
-- parameters/
- templates/

This would not break existing functionality, users could continue to use a single StackMaster config file for all environments or one for each environment. Only when the environments: key is encountered in the top level config file would this functionality take effect.

[orien]

This looks pretty sweet! Do you have further insights gleaned from the last couple of years @patrobinson?

It would be nice to have a mechanism to share parameters between environments also.

[orien]

I see some interesting discussion in #256 also.

[patrobinson]

#256 unfortunately showed me how hard this would be to implement. It involves a pretty significant refactor of StackMaster with a change to the StackDefinition class, which is used in a very large number of places.

I think the feedback was clear "This would result in having less infrastructure represented in code."

That's the opposite of what we wanted. I really like Ray's suggestion that Stacks should have "targets", but implementing that would probably require a good week or two of focus time that I can't justify committing.

[patrobinson]

Part of me thinks if I think about this problem long enough I can break it down into smaller parts that are more achievable, but I haven't managed to do that yet

[orien]

@patrobinson I hear you. It's hard to contemplate broad-reaching design changes with a constant flow of day-to-day tasks fighting for your attention.