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