Terraform: балансировщик нагрузки для публичных и частных приложений с использованием модуля с интерполяцией

Question

У меня есть сценарий использования, в котором я хотел создать 2 балансировщика нагрузки приложения, одно будет общедоступным, другое будет частным с использованием модулей terraform.

Я знаю, что мы можем создать 2 каталога с одинаковым кодомдля приватных и общедоступных параметров соответственно, но я пытался создать оба балансировщика нагрузки, используя интерполяцию terraform, как упомянуто ниже.

Модуль ALB:

resource "aws_alb" "default" {
  name            = "${var.name}-${var.env_name}-${var.internal == "false" ? "public" : "private" }"
  internal        = "${var.internal == "false" ? "false" : "true" }"
  security_groups = ["${var.internal == "false" ? var.sg80 : var.instance_in_all }"]
  subnets         = ["${var.internal == "false" ? var.public_subnets : var.private_subnets }"]
}

main.tf из того места, где я вызываю модуль alb.

module "public-alb" {
      source         = "../../modules/alb"
      name           = "example"
      internal       = "false"                         #internal: Give it false for public load balancer.
      env_name       = "production"
      vpc_id         = "${module.vpc.vpc_id}"
      public_subnets = "${module.vpc.public_subnets}"
      private_subnets = "${module.vpc.public_subnets}" #This does not matter here because check condition in internal file.
      sg80           = "${module.security-group.sg80}"
      instance_in_all = "${module.security-group.instance_in_all}" #This does not matter here because check condition in internal file.
    }

module "private-alb" {
      source         = "../../modules/alb"
      name           = "example"
      internal       = "true"                          #internal: Give it false for public load balancer.
      env_name       = "production"
      vpc_id         = "${module.vpc.vpc_id}"
      private_subnets = "${module.vpc.public_subnets}"
      public_subnets = "${module.vpc.public_subnets}" #This does not matter here because check condition in internal file.
      sg80           = "${module.security-group.sg80}" #This does not matter here because check condition in internal file.
      instance_in_all = "${module.security-group.instance_in_all}" 
    }

Итак, для общего балансировщика нагрузки я должен передать частные подсети и внутреннюю группу безопасности с частным балансировщиком нагрузки.передать открытые подсети и внешнюю группу безопасности, потому что я передаю эти переменные из variables.tf (упомянутого ниже), в котором нет необходимости.

variable "vpc_id" {}

#variable "private_subnets" {   type        = "list"}
variable "sg80" {}

variable "public_subnets" {
  type = "list"
}

variable "name" {}

variable "internal" {}

variable "env_name" {}

variable "private_subnets" {
    type  = "list"
}

variable "instance_in_all" {}

Я хотел бы знать, является ли это правильным способом или отдельнымкаталог является единственным обходным решением на данный момент.

Answer 1

Пара возможных сценариев:

1) Максимальная конфигурируемость: я бы не выставлял обе переменные, необходимые для публичного и частного использования.Всего одна переменная называется «подсетями» и присваивает значение переменной снаружи модуля.Кроме того, при передаче как private_subnets, так и public_subnets, если вы будете использовать модуль в среде, которая содержит только общедоступный балансировщик нагрузки, вам придется каким-то образом обойти передачу частных подсетей и групп безопасности, затрудняя повторное использование.

2) Меньше шаблонного, вот как я интерпретирую ваш вопрос: Использование источников данных внутри модулей.Если вам нужна полная автономия (например, только pass internal = true / false), и у вас есть фиксированные подсети и группы безопасности для этих сценариев, вы можете получить их, используя источники данных, где запрос зависит от того, является ли var.internal истинным или ложным.

Пример:

data "aws_security_groups" "private_lb" {
  tags {
    SomeTag = "something_that_accurately selects my private security groups"
  }
}

data "aws_security_groups" "public_lb" {
  tags {
    SomeTag = "something_that_accurately selects my public security groups"
  }
}

resource "aws_alb" "default" {
  name = "${var.name}-${var.env_name}-${var.internal == "false" ? "public" : "private" }"
  internal = "${var.internal == "false" ? "false" : "true" }"

  security_groups = ["${var.internal == "false" ? data.aws_security_groups.public_lb.ids : data.aws_security_groups.private_lb.ids }"]

  etc...
}

Конечно, вы также можете поместить условную часть в сам источник данных, например, изменить фильтры на основе var.internal.

Третийвариант может заключаться в том, чтобы создать выделенную группу безопасности внутри вашего модуля и назначить правила входа / выхода по умолчанию на основе var.internal, предоставляя идентификатор этой группы в вашем output, чтобы вы могли добавить к ней дополнительные правила извне модуля.