Type | Description | Readiness |
---|---|---|
Type | Description | Readiness |
---|---|---|
מספר משאבים מועט, ללא תלות חיצונית. חשבון AWS יחיד. region בודד. סביבה אחת.
כן
מספר חשבונות וסביבות של AWS, מודולי תשתית מוכנים, מידול קומפוזיציות בעזרת terraform.
כן
חשבונות AWS רבים, regions רבים, דחיפות להורדת העתק הדבק, מודולי תשתית מותאמים אישית, שימוש כבד בקומפוזיצות. שימוש ב terraform.
בתהליכים
ענק
Several providers (AWS, GCP, Azure). Multi-cloud deployments. Using Terraform.
לא
בינוני
מספר חשבונות וסביבות של AWS, מודולי תשתית מוכנים, מידול קומפוזיציות בעזרת terragrunt.
לא
גדול
חשבונות AWS רבים, regions רבים, דחיפות להורדת העתק הדבק, מודולי תשתית מותאמים אישית, שימוש כבד בקומפוזיצות. שימוש ב terragrunt.
לא
ענק
מספר ספקים (AWS, GCP, AZURE). פריסות על גבי מספר עננים. שימוש ב terragrunt
לא
This example contains code as an example of structuring Terraform configurations for a large-size infrastructure which uses:
2 AWS accounts
2 regions
2 separate environments (prod
and stage
which share nothing). Each environment lives in a separate AWS account and span resources between 2 regions
Each environment uses the same version of an internal module modules/network
since it is sourced from a local directory.
Perfect for projects where infrastructure is logically separated (separate AWS accounts)
Good when there is no is need to modify resources shared between AWS accounts (one environment = one AWS account = one state file)
Good when there is no need for the orchestration of changes between the environments
Good when infrastructure resources are different per environment on purpose and can't be generalized (eg, some resources are absent in one environment or in some regions)
As the project grows, it will be harder to keep these environments up-to-date with each other. Consider using infrastructure modules (off-the-shelf or internal) for repeatable tasks.
Source:
Each environment uses a different version of the off-the-shelf infrastructure module (alb
) sourced from
In a large project like described here the benefits of using Terragrunt become very visible. See .
מקור: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
דוגמא זו מכילה קוד לבניית קונפיגורציית Terraform עבור תשתית בקנה מידה קטן, שבה לא נעשה שימוש בתלות חיצונית.
מושלם להתחלה ולשיכתוב בהמשך
מושלם עבור מודולי משאבים קטנים
מתאים למודולי תשתית קטנים וליניאריים
טוב למספר קטן של משאבים (פחות מ- 20-30)
קובץ מצב יחיד עבור כל המשאבים יכול להאט את תהליך העבודה עם Terraform אם מספר המשאבים גדל
(שקול להשתמש בארגומנט - יעד (target-)
להגבלת מספר המשאבים)
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
This example contains code as an example of structuring Terraform configurations for a medium-size infrastructure which uses:
2 AWS accounts
2 separate environments (prod
and stage
which share nothing). Each environment lives in a separate AWS account
Each environment uses a different version of the off-the-shelf infrastructure module (alb
) sourced from Terraform Registry
Each environment uses the same version of an internal module modules/network
since it is sourced from a local directory.
Perfect for projects where infrastructure is logically separated (separate AWS accounts)
Good when there is no is need to modify resources shared between AWS accounts (one environment = one AWS account = one state file)
Good when there is no need in the orchestration of changes between the environments
Good when infrastructure resources are different per environment on purpose and can't be generalized (eg, some resources are absent in one environment or in some regions)
As the project grows, it will be harder to keep these environments up-to-date with each other. Consider using infrastructure modules (off-the-shelf or internal) for repeatable tasks.