Terraform 12 И Terragrunt И Как Их Можно Использовать Для Мультиоблачной Инфраструктуры. Александр Довнар



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Что такое Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.

Мы поговорим о влиянии IaC (Infrastructure as Code) на современный мир и о том, как Terraform помогает работать с гетерогенными средами.

Хочу немного поговорить о самом Terraform, какие у него проблемы и как Terragrunt их решает. Далее я расскажу о своем опыте работы с Terragrunt и немного затрону тему мультиоблаков.

Во второй части обсуждения темы я хотел бы показать результат своих выводов по использованию Terraform + Terragrunt в среде с тремя облачными провайдерами (AWS, GCP, Azure) и CloudFlare в качестве DNS.

  • (Александр) Сегодня я хочу рассказать о том, как мне удалось сделать Multi-Cloud Deployment с помощью Terraform и Terragrunt, а также как это работает в отдельности и по отдельности.

  • (Виктор) Круто! Я знаю, что Саша подготовил вопросы.

    И по традиции перед каждым докладом мы запускаем викторину.

    Думаю, этот тест будет вам полезен с точки зрения понимания, все ли вы знаете о Terraform и будет ли вам интересен этот доклад.

Предлагаю провести викторину прямо сейчас.

И может быть, вместе с тобой, Саша, мы сможем рассмотреть вопросы, которые ты сам придумал.

Обращаем Ваше внимание, что принять участие в викторине можно на нашем Telegram-канале, в DevOpsМинск Чат .

Бот запускается там.

Вы можете заводить друзей и взаимодействовать с этим ботом.

Итак, викторина.

Я прочитаю вопросы и прокомментирую.

Терраформ – это:

  1. Инструмент управления конфигурацией
  2. Монетизация HashiCorp
  3. Инфраструктура — это код
  4. Инфраструктура как код.
Terraform используется для описания инфраструктуры HCL. Что такое ХКЛ?
  • (Александр) Язык конфигурации HashiCorp. Вот как описывается инфраструктура.

    Это синтаксис, разработанный самой HashiCorp.

  • (Виктор) Можно ли быстро конвертировать HCL в YAML. Мы здесь почти все YAML-разработчики.

  • (Александр) Да и обратно.

  • (Виктор) И это вполне работает даже несмотря на все последние изменения? Я знаю, что они выпустили HCL 2.0.
  • (Александр) Именно в HCL 2.0 появились удобные фильтры: YAML кодировать, декодировать и JSON кодировать, декодировать, которые позволяют достаточно просто конвертировать между тремя форматами.

    Это делается в первую очередь в самих продуктах HashiCorp.

Какой тип ресурса позволяет получить информацию о существующей инфраструктуре VPC или VM:
  1. Бэкэнд
  2. Запрос
  3. Источник данных
  4. Источник фильтра
Как часто вам приходится использовать DataSource на практике?
  • (Александр) Да, потому что часто приходится запрашивать информацию, которой нет в Terraform. Например, мы хотим охватить все доступные зоны доступности нашими подсетями Amazon. Мы можем использовать специальный DataSource, который предоставит нам все доступные на данный момент зоны доступности.

    Используя исключения и включения, мы можем манипулировать этим и использовать этот список в нашем коде Terraform.

  • (Виктор) А еще, если какая-то инфраструктура по тем или иным причинам была создана вручную, можно ли с ней взаимодействовать с помощью DataSource?
  • (Александр) Верно.

Как я могу воссоздать ресурс с помощью Terraform без изменения конфигурации?
  1. Терраформирующая порча
  2. Терраформировать уничтожить
  3. Терраформ применить
  4. Терраформированная равнина
  5. Обновление терраформа
