[Системное администрирование, IT-инфраструктура, Amazon Web Services, DevOps] Terraform 12 и Terragrunt и как это можно применять для Multi-Cloud-инфраструктуры. Александр Довнар

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
02-Дек-2020 13:32

Цитировать

Что такое Terraform 12 и Terragrunt, и как это можно применять для Multi-Cloud инфраструктуры.
Мы поговорим про IaC (Инфраструктура как код) влияние на современный мир и о том, как Terraform помогает работать с гетерогенных окружениях.Я хочу обсудить немного сам Terraform, какие у него есть проблемы и как их решает Terragrunt. После я расскажу про мой опыт с Terragrunt и немного зацеплю такую тему, как Multi-Clouds.Во второй части обсуждения темы я бы хотел показать результат моих находок в использовании Terraform+Terragrunt в среде с тремя облачными провайдерами (AWS, GCP, Azure) и CloudFlare в качестве DNS.
Извините, данный ресурс не поддреживается. :(

(Александр) Сегодня я хочу рассказать о том, как у меня получилось сделать Multi-Cloud deployment с помощью Terraform и Terragrunt, а также о том, как это работает в частности и в отдельности.
(Виктор) Круто! Я знаю, что Саша подготовил вопросы. И по традиции перед каждым докладом мы запускаем quiz. Я думаю, что этот quiz вам будет полезен с точки зрения того, чтобы понять все ли вы знаете про Terraform и будет ли вам интересен этот доклад.

Я предлагаю сейчас запустить quiz. И, может быть, вместе с тобой, Саша, посмотреть на вопросы, которые ты сам же придумал.
Обращаю внимание, что поучаствовать в quiz можно на нашем канале в Телеграме, в DevOpsMinsk Chat. Там запускается бот. С этим ботом можно подружиться и взаимодействовать.
Итак, quiz. Я буду читать вопросы и комментировать.
Terraform – это:

Инструмент configuration management.
Монетизация HashiCorp.
Infrastructure is code.
Infrastructure as code.

Terraform используется для описания инфраструктуры HCL. Что такое HCL?

(Александр) HashiCorp Configuration Language. Это то, как описывается инфраструктура. Это разработанный синтаксис самим HashiCorp.
(Виктор) Можно ли HCL быстро сконвертировать в YAML. Мы здесь почти все YAML-Developers.
(Александр) Да и обратно.
(Виктор) И оно достаточно хорошо работает даже несмотря на все последние изменения? Я знаю, что они зарелизили HCL 2.0.
(Александр) Как раз в HCL 2.0 появились удобные фильтры: YAML encode, decode и JSON encode, decode, которые позволяют конвертировать между тремя форматами достаточно просто. Это делается в первую очередь внутри самих продуктов HashiCorp.

Какой тип ресурсов позволяет информацию о существующей инфраструктуре VPC или VM info:

Backend.
Query
DataSource.
Filter Source.

Часто ли в практике приходится использовать DataSource?

(Александр) Да, потому что часто нужно запросить такую информацию, которая не под Terraform. Например, мы хотим покрыть нашими subnets в Amazon все доступные availability-зоны. Мы можем использовать специальные DataSource, которые нам дадут все доступные на данный момент availability-зоны. С помощью exclude, include мы можем этим манипулировать и использовать этот список в своем Terraform-коде.
(Виктор) И в том числе, если какая-то инфраструктура по тем или иным причинам была создана руками, мы можем с ней взаимодействовать, используя DataSource?
(Александр) Все верно.

Как с помощью Terraform пересоздать ресурс без изменения конфигурации?

Terraform taint
Terraform destroy.
Terraform apply.
Terraform plain.
Terraform refresh.

Поясни, что делает taint.

(Александр) Taint как раз и нужен для таких целей. По сути, он помечает ресурс как то, что должно пересоздаться. Допустим, надо пересоздать машину. Но у нас в ней конфигурация не меняется. Мы делаем taint этого ресурса. И при следующем запуске Terraform, он для себя будет понимать, что ее надо пересоздать, потому что мы этого захотели.
(Виктор) А если в ресурсе, который мы хотим пересоздать, например, в виртуалке, есть какие-то зависимые вещи? Например, диски мы подключаем, интерфейсы настраиваем или что-то еще. Он контролирует только сам этот ресурс или еще пересоздаст?
(Александр) Если мы будем запускать полноценные plan, apply, то такие вещи, как диск, который аттачится к машине, тоже будет обновлен, потому что в нем поменялась машина, на которую он аттачит. И ID каждый раз будет новым.
(Виктор) Результат нашего quiz. Человек за 19 секунд ответил на 5 вопросов. Это Экссметана. Мы с тобой свяжемся. Промокод на пиццу будет передан. И судя потому что человек смог ответить на 3 вопроса правильно, а все остальные еще меньше, то я думаю, что доклад должен быть интересен. Саша, передаю тебе слово.
(Александр) О чем я хочу рассказать? Хочу рассказать о том, что такое Terraform, Terragrunt и как это все можно использовать как для Multi-Cloud deployment, так и для любых других задач.

Для начала я расскажу немножко о себе:

Меня зовут Саша. Я работаю в компании EPAM Systems как lead systems engineer.
В DevOps-мире я чуть больше 4 лет.
До этого я еще 6 лет работал в крупнейшем в Белоруссии Интернет-Сервис провайдере.
Automation fanatic – это очень громко сказано, но я сам для себя понимаю, что автоматизировать вещи лучше, чем делать это руками, потому что я сам допускаю в этом много ошибок и пытаюсь всех других от этого уберечь. Я стараюсь людям об этом рассказывать.

О чем мы сегодня будем говорить?

Для начала я хочу рассказать, зачем я тут и что я буду рассказывать в деталях.
Потом немножко пробежимся по теоретическим аспектам, т. е. о том, что такое Terraform, Terragrunt и Multi-Cloud. Расскажу, что это такое и зачем это надо.
Далее я покажу небольшое демо, которое я подготовил в рамках данного доклада.
И я расскажу о том, что из этого получилось. Поделюсь своими впечатлениями.
Q&A.

Это QR-соды, которые позволят ориентироваться по ходу доклада. Можно посмотреть на исходный код. Также сейчас задеплоен PreProd Demo site. И в рамках нашего доклада мы будем деплоить production. Можно ссылочки открыть и увидеть, что там есть. Я потом чуть подробней об этом расскажу.

(Виктор) Ребята, у вас есть возможность открыть код и вместе с Сашей, когда он будет запускать демо, смотреть и понимать, что происходит.

Саша, у меня еще один вопрос, который я не успел задать. У тебя в названии написано «Terraform 12». А вроде бы даже первого релиза не было. Почему так?

(Александр) Сейчас релиз Terraform, если по семантике версионирования смотреть, он 0., т. е. 0.11, 0.12, и грядет 0.13. Причина в том, что HashiCorp, как компания, имеет достаточно жесткие требования к релизу, который готов быть 1.0. Я об этом чуть позже расскажу, когда буду говорить про Terraform.

Я покажу слайд из последнего доклада HashiConf, где как раз был такой вопрос. И там немножко расписано на примере Packer. Это другая утилита от HashiCorp. И там расписано, что нужно для того, чтобы в HashiCorp сказали, что она готова быть 1.0. Я для упрощения убрал нолик, но подробней об этом мы чуть позже поговорим.

(Виктор) Судя по тому, сколько уже Terraform существует, он уже действительно, скорее всего, уже 12-ой версии.
(Александр) Именно так.

Небольшой дисклеймер, т. е. тот исходный код, который вы видели, нужен только для того, чтобы сделать это демо. Какие-то вещи там можно использовать для реальных проектов. Я постарался максимально раскрыть функционал и возможности, которые есть как в Terragrunt, так и в Terraform с точки зрения модулей и Multi-Cloud взаимодействия. Но это не real production, т. е. всегда вчитываться и переносить в environment ваш проект надо с большой аккуратностью.
И также вы можете задавать вопросы в Телеграме, на которые мы постараемся ответить. И также можете по моим контактным данным меня найти и задать вопрос, я всегда рад помочь. Я готов делиться знаниями и опытом.

Начнем с того, почему я здесь.

Виктор мне предложил рассказать про Terraform. Мне это интересно. Я давно хотел получить подобный опыт. Мы совместно с ребятами выбрали эту тему, потому что она более интересная и максимально раскрывает все грани.
Цели, которые мы ставим, следующие:

Мы хотим задеплоить какую-то инфраструктуру в 3 clouds: Amazon, Azure и GCP. И хотим вместе их соединить, и показать, как они вместе могут работать. Это один из вариантов deployment-стратегий, когда мы деплоим в 3 clouds для большей доступности и возможного катаклизма, когда один из трех выйдет из строя.
Также я хочу показать, как в этом помогает Terragrunt. Расскажу зачем он нужен.
И хочу поделиться своим опытом, потому что это все писалось с нуля в рамках подготовки. И этот опыт достаточно интересен.
Из challenges, с которыми я столкнулся:
Работать с Azure я практически не умел. Я его знал только по тому, что это Microsoft. И я поделюсь своими отзывами.
И также я постарался сделать такую инфраструктуру, которая будет бесплатной. Я сделал free tier в AWS и в GCP. Azure у меня был, поэтому приложение достаточно примитивное.

Давайте немножко поговорим о теоретическом аспекте. Т. е. о том:

Что такое Multi-Cloud.
Что такое Terraform.
И зачем нужен Terragrunt, если и так есть Terraform.

О Multi-Cloud, я думаю, слышали многие. Из названия понятно, о чем это. Это несколько облачных решений. И он вроде есть везде, но его нет нигде.

(Виктор) Я бы немножко по-другому сказал: о нем говорят все, но его никто не видел.
(Александр) Да.
По моему опыту, в основном Multi-Cloud выбирают в том случае, когда хотят максимально избавиться от vender-lock, потому что любой cloud представляет manage-сервис, который удобно активно использовать. И, как правило, уход из одного cloud в другой по каким-либо причинам становится очень дорогим. Поэтому многие компании об этом задумываются, многие уже начинают это делать.
Следующий момент – это помощь IT. Часто в больших enterprise-компаниях случается ситуация, когда какая-то команда, которая занимается разработкой и улучшением продукта, понимает, что они хотят использовать сервис в Google Cloud, поэтому это будет быстрее и дешевле. В случае наличия Multi-Cloud на месте, где у нас есть вся нужная обвязка, есть аккаунты, легче предоставить sandbox в Google Cloud, когда команда это хочет. И это получается быстрее и дешевле, как правило, чем начинать это все заново и говорить: «Нет, делайте это все в Amazon».
С Performance and resiliency все понятно. Нам нужен performance или сервис, который лучше работает в Google Cloud или нам нужен Active Directory Management Service, который работает отлично в Azure. И тогда мы разделяем наш сервис по нескольким облакам. А также это может быть гибридным облаком. Все зависит от конкретного сценария.
И последний немаловажный пункт, особенно для Европы и Америки, это Compliance, т. е. соответствие с регламентами, когда нам нужно хранить пользовательские данные в какой-то локации, а регионального в Amazon нет, но он есть в Azure или, наоборот, он есть в Google Cloud, но нет в Azure и т. д.
(Виктор) Добавлю маленькую ремарку. Это касается не только Америки и Европы, а также всех стран, которые движутся. Даже у Канады очень похожие законы, что, если что-то sensitive, то обязательно должно хранится только на территории страны. И в том числе в России, когда AWS нет, проекта там не будет под AWS.
(Александр) Скоро будет.
(Виктор) Да, обещали, я тоже слышал эту новость.
(Александр) Но, наверное, неправда, потому что это будет интеграция.
(Виктор) Да, mail.ru.
(Александр) Все боятся. Ладно, mail.ru, наверное, тоже хорошие предоставляет сервисы. Но не удалось с ними поработать, к сожалению.

Какие challenges у компаний есть?

В первую очередь – это дорого как с точки зрения инфраструктуры, так с точки зрения специалистов, потому что найти человека, который умеет в Amazon легко, найти человека, который умеет в Google достаточно просто, с Azure тоже просто, но найти того, кто умеет и там, и там, и причем хорошо – очень сложно. Поэтому это либо большой департамент разноплановых специалистов, либо какие-то единороги, которые знают все, но они, наверняка, недешевые, потому что они единороги.
И требуется определенная готовность компании к этому, потому что надо иметь налаженные процессы, надо иметь нормальную культуру DevOps, которая позволяет все это делать быстро, удобно и хорошо. И чтобы не было такого, что кто-то создал виртуалку максимального size, и она год нам пишет деньги, а ей никто не пользуется. Без автоматизации соваться в Multi-Cloud, по мне, не стоит. Но это лично мое мнение, оно может быть не совсем корректным.

Про Multii-Cloud у меня все, я хочу сейчас больше времени уделить Terraform, потому что в том, о чем я говорю, он играет достаточно ключевую роль.

Ты спросил, что такое HCL. Это HashiCorp Configuration language.
Для чего он нужен? Для того чтобы унифицировано иметь возможность описать инфраструктуру, либо абстрактные инфраструктурные компоненты, как например, Kubernetes Name Space с помощью одного языка. И если человек писал на Terraform, то начать писать в Azure на том же Terraform не составляет труда, чем, если бы он переходил с Cloud formation на Azure template. Это достаточно затрудняет такие перемещения. Но в первую очередь HCL унифицирует подход к написанию кода. Понятно, что везде разные атрибуты, разные параметры у всех ресурсов.

Ты правильно заметил, что нельзя написать описание виртуалки, хотя, казалось бы, одна и та же сущность: одна виртуальная машина, какое-то количество дисков, сетевых интерфейсов. И не получается, чтобы одно и то же описание запустилось на всех clouds. Придется все переписывать. И, мне кажется, важно сделать такое уточнение, что HCL – это тоже декларативный язык как YAML, который не совсем создан для того, чтобы писать разветвление, циклы и прочее. Хотя в HCL 2.0 появились очень круты фишечки.
(Александр) В рамках этого доклада я сделал модуль, который унифицирован для трех clouds. Он принимает параметры. И этот модуль можно спокойно использовать в трех местах, в трех clouds. И он деплоится одинаковыми абстракциями.
(Виктор) Один модуль для всех?
(Александр) Да.
(Виктор) И какой ресурс?
(Александр) Все. VPC.
(Виктор) Но все равно у тебя каждый объект описывается по-своему.
(Александр) Внутри модуля да, но я предоставляю уровень абстракции, который позволяет пользователю передать какой-то параметр. Это один из моментов, который я хотел проверить, потому что я так не делал. И, я думаю, что получилось интересно.

Что еще сказать про Terraform? В отличии от всех конкурентов, которые специфичны для каждого cloud, у него есть такой нюанс, что он использует и апеллирует стейтом. Т. е. все, что Terraform сделал, записывает в какой-то state. Обычно это файлик, который хранится в достаточно надежном хранилище типа S3 bucket. И он там хранит все, что он сделал. И в момент выполнения следующего запуска он, грубо говоря, берет код, который вы написали, сравнивает его с тем, что есть в state. И плюс он анализирует то, что есть в облаке, если оно действительно есть. И выстраивает то, что он делает. Он меняет машинку, меняет install stipe и тому подобное.

(Виктор) И здесь важно подчеркнуть один момент. Ты сказал, что надежное хранилище в качестве бэкенде и сказал S3. Мне кажется, что у наших зрителей может возникнуть идея о том, что это надежность с точки зрения durability, что эти данные не потеряются.
(Александр) Да.
(Виктор) Но мне кажется, что очень важно уточнить, что если ты создаешь какую-то базу данных и туда пишет пароль, то в state, он, к сожалению, все еще в открытом виде. И, к сожалению, Terraform в 12-ой версии все еще есть тикет, чтобы ребята с этим поработали, но пока этого нет. И поэтому важно ограничить доступ к этому state-файлу, чтобы он не был доступен для всех. И, конечно, чтобы не потерять durability, это тоже очень важно.
(Александр) Да.

Сейчас Terraform поддерживает, по-моему, около 10 из коробки remote state locations, т. е. от S3 до Cassandra, если я не ошибаюсь.
И это ключевой аспект – Terraform state, потому что если он запустит Terraform с описанием на существующий аккаунт в Amazon или в Azure, то попытается создать. Он ничего не знает о том, что там создано. Можно ему импортировать в state существующие ресурсы, но это отдельная история.
И последний момент – Terraform поддерживает на сегодняшний момент более 100 провайдеров, т. е. концепция Terraform – это определенный механизм трансформации HCL в API-вызовы конкретного провайдера. Т. е. Amazon, OpenStack, Kubernetes, Helm, GitLab‑репозиторий, например.

(Виктор) Т. е. уровень абстракции в виде декларативного описания взаимодействия API с тем, с чем ты хочешь работать?
(Александр) Да, все верно. Все это документируется HashCorp’ом. Есть официально поддерживаемые провайдеры, есть провайдеры, которые кто-то делал, т. е. их можно писать. Но, как правило, мне хватало того, что есть.

О Terraform слышно много всего. И почему именно Terraform? На самом деле я слежу периодически за репортами.

(Виктор) Мы два выпуска назад говорили, что консалтинговая компания Thoughtworks выпускает свой Technology Radar.
(Александр) Да. Что такое Technology Radar? Это анализ того, что есть сегодня на рынке и того, что используется в разных компаниях. И классификация подходов, либо рекомендации по использованию.

И Terraform в прошлом году, когда еще были инструменты в Technology Ragar, он был adopt в том плане, что строго рекомендуется использовать в production для реальных проектов.
В этом году они немножко поменяли концепцию. И от инструментов они ушли. Но есть подход инфраструктуры как код, т. е. когда рекомендуется использовать этот подход, потому что иначе вы рискуете быть не конкурентно способными. У вас не будет возможности все это удобно расширять и этим всем управлять, поэтому данный подход очень удобен. Сегодня все рекомендуется как код.
Сегодня Terraform в топе. И даже многие cloud-провайдеры активно инвестирует в поддержку Terraform-провайдеров. Они от себя выделяют людей и, возможно, департаменты.

(Виктор) Я уверен, что провайдеры в Azure много контрибьютят, чтобы все ресурсы, которые у них есть, поддерживали Terraform, поэтому что это иногда является ключевым фактором для компании при выборе infrastructure as code. Это один инструмент для всего.
(Александр) Да, все верно.

Что еще про Terraform сказать?

На него отлично ложится любой подход программирования. Есть возможность делать модульность. Ты можешь эти модули версионировать.
Если хочешь включать Terraform в CI/CD, то – пожалуйста. Есть всевозможные lints. Они существуют не официально, но они достаточно популярные и хорошо поддерживаемые.
Есть возможность unit-тестирования. Есть возможность интеграционного тестирования.

Подходов море, фреймворков море. Даже сервисов море, которые могут это делать под капотом.
И что является результатом CI? Это артефакт CI и Terraform-модуль, который в результате CI получен и будет версионироваться, и идет как часть приложения при доставке. Это тоже очень удобно.

(Виктор) Ты сказал о модуле, о артефакте. И я почему-то у себя в голове нарисовал, что когда я запускаю CI для Terraform, то это Terraform plan, который формирует тот state, который потом выкинет на бэкенд при apply, но он еще не применился. Т. е. я смогу на него посмотреть и сравнить с тем, что у меня есть. И, мне казалось, что это является тем артефактом, когда я делаю build чего-либо, то у меня получается то, что я буду выполнять. И в Terraform state, который я потом буду эпплаитить на мою инфраструктуру.
(Александр) На самом деле там много инструментов и подходов. Это отдельная тема для доклада. На своем проекте мы полностью реализовали CI для модулей. Это linting, plan, apply, compliance, security. И все это прогоняется на основе модуля.
(Виктор) Я понял.
(Александр) И расширять это можно бесконечно. Все зависит от требований продукта на конкретном проекте. Мы можем использовать … и результаты выполнения Terraform в наших процессах безграничны. Все зависит только от нашей фантазии. Terraform вроде бы очень простой, но в то же время он дает достаточно большое поле для творчества. Можно расширять своими tools, используя его в output. Можно включать эти outputs в какие-то процессы и т. д.

Тут нет best practices, но есть возможность. И она достаточно большая. И в этом большое отличие, потому что я, например, не знаю, как cloud formation template можно протестировать без Amazon, т. е. просто статический код проанализировать. Возможно, какие-то инструменты есть, но я не работал достаточно плотно с ним. Может быть, кто-то подскажет из аудитории.

Я тут украл цитату у Антона Бабенко. Это достаточно интересный контрибьютор в мире Terraform. На докладе, который он озвучивал в Минске, он рассказывал о том, что условно можно выделить 2 типа пользователей Terraform.
Это:

Terraform-разработчики, которые понимают, что такое HCL 2.0 и которые понимают, что там писать.
Люди, которые хотят получить какой-то модуль, чтобы дать туда параметры и получить инфраструктуру.
(Виктор) Скорее, хотят получить не модуль, а результат как можно скорее, не заморачиваясь с точки зрения того, что там под капотом. И при этом быть на самом высоком уровне абстракции. Грубо говоря, я хочу 15 виртуальных машин с одним load balancing и все.
(Александр) Все верно. Т. е. первые предоставляют вторым возможность это делать.

И дальше я буду рассказывать об отличиях 11-го и 12-го Terraform. И это больше про разработку, т. е. для тех, кто просто потребляет Terraform как пользователь, это все не нужно. И, по сути, им незачем это знать.

На экране сейчас есть базовый пример кода на 11-ом Terraform, где отображена моя самая большая боль.
Первое – это синтаксис интерполяции, когда мы берем переменные, либо функции и мы вынуждены их обрамлять в фигурные скобки с долларом и в кавычках. И если честно, то мне это доставляло много дискомфорта. И часто синтаксические ошибки прилетают как раз из-за этого, потому что бывают очень сложные строки с экранированием. Наверное, на это многие натыкались.

(Виктор) Мне кажется, что в 12-ой версии все равно остались доллар и скобка. Это осталось для того, если тебе нужно что-то обработать, т. е. не просто переменная, а когда тебе нужно что-то получить.
(Александр) На данный момент это используется только в строках, т. е. ты в строке хочешь вставить переменную и тогда ты используешь интерполяцию. Для всего остального это убрали. И я чуть позже об этом расскажу.

И достаточно серьезный такой момент в том, что API всех clouds, в частности Amazon, очень сильно меняются. И они заточены, как правило, на определенную структуру API-вызовов. И в силу этого Terraform 11-ой версии был ограничен. И когда мы хотели создать security group и разрешать какие-то порты декларативно, тогда нам приходилось на 11-ом Terraform это хардкодить. Нам нужно было в ingress rules записывать. И если у нас было 2 environment, где в одном мы хотели разрешить 25 порт, а во втором 22-ой, то мы уже не могли использовать один и тот же модуль. Нам приходилось в этом модуле писать 2 ресурса, которые от каких-то условий будут зависеть. И это достаточно неприятный аспект.

И следующая болевая точка для многих – это циклы. В 11-ом Terraform были циклы.

(Виктор) Count, по сути.
(Александр) Да, все верно. Но это просто массив. И какая проблема? Например, сейчас на экране есть обычная конструкция. Мы хотим создать несколько rules для security groups. Там описываем лист словарей, где мы описываем порт, описание и т. д.

И вот у нас есть на экране 2 rules и plan. Мы применили, все работает. Завтра приходит кто-нибудь и говорит: «Надо еще порт добавить».

И мы добавляет этот порт не важно куда: в конец, в начало, в середину. Даже если мы это сделаем в конец, то при следующем запуске Terraform не поймет, что мы сделали. И он захочет пересоздать первый rule, т. е добавить нужный новый, но у него сортировка в голове поменяется и он захочет удалить один rule. Это нестрашно, но когда у тебя инфраструктура большая и это уже в prod, т. е. если махнуть шашкой, то можно на какое-то время словить downtime.
Поэтому приходилось лезть в state для того, чтобы что-то править, либо применять в момент maintenance …, но это так себе способ.
И многие на это ругались в GitHub. И два года назад объявили релиз 0.12-ой версии.

(Виктор) По-моему, это было в прошлом году, когда он стал stable.
(Александр) Может быть.
(Виктор) Наверное, 2 года назад он был в beta как сейчас 0.13. Значит, с апреля про него начали говорить.
(Александр) В июне 18-го года. И суть в том, что в 12-ой они пересмотрели синтаксис, т. е. ввели HashiCorp Configuration language 2.0, в котором много чего поменялось.

Чего в первую очередь коснулись изменения?

Во-первых, у нас появились нормальные циклы. У нас появился не только count, у нас появился for_each, который итерирует по сложным объектам типа словарь и по ключам. Таким образом мы можем в качестве ключа выбрать какое-то уникальное значение и при следующем запуске не будет той проблемы, которая была на предыдущем слайде. В случае с for_each у нас есть возможность написать более грамотно.
И плюс убрали интерполяцию. Если посмотреть, то все переменные без фигурных скобок. И мне это привычней, потому что во всех языках обычно переменные используются без кавычек, без каких-то обрамлений, если они указаны без каких-то срок рядом.
И более удобная для Terraform-разработчиков штука – это dynamic-блоки, которые позволяют генерировать структуры, которые раньше заставляли нас хардкодить. Теперь мы их можем генерировать при выполнении плана автоматически. Это очень удобно.

У for_each есть нюансы. В Terraform for_each не умеет вычислять на лету, т. е. for_each на входе должен быть уже известен. Например, у нас должен быть известен key-value объект. И это очень важно, потому что, если мы хотим получить какой-то ресурс, который еще не создался, и эти значения построить в динамическую конструкцию, и скормить это for_each, то Terraform скажет, что я об этом ничего не знаю, давай сначала применяй через таргет отдельную часть. Это проблема известная, тут ничего нового.

В 12-ом Terraform разница очень ощутимая и очень приятная.

(Виктор) Как я понимаю, той боли и убийства какого-то одного rule уже не будет, у тебя появится только новый ресурс, который ты добавил? И в данном случае – это 36 порт?
(Александр) Да.
(Виктор) Соответственно, только 36 порт будет добавлен в наши rules?
(Александр) Все верно.

Есть еще пара фич достаточно серьезных.

Это не только декларативное описание. Появилась возможность встраивать динамические конструкции, чего нет в YAML. Мы можем собирать объекты на лету во время выполнения плана через всякие конструкции типа for, if. Появилось больше функциональных нюансов у HCL, который доступен не только в Terraform, он доступен в любом продукте, который использует HCL. Сегодня это Packer. Это достаточно важный момент.
Также приехали дата-типы. Если в 11-ом Terraform у нас string был string, number был string, boolean был string, то это порождало очень много энтропии, которая очень сильно мешала, потому что 1 и 0 может быть интерпретированы в трех случаях по-разному: где-то это true, где-то это 1, где-то это строка.
Плюс были листы очень примитивные. И словари maps. Сейчас у нас реальный string, реальный number, реальный boolean, которые ты строго можешь прописать. И это более привычно, можно как в других языках апеллировать.
Плюс появились более гибкие возможности пизировать листы и maps с помощью дополнительных типов скобок.
И более того, можно создавать кастомные объекты, в которых ты строго задаешь, какие типы данных в них будут фигурировать.

(Виктор) Может быть, не все знают, что в YAML есть anchors. С помощью них логики не добавишь. Но если у тебя есть какой-то повторяющийся код, то с помощью anchors это можно делать. Поэтому, если вы с этим не знакомы, то крайне рекомендую посмотреть эту штуку. Она бывает весьма полезной. В GitLab CI, в Kubernetes такие вещи можно хорошо завязать.
(Александр) И еще появились null, values. Раньше в 11-ом Terraform дефолтное значение, которое типа ничего, это пустая строка. И из-за этого было много проблем, потому что приходилось сравнивать с пустыми строками. Это было неприятно. Теперь есть null. Null – это null, это ничего, поэтому это более понятно тем, кто пишет код.

Также в 12-ом Terraform в отличии от 11-го теперь нормально работают условия. В 11-ом Terraform было условие: если A равно B, то C, иначе D. И когда 11-ый Terraform выполнялся, он пытался сразу все значения посчитать, а потом сравнить. Т. е. если были какие-то функции, он сначала все считал, потом сравнивал. Из этого выпадали ошибки, как на экране.
В 12-ом Terraform от этого ушли. И теперь условия работают корректно. Если A равно B, то будет смотреться C. Если A не равно B, то будет смотреться D, а C вообще никак не будет вычисляться. Это удобно и дает много преимуществ в разработке, в создании сложных модулей для Terraform.

Terraform 0.13 и 1.0 – это то, о чем мы говорили. На самом деле в июне объявили бета-тестирование 13-ой версии.
Появились такие вещи, как depends_on, циклы для модулей. Раньше этого не было. И от этого все страдали.
И появилась крутая штука – валидация переменных, где можно задать логику, как эти переменные используются. И на момент валидации Terraform-кода Terraform будет проверять проходит ли входное значение эту валидацию. Я это частично использовал в подключаемом Feature flags в моем демо, т. е. можно посмотреть, как это работает, какой cloud верифицируется. Если cloud не AWS, GCP, Azure, то Terraform говорит: «Я не понимаю».
И, как правильно сказал Виктор, Terraform близок к тому, чтобы выйти на 1.0.
Что они хотят?

Они хотят, чтобы это было активно использовано в prod.
Они хотят, чтобы это было secure.
Они хотят, чтобы конечная архитектура уже была ясна.
И хотят, чтобы tool выполнял определенную функцию.

Сейчас Terraform выполняет все. Чтобы сделать 1.0, на мой взгляд, надо более четко сформировать его назначение. Потому что изначально он позиционировался как infrastructure as code. Сегодня и репозиторий можно создавать Terraform’ом, и все, что угодно.

(Виктор) Он может заменить Helm и конфигурирование всех ресурсов в Kubernetes после того, как они заявили о Kubernetes-провайдере.
(Александр) Это неудобно. У меня был опыт, это неудобно. Helm все-таки удобней, потому что на HCL описывать Kubernetes-манифесты – это очень неприятно.
(Виктор) Совсем-совсем?
(Александр) Ты можешь в YAML писать, а потом декодировать, но это не совсем корректно работает. А если в HCL, то получается очень много HCL. И он очень большой. Это не очень удобно. Я для себя пришел к тому, что Helm удобней. Тем же Terraform Helm отлично можно вызывать. Это очень удобно. Ты создал кластер, прокинул load, потому kube-config, прокинул в настройку Helm и ничего не надо делать локально, все из коробки работает.

Я думаю где-то через годика полтора у нас будет 1.0, потому что версии очень прыгают. И за 3 года существования 0.11-ой версии Terraform дошел до 19 минорной версии. А 12-ая уже 20-какая-то. И это уже за меньшее время, потому что они увеличивают релизные циклы, чтобы закрыть больше запросов. Они явно двигаются к тому, чтобы в конечном счете сделать стабильную версию 1.0.

(Виктор) И что интересно, даже в безрелизных версиях они продают свой Terraform enterprise, при этом очень-очень активно. Никто не знает, сколько стоит, но говорят, что практически космолет. И даже с нулевой версии получилось продавать enterprise-версию.
(Александр) Да, все верно.

Какие проблемы с чистым Terraform, на мой взгляд, есть?

Когда мы начинаем работать с Terraform, то вроде бы все просто. Мы сделали первую VPC, сделали первый environment – вроде нормально.
Потом нам надо сделать второй environment, либо второй регион. И мы начинаем дублировать свой код. Мы начинаем конфигурировать бэкенд в двух местах. Мы приходим к модулям, но модули тоже нужно дублицировать. Тебе надо постоянно описывать variable staff, который ты передаешь в модуль. И в итоге ты себя повторяешь снова и снова. Тебе надо сделать новый environment, сделать remote state location. Terraform не умеет создавать бэкенд, где он хранит remote state. Тебе надо об этом позаботиться самому. И нужно попросить Васю сходить к bucket-создателю. Нужно писать скрипт, который будет это делать. При этом надо, чтобы туда никто не зашел, надо накатить policy, зарестриктить доступ. И в итоге это выливается в очень неприятный процесс.
И новый environment мы эстимируем в x*3 days. И мы не знаем, сколько это займет, потому что это неизвестно.
Вроде бы сделали. Потом меняем версию модуля в одном environment и это аффектит другие, потому что у нас структура с шаренными кодами, чтобы мы себя не повторяли, приводит к тому, что это продолжается применяться не контролируемо дальше. Мы вынуждены это как-то применять и т. д. Появляется больше условий от входных перемен. И другие люди, кроме тебя, перестают понимать, что там внутри.
И для того чтобы людям помочь, ты пишешь скрипт, который запускает Terraform в разных папках с разными аргументами. И вроде бы работает, но это костыль на костыле.

На моем прошлом проекте у меня был чистый Terraform, потом был Bash, потом Python, который в итоге, как на картинке видно, составил 690 строк кода. Это Python, который запускал Terraform. И мы в последствие пришли к Terragrunt.
Вот так примерно выглядела бы наша структура, если бы мы использовали чистый Terraform:

Чтобы нам применить в Multi-Cloud Terraform, нам бы пришлось писать вот такие командные строки, которые не очень читабельные и не очень запоминаются. И у нас будет большой Notepad, где будет все это переходить копи-пастом. И в случае изменений будет больно.

И тут у нас приходит Terragrunt. Terragrunt – это тоже golang tool, но просто cli, который выступает оберткой над Terraform. Даже не совсем над Terraform, но он вызывает Terraform.
Для чего он нужен?

Он создает сам бэкенды. Ты просто указываешь bucket name location. И если его нет, то он создает бэкенд, накидывает policy, делает его secure. И можно его использовать без каких-то интерфейсов из вне.
Полностью поддерживается HCL 2.0.
И вокруг этого много фич. Ты можешь использовать циклы, функции, которые есть в HCL 2.0.
Ты можешь организовать stacks, т. е. какой-то кусочек инфраструктуры так, как тебе угодно. Ты можешь сделать глобальный ресурс для аккаунта, ты можешь разделить на environments. И это все хорошо делиться по папочкам.
Что делает Terragrunt? У него один stack – это один HCL-файл. Этот HCL-файл – это описание твоего модуля, входных параметров и каких-то зависимостей, которые он анализирует и выстраивает себе граф того, как он будет работать. И Terragrunt хорошо подходит для не консистентных environments, для мультикомпонентных environments, где у тебя что-то есть, чего-то нет.

На первых взгляд входной порог длинный. Я лично подходил к Terragrunt три раза. И только с третьего раза у меня получилось. До 12-го Terraform мне казался он странным. Но теперь я распробовал его и не хочу менять подход.

Вот пример обычного HCL-файла. Есть какие-то входные параметры, есть ссылочка на модуль. И есть определенные dependency, которые из себя представляют очень важный момент, когда мы можем описать зависимость от других states.

(Виктор) Я правильно понимаю, что если мне нужно создать еще один environment, то я копирую все содержимое этого preprod, меняю variable, который мне нужен, например, в cloud YAML или в HCL в том числе можно определять, — и все, и новый environment готов? Т. е. он создастся с правильным бэкендом, с правильной конфигурацией? И, например, для preprod у меня будет 2 машины, для prod 200 машин. И какие-то ресурсы в preprod будут существовать, какие-то в prod не будут существовать, потому что мы еще не готовы?
(Александр) Все верно. Это такая концепция. Он позволяет сделать уровень абстракции выше над Terraform. И этим удобнее апеллировать. Это пример программирования в Terragrunt, когда можно повторяемые вещи вынести в отдельный файлик.

Например, как в данном примере мы конфигурируем бэкенд, где хранится remote state в зависимости оттого, где мы находимся, т. е. где конкретно stack находится. Анализируются папки сверху, выстраивается какое-то имя. И таким образом нам не надо прописывать ручками наш location.

(Виктор) Я правильно понимаю, что ты здесь прописываешь location, но у тебя все равно один бэкенд и ты показываешь путь, как дойти до твоего бэкенда? И если ты работаешь с Azure, то у тебя будет какое-то название у твоего бэкенда, а потом Azure как folder?
(Александр) Да, анализируется файловая структура. Составляется какое-то naming convention. И на основе этого создается bucket и объект в этом bucket.

Демо с 46:56 до
Что у нас есть?

У нас есть репозиторий, который я показывал. В нем я уже нагенерировал структуру.

Как правильно ты сказал, у нас есть YAML, который общий для всего environment, где описаны общие переменные.
Тут описаны такие вещи, как cloud abstractions, как регион. А также такие вещи, которые нужны для кода в целом.

Также здесь есть уже готовый preprod. У него есть environment.yaml, в котором описана специфика environment, т. е. cidr, subnet, instance_size, location и наименование.

(Виктор) И я так понимаю, что это потом для всех провайдеров передается?
(Александр) Да, это передается едино.
(Виктор) И здесь определяем, что location – это Европа? А в том файле, который ты до этого показывал, используется как трансляция, что такое Европа. И Европа для GCP – это вот это, для Azure – это вот это.

(Александр) Это происходит уже внутри модуля частично. Тут есть demo.hcl, который делает вот эту всю магию. И генерируются провайдеры для того, чтобы мы сконфигурировали Terraform для работы со всеми облаками.

Тут можно долго по коду бегать. Это будет долго. Я перейду к идее.
У меня есть pull request, где я подготовил обычным templanding’ом наш production. Это набор HCL-файлов + YAML, где мы описываем значения. И мы это все дело мержим сразу в мастер.
Я вернусь к презентации на секунду.

Что мы строим? У нас есть 3 облака, есть Travis CI и CloudFlare в качестве терминирования DNS-имени. И все это Travis’ом деплоится в 3 облака. В Travis уже зашиты все credentials и т. д.

Пока я мержу, у нас запустился процесс. Сейчас создастся VPC, создастся subnet, создастся все, что нужно. И будет готовый результат.

В свою очередь мы деплоим prod в среду. Это неплохо. Если была бы пятница, то было бы хуже. Но этот production у нас достаточно условный.
Если вернуться в Travis, то тут должен был запуститься процесс, который будет нам деплоить с мастер-ветки. Так и есть. Пока у нас Booting VM. И надеюсь, что сейчас это будет быстрее происходить, потому что время от времени это бывает долго.
И пока у нас тут происходит магия, мы можем сделать небольшую проверку. Это обычный shell-скрипт, который будет наш домен проверять. Как видно, пока доменной записи не существует, она не прописана в CloudFlare DNS. И пока у нас деплоится, мы можем попробовать поотвечать на вопросы.

(Виктор) Ты прочитал мои мысли. Первый вопрос: «Какой обычно процесс, если нужные провайдеры в Terraform отсутствуют? Писать в куски ARM, если это Azure или переключаться в скрипты, или писать в те провайдеры?»
(Александр) Провайдеры – это ресурсы, которыми мы хотим в каком-то cloud управлять?
(Виктор) Это сложный вопрос. Мне кажется, что да, потому что если мы говорим про провайдер и Azure, то провайдер в Azure точно существует, он там уже давно. Microsoft его поддерживает. Я подозреваю, что да. Например, выходит новая фича или новый тип ресурса, в Azure его нет.
(Александр) В данном случае, если вы не знаете Golang, то у вас выхода нет, потому что вы можете либо форкнуть провайдер, дописать нужный вам ресурс на Golang и потом сделать обратный pull request в официальный репозиторий, либо подождать, пока это сделает кто-то другой. Как правило, это очень быстро происходит. Community очень большое. В Azure похуже, я потом про это расскажу. Но некоторые вещи в terraform быстрее, чем в cloudformation, что очень странно, но это реальность. И в данном случае без знания Golang, наверное, остальные варианты будут костылями.
(Виктор) Есть очень длинный вопрос: «Если модулей для развертывания инфраструктуры много, как победить проблему с общей версионностью? Контекст: среда развертывания N-количество, которое все время увеличивается. Какие есть общие подходы для ведения прозрачной разработки и версионирования для понимания, где и что развернуто на текущий момент времени? И как обновить с одного на другое с меньшими преобразованиями, с меньшими временными затратами?».
(Александр) Тут просится CI для модулей, который будет автоматически версионировать модули в зависимости от каких-то git commits. Плюс cmdb. Т. е. configuration management – это база, где у вас будет хранится версионирование. И на основе cmdb вы сможете выстраивать какие-то таблицы, либо графики, например, в Grafana, где у вас будет расписано, где и что у вас задеплоено. И можно написать какие-то вещи вокруг этого в changelog, например, чтобы сравнить две версии. Допустим, prod у вас отстал, вы хотите задеплоить новую версию. Вы берете Git diff и смотрите, что из этого получилось. Тут каких-то родных средств нет, тут больше процессионные рекомендации, но они едины для любых разработок. Тут нет особой разницы, но понятно, что много модулей без автоматизации это очень сложно.
(Виктор) И чем дольше вы получаете разницу между environments, тем сложнее будет потом эту разницу без проблем задевелопеть в тех же management-системах таких, как Ansible, Puppet. И когда одно обновление сделал, потом другое накатил, то процессы обновления тоже иногда включают какую-то зависимость. В Terraform я о таком не слышал, но тем не менее, мне кажется, чем больше ты накопишь разницу, тем сложнее будет ее задевелопеть.

Следующий вопрос: «Где хранить state of staff в случае трех cloud-провайдеров, учитывая, что каждый cloud бэкапит другой, как ты сказал?». Как я понял, у тебя все в GCP, в storage?

(Александр) В третьем. Никто не мешает поднять какую-то базу on-premise и там хранить. Она будет доступна только с вашего subnet, т. е. откуда вы это применяете. Либо где-то рядом с CI-системой, которая это применяет, поставить базу. Я бы рекомендовал использовать cloud, потому что это более надежно, но это зависит, насколько вы кому-то доверяете.
(Виктор) И есть у Terraform cloud, где они тебе предлагают возможность хостить свои states. Там работают workspaces.

Вопрос: «Чего не хватает у Terraform вам для полного счастья прямо сейчас?».

(Александр) Мне нравится Terraform.
(Виктор) Нет foreach для модулей.
(Александр) Мне это не мешает. С Terragrunt он не нужен.
Мне мешает. У меня были кейсы, когда мне нужно было создавать в GCP сервис-аккаунты. И модуль, который создает сервис-аккаунты, к сожалению, не поддерживает map, где я передаю сервис-аккаунт и какие роли нужно замапить к этому сервис-аккаунту. Такого он не может схавать. И тебе нужно самому каким-то образом каждый раз делать вызов этого модуля. И если там был бы foreach, то это сильно упростило бы.
(Александр) У меня не было таких кейсов. Но эта вещь нужная. Я хотел бы, чтобы foreach починили, чтобы он работал всегда.
(Виктор) Ты имеешь в виду динамически в том числе, т. е. до того, как ты запускаешь, вся инфраструктура должна быть готовой?
(Александр) Да.
(Виктор) Вопрос: «Что нового и полезного в Terraform 13 и можно ли его уже использовать?». Мне кажется, мы частично уже это покрыли. У тебя был слайд об этом.
(Александр) Count, foreach для модулей, depends_on для модулей, чтобы можно было зависеть от каких-то внешних сущностей. И variables validation, что тоже очень круто для модулей, когда ты можешь провалидировать. Его можно использовать, если вы рисковый человек, но так как это бета, то отсюда все вытекающие.
(Виктор) Мне кажется, если вы сейчас стартуете разработку какого-то проекта и ваш релиз production намечен на осень, то, наверное, в этом ничего опасного нет. И к осени уже 13-ый Terraform станет финальной версией.
(Александр) Я лично 12-ый начал использовать только с версией 0.12.18. Я 18-ую минорную версию ждал.
(Виктор) Вопрос: «Как в текущем setup решить вопрос с блокировкой файла-состояния, чтобы избежать одновременного запуска нескольких версий Terraform-кода, использующих один и тот же state, с учетом того, что ваш текущий проект мультиоблачный? Решение одного из трех vendors не предлагать». Если честно, я до конца не понял вопрос.
(Александр) Это, наверное, про то, где хранить state.
(Виктор) Да. Мне кажется, в одном месте определили и все.
(Александр) В четвертом, в Consul, в базе.
(Виктор) Да, Consul тоже поддерживает state. Мне кажется, что тут особой проблемы нет. Если все ссылаются на один и тот же бэкенд и не важно, сколько людей будет запускать, то все равно появится lock-файл, который не даст вам запустить еще раз.
(Александр) По ходу демка у нас не взлетит. Видимо, что-то в Azure тупануло, не создается сеть. Вчера у меня такое было. Перезапуск помог.
(Виктор) Можно ли как-то попробовать самостоятельно людям запустить?
(Александр) Да. Но вам надо 3 clouds, что не так просто. Давайте я тогда покажу, как это выглядит для preprod, т. е. если добавить preprod. У нас есть обычный HAProxy, который терминирует это доменное имя.
(Виктор) Я так понимаю, что это ты уже создал?
(Александр) Это было создано.
(Виктор) Это бэкап plan?
(Александр) Да, бэкап plan.
(Виктор) Я понял.
(Александр) И он бегает между тремя clouds, т. е. если у нас один cloud падает, то health check HAproxy это задизейблит, и мы будем между двумя прыгать. Это банальный round-robin на HAProxy. Вот Multi-Cloud. Чтобы время не тратить, тайм-аут там 20 минут, это может быть вечно в Azure, поэтому я закончу.
(Виктор) У нас еще пара вопросов.
(Александр) Хорошо, я просто думал ответить на вопросы в конце.
(Виктор) А, ты хочешь feedback пошарить?
(Александр) Да, а потом поотвечаем.
(Виктор) Ок.

(Александр) Демо не взлетело, и я расскажу, по какой причине.

Когда нужно использовать Terragrunt? Когда у вас большие environments не консистентные, где много компонентов, где они разные по набору, в любом из этих случаев Terragrunt – это ваше спасение, на мой взгляд. Если вы хотите версионировать свои компоненты, модули и удобно с ними работать, то лучше использовать Terragrunt. Он это делает из коробки. Вам не надо запариваться с какими-то скриптами и т. д., потому что это будет больно вам и тем, кто после вас будет с этим работать.
Если вы хотите темплотизировать ваши environments, как делал я в демо, то Terragrunt – то отличный вариант. Один YAML с переменными, все остальное – это просто статика, плюс динамика, которая скрыта от пользователя. И все это дает нужный результат. И можно деплоить ENV очень быстро. На самом деле, эта демка должна подниматься за 3 минуты. И все время она поднималась. Вчера она запнулась в первый раз. И сегодня повторилась ситуация, потому что доклад. Ничего удивительно, это жизнь. В следующий раз буду записывать на видео.
И вы гибки в организации репозитория, т. е. если в Terraform у вас есть строгая необходимость сделать tf-файлы, а сейчас еще и HCL, то делайте, что хотите, Terragrunt обо всем позаботится.

Что я выучил? Google Cloud, Amazon – круто. Terraform круто работает, CLoudFlare – тоже отлично, там ничего сложного. Но с Azure как-то все тяжело и даже support для Microsoft для Azure очень странный. Там одна девочка страдает. Как я смотрел GitHub, одна девочка реагирует, может быть, еще кто-то, но видно, что им не хватает community. Но я не знаю, как работает Azure API, возможно, он закрытый и в этом проблема. Я не знаю этого.

Что бы я посоветовал?

Если вам интересна тема, то посмотрите open source, посмотрите GitHub. Смотрите issues. Если вы знаете Golang, попробуйте поучаствовать. И это поможет. Ваше участие необходимо, это достаточно ключевая вещь.
И я всем советую, если вы хотите делать крутую инфраструктуру автоматически, то берете Terraform и Terragrunt сразу. Лучше потратьте время, изучите, потом будет все вылетать на раз-два без всяких подводных камней. Может быть, с подводными камнями, но без айсбергов на пути.
И говорят где-то в чатах и на форумах, что Terragrunt будет платным, но мне не понятна схема монетизации. Это неофициальная информация. Я бы, наверное, не советовал это делать. Если меня смотрит Евгений Брикман, то не надо так делать – люди расстроятся. И платить вряд ли будут. Будут писать shell-скрипты и Python.
(Виктор) Я тоже так думаю.

(Александр) Теперь продолжим отвечать на вопросы.
(Виктор) Я бы еще добавил маленькую ремарку. Евгений Брикман – это автор книги «Terraform: Up & Running».
(Александр) Да, первой и второй версии.
(Виктор) Да, это очень классная книга. Крайне рекомендую ее. Это лучшая книга по изучению Terraform, если вы еще не знаете, что это такое.

Вопрос: «Если Terraform начал разрабатывать СDK для других языков, чтобы писать нативно и если есть нативный cloud СDK, то зачем в этой связке Terraform, когда можно сразу писать то, что нужно на нативном языке?»

(Александр) Я так понимаю, что это про CDK, который недавно анонсировали. HashiCorp позволил писать Terraform на CDK. Type-скрипт, который от Amazon.
(Виктор) Да-да.
(Александр) На самом деле, программирование – это программирование, т. е. все-таки какой-то уровень абстракции делает вхождение в инструмент легче. Например, освоить Terraform легче, чем type-скрипт, на мой взгляд. Я лично приверженец того, что это должно быть все декларативно, что не дает нам программирование, в частности тот же CDK. State в Terraform дает большой benefit компаниям, которым важно то, что они делают в том плане, что они хотят контролировать все. Этот state может использоваться для отрисования инфраструктурной схемы для того, чтобы показать на любой аудит. И все, вам больше ничего не надо делать. Во втором случае вам надо вести документацию, анализировать сам cloud, все оттуда вытягивать.

Я лично не сторонник таких инструментов, как CDK. Мне больше нравится Terraform, потому что он декларативный. Это для меня основной момент.
Но инструменты выбираются под задачу. Нельзя сказать, что это silver bullet. Нет, это не так.

(Виктор) Вопрос: «Какие бэкенды может создать Terragrunt? Может ли он засетапить Vault?». Мне кажется, что этот вопрос из разряда – пойти и посмотреть документацию.
(Александр) Которая у Terragrunt очень специфичная. У Terragrunt минус в том, что документация какая-то неочевидная. Но они улучшают этот момент. Я не знаю точно ответ на ваш вопрос. Я знаю, что cloud да, Azure, и Amazon. С остальными не знаю, лучше обратиться к создателям. Я думаю, они лучше ответят.
(Виктор) Да, я думаю, что правильно посмотреть документацию. Но, как правильно ты подметил, документация у Terragrunt на порядок хуже, чем у Terraform.

Вопрос: «Какие модули планируешь дописать до Terraform?»

(Александр) Дописать?
(Виктор) Да, дописать.
(Александр) Если говорить про написание open source модулей, то у меня есть такая внутренняя задача, но не хватает времени, потому что это нужно вливаться в community, а проектная загрузка этого не позволяет.

Модули, которые я предоставил для демо, они только для демо. Смысл их расширять ноль, на мой взгляд.

(Виктор) Мне кажется, что те модули, которые ты написал и показал, это классная штука.

Вопрос: «Ты говорил, что Terragrunt имеет высокий порог вхождения и о том, что только с третьего подхода он зашел. Не планируете ли какой-то дополнительный доклад на эту тему?». Мне кажется, что человек имел в виду обучающий доклад. Здесь важно самому попробовать. И тот вариант с кодом, который ты предложил, можно попробовать запустить. Это будет классно с точки зрения того, что ты сам его руками запустишь.

(Александр) Да, есть хорошая документация у Terragrunt start. Если вы знаете Terraform, вы поймете для чего. Если не знаете Terraform, то начните с Terraform Up and Running. Examples в интернете миллиард.
(Виктор) Еще крутые у Terraform есть learns. Там по каждому cloud разбита информация. Полтора часа на любой cloud. И можно изучить шаг за шагом.

Саша, это все. Какой вопрос, на твой взгляд был лучшим?

(Александр) Мне понравился вопрос про много environments и версионирование модулей, потому что он правильный. Я чувствую боль этого человека. И если человеку интересно, то я готов в рамках своего интереса предложить какое-то решение, которое, возможно, человеку в голову не пришло. Я готов максимально помочь в этом.
(Виктор) Саша, спасибо огромное! Мне кажется, доклад получился очень интересным! Спасибо большое за подготовку!

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_itinfrastruktura (IT-инфраструктура), #_amazon_web_services, #_devops, #_terraform, #_aws, #_sistemnoe_administrirovanie (
Системное администрирование
), #_itinfrastruktura (
IT-инфраструктура
), #_amazon_web_services, #_devops

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 07:03
Часовой пояс: UTC + 5