Terraform & HCL Vocabulary: 30 Terms for Infrastructure as Code (англійською)

Інфраструктура як код (IaC) трансформувала те, як команди управляють хмарною інфраструктурою, і Terraform, з його синтаксисом HCL (HashiCorp Configuration Language), є домінуючим інструментом. Незалежно від того, пишете ви Terraform самостійно, переглядаєте запити на зміни інфраструктури або працюєте разом з інженером DevOps, цей словник допоможе вам слідкувати за розмовою і чітко робити свій внесок.

---

Будівельні блоки HCL

Resource

** Ресурс ** є найважливішим елементом у Terraform. Він представляє один об’ єкт інфраструктури — віртуальну машину, базу даних, запис DNS, контейнер для зберігання. Ресурси декларуються з блоком resource.

“Ми повинні додати ресурс aws_s3_bucket для статичних активів. Кожен ресурс в Terraform відображається на один об’єкт інфраструктури»

Джерело даних

** джерело даних ** (задеклароване символом data ) надає вам змогу отримати інформацію про існуючу інфраструктуру, якою Terraform не керує. Ви читаєте його, але не створюєте і не змінюєте.

«Ми використовуємо блок data, щоб пошукати існуючий VPC за тегами — ми не хочемо, щоб Terraform створив новий»

Variable

Змінна (заявлена з variable ) є вхідним параметром для конфігурації Terraform. Змінні роблять налаштування повторно використовуваними у різних середовищах.

Розмір екземпляра є змінною — передайте t3.small для dev і t3.xlarge для production

Output

** вивід ** (зазначений символом output ) показує значення з вашого налаштування Terraform, наприклад, IP- адресу або ідентифікатор ресурсу, щоб інші налаштування або користувачі могли їх використовувати.

«Ми виставляємо кінцеву точку бази даних як вивід, щоб команда застосунку могла посилатися на неї у своїй власній конфігурації Terraform»

Local

** local ** (зазначено символом locals ) — це обчислене значення, яке ви визначаєте один раз і на яке посилається декілька разів у конфігурації. Розглядайте його як локальну змінну для коду DRY.

«Ми визначили locals блок для спільних тегів, тому ми не повторюємо їх в кожному ресурсі»

---

Постачальники і держава

Provider

Provider це плагін, який взаємодіє з певним API хмари або сервісу — AWS, Google Cloud, Azure, Kubernetes, GitHub. Провайдери оголошуються в верхній частині конфігурації і завантажуються з terraform init.

«Ми додаємо cloudflare провайдера для керування DNS записами — нам потрібно додати його до блоку required_providers і запустити terraform init.»

Державний архів

Файл state ( terraform.tfstate ) — це файл JSON, який відстежує поточний стан вашої керованої інфраструктури. Terraform використовує його, щоб визначити, які зміни робити.

“Ніколи не редагуйте файл стану вручну. Якщо він пошкоджений, відновлення управління інфраструктурою може бути болісним»

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

** Віддалений стан ** зберігає файл стану у спільному сервері — S3, Terraform Cloud, GCS — а не локально. Необхідно для команд: тільки одна людина може мати блокування стану водночас.

«Ми перейшли до віддаленого стану в S3 з блокуванням DynamoDB — більше немає конфліктів, коли два інженери запускають terraform apply одночасно»

Налаштування сервера

** Сервер ** визначає, де зберігається файл стану і як виконуються дії. Налаштований в блоку backend всередині terraform { }.

«Наш бекенд налаштований на використання S3 для зберігання стану і DynamoDB для блокування стану.»

dependency_ lock. hcl

Файл .terraform.lock.hcl записує точні версії провайдерів, використовуваних у налаштуванні. Його слід передати до контролю версій, щоб всі члени команди використовували ті ж самі версії постачальника.

«Затвердити файл блокування — це забезпечує, що кожен у команді використовує ту ж саму версію постачальника AWS»

---

Робочі простори і модулі

Workspace

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

«Ми маємо три робочі простори Terraform: dev, staging, і prod. Запустити terraform workspace select prod перед застосуванням змін до виробництва»

Module

** модуль ** — це пакунок налаштувань Terraform, який можна використовувати повторно. * Кореневий модуль * — це основні налаштування, які ви застосовуєте; * дочірні модулі * — це будівельні блоки, які можна використовувати знову і знову.

