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

Концепцию изоляции лучше опустить на уровень ниже, вплоть до компонентов — наборов связанных между собой ресурсов, которые обычно развертываются совместно. Например, после настройки базовой сетевой топологии для своей инфраструктуры (в терминологии AWS это виртуальное частное облако (VPC) и все связанные с ним подсети, правила маршрутизации, VPN и сетевые списки доступа) вы будете менять ее не чаще раза в месяц. Но новые версии серверов могут развертываться по нескольку раз в день. Управляя инфраструктурой VPC и веб-сервера в одной и той же конфигурации Terraform, вы постоянно рискуете нарушить работу всей своей сетевой топологии (скажем, из-за простой опечатки в коде или случайного выполнения не той команды) без причины.

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

На рис. 3.7 показана типичная структура файлов в моих проектах.

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

•stage — среда для предпромышленной нагрузки (тестирование).

• prod — среда для промышленной нагрузки (приложения, взаимодействующие с пользователями).

• mgmt — среда для инструментария DevOps (например, узел-бастион, Jenkins).

•global — папка с ресурсами, которые используются во всех средах (скажем, S3, IAM).

Рис. 3.7. Типичная структура файлов для проекта Terraform

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

•vpc — сетевая топология для этой среды.

•services — приложения или микросервисы, которые запускаются в этой среде, например Ruby on Rails на стороне клиента или Scala на стороне сервера. Вы можете даже изолировать все приложения, поместив их в отдельные папки.

•data-storage — хранилища данных для этой среды, такие как MySQL или Redis. Хранилища можно изолировать друг от друга, разместив их в отдельных папках.

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

•variables.tf — входные переменные.

• outputs.tf — выходные переменные.

•main.tf — ресурсы.

При запуске Terraform просто ищет в текущей папке файлы с расширением .tf, поэтому вы можете называть свои файлы как угодно. Но, несмотря на это, вашим коллегам не все равно, какие названия файлов вы используете. Если задать последовательные и предсказуемые названия, это упростит просмотр кода. Вы всегда будете знать, где искать переменные, вывод или ­ресурсы. Если какой-то файл (особенно ma­in.tf) ­становится слишком крупным, можете свободно вынести из него часть функциональности (и назвать ее, к примеру, iam.tf, s3.tf или database.tf), но это также может быть признаком того, что вам следует разбить свой код на более мелкие модули. Эту тему мы подробно рассмотрим в главе 4.

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

Структура файлов и каталогов, описанная в этом разделе, имеет много повторя­ющихся элементов. Например, одни и те же приложения 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.