terraform что это простыми словами
Как управлять облачной инфраструктурой с помощью Terraform
В этой статье мы рассмотрим из чего состоит Terraform, а также поэтапно запустим собственную инфраструктуру в облаке с VMware — подготовим три VM для разных целей: прокси, файловое хранилище и CMS.
Обо всем подробно и в три этапа:
1. Terraform — описание, преимущества и составляющие
В работе с инструментом мы отметили несколько преимуществ:
Скорость развертывания новых тенантов (пользовательских виртуальных сред). Обычно, чем больше новых клиентов, тем больше «кликов» требуется сделать сотрудникам технической поддержки для публикации новых ресурсов. С Terraform пользователи могут изменять параметры виртуальных машин (например, автоматически выключать ОС и увеличивать раздел виртуального диска ) без участия технической поддержки и выключения самой машины.
Моментальная проверка плана активации нового теннанта. С помощью описания кода инфраструктуры мы можем сразу же проверить, что и в каком порядке будет добавлено, а также в каком конечном состоянии будет та или иная виртуальная машина или виртуальная сеть с подключениями к виртуальным машинам.
Возможность описывать большинство популярных облачных платформ. Вы можете использовать инструмент от Amazon и Google Cloud, до частных платформ на базе VMware vCloud Director, предлагающих услуги в рамках IaaS, SaaS и PaaS решений.
Управлять несколькими облачными провайдерами и распространять инфраструктуру между ними для повышения отказоустойчивости, используя одну конфигурацию для создания, диагностики и управления облачными ресурсами.
Удобное использование для создания демо-стендов под тестирование и отладку программного обеспечения. Вы можете создавать и передавать стенды для отдела тестирования, параллельно проверять ПО в разных средах, а также моментально изменять и удалять ресурсы, создав всего лишь один план построения ресурсов
«Террариум» Terraform
Кратко рассказали про преимущества инструмента, теперь разберем его на составляющие
Providers (провайдеры).
В Terraform практически любой тип инфраструктуры можно представить в качестве ресурса. Связь между ресурсами и платформой API обеспечивается providers модулями, которые позволяют создавать ресурсы в рамках определённой платформы, например, Azure или VMware vCloud Director.
В рамках проекта вы можете взаимодействовать с разными провайдерами на разных платформах.
Resources (описание ресурсов).
Описание ресурсов позволяет управлять компонентами платформы, например виртуальными машинами или сетями.
Вы можете самостоятельно создать описание ресурсов для провайдера VMware vCloud Director и использовать это описание для создания ресурсов у любого хостинг-провайдера, который использует vCloud Director. Вам потребуется лишь заменить параметры аутентификации и параметры сетевого подключения к необходимому хостинг-провайдеру
Provisioners.
Эта составляющая дает возможность выполнять операции по первоначальной установке и обслуживанию операционной системы после создания виртуальных машин. После того, как вы создали ресурс виртуальной машины, с помощью provisioners вы можете настроить и подключиться по SSH, выполнить обновление операционной системы, а также загрузить и выполнить скрипт.
Переменные Input и Output.
Input переменные — входные переменные для любых типов блоков.
Output переменные позволяют сохранить значения после создания ресурсов и могут быть использованы, как входные переменные в других модулях, например в блоке Provisioners.
States (состояния).
States-файлы хранят информацию о конфигурации ресурсов платформы провайдера. При первом создании платформы никаких сведений о ресурсах нет и перед любой операцией Terraform обновляет состояние с реальной инфраструктурой уже описанных ресурсов.
Основная цель состояний, это сохранение связки объектов уже созданных ресурсов для сравнение конфигурации добавляемых ресурсов и объектов, чтобы избежать повторного создания и изменений платформы.
Информация о состоянии по умолчанию хранится в локальном файле terraform.tfstate, но при необходимости есть возможность использовать удаленное хранение для работы в команде.
Также вы можете импортировать текущие ресурсы платформы в состояние, чтобы далее взаимодействовать с другими ресурсами, которые в свою очередь были созданы без помощи Terraform.
2. Создание инфраструктуры
Составляющие разобрали, теперь с помощью Terraform мы поэтапно создадим инфраструктуру с тремя виртуальными машинами. Первая с установленным прокси-сервером nginx, вторая с файловым хранилищем на базе Nextcloud и третья с CMS Bitrix.
Писать код и исполнять его мы будем на примере нашего облака на VMware vCloud Director. У нас пользователи получают учётную запись правами Organization Administrator, если вы используете учетную запись с теми же правами в другом облаке VMware, то сможете воспроизвести код из наших примеров. Поехали!
Сначала создадим для нашего нового проекта директорию, в которой будут размещены файлы с описанием инфраструктуры.
Для описания компонентов нашей инфраструктуры, мы создали следующие файлы:
Язык конфигурации в Terraform является декларативным и порядок блоков не имеет значения, кроме блоков provisioner, т.к. в этом блоке мы описываем команды для выполнения при подготовке инфраструктуры и они будут выполнятся по порядку.
Для описания блоков используется собственный язык программирования HCL (HashiCorp Configuration Language), возможно описывать инфраструктуру и с помощью JSON. Подробнее о синтаксисе можно прочитать на сайте разработчика.
Конфигурация переменной окружения, variables.tf и vcd.tfvars
Сначала создадим два файла, которые описывают список всех используемых переменных и их значений для модуля VMware vCloud Director. Первым создадим файл variables.tf.
Cодержимое файла variables.tf.
description = «vCD Tenant User»
description = «vCD Tenant Password»
description = «vCD Tenant Org»
description = «vCD Tenant VDC»
description = «vCD Tenant URL»
description = «vCD edge name»
description = «vCD public catalog»
description = «OS CentOS 7»
description = «Storage Policies»
default = «Gold Storage Policy»
description = «Storage Policies»
default = «Bronze Storage Policy»
description = «Organization Network Subnet»
description = «External public IP»
И вводим свои переменные:
Вторым файлом создаем и указываем переменные для модуля VMware vCloud Director в файле vcd.tfvars: Напомним, что в нашем примере мы используем собственное облако mClouds, если вы работаете с другим провайдером уточните значения у него.
Содержимое файла vcd.tfvars.
vcd_org_ssd_sp = «Gold Storage Policy»
vcd_org_hdd_sp = «Bronze Storage Policy»
Сетевая конфигурация, network.tf.
Переменные окружения заданы, теперь настроим схему подключения виртуальных машин — к каждой виртуальной машине назначим приватный IP-адрес и с помощью Destination NAT «пробрасываем» порты во внешнюю сеть. Для ограничения доступа к портам управления установим доступ только для нашего IP-адреса.
Схема сети для создаваемой Terraform платформы
Создаем виртуальную организационную сеть с названием net_lan01, шлюзом по умолчанию: 192.168.110.254, а также с адресным пространством: 192.168.110.0/24.
Описываем виртуальную сеть.
resource «vcd_network_routed» «net» <
Создадим правила для межсетевого экрана, которое позволяет предоставить виртуальным машинам доступ в сеть Интернет. В рамках этого блока все виртуальные ресурсы в облаке будут иметь доступ в сеть Интернет:
Описываем правила для доступа VM в интернет.
resource «vcd_nsxv_firewall_rule» «fw_internet_access» <
name = «Internet Access»
Установив зависимость, что после обработки блока vcdnetworkrouted.net мы приступаем к конфигурации блока vcdnsxvfirewallrule, с помощью dependson. Используем эту опцию, так как некоторые зависимости могут быть распознаны неявно в конфигурации.
Далее создадим правила разрешающее доступ к портам из внешней сети и указываем наш IP-адрес для подключения по SSH к серверам. Любой пользователь сети Интернет имеет доступ к портам 80 и 443 на веб-сервере и пользователь с IP-адресом 90.1.15.1 имеет доступ к портам SSH виртуальных серверов.
Разрешаем доступ к портам из внешней сети.
resource «vcd_nsxv_firewall_rule» «fwnatports» <
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
В данной статье мы рассмотрим, что такое Terraform и для чего он нужен.
1.Обзор
Terraform – Open Source проект от HashiCorp создан в 2014 году. Является превосходным инструментом для создания Инфраструктуре в коде (Infrastructure as a Code). Проект абсолютно бесплатный и можно даже скомпилировать его из исходников, изменить его, т.е полностью открытый проект. Данный продукт является превосходным инструментом для создания инфраструктуры в коде. Сайт продукта https://www.terraform.io.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
И так, что это такое? Язык программирования инфраструктуры в cloud, не важно какой cloud. AWS, Google Cloud, Microsoft Azure, Digital Ocean, Yandex, AliCloud и есть поддержка многого другого, в том числе плагины под VMware. С помощью данного программного обеспечения можно даже управлять репозиторием Git Hub. Данный продукт является отличным для написания IaaS кода.
2. Установка на Windows
3. Установка в Linux
Что такое модули Terraform и как они работают?
Многие новички пропускают настройку модулей Terraform, чтобы облегчить процесс настройки. По крайней мере, они так думают, что облегчили себе задачу. Рассмотрим что такое модули Terraform и как они работают.
Я предполагаю, что вы уже знаете некоторые основы Terraform и даже пытались использовать его раньше. Если нет, ознакомьтесь с этим обзором Terraform и этим видеоуроком, прежде чем продолжить чтение.
Обратите внимание: я намеренно не использую реальные примеры кода с некоторыми конкретными поставщиками, такими как AWS или Google для простоты понимания.
Модули Terraform
Вы уже пишете модули
Даже если вы не создаете модуль намеренно, если вы используете Terraform, вы уже пишете модуль — так называемый «корневой» модуль.
Что делает модуль?
Модуль Terraform позволяет вам создавать логическую абстракцию поверх некоторого набора ресурсов. Другими словами, модуль позволяет вам группировать ресурсы вместе и повторно использовать эту группу позже, возможно, много раз.
Предположим, у нас есть виртуальный сервер с некоторыми функциями, размещенными в облаке. Какой набор ресурсов может описывать этот сервер? Например:
сама виртуальная машина, созданная из некоторого образа
подключенное блочное устройство указанного размера для дополнительного хранилища
статический общедоступный IP-адрес, сопоставленный с виртуальным сетевым интерфейсом сервера
набор правил брандмауэра, который будет прикреплен к серверу
другие вещи, такие как другое блочное устройство, дополнительный сетевой интерфейс и т. д.
Теперь предположим, что вам нужно создать этот сервер с набором ресурсов много раз. Именно здесь модули действительно полезны. Вы же не хотите повторять один и тот же код конфигурации снова и снова, не так ли?
Вот пример, показывающий, как может быть вызван наш «серверный» модуль.
«Вызвать модуль» означает использовать его в файле конфигурации.
Здесь мы создаем 5 экземпляров «сервера», используя единый набор конфигураций (в модуле):
Terraform поддерживает «счетчик» для модулей, начиная с версии 0.13.
Организация модуля: дочерний и корневой
Конечно, вы, вероятно, захотите создать более одного модуля. Вот несколько распространенных примеров:
сеть, подобная виртуальному частному облаку (VPC)
хостинг статического контента (т.е. bucket)
балансировщик нагрузки и связанные с ним ресурсы
или что-то еще, что вы считаете отдельным логическим компонентом инфраструктуры
Допустим, у нас есть два разных модуля: «серверный» модуль и «сетевой» модуль. В модуле под названием «сеть» мы определяем и настраиваем нашу виртуальную сеть и размещаем в ней серверы:
Два разных дочерних модуля, вызываемые в корневом модуле
Когда у нас есть несколько настраиваемых модулей, мы можем называть их «дочерними» модулями. А файл конфигурации, в котором мы вызываем дочерние модули, относится к корневому модулю.
Дочерний модуль может быть получен из нескольких мест:
официальный реестр Terraform — если вы знакомы с другими реестрами, такими как реестр Docker, то вы уже понимаете идею
репозиторий Git (пользовательский или GitHub/BitBucket)
Но как передать сведения о ресурсах между модулями?
В нашем примере серверы должны быть созданы в сети. Итак, как мы можем сказать «серверному» модулю создавать виртуальные машины в сети, которая была создана в модуле «сеть»?
Вот тут и появляется инкапсуляция.
Инкапсуляция модуля
Инкапсуляция в Terraform состоит из двух основных концепций: области модуля и явного доступа к ресурсам.
Scope (область видимости) модуля
Все экземпляры ресурсов, имена и, следовательно, видимость ресурсов изолированы в области действия модуля. Например, модуль «A» по умолчанию не видит и не знает о ресурсах в модуле «B».
Видимость ресурсов, иногда называемая изоляцией ресурсов, гарантирует, что ресурсы будут иметь уникальные имена в пространстве имен модуля. Например, с нашими 5 экземплярами модуля «сервер»:
Адреса ресурсов модуля, созданные с помощью мета-аргумента count
С другой стороны, мы могли бы создать два экземпляра одного и того же модуля с разными именами:
Обратите внимание на аргумент источника — он остается прежним, это тот же исходный модуль
В этом случае имя или адрес ресурсов будет следующим:
Явное раскрытие ресурсов
Если вы хотите получить доступ к некоторым сведениям о ресурсах в другом модуле, вам необходимо настроить это.
По умолчанию наш модуль «сервер» не знает о сети, которая была создана в модуле «сеть».
Поэтому мы должны объявить значение output в «сетевом» модуле, чтобы экспортировать его ресурс или атрибут ресурса в другие модули.
Имена output и variable могут отличаться, но для ясности я предлагаю использовать одни и те же имена.
Это явное объявление вывода — это способ предоставить некоторый ресурс (или информацию о нем) извне — в область видимости «корневого» модуля, чтобы сделать его доступным для других модулей.
Затем, когда мы вызываем дочерний модуль «сервер» в корневом модуле, мы должны назначить вывод из «сетевого» модуля переменной модуля «сервер»:
Обратите внимание на выходной адрес ‘ network_id ‘ здесь — мы указываем, где он находится
Вот как будет выглядеть окончательный код для вызова наших дочерних модулей:
В этом примере конфигурации будет создано 5 экземпляров одного и того же сервера со всеми необходимыми ресурсами в сети, которую мы создали как отдельный модуль.
Подведение итогов
Теперь вы должны понять, что такое модули и для чего они нужны.
Если вы находитесь в самом начале пути к Terraform, вот несколько советов по дальнейшим действиям.
Я рекомендую вам ознакомиться с этим коротким руководством от HashiCorp, создателя Terraform, о модулях: «Organize Configuration».
Кроме того, есть отличное комплексное учебное пособие, охватывающее все, от новичка до продвинутых понятий о Terraform: «Study Guide — Terraform Associate Certification».
Модульная структура кода делает вашу конфигурацию более гибкой и простой для понимания другими. Последнее особенно полезно для команды.
Если вам понравилась статья, подпишитесь на меня в Twitter (@vasylenko), где я иногда делюсь своими выводами и советами по Terraform, AWS, Ansible и другим технологиям, связанным с DevOps.
Terraform что это простыми словами
Terraform — это open-source программное обеспечение Infrastructure as code (IaC) или по-русски «инфраструктура как код», созданное HashiCorp. Это ПО позволяет администраторам описывать и разворачивать инфраструктуру ЦОД в облачных сервисах с помощью высокоуровневого языка конфигурации, известного как Hashicorp Configuration Language (HCL) или, опционально, JSON. Terraform поддерживает ряд поставщиков облачной инфраструктуры, таких как Amazon Web Services (AWS), IBM Cloud (ранее Bluemix), Google Cloud Platform (GCP), DigitalOcean, Linode, Microsoft Azure, Oracle Cloud Infrastructure, OVH, Scaleway, VMware vSphere или Open Telekom Cloud, а также OpenNebula и OpenStack.
При запуске Terraform читает код и, используя представленные провайдерами облачного сервиса плагины, приводит вашу инфраструктуру к описанному состоянию, совершая необходимые в
ызовы к API. Если перенести управление инфраструктурой в текстовые файлы, то открывается возможность вооружиться всеми излюбленными инструментами для управления исходным кодом и процессами, после чего нацелить их для работы с инфраструктурой. Теперь инфраструктура подчиняется системам контроля версий, точно как исходный код, ее можно точно так же рецензировать или откатывать к более раннему состоянию, если что-нибудь пойдет неправильно.
Так как Terraform это решение с открытым кодом, его развитие поддерживается большим и непрерывно растущим сообществом разработчиков. Terraform, несомненно, крут, и со временем станет только лучше. Эта утилита не станет “убийцей” Salt, Ansible, или Puppet, но по праву займет достойное место в инструментарии любого DevOps инженера.
Организации, стремящиеся к более четкому распределению обязанностей или автоматическому применению политики, могут приобрести обновления команд и управления для Terraform Cloud. Terraform Cloud — это бесплатное приложение SaaS, которое обеспечивает наилучший рабочий процесс для написания и построения инфраструктуры в виде кода с помощью Terraform.
Terraform делает только одну задачу. И делает её хорошо. Задача эта: создать, собрать и настроить ресурсы. Любые ресурсы, которые можно описать в виде набора свойств, понятных провайдеру этих самых ресурсов. В первую очередь речь идёт о ресурсах наших вычислительных облаков. 
Terraform — это не есть единое API для всех облаков. За единым API необходимо прибегнуть к Kubernetes. Terraform — это единый способ описания ресурсов. И даже, возможно, сразу в нескольких облаках. Но вот сами типы ресурсов, их имена и атрибуты, будут в каждом облаке свои.
Явные преимущества состоят в следующих пунктах:
Terraform 12 и Terragrunt и как это можно применять для Multi-Cloud-инфраструктуры. Александр Довнар
Что такое 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 используется для описания инфраструктуры 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:
Часто ли в практике приходится использовать DataSource?
(Александр) Да, потому что часто нужно запросить такую информацию, которая не под Terraform. Например, мы хотим покрыть нашими subnets в Amazon все доступные availability-зоны. Мы можем использовать специальные DataSource, которые нам дадут все доступные на данный момент availability-зоны. С помощью exclude, include мы можем этим манипулировать и использовать этот список в своем Terraform-коде.
(Виктор) И в том числе, если какая-то инфраструктура по тем или иным причинам была создана руками, мы можем с ней взаимодействовать, используя DataSource?
(Александр) Все верно.
Как с помощью Terraform пересоздать ресурс без изменения конфигурации?
Поясни, что делает taint.
(Александр) Taint как раз и нужен для таких целей. По сути, он помечает ресурс как то, что должно пересоздаться. Допустим, надо пересоздать машину. Но у нас в ней конфигурация не меняется. Мы делаем taint этого ресурса. И при следующем запуске Terraform, он для себя будет понимать, что ее надо пересоздать, потому что мы этого захотели.
(Виктор) А если в ресурсе, который мы хотим пересоздать, например, в виртуалке, есть какие-то зависимые вещи? Например, диски мы подключаем, интерфейсы настраиваем или что-то еще. Он контролирует только сам этот ресурс или еще пересоздаст?
(Александр) Если мы будем запускать полноценные plan, apply, то такие вещи, как диск, который аттачится к машине, тоже будет обновлен, потому что в нем поменялась машина, на которую он аттачит. И ID каждый раз будет новым.
(Виктор) Результат нашего quiz. Человек за 19 секунд ответил на 5 вопросов. Это Экссметана. Мы с тобой свяжемся. Промокод на пиццу будет передан. И судя потому что человек смог ответить на 3 вопроса правильно, а все остальные еще меньше, то я думаю, что доклад должен быть интересен. Саша, передаю тебе слово.
(Александр) О чем я хочу рассказать? Хочу рассказать о том, что такое Terraform, Terragrunt и как это все можно использовать как для Multi-Cloud deployment, так и для любых других задач.
Для начала я расскажу немножко о себе:
О чем мы сегодня будем говорить?
Это QR-соды, которые позволят ориентироваться по ходу доклада. Можно посмотреть на исходный код. Также сейчас задеплоен PreProd Demo site. И в рамках нашего доклада мы будем деплоить production. Можно ссылочки открыть и увидеть, что там есть. Я потом чуть подробней об этом расскажу.
Саша, у меня еще один вопрос, который я не успел задать. У тебя в названии написано «Terraform 12». А вроде бы даже первого релиза не было. Почему так?
Я покажу слайд из последнего доклада HashiConf, где как раз был такой вопрос. И там немножко расписано на примере Packer. Это другая утилита от HashiCorp. И там расписано, что нужно для того, чтобы в HashiCorp сказали, что она готова быть 1.0. Я для упрощения убрал нолик, но подробней об этом мы чуть позже поговорим.
(Виктор) Судя по тому, сколько уже Terraform существует, он уже действительно, скорее всего, уже 12-ой версии.
(Александр) Именно так.
Небольшой дисклеймер, т. е. тот исходный код, который вы видели, нужен только для того, чтобы сделать это демо. Какие-то вещи там можно использовать для реальных проектов. Я постарался максимально раскрыть функционал и возможности, которые есть как в Terragrunt, так и в Terraform с точки зрения модулей и Multi-Cloud взаимодействия. Но это не real production, т. е. всегда вчитываться и переносить в environment ваш проект надо с большой аккуратностью.
И также вы можете задавать вопросы в Телеграме, на которые мы постараемся ответить. И также можете по моим контактным данным меня найти и задать вопрос, я всегда рад помочь. Я готов делиться знаниями и опытом.
Начнем с того, почему я здесь.
Виктор мне предложил рассказать про 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, наверное, тоже хорошие предоставляет сервисы. Но не удалось с ними поработать, к сожалению.
Какие challenges у компаний есть?
Про 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. И он деплоится одинаковыми абстракциями.
(Виктор) Один модуль для всех?
(Виктор) И какой ресурс?
(Виктор) Но все равно у тебя каждый объект описывается по-своему.
(Александр) Внутри модуля да, но я предоставляю уровень абстракции, который позволяет пользователю передать какой-то параметр. Это один из моментов, который я хотел проверить, потому что я так не делал. И, я думаю, что получилось интересно.
Что еще сказать про 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 сказать?
Подходов море, фреймворков море. Даже сервисов море, которые могут это делать под капотом.
И что является результатом 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, в котором много чего поменялось.
Чего в первую очередь коснулись изменения?
У 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.
Сейчас 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, потом был Bash, потом Python, который в итоге, как на картинке видно, составил 690 строк кода. Это Python, который запускал Terraform. И мы в последствие пришли к Terragrunt.
Вот так примерно выглядела бы наша структура, если бы мы использовали чистый Terraform:
Чтобы нам применить в Multi-Cloud Terraform, нам бы пришлось писать вот такие командные строки, которые не очень читабельные и не очень запоминаются. И у нас будет большой Notepad, где будет все это переходить копи-пастом. И в случае изменений будет больно.
И тут у нас приходит Terragrunt. Terragrunt – это тоже golang tool, но просто cli, который выступает оберткой над Terraform. Даже не совсем над Terraform, но он вызывает Terraform.
На первых взгляд входной порог длинный. Я лично подходил к 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.
У нас есть репозиторий, который я показывал. В нем я уже нагенерировал структуру.
Как правильно ты сказал, у нас есть YAML, который общий для всего environment, где описаны общие переменные.
Тут описаны такие вещи, как cloud abstractions, как регион. А также такие вещи, которые нужны для кода в целом.
Также здесь есть уже готовый preprod. У него есть environment.yaml, в котором описана специфика environment, т. е. cidr, subnet, instance_size, location и наименование.
Тут можно долго по коду бегать. Это будет долго. Я перейду к идее.
У меня есть 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 и версионирование модулей, потому что он правильный. Я чувствую боль этого человека. И если человеку интересно, то я готов в рамках своего интереса предложить какое-то решение, которое, возможно, человеку в голову не пришло. Я готов максимально помочь в этом.
(Виктор) Саша, спасибо огромное! Мне кажется, доклад получился очень интересным! Спасибо большое за подготовку!