broad-pencil-85643
09/30/2019, 6:02 AMdev/applications/api-content
, staging/applications/api-content
, and prod/applications/api-content
. Each of these directories have their own Terraform configs that might describe an S3 bucket or two, the EB app, an EB environment (or two), DBs, etc. Importantly, they're not all the same underlying infrastructure/resources.
Initially I figured re-creating this setup could be done by having, e.g., an api-content
project with dev
, staging
, and prod
stacks. But since, for example, there might not be an S3 bucket in the dev
stack whereas there is in staging
and prod
, it started to look like there would be a lot of if/else statements in my Pulumi source files. Do you think it might make more sense to create a project per environment, each with a single stack? That way I could ensure the Pulumi source is tailored specifically to each environment, and can still have something like a common project/stack that each environment pulls from for conventions/components shared between these environments.broad-dog-22463
09/30/2019, 8:33 AMcalm-table-93204
09/30/2019, 1:45 PMacoustic-noon-6208
09/30/2019, 3:24 PMpulumi.runtime.getStack();
and that way detect running stack and execute required changes for that specific stack. You can see this approach here (WIP, lots of things require refactoring, but most important it works 😄): https://github.com/ever-co/gauzy-pulumi/blob/develop/index.tsalert-beard-9601
09/30/2019, 4:33 PMbroad-pencil-85643
09/30/2019, 10:27 PMdev
, staging
, prod
, and shared
projects. That way everything that lives in the shared
project would be almost identical, except for config-level changes between stacks. Any more extreme outliers between each environment could be managed in the appropriate environment's project. For example, if we need 3 Elastic Beanstalk environments in dev
because we're testing 2 environments that might never make their way to staging
or prod
, we can describe the 1 shared environment in the shared
project, and those other 2 outliers just stay in dev
(and can be elevated up to shared
if they make the cut).
The one downside of this as opposed to creating very granular "micro-stacks" seems to be that any time I do pulumi up
for a given project, it has a lot more heavy-lifting to do to determine changes (since it's acting on an entire vertical slice of our infrastructure vs. a single application's stack). But that's kind of a separate issue of monolithic vs. micro-stacks, it seems.