Условные обозначения

В этой книге используются следующие типографические обозначения.

Курсив

Обозначает новые термины и важные моменты.

Рубленый

Обозначает URL, адреса электронной почты и элементы интерфейса.

Моноширинный шрифт

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

Жирный моноширинный шрифт

Обозначает команды или другой текст, который должен быть введен пользователем.

Курсивный моноширинный шрифт

Обозначает текст, вместо которого следует подставить пользовательские значения или данные, зависящие от контекста.

Этот значок обозначает примечание общего характера.

Этот значок обозначает предупреждение или предостережение.

Как работает Terraform

Вот обобщенная и немного упрощенная картина того, как работает Terraform. Terraform — это инструмент с открытым исходным кодом от компании HashiCorp, написанный на языке программирования Go. Код на Go компилируется в единый двоичный файл (если быть точным, по одному файлу для каждой поддерживаемой операционной системы) с предсказуемым названием terraform.

Этот файл позволяет развернуть инфраструктуру прямо с вашего ноутбука или сборочного сервера (либо любого другого компьютера), и для всего этого не требуется никакой дополнительной инфраструктуры. Все благодаря тому, что внутри исполняемый файл terraform делает от вашего имени API-вызовы к одному/нескольким провайдерам, таким как AWS, Azure, Google Cloud, DigitalOcean, OpenStack и т. д. Это означает, что Terraform использует инфраструктуру, которую эти провайдеры предоставляют для своих API-серверов, а также их механизмы аутентификации, которые вы уже применяете (например, ваши API-ключи для AWS).

Но откуда Terraform знает, какие API-вызовы нужно делать? Для этого вам необходимо создать текстовые файлы с конфигурацией, в которых описывается, какую инфраструктуру вы хотите создать. В концепции «инфраструктура как код» эти файлы играют роль кода. Вот пример конфигурации Terraform:

resource "aws_instance" "example" {

  ami           = "ami-0c55b159cbfafe1f0"

  instance_type = "t2.micro"

}

resource "google_dns_record_set" "a" {

  name         = "demo.google-example.com"

  managed_zone = "example-zone"

  type         = "A"

  ttl          = 300

  rrdatas      = [aws_instance.example.public_ip]

}

Даже если вы никогда раньше не видели код Terraform, не должно быть особых проблем с тем, чтобы его понять. Этот фрагмент заставляет Terraform выполнить API-вызовы к двум провайдерам: к AWS, чтобы развернуть там сервер, и к Google Cloud, чтобы создать DNS-запись, которая указывает на IP-адрес сервера из AWS. Terraform позволяет использовать единый простой синтаксис (который вы изучите в главе 2) для развертывания взаимосвязанных ресурсов в нескольких разных облаках.

Вы можете описать всю свою инфраструктуру (серверы, базы данных, балансировщики нагрузки, топологию сети и т. д.) в конфигурационных файлах Terraform и сохранить их в системе управления версиями. Затем эту инфраструктуру можно будет развернуть с помощью определенных команд, таких как terraformapply. Утилита terraform проанализирует ваш код, преобразует его в последовательность API-вызовов к облачным провайдерам, которые в нем заданы, и выполнит эти API-вызовы от вашего имени максимально эффективным образом (рис. 1.6).

Рис. 1.6. Terraform — это утилита, которая преобразует содержимое ваших конфигурационных файлов в API-вызовы к облачным провайдерам

Если кто-то в вашей команде хочет изменить инфраструктуру, то вместо того, чтобы делать это вручную прямо на серверах, они редактируют конфигурационные файлы Terraform, проверяют их с помощью автоматических тестов и разбора кода, фиксируют обновленный код в системе управления версиями и затем выполняют коман­ду terraformapply, чтобы сделать необходимые для развертывания изменений API-вызовы.

Номера портов

В этом примере вместо стандартного HTTP-порта 80 используется 8080. Дело в том, что все порты меньше 1024 требуют администраторских привилегий. Это потенциальный риск безопасности, поскольку любой злоумышленник, которому удастся взломать ваш сервер, тоже получит привилегии администратора.

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

Как запустить этот скрипт на сервере EC2? Как уже упоминалось в подразделе «Средства шаблонизации серверов» на с. 31, для этого обычно применяется инструмент вроде Packer, который создает пользовательский образ AMI с предустановленным веб-сервером. Поскольку в этом примере в качестве веб-сервера используется однострочный скрипт на основе busybox, вы можете обойтись стандартным образом Ubuntu 18.04 и запустить скрипт Hello, World в рамках конфигурации пользовательских данных вашего сервера EC2. Вы можете передать параметру user_data в коде Terraform то, что будет выполнено при загрузке сервера: либо скрипт командной оболочки, либо директиву cloud-init. Вариант со скриптом показан ниже:

resource "aws_instance" "example" {

  ami                   = "ami-0c55b159cbfafe1f0"

  instance_type         = "t2.micro"

  user_data = <<-EOF

              #!/bin/bash

              echo "Hello, World" > index.html

              nohup busybox httpd -f -p 8080 &

              EOF

  tags = {

    Name = "terraform-example"

  }

}

<<-EOF и EOF — элементы синтаксиса heredoc, который позволяет создавать многострочные строковые литералы без использования множества символов перехода на новую строку.

Перед запуском этого веб-сервера нужно сделать еще кое-что. AWS по умолчанию закрывает для сервера EC2 весь входящий и исходящий трафик. Чтобы ваш сервер мог принимать запросы на порте 8080, необходимо создать группу безопасности:

resource "aws_security_group" "instance" {

  name = "terraform-example-instance"

  ingress {

    from_port   = 8080

    to_port     = 8080

    protocol    = "tcp"

    cidr_blocks = ["0.0.0.0/0"]

  }

}

Этот код создает новый ресурс под названием aws_security_group (обратите внимание, что все ресурсы в AWS начинаются с aws_) и делает так, чтобы эта группа разрешала принимать на порте 8080 TCP-запросы из блока CIDR 0.0.0.0/0. Блок CIDR — это краткая запись диапазона IP-адресов. Например, блок CIDR 10.0.0.0/24 представляет все IP-адреса между 10.0.0.0 и 10.0.0.255. Блок CIDR 0.0.0.0/0 охватывает диапазон всех возможных IP-адресов, поэтому данная группа безопасности разрешает принимать на порте 8080 запросы с любого IP30.

Создания группы безопасности как таковой будет недостаточно. Нужно сделать так, чтобы сервер EC2 ее использовал. Для этого вы должны передать ее идентификатор аргументу vpc_security_group_ids ресурса aws_instance. Но сначала необходимо познакомиться с выражениями Terraform.

В Terraform выражением является все, что возвращает значение. Вы уже видели простейший тип выражений — литералы, такие как строки (например, "ami-0c55b159cbfafe1f0") и числа (скажем, 5). Terraform поддерживает много других разновидностей выражений, которые будут встречаться на страницах этой книги.

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

<PROVIDER>_<TYPE>.<NAME>.<ATTRIBUTE>

PROVIDER — это имя провайдера (например, aws), TYPE — это тип ресурса (вроде security_group), NAME — имя этого ресурса (в нашем случае группа безопасности называется "instance"), а ATTRIBUTE — это либо один из аргументов ресурса (скажем, name), либо один из атрибутов, которые он экспортировал (список доступных атрибутов можно найти в документации каждого ресурса). Группа безопасности экспортирует атрибут под названием id, поэтому к нему можно обратиться с помощью такого выражения:

aws_security_group.instance.id

Вы можете использовать идентификатор этой группы безопасности в аргументе vpc_security_group_ids ресурса aws_instance:

resource "aws_instance" "example" {

  ami                    = "ami-0c55b159cbfafe1f0"

  instance_type          = "t2.micro"

  vpc_security_group_ids = [aws_security_group.instance.id]

  user_data = <<-EOF

              #!/bin/bash

              echo "Hello, World" > index.html

              nohup busybox httpd -f -p 8080 &

              EOF

  tags = {

    Name = "terraform-example"

  }

}

Ссылаясь в одном ресурсе на другой, вы создаете неявную зависимость. Terraform анализирует такие зависимости, строит из них граф и применяет его для автоматического определения порядка, в котором должны создаваться ресурсы. ­Например, если бы этот код развертывался с нуля, система Terraform знала бы о том, что группу безопасности нужно создать раньше, чем сервер EC2, поскольку последний использует ID этой группы. Вы можете даже вывести граф зависимостей с помощью команды graph:

$ terraform graph

digraph {

        compound = "true"

        newrank = "true"

        subgraph "root" {

                "[root] aws_instance.example"

                  [label = "aws_instance.example", shape = "box"]

                "[root] aws_security_group.instance"

                  [label = "aws_security_group.instance", shape = "box"]

                "[root] provider.aws"

                  [label = "provider.aws", shape = "diamond"]

                "[root] aws_instance.example" ->

                  "[root] aws_security_group.instance"

                "[root] aws_security_group.instance" ->

                  "[root] provider.aws"

                "[root] meta.count-boundary (EachMode fixup)" ->

                  "[root] aws_instance.example"

                "[root] provider.aws (close)" ->

                  "[root] aws_instance.example"

                "[root] root" ->

                  "[root] meta.count-boundary (EachMode fixup)"

                "[root] root" ->

                  "[root] provider.aws (close)"

        }

}

Вывод выполнен на языке описания графов под названием DOT. Сам граф можно отобразить, как это сделано на рис. 2.7, с использованием настольного приложенияGraphviz или его веб-версии GraphvizOnline (bit.ly/2mPbxmg).

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

Рис. 2.7. Граф зависимостей для сервера EC2 и его группы безопасности

Выполнив команду apply, вы увидите, что Terraform хочет создать группу безопасности и заменить имеющийся сервер EC2 другим — с новыми пользовательскими данными:

$ terraform apply

(...)

Terraform will perform the following actions:

  # aws_instance.example must be replaced

-/+ resource "aws_instance" "example" {

        ami                          = "ami-0c55b159cbfafe1f0"

      ~ availability_zone            = "us-east-2c" -> (known after apply)

      ~ instance_state               = "running" -> (known after apply)

        instance_type                = "t2.micro"

        (...)

      + user_data                    = "c765373..." # forces replacement

      ~ volume_tags                  = {} -> (known after apply)

      ~ vpc_security_group_ids       = [

          - "sg-871fa9ec",

        ] -> (known after apply)

        (...)

  }

# aws_security_group.instance will be created

+ resource "aws_security_group" "instance" {

    + arn                    = (known after apply)

    + description            = "Managed by Terraform"

    + egress                 = (known after apply)

    + id                     = (known after apply)

    + ingress                = [

        + {

            + cidr_blocks      = [

                + "0.0.0.0/0",

              ]

            + description      = ""

            + from_port        = 8080

            + ipv6_cidr_blocks = []

            + prefix_list_ids  = []

            + protocol         = "tcp"

            + security_groups  = []

            + self             = false

            + to_port          = 8080

          },

        ]

      + name                   = "terraform-example-instance"

      + owner_id               = (known after apply)

      + revoke_rules_on_delete = false

      + vpc_id                 = (known after apply)

    }

Plan: 2 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?

  Terraform will perform the actions described above.

  Only 'yes' will be accepted to approve.

Enter a value:

Символы -/+ в выводе плана означают «заменить». Чтобы понять, чем продиктовано то или иное изменение, поищите в выводе плана словосочетание forces replacement. Изменение многих аргументов ресурса aws_instance приводит к замене. Это означает, что имеющийся сервер EC2 будет удален, а его место займет совершено новый сервер. Это пример парадигмы неизменяемой инфраструктуры, которую мы обсуждали в подразделе «Средства шаблонизации серверов» на с. 31. Стоит отметить, что, несмотря на замену веб-сервера, ни один из его пользователей не заметит перебоев в работе; в главе 5 вы увидите, как с помощью Terraform выполнять развертывания с нулевым временем простоя.

Похоже, с планом все в порядке, поэтому введите yes, и вы увидите, как развертывается новый сервер EC2 (рис. 2.8).

Если щелкнуть на новом сервере, внизу страницы, на панели с описанием, можно увидеть его публичный IP-адрес. Дайте ему минуту или две, чтобы он загрузился, и затем сделайте HTTP-запрос по этому адресу на порте 8080, используя браузер или утилиту вроде curl:

$ curl http://<EC2_INSTANCE_PUBLIC_IP>:8080