Объясните, что делает тинт.
  • (Александр) Taint — это именно то, что нужно для таких целей.

    По сути, он помечает ресурс как нечто, что необходимо воссоздать.

    Допустим, нам нужно воссоздать машину.

    Но наша конфигурация в нем не меняется.

    Мы занимаемся порчей этого ресурса.

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

  • (Виктор) А что, если у ресурса, который мы хотим воссоздать, например, в виртуальной машине, есть какие-то зависимые вещи? Например, подключаем диски, настраиваем интерфейсы или что-то еще.

    Он контролирует только сам этот ресурс или будет его воссоздавать?

  • (Александр) Если запустить полноценный план, применить, то такие вещи как диск, который подключен к машине, тоже обновятся, потому что машина, к которой он подключен, изменилась.

    И идентификатор будет каждый раз новый.

  • (Виктор) Результат нашей викторины.

    Мужчина ответил на 5 вопросов за 19 секунд. Это Шксметана.

    Мы свяжемся с вами.

    Будет выслан промокод на пиццу.

    И судя по тому, что человек смог правильно ответить на 3 вопроса, а на все остальные и того меньше, то я считаю, что доклад должен быть интересным.

    Саша, я предоставляю тебе слово.

  • (Александр) О чем я хочу поговорить? Я хочу рассказать о том, что такое Terraform, Terragrunt и как все это можно использовать как для развертывания Multi-Cloud, так и для любых других задач.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Сначала расскажу немного о себе:
  • Меня зовут Саша.

    Я работаю в EPAM Systems ведущим системным инженером.

  • Я работаю в мире DevOps чуть больше 4 лет.
  • До этого я еще 6 лет проработал в крупнейшем интернет-провайдере Беларуси.

  • Фанатик автоматизации – очень громкое слово, но я для себя понимаю, что автоматизировать дело лучше, чем делать это вручную, потому что сам допускаю в этом много ошибок и стараюсь оградить от этого всех остальных.

    Я стараюсь рассказывать об этом людям.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

О чем мы будем говорить сегодня?
  • Для начала я хочу рассказать вам, почему я здесь и что я вам расскажу подробно.

  • Затем мы немного пробежимся по теоретическим аспектам, т.е.

    что такое Terraform, Terragrunt и Multi-Cloud. Расскажу, что это такое и зачем это нужно.

  • Далее я покажу небольшую демонстрацию, которую я подготовил в рамках этого отчета.

  • И я расскажу вам, что из этого получилось.

    Поделюсь впечатлениями.

  • Вопросы и ответы.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Это QR-газировки, которые позволят вам ориентироваться по ходу репортажа.

Вы можете посмотреть исходный код. Демонстрационный сайт PreProd также теперь развернут. И в рамках нашего отчета мы развернём производство.

Вы можете открыть ссылки и посмотреть, что там.

Я расскажу вам об этом немного позже.

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

В вашем названии написано «Терраформ 12».

И вроде бы даже первого релиза не было.

Почему это?

  • (Александр) Сейчас релиз Terraform, если посмотреть на семантику версионирования, то это 0., т.е.

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

Покажу вам слайд из последнего отчета HashiConf, где был задан именно такой вопрос.

И там есть небольшое описание на примере Пакера.

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

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



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Небольшой отказ от ответственности, т. е.

исходный код, который вы видели, нужен только для создания этой демонстрации.

Некоторые вещи там можно использовать для реальных проектов.

Я постарался максимизировать функциональность и возможности, существующие как в Terragrunt, так и в Terraform, с точки зрения модулей и взаимодействия с несколькими облаками.

Но это не настоящее производство, т. е.

всегда нужно очень внимательно читать и переносить свой проект в среду.

А еще вы можете задать вопросы в Telegram, на которые мы постараемся ответить.

А еще вы можете найти меня по моим контактным данным и задать вопрос, я всегда рада помочь.

Готов поделиться знаниями и опытом.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

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



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Виктор предложил рассказать мне о Терраформе.

Мне это интересно.

Я давно хотел получить такой опыт. Вместе с ребятами мы выбрали эту тему, потому что она более интересна и максимально раскрывает все грани.

Цели, которые мы ставим следующие:

  • Мы хотим развернуть некоторую инфраструктуру в трёх облаках: Amazon, Azure и GCP. И мы хотим соединить их вместе и показать, как они могут работать вместе.

    Это один из вариантов стратегии развертывания, когда мы разворачиваемся в 3 облака для большей доступности и возможного катаклизма при выходе из строя одного из трёх.

  • Еще хочу показать, как в этом помогает Terragrunt. Я расскажу вам, зачем это нужно.

  • И я хочу поделиться своим опытом, ведь это все было написано с нуля в рамках подготовки.

    И этот опыт весьма интересен.

  • Из проблем, с которыми я столкнулся:
  • Я практически не умел работать с Azure. Я знал это только потому, что это была Microsoft. И я поделюсь своим отзывом.

  • А еще я пытался создать инфраструктуру, которая была бы бесплатной.

    Я создал бесплатный уровень в AWS и GCP. У меня был Azure, поэтому приложение достаточно примитивное.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Поговорим немного о теоретическом аспекте.

