Каково назначение файла variables.tf в корневом каталоге Terraform при использовании модулей?

Question

Я пишу некоторый код для описания инфраструктуры AWS и следую рекомендациям Terraform.Чтобы сделать мой код более пригодным для повторного использования и использовать его в будущем, я использую модули.В конце мой код может выглядеть так:

├── modules
│   └── aws_vpc
│       ├── main.tf
│       └── vars.tf
├── prod
│   ├── main.tf
│   └── variables.tf
├── terraform.tfstate
└── terraform.tfstate.backup

Я НЕ использую рабочее пространство terraform для простоты.

Вопрос в том, какова цель variables.tf в каталоге Terraform root, если я не могу использовать их в модулях?

Идея состоит в том, чтобы иметь отдельные каталоги для каждой среды dev, prod и qa, где я могу повторно использовать все свои модули, определенные в каталоге modules, и использовать переменные среды, определенные в каталоге env,

Есть аналогичные обсуждения на страницах Terraform Github , но, как я вижу, такое использование не приветствуется.

Итак, какова цель variables.tf в корневом каталоге Terraform, если я не могу использовать их позже в модулях?

Я знаю, что есть Terragrunt, который действует как обертка вокруг Terraform, но я хотел бы придерживаться Terraform исключительно.

Answer 1

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

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

Ваш модуль вызывается кодом Terraform в каталоге вашей среды ./prod/, который сам имеет объявления variable в ./prod/variables.tf.Поскольку вы создаете каталог для каждой среды, единственный способ обмениваться данными или ресурсами на этом верхнем уровне - это копировать / вставлять или создавать символические ссылки, например, так:

├── modules
│   └── aws_vpc
│       ├── main.tf
│       └── vars.tf
├── prod
│   ├── global_variables.tf (symlink from ./shared/global_variables.tf)
│   ├── main.tf
│   └── variables.tf
├── shared
│   └── global_variables.tf
├── terraform.tfstate
└── terraform.tfstate.backup

Обратите внимание, что если вы нена самом деле вы хотите изменить эти значения во время выполнения с помощью -var или -var-file, вы можете использовать localals .Я использовал переменные со значениями по умолчанию вместо локальных, но если значение никогда не изменится для этой среды, имеет смысл вместо этого использовать локальные.

Answer 2

В любом данном Terraform dir, я не думаю, что какие-либо .tf файлы имеют какую-либо конкретную функцию, кроме как дать вам некоторую информацию о том, как вы распределили свои ресурсы и / или организоваливаш код.Таким образом, main.tf и variables.tf могут быть объединены в 1 файл без потери функции.

В вашей настройке ваш variables.tf будет иметь набор переменных, каждый из которых будет иметь значение default (илиКоманды else terraform x запрашивают их значения).В качестве альтернативы вы можете опустить значения default и вместо этого создать файл terraform.tfvars, который устанавливает значения для каждой переменной.

В этой настройке с отдельными директориями для каждой среды (prod, test, dev и т. Д.), Я предпочитаю использовать terraform.tfvars, так как мне легче делать различия, и я знаю, что единственное, что янеобходимо изменить с любым заданным env файл terraform.tfvars.

Например, cidr_block может быть переменной, которую вы указываете для каждого env, а затем передавать в модуль aws_vpc. prod может быть 192.168.0.0/16, в то время как test может иметь 10.1.0.0/16.

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