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

Здесь мы опять ссылаемся на атрибуты, на этот раз на атрибут public_ip ресурса aws_instance. Если снова выполнить команду apply, Terraform не внесет никаких изменений (поскольку вы не меняли никакие ресурсы), но покажет вам в самом конце новый вывод:

$ terraform apply

(...)

aws_security_group.instance: Refreshing state... [id=sg-078ccb4f9533d2c1a]

aws_instance.example: Refreshing state... [id=i-028cad2d4e6bddec6]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

public_ip = 54.174.13.5

Как видите, после выполнения terraformapply выходная переменная выводится в консоли, что может пригодиться пользователям Terraform (например, вы будете знать, какой IP-адрес нужно проверить после развертывания веб-сервера). Вы также можете ввести команду terraformoutput, чтобы вывести список всех выходных значений без применения каких-либо изменений:

$ terraform output

public_ip = 54.174.13.5

Чтобы посмотреть значение определенной выходной переменной, можно воспользоваться командой terraformoutput<ИМЯ_ПЕРЕМЕННОЙ>:

$ terraform output public_ip

54.174.13.5

Это будет особенно полезно при написании скриптов. Например, вы можете создать скрипт развертывания, который развертывает веб-сервер с помощью команды terraformapply, берет его публичный IP-адрес из terraformoutputpublic_ip и обращается к этому адресу, используя curl. В итоге получится проверка по горячим следам, которая подтвердит, что развертывание работает.

Входные и выходные переменные также являются неотъемлемыми составляющими при создании конфигурируемого инфраструктурного кода, пригодного к повторному применению. Подробнее об этом — в главе 4.

Развертывание кластера веб-серверов

Запуск одного сервера — хорошее начало. Однако в реальном мире это означает наличие единой точки отказа. Если этот сервер выйдет из строя или перестанет справляться с нагрузкой из-за слишком большого объема трафика, пользователи не смогут открыть ваш сайт. В качестве решения можно запустить кластер серверов: если один из них откажет, запросы допускается перенаправить к другому серверу, а размер самого кластера можно увеличивать и уменьшать в зависимости от трафика32.

Ручное управление таким кластером потребует много усилий. К счастью, как показано на рис. 2.9, AWS может позаботиться об этом за вас, используя группу автомасштабирования (англ. auto scaling group, или ASG). ASG автоматически выполняет множество задач, включая запуск кластера серверов EC2, мониторинг работоспособности каждого сервера, замену неисправных серверов и изменение размера кластера в зависимости от нагрузки.

Рис. 2.9. Вместо одного веб-сервера группа автомасштабирования запускает кластер веб-серверов

Первое, что нужно сделать при создании ASG, — это написать конфигурацию запуска, которая определяет, как нужно настроить каждый сервер EC2 в вашей группе. Ресурс aws_launch_configuration использует почти все те же параметры, что и aws_instance (только у двух из них отличаются имена: image_id вместо ami и security_groups вместо vpc_security_group_ids), поэтому вы можете их легко заменить:

resource "aws_launch_configuration" "example" {

  image_id        = "ami-0c55b159cbfafe1f0"

  instance_type   = "t2.micro"

  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

}

Теперь вы можете создать саму группу ASG, используя ресурс aws_autoscaling_group:

resource "aws_autoscaling_group" "example" {

  launch_configuration = aws_launch_configuration.example.name

  min_size = 2

  max_size = 10

  tag {

    key                 = "Name"

    value               = "terraform-asg-example"

    propagate_at_launch = true

  }

}

Эта группа ASG включает в себя от двух до десяти серверов EC2 (сначала запускается только два), каждый из которых имеет тег terraform-asg-example. Обратите внимание, что ASG использует ссылку в качестве имени конфигурации запуска. Это приводит к проблеме: конфигурация запуска неизменяема, поэтому, если вы измените любой ее параметр, Terraform попытается заменить ее целиком. Обычно при замене ресурса Terraform сначала удаляет его старую версию и затем создает новую, но, поскольку ASG теперь ссылается на старый ресурс, Terraform не сможет его удалить.

Чтобы решить эту проблему, можно воспользоваться параметром жизненного цикла. Он поддерживается всеми ресурсами Terraform и определяет их создание, обновление и/или удаление. Особенно полезным параметром жизненного цикла является create_before_destroy. Если присвоить ему true, Terraform поменяет порядок замены ресурсов на противоположный. В итоге сначала будет создана замена (с обновлением всех ссылок таким образом, чтобы они указывали на нее, а не на старый ресурс) и только потом произойдет удаление старого ресурса. Добавьте раздел lifecycle в aws_launch_configuration, как показано ниже:

resource "aws_launch_configuration" "example" {

  image_id        = "ami-0c55b159cbfafe1f0"

  instance_type   = "t2.micro"