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

  security_groups = [aws_security_group.instance.id]

  user_data = <<-EOF

              #!/bin/bash

              echo "Hello, World" > index.html

              nohup busybox httpd -f -p ${var.server_port} &

              EOF

  # Требуется при использовании группы автомасштабирования

  # в конфигурации запуска.

  # https://www.terraform.io/docs/providers/aws/r/launch_configuration.html

  lifecycle {

    create_before_destroy = true

  }

}

Для работы группы ASG требуется еще один параметр: subnet_ids. Он определяет подсети VPC, в которых должны быть развернуты серверы EC2 (справочная информация о подсетях дается во врезке «Сетевая безопасность» на с. 79). Каждая подсеть находится в изолированной зоне доступности AWS (то есть в отдельном вычислительном центре), поэтому, развертывая свои серверы по разным подсетям, вы гарантируете, что ваш сервис продолжит работать, даже если некоторые из вычислительных центров выйдут из строя. Список подсетей можно прописать прямо в коде, но такое решение будет сложно поддерживать и переносить. Вместо этого лучше использовать соответствующий источник данных для получения списка подсетей, принадлежащих к вашей учетной записи AWS.

Источник данных представляет собой фрагмент информации, доступной сугубо для чтения, который извлекается из провайдера (в нашем случае из AWS) при каждом запуске Terraform. Добавляя источник данных в конфигурацию Terraform, вы не создаете ничего нового. Это просто возможность запросить информацию из API провайдера, чтобы сделать ее доступной для остального кода Terraform. Каждый провайдер предоставляет целый ряд источников. Например, провайдер AWS позволяет запрашивать данные о VPC и подсетях, идентификаторы AMI, диапазоны IP-адресов, идентификатор текущего пользователя и многое другое.

Синтаксис использования источников данных очень похож на синтаксис ресурса:

data "_" "" {

   [CONFIG ...]

}

PROVIDER — имя провайдера (например, aws), TYPE — тип источника данных, который вы хотите использовать (скажем, vpc), NAME — идентификатор, с помощью которого можно ссылаться на этот источник данных в коде Terraform, а CONFIG состоит из одного или нескольких аргументов, предусмотренных специально для этого источника. Вот как можно воспользоваться источником данных aws_vpc, чтобы запросить информацию о вашем облаке VPC по умолчанию (справочную информацию ищите во врезке «Замечание о виртуальных частных облаках по умолчанию» на с. 63):

data "aws_vpc" "default" {

  default = true

}

Стоит отметить, что в случае с источниками данных в качестве аргументов обычно передаются фильтры, которые указывают на то, какую информацию вы ищете. Источнику данных aws_vpc нужно указать лишь один фильтр, default=true, который инициирует в вашей учетной записи AWS поиск VPC по умолчанию.

Чтобы получить данные из источника, нужно использовать следующий синтаксис доступа к атрибутам:

data._..

Например, чтобы получить идентификатор VPC из источника данных aws_vpc, надо написать следующее:

data.aws_vpc.default.id

Вы можете добавить к этому еще один источник данных, aws_subnet_ids, чтобы найти подсети внутри этого облака VPC:

data "aws_subnet_ids" "default" {

  vpc_id = data.aws_vpc.default.id

}

Вы можете извлечь идентификаторы подсетей из источника aws_subnet_ids и воспользоваться аргументом с довольно странным названием vpc_zone_identifier, чтобы ваша группа ASG использовала эти подсети:

resource "aws_autoscaling_group" "example" {

  launch_configuration = aws_launch_configuration.example.name

  vpc_zone_identifier  = data.aws_subnet_ids.default.ids

  min_size = 2

  max_size = 10

  tag {

    key                 = "Name"

    value               = "terraform-asg-example"

    propagate_at_launch = true

  }

}

Развертывание балансировщика нагрузки

Вы уже научились развертывать группу ASG, но при этом возникает небольшая проблема: у вас есть несколько серверов с отдельными IP-адресами, однако конечным пользователям обычно нужна единая точка входа. Одно из решений заключается в развертывании балансировщика нагрузки, который будет распределять трафик между вашими серверами и предоставлять всем вашим пользователям собственный IP-адрес (или, если быть точным, доменное имя). Создание балансировщика нагрузки с высокими доступностью и масштабируемостью требует много усилий. И опять вы можете положиться на AWS, воспользовавшись сервисом Elastic Load Balancer (ELB) от Amazon (рис. 2.10).

Рис. 2.10. Использование Amazon ELB для распределения трафика по группе автомасштабирования

AWS предлагает три типа балансировщиков нагрузки.

•Application Load Balancer (ALB). Лучше всего подходит для балансировки трафика по протоколам HTTP и HTTPS. Работает на прикладном уровне (уровень 7) сетевой модели OSI.