> For the complete documentation index, see [llms.txt](https://www.terraform-best-practices.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.terraform-best-practices.com/kn/examples/terraform/medium-size-infrastructure.md).

# ಮಧ್ಯಮ ಗಾತ್ರದ infrastructure ಟೆರಾಫಾರ್ಮ್ ನೊಂದಿಗೆ

ಮೂಲ: <https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform>

ಈ ಉದಾಹರಣೆಯು ಮಧ್ಯಮ ಗಾತ್ರದ infrastructure ಗಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಷನ್ ಗಳನ್ನು ರಚಿಸುವ ಉದಾಹರಣೆಯಾಗಿ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ:

* 2 AWS ಖಾತೆಗಳು
* 2 ಪ್ರತ್ಯೇಕ ಪರಿಸರಗಳು (`prod` ಮತ್ತು `stage` ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ). ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ.
* ಪ್ರತಿ ಪರಿಸರವು [ಟೆರ್ರಾಫಾರ್ಮ್ ರಿಜಿಸ್ಟ್ರಿಯಿಂದ](https://registry.terraform.io/) ಆಫ್-ದಿ-ಶೆಲ್ಫ್ infrastructure ಮಾಡ್ಯೂಲ್ (alb) ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ
* ಪ್ರತಿ ಪರಿಸರವು ಆಂತರಿಕ ಮಾಡ್ಯೂಲ್ `modules/network` ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹೊಂದಲ್ಪಟ್ಟಿದೆ.

{% hint style="success" %}

* Infrastructure ಅನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿದ ಯೋಜನೆಗಳಿಗೆ ಉತ್ತಮ (ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಗಳು)
* AWS ಖಾತೆಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಒಂದು ಪರಿಸರ = ಒಂದು AWS ಖಾತೆ = ಒಂದು ಸ್ಟೇಟ್ ಫೈಲ್)
* ಪರಿಸರಗಳ ನಡುವಿನ ಬದಲಾವಣೆಗಳ orchestration ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು
* Infrastructure ಸಂಪನ್ಮೂಲಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಸರಕ್ಕೆ ವಿಭಿನ್ನವಾಗಿರುವಾಗ ಮತ್ತು ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಉದಾ, ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು ಒಂದು ಪರಿಸರದಲ್ಲಿ ಅಥವಾ ಕೆಲವು ಪ್ರದೇಶಗಳಲ್ಲಿ ಇರುವುದಿಲ್ಲ)
  {% endhint %}

{% hint style="warning" %}
ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳೆದಂತೆ, ಈ ಪರಿಸರಗಳನ್ನು ಪರಸ್ಪರ ನವೀಕೃತವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಪುನರಾವರ್ತಿತ ಕಾರ್ಯಗಳಿಗಾಗಿ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು (ಆಫ್-ದಿ-ಶೆಲ್ಫ್ ಅಥವಾ ಆಂತರಿಕ) ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
{% endhint %}

##