Как я могу разделить создание ресурса на разные модули с помощью Terraform?

Лучший способ сделать это - обернуть terraform сценарием bash или любым другим языком сценариев, который вы хотите (python). Затем создайте шаблон в bash или python (jinja2) для создания ресурса с любыми параметрами, выбранными клиентом для настроек, запустите шаблон для генерации кода терраформы, а затем примените его.

Я довольно часто делал это с ведрами S3. В terraform 0.12 вы можете создавать шаблоны в terraform.

Я знаю, что ему 5 месяцев назад, но я думаю, что часть ситуации здесь заключается в том, что способ, которым вы описываете разделение, не совсем соответствует тому, как модули предназначены для использования. Во-первых, вы не можете «наращивать ресурс» динамически, так как Terraform декларативен по своему замыслу. Вы можете только определить ресурс, а затем динамически предоставить его предопределенные входы (включая его количество для активации / деактивации). Во-вторых, модули никоим образом не нужны для включения и выключения частей стека через конфигурацию. Модули - это просто способ группировки наборов ресурсов вместе для сдерживания и повторного использования. Любой динамизм, доступный вам со стеком, состоящим из сложной иерархии модулей, будет в равной степени доступен с по существу одним и тем же кодом в гигантском монолитном блоке. Монолит будет просто беспорядком, вот в чем проблема, и вы не сможете использовать его части для других целей. Наконец, использование модуля для предоставления настроек - не совсем то, для чего они нужны. Да, теоретически вы могли бы создать модуль с «null_data_source», а затем использовать его просто как своего рода прокладку для предоставления настроек, но, вероятно, это будет запутанный ненужный подход к чему-то, что лучше сделать, просто предоставив переменную так, как вы уже показано.

Вероятно, вам потребуется обернуть это в какой-то сценарий bash (и т. Д.) На верхнем уровне, как упоминалось в других ответах, и это не ограничение terraform. Например, если у вас есть модули, вы захотите сохранить все применяемые в данный момент стеки (для каждого клиента или чего-то еще) в каком-то репозитории композиции. Как вы будете создавать наборы композиций для этих клиентов после того, как они заполнят форму настройки? Вам придется сделать это с помощью некоторой автоматизации создания файлов, для которой Terraform не предназначен. Terraform предназначен для выполнения существующих стеков. Это не ограничение Terraform, что вы должны для начала создавать файлы .tf с помощью внешнего текстового редактора, и это не ограничение, что в такой ситуации вы должны использовать некоторые внешние сценарии для динамического создания стеков композиции для клиента. , это лишь часть того, как вы использовали бы автоматизацию, чтобы подготовить Terraform к выполнению своей работы по применению стеков.

Таким образом, вы не можете избежать этого внешнего инструментария-скрипта, и вы, вероятно, использовали бы его для создания папок для конкретных стека композиций клиента (которые относятся к вашим модулям), заполнения папок файлами по умолчанию и для создания файла .tfvars на основе клиенты вводят данные из формы. Тогда вы можете сделать это несколькими способами:

1. У вас есть файл .tfvars, который является единственной разницей между стеками состава клиентов. Независимо от того, какие модули вы используете или не хотите использовать, они будут активированы / деактивированы упомянутым вами «счетным трюком» с учетом переменных из .tfvars. Преимущество этого способа состоит в том, что его легко рассуждать, поскольку все стеки составления клиентов - это одно и то же, только настроенные по-разному.

2. У вас может быть инструмент, который действительно вставляет определения модулей, которые вы хотите, в файлы стека композиции. Это позволит создать более лаконичные стеки композиции с меньшим количеством трюков со счетом, но стопка каждого покупателя будет представлять собой свою странную снежинку.

Что касается разделения модулей, имейте в виду, что в этом есть целое искусство / наука / философия. Я отсылаю вас к этому ресурсу по шаблонам проектирования IAC и этот доклад на эту тему (соответствующий фрагмент начинается в 19:15). Это общий контекст по предмету.

В вашем конкретном случае вы в основном захотите поместить все самые маленькие делимые функциональные блоки (которые могут быть включены / выключены) в их собственные модули, на каждый из которых будут ссылаться модули, потребляющие более высокого уровня. Вы упомянули, что невозможно иметь модуль для каждой перестановки, опять же, вы неправильно думаете об этом. Вы бы нацелились на что-то, что было бы скорее деревом модулей и комбинаций. На верхнем уровне у вас будет инструмент (bash и т. Д.), Который создает папку композиции новых клиентов, их файл .tfvars и помещает в тот же стек композиции, который будет наверху «дерева модулей». Каждый модуль, представляющий необязательную часть стека клиентов, будет подсчитан. Эти модули будут либо иметь функциональные ресурсы внутри, либо будут промежуточными модулями, которые сами создают настраиваемый набор альтернативных подмодулей, содержащих ресурсы.

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

Динамические вложенные блоки TFv12 помогут вам, в частности, с одним аспектом наличия или отсутствия объявленного блока, такого как app_settings. Поскольку вы не можете «создавать ресурс» динамически, единственной альтернативой в подобном случае было бы наличие промежуточного модуля, который объявляет ресурс несколькими способами (с блоком app_settings и без него), и один из них будет выбран через «count трюк »или другая конфигурация входа. Теперь, когда существуют динамические блоки, в подобных вещах нет необходимости.