Hello, World

Ура! Теперь у вас есть рабочий веб-сервер, запущенный в AWS!

Рис. 2.8. Вместо старого сервера EC2 мы получаем новый, с кодом веб-сервера

Как избежать дублирования кода

Структура файлов и каталогов, описанная в этом разделе, имеет много повторя­ющихся элементов. Например, одни и те же приложения frontend-app и backend-app находятся сразу в двух папках: stage и prod. Но не волнуйтесь, вам не придется копировать и вставлять весь этот код! В главе 4 вы увидите, как избегать дублирования и соблюдать принцип DRY с помощью модулей Terraform.

Возьмем код кластера с веб-сервером, который вы написали в главе 2, объединим его с кодом для Amazon S3 и DynamoDB из этой главы и организуем это все в виде структуры каталогов, представленной на рис. 3.8.

Рис. 3.8. Структура файлов для кода кластера с веб-сервером

Бакет S3, созданный вами в этой главе, необходимо переместить в папку glo­bal/s3. Поместите выходные переменные (s3_bucket_arn и dynamodb_table_name) в файл outputs.tf. При перемещении файлов в новое место убедитесь, что вы не забыли скопировать (скрытую) папку .terraform, иначе придется заново все инициализировать.

Кластер веб-серверов, который вы создали в главе 2, следует поместить в папку stage/services/webserver-cluster (своего рода тестовая версия этого кластера; промышленную мы добавим в следующей главе). Не забудьте скопировать папку .terraform и поместить входные и выходные переменные в файлы variables.tf и соответственно outputs.tf.

Вам также необходимо обновить кластер веб-серверов, чтобы он использовал S3 в качестве хранилища. Вы можете просто скопировать и вставить раздел backend из файла global/s3/main.tf без особых изменений, но не забудьте присвоить параметру key путь к папке, в которой находится код веб-сервера: stage/services/webserver-cluster/terraform.tfstate. Таким образом, код Terraform в системе управления версиями и структура ваших файлов состояния будут полностью совпадать и вам будет очевидно то, как они между собой связаны. Модуль s3 использует этот же принцип для установки параметра key.

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

Конечно, это свойство в каком-то смысле является и недостатком: разделение компонентов на отдельные папки не дает случайной оплошности нарушить работу всей инфраструктуры, но при этом лишает вас возможности развертывать всю инфраструктуру одной командой. Если бы все компоненты для одного окружения были описаны в одном конфигурационном файле Terraform, вы бы могли запустить все это окружение с помощью единого вызова terraformapply. Но если все компоненты находятся в отдельных папках, нужно выполнить terraformapply в каждой из них. Стоит отметить, что в случае применения Terragrunt вы можете автоматизировать этот процесс с помощью команды apply-all39.

У этой структуры файлов есть еще одна проблема: она усложняет использование зависимостей ресурсов. Приложение имеет прямой доступ к атрибутам базы данных (то есть может сослаться на адрес базы данных через aws_db_instan­ce.foo.address), если код этих двух компонентов находится в одних и тех же конфигурационных файлах Terraform. Но если код приложения и базы данных размещен в разных папках, как я советовал, эта возможность теряется. К счастью, Terraform предлагает решение этой проблемы: источник данных terraform_remote_state.

Сетевая изоляция

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

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

В связи с этим, если не считать простые примеры и эксперименты, вы должны размещать каждую среду в отдельном облаке VPC. Для пущей уверенности окружения можно даже разнести по разным учетным записям AWS.

Выражения if с использованием параметра count

В главе 4 вы написали модуль Terraform, который можно применить в качестве «чертежа» для развертывания кластеров с веб-серверами. Этот модуль создавал группу автомасштабирования (ASG), балансировщик нагрузки (ALB), группы безопасности и ряд других ресурсов. Чего он не создавал, так это запланированного действия. Поскольку кластер нужно масштабировать только в промышленных условиях, вы определили ресурсы aws_autoscaling_schedule непосредственно в промышленной конфигурации в файле live/prod/services/webserver-cluster/main.tf. Можно ли их определить в модуле webserver-cluster и затем создавать только для определенных пользователей?

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

variable "enable_autoscaling" {

  description = "If set to true, enable auto scaling"

  type        = bool

}

Теперь, если бы вы использовали язык программирования общего назначения, вы бы могли применить эту входную переменную в выражении if:

# Это просто псевдокод. Он не будет работать в Terraform.

if var.enable_autoscaling {

  resource "aws_autoscaling_schedule" "scale_out_during_business_hours" {

    scheduled_action_name  = "${var.cluster_name}-scale-out-during-business-hours"

    min_size               = 2

    max_size               = 10

    desired_capacity       = 10

    recurrence             = "0 9 * * *"

    autoscaling_group_name = aws_autoscaling_group.example.name

  }

  resource "aws_autoscaling_schedule" "scale_in_at_night" {

    scheduled_action_name  = "${var.cluster_name}-scale-in-at-night"

    min_size               = 2

    max_size               = 10

    desired_capacity       = 2

    recurrence             = "0 17 * * *"

    autoscaling_group_name = aws_autoscaling_group.example.name

  }

}

Terraform не поддерживает выражения if, поэтому данный код работать не будет. Но того же результата можно добиться с помощью параметра count и двух особенностей языка.

• Если внутри ресурса параметру count присвоить значение 1, вы получите копию этого ресурса; если указать 0, этот ресурс вообще не будет создан.

• Terraform поддерживает условные выражения в формате <CONDITION>?<TRUE_VAL>:<FALSE_VAL>. Это тернарный синтаксис, с которым вы можете быть знакомы по другим языкам программирования. Он проверит булеву логику в CONDITION и, если результат равен true, вернет TRUE_VAL; в противном случае возвращается FALSE_VAL.

Объединив эти две идеи, мы можем обновить модуль webserver-cluster следу­ющим образом:

resource "aws_autoscaling_schedule" "scale_out_during_business_hours" {

  count = var.enable_autoscaling ? 1 : 0

  scheduled_action_name  = "${var.cluster_name}-scale-out-during-business-hours"

  min_size               = 2

  max_size               = 10

  desired_capacity       = 10

  recurrence             = "0 9 * * *"

  autoscaling_group_name = aws_autoscaling_group.example.name

}

