https://pulumi.com logo
#getting-started
Title
# getting-started
f

fresh-xylophone-16772

01/23/2024, 12:11 PM
Hello. First off, I hope #getting-started is the right place for proof of concept talk. Feel free to forward this to general if needed. I’m working on a PoC for our team to adopt Pulumi. Currently, I’m looking for examples of the following: 1. Multiple region use - Specifically, is it recommended to have a stack per region or per SDLC deploy. Everything in the docs insinuates the latter, like dev, qa, and prod. But, having a large prod deploy to 20+ regions seems daunting. Or rather, a huge leap of faith to get everyone on board? 2. Blue/Green deployment - I currently don’t see how blue/green deployments can be achieved, without creating stacks for each of these. If that were combined with the stacks per region above, you see where our stacks proliferate and they become a whole other issue to manage. Any existing examples or thoughts are welcome. I’m hoping to get our project on the right track and migrate incrementally. Update: Maybe a better question to ask is how to treat existing infrastructure as immutable and use pulumi to deploy to a new region as a blue/green setup for future deployments.
s

salmon-account-74572

01/23/2024, 5:08 PM
For #1, you can deploy to multiple regions in a single stack if that would make more sense. For example, if your production environment normally encompasses resources in multiple regions, then put that into a single stack. The key in this case is that you have to multiple multiple providers, each configured for a region where you're deploying. Look up "explicit providers" and you'll see some examples of what I'm talking about. I think you'd have to use separate stacks for #2; I don't see any other way of making it work. You might need a third project that controls the routing between the "blue" and "green" stacks so that you can gradually cut traffic over, then run a
pulumi destroy
on the old stack once all the traffic is moved over. I hope this helps! Please continue to ask questions, and we'll do our best to help.
f

fresh-xylophone-16772

01/23/2024, 5:59 PM
Thanks for the direction. So, in the case of the blue/green deployment, the third stack that you are referring to would be our prod networking infrastructure, such as route53, etc., correct? And, we would use these as shared resources, correct? Here is where things get fuzzy for me. 1. I want these stacks to be able to update things like CNAME per instance and add to the routing, but I don’t want them to be able to ever destroy that route53 instance. Making it mutable, but indestructible. Is that a thing? 2. So, let’s assume 3 stacks now;
blue
,
green
, and
backbone
.
blue
has v1 in it, with load balancers, app servers, CNAME updated in route53 from
backbone
, etc. all setup and deployed. When
green
runs
pulumi up
, it adds v2, route53, etc. Now…the doubt…sorry for being new and asking this ahead of time, if
green
runs
pulumi down
, does it properly remove solely the CNAME entires that it made and not try to tear down the whole route53 instance?
s

salmon-account-74572

01/23/2024, 6:04 PM
The devil is in the details (which I don't have), but based on what I do know: 1. It seems like this could be solved by letting
backbone
manage the hosted zone, but the zone entries themselves could be created by
blue
or
green
(and therefore could also be destroyed by
blue
or
green
) 2. If you follow the approach in step 1, then yes, you should be good to go. Obviously, you'll want to test all this to be sure it behaves as you expect (and as you want).
l

little-cartoon-10569

01/23/2024, 7:06 PM
Just in case it's not obvious from the docs: the potential
backbone
stack should not be a stack in the same project. Since it has completely different resources than
blue
and
green
, the correct solution here is to use two projects: one for the backbone stuff, and one for your deployable instance (`blue`/`green`).
s

salmon-account-74572

01/23/2024, 7:07 PM
Yes, thank you for clarifying that @little-cartoon-10569! I thought I had referred to
backbone
as a project, so Paul's comments are absolutely spot on.