Terraform: инфраструктура на уровне кода

В главе 3 вы поместили скрипт пользовательских данных для кластера веб-серверов во внешний файл, user-data.sh, и применили встроенную функцию file, чтобы прочитать его с диска. Неочевидный момент функции file состоит в том, что файловый путь, который она использует, должен быть относительным (поскольку Terraform можно запускать на множестве разных компьютеров) — но относительно чего?

По умолчанию Terraform интерпретирует этот путь относительно текущей рабочей папки. Это не вызывает проблем, если вы используете функцию file в конфигурационном файле Terraform в той же папке, из которой выполняется команда terraformapply (то есть если функция file применяется в корневом модуле). Но если сделать то же самое в модуле, размещенном в отдельной папке, ничего не будет работать.

Решить эту проблему можно с помощью выражения, известного как «ссылка на путь», которое имеет вид path.. Terraform поддерживает следующие типы этих ссылок.

• path.module — возвращает путь к модулю, в котором определено выражение.

• path.root — возвращает путь к корневому модулю.

• path.cwd — возвращает путь к текущей рабочей папке. При нормальном использовании Terraform это значение совпадает с path.root, но в некоторых нестандартных случаях Terraform запускается не из папки корневого модуля, что приводит к расхождению этих путей.

Для скрипта пользовательских данных нужен путь, взятый относительно самого модуля, поэтому в источнике данных template_file в файле modules/services/webser-vercluster/main.tf следует применять path.module:

data "template_file" "user_data" {

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

  vars = {

    server_port = var.server_port

    db_address  = data.terraform_remote_state.db.outputs.address

    db_port     = data.terraform_remote_state.db.outputs.port

  }

}

Вложенные блоки

Конфигурацию некоторых ресурсов Terraform можно определять отдельно или в виде вложенных блоков. При создании модулей всегда следует отдавать предпочтение отдельным ресурсам.

Например, ресурс aws_security_group позволяет определять входящие и исходящие правила в виде вложенных блоков. Вы уже это видели в модуле webserver-cluster (modules/services/webserver-cluster/main.tf):

resource "aws_security_group" "alb" {

  name = "${var.cluster_name}-alb"

  ingress {

    from_port   = local.http_port

    to_port     = local.http_port

    protocol    = local.tcp_protocol

    cidr_blocks = local.all_ips

  }

  egress {

    from_port   = local.any_port

    to_port     = local.any_port

    protocol    = local.any_protocol

    cidr_blocks = local.all_ips

  }

}

Вы должны модифицировать этот модуль так, чтобы те же входящие и исходящие правила определялись в виде отдельных ресурсов aws_security_group_rule (не забудьте сделать это для обеих групп безопасности в данном модуле):

resource "aws_security_group" "alb" {

  name = "${var.cluster_name}-alb"

}

resource "aws_security_group_rule" "allow_http_inbound" {

  type              = "ingress"

  security_group_id = aws_security_group.alb.id

  from_port   = local.http_port

  to_port     = local.http_port

  protocol    = local.tcp_protocol

  cidr_blocks = local.all_ips

}

resource "aws_security_group_rule" "allow_all_outbound" {

  type              = "egress"

  security_group_id = aws_security_group.alb.id

  from_port   = local.any_port

  to_port     = local.any_port

  protocol    = local.any_protocol

  cidr_blocks = local.all_ips

}

При попытке одновременного использования вложенных блоков и отдельных ресурсов вы получите ошибки, когда правила маршрутизации конфликтуют и переопределяют друг друга. Поэтому вы должны выбрать что-то одно. В связи с этим ограничением при создании модуля всегда следует использовать отдельные ресурсы вместо вложенных блоков. В противном случае ваш модуль получится менее гибким и конфигурируемым.

Например, если все входящие и исходящие правила в модуле webserver-cluster определены в виде отдельных ресурсов aws_security_group_rule, вы сможете сделать этот модуль достаточно гибким для того, чтобы разрешить пользователям добавлять собственные правила за его пределами. Для этого идентификатор aws_security_group нужно экспортировать в виде выходной переменной внутри modules/services/webserver-cluster/outputs.tf:

output "alb_security_group_id" {

  value       = aws_security_group.alb.id

  description = "The ID of the Security Group attached to the load balancer"

}

Теперь представьте, что вам нужно сделать доступным извне дополнительный порт, сугубо для тестирования. Теперь это легко сделать: нужно лишь добавить в файл stage/services/webserver-cluster/main.tf ресурс aws_security_group_rule:

resource "aws_security_group_rule" "allow_testing_inbound" {

  type              = "ingress"

  security_group_id = module.webserver_cluster.alb_security_group_id

  from_port   = 12345

  to_port     = 12345

  protocol    = "tcp"

  cidr_blocks = ["0.0.0.0/0"]

}