topic Re: Best Practices for Organizing Terraform Configuration for Dynatrace in Open Q&A

Best Practices for Organizing Terraform Configuration for Dynatrace

lwaldrop — Wed, 02 Apr 2025 07:10:06 GMT

Hi everyone,

I'm working on implementing a Terraform configuration for Dynatrace across multiple environments (e.g., prod, test). I have no issues exporting the existing configuration or importing state, but I’m looking for advice on how to best organize the exported data.

By default, the export creates a structure with a configuration folder with modules. Is this the recommended approach, or is there a better way to structure it—especially when managing multiple environments?

Since I'm new to this, I’d appreciate any guidance on how to visualize and structure the project effectively. Here’s what my directory looks like after a partial export:

C:\Users\Lance\source\repos\

dynatrace-terraform-project\
- .terraform\...\terraform-provider-dynatrace_v1.73.0.exe
- configuration\
  - .terraform
    - modules\modules.json
    - providers\...\terraform-provider-dynatrace_v1.73.0.exe
  - modules/alerting/.tf files for alerting configuration including a providers and variables.tf (example)
  - .terraform.lock.hcl
  - providers.tf
  - main.tf
- .terraform.lock.hcl
- providers.tf

Sincerely,
Lance

Re: Best Practices for Organizing Terraform Configuration for Dynatrace

SjoerdB — Mon, 03 Feb 2025 11:00:42 GMT

Hi @lwaldrop ,

I created a terraform structure, where I use separate terraform-workspaces to keep the state of the individual tenants (Dev/Test/Acc/Prod), and created settings.yaml file per environment:

terraform
- environments
  - develop
    - settings.yaml
  - test
    - settings.yaml
  - acceptance
    - settings.yaml
  - production
    - settings.yaml

In the locals.tf, I read the correct settings file per tenant, based on the workspace name.... So if I "terraform workspace select develop", automatically my /environments/develop/settings.yaml gets activated.

In this way I can easily create specific variables containing configuration items/names specific to an environment (e.g. HOST-GROUP-12345678) or specific name-prefixes which are different between environments (e.g. subdirectory names in log directories).

Further I created multiple "top-level" main-entries, like "system" and "sre" to make a splitting between resonsibilities. Inside those directories I'm keeping the original module names as visible in the export, because that gives me a hint of the original API/rule that is used to inject the setting...

terraform
- environments (see above)
  - develop
    - settings.yaml
  - test
    - settings.yaml

- - acceptance
    - settings.yaml
  - production
    - settings.yaml

system
- dashboards_general
- ...
sre
- custom_service
- ...
locals.tf
main.tf
version.tf

hope this helps somewhat...

Re: Best Practices for Organizing Terraform Configuration for Dynatrace

lwaldrop — Tue, 04 Mar 2025 20:57:50 GMT

Hey SjoerdB -- Thanks for the advice. Definitely get's me a good starting point. Appreciate your help. 🙂

Re: Best Practices for Organizing Terraform Configuration for Dynatrace

m3tomlins — Tue, 01 Apr 2025 20:45:33 GMT

Thank you @SjoerdB - I'd be very curious to learn more about how you've built this out with Terraform workspaces. It seems like a slick way to have support for a common configuration of resources across mutiple, separate Dynatrace tenants each with unique id's for the same configurations (e.g. scoped by host group, host id, service id, etc) Do you have a repo somewhere or more detailed examples to share?