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

И передайте важные выходные параметры из asg-rolling-deploy и alb в качестве вывода модуля hello-world-app:

output "alb_dns_name" {

  value       = module.alb.alb_dns_name

  description = "The domain name of the load balancer"

}

output "asg_name" {

  value       = module.asg.asg_name

  description = "The name of the Auto Scaling Group"

}

output "instance_security_group_id" {

  value       = module.asg.instance_security_group_id

  description = "The ID of the EC2 Instance Security Group"

}

Это композиция функций в действии: вы выстраиваете сложное поведение (приложение Hello, World) из более простых частей (модули ASG и ALB). В Terraform часто можно встретить как минимум два типа модулей.

•Обобщенные модули. Такие модули, как asg-rolling-deploy и alb, являются базовыми составными блоками вашего кода, которые можно использовать во множестве разных сценариев. Вы видели, как с их помощью развертывается приложение Hello, World, но те же модули можно применить, к примеру, чтобы развернуть ASG для запуска кластера Kafka или полностью автономного экземпляра ALB, способного распределять нагрузку между разнообразными приложениями. Использовать один балансировщик для всех приложений сразу будет дешевле, чем выделять для каждого из них по одному ALB.

•Узкоспециализированные модули. Модули вроде hello-world-app сочетают в себе несколько обобщенных модулей с расчетом на один конкретный сценарий использования, скажем, развертывание приложения Hello, World.

В реальной работе вам, возможно, придется дробить свои модули еще сильнее, чтобы улучшить композицию и повторное применение. Например, вы можете применять коллекцию открытых, универсальных модулей из репозитория terraform-aws-consul (http://bit.ly/33hhOwr) для работы с HashiCorp Consul. Consul — это открытое, распределенное хранилище типа «ключ — значение», которому иногда нужно прослушивать сетевые запросы на множестве разных портов (серверные RPC, CLI RPC, Serf WAN, HTTP API, DNS и т. д.), поэтому оно обычно требует около 20 групп безопасности. В репозитории terraform-aws-consul правила этих групп описываются в отдельном модуле consul-security-group-rules (http://bit.ly/31oo5oc).

Чтобы понять, зачем это нужно, можно сначала посмотреть на то, как развертывается система Consul. Ее часто развертывают в качестве хранилища данных для HashiCorp Vault, открытого распределенного хранилища конфиденциальной информации, в котором можно безопасно размещать пароли, API-ключи, сертификаты TLS и т. д. В репозитории terraform-aws-vault (http://bit.ly/2MM6AKn) можно найти коллекцию открытых универсальных модулей для работы с Vault. Там же представлена диаграмма, на которой изображена типичная промышленная архитектура для этой системы (рис. 6.3).

В промышленных условиях Vault обычно запускается в одной группе ASG, состоящей из 3–5 серверов (развернутых с помощью модуля vault-cluster (http://bit.ly/2TngRON), а Consul — в другой, тоже с 3–5 серверами (развернутыми с модулем consul-cluster (http://bit.ly/2YQXIWe), поэтому каждую из этих систем можно масштабировать и защищать по отдельности. Однако в ­тестовом окружении ­запуск такого количества серверов будет излишним, поэтому, чтобы сэкономить, Vault и Consul лучше запускать в одной группе ASG, состоящей, скажем, из одного сервера и развернутой с использованием модуля vault-cluster. Если бы все правила группы безопасности Consul были описаны в модуле consul-cluster, вы бы не смогли применять их повторно (разве что вы вручную скопируете 20 с лишним правил) при развертывании Consul с модулем vault-cluster. Но, поскольку правила описаны в отдельном модуле, consul-security-group-rules, вы можете подключить их к vault-cluster или к кластеру почти любого другого типа.

Рис. 6.3. Архитектура HashiCorp Vault и Consul

Для простого приложения вроде Hello, World такого рода разбиение будет чрезмерным, но, если вы имеете дело с настоящей сложной инфраструктурой, выделение правил группы безопасности, политик IAM и других сквозных элементов в отдельные автономные модули — часто необходимый шаг для поддержки разных методик развертывания. Мы их использовали не только для Consul и Vault, но и для стека ELK (в промышленной среде мы запускали Elasticsearch, Logstash и Kibana в отдельных кластерах, а в тестовой — в одном и том же), Confluent Platform (в промышленной среде мы запускали Kafka, ZooKeeper, REST Proxy и Schema Registry в отдельных кластерах, а в тестовой — в одном и том же), стека TICK (в промышленной среде мы запускали Telegraf, InfluxDB, Chronograf и Kapacitor в отдельных кластерах, а в тестовой — в одном и том же) и т. д.

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

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