То есть примерно:

  • Что такое мультиоблако.

  • Что такое Терраформ?
  • А зачем нам Террагрунт, если Терраформ у нас уже есть?


Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Думаю, многие слышали о Multi-Cloud. Из названия понятно, о чем речь.

Это несколько облачных решений.

И вроде бы оно везде, но его нет нигде.

  • (Виктор) Я бы сказал немного по-другому: все о нем говорят, но никто его не видел.

  • (Александр) Да.

  • По моему опыту, Multi-Cloud в основном выбирают тогда, когда хотят максимально избавиться от вендерлока, ведь любое облако предоставляет сервис управления, которым удобно активно пользоваться.

    И, как правило, уходить из одного облака в другое по каким-то причинам становится очень дорого.

    Поэтому многие компании об этом думают, многие уже начинают это делать.

  • Следующий пункт – ИТ-помощь.

    Часто в крупных корпоративных компаниях возникает ситуация, когда какая-то команда, разрабатывающая и улучшающая продукт, понимает, что они хотят использовать сервис в Google Cloud, поэтому это будет быстрее и дешевле.

    Если у нас на сайте есть Multi-Cloud, где есть все необходимое оборудование и учетные записи, проще предоставить песочницу в Google Cloud, когда команда этого захочет. И обычно это получается быстрее и дешевле, чем начинать все заново и говорить: «Нет, делайте все это на Amazon».

  • С Производительностью и отказоустойчивостью все понятно.

    Нам нужна производительность или услуга, которая лучше работает в Google Cloud, или нам нужна служба управления Active Directory, которая отлично работает в Azure. А затем мы делим наш сервис на несколько облаков.

    Это также может быть гибридное облако.

    Все зависит от конкретного сценария.

  • И последний важный момент, особенно для Европы и Америки, это Compliance, т.е.

    соответствие регламенту, когда нам нужно хранить пользовательские данные в каком-то месте, а в Amazon регионального нет, а оно есть в Azure или, наоборот, там.

    доступно в Google Cloud, но не в Azure и т. д.

  • (Виктор) Добавлю небольшую ремарку.

    Это касается не только Америки и Европы, но и всех стран, которые переезжают. Даже в Канаде действуют очень похожие законы, в которых говорится, что если что-то конфиденциально, то оно должно храниться только внутри страны.

    А также в России, когда не будет AWS, не будет там и проекта под AWS.

  • (Александр) Скоро.

  • (Виктор) Да, обещали, я тоже слышал эту новость.

  • (Александр) Но это, наверное, не так, потому что это будет интеграция.

  • (Виктор) Да, mail.ru.
  • (Александр) Все боятся.

    Ладно, mail.ru, наверное, тоже предоставляет хорошие услуги.

    Но, к сожалению, нам не удалось с ними поработать.

Какие проблемы стоят перед компаниями?
  • Во-первых, это дорого и с точки зрения инфраструктуры, и с точки зрения специалистов, потому что найти человека, умеющего делать Amazon, легко, найти человека, умеющего делать Google, довольно просто.

    с Azure это тоже легко, но найти человека, который умеет и там, и там, и делает это хорошо — очень сложно.

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

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

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

    На мой взгляд, без автоматизации лезть в Multi-Cloud не стоит. Но это мое личное мнение, оно может быть не совсем правильным.

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



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Вы спросили, что такое HCL. Это язык конфигурации HashiCorp. Для чего это? Чтобы иметь возможность унифицированно описывать инфраструктуру или абстрактные компоненты инфраструктуры, такие как пространство имен Kubernetes, используя один язык.

И если человек писал на Terraform, то начать писать в Azure на том же Terraform не сложнее, чем если бы он перешел с облачного формирования на шаблон Azure. Это делает такие движения довольно трудными.

