Spoko, to wyglada na rozwiazanie posrednie, ale znowu wiem ze niektorzy je stosuja, chociaz przyznam szczerze wywodzac sie ze srodowiska Azure, gdzie korzystalem z natywnych tooli do IaC jak ARM/Bicep nigdy na oczy takiego setupu nie widzialem i troche go osobiscie nie rozumiem.
Jak ja zazwyczaj robie w przypadku Terraforma na Azure (jak robie definicje infry pod konkretny projekt, jak to ma byc wspoldzielone repo z bazowymi modulami do uzytku w organizacji, albo jakis service catalog to bedzie pewnie inaczej):
/
└── terraform
│ └── environments
│ ├── dev.tfvars
│ └── prod.tfvars
├── main.tf
├── variables.tf
├── outputs.tf
├── storage.tf
├── keyvault.tf
├── database.tf
└── appservice.tf
Czyli dokladnie jeden modul glowny (nie mam main.tf per srodowisko) po prostu w rozny sposob parametryzowany pomiedzy srodowiskami.
Korzystałeś może z terraform backend?
Korzystalem, bo chyba nie da sie korzystac z TF bez backendu :D
Ale tylko z Azurowego Blob Storage.
Da się korzystać bez backendu, bo wtedy Ci state trzyma lokalnie, ale jest to troche śliskie mimo wszystko.
To co mam teraz to działa praktycznie tak samo jak twoje, tylko, że w .tfvars trzymam głównie jakieś secrety czy inne rzeczy które są z natury zmienne albo prywatne a w main.tf (tym dla konkretnego środowiska) już są bardziej statycznie zdefiniowane wartości które lecą do konkretnego modułu, jak np:
module "aws-lambda-export" {
source = "../../modules/aws-lambda/aws-lambda-export"
node_env = "dev"
lambda_name = "jakas_nazwa"
runtime = "nodejs18.x"
iam_role = module.aws-iam.lambda_iam_role
lambda_bucket = module.aws-s3.lambda_bucket
mongodb_name = var.mongodb_name
mongodb_url = var.mongodb_url
memory_size = 2048
timeout = 600
}