Comment on page
Структура коду
Питання, пов’язані зі структурою коду Terraform, є найпоширенішими у спільноті. Кожен також думав про найкращу структуру коду для проекту.
Це одне з питань, де існує багато рішень і дуже важко дати якусь одну універсальну пораду, тож почнемо з розуміння того, з чим ми маємо справу.
- Яка складність вашого проекту?
- Кількість супутніх ресурсів
- Кількість Terraform провайдерів (див. примітку нижче про "логічних провайдерів")
- Як часто змінюється ваша інфраструктура?
- Від раз на місяць/тиждень/день
- До безперервно (щоразу, коли є новий коміт)
- Ініціатори зміни коду? Чи дозволяєте ви серверу CI оновлювати репозиторій, коли створюється новий артефакт?
- Тільки розробники можуть пушати до репозиторію інфраструктури
- Кожен може запропонувати змінити будь-що, відкривши PR (включаючи автоматизовані завдання, що виконуються на сервері CI)
- Яку платформу або сервіс для деплою ви використовуєте?
- AWS CodeDeploy, Kubernetes, чи OpenShift вимагає дещо іншого підходу
- Як згруповані середовища?
- За середовищем, регіоном, проектом
Ведення всього коду в
main.tf
- гарна ідея, якщо ви починаєте роботу або пишете приклад коду. У всіх інших випадках вам буде краще, якщо декілька файлів розділити логічно так:main.tf
- викликає modules, locals, а також data sources, щоб створювати всі ресурсиvariables.tf
- містить оголошення змінних, які використовуються вmain.tf
outputs.tf
- містить outputs з ресурсів, які були створені вmain.tf
versions.tf
- містить вимоги до версії для Terraform і провайдерів
Будь ласка, переконайтеся, що ви розумієте ключові поняття - ресурсний модуль, інтфраструктурний модуль, а також композицію, так як вони використовуються в наступних прикладах.
Загальні рекомендації щодо структурування коду
- З меншою кількістю ресурсів працювати легше і швидше
terraform plan
таterraform apply
обидва здійснюють виклики хм арного API для перевірки стану ресурсів- Якщо у вас вся інфраструктура в одній композиції, це може зайняти деякий час
- Радіус вибуху менший при меншій кількості ресурсів
- Ізоляція ресурсів, непов'язаних один від одного, шляхом розміщення їх в окремих композиціях, зменшує ризик, якщо щось піде не так
- Почніть свій проект, використовуючи віддалений стан, тому що:
- Ваш ноутбук – це не місце для джерела ресурсів усієї інфраструктури
- Управління файлом tfstate в git — кошмар
- Пізніше, коли рівні інфраструктури почнуть зростати в кількох напрямках (кількість залежностей або ресурсі в), буде легше тримати все під контролем.
- Як і процедурний код, код Terraform повинен бути написаний для того, щоб люди спочатку прочитали; узгодженість допоможе потім, коли будуть зміни через шість місяців
- Можна переміщати ресурси у файлі стану Terraform, але це буде важче зробити, якщо у вас непослідовна структура та імена
- Робіть модулі ресурсів максимально простими
- Не "хардкодьте" значення, які можна передати через змінні або виявити за допомогою джерел даних
- Використовуйте джерела даних та
terraform_remote_state
спеціально як з'єднувальники між модулями інфраструктури у межах композиції
У цій книзі приклади проектів згруповано за складністю - від малих до дуже великих інфраструктур. Цей поділ не є суворим, тому перевірте також інші конструкції.
Наявність невеликої інфраструктури означає, що існує неве лика кількість залежностей і мало ресурсів. У міру розвитку проекту стає очевидною необхідність пов’язати виконання конфігурацій Terraform, під’єднуючи різні модулі інфраструктури та передаючи значення в межах композиції.
Існує принаймні 5 окремих груп рішень для оркестровки, які використовують розробники:
- 1.Лише Terraform. Дуже просто, розробники повинні знати тільки Terraform, щоб виконати роботу.
- 2.Terragrunt. Чистий інструмент оркестрування, який можна використовувати для оркестрування всієї інфраструктури, а також для обробки залежностей. Terragrunt працює з інфраструктурними модулями та композиціями, тому зменшує дублювання коду.
- 3.In-house скрипти. Часто це відбувається як відправна точка для оркестрування і перед відкриттям Terragrunt.
- 4.Ansible або подібний інструмент автоматизації загального призначення. Зазвичай використовується, коли Terraform адаптований після Ansible, або коли Ansible UI активно використовується.
- 5.Crossplane та інші Kubernetes-натхненні рішення. Іноді має сенс використовувати екосистему Kubernetes і використовувати функцію циклу узгодження для досягнення бажаного стану ваших конфігурацій Terraform. Перегляньте відео Crossplane vs Terraform для додаткової інформації.
З огляду на це, у книзі розглядаються перші два з цих структурних проектів, тобто лише Terraform і Terragrunt.
Last modified 1yr ago