resource "aws_autoscaling_schedule" "scale_in_at_night" {

  count = var.enable_autoscaling ? 1 : 0

  scheduled_action_name  = "${var.cluster_name}-scale-in-at-night"

  min_size               = 2

  max_size               = 10

  desired_capacity       = 2

  recurrence             = "0 17 * * *"

  autoscaling_group_name = aws_autoscaling_group.example.name

}

Если var.enable_autoscaling равно true, параметру count для каждого из ресурсов aws_autoscaling_schedule будет присвоено значение 1, поэтому оба они будут созданы в единственном экземпляре. Если var.enable_autoscaling равно false, параметру count для каждого из ресурсов aws_autoscaling_schedule будет присвоено значение 0, поэтому ни один из них создан не будет. Это именно та условная логика, которая нам нужна!

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

module "webserver_cluster" {

  source = "../../../../modules/services/webserver-cluster"

  cluster_name           = "webservers-stage"

  db_remote_state_bucket = "(YOUR_BUCKET_NAME)"

  db_remote_state_key    = "stage/data-stores/mysql/terraform.tfstate"

  instance_type        = "t2.micro"

  min_size             = 2

  max_size             = 2

  enable_autoscaling   = false

}

Аналогичным образом обновим использование этого модуля в промышленной среде (в файле live/prod/services/webserver-cluster/main.tf). Включим масштабирование, присвоив enable_autoscaling значение true (не забудьте также убрать пользовательские ресурсы aws_autoscaling_schedule, которые остались в промышленной среде после выполнения примеров главы 4):

module "webserver_cluster" {

  source = "../../../../modules/services/webserver-cluster"

  cluster_name           = "webservers-prod"

  db_remote_state_bucket = "(YOUR_BUCKET_NAME)"

  db_remote_state_key    = "prod/data-stores/mysql/terraform.tfstate"

  instance_type        = "m4.large"

  min_size             = 2

  max_size             = 10

  enable_autoscaling   = true

  custom_tags = {

    Owner      = "team-foo"

    DeployedBy = "terraform"

  }

}

Этот подход хорошо работает в случае, если пользователь передает вашему модулю явное булево значение. Но если вместо этого передается результат более сложного сравнения, такого как проверка равенства строк? Рассмотрим более замысловатый пример.

Представьте, что вы хотите создать в рамках модуля webserver-cluster набор оповещений CloudWatch. Оповещение CloudWatch может доставляться с помощью разных механизмов (скажем, в виде электронного письма или текстового сообщения), если достигается заранее заданный порог. Например, ниже мы используем ресурс aws_cloudwatch_metric_alarm в файле modules/services/webserver-cluster/main.tf, чтобы создать оповещение, которое срабатывает, если загруженность процессора превышает 90 % на протяжении пяти минут:

resource "aws_cloudwatch_metric_alarm" "high_cpu_utilization" {

  alarm_name  = "${var.cluster_name}-high-cpu-utilization"

  namespace   = "AWS/EC2"

  metric_name = "CPUUtilization"

  dimensions = {

    AutoScalingGroupName = aws_autoscaling_group.example.name

  }

  comparison_operator = "GreaterThanThreshold"

  evaluation_periods  = 1

  period              = 300

  statistic           = "Average"

  threshold           = 90

  unit                = "Percent"

}

Это хорошо работает для показателя CPUUtilization. Но если нужно добавить еще одно оповещение, которое срабатывает, когда заканчиваются кредиты для процессора?46 Ниже это демонстрируется на примере нашего кластера веб-серверов:

resource "aws_cloudwatch_metric_alarm" "low_cpu_credit_balance" {

  alarm_name  = "${var.cluster_name}-low-cpu-credit-balance"

  namespace   = "AWS/EC2"

  metric_name = "CPUCreditBalance"

  dimensions = {

    AutoScalingGroupName = aws_autoscaling_group.example.name

  }

  comparison_operator = "LessThanThreshold"

  evaluation_periods  = 1

  period              = 300

  statistic           = "Minimum"

  threshold           = 10

  unit                = "Count"

}

Но есть одна загвоздка: кредиты для процессора распространяются только на серверы типа tXXX (как t2.micro, t2.medium и т. д.). Более крупные типы серверов (вроде m4.large) эти кредиты не поддерживают и не отчитываются о показателе CPUCreditBalance. Поэтому, если вы создадите подобное оповещение для таких серверов, оно никогда не выйдет из состояния INSUFFICIENT_DATA. Возможно ли создавать оповещения только в случае, если var.instance_type начинается с буквы t?

Вы могли бы создать новую булеву входную переменную с именем var.is_t2_instance, но тогда бы она дублировала var.instance_type, а вы, скорее всего, забудете обновлять их вместе. Лучшая альтернатива — использование условного выражения:

resource "aws_cloudwatch_metric_alarm" "low_cpu_credit_balance" {

  count = format("%.1s", var.instance_type) == "t" ? 1 : 0

  alarm_name  = "${var.cluster_name}-low-cpu-credit-balance"

  namespace   = "AWS/EC2"

  metric_name = "CPUCreditBalance"

  dimensions = {

    AutoScalingGroupName = aws_autoscaling_group.example.name

  }

  comparison_operator = "LessThanThreshold"

  evaluation_periods  = 1

  period              = 300

  statistic           = "Minimum"

  threshold           = 10

  unit                = "Count"

}

Код оповещения остается прежним, если не считать относительно сложного параметра count:

count = format("%.1s", var.instance_type) == "t" ? 1 : 0

Здесь используется функция format, которая извлекает первый символ из var.in­stance_type. Если это символ t (как в случае с t2.micro), параметру count присваивается значение 1; в противном случае параметр count будет равен 0. Таким образом, оповещение создается только для серверов, у которых действительно есть показатель CPUCreditBalance.

Тестируемые модули

Вы уже написали довольно много кода в виде трех модулей: asg-rolling-deploy, alb и hello-world-app. Теперь нужно убедиться, что этот код и правда работает.

Указанные модули не корневые и не предназначены для развертывания напрямую. Чтобы их развернуть, нужно написать какой-то код Terraform, подключить нужные вам аргументы, сконфигурировать поля provider и backend и т. д. Для этого можно создать папку examples, которая будет содержать примеры использования ваших модулей. Попробуем это сделать.

