https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
g
I asked a similar question last week and the recommendations were to have multiple Pulumi projects for these different modules
And from there, we're looking at using Pulumi's Automation API to loosely couple the infra projects together
b
In this particular case, I'd do the following: - define the VPC as its own project, output the VPC id as a stack output - encapsulate the rest of your logic into component resources with an input arg of VPC id - you can then either 1) grab the vpc id as a stack output or 2) use 
vpc.get()
✨ 1
it gives you a lot of flexibility
my usual advice is to group projects together logically using considerations of "rate of change" or "blast radius" as a consideration. What I mean by that is, if you have a shared VPC for a lot of different stuff, that is likely to change a lot less than the things that live inside it, so it's useful to decouple them into different proijects
b
Makes sense, thanks a lot @green-musician-49057 & @billowy-army-68599! The only downside of this is that the subproject is not independant; if I were to start from scratch, but it's a very minor problem compared to the upsides
b
can you elaborate on that a little? not quite followingh
b
Let's say I have two stacks: 
common
(which has the VPC resource), and another stack 
s3-website
which consumes that VPC id. If I were to checkout the stack 
s3-website
and try to apply it on a brand new AWS account, it wouldn't work because the VPC would not exist. If they were both in the same stack, this would not happen
b
ahhh got it, yeah I'm following now
yeah that is a trade off, but I think you'll find the pros outweigh the cons 🙂
b
For sure! And the fact that it will break if the 
common
stack is not deployed is perfect, fail fast!
b
you can even 
throw
is the stack output is not resolved 🙂
❤️ 1
b
damn that's true! It's cleaner than the way I used to "throw" in TF haha:
Copy code
locals {
  # Abusing the 'file' function to fail if the specified environment does not match the workspace
  assert_environment_matches_workspace = terraform.workspace != var.environment ? file("ERROR: Environment needs to match the workspace") : null
}
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by