Я знаю, что это 5 месяцев, но я думаю, что часть ситуации здесь в том, что способ, которым вы описываете его разделение, не совсем соответствует тому, как модули предназначены для использования.С одной стороны, вы не можете «создать ресурс» динамически, так как Terraform по своей природе декларативен.Вы можете только определить ресурс и затем динамически предоставить его предопределенные входные данные (включая его счетчик для активации / деактивации).Во-вторых, модули ни в коем случае не нужны для включения и выключения частей стека посредством конфигурации.Модули просто представляют собой способ группировки наборов ресурсов вместе для сдерживания и повторного использования.Любой динамизм, доступный вам со стеком, состоящим из сложной иерархии модулей, будет одинаково доступен с практически одним и тем же кодом в гигантском монолитном объекте.Монолит будет просто беспорядком, это проблема, и вы не сможете использовать его для других целей.Наконец, использование модуля для предоставления настроек не совсем то, для чего они нужны.Да, теоретически вы можете создать модуль с «null_data_source», а затем использовать его исключительно как своего рода прокладку для обеспечения настроек, но, скорее всего, это будет излишне ненужный подход к чему-то, что лучше сделать, просто предоставив переменную, как у вас естьуже показано.
Вам, вероятно, потребуется , чтобы обернуть это в какой-то сценарий bash (и т. д.) на верхнем уровне, как указано в других ответах, и это , а не ограничение терраформ.Например, если у вас есть свои модули, вы захотите сохранить все применяемые в настоящее время стеки (для каждого клиента или чего-либо еще) в каком-либо репозитории композиций.Как вы будете создавать составные стеки для этих клиентов после заполнения формы установки?Вам придется сделать это с некоторой автоматизацией создания файлов, для которой Terraform не предназначен.Terraform предназначен для выполнения существующих стеков.Terraform не является ограничением того, что для начала вам нужно создавать файлы .tf с помощью внешнего текстового редактора, и не является ограничением того, что в подобной ситуации вы использовали бы некоторые внешние сценарии для динамического создания стеков композиции для клиента.это всего лишь часть того, как вы будете использовать автоматизацию, чтобы подготовить Terraform к работе по применению стеков.
Таким образом, вы не можете избежать этого внешнего инструмента скриптов, и вы, вероятно, использовали бы его для созданияпапки для пользовательских стеков композиции (которые относятся к вашим модулям), заполнение папок файлами по умолчанию и создание файла .tfvars на основе данных, введенных клиентами из формы.Тогда вы можете сделать это несколькими способами:
У вас есть файл .tfvars, который будет единственным отличием стеков составов клиентов.Независимо от того, какие модули вы используете или не хотите использовать, они будут активированы / деактивированы упомянутой вами «уловкой подсчета» с учетом переменных из .tfvars.Этот способ имеет то преимущество, что его легко рассуждать, так как все стеки составления клиентов - это одно и то же, просто они настроены по-разному.
У вас может быть инструмент, фактически вставляющий определения модулей, которые вы хотите вфайлы композиции стеков.Это создаст более сжатые композиции стеков, с меньшим количеством хитрых «хитростей подсчета», но стек каждого клиента будет его собственной странной снежинкой.
Что касается разделения модулей, имейте в виду, что естьэто целое искусство / наука / философия об этом.Я отсылаю вас к этому ресурсу по шаблонам проектирования IAC и к этому разговору по теме (соответствующий бит начинается в 19:15).Это общий контекст по теме.
В вашем конкретном случае вы, по сути, хотели бы поместить все наименьшие делимые функциональные блоки (которые могут быть включены / выключены) в свои собственные модули, на которые должны ссылаться модули потребления более высокого уровня.Вы упоминаете, что не было возможности иметь модуль для каждой перестановки, опять же, который думает об этом неправильно.Вы стремитесь к чему-то, что будет представлять собой дерево модулей и комбинаций.На верхнем уровне у вас будет инструмент (bash и т. Д.), Который создаст новую композиционную папку клиентов, их файл .tfvars и поместит в тот же составной стек, который будет вершиной «дерева модулей».Каждый модуль, представляющий необязательную часть стека клиентов, будет считаться.Эти модули будут либо иметь функциональные ресурсы внутри, либо будут являться промежуточными модулями, которые сами будут создавать настраиваемый набор альтернативных субмодулей, содержащих ресурсы.
Но вам придется сесть и подумать над дизайном "дерево решений ", реализованная в виде иерархии модулей, которая охватывает все перестановки, для которых невозможно создать отдельные монолитные стеки. Динамические вложенные блоки TFv12
помогут вам конкретно с одним аспектом: иметь или не иметьобъявленный блок, как app_settings.Поскольку вы не можете «создать ресурс» динамически, единственной альтернативой в подобном случае будет наличие промежуточного модуля, который объявляет ресурс несколькими способами (с блоком app_settings и без него), и один из них будет выбран через «count».трюк "или другая входная конфигурация.Подобные вещи просто не нужны сейчас, когда существуют динамические блоки.