Создайте файл examples/asg/main.tf следующего содержания:

provider "aws" {

  region = "us-east-2"

}

module "asg" {

  source = "../../modules/cluster/asg-rolling-deploy"

  cluster_name  = var.cluster_name

  ami           = "ami-0c55b159cbfafe1f0"

  instance_type = "t2.micro"

  min_size           = 1

  max_size           = 1

  enable_autoscaling = false

  subnet_ids = data.aws_subnet_ids.default.ids

}

data "aws_vpc" "default" {

  default = true

}

data "aws_subnet_ids" "default" {

  vpc_id = data.aws_vpc.default.id

}

Этот фрагмент кода развертывает группу ASG с одним сервером, применяя модуль asg-rolling-deploy. Попробуйте выполнить команды terraforminit и terraformapply и убедитесь, что все работает без ошибок и ASG действительно создается. Теперь добавьте файл README.md с данными инструкциями, после чего этот крошечный пример станет куда более мощным. С помощью всего нескольких файлов и строк кода вы получаете следующее.

•Механизм ручных тестов. Этот демонстрационный код можно использовать при работе над модулем asg-rolling-deploy, развертывая и удаляя его по много раз путем ручного выполнения команд terraformapply и terraformdestroy. Это позволит убедиться в его предсказуемом поведении.

• Механизм автоматических тестов. Как вы увидите в главе 7, с помощью этого демонстрационного кода можно также создавать автоматические тесты для ваших модулей. Советую размещать тесты в папке test.

• Исполняемая документация. Если сохранить этот пример (вместе с файлом README.md) в системе управления версиями, каждый член вашей команды сможет его найти и понять с его помощью, как работает ваш модуль. Это также позволит запускать модуль без написания какого-либо кода. Таким образом, вы предоставляете своей команде обучающий материал и вместе с тем можете подтвердить его корректность автоматическими тестами.

У каждого модуля Terraform, который находится в папке modules, должна быть папка examples с соответствующим примером. А у последнего в этой папке должен быть подходящий тест в папке test. У каждого модуля, скорее всего, будет ряд примеров (и, следовательно, несколько тестов), которые иллюстрируют разные конфигурации и сценарии использования. Скажем, для модуля asg-rolling-deploy можно придумать другие примеры, чтобы показать, как он работает с правилами автомасштабирования, как к нему подключать балансировщики нагрузки, как ему назначить пользовательские теги и т. д.

Если все это объединить, структура каталогов типичного репозитория modules будет выглядеть так:

modules

└ examples

   └ alb

   └ asg-rolling-deploy

     └ one-instance

     └ auto-scaling

     └ with-load-balancer

     └ custom-tags

   └ hello-world-app

   └ mysql

└ modules

   └ alb

   └ asg-rolling-deploy

   └ hello-world-app

   └ mysql

└ test

   └ alb

   └ asg-rolling-deploy

   └ hello-world-app

   └ mysql

В качестве упражнения предлагаю вам превратить код RDS, который вы написали, в модуль MySQL и добавить к модулям alb, asg-rollingdeploy, mysql и hello-world-app множество разных примеров.

Разработку нового модуля крайне полезно начинать с написания демонстрационного кода. Если сразу заняться реализацией, можно легко погрязнуть в деталях, и к моменту, когда вы вернетесь к API, ваш модуль будет малопонятным и сложным в применении. Если же вы начнете с кода примера, у вас будет возможность подумать об опыте использования, выработать для своего модуля аккуратный API и затем вернуться к реализации. Поскольку код примера и так служит основным способом тестирования модуля, такой подход является разновидностью разработки через тестирование (Test-Driven Development, TDD); подробнее о тестировании мы поговорим в главе 7.

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

terraform {

  # Требуем любую версию Terraform вида 0.12.x

  required_version = ">= 0.12, < 0.13"

}

Этот код позволит использовать для вашего модуля только версии Terraform ви­да 0.12.x, но не 0.11.x или 0.13.x. Это очень важно, потому что при каждом мажорном выпуске Terraform теряет обратную совместимость: например, переход с 0.11.x на 0.12.x требует существенного изменения кода, поэтому вам вряд ли понравится, если такой переход произойдет случайно. Если добавить параметр required_version и попытаться выполнить terraformapply, используя другую версию, сразу же появится ошибка:

$ terraform apply

Error: Unsupported Terraform Core version

This configuration does not support Terraform version 0.11.11. To proceed, either choose another supported Terraform version or update the root module's version constraint. Version constraints are normally set for good reason, so updating the constraint may lead to other errors or unexpected behavior.

Для кода промышленного уровня рекомендую еще строже закреплять версию:

terraform {

  # Требуем исключительно версию Terraform 0.12.0

  required_version = "= 0.12.0"

}

Это вызвано тем, что даже переход на новые «заплаточные» версии (скажем, 0.12.0 —> 0.12.1) может создать проблемы. Иногда они содержат ошибки, а иногда у них ломается обратная совместимость (хотя в наши дни это случается реже). Но еще более серьезной проблемой является то, что файл состояния, измененный более новой версией Terraform, уже нельзя использовать в старых версиях. Представьте, к примеру, что весь ваш код развернут с помощью Terraform 0.12.0, и тут вдруг разработчик, у которого установлена версия 0.12.1, применяет к некоторым из ваших модулей команду terraformapply. В результате файлы состояния этих модулей больше не совместимы с 0.12.0, поэтому вы вынуждены обновить все свои компьютеры для разработки и CI-серверы на 0.12.1!

Ситуация, скорее всего, улучшится, когда Terraform достигнет версии 1.0.0 и на­чнет соблюдать обратную совместимость, но, пока этого не произошло, я советую привязываться к определенной версии этой системы. Это позволит избежать незапланированных обновлений. Вы сможете обновляться тогда, когда будете готовы, и делать это сразу для всех своих компьютеров и CI-серверов.

Рекомендую также закреплять версии всех ваших провайдеров:

provider "aws" {

  region = "us-east-2"

  # Разрешаем использовать любую версию провайдера AWS вида 2.x

  version = "~> 2.0"

}