Но прежде всего HCL унифицирует подход к написанию кода.

Понятно, что везде разные атрибуты, разные параметры для всех ресурсов.

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

    И невозможно, чтобы одно и то же описание работало во всех облаках.

    Все придется переписывать.

    И, как мне кажется, важно сделать такое уточнение, что HCL — это еще и декларативный язык типа YAML, который не совсем предназначен для написания ветвей, циклов и т.п.

    Хотя в HCL 2.0 появилось несколько очень крутых возможностей.

  • (Александр) В рамках этого доклада я сделал модуль, унифицированный для трёх облаков.

    Он принимает параметры.

    И этот модуль можно смело использовать в трёх местах, в трёх облаках.

    И он использует те же абстракции.

  • (Виктор) Один модуль для всех?
  • (Александр) Да.

  • (Виктор) А какой ресурс?
  • (Александр) Вот и все.

    ВПК.

  • (Виктор) Но все же каждый предмет вы описываете по-своему.

  • (Александр) Да, внутри модуля, но я предоставляю уровень абстракции, который позволяет пользователю передавать некоторые параметры.

    Это одна из вещей, которую я хотел проверить, потому что я этого не сделал.

    И мне кажется, получилось интересно.

Что еще я могу сказать о Терраформе? В отличие от всех конкурентов, которые специфичны для каждого облака, оно имеет такой нюанс, которым пользуется и апеллирует к государству.

То есть все, что сделал Terraform, записывается в какое-то состояние.

Обычно это файл, который хранится в достаточно надежном хранилище типа S3. И он хранит все, что сделал там.

И в момент следующего запуска, грубо говоря, берет код, который вы написали, и сравнивает его с тем, что есть в состоянии.

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

  • (Виктор) И здесь важно подчеркнуть один момент. Вы сказали «надежное хранилище» в качестве бэкэнда и сказали «S3».

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

  • (Александр) Да.

  • (Виктор) Но мне кажется очень важно уточнить, что если создать какую-то базу данных и записать туда пароль, то в штате он, к сожалению, пока находится в открытом виде.

    И, к сожалению, у Terraform в 12 версии еще есть билет для ребят, чтобы над этим поработать, но пока нет. И поэтому важно ограничить доступ к этому файлу состояния, чтобы он был доступен не всем.

    И, конечно, чтобы не потерять долговечность, это тоже очень важно.

  • (Александр) Да.

Сейчас Terraform из коробки поддерживает, по моему мнению, около 10 удаленных стейт-локаций, т.е.

от S3 до Cassandra, если не ошибаюсь.

И это ключевой аспект — состояние Terraform, потому что если он запустит Terraform с описанием на существующем аккаунте в Amazon или в Azure, он попытается создать.

Он ничего не знает о том, что там создано.

Он может импортировать существующие ресурсы в состояние, но это уже другая история.

И последний момент — Terraform на данный момент поддерживает более 100 провайдеров, т.е.

концепция Terraform — это конкретный механизм преобразования HCL в API-вызовы конкретного провайдера.

То есть репозиторий Amazon, OpenStack, Kubernetes, Helm, GitLab, например.

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

    Все это задокументировано HashCorp. Есть официально поддерживаемые провайдеры, есть провайдеры, которые кто-то сделал, т.е.

    их можно написать.

    Но, как правило, мне хватало того, что было.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

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

  • (Виктор) Два выпуска назад мы говорили, что консалтинговая компания Thoughtworks выпускает свой технологический радар.

  • (Александр) Да.

    Что такое технологический радар? Это анализ того, что сегодня есть на рынке и что используют в разных компаниях.

    И классификация подходов или рекомендации по использованию.

А Terraform в прошлом году, когда еще были инструменты в Technology Ragar, его взяли на вооружение в том смысле, что его строго рекомендуется использовать в производстве для реальных проектов.

В этом году немного изменили концепцию.

И они оставили инструменты.

Но есть подход «инфраструктура как код», т.е.

когда рекомендуется использовать этот подход, потому что иначе вы рискуете не быть конкурентоспособными.

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

Сегодня все рекомендуется в виде кода.

Сегодня Terraform находится на вершине.

