[iliaxj]

We use a single codebase to deploy to multiple environments. The setup looks like this:

  - root
  -- /envs
  --- / dev.tfvars
  --- / prod.tfvars
  - main.tf

When it gets deployed by the CICD, the right tfvars file is passed in via the -var-file parameter. A standard `env` var is also passed in, and used as a basis for a naming convention. Backend is also set by the pipeline.

The rationale here is that our environments should be almost the same between them, and any variations should be accomplished by parameterization.

Modules are kept either in separate repos, if they need to be shared between many workspaces, or under the `modules` subfolder.

[based2]

alt

    - root
     -- /envs
     --- / .dev.env
     --- / .test.env
     --- / .prod.env
     --- / dev.tfvars
     --- / test.tfvars
     --- / prod.tfvars
     - 1_create_network.tf
     - 2_create_storage.tf
     - 3_create_service.tf

https://www.youtube.com/watch?v=WgPQ-nm_ers Compliance At Scale: Hardened Terraform Modules at Morgan Stanley

https://www.weekly.tf/

[carty7]

Thanks for sharing. I’ll add the video to my queue.

[FrenchyJiby]

Yeah I'm confused why none of the solutions presented deploy the same TF across the environments: Surely if you have dev vs prod, 90% of dev infra is also needed in prod?

Then sure sprinkle a few per-env-toggles `count: 1 if env == dev else 0` (or whatever the latest nicest way to do that is today), but it feels weird to have to set up an artificial TF module around our entire codebase to be able to share the bulk of the code?

[manfre]

Instead of env conditionals, I strongly recommended feature/functionality conditionals or variables. E.g. var.create_s3 is better than var env == 'prod'

[baby_souffle]

+1 for this. Do as much as you can in modules and write each of your modules to have a simple enable or disable input.

[bloopernova]

I just wanted to clarify: are you referring to this pattern?

  module "cool_name" {
    count  = var.create_cool_name ? 1 : 0
  }

I've always wanted a simple enable/disable syntax for modules in tf.

[baby_souffle]

> I just wanted to clarify: are you referring to this pattern?

Does TF support count on modules now?! The pattern I was referring to is akin to having an `enabled` var that you define in _every_ module (there are ways to make this easier to do [0]) and inside of each module you have a

    local {
        make_the_s3_bucket = var.enabled && var.make_s3_bucket
        make_the_rds_instance = var.enabled && var.enable_rds
    }

Then you use the typical `count: foo == bar ? 1:0` trick where some part of the `foo/bar` conditional ropes in local.make_the_rds_instance

[0]: https://github.com/cloudposse/terraform-null-label/tree/main

[bloopernova]

https://developer.hashicorp.com/terraform/language/modules/s...

count - Creates multiple instances of a module from a single module block.

for_each - Creates multiple instances of a module from a single module block.

providers - Passes provider configurations to a child module. If not specified, the child module inherits all of the default (un-aliased) provider configurations from the calling module.

depends_on - Creates explicit dependencies between the entire module and the listed targets.

I hope this doesn't come across as snarky, I just wanted to share the doc link :)

[bloopernova]

Yeah I use the count attribute on modules all the time.

Thank you for replying though, I appreciate it :)

[forty]

In practice for complex env it ends up creating a lot of if(env) and the code ends up being horrible. At least it was our experience and we ended up having common modules instantiated in different environment as needed, which was much nicer