# დიდი ზომის ინფრასტრუქტურა Terraform-ით

წყარო: [https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform](https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform)

ეს Terraform კოდის სტრუქტურის მაგალითი განკუთვნილია დიდი ზომის ინფრასტრუქტურისთვის რომელიც იყენებს შემდეგ კომპონენტებს:

* 2 AWS ანგარიში
* 2 რეგიონი
* 2 გამოყოფილი გარემო (`prod` და `stage` რესურსების გაზიარების გარეშე). თითოეული გარემო მუშაობს გამოყოფილ AWS ანგარიშში და მოიცავს რესურსებს ორივე რეგიონში
* თითოეული გარემო იყენებს მზა ინფრასტრუქტურის მოდულის (`alb`) განსხვავებულ ვერსიას რომლის კოდის წყაროც არის [Terraform Registry](https://registry.terraform.io/)
* თითოეული გარემო იყენებს თვითნაწერ მოდულს `modules/network` რომელიც ლოკალურად დირექტორიაში ინახება.&#x20;

{% hint style="info" %}
დიდ პროექტში, როგორიც აქ არის აღწერილი, Terragrunt-ის გამოყენების სარგებელი ძალიან თვალსაჩინო ხდება. იხილეთ [კოდის სტრუქტურის მაგალითები Terragrunt](../terragrunt).
{% endhint %}

{% hint style="success" %}
* იდეალურია პროექტებისთვის, სადაც ინფრასტრუქტურა ლოგიკურად არის გამოყოფილი (ცალკე AWS ანგარიშები)
* კარგია, როდესაც არ არის საჭირო AWS ანგარიშებს შორის გაზიარებული რესურსების ცვლილება (ერთი გარემო = ერთი AWS ანგარიში = ერთი სახელმწიფო ფაილი)
* კარგია, როდესაც არ არის საჭირო გარემოს შორის ცვლილებების ორკესტრირება
* კარგია, როდესაც ინფრასტრუქტურის რესურსები განსხვავებულია თითო გარემოში და მიზანმიმართულად და მათი განზოგადება შეუძლებელია (მაგ., ზოგიერთი რესურსი არ არის ერთ გარემოში ან ზოგიერთ რეგიონში)
{% endhint %}

{% hint style="warning" %}
რაც უფრო იზრდება პროექტი, უფრო რთული იქნება ამ გარემოს ერთმანეთთან განახლების შენარჩუნება. განიხილეთ ინფრასტრუქტურის მოდულების გამოყენება (თაროზე მოთავსებული ან შიდა) განმეორებადი ამოცანებისთვის.
{% endhint %}

##