И даже многие поставщики облачных услуг активно инвестируют в поддержку поставщиков Terraform. Они отделяют от себя людей и, возможно, подразделения.

  • (Виктор) Я уверен, что провайдеры Azure вносят большой вклад в то, чтобы все имеющиеся у них ресурсы поддерживали Terraform, поэтому иногда это является ключевым фактором для компании при выборе инфраструктуры в качестве кода.

    Это один инструмент для всего.

  • (Александр) Да, это так.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Что еще я могу сказать о Терраформе?
  • Он идеально подходит для любого подхода к программированию.

    Можно делать модульность.

    Вы можете создавать версии этих модулей.

  • Если вы хотите включить Terraform в CI/CD, пожалуйста.

    Есть все виды ворса.

    Официально их не существует, но они довольно популярны и хорошо поддерживаются.

  • Есть возможность модульного тестирования.

    Есть возможность интеграционного тестирования.

Море подходов, море рамок.

Под капотом есть даже море сервисов, которые могут это сделать.

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

Это также очень удобно.

  • (Виктор) Вы сказали про модуль, про артефакт. И почему-то я представил в голове, что когда я запускаю CI для Terraform, именно план Terraform генерирует состояние, которое потом при применении будет выброшено на бэкенд, но оно еще не применено.

    То есть я могу посмотреть на это и сравнить с тем, что у меня есть.

    И, мне казалось, это тот артефакт, что когда я что-то строю, у меня в итоге получается что-то, что я исполню.

    И в состоянии Terraform, которое я затем применю к своей инфраструктуре.

  • (Александр) На самом деле там много инструментов и подходов.

    Это отдельная тема для доклада.

    В нашем проекте мы полностью реализовали CI для модулей.

    Это линтинг, планирование, применение, соответствие, безопасность.

    И все это выполняется на базе модуля.

  • (Виктор) Я понимаю.

  • (Александр) И это можно расширять бесконечно.

    Все зависит от требований к продукту для конкретного проекта.

    Мы можем использовать телеметрию (мониторинг, метрики), а результаты использования Terraform в наших процессах безграничны.

    Все зависит только от нашей фантазии.

    Terraform кажется очень простым, но в то же время дает достаточно большое поле для творчества.

    Вы можете расширить его с помощью своих инструментов, используя его в выводе.

    Вы можете включить эти результаты в некоторые процессы и т. д.

Здесь нет лучших практик, но вероятность есть.

И он достаточно большой.

И это большая разница, потому что я, например, не знаю, как без Amazon можно протестировать шаблон формирования облака, то есть просто проанализировать статический код. Возможно, есть какие-то инструменты, но я недостаточно плотно с ними работал.

Может быть, кто-то из зала мне подскажет.

Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Я украл цитату Антона Бабенко.

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

  • Разработчики Terraform, понимающие, что такое HCL 2.0 и понимающие, что там писать.

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

  • (Виктор) Вернее, они хотят получить не модуль, а результат как можно быстрее, не заморачиваясь о том, что под капотом.

    И при этом быть на самом высоком уровне абстракции.

    Грубо говоря, я хочу 15 виртуальных машин с одной балансировкой нагрузки и все.

  • (Александр) Верно.

    То есть первые предоставляют вторым возможность это сделать.

И далее я расскажу об отличиях 11-го и 12-го Терраформа.

И это больше про разработку, т.е.

тем, кто просто потребляет Terraform как пользователь, всё это не нужно.

И, по сути, им незачем это знать.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Теперь на экране представлен базовый пример кода Terraform 11, который показывает мою самую большую болевую точку.

Первый — это синтаксис интерполяции, когда мы берём переменные или функции и вынуждены заключать их в фигурные скобки с долларом и кавычки.

И, честно говоря, это доставило мне немало дискомфорта.

И часто именно из-за этого возникают синтаксические ошибки, ведь есть очень сложные escape-строки.

Наверное многие с этим сталкивались.

  • (Виктор) Мне кажется, в 12 версии доллар и скобка все равно остались.

    Это оставлено на тот случай, когда нужно что-то обработать, то есть не просто переменную, а когда нужно что-то получить.

  • (Александр) На данный момент это используется только в строках, т. е.

    вы хотите вставить переменную в строку, а затем используете интерполяцию.

    Во всем остальном это было удалено.

    И об этом я расскажу вам чуть позже.

