[Системное администрирование, Системное программирование, DevOps] Что такое модули Terraform и как они работают? (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Многие новички пропускают настройку модулей Terraform, чтобы облегчить процесс настройки. По крайней мере, они так думают, что облегчили себе задачу. Рассмотрим что такое модули Terraform и как они работают.
Я предполагаю, что вы уже знаете некоторые основы Terraform и даже пытались использовать его раньше. Если нет, ознакомьтесь с этим обзором Terraform и этим видеоуроком, прежде чем продолжить чтение.
Обратите внимание: я намеренно не использую реальные примеры кода с некоторыми конкретными поставщиками, такими как AWS или Google для простоты понимания.
Модули Terraform
Вы уже пишете модули
Даже если вы не создаете модуль намеренно, если вы используете Terraform, вы уже пишете модуль — так называемый «корневой» модуль.
Любой файл конфигурации Terraform (.tf) в каталоге, даже один, образует модуль.
Что делает модуль?
Модуль Terraform позволяет вам создавать логическую абстракцию поверх некоторого набора ресурсов. Другими словами, модуль позволяет вам группировать ресурсы вместе и повторно использовать эту группу позже, возможно, много раз.
Предположим, у нас есть виртуальный сервер с некоторыми функциями, размещенными в облаке. Какой набор ресурсов может описывать этот сервер? Например:
- сама виртуальная машина, созданная из некоторого образа
- подключенное блочное устройство указанного размера для дополнительного хранилища
- статический общедоступный IP-адрес, сопоставленный с виртуальным сетевым интерфейсом сервера
- набор правил брандмауэра, который будет прикреплен к серверу
- другие вещи, такие как другое блочное устройство, дополнительный сетевой интерфейс и т. д.
Теперь предположим, что вам нужно создать этот сервер с набором ресурсов много раз. Именно здесь модули действительно полезны. Вы же не хотите повторять один и тот же код конфигурации снова и снова, не так ли?
Вот пример, показывающий, как может быть вызван наш «серверный» модуль.
«Вызвать модуль» означает использовать его в файле конфигурации.
Здесь мы создаем 5 экземпляров «сервера», используя единый набор конфигураций (в модуле):
module "server" {
count = 5
source = "./module_server"
some_variable = some_value
}
Terraform поддерживает "счетчик" для модулей, начиная с версии 0.13.
Организация модуля: дочерний и корневой
Конечно, вы, вероятно, захотите создать более одного модуля. Вот несколько распространенных примеров:
- сеть, подобная виртуальному частному облаку (VPC)
- хостинг статического контента (т.е. bucket)
- балансировщик нагрузки и связанные с ним ресурсы
- конфигурация журналирования
- или что-то еще, что вы считаете отдельным логическим компонентом инфраструктуры
Допустим, у нас есть два разных модуля: «серверный» модуль и «сетевой» модуль. В модуле под названием «сеть» мы определяем и настраиваем нашу виртуальную сеть и размещаем в ней серверы:
module "server" {
source = "./module_server"
some_variable = some_value
}
module "network" {
source = "./module_network"
some_other_variable = some_other_value
}
Два разных дочерних модуля, вызываемые в корневом модуле
Когда у нас есть несколько настраиваемых модулей, мы можем называть их «дочерними» модулями. А файл конфигурации, в котором мы вызываем дочерние модули, относится к корневому модулю.
Дочерний модуль может быть получен из нескольких мест:
- локальные пути
- официальный реестр Terraform — если вы знакомы с другими реестрами, такими как реестр Docker, то вы уже понимаете идею
- репозиторий Git (пользовательский или GitHub/BitBucket)
- HTTP URL-адрес архива .zip с модулем
Но как передать сведения о ресурсах между модулями?
В нашем примере серверы должны быть созданы в сети. Итак, как мы можем сказать «серверному» модулю создавать виртуальные машины в сети, которая была создана в модуле «сеть»?
Вот тут и появляется инкапсуляция.
Инкапсуляция модуля
Инкапсуляция в Terraform состоит из двух основных концепций: области модуля и явного доступа к ресурсам.
Scope (область видимости) модуля
Все экземпляры ресурсов, имена и, следовательно, видимость ресурсов изолированы в области действия модуля. Например, модуль «A» по умолчанию не видит и не знает о ресурсах в модуле «B».
Видимость ресурсов, иногда называемая изоляцией ресурсов, гарантирует, что ресурсы будут иметь уникальные имена в пространстве имен модуля. Например, с нашими 5 экземплярами модуля «сервер»:
module.server[0].resource_type.resource_name
module.server[1].resource_type.resource_name
module.server[2].resource_type.resource_name
...
Адреса ресурсов модуля, созданные с помощью мета-аргумента count
С другой стороны, мы могли бы создать два экземпляра одного и того же модуля с разными именами:
module "server-alpha" {
source = "./module_server"
some_variable = some_value
}
module "server-beta" {
source = "./module_server"
some_variable = some_value
}
Обратите внимание на аргумент источника — он остается прежним, это тот же исходный модуль
В этом случае имя или адрес ресурсов будет следующим:
module.server-alpha.resource_type.resource_name
module.server-beta.resource_type.resource_name
Явное раскрытие ресурсов
Если вы хотите получить доступ к некоторым сведениям о ресурсах в другом модуле, вам необходимо настроить это.
По умолчанию наш модуль «сервер» не знает о сети, которая была создана в модуле «сеть».
Поэтому мы должны объявить значение output в «сетевом» модуле, чтобы экспортировать его ресурс или атрибут ресурса в другие модули.
Модуль «сервер» должен объявить variable, которая будет использоваться позже в качестве входных данных:
Имена output и variable могут отличаться, но для ясности я предлагаю использовать одни и те же имена.
Это явное объявление вывода — это способ предоставить некоторый ресурс (или информацию о нем) извне — в область видимости «корневого» модуля, чтобы сделать его доступным для других модулей.
Затем, когда мы вызываем дочерний модуль «сервер» в корневом модуле, мы должны назначить вывод из «сетевого» модуля переменной модуля «сервер»:
network_id = module.network.network_id
Обратите внимание на выходной адрес 'network_id' здесь — мы указываем, где он находится
Вот как будет выглядеть окончательный код для вызова наших дочерних модулей:
module "server" {
count = 5
source = "./module_server"
some_variable = some_value
network_id = module.network.network_id
}
module "network" {
source = "./module_network"
some_other_variable = some_other_value
}
В этом примере конфигурации будет создано 5 экземпляров одного и того же сервера со всеми необходимыми ресурсами в сети, которую мы создали как отдельный модуль.
Подведение итогов
Теперь вы должны понять, что такое модули и для чего они нужны.
Если вы находитесь в самом начале пути к Terraform, вот несколько советов по дальнейшим действиям.
Я рекомендую вам ознакомиться с этим коротким руководством от HashiCorp, создателя Terraform, о модулях: "Organize Configuration".
Кроме того, есть отличное комплексное учебное пособие, охватывающее все, от новичка до продвинутых понятий о Terraform: "Study Guide — Terraform Associate Certification".
Модульная структура кода делает вашу конфигурацию более гибкой и простой для понимания другими. Последнее особенно полезно для команды.
Если вам понравилась статья, подпишитесь на меня в Twitter (@vasylenko), где я иногда делюсь своими выводами и советами по Terraform, AWS, Ansible и другим технологиям, связанным с DevOps.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Serhii Vasylenko
===========Похожие новости:
- [Управление проектами] Как настроить дашборды в Azure DevOps, чтобы они приносили пользу
- [Системное администрирование, Серверное администрирование, Резервное копирование, Софт] Детектив с Кластером Hyper-V: шаг за шагом ищем решение проблемы
- [IT-инфраструктура, Apache, Big Data, DevOps] Итоговый проект для видеокурса и подкаст «Проблемная Kafka»
- [Информационная безопасность, WordPress, Разработка веб-сайтов, Системное администрирование, Контекстная реклама] WordPress автоматически отключит Google FLoC на веб-сайтах
- [Управление проектами, Agile, Развитие стартапа, DevOps, Удалённая работа] Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)
- [Open source, DevOps, Kubernetes] Чистка GitLab Registry для Kubernetes админов
- [Системное администрирование, PostgreSQL, Администрирование баз данных] Noisia — генератор аварийных и нештатных ситуаций в PostgreSQL
- [ERP-системы] OpenSAP или чему можно учиться бесплатно в мире SAP
- [Системное администрирование, Разработка под Windows, Дизайн, Софт] Показания загруженности процессора в диспетчере задач ни о чем на самом деле не говорят (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом, DevOps] Практика создания единого шаблона проектов на базе Azure DevOps (TFS)
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_sistemnoe_programmirovanie (Системное программирование), #_devops, #_terraform, #_sistemnoe_administrirovanie (
Системное администрирование
), #_sistemnoe_programmirovanie (
Системное программирование
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 02:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Многие новички пропускают настройку модулей Terraform, чтобы облегчить процесс настройки. По крайней мере, они так думают, что облегчили себе задачу. Рассмотрим что такое модули Terraform и как они работают. Я предполагаю, что вы уже знаете некоторые основы Terraform и даже пытались использовать его раньше. Если нет, ознакомьтесь с этим обзором Terraform и этим видеоуроком, прежде чем продолжить чтение. Обратите внимание: я намеренно не использую реальные примеры кода с некоторыми конкретными поставщиками, такими как AWS или Google для простоты понимания. Модули Terraform Вы уже пишете модули Даже если вы не создаете модуль намеренно, если вы используете Terraform, вы уже пишете модуль — так называемый «корневой» модуль. Любой файл конфигурации Terraform (.tf) в каталоге, даже один, образует модуль. Что делает модуль? Модуль Terraform позволяет вам создавать логическую абстракцию поверх некоторого набора ресурсов. Другими словами, модуль позволяет вам группировать ресурсы вместе и повторно использовать эту группу позже, возможно, много раз. Предположим, у нас есть виртуальный сервер с некоторыми функциями, размещенными в облаке. Какой набор ресурсов может описывать этот сервер? Например:
 Теперь предположим, что вам нужно создать этот сервер с набором ресурсов много раз. Именно здесь модули действительно полезны. Вы же не хотите повторять один и тот же код конфигурации снова и снова, не так ли? Вот пример, показывающий, как может быть вызван наш «серверный» модуль. «Вызвать модуль» означает использовать его в файле конфигурации. Здесь мы создаем 5 экземпляров «сервера», используя единый набор конфигураций (в модуле): module "server" {
count = 5 source = "./module_server" some_variable = some_value } Terraform поддерживает "счетчик" для модулей, начиная с версии 0.13. Организация модуля: дочерний и корневой Конечно, вы, вероятно, захотите создать более одного модуля. Вот несколько распространенных примеров:
Допустим, у нас есть два разных модуля: «серверный» модуль и «сетевой» модуль. В модуле под названием «сеть» мы определяем и настраиваем нашу виртуальную сеть и размещаем в ней серверы: module "server" {
source = "./module_server" some_variable = some_value } module "network" { source = "./module_network" some_other_variable = some_other_value } Два разных дочерних модуля, вызываемые в корневом модуле Когда у нас есть несколько настраиваемых модулей, мы можем называть их «дочерними» модулями. А файл конфигурации, в котором мы вызываем дочерние модули, относится к корневому модулю.  Дочерний модуль может быть получен из нескольких мест:
Но как передать сведения о ресурсах между модулями? В нашем примере серверы должны быть созданы в сети. Итак, как мы можем сказать «серверному» модулю создавать виртуальные машины в сети, которая была создана в модуле «сеть»? Вот тут и появляется инкапсуляция. Инкапсуляция модуля Инкапсуляция в Terraform состоит из двух основных концепций: области модуля и явного доступа к ресурсам. Scope (область видимости) модуля Все экземпляры ресурсов, имена и, следовательно, видимость ресурсов изолированы в области действия модуля. Например, модуль «A» по умолчанию не видит и не знает о ресурсах в модуле «B». Видимость ресурсов, иногда называемая изоляцией ресурсов, гарантирует, что ресурсы будут иметь уникальные имена в пространстве имен модуля. Например, с нашими 5 экземплярами модуля «сервер»: module.server[0].resource_type.resource_name
module.server[1].resource_type.resource_name module.server[2].resource_type.resource_name ... Адреса ресурсов модуля, созданные с помощью мета-аргумента count С другой стороны, мы могли бы создать два экземпляра одного и того же модуля с разными именами: module "server-alpha" {
source = "./module_server" some_variable = some_value } module "server-beta" { source = "./module_server" some_variable = some_value } Обратите внимание на аргумент источника — он остается прежним, это тот же исходный модуль В этом случае имя или адрес ресурсов будет следующим: module.server-alpha.resource_type.resource_name
module.server-beta.resource_type.resource_name Явное раскрытие ресурсов Если вы хотите получить доступ к некоторым сведениям о ресурсах в другом модуле, вам необходимо настроить это. По умолчанию наш модуль «сервер» не знает о сети, которая была создана в модуле «сеть».  Поэтому мы должны объявить значение output в «сетевом» модуле, чтобы экспортировать его ресурс или атрибут ресурса в другие модули. Модуль «сервер» должен объявить variable, которая будет использоваться позже в качестве входных данных:  Имена output и variable могут отличаться, но для ясности я предлагаю использовать одни и те же имена. Это явное объявление вывода — это способ предоставить некоторый ресурс (или информацию о нем) извне — в область видимости «корневого» модуля, чтобы сделать его доступным для других модулей. Затем, когда мы вызываем дочерний модуль «сервер» в корневом модуле, мы должны назначить вывод из «сетевого» модуля переменной модуля «сервер»: network_id = module.network.network_id
Обратите внимание на выходной адрес 'network_id' здесь — мы указываем, где он находится Вот как будет выглядеть окончательный код для вызова наших дочерних модулей: module "server" {
count = 5 source = "./module_server" some_variable = some_value network_id = module.network.network_id } module "network" { source = "./module_network" some_other_variable = some_other_value } В этом примере конфигурации будет создано 5 экземпляров одного и того же сервера со всеми необходимыми ресурсами в сети, которую мы создали как отдельный модуль. Подведение итогов Теперь вы должны понять, что такое модули и для чего они нужны. Если вы находитесь в самом начале пути к Terraform, вот несколько советов по дальнейшим действиям. Я рекомендую вам ознакомиться с этим коротким руководством от HashiCorp, создателя Terraform, о модулях: "Organize Configuration". Кроме того, есть отличное комплексное учебное пособие, охватывающее все, от новичка до продвинутых понятий о Terraform: "Study Guide — Terraform Associate Certification". Модульная структура кода делает вашу конфигурацию более гибкой и простой для понимания другими. Последнее особенно полезно для команды. Если вам понравилась статья, подпишитесь на меня в Twitter (@vasylenko), где я иногда делюсь своими выводами и советами по Terraform, AWS, Ansible и другим технологиям, связанным с DevOps. =========== Источник: habr.com =========== =========== Автор оригинала: Serhii Vasylenko ===========Похожие новости:
Системное администрирование ), #_sistemnoe_programmirovanie ( Системное программирование ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 02:29
Часовой пояс: UTC + 5