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

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

•aws_security_group и aws_security_group_rule;

• aws_route_table и aws_route;

•aws_network_acl и aws_network_acl_rule.

Теперь вы готовы развернуть свой кластер веб-серверов сразу в тестовой и промышленной средах. Выполните terraformapply и наслаждайтесь работой с двумя отдельными копиями своей инфраструктуры.

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

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

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

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

Управление версиями

Если ваши тестовая и промышленная среды ссылаются на папку с одним и тем же модулем, любое изменение в этой папке коснется и той и другой при следующем же развертывании. Такого рода связывание усложняет тестирование изменений в изоляции от промышленного окружения. Вместо этого лучше использовать разные версии модулей: например, v0.0.2 для тестовой среды и v0.0.1 для промышленной, как показано на рис. 4.5.

Рис. 4.5. Применение разных версий модуля в разных окружениях

Во всех примерах с модулями, которые вы видели до сих пор, параметр source содержал локальный файловый путь. Но, помимо файловых путей, модули Terraform поддерживают и другие виды источников, такие как URL-адреса Git/Mercurial и произвольные URL44. Самый простой способ управления версиями модуля — размещение его кода в отдельном Git-репозитории, URL-адрес которого затем прописывается в параметре source. Это означает, что код Terraform будет распределен (как минимум) по двум репозиториям.

•modules — в этом репозитории находятся универсальные модули. Каждый модуль — своего рода «чертеж», который описывает определенную часть вашей инфраструктуры.

•live — репозиторий, который содержит текущую инфраструктуру, развернутую в каждом окружении (stage, prod, mgmt и т. д.). Это такие «здания», которые вы строите по «чертежам», взятым из репозитория modules.

Обновленная структура папок для вашего кода Terraform будет выглядеть примерно так, как на рис. 4.6.

Рис. 4.6. Структура файлов и каталогов с несколькими репозиториями

Чтобы организовать код таким образом, сначала нужно переместить папки stage, prod и global в папку под названием live. Затем вы должны разнести папки live и modules по отдельным Git-репозиториям. Вот пример того, как это делается с папкой modules:

$ cd modules

$ git init

$ git add .

$ git commit -m "Initial commit of modules repo"

$ git remote add origin "(URL OF REMOTE GIT REPOSITORY)"

$ git push origin master

Репозиторию modules можно также назначить тег, который будет использоваться в качестве номера версии. Если вы работаете с сервисом GitHub, это можно сделать в его пользовательском интерфейсе: создайте выпуск (bit.ly/2Yv8kPg), который автоматически создаст тег. Если вы не используете GitHub, можете применить утилиту командной строки Git:

$ git tag -a "v0.0.1" -m "First release of webserver-cluster module"

$ git push --follow-tags

Теперь вы можете работать с разными версиями модуля в тестовой и промышленной средах, указав URL-адрес Git в параметре source. Вот как это будет выглядеть в файле live/stage/services/webserver-cluster/main.tf, если ваш репозиторий modules находится в GitHub по адресу github.com/foo/modules (имейте в виду, что двойная косая черта в URL-адресе Git является обязательной):

module "webserver_cluster" {

  source = "github.com/foo/modules//webserver-cluster?ref=v0.0.1"

  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

}