Автор, у меня есть неплохое и даже не костыльное решение твоей проблемы с невозможностью использовать бренчи при работе с терраформ кодом.
Во-первых, моя система управления полностью в докере. Из докер-среды я управляю терраформой, ансиблом и кубером. Это удобно даже потому, что много проектов подразумевают разные версии terraform/kubectl/helm/kubeless и всего остального. Dockerfile, docker-compose.yml.
Во-вторых, внутри этого докер образа настроен .bashrc — персоналии, подсветки, комплишны и прочие свистелки — и среди них есть несколько команд, которые детектят среду (дев/прод) и добавляют соответствующие энвы — которые максимально удобны и в ансибле, или для тонкой настройки терраформы. .bashrc, env-helper.
В-третьих, у терраформ-бинаря есть wrapper. Враппер туп как табурет — он, используя энвы, которые заданы из env-helper, устанавливает симлинку на правильный файл. Например, globals.tf смотрит на envs/production.tf как на этой пикче.
В четвертых, файлы envs/some_env.tf содержат в себе определения для state backend и уже довольно приличную горстку переменных, которые (и только которые) определяют поведение кода терраформа. Например, тип инстанса и дефолтный размер aws autoscaling group.
По итогу, мы получаем возможность работать с кодом терраформа на основе git workflow — например, можно делать мерджи между master/develop бренчами, и при этом ничего не будет ломаться.
Во-первых, моя система управления полностью в докере. Из докер-среды я управляю терраформой, ансиблом и кубером. Это удобно даже потому, что много проектов подразумевают разные версии terraform/kubectl/helm/kubeless и всего остального. Dockerfile, docker-compose.yml.
Во-вторых, внутри этого докер образа настроен .bashrc — персоналии, подсветки, комплишны и прочие свистелки — и среди них есть несколько команд, которые детектят среду (дев/прод) и добавляют соответствующие энвы — которые максимально удобны и в ансибле, или для тонкой настройки терраформы. .bashrc, env-helper.
В-третьих, у терраформ-бинаря есть wrapper. Враппер туп как табурет — он, используя энвы, которые заданы из env-helper, устанавливает симлинку на правильный файл. Например, globals.tf смотрит на envs/production.tf как на этой пикче.
В четвертых, файлы envs/some_env.tf содержат в себе определения для state backend и уже довольно приличную горстку переменных, которые (и только которые) определяют поведение кода терраформа. Например, тип инстанса и дефолтный размер aws autoscaling group.
По итогу, мы получаем возможность работать с кодом терраформа на основе git workflow — например, можно делать мерджи между master/develop бренчами, и при этом ничего не будет ломаться.