bored-table-20691
02/03/2022, 9:57 PMinfra
project that provisions all the infrastructure needed (e.g. EKS, RDS, VPC and so on), and then a tenant
project where we provision some per-tenant resources in an individual stack per tenant (and this uses a stack reference back to an infra
- which one to use in the stack config).
So now, if I want to have dev/staging/prod type separation, I can do it in a couple of high level ways:
1. One project for infra
and then just name them appropriately or set some property on each stack which type of environment it lives in.
2. A project for infra
per environment (dev/staging/prod).
Same options exist for the tenant
project as well (i.e. one project for all envs or one per env).
Code duplication is not a huge issue - 99% of the code is in some shared libraries, so the main.go
for us is very small.
The main tradeoff in my mind is that with (1), we get the simplicity of a single project, but now if we want to do something for “all staging stacks”, it becomes a much more complex operation (need to decide how to distinguish them, etc). For (2), it’s kind of reversed.
I was wondering if folks have any real life experience or advice to share.little-cartoon-10569
02/03/2022, 10:07 PMechoing-dinner-19531
02/03/2022, 10:07 PMbored-table-20691
02/03/2022, 10:30 PMinfra
stacks are more like independent cells, so they share nothing with each other. I’m just thinking what I should do now to make the future easier in terms of manageability, CI/CD, permissions.
Changing this stuff tends to be painful 🙂little-cartoon-10569
02/03/2022, 10:32 PMbored-table-20691
02/03/2022, 10:33 PMinfra-dev-project/
dev-stack1.yaml
dev-stack2.yaml
...
infra-staging-project/
...
infra-produ-project/
...
or
infra-project/
dev-stack1.yaml
staging-stack1.yaml
...
Then if an operation I wanted to do was something like “update all staging stacks”, the logic would be quite different between the two options.little-cartoon-10569
02/03/2022, 10:37 PMbored-table-20691
02/03/2022, 10:41 PMgit
branches seem like not a good fit, especially for trunk-based development.
An example operation is “I want to update all the production infra stacks” - that now involves me somehow deciding from the stack what is a production one and what isn’t, as opposed to just listing all the stacks in the infra-prod
project. I can of course add some custom config or use naming convention for this, but it does add complexity.little-cartoon-10569
02/03/2022, 10:51 PMbored-table-20691
02/03/2022, 10:52 PMbored-oyster-3147
02/03/2022, 11:00 PMbored-table-20691
02/03/2022, 11:06 PMbored-oyster-3147
02/03/2022, 11:09 PM/infra
while your pulumi state backend could reflect /infra-{env}
- so you could simulataneously have no code duplication in your repository and split your environments into different pulumi projects from the perspective of the statebored-table-20691
02/03/2022, 11:10 PMpulumi up
and so on, to make it easier to do iterative dev work on the stack itself.