И довольно серьёзный момент — API всех облаков, в частности Amazon, очень сильно меняются.

И они, как правило, заточены под определённую структуру вызовов API. И из-за этого версия Terraform 11 была ограничена.

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

А если бы у нас было 2 среды, где в одной мы хотели разрешить порт 25, а во второй 22, то мы уже не могли бы использовать один и тот же модуль.

Нам пришлось написать в этом модуле 2 ресурса, которые бы зависели от некоторых условий.

И это довольно неприятный аспект.

Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

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

В Terraform 11 были циклы.

  • (Виктор) Считай, по сути.

  • (Александр) Да, это так.

    Но это всего лишь массив.

    И в чем проблема? Например, теперь на экране обычный дизайн.

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

    Там описываем список словарей, где описываем порт, описание и т.д.

И теперь у нас на экране 2 правила и план.

Мы применили, все работает. Завтра кто-то придет и скажет: «Надо добавить еще один порт».



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

И добавляем этот порт неважно где: в конце, в начале, в середине.

Даже если мы сделаем это в конце, при следующем запуске Terraform он не поймет, что мы сделали.

И он захочет воссоздать первое правило, то есть добавить необходимое новое, но сортировка в его голове изменится и он захочет удалить одно правило.

Это не страшно, но когда у тебя большая инфраструктура и она уже в проде, т. е.

если махнуть шашкой, можно на какое-то время словить даунтайм.

Поэтому приходилось заходить в состояние, чтобы что-то редактировать, или использовать во время обслуживания.

, но это так себе метод. И многие люди жаловались на это на GitHub. А два года назад анонсировали выход версии 0.12.

Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

  • (Виктор) Думаю, это было в прошлом году, когда ситуация стабилизировалась.

  • (Александр) Возможно.

  • (Виктор) Вероятно, 2 года назад он был в бета-версии, а сейчас 0.13. Это значит, что о нем заговорили еще в апреле.

  • (Александр) В июне 18 года.

    А дело в том, что в 12-й пересмотрели синтаксис, т.е.

    ввели язык HashiCorp Configuration 2.0, в котором много чего изменилось.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

На что изменения коснулись в первую очередь?
  • Во-первых, у нас нормальный цикл.

    Теперь у нас есть не только count, но и for_each, который перебирает сложные объекты, такие как словарь и ключи.

    Таким образом, мы можем выбрать какое-то уникальное значение в качестве ключа, и при следующем запуске у нас не возникнет проблема, которая была на предыдущем слайде.

    В случае с for_each у нас есть возможность написать его более грамотно.

  • И плюс, интерполяцию убрали.

    Если посмотреть, все переменные без фигурных скобок.

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

  • И более удобная вещь для разработчиков Terraform — динамические блоки, которые позволяют нам генерировать структуры, которые раньше заставляли нас жестко кодировать.

    Теперь мы можем генерировать их автоматически при выполнении плана.

    Это очень удобно.

for_each имеет некоторые нюансы.

В Terraform for_each не может вычисляться на лету, т.е.

for_each уже должен быть известен на входе.

Например, мы должны знать объект «ключ-значение».

И это очень важно, потому что если мы захотим получить какой-то ресурс, который еще не создан, и встроить эти значения в динамическую конструкцию, и передать их в for_each, то Terraform скажет, что я ничего не знаю о это давайте сначала применим через Target отдельную часть.

Это известная проблема, здесь нет ничего нового.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

В 12-м Терраформе разница очень заметна и очень приятна.

  • (Виктор) Я так понимаю, что боли и убийства одного правила больше не будет, у вас будет только новый ресурс, который вы добавили? И в данном случае это порт 36?
  • (Александр) Да.

  • (Виктор) Соответственно в наши правила будет добавлен только 36 порт?
  • (Александр) Верно.

Есть еще пара особенностей, весьма серьезных.



Terraform 12 и Terragrunt и как их можно использовать для мультиоблачной инфраструктуры.
</p><p>
 Александр Довнар

Теги: #ИТ-инфраструктура #Системное администрирование #terraform #DevOps #aws #Amazon Web Services

Вместе с данным постом часто просматривают: