Last updated
Офіційна документація Terraform описує . Уважно прочитайте її, щоб зрозуміти решту цього розділу.
У цьому розділі описуються ключові поняття, які використовуються в книзі.
Ресурс - це aws_vpc, aws_db_instance і т.д. Ресурс належить провайдеру, включаючи аргументи, вихідні дані; він також має життєвий цикл . Ресурс можна створювати, отримувати, оновлювати та видаляти.
Ресурсний модуль - це колекція підключених ресурсів, які разом виконують спільну дію (наприклад, створює VPC, сабнети, NAT gateway і т.д.). Він залежить від конфігурації провайдера, яка може бути визначена в ньому або в структурах вищого рівня (наприклад, в модулі інфраструктури).
Інфраструктурний модуль - це колекція ресурсних модулів, які можуть бути логічно не підключені, але в поточній ситуації/проекті/налаштуваннях служать єдиній меті. Він визначає конфігурацію для провайдерів, які передаються до поточних ресурсних модулів і до ресурсів. Зазвичай він обмежується роботою в одній сутності на один логічний роздільник (наприклад, AWS регіон, Google проект).
Наприклад, модуль використовує ресурсні модулі ( та ) щоб керувати інфраструктурою, необхідною для роботи на .
Інший приклад - , де численні модулі використовуються разом для керування інфраструктурою, а також для використання ресурсів Docker, щоб мати змогу створювати, пушати та розгортати образи Docker. Все в одному наборі.
Композиція - це колекція інфраструктурних модулів, які можуть охоплювати декілька логічно відокремлених областей (наприклад, декілька AWS регіонів або декілька AWS акаунтів). Композиція використовується для опису повної інфраструктури, необхідної для всієї організації або проекту.
Композиція складається з інфраструктурних модулів, які, в свою чергу, складаються з ресурсних модулів, які потім реалізують індивідуальні ресурси.
Джерело даних виконує лише read-only операції та залежить від конфігурації постачальника, використовується в ресурсних та інфраструктурних модулях.
Джерело даних terraform_remote_state діє як з'єднувальник для модулів і композицій вищого рівня.
Провайдери, постачальники та деякі інші терміни дуже добре описані в офіційній документації, тому немає сенсу повторювати їх тут. На мою думку вони мають мало спільного з написанням якісних Terraform модулів.
Доступ до даних між молекулами (ресурсними та інфраструктурними модулями) здійснюється за допомогою вихідних даних модулів та джерел даних.
Якщо спробувати описати вище зазначені поняття у псевдовідношеннях, це може виглядати так:
data source дозволяє зовнішній програмі діяти, відкриваючи довільні дані для використання в інших місцях конфігурації Terraform. Як приклад можна назвати , де ім'я файлу обчислюється шляхом виклику зовнішнього Python скрипта.
Інший приклад - джерело даних робить HTTP GET запит на заданий URL і експортує інформацію про відповідь, яка часто корисна для отримання інформації з кінцевих точок, де рідний Terraform провайдер не існує.
Інфраструктурні модулі та композиції повинні зберігати свої у віддаленому місці, де їх зможуть отримати інші керованим способом (наприклад через ACL, версії, журналювання).
У той час як окремі ресурси – це атоми в інфраструктурі, ресурсні модулі - це молекули. Модуль — це найменший версійний блок, який можна спільно використовувати. Він має точний список аргументів, реалізує базову логіку, щоб виконувати потрібну функцію. Наприклад, модуль створює aws_security_group і aws_security_group_rule ресурси на основі вхідних даних. Цей ресурсний модуль сам по собі можна використовувати разом з іншими модулями для створення модуля інфраструктури.
Доступ між композиціями часто виконується використовуючи віддалений стан джерел даних. Існує .