Этот пример привязывает код провайдера AWS к версиям вида 2.x (синтаксис ~>2.0 эквивалентен >=2.0,<3.0). И снова, чтобы избежать случайного внесения обратно несовместимых изменений, необходимо закрепить мажорную версию. Закрепление конкретной версии зависит от провайдера. Предположим, провайдер AWS часто обновляется и имеет хорошую поддержку обратной совместимости, поэтому будет разумно закрепить только его мажорную версию и позволить автоматическое обновление заплаток, чтобы получить удобный доступ к новым возможностям. Однако все провайдеры разные, поэтому обращайте внимание на то, насколько хорошо они справляются с поддержкой обратной совместимости, и закрепляйте номера версий соответствующим образом.

Основы модульных тестов

Какой эквивалент такого рода модульных тестов для кода Terraform? Для начала нужно определиться с тем, что в мире Terraform считается модулем. Ближайший аналог отдельной функции или класса — обобщенный модуль (определение термина дано в подразделе «Компонуемые модули» на с. 226), такой как alb из главы 6. Как бы вы его протестировали?

В Ruby для написания модульных тестов необходимо провести такой рефакторинг, чтобы код можно было выполнять без сложных зависимостей вроде HTTPServer, HTTPRequest или HTTPResponse. Если подумать о том, чем занимается код Terraform (обращение к API AWS для создания балансировщиков нагрузки, прослушивателей, целевых групп и т. д.), то в 99 % случаев он взаимодействует со сложными зависимостями! Не существует практичного способа свести число внешних зависимостей к нулю, но, даже если бы вы могли это сделать, у вас бы практически не осталось кода для тестирования56.

Это подводит нас к ключевому выводу о тестировании № 3: вы не можете проводить чистое тестирование кода Terraform.

Но не отчаивайтесь. Вы все еще можете укрепить свою уверенность в том, что ваш код Terraform ведет себя предсказуемо. Для этого автоматические тесты должны использовать ваш код для развертывания реальной инфраструктуры в реальном окружении (например, в настоящей учетной записи AWS). Иными словами, модульные тесты для Terraform на самом деле являются интеграционными. Но я все равно предпочитаю называть их модульными, чтобы подчеркнуть нашу цель: протестировать отдельный (обобщенный) модуль и как можно быстрее получить результат.

Это означает, что базовая стратегия написания модульных тестов для Terraform подразумевает следующее.

1. Создание обобщенного автономного модуля.

2. Создание простого в развертывании примера для этого модуля.

3. Выполнение terraformapply для развертывания примера в реальной среде.

4. Проверка того, что развернутый вами код работает так, как вы ожидали. Этот этап зависит от типа инфраструктуры, которую вы тестируете: например, чтобы проверить балансировщик ALB, ему нужно послать HTTP-запрос и убедиться в том, что он возвращает тот ответ, который вы ожидаете.

5. Выполнение terraformdestroy в конце для очистки ресурсов.

Иными словами, вы выполняете все те же шаги, что и при ручном тестировании, но оформляете их в виде кода. Такой образ мышления хорошо подходит для создания автоматических тестов для кода Terraform: спросите себя, как бы вы проверили данный модуль, чтобы убедиться в его работе, и затем запрограммируйте этот тест.

Для написания тестов подходит любой язык программирования. В этой книге все тесты написаны на языке Go. Это позволяет использовать открытую библиотеку тестирования Terratest (http://bit.ly/2Tbzvch), которая поддерживает широкий спектр инструментов IaC (скажем, Terraform, Packer, Docker, Helm) в разнообразных окружениях (таких как AWS, Google Cloud, Kubernetes). Библиотека Terratest напоминает швейцарский армейский нож: в ней сотни инструментов, которые существенно упрощают тестирование инфраструктурного кода, включая полноценную поддержку только что описанной стратегии, когда вы развертываете код с помощью terraformapply, убеждаетесь, что он работает, и затем выполняете в конце terraformdestroy, чтобы очистить ресурсы.

Чтобы использовать Terratest, вам нужно сделать следующее.

1. Установить Go: golang.org/doc/install.

2. Настроить переменную среды GOPATH: golang.org/doc/code.html#GOPATH.

3. Добавить $GOPATH/bin в переменную среды PATH.

4. Установить Dep, диспетчер зависимостей для Go: golang.github.io/dep/docs/installation.html57.

5. Создать внутри GOPATH папку для тестов. Учитывая, что переменная GOPATH по умолчанию равна $HOME/go, вы могли бы создать $HOME/go/src/terraform-up-and-running.

6. Выполнить команду depinit в только что созданной вами папке. В результате у вас должны появиться файлы Gopkg.toml и Gopkg.lock, а также пустая папка vendors.

Чтобы быстро проверить, верно ли сконфигурировано ваше окружение, создайте в своей новой папке файл go_sanity_test.go следующего содержания:

package test

import (

        "fmt"

        "testing"

)

func TestGoIsWorking(t *testing.T)  {

        fmt.Println()

        fmt.Println("If you see this text, it's working!")

        fmt.Println()

}

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

$ go test -v

If you see this text, it's working!

PASS

ok   terraform-up-and-running   0.004s

Флаг -v означает verbose («подробно»). Он делает так, чтобы тест показывал весь журнальный вывод.

Если все работает, можете удалить go_sanity_test.go и приступить к написанию модульного теста для модуля alb. Создайте в папке test файл alb_example_test.go со следующим каркасом своего теста:

package test

import (

        "testing"

)

func TestAlbExample(t *testing.T) {

}

Для начала вы должны указать Terratest, где находится ваш код Terraform. Используйте для этого тип terraform.Options:

package test

import (

        "github.com/gruntwork-io/terratest/modules/terraform"

        "testing"

)

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

}

Следует отметить, что для проверки модуля alb вам действительно нужно протестировать код примера в папке examples (обновите относительный путь в TerraformDir, чтобы он вел к нужной папке). Это означает, что демонстрационный код теперь имеет тройное назначение: он служит исполняемой документацией, средством ручного тестирования и инструментом для выполнения автоматических тестов ваших модулей.

Обратите также внимание на новую инструкцию импорта для библиотеки Terratest вверху файла. Чтобы загрузить эту зависимость на ваш компьютер, выполните depensure:

$ dep ensure

