ಮೂಲ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
ಈ ಉದಾಹರಣೆಯು ದೊಡ್ಡ ಗಾತ್ರದ infrastructure ಗಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಷನ್ ಗಳನ್ನು ರಚಿಸುವ ಉದಾಹರಣೆಯಾಗಿ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ:
2 AWS ಖಾತೆಗಳು
2 ಪ್ರದೇಶಗಳು
2 ಪ್ರತ್ಯೇಕ ಪರಿಸರಗಳು (prod
ಮತ್ತು stage
ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ). ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಮತ್ತು 2 ಪ್ರದೇಶಗಳ ನಡುವಿನ ವ್ಯಾಪ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳು
ಪ್ರತಿ ಪರಿಸರವು ಟೆರ್ರಾಫಾರ್ಮ್ ರಿಜಿಸ್ಟ್ರಿಯಿಂದ ಆಫ್-ದಿ-ಶೆಲ್ಫ್ infrastructure ಮಾಡ್ಯೂಲ್ (alb) ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ
ಪ್ರತಿ ಪರಿಸರವು ಆಂತರಿಕ ಮಾಡ್ಯೂಲ್ modules/network
ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹೊಂದಲ್ಪಟ್ಟಿದೆ.
ಇಲ್ಲಿ ವಿವರಿಸಿರುವಂತಹ ದೊಡ್ಡ ಪ್ರಾಜೆಕ್ಟ್ ನಲ್ಲಿ ಟೆರಾಗ್ರಂಟ್ ಅನ್ನು ಬಳಸುವ ಪ್ರಯೋಜನಗಳು ಬಹಳಷ್ಟು ಇವೆ. Code Structures examples with Terragrunt ನೋಡಿ.
Infrastructure ಅನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿದ ಯೋಜನೆಗಳಿಗೆ ಉತ್ತಮ (ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಗಳು)
AWS ಖಾತೆಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಒಂದು ಪರಿಸರ = ಒಂದು AWS ಖಾತೆ = ಒಂದು ಸ್ಟೇಟ್ ಫೈಲ್)
ಪರಿಸರಗಳ ನಡುವಿನ ಬದಲಾವಣೆಗಳ orchestration ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು
Infrastructure ಸಂಪನ್ಮೂಲಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಸರಕ್ಕೆ ವಿಭಿನ್ನವಾಗಿರುವಾಗ ಮತ್ತು ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಉದಾ, ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು ಒಂದು ಪರಿಸರದಲ್ಲಿ ಅಥವಾ ಕೆಲವು ಪ್ರದೇಶಗಳಲ್ಲಿ ಇರುವುದಿಲ್ಲ)
ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳೆದಂತೆ, ಈ ಪರಿಸರಗಳನ್ನು ಪರಸ್ಪರ ನವೀಕೃತವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಪುನರಾವರ್ತಿತ ಕಾರ್ಯಗಳಿಗಾಗಿ infrastructure ಮಾಡ್ಯೂಲ್ಗಳನ್ನು (ಆಫ್-ದಿ-ಶೆಲ್ಫ್ ಅಥವಾ ಆಂತರಿಕ) ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
ಮೂಲ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
ಈ ಉದಾಹರಣೆಯು ಸಣ್ಣ-ಗಾತ್ರದ infrastructure ಗಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಷನ್ ಗಳನ್ನು ರಚಿಸುವ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಅಲ್ಲಿ ಯಾವುದೇ ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಬಳಸಲಾಗಿಲ್ಲ .
ಪ್ರಾರಂಭಿಸಲು ಉತ್ತಮ ಹಾಗು ಮುಂದುವರಿಸುತ್ತಿದ್ದಂತೆಯೇ ಮರು -ಪರಿಶೀಲಿಸಬಹುದು
ಸಣ್ಣ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ಗಳಿಗೆ ಉತ್ತಮ
ಸಣ್ಣ ಮತ್ತು ಲೀನಿಯರ್ infrastructure ಮಾಡ್ಯೂಲ್ಗಳಿಗೆ ಉತ್ತಮವಾಗಿದೆ (ಉದಾ, terraform-aws-atlantis)
ಸಣ್ಣ ಸಂಖ್ಯೆಯ ಸಂಪನ್ಮೂಲಗಳಿದ್ದಾಗ ಒಳ್ಳೆಯದುಸಣ್ಣ ಸಂಖ್ಯೆಯ ಸಂಪನ್ಮೂಲಗಳಿದ್ದಾಗ ಒಳ್ಳೆಯದು (20-30ಗಿಂತ ಕಡಿಮೆ)
ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚಿದ್ದಾಗ , ಎಲ್ಲಕ್ಕೂ ಸೇರಿ ಒಂದೇ ಸಿಂಗಲ್ -ಸ್ಟೇಟ್ ಫೈಲ್ ಇದ್ದರೆ, ಟೆರಾಫಾರ್ಮ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ (ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು -target
ಎಂಬ ಆರ್ಗ್ಯುಮೆಂಟ್ ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ)
ಮೂಲ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
ಈ ಉದಾಹರಣೆಯು ಮಧ್ಯಮ ಗಾತ್ರದ infrastructure ಗಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಷನ್ ಗಳನ್ನು ರಚಿಸುವ ಉದಾಹರಣೆಯಾಗಿ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ:
2 AWS ಖಾತೆಗಳು
2 ಪ್ರತ್ಯೇಕ ಪರಿಸರಗಳು (prod
ಮತ್ತು stage
ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ). ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ.
ಪ್ರತಿ ಪರಿಸರವು ಟೆರ್ರಾಫಾರ್ಮ್ ರಿಜಿಸ್ಟ್ರಿಯಿಂದ ಆಫ್-ದಿ-ಶೆಲ್ಫ್ infrastructure ಮಾಡ್ಯೂಲ್ (alb) ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ
ಪ್ರತಿ ಪರಿಸರವು ಆಂತರಿಕ ಮಾಡ್ಯೂಲ್ modules/network
ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹೊಂದಲ್ಪಟ್ಟಿದೆ.
Infrastructure ಅನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿದ ಯೋಜನೆಗಳಿಗೆ ಉತ್ತಮ (ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಗಳು)
AWS ಖಾತೆಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಒಂದು ಪರಿಸರ = ಒಂದು AWS ಖಾತೆ = ಒಂದು ಸ್ಟೇಟ್ ಫೈಲ್)
ಪರಿಸರಗಳ ನಡುವಿನ ಬದಲಾವಣೆಗಳ orchestration ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಒಳ್ಳೆಯದು
Infrastructure ಸಂಪನ್ಮೂಲಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಸರಕ್ಕೆ ವಿಭಿನ್ನವಾಗಿರುವಾಗ ಮತ್ತು ಸಾಮಾನ್ಯೀಕರಿಸಲಾಗದಿದ್ದಾಗ ಒಳ್ಳೆಯದು (ಉದಾ, ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು ಒಂದು ಪರಿಸರದಲ್ಲಿ ಅಥವಾ ಕೆಲವು ಪ್ರದೇಶಗಳಲ್ಲಿ ಇರುವುದಿಲ್ಲ)
ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳೆದಂತೆ, ಈ ಪರಿಸರಗಳನ್ನು ಪರಸ್ಪರ ನವೀಕೃತವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಪುನರಾವರ್ತಿತ ಕಾರ್ಯಗಳಿಗಾಗಿ infrastructure ಮಾಡ್ಯೂಲ್ಗಳನ್ನು (ಆಫ್-ದಿ-ಶೆಲ್ಫ್ ಅಥವಾ ಆಂತರಿಕ) ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.