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



В связи с этим я рекомендую использовать отдельные папки 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.