Команда depensure просканирует ваш код на Go, найдет все новые инструкции импорта, автоматически загрузит их вместе со всеми зависимостями в папку vendor и пропишет их в файл Gopkg.lock. Если для вас в этом слишком много магии, можете использовать команду depensure-add, чтобы перечислить все нужные вам зависимости вручную:

$ dep ensure -add github.com/gruntwork-io/terratest/modules/terraform

Следующий этап автоматического тестирования — выполнение команд terraforminit и terraformapply, которые развернут ваш код. У Terratest для этого есть вспомогательные средства:

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        terraform.Init(t, opts)

        terraform.Apply(t, opts)

}

Выполнение команд init и apply в Terratest — настолько рутинная операция, что для этого предусмотрен удобный вспомогательный метод, который делает все одной командой:

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        // Развертываем пример

        terraform.InitAndApply(t, opts)

}

Код выше уже представляет собой довольно функциональный модульный тест: он выполняет terraforminit и terraformapply и проваливает тест, если эти команды­ не завершаются успешно (например, из-за проблем в вашем коде Terraform). Но вы можете пойти еще дальше и выполнить HTTP-запросы к развернутому балансировщику нагрузки, чтобы убедиться, что он возвращает нужные вам данные. Для этого вам надо как-то получить доменное имя развернутого балансировщика. К счастью, пример alb возвращает его в виде выходной переменной:

output "alb_dns_name" {

  value       = module.alb.alb_dns_name

  description = "The domain name of the load balancer"

}

У Terratest есть встроенные вспомогательные средства для чтения вывода из кода Terraform:

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        // Развертываем пример

        terraform.InitAndApply(t, opts)

        // Получаем URL-адрес ALB

        albDnsName := terraform.OutputRequired(t, opts, "alb_dns_name")

        url := fmt.Sprintf("http://%s", albDnsName)

}

Функция OutputRequired возвращает вывод с заданным именем или проваливает тест, если этот вывод пустой или не существует. Предыдущий листинг формирует на основе этого вывода URL-адрес, используя встроенную в Go функцию ­fmt.Sprintf (не забудьте импортировать пакет fmt). Следующим шагом будет выполнение HTTP-запросов по этому URL-адресу:

package test

import (

        "fmt"

        "crypto/tls"

        "github.com/gruntwork-io/terratest/modules/http-helper"

        "github.com/gruntwork-io/terratest/modules/terraform"

        "testing"

)

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        // Развертываем пример

        terraform.InitAndApply(t, opts)

        // Получаем URL-адрес ALB

        albDnsName := terraform.OutputRequired(t, opts, "alb_dns_name")

        url := fmt.Sprintf("http://%s", albDnsName)

        // Проверяем в ALB действие по умолчанию, которое должно вернуть 404

        expectedStatus := 404

        expectedBody := "404: page not found"

http_helper.HttpGetWithValidation(t, url, expectedStatus, expectedBody)

}

Этот код импортирует из Terratest новый пакет, http_helper. Чтобы его загрузить, нужно еще раз выполнить rundep. Метод http_helper.HttpGetWithValidation сделает HTTP-запрос типа GET по переданному вами URL-адресу и провалит тест, если код состояния и тело ответа не совпадают с теми, которые вы указали.

У этого кода есть одна проблема: между завершением команды terraformapply и тем, когда доменное имя балансировщика нагрузки становится доступным (то есть распространилось по системе), проходит время. Если вызвать http_helper.HttpGetWithValidation незамедлительно, он, вполне вероятно, окажется неудачным, хотя через 30 секунд или минуту ALB заработает в нормальном режиме. Как уже обсуждалось в подразделе «Отложенная согласованность согласуется… с отлагательством» на с. 211, такого рода асинхронное поведение с отложенной согласованностью является для AWS (а точнее, для большинства распределенных систем) нормальным и решением будет повторное выполнение вызовов. У Terratest есть вспомогательный метод и для этого:

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        // Развертываем пример

        terraform.InitAndApply(t, opts)

        // Получаем URL-адрес ALB

        albDnsName := terraform.OutputRequired(t, opts, "alb_dns_name")

        url := fmt.Sprintf("http://%s", albDnsName)

        // Проверяем в ALB действие по умолчанию, которое должно вернуть 404

        expectedStatus := 404

        expectedBody := "404: page not found"

        maxRetries := 10

        timeBetweenRetries := 10 * time.Second

http_helper.HttpGetWithRetry(

                t,

                url,

                &tls.Config{},

                expectedStatus,

                expectedBody,

                maxRetries,

                timeBetweenRetries,

        )

}

Метод http_helper.HttpGetWithRetry почти не отличается от метода http_helper.HttpGetWithValidation, только при отсутствии ответа с нужными кодом состояния или телом он повторит попытку. Максимальное количество повторений (десять) и длину интервалов между ними (десять секунд) можно настроить. Если в какой-то момент он получит ожидаемый ответ, тест будет пройден; если после истечения максимального количества попыток ожидаемый ответ так и не пришел, тест считается проваленным.

В конце теста нужно выполнить команду terraformdestroy, чтобы очистить ресурсы. Для этого у Terratest есть вспомогательный метод: terraform.Destroy. Но, если вызывать его в самом конце, из-за любой программной ошибки выше по коду (например, HttpGetWithRetry даст сбой из-за неправильной конфигурации ALB) тест может завершиться, не доходя до него, в результате чего развернутая инфраструктура не будет удалена.

Таким образом, вам нужно убедиться в том, что terraform.Destroy выполняется всегда, даже если тест проваливается. Во многих языках программирования для этого предусмотрены конструкции try/finally или try/ensure. Но в Go это делается с помощью выражения defer, которое гарантирует, что переданный в него код будет выполнен при завершении окружающей его функции (каким бы оно ни было):

func TestAlbExample(t *testing.T) {

        opts := &terraform.Options{

                // Сделайте так, чтобы этот относительный путь

                // вел к папке с примерами для alb!

                TerraformDir: "../examples/alb",

        }

        // Удаляем все в конце теста

        defer terraform.Destroy(t, opts)

        // Развертываем пример

        terraform.InitAndApply(t, opts)

        // Получаем URL-адрес ALB

        albDnsName := terraform.OutputRequired(t, opts, "alb_dns_name")

        url := fmt.Sprintf("http://%s", albDnsName)

        // Проверяем в ALB действие по умолчанию, которое должно вернуть 404

        expectedStatus := 404

        expectedBody := "404: page not found"

        maxRetries := 10

        timeBetweenRetries := 10 * time.Second

http_helper.HttpGetWithRetry(

                t,

                url,

                &tls.Config{},

                expectedStatus,

                expectedBody,

                maxRetries,

                timeBetweenRetries,

        )

}

