https://pulumi.com logo
#general
Title
# general
g

gorgeous-pharmacist-71907

01/04/2024, 4:15 PM
anyone know the right way to share resources between stacks in pulumi? for e.g. i have two stacks
staging
and
prod
i want to create an IAM user in aws that is shared/known to both environments. so when i deploy the
staging
stack for example, it'll create this user, but then when i switch to
prod
, i want it to recognise the user has already been created, rather than trying to re-create it which is what happens given the resource isn't being shared between the stacks any help would be much appreciated as I'm new to pulumi
l

little-library-54601

01/04/2024, 4:20 PM
d

dry-keyboard-94795

01/04/2024, 4:24 PM
For shared resources, it'd be best to setup another project, then have both your staging/prod stacks in your current project reference them using Stack References
g

gorgeous-pharmacist-71907

01/04/2024, 4:25 PM
thanks, came across this. just need to figure out/see examples for how to effectively structure the project folders/files
d

dry-keyboard-94795

01/04/2024, 4:26 PM
There's a quick guide to help with deciding overall structure here: https://www.pulumi.com/docs/using-pulumi/organizing-projects-stacks/
g

gorgeous-pharmacist-71907

01/04/2024, 4:32 PM
@dry-keyboard-94795 okay. ideally i want to keep it all contained within a single project. just skimmed through that article. im thinking infra • aws ◦ shared ▪︎ index.ts ◦ staging ▪︎ index.ts ◦ prod ▪︎ index.ts guessing this will work, if i utilise stack refs to bring into
prod
and
staging
from
shared
d

dry-keyboard-94795

01/04/2024, 4:33 PM
I'd expect the staging + prod stacks to be the same project
g

gorgeous-pharmacist-71907

01/04/2024, 4:36 PM
they would all be in the same Pulumi project if that's what you mean? e.g. they all use the same AWS account. i think it makes sense to keep them separate? that way I can for example define a lambda that will only be deployed into staging and not in prod?
d

dry-keyboard-94795

01/04/2024, 4:44 PM
For simplicity, yes you could deploy all services from a single project. Instead of having separate staging/prod entrypoints, I'd recommend using feature flags; ie your
Pulumi.staging.yaml
file contains
enable-some-service: true
. This way, your code is the same between production + staging
s

salmon-account-74572

01/04/2024, 4:48 PM
+100 to everything @dry-keyboard-94795 said. 😄
g

gorgeous-pharmacist-71907

01/04/2024, 4:51 PM
okay just to make sure ive got this clear youre suggesting one stack for staging & prod but making use of feature flags set in the config to manage differences between them?
d

dry-keyboard-94795

01/04/2024, 4:52 PM
Multiple stacks, one project. A project is the directory that holds your code (
Pulumi.yaml
index.js
). A Stack is represented by the config
Pulumi.staging.yaml
(for the staging stack)
s

salmon-account-74572