«Ми побудували vpc модуль, який ми викликаємо з кожного середовища — одне визначення, використане три рази»

Виклик модуля

Ви ** викликаєте ** модуль з блоком module, передаючи вхідні змінні. Модуль інкапсулює ресурси і виводить їх.

«Ми викликаємо модуль rds-cluster з instance_class = var.db_size — модуль обробляє решту.»

Створення модуля

Коли ви ** створюєте модуль **, ви створюєте теку з власними variables.tf, main.tf і outputs.tf. Конвенція зберігає вхідні дані, ресурси і вихідні дані чітко відокремлені.

---

Центр об’єднаної територіальної громади

Ініціалізація Terraform

** terraform init ** звантажує постачальників, налаштовує сервер і підготовлює робочий каталог. Завжди запускати цей пункт після клонування сховища або додавання нового постачальника.

Перевірка терраформи

** terraform validate ** перевіряє налаштування на наявність синтаксичних помилок і внутрішню послідовність — без з’ єднання з будь- яким постачальником.

Завжди виконуйте terraform validate в CI перед запуском plan — це негайно ловить синтаксичне помилки

terraform fmt

** terraform fmt ** форматує код HCL у канонічний стиль. Запуск у CI зберігає кодове форматування послідовним у всій команді.

План Терраформи

** terraform plan ** обчислює і показує, які зміни Terraform зробить, якщо його застосувати. Він не робить ніяких змін — це сухий запуск.

“Завжди переглядайте вихід плану перед застосуванням. Подивіться на несподівані руйнування — вони можуть викликати перерви»

Терраформа застосовується

** terraform apply ** виконує заплановані зміни у реальній інфраструктурі. Він запитує підтвердження, якщо ви не передали -auto-approve.

Терраформу знищити

** terraform destroy ** вилучає всю інфраструктуру, якою керує поточне налаштування. Обробляйте з особливою обережністю при виробництві.

«Ми запустили terraform destroy на стадіонному середовищі в кінці спринту, щоб уникнути непотрібних хмарних витрат»

Імпорт Terraform

** terraform import ** передає існуючий ресурс інфраструктури під керування Terraform, пов’ язавши його з блоком ресурсів.

“Балансир навантаження був створений вручну. Ми import -ed його в Terraform, так що майбутні зміни проходять через перегляд коду. “

---

Просунуті шаблони

Виявлення дрейфу

** Дрейф ** відбувається, коли справжній стан інфраструктури відрізняється від того, що записано у файлі стану — зазвичай, тому що хтось зробив зміну вручну поза Terraform. terraform plan показує дрейф.

«plan показує, що правило групи безпеки було додано вручну — це дрейф. Нам потрібно або імпортувати його, або видалити його»

count проти for_ each

** count ** створює декілька ідентичних копій ресурсу за допомогою цілого числа. ** for_each ** створює ресурси з карти або набору, надаючи кожній з них стабільний ключ. Віддавати перевагу for_each, коли елементи мають значущі ідентифікатори.

«Використовуйте for_each з мапою назв відділень, а не count з індексом — якщо ви вилучите відділення з середини, for_each тільки знищить це відділення; count знищить і відтворить все після нього»

Динамічний блок

** Динамічний блок ** створює повторювані вкладені блоки всередині ресурсу, заснованого на збірці — це корисно, якщо кількість піделементів змінюється.

«Ми використовували блок dynamic для правил вступу, тому ми можемо передати будь-яку кількість CIDR діапазонів як змінну.»

Змінні середовища в Terraform

Terraform читає змінні середовища з префіксом TF_VAR_ як вхідні змінні: TF_VAR_region=eu-west-1. Це стандартний спосіб передачі секретів і значень, специфічних для середовища, у конвеєрах CI.

Процитовано 2011-08-10.  Set TF_VAR_db_password in GitHub Actions secrets — never put passwords in .tfvars files that get committed

---

Фразеологічні сполучення

Phrase	Meaning
”Run a plan first”	Preview changes before applying them
”There’s drift in the state”	Real infrastructure differs from the state file
”The state is locked”	Another operation is running — wait for it to finish
”Refactor to a module”	Extract reusable config into a separate module
”The resource will be destroyed”	Terraform will delete and recreate that resource
”We need to import this”	Bring a manually created resource under Terraform management
”Pin the provider version”	Specify an exact version in required_providers to avoid surprises