Пришло время собрать это все воедино. Для этого мы создадим правила прослушивателя, используя ресурс aws_lb_listener_rule:
resource "aws_lb_listener_rule" "asg" {
listener_arn = aws_lb_listener.http.arn
priority = 100
condition {
field = "path-pattern"
values = ["*"]
}
action {
type = "forward"
target_group_arn = aws_lb_target_group.asg.arn
}
}
Этот код добавляет правило прослушивателя, которое отправляет запросы, соответствующие любому пути, к целевой группе с ASG внутри.
Прежде чем разворачивать балансировщик нагрузки, нужно сделать еще кое-что — поменять старый вывод public_ip одного сервера EC2 на вывод доменного имени ALB:
output "alb_dns_name" {
value = aws_lb.example.dns_name
description = "The domain name of the load balancer"
}
Выполните terraformapply и почитайте полученный план. Согласно ему наш исходный сервер EC2 удаляется, а вместо него Terraform создает конфигурацию запуска, ASG, ALB и группу безопасности. Если с планом все в порядке, введите yes и нажмите клавишу Enter. Когда команда apply завершит работу, вы должны увидеть вывод alb_dns_name:
Outputs:
alb_dns_name = terraform-asg-example-123.us-east-2.elb.amazonaws.com
Скопируйте этот URL-адрес. Подождите, пока наши серверы загрузятся и ALB пометит их как работоспособные. Тем временем можете просмотреть то, что вы развернули. Открыв раздел ASG консоли EC2 (https://amzn.to/2MH3mId), вы должны увидеть, что группа автомасштабирования уже создана (рис. 2.12).
Рис. 2.12. Группа автомасштабирования
Если перейти на вкладку Instances (Серверы), можно увидеть запуск двух серверов EC2, как показано на рис. 2.13.
Рис. 2.13. Запуск серверов EC2 в ASG
Щелкнув на вкладке Load Balancers (Балансировщики нагрузки), вы увидите свой экземпляр ALB, как показано на рис. 2.14.
Рис. 2.14. Application Load Balancer
Чтобы найти целевую группу, как показано на рис. 2.15, перейдите на вкладку Target Groups (Целевые группы).
Рис. 2.15. Целевая группа
Если вы выберете свою целевую группу и щелкнете на вкладке Targets (Цели) в нижней части экрана, то сможете увидеть, как ваши серверы регистрируются в целевой группе и проходят проверки работоспособности. Подождите, пока их индикатор состояния не начнет показывать healthy. Это обычно занимает одну-две минуты. После проверьте вывод alb_dns_name, который вы скопировали ранее:
$ curl http://
Hello, World
Получилось! ALB направляет трафик к вашим серверам EC2. Каждый раз, когда вы обращаетесь по этому URL-адресу, он выбирает другой сервер для обработки запроса. Вы получили полностью рабочий кластер веб-серверов!
На этом этапе можно видеть, как ваш кластер реагирует на создание новых и удаление старых серверов. Например, перейдите на вкладку Instances (Серверы) и удалите один из серверов: установите флажок, нажмите вверху кнопку Actions (Действия) и затем поменяйте состояние сервера на Terminate (Удалить). Если вы снова попробуете обратиться к тестовому URL-адресу ALB, каждый ваш запрос должен вернуть 200OK даже после удаления сервера. ALB автоматически обнаружит, что сервера больше нет, и перестанет направлять к нему трафик. Что еще интересней, вскоре после удаления ASG поймет, что у нас остался один сервер вместо двух, и автоматически запустит замену (самовосстановление!). Чтобы увидеть, как ASG меняет свой размер, можете добавить в свой код Terraform параметр desired_capacity и снова выполнить команды apply.
Удаление ненужных ресурсов
Когда вы закончите экспериментировать с Terraform в конце этой или одной из следующих глав, желательно удалить все созданные вами ресурсы, чтобы за них не пришлось платить. Поскольку Terraform отслеживает все, что вы создаете, это не составит проблемы. Достаточно выполнить команду destroy:
$ terraform destroy
(...)
Terraform will perform the following actions:
# aws_autoscaling_group.example will be destroyed
- resource "aws_autoscaling_group" "example" {
(...)
}
# aws_launch_configuration.example will be destroyed
- resource "aws_launch_configuration" "example" {
(...)
}
# aws_lb.example will be destroyed
- resource "aws_lb" "example" {
(...)
}
(...)
Plan: 0 to add, 0 to change, 8 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value:
Вы, наверное, и сами понимаете, что команда destroy в промышленной среде должна использоваться редко (или вообще никогда). Ее нельзя отменить, поэтому Terraform даст вам последний шанс взглянуть на свои действия, отобразив на экране список всех ресурсов, которые будут удалены, и запросит у вас подтверждение. Если все выглядит хорошо, введите yes и нажмите клавишу Enter. Terraform построит граф зависимостей и удалит все ваши ресурсы в корректном порядке, как можно сильнее распараллеливая этот процесс. Через одну-две минуты ваша учетная запись AWS снова будет пустой.
Имейте в виду, что в дальнейшем мы продолжим разрабатывать этот пример, поэтому не удаляйте код Terraform! Но вы можете в любой момент выполнить команду destroy, чтобы удалить уже развернутые ресурсы. Прелесть концепции IaC в том, что вся информация об этих ресурсах описана в коде, поэтому при желании вы можете воссоздать их все с помощью одной команды: terraformapply. На самом деле последние внесенные изменения лучше зафиксировать в Git, чтобы вы могли отслеживать историю своей инфраструктуры.
Резюме
У вас теперь есть общее преставление об использовании Terraform. Декларативный язык позволяет легко описывать именно ту инфраструктуру, которую вы хотите создать. С помощью команды plan можно просмотреть потенциальные изменения и устранить ошибки, прежде чем приступать к развертыванию. Переменные, ссылки и зависимости позволяют избавить ваш код от повторяющихся фрагментов и сделать его максимально конфигурируемым.
Но это лишь начало. Из главы 3 вы узнаете, как Terraform следит за тем, какая инфраструктура уже была создана, и то, насколько сильно это влияет на структурирование кода Terraform. В главе 4 научитесь применять модули Terraform для создания инфраструктуры, пригодной для повторного использования.
25 Если технологии AWS кажутся вам запутанными, обязательно почитайте статью AWS in Plain English по адресу expeditedsecurity.com/aws-in-plain-english/.
26 Подробнее о рекомендуемых подходах к управлению пользователями в AWS можно почитать по ссылке amzn.to/2lvJ8Rf.
27 Больше о политиках IAM можно узнать на сайте AWS по адресу docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html.
28 Код Terraform можно также писать на чистом JSON и хранить в файлах с расширением .tf.json. Больше о синтаксисе HCL и JSON можно узнать на сайте Terraform: bit.ly/2MDZyaN.
29 На GitHub по адресу bit.ly/2OIIrr2 можно найти полезный список однострочных HTTP-серверов.
30 Больше о принципе работы CIDR можно узнать на странице в «Википедии» по адресу bit.ly/2l8Ki9g. Для преобразования диапазонов IP-адресов в CIDR и обратно можете использовать веб-калькулятор cidr.xyz или установить команду ipcalc в своем терминале.
31 Из книги: Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мастеру (The Pragmatic Programmer). — М.: Лори, 2009.
32 Более подробное обсуждение построения высокодоступных и масштабируемых систем в AWS приводится в статье по адресу bit.ly/2mpSXUZ.
33 Чтобы не усложнять эти примеры, мы запускаем серверы EC2 и ALB в одной подсети. В промышленных условиях их почти наверняка следовало бы разместить в разных подсетях: серверы EC2 в закрытой (чтобы они не были доступны непосредственно из Интернета), а ALB — в открытой (чтобы пользователи могли обращаться к нему напрямую).
3. Как управлять состоянием Terraform
В главе 2, используя Terraform для создания и обновления ресурсов, вы могли заметить, что при каждом выполнении команд terraformplan и terraformapply этой системе удавалось находить созданные ранее ресурсы и обновлять их соответствующим образом. Но откуда ей было известно о том, какие из них находятся под ее управлением? В вашей учетной записи AWS может находиться любая инфраструктура, развернутая с помощью различных механизмов (отчасти вручную, отчасти через Terraform, отчасти с помощью утилиты командной строки). Так как же Terraform определяет свои ресурсы?
В этой главе вы узнаете, как Terraform отслеживает состояние вашей инфраструктуры и каким образом это влияет на структуру файлов и каталогов, изоляцию и блокирование в проекте Terraform. Вот ключевые темы, по которым мы пройдемся.
• Что собой представляет состояние Terraform.
• Общее хранилище для файлов состояния.
• Ограничения внутренних хранилищ Terraform.
• Изоляция файлов состояния.
• Изоляция с помощью рабочих областей.
• Изоляция с помощью описания структуры файлов.
• Источник данных terraform_remote_state.
Примеры кода
Напоминаю: все примеры кода для этой книги можно найти по адресу github.com/brikis98/terraform-up-and-running-code.
Что собой представляет состояние Terraform
При каждом своем запуске система Terraform записывает информацию о созданной ею инфраструктуре в свой файл состояния. По умолчанию, если запуск происходит в /foo/bar, Terraform создает файл /foo/bar/terraform.tfstate. Этот файл имеет нестандартный формат JSON и связывает ресурсы Terraform в ваших конфигурационных файлах с их представлением в реальном мире. Представьте, к примеру, что у Terraform следующая конфигурация: