https://pulumi.com
Join Slack
Menu
Home
Archive
This message was deleted.
# general
s
This message was deleted.
👀 1
m
It’d be interesting if you could have multiple stacks that shared some state - ie. a project that was for a single microservice instance and a monolithic project that was for an entire environment that included the microservice. Obviously there’d be a challenge in reading multiple pieces of state across multiple storage areas (eg.GCS buckets) and co-ordination/locking.
The popular method for achieving this is with a "shared-" or "base-" project that has the resources which other stacks share. The "child" stacks get the values of the Outputs via StackReferences, and use the resource getters to get a copy of the resource in the current scope. https://www.pulumi.com/blog/iac-recommended-practices-using-stack-references/
I would recommend against the monolithic approach.
l
interesting - that’s new to me
m
The more resources you manage, the longer deployments will take just to calculate the resource graph. When your plan fails, it will fail big. Operationally, micro stacks help you limit the damage in the case of an incident.
l
my gripe is that stacks feel more like different envs (staging/test/prod) instead of different vertical slices
m
That's where I think you're looking for the Stack References pattern
l
oh, it works across projects?
I’ll have a read later, thanks
m
It's also worth noting there is "project level configuration" that all stacks can inherit, but not resources.
l
Is this relatively new?
m
Right. Nope.
My organization uses this pattern fairly heavily in conjunction with a few other patterns. 1. 
shared-infrastructure
for your account-wide resources 2. 
shared-project-name
for resources shared across other stacks in a project (e.g. you have a 3 tier web application, and they all have to share some S3 bucket) 3. 
pulumi-components
for our "level 2" abstractions of our resources (e.g. custom resource) distributed as a library for Stacks to use to simplify resource declarations
l
do StackReferences work when not using Pulumi’s backend?
m
Yes, there is a note about a recent change regarding that though
TL;DR, before this change, YOU WILL NOT have "fully qualified stack names" like you do in the Pulumi service. e.g. 
my-org/my-project/my-stack
.
The work-around was to create your own namespace convention, and all states live as siblings in the state storage backend. e.g. 
my-org.my-project.my-stack
g
One thing to remember about the stack references is that the parent stack can decide to remove the reference and there's no way to notify downstream about the change or removal. So I'd advise combining stack references with lookup aka 
get_<resource>
functions.
5 Views
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