AWS Meetup Terraform & Terragrunt. Антон Бабенко (2020)
AWS Meetup Terraform & Terragrunt (Антон Бабенко)
Terraform — это популярный инструмент компании Hashicorp, для управления вашей облачной инфраструктурой в парадигме Infrastructure as a Code.
Terragrunt — это wrapper для Terraform, которая предоставляет дополнительные инструменты для хранения ваших конфигураций Terraform, работы с несколькими модулями Terraform и управления удаленным состоянием.
Видео:
Ссылки:
Я являюсь AWS Community Hero. Я — сертифицированный Terraform-фанатик, потому что я прошел сертификацию Terraform. Есть такое понятие, как HashiCorp-сертификация.
Я являюсь активным участником open source движения. Я много трачу своего времени, энергии на создание и поддержание Terraform-проектов, community-modules, aws-modules. Может быть, кто-то из вас даже чем-то пользуется из этого.
Я делаю много утилит таких, как, например, Pre-commit-terraform. Это утилита для автоматического форматирования кода документации, форматирования кода и т. д.
Я стараюсь участвовать во всех конференциях. В данном случае у меня появилась возможность выступить на этой конференции, благодаря тому, что завтра будет конференция Delivery Excellence. Вы можете сходить туда и услышать еще кучу всего про Terraform и не только про Terraform.
Если у вас есть Твиттер, GitHub и вы не рекрутер, то Linkedin для вас. Рекрутеры мне ну нужны, потому что все в open source, и мы все находим работу исключительно в open source.
Open source — это бесплатная чаще всего вещь. Мои проекты open source. Они мне дают обычно заказчиков, которые говорят: «Можешь сделать то же самое? Можешь научить нас пользоваться этим?». И это называется консалтинг.
Если есть какая-то команда, которая использует Terraform, и в Terraform используют Terraform workspace, то я говорю: «Давайте я вам workshops проведу и скажу, что это зло?». Это называется workshops.
Если люди пишут код в течение недели-двух и не совсем понимают правильно ли они делают, т. е., может быть, какое-то решение есть получше, тогда они обращаются ко мне, и я примерно час-два в неделю занимаюсь тем, что я их консультирую, смотрю pull request, обсуждаю решения и говорю, как это можно сделать по-другому. Не всегда лучше, иногда просто по-другому.
У меня есть email: anton [собака] antonbabanko.com. Вы всегда можете писать, я, скорее всего отвечу, т. е. я отвечаю, но иногда с задержкой, потому что я сейчас очень много путешествую.
Компания называется Betajob.com. Я в ней единственный сотрудник.
https://github.com/terraform-aws-modules
https://registry.terraform.io/modules/terraform-aws-modules
Terraform AWS модули — это один из основных моих проектов, который я начал в 2017-ом году, потому что мне нравилось делать что-то такое, что нужно большому количеству людей. Например, так или иначе настраивают VPC в Amazon. Я подумал, что надо сделать это как-то правильно. И вместо того, чтобы взять еще один модуль, который кто-то написал, я взял тот, который был самым популярным у меня. Потратил на него несколько сотен часов. И выложил это все в открытый доступ.
Дальше все остальные пошли намного лучше, быстрее. И все оказалось не таким сложным.
Тоже самое касается и поддержания этих сервисов, модулей. Я не трачу на них огромное количество времени. Но все равно достаточное.
https://github.com/sponsors/antonbabenko
Было 7 000 000 загрузок, больше 1 000 pull requests и множество issues было пофиксено. И частично это все благодаря этим 6 аватаркам, которые спонсируют меня на GitHub. Если ваша компания пользуется из этого чем-нибудь, то вы можете присоединиться, и ваш аватар будет тут тоже. Вам все равно, а мне приятно.
Еще один проект, с которым я связан, называется Cloudcraft. Это такая утилита, которая в браузере позволяет все это визуализировать, т. е. нарисовать инфраструктуру, соединить все компоненты. В общем, сделать все классно, как мы можем понять.
Cloudcraft дает возможность это все экспортировать как картинку, посмотреть, сколько это стоит или втянуть в существующую AWS-инфраструктуру.
https://dzone.com/articles/infrastructure-as-code-the-benefits
Я понимаю, что когда это все красиво смотрится, это может впечатлить начальников, менеджеров и дать больше денег, но когда мы возвращаемся к работе, то мы все равно пропагандируем здоровый образ жизни, т. е. инфраструктуру как код. Мы не может ничего сделать с картинкой, т. е. она классно выглядит, ее все пихают во все презентации. Но в реальности инфраструктура должна быть как код, а не инфраструктура как Powerpoint. Или еще хуже, когда инфраструктура как clickops, когда в консоли — клац, клац, готово. И никто не знает, как это работает, зачем это сделано.
И давайте договоримся, что инфраструктура как код — это хорошо, потому что мы ее отслеживаем, мы видим, кто поменял и что поменял. Мы можем четко посмотреть на файлы и понять, какая конфигурация прямо сейчас находится в проекте. К этому надо стремиться. Не всегда это получается. Для этого существуют сервисы cndb, Systems Manager от Amazon. Но это хорошая цель.
О чем мы будем сегодня говорить?
Есть Terraform 0.12 и Terraform 0.11.
Начнем с того, зачем Terraform появился. Я понимаю, что вы многие это уже знаете. Terraform довольно часто упоминается на большом количестве докладов. Тут ничего удивительно нет, потому что Terraform появился неспроста.
Amazon в 2011-ом году сказал: «Вот вам CloudFormation». На нулевой день люди поняли, что это круто. На первый день люди начали писать Spectrum, Fogs и т. д., чтобы собирать эти кусочки JSON, YAML и т. д., т. е. как-то их организовывать. Они придумывали разные DSL и т. д. Вы можете зайти на GitHub и погуглить, например, orchestration-cloudformation. И вы увидите большое разнообразие утилит. Spectrum — это одна из тех, о которой я сегодня здесь слышал от кого-то.
В общем, Google сказал, что все фигня, мы будем, как программисты, людям давать возможность писать на Python, пусть используют Jinja Tempating, будут описывать свою инфраструктуру. Это вполне здравомыслящий подход от Google.
Но Azure тоже сказал, что это все фигня, потому что нет ничего лучше, чем JSON. И ничего, что программисты не понимают, что там происходит. Программисты пользуются этим, плюются. Большинство программистов переходит из Azure ARM в Terraform в одностороннем порядке. Я ни разу не слышал, чтобы кто-то сказал, что Terraform — фигня, я обожаю JSON, я люблю мазахизм.
И по историческим причинам у нас есть Chef, Ansible, Puppet, которые так или иначе умеют всем управлять. У них есть миллион ресурсов, моделей, плейбуков. Там все здорово.
Из этого следует логичный вывод: если можно управлять каким-то одним ресурсом, то можно управлять и public cloud ресурсами Amazon, Google, Azure и т. д. У большинства configuration management утилит уже есть какие-то модули, решения, поэтому все классно. Поэтому сейчас мы видим, что есть куча решений: есть решения, которые сделаны одним провайдером, либо одно решение работает на разных провайдерах.
Terraform в 2014-ом году появился с той идеей, что давайте забудем все то, что есть у остальных, будем смотреть только на то, что сделал хорошего CloudFormation, потому что CloudFormation дал значительный вклады в понимание того, как должна работать архитектура, как ее описывать и что пользователи хотят с ней делать и т. д.
И поэтому появился Terraform, в котором сейчас поддерживается больше, чем 250 провайдеров и используется один и тот же язык для настройки, т. е. используется HashiCorp Configuration Language, где достаточно знать один язык, и можно одинаково работать с ресурсами совершенно на любом провайдере.
И Terraform является первой из существующих программ, утилит, которая позволяет работать с ресурсами на более высоком уровне. В Terraform есть концепция модуля, которая заложена в самую-самую основу. Буквально на второй день использования Terraform, так или иначе возникнет желание этот код использовать. И у Terraform есть такая возможность. У CloudFormation с самого начала этой возможности не было. Конечно, сейчас CloudFormation уже не такой, какой он был в 2013–2014-ом году, но все равно не так все радужно.
Также Terraform не работает со всеми доисторическими mainframes, workers и т. д. Поддерживается то, что существовало, начиная с 2014-го года. Если вы хотите администрировать то, что не администрируется, то вам нужно самому написать API к этому, и написать в Terraform провайдер. И тогда у вас будет Terraform администрировать неадминистрируемое. Это тоже нормальный use cases.
https://www.terraform.io/docs/providers/index.html
Но на самом деле API есть у всего, т. е. от создания email в Google до управления файлами и permeation в Dropbox, и до заказов пиццы. Наверное, многие уже знают, что пиццу тоже можно через Terraform заказывать. Это нормальный use cases.
Но мне больше нравится use cases, где в основу принята концепция взаимодействия. Представьте, что у вас в Minecraft есть земля и есть овца. И если мы бросаем овцу, то овца будет падать-падать. И в конце концов упадет на землю. Если мы уберем землю, то овца упадает и умрет. Поэтому что надо сделать, если мы мыслим как Terraform? Надо сделать так, чтобы овца зависела от земли. И когда мы это описываем внутри hsale, то мы описываем, что есть ресурс овца и ресурс земля. И делаем так, что ресурс овца принимает как аргумент землю. Таким образом мы даем Terraform понять, что сначала сделай землю, а потом брось туда овцу, иначе все пропадет. Это пример того, как можно использовать зависимость в реальном мире.
Это примерно по той же причине, зачем мы придумали объектно-ориентированное программирование. Мы посмотрели вокруг себя и увидели, что у нас много объектов. И решили придумать им какие-нибудь ключевые слова, объекты, наследования и т. д. Тоже самое происходит с Terraform. В Terraform можно описать все, где есть API и есть зависимости.
Если у вас много свободного времени, то можете посмотреть список провайдеров по данной ссылке и представить, какую часть инфраструктуры в своей компании вы можете автоматизировать. На вскидку могу сказать, что весь процесс создания, когда кто-то приходит в компанию, и вы ему создаете email, создаете доступы в GitHub-репозитории, доступы в Jira. Это все в нормальных компаниях автоматизирован с помощью одного pull requests в Terraform. И точно так же происходит при создании.
Если вы начинаете учить Terraform, то я рекомендую всего лишь 3 ресурса:
Terraform.io — почитать документацию, потому что документация дает информацию о том, что существует.
Learn.hashicorp.com — потом потыкать это здесь.
Terraform-best-practices.com — когда вы уже узнали, что есть 100–500 фич разных в Terraform, вы попробовали из них половину, поняли, что что-то тут попахивает и начинаете думать, что есть best practices. Вы пишете в Google «Terraform best practices» и попадаете на мой сайт.
Я этот сайт написал, потому что люди спрашивали меня: «Как это сделать правильно?». Люди спорили — best practices это или нет. И понял, что best practices — это то, что опубликовано на сайте terraform-best-practices. Я так и сделал. Т. е. написал то, что я считаю самым важным. Например, как структурировать код, какие основные фичи в Terraform и вообще при работе с инфраструктурой как код надо учитывать. Я написать еще кучу примеров кода, как это работает для маленьких, для средних, для больших и очень больших компаний в зависимости от количества ресурсов, провайдеров. И я написал это, потому что мне не хочется, чтобы люди делали что-то неправильно.
Теперь, спустя полтора года, люди туда заходят в большом количестве и очень мало людей сопротивляется. Очень мало людей мне говорит: «Ты не прав тут», т. е., пожалуйста, если кто-то не согласен с тем, что там написано, напишите на email или откройте pull request и скажите, что так не работает. Потому что там есть места, которые уже не работают, потому что работали полтора года назад. С тех пор я кое-что там изменил.
Можете изучать эти ресурсы. И важно, чтобы вы понимали, что весь функционал Terraform — это не то, что надо вашей компании. И это, пожалуй, один из важных моментов, который я хочу сегодня донести в докладе. Потому что Terraform очень большой проект, если его весь использовать, то того и гляди вы еще work space начнете использовать.
Что это знает?
В Terraform 0.11 выглядели вот так конфигурационные файлы, т. е. мы описывали инфраструктуру. В данном случае мы создаем s3_bucket.
В Terraform 0.12 все вот так вот. Это все, что надо знать. Оно и так будет работать. Но меняется то, что меньше надо символов писать.
https://www.hashicorp.com/blog/announcing-terraform-0–1–2-beta
Там еще есть куча фич. Можно использовать циклы; динамические блоки, где правильно вычисляются условные операторы, где левая и правая часть не вычисляются одновременно.
Если вы использовали Terraform 0.11, то вы, наверное, помнили тот ужас, когда надо было написать выражение, которое и в try, и в false было адекватно правильно написано. И это одна из тех фич, которая мне сделала жизнь сложнее. Correct conditional operators означает, что если выражение истина, то берется левое значение, если не истина, то правое значение. Я поддерживаю большое количество Terraform AWS модулей. И вот эта конкретная штука сделала мою жизнь сложнее.
Почему? Как было раньше? У меня есть 100 -500 ресурсов, которые создаются в зависимости от разных условий. И когда я запускал Terraform plan, Terraform apply в своих тестовых environment, мне не так важно было проверять левую часть отдельно от правой части. Мне главное, чтобы это выражение не содержало ошибок и все. Сейчас мне надо писать test cases для двух разных условий: когда левая часть проверена и правая часть проверена отдельно. Т. е. мне надо писать в два раза больше кода и надо в два раза больше думать. А я люблю, когда Terraform думает за меня. Т. е. я люблю, когда Terraform проверяет значения и выдает какой-то вид ошибки без моего участия, а именно, когда я делаю код review, мне не надо запускать этот код в голове.
Много всего появилось. Все классно. Если вы следили за тем, как появлялся Terraform, т. е. вот этот блокпост на сайте HashiCorp появился примерно за полгода до релиза. И очень много людей думали, что сейчас Terraform 0.12 родится, и мы заживем.
Он родился спустя полгода. За это время было много гневных комментариев от людей в Твиттере, что HashiCorp — плохая компания, потому что она анонсировала, а продукт не готов. Люди были очень расстроены. Это реальность жизни в open source.
https://www.terraform.io/upgrade-guides/0–12.html
Для тех людей, которые хотят обновить с 0.11 на 0.12 вот это самый важный слайд.
Во-первых, есть upgrade guide, где описано, что конкретно поменяется в коде, на что надо обращать внимание, как запускать. Все там классно написано. Если вы прочитаете, то я на 90% уверен, что миграция у вас пройдет гладко.
Если есть проекты или части проекта, в которых вы не можете использовать Terraform 0.12, но можете использовать 0.11 последней версии, то у вас есть возможность читать Terraform state файлы, созданные версией 0.12. Это основное отличие в самой распространенной ситуации, когда вы обновили что-то, а потом пытаетесь использовать старую версию, а вам говорят, что этот state файл был создан новой версии, пожалуйста, обновите это.
В данном случае это решено специально для того, чтобы была возможность плавно мигрировать части инфраструктуры. Какая-то часть уже на 0.12, а какая-то часть на старой версии, до которой руки не дошли или которую вы собираетесь удалить, поэтому вам не надо ее переписывать.
https://github.com/tfutils/tfenv
Если вы хотите контролировать версии, то есть такая утилита как tfenv. Тут все просто.
https://www.terraform.io/docs/configuration/terraform.html
Есть возможность указания версии провайдеров, о которой не многие знают, хотя она написана в документации. Можно указывать версии того провайдера, в котором работает ваша архитектура. Как часто делают люди? Берут провайдер-блок. Допустим, провайдер AWS. И там написан регион, и там же указана версия провайдера. Можно так делать. Но когда у вас есть один Terraform-блок, то вы выносите в самый верх своей инфраструктуры. И там указываете все свои зависимости. Так намного проще работать.
Если вы обновились, а потом подумали: «Ой, кошмар, что я сделал?», то вот такую команду запустите и она вам вернет предыдущий Terraform state файл поверх того, что у вас сейчас есть. Эта команда спасла не один проект.
Теперь поговорим о том, как структурировать Terraform конфигурации и вообще, как с этим жить.
Когда мы написали все в ресурсах, потом мы осознали, что есть Terraform модули, потому у нас есть куча Terraform моделей. И мы начинаем думать, как их вызывать.
Есть такой способ, как all-in-one, когда мы в tf файлы запихиваем вызовы Terraform-модулей. И преимущество у такого подхода заключается в том, что нам нужно меньше объявлять переменных, меньше outputs. Но когда мы работаем с таким проектом, у нас refresh занимает много времени, plan тоже занимает много времени. И мы работаем с инфраструктурой как с одним большим целом.
Второй способ — это, когда мы делаем 1-in-1. Таким образом у нас намного меньше вызов. И когда мы работаем с каким-то конкретным стеком, мы можем перейти в ту папку и сделать какие-то изменения, и все. Мы работаем в довольно изолированном виде, все намного быстрее.
Представьте свой проект на работе. Как он выглядит: all-in-one или 1-in-1? Многие, когда я задаю этот вопрос, думают, что all-in-one — это кошмар, а 1-in-1 — норма.
На самом деле MFA (Most Frequent Answer) — это посередине.
Потому что, когда начинаем работать над каким-то проектом, у нас есть несколько вариантов. Мы либо идем в Google и спрашиваем: «Google, дай мне какой-нибудь готовый кусок кода, который я сейчас сюда вкину», либо идем на terraform.io, берем оттуда какой-то проект и прикручиваем его к себе — all-in-one. Мы потом берем другие ресурсы, подключаем это все вместе. Запускаем Terraform plan 20 раз. Мы начинаем работать с all-in-one.
Потом мы понимаем, что вот эта целая штука, которая была all-in-one закончена, она тесно между собой связана. Мы это делаем, допустим, как модуль. И дальше уже встраиваем либо в другой проект, либо в другой environment. Т. е. как-то стараемся это переиспользовать.
А структура 1-in-1 является классным примером, когда у нас есть уже готовые куски кода. Например, мы зашли Registry на сайте terraform.io, взяли готовый VPC-модуль. Понятно, что мы его не будем переписывать, дописывать, расширять. Мы будем его просто использовать. И когда у нас есть возможность что-то готовое использовать, намного удобнее работать. Это 1-in-1.
Также, если у нас есть возможность или необходимость разделять это между разными командами или разными программистами внутри одного проекта, когда кто-то из программистов является писателем Terraform-кода, а кто-то не хочет вникать, как он написан, а просто хочет его использовать.
Также, если вы знаете, что такое Terragrunt, то 1-in-1 для этого.
Какой тип окристрации между модулями вы знаете?
Представьте, что у нас есть проект all-in-one. И мы пишем Terraform plan. Ждем 15 минут. Он весь интернет сканирует. Потом мы видим, что там какой-то ресурс должен быть изменен. Мы запускаем Terraform apply, ждем 15 минут, пишем «Yes», все классно.
Потом мы понимаем, что есть такой вариант, как main targets. Мы пишем terraform apply -targets = module.vpc. И вся наша область деятельности ограничена только модулем VPC. Также мы можем написать оболочку, shell-скрипт, makefile, PowerShell и это будет как-то подсказывать Terraform, какие аргументы передавать, либо какие war-файлы загружать, либо какие таргеты использовать. Многое чего можно делать.
Если мы используем 1-in-1, то примером такого mikefile может быть следующее. Мы можем запустить Terraform apply в одной папочке, потом перейти в другую папочку и запустить Terraform apply еще раз. И вот так последовательно это будет запускаться. Т. е. мы заходим в самый верхний уровень, пишем make terraform apply и ждем какое-то время. И все изменения применяются.
Какие еще варианты бывают? Да, мы можем использовать state файл как input для другого скрипта. Это, по сути, реализовано внутри shell-скрипта, который занимается тем, что создает инфраструктуру в одном месте. Потом, когда переходим в другую папку, запускаем Terraform apply, и там используется data-source для того, чтобы прочитать Terraform remote state из известного места. Это тоже способ. Так или иначе это все ограничивается shell-скриптами, makefiles.
А как вам такой вариант? Кто хочет так использовать? Он же работает. Можно до бесконечности все усложнять. Terraform используется для запуска Terraform.
Не надо так делать, конечно. Это плохо. Почему это плохо? Потому что Terraform предназначен для линейной работы. Т. е. мы отредактировали один файл, запустили команду «Terraform apply». Подождали чуть-чуть, увидели результат. Потом зашли и изменили снова этот файл, снова запустили команду.
Все время, когда мы хотим сделать Terraform чуть умнее, чем он был изначально запланирован, этим очень легко выстрелить себе в ногу. Это один из примеров.
Есть такая штука, которая называется Terragrunt. Это чуть получше.
https://github.com/gruntwork-io/terragrunt
https://github.com/antonbabenko/terragrunt-reference-architecture
Основная цель этой утилиты — это помочь пользователям Terraform легче обращаться с Terraform-модулями.
Основной компонент, который используется внутри Terragrunt, это Terraform-модули. Не индивидуальные ресурсы, не настройки, а именно Terraform-модули. Terragrunt апеллирует исключительно Terraform-модулями.
Его можно расширять до посинения, но не надо. Terragrunt работает только как оркестратор именно этих инфраструктурных модулей.
Можете почитать документацию, посмотреть код, нажать «star» на GitHub, там уже больше 3 000 звездочек. Это значит, что людям этот проект нужен. И это здорово.
Единственное, что не здорово, это то, что это отдельный проект. Но об этом чуть попозже.
Если вы почитали документацию и думаете, что это сложно начинается, то вот вам еще одна ссылочка со всеми фичами. Я в этот проект Terragrunt-reference-architecture вкинул все фичи, которые я использую на настоящих проектов. Это настоящий проект, я только поменял название заказчика. Все зависимости, все файлы, все папки там есть. Советую посмотреть, если вы сомневаетесь или пытаетесь начать с нуля и можете наломать своих граблей, а потом расстроиться.
Вот это конфигурационный файл в Terragrunt. Файл с расширением .hcl. Вы можете заметить, что он чем-то похож на Terraform файл, но он со своими расширениями.
Основная строка 3 указывает, какой версии модуль взять. И блок inputs на 14-ой строчке указывает, какие аргументы передать в этот модуль. По сути, это все, что надо знать о Terragrunt.
План действий: вы заходите на registry, находите модуль. Пишите, какой модуль вы хотите использовать в строке 3. Читаете документацию, какие параметры принимает этот модуль. Пишите их в строчке 14. Нажимаете terragrunt apply и все.
Вам не надо знать ни Terraform, ни то, как он взаимодействует с ресурсами. Самое главное вам не надо разбираться, почему в AutoScaling модуле около 200–300 строк, что они там делают.
Вам надо понимать, что есть самый низкий уровень, это когда вы смотрите в исходники Terraform, AWS SDK, либо, когда вы смотрите повыше уровнем.
Если я работаю с людьми, которые не знают специфику Amazon, DevOps, инфраструктуры, то я всегда их отгораживают от Terraform-внутренностей. Максимум, что я рекомендую им смотреть, это: скажи мне какой модуль и какие значения передать.
Но не волнуйтесь: Terragrunt вас не заменит, никто вас не уволит, даже если вы будете это использовать, для вас всегда найдется работа.
Есть много разных фич внутри Terragrunt. Самая важная из них заключается в том, что есть возможность запуска hooks до и после определенных команд. Таким образом можно расширять функционал до бесконечности. Другое дело, когда вы будете слишком много hooks добавлять, вы сами споткнетесь в них и будет уже сложнее работать. Но один-два hooks ничего плохого не сделают.
И также есть возможность указания зависимости. На этом слайде в строчке 10 указано, что для того, чтобы создать autoscaling group, нам надо создать VPC. Где находится код для создания VPC? В строчке 11 указано, что он находится в папке VPC. Для того чтобы создать autoscaling group, нам надо взять список public subnet и передать его в этот список. Это делается на строчке 20 указанием dependency.vpc.outputs.public_subnets.
Наверное, кто-то думает: «А зачем так делать, если можно использовать data-source и data-source«м брать какое-то значение из state файла?». Преимуществом в том, что внутри используется нативный terraform output. Что делает Terragrunt? Он переходит в папку, которая указана тут (.vpc) и там запускает terraform outputs.public_subnets. Получают список subnets и подставляют вместо этого значения dependency.vpc. Таким образом здесь указана мягкая ссылка в значении vpc_zone_identifier. И это значение будет получено без использования data-source и т. д.
Также есть возможность запуска конфигурации на самом верхнем уровне. Если у вас инфраструктура описана как 1-in-1, когда у вас есть куча разных блоков, то вы, конечно, не хотите заходить в каждый блок и писать terragrunt apply, и ждать, пока что-то произойдет, нажимать «Yes» и т. д. Можно зайти в папку уровнем выше и написать terragrunt apply all, тогда он проверит все папки, которые внизу, поймет от какой папки зависит. И спросит: «Действительно ли ты хочешь это сделать?». Нажимаем «Да». И таким образом он создает все, что надо.
Также в Terragrunt есть поддержка pre-commit. И pre-commit hooks позволяют валидировать синтаксис Terragrunt конфигов, а также обновлять документацию.
Есть такой веб-сайт, где написана документация. Можете почитать, если разберетесь. По-моему, она сейчас написана очень плохо. До этого она была в одном файле, в котором можно было искать. Сейчас ее впихнули в красивый веб-сайт, на котором ничего не понятно.
Да, есть и плохое в Terragrunt, например, Terraform Cloud. Что это значит? Terragrunt работает здорово, когда у вас есть доступ к тому месту, где вы его запускаете.
Если вы хотите использовать Terraform Cloud, то Terragrunt тут не поможет вам. Terraform Cloud стоит много денег. И функционал, который он представляет, стоит от 0 до 70 долларов за человека в месяц. По-моему, это много денег.
И даже если прочитать документацию, проникнуться и сказать, что Terraform Cloud — это классно, а потом у вас закончатся деньги, то вы не сможете легко мигрировать в open source. Есть определенный функционал, который доступен в enterprise. Он классный, но его нет в open source версии, поэтому вам надо будет писать большое количество shell-скриптов. И опять-таки workspaces. Они работают по-разному в open source версии и в enterprise, поэтому их лучше вообще не использовать.
Что такое workspaces?
Представьте, что у вас есть одна папка с конфигурацией Terraform, вы запускаете Terraform apply. Создается там инфраструктура, все классно. И тут вы думаете, что я хочу создать эту же инфраструктуру только с чуть-чуть другими значениями. Для этого вы пишите «Terraform workspaces new» и переключаетесь на другой workspace. Потом вы пишите «Terraform plan». И Terraform plan говорит: «Я не знаю ни про какие ресурсы». Т. е. у вас есть ресурсы, которые в дефолт workspace, которые вы уже создали, и какой-то новый workspace. Новый workspace вы только создали, поэтому там ничего нет. В этом возникает 100 проблем.
Первая проблема — это то, что workspaces никак не отражены в коде. Можно написать shell-скрипты, посмотреть в bucket по названию, по имени файла догадаться.
Вторая проблема — для того чтобы правильно работать с инфраструктурой в зависимости от workspaces, в значениях должны писать условие. Например, если Terraform.workspaces = prod, то значение 5, иначе 25. Хорошо, вы так сделали для двух значений. Потом вы осознали, что у вас есть 5 environment и вы, конечно, используете lookup функцию. И берете lookup из ассоциативного массива по ключу, который называется Terraform workspaces. Все классно, вы сами себе усложняете жизнь.
Дальше приходит Вася и спрашивает: «Когда этот workspaces был задеплоен? Этот код в production или QA environment?». И вы: «Не знаю, надо спросить в slack». Начинается кошмар. А потом кто-то спрашивает: «А какая разница между staging и production environment в конфигурации?». На эти вопросы вы не сможете ответить мгновенно.
Смысл работы с инфраструктурой как код в том, что, когда вы открываете файл, то как можно быстрее и в нужном месте вы видите все значения без запуска Terraform в голове. Раньше мы открывали файл Terraform.tfvars, чтобы посмотреть, какие значения там указаны. Мы видим там версии, instances. У нас есть представление.
Когда мы используем workspaces, то мы как бы размазываем информацию по всему. Мы размазываем ее по S3_bucket, в разных state файлах она будет хранится.
И самое главное, мы вводим еще одну ось. У нас есть ось времени и сложности. И мы: «Нам этого мало, мы введем еще одну ось, которая называется workspaces name». И мы уже можем запутаться.
Основная плохая штука в workspaces заключается в том, что workspaces — это просто ненужный функционал. Можете со мной поспорить. Если вы работаете с workspaces и не потратили на работу с workspaces достаточно много времени на написание shell-скриптов, AWS-утилит, которые смотрят, подчищают ресурсы, то вам это все еще предстоит.
Есть один единственный use cases, когда workspaces имеют смысл. Я его специально сюда не написал, но я о нем иногда рассказываю. Я его не написал, потому что люди начнут говорить, что раз я его написал, значит его можно использовать.
Этот use cases имеет смысл, когда у вас есть инфраструктура, которая живет в течение всего pull request. Т. е. у вас открылся pull request, вы переключили на какой-то workspaces, создали временную инфраструктуру, задеплоили туда что-то, отправили эту ссылку в GitHub. Кто-то посмотрел, что там произошло, смержили код. И удалили эту инфраструктуру, и удалили workspaces. Таким образом, эта инфраструктура заведомо создана, чтобы быть удаленной. Для этого надо написать кое-какие утилиты. И тогда есть смысл брать инфраструктуру, которая задеплоена для production environment и просто переключать workspaces.
Я могу еще экстремальный use cases подсказать. Есть такой бэкенд, который нигде не задокументирован. Он называется inmem. Это следующая стадия за workspaces. Т. е. когда мы создаем workspaces и создаем ресурсы, то они хоть как-то где-то отражены. Если вы не хотите париться, что есть такое понятие, как Terraform state, то можете указать Terraform backend configuration type и там inmem (в памяти). Документации на официальном сайте нет, но это работает.
Решением для большинства проблем с workspaces является то, что мы делаем код, с которым работаем, более повторяющимся. И мы используем модули, конфигурация которого хранится в файле или отдельной папке, вместо излишней магии, которая называется workspaces. Таким образом, у нас есть workspaces, которые вы создаете для чего-то временного. Можно создать папку, которая называется Feature 1. В нее положить код, запустить terraform apply. Создать это все, закоммитить это все. И когда у вас эта фича отжила, написать terraform destroy.
Смысл в том, что ваш репозиторий, который содержит всю инфраструктуру, должен отражать полностью все то, что у вас происходит.
Terraform workspaces никак не отражены в коде. И это большая проблема. Я не могу посмотреть в код и сказать, что у нас есть 20 сервисов таких, 10 сервисов таких. Когда вы используете не workspaces, много проблем можно избежать. Используйте модули и будет счастье.
Вот этот сл
