Ключові концепції

Офіційна документація Terraform описує всі аспекти конфігурації в деталях. Уважно прочитайте її, щоб зрозуміти решту цього розділу.

У цьому розділі описуються ключові поняття, які використовуються в книзі.

Ресурс

Ресурс - це aws_vpc, aws_db_instance і т.д. Ресурс належить провайдеру, включаючи аргументи, вихідні дані; він також має життєвий цикл . Ресурс можна створювати, отримувати, оновлювати та видаляти.

Ресурсний модуль

Ресурсний модуль - це колекція підключених ресурсів, які разом виконують спільну дію (наприклад, AWS VPC Terraform module створює VPC, сабнети, NAT gateway і т.д.). Він залежить від конфігурації провайдера, яка може бути визначена в ньому або в структурах вищого рівня (наприклад, в модулі інфраструктури).

Інфраструктурний модуль

Інфраструктурний модуль - це колекція ресурсних модулів, які можуть бути логічно не підключені, але в поточній ситуації/проекті/налаштуваннях служать єдиній меті. Він визначає конфігурацію для провайдерів, які передаються до поточних ресурсних модулів і до ресурсів. Зазвичай він обмежується роботою в одній сутності на один логічний роздільник (наприклад, AWS регіон, Google проект).

Наприклад, terraform-aws-atlantis модуль використовує ресурсні модулі (terraform-aws-vpc та terraform-aws-security-group) щоб керувати інфраструктурою, необхідною для роботи Atlantis на AWS Fargate.

Інший приклад - terraform-aws-cloudquery, де численні модулі terraform-aws-modules використовуються разом для керування інфраструктурою, а також для використання ресурсів Docker, щоб мати змогу створювати, пушати та розгортати образи Docker. Все в одному наборі.

Композиція

Композиція - це колекція інфраструктурних модулів, які можуть охоплювати декілька логічно відокремлених областей (наприклад, декілька AWS регіонів або декілька AWS акаунтів). Композиція використовується для опису повної інфраструктури, необхідної для всієї організації або проекту.

Композиція складається з інфраструктурних модулів, які, в свою чергу, складаються з ресурсних модулів, які потім реалізують індивідуальні ресурси.

Simple infrastructure composition

Джерело даних (data source)

Джерело даних виконує лише read-only операції та залежить від конфігурації постачальника, використовується в ресурсних та інфраструктурних модулях.

Джерело даних terraform_remote_state діє як з'єднувальник для модулів і композицій вищого рівня.

External data source дозволяє зовнішній програмі діяти, відкриваючи довільні дані для використання в інших місцях конфігурації Terraform. Як приклад можна назвати terraform-aws-lambda module, де ім'я файлу обчислюється шляхом виклику зовнішнього Python скрипта.

Інший приклад - http джерело даних робить HTTP GET запит на заданий URL і експортує інформацію про відповідь, яка часто корисна для отримання інформації з кінцевих точок, де рідний Terraform провайдер не існує.

Віддалений стан

Інфраструктурні модулі та композиції повинні зберігати свої Terraform state у віддаленому місці, де їх зможуть отримати інші керованим способом (наприклад через ACL, версії, журналювання).

Провайдер, постачальник (provisioner) і т.д.

Провайдери, постачальники та деякі інші терміни дуже добре описані в офіційній документації, тому немає сенсу повторювати їх тут. На мою думку вони мають мало спільного з написанням якісних Terraform модулів.

Чому так важко?

У той час як окремі ресурси – це атоми в інфраструктурі, ресурсні модулі - це молекули. Модуль — це найменший версійний блок, який можна спільно використовувати. Він має точний список аргументів, реалізує базову логіку, щоб виконувати потрібну функцію. Наприклад, terraform-aws-security-group модуль створює aws_security_group і aws_security_group_rule ресурси на основі вхідних даних. Цей ресурсний модуль сам по собі можна використовувати разом з іншими модулями для створення модуля інфраструктури.

Доступ до даних між молекулами (ресурсними та інфраструктурними модулями) здійснюється за допомогою вихідних даних модулів та джерел даних.

Доступ між композиціями часто виконується використовуючи віддалений стан джерел даних. Існує багато способів обмінюватися даними між конфігураціями.

Якщо спробувати описати вище зазначені поняття у псевдовідношеннях, це може виглядати так:

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }

}