Comments 9
Подскажите, а новые версии приложения раскатывать, это совсем не про terraform?
Правильно понимаю, что нужно сделать AMI, который готов, скажем, делать docker pull при помощи CI/CD системы? И далее он просто живет и Jenkins туда катит новые версии.
Или есть способы, при которых можно через terraform apply раскатывать новые версии приложения?
пакером соберите нужную конфигурацию вашего приложение и раскатывайте через терраформ
learn.hashicorp.com/tutorials/terraform/packer
learn.hashicorp.com/tutorials/terraform/packer
как вариант — работать с провижинерами, если вы работаете с EC2
www.terraform.io/docs/provisioners/index.html
Но мне не нравится, проще заменить immutable образ полностью. Ну и обратите предупреждение Provisioners are a Last Resort
www.terraform.io/docs/provisioners/index.html
Но мне не нравится, проще заменить immutable образ полностью. Ну и обратите предупреждение Provisioners are a Last Resort
Расскажите человеку про Terragrunt, пожалуйста. У меня болит голова от идеи симлинков в репозитории с Terraform кодом.
Автор, у меня есть неплохое и даже не костыльное решение твоей проблемы с невозможностью использовать бренчи при работе с терраформ кодом.
Во-первых, моя система управления полностью в докере. Из докер-среды я управляю терраформой, ансиблом и кубером. Это удобно даже потому, что много проектов подразумевают разные версии 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 бренчами, и при этом ничего не будет ломаться.
Sign up to leave a comment.
Паттерны в Terraform для борьбы с хаосом и ручной рутиной. Максим Кострикин (Ixtens)