Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow stacks to be instantiated multiple times #10

Open
ampedandwired opened this issue Oct 16, 2016 · 7 comments
Open

Allow stacks to be instantiated multiple times #10

ampedandwired opened this issue Oct 16, 2016 · 7 comments

Comments

@ampedandwired
Copy link
Owner

See #6 for background. The basic idea is taking a stack, say "web-uat" and being able to instantiate that many times ("web-uat-1", "web-uat-2", etc).

At the moment this is possible by using the --cfn-stack-name command line option, however this should really be supported as a first-class citizen in Bora, as it is a powerful way of working with stacks.

@herebebogans
Copy link
Contributor

herebebogans commented Oct 24, 2016

I think most use cases of this will be an orchestrator creating new stacks with a build number? We use ansible to create the bora.yml from a template in a prep stage as part of a Jenkins release pipeline. The build number goes into the stack name eg


template:
  myapp:
    stacks:
      dev-{{build_number}}:
      .....
      uat-{{build_number}}:
      .....
      prd-{{build_number}}:
      ....

The generated bora.yml also becomes a convenient release artifact.

I'm wondering is should be a bora feature or better done outside of it with a templating tool?

@herebebogans
Copy link
Contributor

Sorry didn't notice the closed ...

@ampedandwired
Copy link
Owner Author

Using ansible that way is a neat idea. Gives you immutable stacks which are pretty cool. How do you manage the switch over from one prd stack to another?

You might be right, maybe this is something that should be layered on top of Bora using a different tool. That said, I can see an argument for some support of this inside Bora too. Depends on how common of a use case this is, and how people are integrating Bora into their deployment pipelines.

@herebebogans
Copy link
Contributor

We do the switchover outside cloudformation with Route53 DNS changes - but our scenario is quite a simple website stack.

Yes I can see it both ways.
I think bora is a great purpose tool for it's solution to "per environment cookie cutter cloudformation stacks".

I've seen quite a few posts on the cfndsl issue list of people looking for this kind of environment abstraction solution - should promote it some more there!

@ampedandwired
Copy link
Owner Author

Yeah, I really should get out and promote it a bit more :)

@ampedandwired
Copy link
Owner Author

@herebebogans What I was thinking for this was adding an additional optional "stack identifier" to the end of the bora command. So your example config above would become simply:

template:
  myapp:
    stacks:
      dev
      .....
      uat
      .....
      prd
      ....

And then you would apply it like this:

$ bora apply myapp-dev <build_number>

where build_number comes from Jenkins.

This would result in a stack named myapp-dev-<build_number> in cloudformation.

Thoughts?

@herebebogans
Copy link
Contributor

Yes - that's a elegant idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants