Как написать поддерживаемый шаблон Terraform

для моей компании мне было поручено создать стандартную конфигурацию и шаблон для (EKS) кластера Kubernetes в Terraform, который можно развернуть с помощью GitLab CI/CD. Развертывание и настройка выполнялись некоторое время, но я боролся с шаблонной стороной вещей.

Вот моя задача: создать шаблон проекта/репозитория с конфигурацией, которую кто-то другой может копировать и редактировать.

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

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

Итак, я в растерянности здесь.Это не кажется очень удобным для меня или для них в будущем. Самое главное, когда для моего шаблона произойдет обновление основной версии, их конфигурация наверняка сломается, и я не смогу исправить это без большого количества ручной работы. Я хочу сделать немного больше работы сейчас, чтобы в будущем его можно было поддерживать с минимальными усилиями, но я не могу найти хорошего решения.

Итак, мой вопрос ко всем вам звучит так: как мне правильно создать поддерживаемый шаблон кластера Terraform Kubernetes, который я смогу обновлять с минимальными усилиями в будущем?

Модули Terraform — это предполагаемый механизм для инкапсуляции набора объявлений в повторно используемую форму.

Вы упомянули, что ваша основная проблема заключается в том, что функции, добавленные позже, могут привести к тому, что модуль превратится в «необслуживаемый беспорядок». Это типичная проблема проектирования, с которой должны справиться специалисты по сопровождению любого повторно используемого кода: для каждой новой функции, которую кто-то запрашивает, вам нужно будет либо найти способ интегрировать ее в существующий дизайн, либо объявить эту функцию выходящей за рамки и предоставить отдельное решение этой проблемы, например, другой модуль, предназначенный для использования вместе с первым.

Не может быть универсального решения проблемы постоянного сопровождения общего кода, будь то в Terraform или нет, но раздел документации Terraform Состав модуля описывает некоторые шаблоны для разбиения проблемы на более мелкие части, которые можно комбинировать вместе по-разному.

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