01/04/2024, 4:52 PM
Put another way: one project for staging and prod, but each of them would be a separate stack within that project (and here I'm using "project" and "stack" in the Pulumi sense).
The IAM user would be a separate project with its own stack, and the staging and prod stacks would reference that user via a stack reference.
d

dry-keyboard-94795

01/04/2024, 4:53 PM
Just on the shared user, I'm curious on your usecase. It's not necessarily wrong to do, I've done similar to shortcut setup for CI/CD before
g

gorgeous-pharmacist-71907

01/04/2024, 4:54 PM
hmm, i understand, ideally id like one project with 3 stacks
staging
,
prod
and
shared
and
staging
and
prod
can make use of stack references from
shared
, rather than having a separate project for
shared
d

dry-keyboard-94795

01/04/2024, 4:56 PM
It will be simpler to just have a separate
shared
project, so your code doesn't need to be concerned with too much branching. You could even nest it in the same directory if you want: • Infra/ ◦ Pulumi.yaml ◦ shared/ ▪︎ Pulumi.yaml
g

gorgeous-pharmacist-71907

01/04/2024, 4:56 PM
@dry-keyboard-94795 essentially there are some resources we have on AWS that aren't necessary for us to have per environment. e..g we're happy to use the same IAM user for both
prod
and
staging
resources. we have a few instances of those. because of that we just want to shared resources so there isnt conflict (e..g prod does not try and recreate that IAM user). hopefully that makes sense?
@dry-keyboard-94795 thats a good idea and structure
s

salmon-account-74572

01/04/2024, 5:01 PM
hmm, i understand, ideally id like one project with 3 stacks
@gorgeous-pharmacist-71907 You could make it work that way, but IMO it would be unnecessarily complex. You want to think of a stack as an instance of the infrastructure defined in your program. This is what enables you to have identical (or nearly identical) infrastructure in your staging environment (one stack) and your production environment (a second stack)---because they run the same code, but with independent state and independent configuration values. As Anthony mentioned, it's best if you have a separate
shared
project (and every project will have at least one stack) when you have resources that need to be accessed/used/referenced by other stacks (like the IAM user in your use case).
But listen to Anthony---he's smart and will definitely lead you in the right direction. 👍🏻
g

gorgeous-pharmacist-71907

01/04/2024, 5:06 PM
yeah so if ive understood correctly, i think we're on the same page now @salmon-account-74572? so having two projects. one project housing shared infra. the other housing code for both
prod
and
staging
(stack for each for independent config)
s

salmon-account-74572

01/04/2024, 5:09 PM
Yep! And to Anthony's point earlier, you can write the code for the
prod
and
staging
stacks such that they can use configuration values to provision slightly differently (for example, maybe you want to use smaller instance types in staging, so parameterize that as a configuration value).
d

dry-keyboard-94795

01/04/2024, 5:10 PM
^^ yep. This will help in the longer term, as iam management, + maybe core networking, requires more privileges than an app deployment. Keeping them split will reduce the temptation to just use admin roles for deployment
g

gorgeous-pharmacist-71907

01/04/2024, 5:11 PM
yeah i really like this setup, sounds like it ticks all the boxes and quite an easy workflow to understand/maintain, single repo is always nice too
thanks a lot @dry-keyboard-94795 @salmon-account-74572 👏
s

salmon-account-74572

01/04/2024, 5:13 PM
Happy to help!
g

gorgeous-pharmacist-71907

01/04/2024, 7:41 PM
sorry to message again, i've got a test project up and running but it seems as though it's not recognising the stack reference created a
shared
project & stack as we mentioned & exported an output named
IAMUserARN
and verified with
pulumi stack output
then in my
index.ts
for the
staging|prod
stack I've setup, i have the following:
Copy code
const sharedStack = new Pulumi.StackReference("shared")

sharedStack.getOutput("IAMUserARN").apply((arn) => {
    console.log(`${arn}`)
})
when i run
pulumi up
, it doesnt print anything: am i doing something wrong here?
i've tried
<http://Pulumi.log.info|Pulumi.log.info>
too and i get the same result
d

dry-keyboard-94795

01/04/2024, 7:44 PM
The stack reference doesn't look right, it should include a project name and the stack name
And an org name if you're using orgs with pulumi cloud
g

gorgeous-pharmacist-71907

01/04/2024, 7:46 PM
yeah so im using
file://
to store pulumi state i came across this SO post which recommended setting it to just the name of the stack: https://stackoverflow.com/questions/71491871/how-to-reference-another-stack-for-file-backend
d

dry-keyboard-94795

01/04/2024, 7:46 PM
Ah, I'm not familiar with our stack references work for the file backend
g

gorgeous-pharmacist-71907

01/04/2024, 7:47 PM
ah fair enough, yeah it's a tricky one, do you recommend i ask in the general chat or raise an issue on Github? ive scoured google a fair bit and can't see anything on it..
d

dry-keyboard-94795

01/04/2024, 7:53 PM
So you have
backend.url
set in
Pulumi.yaml
?
It looks like you still need to specify both the project and stack name in the reference, but should work
g

gorgeous-pharmacist-71907

01/04/2024, 8:13 PM
i didn't know i had to set
backend.url
, thought
pulumi login file://./
was enough in any case i've added that now just to clarify my project structure is: infra • shared ◦ index.ts ◦ Pulumi.yaml ◦ Pulumi.shared.yaml • resources ◦ iam.ts ◦ ... • index.ts • Pulumi.yaml • Pulumi.staging.yaml • Pulumi.prod.yaml i set the
backend.url
but that didnt seem to work i also tried
shared/shared
as you suggested. the contents of my
Pulumi.yaml
file in the shared directory is:
Copy code
name: shared
runtime: nodejs
description: Shared infrastructure that can be used in other stacks
organization: testorg
backend:
  url: file://./
im guessing that's correct, not sure if ive missed anything
d

dry-keyboard-94795

01/04/2024, 8:15 PM
the backend.url will need to point to the same location in both projects
g

gorgeous-pharmacist-71907

01/04/2024, 8:16 PM
oh okay, let me try that
d

dry-keyboard-94795

01/04/2024, 8:17 PM
If it was unset for both, this would have been the case already, and using
shared/shared
as your stack reference will work
g

gorgeous-pharmacist-71907

01/04/2024, 8:28 PM
okay i think it worked in the
infra
root is where im storing the state so in
infra/shared/Pulumi.yaml
, i set the backend url to
file://../
and in
infra/Pulumi.yaml
, i set the backend url
file://./
so it points to the same dir and then weirdly i tried
shared/shared
but it demanded
organization
at the beginning. changing to
organization/shared/shared
seems to have worked
s

salmon-account-74572

01/04/2024, 8:38 PM
I'll admit that stack references outside of Pulumi Cloud aren't documented well; it's definitely an area where we can provide more examples. That being said, I'm glad it seems to be working for you now.
d

dry-keyboard-94795

01/04/2024, 8:40 PM
Support was only added in the end of March. I don't see many using object/file based state either
Just so you know, by default, secrets won't be encrypted with file-based as far as I know, so be wary of committing the state directory. Also be wary of losing that directory. Going with pulumi cloud is the simplest way of setting up for production, though you can use s3
s

salmon-account-74572

01/04/2024, 8:43 PM
Going with pulumi cloud is the simplest way of setting up for production
100 rainbow
g

gorgeous-pharmacist-71907

01/04/2024, 8:48 PM
yeah that makes sense, im just testing around atm before committing to anything
but good to know
one other q, do you know if its possible to export a provider and use it? eg resources accept the
{provider}
param but the type is
Pulumi.ProviderResource
. however the
sharedStack.getOutput("euWest1Provider")
wont return that type
d

dry-keyboard-94795

01/04/2024, 8:51 PM
It won't, you need to output the parameters from the stack, then initialise again in the receiving stack
g

gorgeous-pharmacist-71907

01/04/2024, 8:52 PM
okay that makes sense, ill try that
thanks
turns out
Pulumi.ProviderResource
is an abstract class so no luck there and also cant use
new AWS.Provider
as that'll just create another provider in the receiving stack
d

dry-keyboard-94795

01/04/2024, 9:09 PM
Creating a provider is the intended usecase
It doesn't create anything in your aws account, it's just configuring auth + how to connect
g

gorgeous-pharmacist-71907

01/04/2024, 9:10 PM
okay in that case no need to create in the shared then
d

dry-keyboard-94795

01/04/2024, 9:11 PM
Pulumi provides you a defualt provider, that can be configuring using the config file, or environment variables
It's best to use environment variables, so you're not storing any secrets in files
g

gorgeous-pharmacist-71907

01/04/2024, 9:13 PM
yup so setup the default one but theres cases where we want to create infra in different regions and so want to manually set that per resource
d

dry-keyboard-94795

01/04/2024, 9:15 PM
Correct
i

icy-controller-6092

01/05/2024, 6:05 AM
interesting discussion on the need to create 2 projects, imo I'd create one project -- I don't see any downside to using different programs for different stacks in the same project file structure is easy enough, you just have a dedicated folder for each program type. multiple folders can share the same
Pulumi.yaml
project name and if it's important to distinguish which program was used to create which stack, you can export static identifiers from your program
I do this currently, where I have a lot of stacks in one project, using a different program for each microservice. The naming convention is
[service].[env]
keen to understand if there's anything I'm missing that might come to bite me later on down the road...
2 Views