Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-ai
pulumi-cdk
pulumi-cloud
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Title
a
able-honey-93860
12/29/2021, 4:30 AMCan please help me break down stacks vs projects? My current understanding is that a Project should be high level like Prod and Dev environments then a stack would be smaller cases of the managed environments. Here's the structure I am going for, is this best practice?
Project: AWS_Prod
Stack:
◦ s3
◦ ec2
Project: AWS_Dev
Stack:
◦ s3
◦ ec2
Project: Okta_Prod
Stack:
◦ users
◦ authentication
l
little-cartoon-10569
12/29/2021, 4:36 AMMost people prefer to use a project as a group of related resources that need to be deployed at the same time (e.g. shared database, app1, shared network, etc.); and a stack is an instance of the (e.g. dev, staging, prod).
✅ 1
So you can deploy a prod database and a dev database from the same project.
The code is shared between all stacks in a project, and the stack is just the configuration values, like region, prefix, etc.
a
able-honey-93860
12/29/2021, 6:09 AMThis is awesome man thanks for the help!
Typically I like to keep dev and prod isolated completely. It seems like it would be bad practice to have dev code right next to prod code. But I guess in pulumi context you still have to specify the stack so theoretically it's isolated?
l
little-cartoon-10569
12/29/2021, 7:32 PMThe purpose of non-prod code is to ensure prod code is good.
If you're not using prod code in earlier stacks, then you may want to rethink.
You said " It seems like it would be bad practice to have dev code right next to prod code." There is no "next to". It's the same code. Dev is just different parameters.
c
colossal-boots-62227
12/31/2021, 5:22 AMI agree that having all environments/stacks use the same code is a huge advantage - being able to just change a stack name (and perhaps a region) and deploy in Pulumi is really powerful. The only wrinkle I’ve found is for globally shared resources (mainly AWS Route53 zones) for which I have a
globalall