Обратите внимание, что defer размещается в начальной части кода, еще до вызова terraform.InitAndApply. Это нужно для того, чтобы тест не был провален еще до выражения defer, иначе вызов terraform.Destroy может не попасть в очередь на выполнение.

Этот модульный тест готов к запуску. Поскольку он развертывает инфраструктуру в AWS, перед его выполнением следует привычным способом аутентифицировать свою учетную запись (см. врезку «Способы аутентификации» на с. 64). Как упоминалось в этой главе, ручное тестирование следует проводить в изолированной учетной записи. Это вдвойне справедливо для автоматических тестов, поэтому советую сделать аутентификацию от имени совершенно отдельного пользователя. По мере создания все новых автоматических тестов у вас могут создаваться сотни и тысячи ресурсов, поэтому крайне важно изолировать их от всего остального.

Я обычно рекомендую командам разработчиков выделить совершенно отдельную среду (например, в отдельной учетной записи AWS) специально для автоматических тестов — отдельно даже от изолированных окружений, которые используются для ручного тестирования. Так, можно безопасно удалять в этой среде все ресурсы старше нескольких часов (предполагается, что ни один тест не выполняется настолько долго).

После входа в учетную запись AWS, которую можно безопасно применять для тестирования, запустите тест:

$ go test -v -timeout 30m

TestAlbExample 2019-05-26T13:29:32+01:00 command.go:53:

Running command terraform with args [init -upgrade=false]

(...)

TestAlbExample 2019-05-26T13:29:33+01:00 command.go:53:

Running command terraform with args [apply -input=false -lock=false]

(...)

TestAlbExample 2019-05-26T13:32:06+01:00 command.go:121:

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

(...)

TestAlbExample 2019-05-26T13:32:06+01:00 command.go:53:

Running command terraform with args [output -no-color alb_dns_name]

(...)

TestAlbExample 2019-05-26T13:38:32+01:00 http_helper.go:27:

Making an HTTP GET call to URL

http://terraform-up-and-running-1892693519.us-east-2.elb.amazonaws.com

(...)

TestAlbExample 2019-05-26T13:38:32+01:00 command.go:53:

Running command terraform with args

[destroy -auto-approve -input=false -lock=false]

(...)

TestAlbExample 2019-05-26T13:39:16+01:00 command.go:121:

Destroy complete! Resources: 5 destroyed.

(...)

PASS

ok   terraform-up-and-running   229.492s

Обратите внимание на аргумент -timeout30m, который используется вместе с коман­дой gotest. Go по умолчанию ограничивает время работы тестов десятью минутами; когда это время заканчивается, тестовое выполнение принудительно завершается, в результате чего тест не просто проваливается, но даже не доходит до кода очистки (terraformdestroy). Эта проверка ALB должна занять около пяти минут, но при реализации тестов, которые развертывают реальную инфраструктуру, время ожидания лучше увеличить, чтобы тест не прервался на полпути и не оставил после себя разного рода инфраструктуру.

Этот тест сгенерирует длинный журнальный вывод, но, если внимательно почитать, можно заметить все его ключевые моменты.

1. Выполнение terraforminit.

2. Выполнение terraformapply.

3. Чтение выходной переменной с помощью terraformapply.

4. Неоднократная отправка HTTP-запросов к ALB.

5. Выполнение terraformdestroy.

Этот код работает несравнимо медленнее модульных тестов на Ruby, но теперь менее чем за пять минут вы автоматически узнаете, ведет ли себя ли ваш модуль alb так, как вы того ожидали. Для инфраструктуры AWS это максимально быстро, и в результате вы должны увериться в том, что ваш код работает как следует. Если в вашем примере есть какая-либо ошибка (например, код состояния для действия по умолчанию был случайно изменен на 401), вы довольно скоро об этом узнаете:

$ go test -v -timeout 30m

(...)

Validation failed for URL

http://terraform-up-and-running-931760451.us-east-2.elb.amazonaws.com.

Response status: 401. Response body: 404: page not found.

(...)

Sleeping for 10s and will try again.

(...)

Validation failed for URL

http://terraform-up-and-running-h2ezYz-931760451.us-east-2.elb.amazonaws.com.

Response status: 401. Response body: 404: page not found.

(...)

Sleeping for 10s and will try again.

(...)

--- FAIL: TestAlbExample (310.19s)

http_helper.go:94:

    HTTP GET to URL

http://terraform-up-and-running-931760451.us-east-2.elb.amazonaws.com

    unsuccessful after 10 retries

FAIL     terraform-up-and-running       310.204s

Внесение изменений в код

Вы уже можете запустить код приложения. Теперь начнем вносить изменения. Это итеративный процесс: вы редактируете код, повторно запускаете ручные или автоматические тесты, чтобы убедиться в корректности внесенных изменений, снова редактируете код, опять выполняете тесты и т. д.

Например, вы можете заменить вывод web-server.rb на Hello,Worldv2, перезапустить сервер и проверить результат:

$ curl http://localhost:8000

Hello, World v2

Еще раз выполните тесты и посмотрите, будут ли они пройдены:

$ ruby web-server-test.rb

(...)

Failure: test_integration_hello(TestWebServer)

web-server-test.rb:53:in `block in test_integration_hello'

     50:     do_integration_test('/', lambda { |response|

     51:       assert_equal(200, response.code.to_i)

     52:       assert_equal('text/plain', response['Content-Type'])

  => 53:       assert_equal('Hello, World', response.body)

     54:     })

     55:   end

     56:

web-server-test.rb:100:in `do_integration_test'

web-server-test.rb:50:in `test_integration_hello'

<"Hello, World"> expected but was

<"Hello, World v2">

(...)

Finished in 0.236401 seconds.

--------------------------------------------

8 tests, 24 assertions, 2 failures, 0 errors

75% passed

--------------------------------------------

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

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

$ git commit -m "Updated Hello, World text"