When building landing zones, the automation we want to make available to meshStack (e.g. Lambdas) may live in a range of different automation accounts.
The gcp-meshplatform module has solved this quite usefully with this "lz-access" modules https://github.com/meshcloud/terraform-gcp-meshplatform/tree/main/modules that I can compose as necessary (I may need 0...n of these, depending on how many landing zones I have making use of these features)
With GCP we have moved the composition to the user of the module, it can look like this
module "meshplatform" {
...
}
locals {
# terraform can only for_each on sets, so we need to build a meaningful key
functions_map = { for x in var.landingzone_access.functions : "${x.project}:${x.region}:${x.function}" => x }
}
module "meshcloud-replicator-lz-access-cloudfunction" {
source = "git::https://github.com/meshcloud/terraform-gcp-meshplatform.git//modules/meshcloud-replicator-lz-access-cloudfunction?ref=9d76f7bedf9f652817e6fadc7d5e0e4bfa86dd5c"
for_each = local.functions_map
sa_email = module.meshplatform.replicator_sa_email
cloud_function = each.value.function
region = each.value.region
project_id = each.value.project
}
locals {
# terraform can only for_each on sets, so we need to build a meaningful key
gdm_map = { for x in var.landingzone_access.gdm_templates : "${x.project}:${x.bucket_name}" => x }
}
module "meshcloud-replicator-lz-access-gdm" {
source = "git::https://github.com/meshcloud/terraform-gcp-meshplatform.git//modules/meshcloud-replicator-lz-access-gdm-template/?ref=9d76f7bedf9f652817e6fadc7d5e0e4bfa86dd5c"
for_each = local.gdm_map
sa_email = module.meshplatform.replicator_sa_email
project_id = each.value.project
bucket_name = each.value.bucket_name
}
We could move that composition of lz-access modules into the meshplatform module itself by offering a var.landingzone_access variable, but I'm not sure if that could be built for AWS since you also most likely need different aws provider configurations for each of those accounts holding landing zone automations.
My first suggestion would thus be to adopt the same approach as the GCP meshPlatform module structure and allow the caller to compose their meshPlatform + lz-access modules as required
When building landing zones, the automation we want to make available to meshStack (e.g. Lambdas) may live in a range of different automation accounts.
The gcp-meshplatform module has solved this quite usefully with this "lz-access" modules https://github.com/meshcloud/terraform-gcp-meshplatform/tree/main/modules that I can compose as necessary (I may need 0...n of these, depending on how many landing zones I have making use of these features)
With GCP we have moved the composition to the user of the module, it can look like this
We could move that composition of lz-access modules into the meshplatform module itself by offering a
var.landingzone_accessvariable, but I'm not sure if that could be built for AWS since you also most likely need different aws provider configurations for each of those accounts holding landing zone automations.My first suggestion would thus be to adopt the same approach as the GCP meshPlatform module structure and allow the caller to compose their meshPlatform + lz-access modules as required