Паттерны в Terraform для борьбы с хаосом и ручной рутиной. Максим Кострикин (Ixtens)

[@Jsty]

Подскажите, а новые версии приложения раскатывать, это совсем не про terraform?
Правильно понимаю, что нужно сделать AMI, который готов, скажем, делать docker pull при помощи CI/CD системы? И далее он просто живет и Jenkins туда катит новые версии.
Или есть способы, при которых можно через terraform apply раскатывать новые версии приложения?

[@zer0nka]

пакером соберите нужную конфигурацию вашего приложение и раскатывайте через терраформ
learn.hashicorp.com/tutorials/terraform/packer

[@yellowmew]

как вариант — работать с провижинерами, если вы работаете с EC2
www.terraform.io/docs/provisioners/index.html
Но мне не нравится, проще заменить immutable образ полностью. Ну и обратите предупреждение Provisioners are a Last Resort

[@OkGoLove]

Расскажите человеку про Terragrunt, пожалуйста. У меня болит голова от идеи симлинков в репозитории с Terraform кодом.

[@chemtech]

Еще на докладе рассказали.

[@mkostrikin]

не было задачи, рассказать — как теоретически было можно, а рассказал, как было.
Terragrunt — делает не нужным, некоторые «советы».

[@MrEcco]

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

Во-первых, моя система управления полностью в докере. Из докер-среды я управляю терраформой, ансиблом и кубером. Это удобно даже потому, что много проектов подразумевают разные версии 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 бренчами, и при этом ничего не будет ломаться.

[@yellowmew]

решали похожие задачи костылями. Может быть вы сделаете статью с описанием как это работает у вас? было бы интересно

[@chemtech]

Напишите пост с подробностями. Всем интересно.