Джерело: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
Цей приклад містить код як приклад структурування конфігурацій Terraform для інфраструктури середнього розміру, яка використовує:
2 AWS акаунти
2 окремих середовища (prod та stage,які не мають нічого спільного). Кожне середовище живе в окремому акаунті AWS
Кожне середовище використовує різну версію готового інфраструктурного модуля (alb), отриманого з Terraform Registry
Кожне середовище використовує одинакову версію модулів/мережі внутрішнього модуля, оскільки джерело отримане з локального каталогу
Ідеально підходить для проектів, де інфраструктура логічно розділена (окремі акаунти AWS)
Добре, коли немає необхідності змінювати ресурси, спільні для акаунтів AWS (одне середовище = один акаунт AWS = один файл стану)
Добре, коли немає потреби в оркестровці змін між середовищами
Добре, коли ресурси інфраструктури відрізняються для кожного середовища спеціально і не можуть бути узагальнені (наприклад, деякі ресурси відсутні в одному середовищі або в деяких регіонах)
Із розвитком проекту буде все важче підтримувати ці середовища в актуальному стані одне з одним. Подумайте про використання інфраструктурних модулів (готових або внутрішніх) для повторюваних завдань.
Джерело:
Цей приклад містить код як приклад структурування конфігурацій Terraform для інфраструктури великого розміру, яка використовує:
2 AWS акаунти
2 регіона
2 окремих середовища (prod та stage, у яких немає нічого спільного). Кожне середовище живе в окремому акаунті AWS і охоплює ресурси між 2 регіонами
Кожне середовище використовує різну версію готового інфраструктурного модуля (alb), отриманого з
Кожне середовище використовує одинакову версію модулів/мережі внутрішнього модуля, оскільки джерело отримане з локального каталогу.
У великому проекті, як описано тут, переваги використання Terragrunt стають дуже помітними. Перегляньте .
Ідеально підходить для проектів, де інфраструктура логічно розділена (окремі акаунти AWS)
Добре, коли немає необхідності змінювати ресурси, спільні між акаунтами AWS (одне середовище = один акаунт AWS = один файл стану)
Добре, коли немає потреби в оркестровці змін між середовищами
Добре, коли ресурси інфраструктури відрізняються для кожного середовища спеціально і не можуть бути узагальнені (наприклад, деякі ресурси відсутні в одному середовищі або в деяких регіонах)
Із розвитком проекту буде все важче підтримувати ці середовища в актуальному стані одне з одним. Подумайте про використання інфраструктурних модулів (готових або внутрішніх) для повторюваних завдань.
Мало ресурсів, немає зовнішніх залежностей. Єдиний AWS акаунт. Єдиний регіон. Єдине середовище.
Так
Декілька середовищ та AWS акаунтів, готові інфраструктурні модулі з використанням Terraform.
Так
Багато AWS акаунтів, багато регіонів, нагальна потреба скоротити копі-пасти, власні модулі інфраструктури, інтенсивне використання композицій. Використання Terraform.
WIP
Декілька провайдерів (AWS, GCP, Azure). Багатохмарне розгортання. Використання Terraform.
Ні
середня
Декілька акаунтів і середовищ AWS, готові інфраструктурні модулі, шаблони композиції за допомогою Terragrunt.
Ні
велика
Багато AWS акаунтів, багато регіонів, нагальна потреба скоротити копі-пасти, кастомні модулі інфраструктури, інтенсивне використання композицій. Використання Terragrunt.
Ні
дуже велика
Декілька постачальників (AWS, GCP, Azure). Багатохмарне розгортання. Використання Terragrunt.
Ні
Джерело: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Цей приклад містить код як приклад структурування конфігурацій Terraform для невеликої інфраструктури, де не використовуються зовнішні залежності.
Ідеально підходить для початку та реорганізації у процесі
Ідеально підходить для невеликих ресурсних модулів
Добре підходить для невеликих і лінійних інфраструктурних модулів (наприклад, terraform-aws-atlantis)
Добре для невеликої кількості ресурсів (менше ніж 20-30)
Єдиний файл стану для всіх ресурсів може уповільнити процес роботи з Terraform, якщо кількість ресурсів зростає (подумайте про використання аргументу-target щоб обмежити кількість ресурсів)