если нужно только одну базу данных и нет проблем inputs задать со стандартными именами переменных - то можно использовать open source терраформ модули
если нужно создать много и разных баз данных, то я обычно делаю следующее:
(в меньшинстве своем - потому что может возникнуть проблема с breaking changes updates of terraform module) или использую стандартную терраформ библиотеку
(чаще) или использую свой терраформ модуль. Это дает возможность скомпоновать input в виде array/ map с нужными данными (DRY / common values / мои собственные конвенции).
за: В случае множества динамичных ресурсов - это себя окупает по времени,
против: добавляет нужду все это поддерживать, а не использовать уже существующее. Хотя наш терраформ модуль может быть и оберткой на open source module
(лучше всего) отдельный террагрант модуль на каждую базу данных.
за:
бласт радиус,
свой tfstate на каждый такой модуль,
если надо что-то поменять в одном модуле - то надо запустить только его и не все остальное
можно заморозить версии террагрант модуля - для каждого свою версию (хорошо для отладки модуля)
(в случае террагрант модуля) если только для dependency - то можно прописать, какой модуль от какого зависит и это запустит модуль только один раз (когда это нужно). Что хорошо в террагранте - можно запустить только один модуль, но дать аргумент для вызова всех dependency modules: terragrunt run-all plan --terragrunt-source-update --terragrunt-non-interactive --terragrunt-include-external-dependencies
(в случае терраформ модуля) можно прописать разные версии терраформ модуля в разных террагран модулях и кеш терраформ модулей будет создан для каждого террагрант модуля по отдельности
Только у меня вопрос, а почему не GitHub Actions или Argo Workflows + Argo CD + Argo Rollouts? C точки зрения цены - это все бесплатно, но уже не так лампово, это да...
Это так. Но тут есть за и против:
если нужно только одну базу данных и нет проблем inputs задать со стандартными именами переменных - то можно использовать open source терраформ модули
если нужно создать много и разных баз данных, то я обычно делаю следующее:
(в меньшинстве своем - потому что может возникнуть проблема с breaking changes updates of terraform module) или использую стандартную терраформ библиотеку
(чаще) или использую свой терраформ модуль. Это дает возможность скомпоновать input в виде array/ map с нужными данными (DRY / common values / мои собственные конвенции).
за: В случае множества динамичных ресурсов - это себя окупает по времени,
против: добавляет нужду все это поддерживать, а не использовать уже существующее. Хотя наш терраформ модуль может быть и оберткой на open source module
(лучше всего) отдельный террагрант модуль на каждую базу данных.
за:
бласт радиус,
свой tfstate на каждый такой модуль,
если надо что-то поменять в одном модуле - то надо запустить только его и не все остальное
можно заморозить версии террагрант модуля - для каждого свою версию (хорошо для отладки модуля)
против:
очень много hcl файлов?
А зачем вызывать модуль несколько раз?
(в случае террагрант модуля) если только для dependency - то можно прописать, какой модуль от какого зависит и это запустит модуль только один раз (когда это нужно). Что хорошо в террагранте - можно запустить только один модуль, но дать аргумент для вызова всех dependency modules:
terragrunt run-all plan --terragrunt-source-update --terragrunt-non-interactive --terragrunt-include-external-dependencies(в случае терраформ модуля) можно прописать разные версии терраформ модуля в разных террагран модулях и кеш терраформ модулей будет создан для каждого террагрант модуля по отдельности
Спасибо - очень хорошая статья.
Единственное - про backend: это уже не так, можно создавать терраформ модули без пустого блока backend
Да - расписано очень хорошо.
Только у меня вопрос, а почему не GitHub Actions или Argo Workflows + Argo CD + Argo Rollouts? C точки зрения цены - это все бесплатно, но уже не так лампово, это да...