https://pulumi.com logo
Join Slack
Powered by
Hello, I'm a backend developer trying to get into ...
# general
f
Hello, I'm a backend developer trying to get into AWS and DevOps, so I'm using Pulumi to accomplish that. I'm just confused on how injecting resources allocated via Pulumi works. Should I inject into my backend a stack name such as "Org/Project/Stack" and then use LocalWorkspace to get it my resources, or should I do it manually via a .env
l
That depends entirely on your use-case. If you're building a self-help console in a web page, you'd probably use a text field or dropdown. If you're writing a simple CLI, then CLI params might work well.
If you're learning Pulumi, you should probably not start with automation-api. First learn the traditional way of doing things, which will cover stack management and design. Then add automation-api in a future project.
f
So, what is a way of obtaining my exported variables from Pulumi, into a real app in order to inject it into what ever service needs it? Without the Automation API.
l
If you just want to grab output values from a stack, 
pulumi stack output --stack org/proj/stack
should give you everything you need. Pulumi ESC is a full product that gives you that and a lot more, if you need it. And you can use the Pulumi service API, if your stack is in Pulumi Cloud.
f
So that makes sense if I were developing through a dockerfile, as I would be able to call pulumi stack output then pass it in my app directly, however developing through docker is a pain imo, this makes a lot of sense for a production dockerfile though.
I think I'll either just use a Secrets Manager or manually just inject it via a .env file. But thanks for your help.
l
Why can't you just call 
pulumi
? Are you wanting your production application to get values from your deployment application? A vault is indeed the best way to solve that problem.
Your production application shouldn't have the change if you decide to switch from Pulumi to some other tool, next year.
l
You have a rest api or something that needs to know the name of the s3 bucket generated by pulumi etc? Yeah I would push it to ssm param store or secrets manager. If its only a few variables then its probably not the end of the world to manually copy those over either
f
Yeah exactly, I just want a dynamic way of doing things since Pulumi's whole thing is automation. Its definitely not the end all be all.
l
yeah I would maybe say it depends on how many times you'll create this. If its a per-customer thing and you'll spin up hundreds or thousand instances of this stack, then it needs automating. However if it's just a single thing that will never change, it's probably fine to carry the values over manually
f
Well it will change based on environments but that’s about it.
I’m trying to use LocalStack as a dev stack and then real aws as prod stack. A dynamic way of injecting would be nice for that but like you said a param store would be perfect.
l
As I understand it, changing backend requires a change to ~/.pulumi/credentials.json, so there's no way to do that from within your Pulumi program. You probably need to wrap how you call Pulumi in a script, using 
pulumi login
each time.
This isn't a common pattern though. The AWS backend should be completely unrelated to your stacks: don't even use the same AWS account. It should be fine to use one backend for all your stacks, even ones that aren't being deployed to AWS. You can use an AWS backend to deploy to any target cloud or system: the backend is just a place to store a few JSON files, as far as Pulumi is concerned.
f
Well LocalStack has a wrapper that handles all of it, just have to use their Pulumi-Local cli for the dev stack then use the normal Pulumi for the real one
l
I don't know what that means.
f
l
I'm wondering if that leaves the config totally clean, ready for switching between pulumi and pulumi-local. You'll be the expert on that. You still should be able to use real S3 bucket backend for both, LocalStack as your deployment target for dev, and AWS as your target for everything else. I think changing the backend based on stack is an unnecessary complication.
f
The backend won't change its just the dependencies injected into the backend will. The infrastructure will be the same, its just there will be two different infrastructures and the app will need to be injected the correct one based on the environment.
Like in development use the dev stacks' LocalStack S3, and in production use the real AWS S3.
l
Yes, and there isn't a need to have that difference. You use a non-prod S3 for your backend, and both dev and prod state files get stored there.
It is easier, and good practice, to store the state json files for all stacks in the same place. It's how Pulumi prefers to work
f
Okay, but lets' say the service I'm using is more complicated than S3
Something that needs more precise control
l
I'm talking only about the backend, Which is a few JSON files.
Not the deployed resources. Just the Pulumi state files.
f
Yeah that's fine
l
The backend is not the deployed infrastructure
Ok. So there's no need to change the backed. Use the same one for all stacks.
f
all of them will have the same "state"
l
No.
The backend is like a directly. State is like files in that directory
All the states will be separate files, just in the same S3 bucket, or in the Pulumi service, or whatever
f
I don't understand what you are getting at. But don't feel the need to explain it, I feel as though we're not on the same page about what where conversing about.
l
Ok. Have you got everything working? If not, rather than trying to get it working the way you think you need it to, try getting it working the way Pulumi wants it to. Then after that's working, change it to work the way you want it to. You may learn about how Pulumi works, as you work through things.
Because it seems like you're trying to do too many tricky things all at once.
f
Look lol, Pulumi is working great. I just wanted to know the best practice of injecting pulumi created resources into a backend.
l
Resources don't go into a backend
f
Then how does a backend interact with a resource if it doesn't have a way of identifying it.
l
This is the problem we're having in our conversation. We have different understand of what needs to happen.
I am confident you're using the work "backend" in a way that Pulumi doesn't use it.
And that is the root of our conversational difficulties
f
I'm talking about a literal Backend. Like a server.
l
Ah. Well, then you need to use a different word in this Slack. Because here, "backend" means a small storage area used to store Pulumi state files.
f
Like I said, we were not on the same page about what we're conversing about lol. All good though.
l
Yep. You need to use Pulumi language here, sorry.
Open in Slack
PreviousNext
Powered by