Terraform — могут ли исходные модули использовать разные источники данных для каждого экземпляра ОС?

Question

У меня есть ресурс «aws_instance» (в исходном модуле), который отлично работал для загрузки экземпляров Centos, Coreos или Ubuntu через user_data = data.template_file.user-data.renderedс помощью следующего блока данных;

      data "template_file" "user-data" {
  template = file("${path.module}/bootstrap-${var.os_distro}.sh")

  vars = {
    access_port     = var.access_port
    service_port1   = var.service_port1
    docker_api_port = var.docker_api_port
  }
}

Затем связанный файл (например, bootstrap-centos.sh) загружался и отображался в зависимости от значения переменной $os_distro в корневом модуле.

Все было хорошо, пока я не переключился с coreos на coreos fedora... проблема в том, что теперь мне нужно сначала вызвать другой источник данных (ct_config), чтобы передать файл bootstrap-fcos.yaml для зажигания.

Есть ли какая-либо логика, которую я могу использовать в исходном модуле для использования другого источника данных, когда я хочу развернуть Fedora Coreos AMI? Кажется, что совершенно против мощности модулей terraform пойти по простому пути и создать новый исходный модуль только для этой новой ОС.

Основные части исходного и корневого модулей:

ИСТОЧНИК МОДУЛЬ

      resource ` "my-ec2-instance" {
  count                       = var.node_count
  availability_zone           = element(var.azs, count.index)
  subnet_id                   = var.aws_subnet_id
  private_ip                  = length(var.private_ips) > 0 ? element(var.private_ips, count.index) : var.private_ip
  ami                         = var.machine_ami
  instance_type               = var.aws_instance_type
  vpc_security_group_ids      = [aws_security_group.my-sg-group.id]
  key_name                    = var.key_name
  user_data                   = data.template_file.user-data.rendered
  monitoring                  = false
  ebs_optimized               = false
  associate_public_ip_address = var.public_ip

  root_block_device {
    volume_type           = var.root_volume_type
    volume_size           = var.root_volume_size
    delete_on_termination = true
  }
}


data "template_file" "user-data" {
  template = file("${path.module}/bootstrap-${var.os_distro}.sh")

  vars = {
    access_port     = var.access_port
    service_port1   = var.service_port1
    docker_api_port = var.docker_api_port
  }
}

variable "user_data" {
  type        = string
  description = "userdata used to bootstrap the node"
}

variable "os_distro" {
  type        = string
  description = "choose centos coreos or ubuntu to load either bootstrap-centos.sh, bootstrap-ubuntu.sh or bootstrap-coreos.sh from this module"
}

КОРНЕВОЙ МОДУЛЬ

      module "demo_coreos_stg_ec2" {
  source = ".../aws/ec2"                    # as per source module code above
  node_count        = local.node_count
  azs               = local.azs
  aws_subnet_id     = "subnet-c18c0fbb"                         
  private_ips       = ["172.31.16.20"]                          
  machine_ami       = data.aws_ami.fcos-stable-latest.id    # latest stable fedora coreos release
  aws_instance_type = "t2.micro"
  key_name          = "keys-2020"
  user_data         = data.ct_config.boot_config.rendered       # convert the boot config in yaml to the ignition config in json via ct (config transpiler)
  os_distro         = var.os_distro             # enables either bootstrap-centos.sh, bootstrap-ubuntu.sh or bootstrap-coreos.sh from this module

data "ct_config" "boot_config" {
  content = data.template_file.fcos.rendered
  strict = true
  pretty_print = true
}

data "template_file" "fcos" {
  template = file("${path.module}/bootstrap-fcos.yaml")
  vars = {
    access_port     = var.access_port
    service_port1   = var.service_port1
    docker_api_port = var.docker_api_port
  }
}

Обратите внимание, что корневой модуль должен иметь возможность сначала использовать источник данных ct_config , прежде чем использовать источник данных template_file для загрузки bootstrap-fcos.yaml для интерполяции. Раньше все 3 ОС могли использовать template_file для загрузки своего файла .sh.