ಟೆರಾಫಾರ್ಮ್ ಶಕ್ತಿಯುತವಾದದ್ದು ಮತ್ತು infrastructure ಅನ್ನು code ನಂತೆ ನಿರ್ವಹಿಸಲು ಅತಿ ಹೆಚ್ಚು ಬಳಸುವ ಸಾಧನಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ಅನುವು ಮಾಡಿ ಕೊಡುತ್ತದೆ ಮತ್ತು ಸಂಯೋಜಿಸಲು ಕಷ್ಟಕರವಾದ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ಅವರನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ.

ಈ ಪುಸ್ತಕದಲ್ಲಿ ವಿವರಿಸಿದ ಕೆಲವು ಮಾಹಿತಿಯು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಂತೆ ತೋರದೇ ಇರಬಹುದು . ನನಗೆ ಇದು ತಿಳಿದಿದೆ, ಮತ್ತು ಓದುಗರಿಗೆ ಸ್ಥಾಪಿತವಾದ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಮಾಡುವ ಅನ್ಯ ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಹಾಯ ಮಾಡಲು, ಉತ್ತಮ ಅಭ್ಯಾಸಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರತಿಯೊಂದು ಉಪವಿಭಾಗದಲ್ಲಿ ಪ್ರಬುದ್ಧತೆಯ ಮಟ್ಟವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಕೆಲವು ಸುಳಿವು ಮತ್ತು ಐಕಾನ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇನೆ.

ಈ ಪುಸ್ತಕವನ್ನು 2018 ರ ಬೇಸಿಗೆಯಲ್ಲಿ ಮ್ಯಾಡ್ರಿಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ಹಾಗೂ https://www.terraform-best-practices.com/ನಲ್ಲಿ ಉಚಿತವಾಗಿ ಲಭ್ಯವಿದೆ .

ಕೆಲವು ವರ್ಷಗಳ ನಂತರ ಅದನ್ನು ಟೆರಾಫಾರ್ಮ್ 1.0 ರೊಂದಿಗೆ ಹೆಚ್ಚು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ನವೀಕರಿಸಲಾಗಿದೆ. ಅಂತಿಮವಾಗಿ, ಈ ಪುಸ್ತಕವು ಟೆರಾಫಾರ್ಮ್ ಬಳಕೆದಾರರಿಗೆ ನಿರ್ವಿವಾದದ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಶಿಫಾರಸುಗಳನ್ನು ಒಳಗೊಂಡಿರಬೇಕು.

Sponsors

Please contact me if you want to become a sponsor.

ಅನುವಾದಗಳು

ನೀವು ಈ ಪುಸ್ತಕವನ್ನು ಇತರ ಭಾಷೆಗಳಿಗೆ ಭಾಷಾಂತರಿಸಲು ಸಹಾಯ ಮಾಡಲು ಬಯಸಿದರೆ ನನ್ನನ್ನು ಸಂಪರ್ಕಿಸಿ.

ಕೊಡುಗೆಗಳು

ಸಮುದಾಯವು ಪ್ರಬುದ್ಧವಾಗುತ್ತಿದ್ದಂತೆ ನಾನು ಯಾವಾಗಲೂ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಲು ಮತ್ತು ಈ ಪುಸ್ತಕವನ್ನು ನವೀಕರಿಸಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಹೊಸ ಆಲೋಚನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.

ನೀವು ನಿರ್ದಿಷ್ಟ ವಿಷಯಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಸಮಸ್ಯೆಯನ್ನು ತೆರೆಯಿರಿ ಅಥವಾ ನೀವು ಕವರ್ ಮಾಡಲು ಬಯಸುವ ಸಮಸ್ಯೆಯನ್ನು ಹೆಬ್ಬೆರಳು ಅಪ್ ಮಾಡಿ. ನೀವು ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಕೊಡುಗೆ ನೀಡಲು ಬಯಸಿದರೆ, ಡ್ರಾಫ್ಟ್ ಅನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿ (ಈ ಹಂತದಲ್ಲಿ ಉತ್ತಮ ಪಠ್ಯವನ್ನು ಬರೆಯುವ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಡಿ!).

ಲೇಖಕರು

ಈ ಪುಸ್ತಕವನ್ನು ಆಂಟನ್ ಬಾಬೆಂಕೊ ಅವರು ವಿವಿಧ ಕೊಡುಗೆದಾರರು ಮತ್ತು ಅನುವಾದಕರ ಸಹಾಯದಿಂದ ನಿರ್ವಹಿಸಿದ್ದಾರೆ. ಕನ್ನಡ ಭಾಷೆಗೆ ಅನುವಾದ ಮಾಡಿದವರು ತ್ರಿವಿಕ್ರಮ ಹರಿಕೃಷ್ಣನ್.

License

ಈ ಕೆಲಸವು Apache 2 ಪರವಾನಗಿ ಅಡಿಯಲ್ಲಿ ಪರವಾನಗಿ ಪಡೆದಿದೆ. ಪೂರ್ಣ ವಿವರಗಳಿಗಾಗಿ ಪರವಾನಗಿಯನ್ನು ನೋಡಿ.

ಈ ವಿಷಯಕ್ಕೆ ಲೇಖಕರು ಮತ್ತು ಕೊಡುಗೆದಾರರು ಇಲ್ಲಿ ಕಂಡುಬರುವ ಮಾಹಿತಿಯ ಸಿಂಧುತ್ವವನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಒದಗಿಸಲಾದ ಮಾಹಿತಿಯನ್ನು ಉಚಿತವಾಗಿ ಒದಗಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ನಿಮ್ಮ ಮತ್ತು ಈ ವಿಷಯ ಅಥವಾ ಯೋಜನೆಗೆ ಸಂಬಂಧಿಸಿದ ಯಾವುದೇ ವ್ಯಕ್ತಿಗಳ ನಡುವೆ ಯಾವುದೇ ರೀತಿಯ ಒಪ್ಪಂದ ಅಥವಾ ಒಪ್ಪಂದವನ್ನು ರಚಿಸಲಾಗಿಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಲೇಖಕರು ಮತ್ತು ಕೊಡುಗೆದಾರರು ಈ ವಿಷಯದಲ್ಲಿ ಒಳಗೊಂಡಿರುವ, ಸಂಯೋಜಿತವಾಗಿರುವ ಅಥವಾ ಲಿಂಕ್ ಮಾಡಲಾದ ಮಾಹಿತಿಯಲ್ಲಿ ದೋಷಗಳು ಅಥವಾ ಲೋಪಗಳಿಂದ ಉಂಟಾದ ಯಾವುದೇ ನಷ್ಟ, ಹಾನಿ ಅಥವಾ ಅಡ್ಡಿಗಳಿಗೆ ಯಾವುದೇ ಹೊಣೆಗಾರಿಕೆಯನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ನಿರ್ಲಕ್ಷ್ಯ, ಅಪಘಾತ, ಅಥವಾ ಯಾವುದೇ ಇತರ ಕಾರಣ ಇದ್ದರೂ.

ಕಾಪಿರೈಟ್ © 2018-2022 ಆಂಟನ್ ಬಾಬೆಂಕೊ.

ಅಧಿಕೃತ ಟೆರಾಫಾರ್ಮ್ ದಾಖಲೆಗಳು ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತವೆ .ಈ ವಿಭಾಗದ ಉಳಿದ ಭಾಗವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅದನ್ನು ಗಮನವಿಟ್ಟು ಓದಿ.

ಈ ವಿಭಾಗವು ಪುಸ್ತಕದೊಳಗೆ ಬಳಸಲಾದ ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸಂಪನ್ಮೂಲ (Resource)

ಸಂಪನ್ಮೂಲಗಳು ಎಂದರೆ aws_vpc, aws_db_instance, ಇತ್ಯಾದಿ. ಸಂಪನ್ಮೂಲವು ಪೂರೈಕೆದಾರರಿಗೆ ಸೇರಿದೆ, argument ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, property ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ ಮತ್ತು life cycleಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಬಹುದು, retrieve ಮಾಡಬಹುದು, ನವೀಕರಿಸಬಹುದು ಮತ್ತು ಅಳಿಸಬಹುದು.

ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್

ಸಂಪನ್ಮೂಲ module ಎನ್ನುವುದು ಸಂಪರ್ಕಿತ ಸಂಪನ್ಮೂಲಗಳ ಸಂಗ್ರಹವಾಗಿದ್ದು ಅದು ಸಾಮಾನ್ಯ ಕ್ರಿಯೆಯನ್ನು ಒಟ್ಟಿಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, AWS VPC ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ VPC, ಸಬ್‌ನೆಟ್‌ಗಳು, NAT ಗೇಟ್‌ವೇ, ಇತ್ಯಾದಿಗಳನ್ನು ರಚಿಸುತ್ತದೆ). ಇದು ಪೂರೈಕೆದಾರರ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಅದರಲ್ಲಿ ಅಥವಾ ಉನ್ನತ ಮಟ್ಟದ ರಚನೆಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, infrastructure ಮಾಡ್ಯೂಲ್ ನಲ್ಲಿ).

Infrastructure (ಮೂಲಸೌಕರ್ಯ) ಮಾಡ್ಯೂಲ್

Infrastructure ಮಾಡ್ಯೂಲ್ ಎನ್ನುವುದು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳ ಸಂಗ್ರಹವಾಗಿದೆ. ಈ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳು ತಾರ್ಕಿಕವಾಗಿ ಪ್ರತ್ಯೇಕವಾದವುಗಳು. ಆದರೆ ಪ್ರಸ್ತುತ ಪರಿಸ್ಥಿತಿ/ಪ್ರಾಜೆಕ್ಟ್/ಸೆಟಪ್ನಲ್ಲಿ ಯಾವುದೊ ಒಂದು ನಿಯೋಜಿತ ಉದ್ದೇಶವನ್ನು ಪೂರೈಸುತ್ತದೆ. ಇದು ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳಿಗೆ ರವಾನಿಸಲಾಗುವ ಕಾಂಫಿಗುರೇಷನ್ಗಳನ್ನು ಪೂರೈಕೆದಾರರಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ತಾರ್ಕಿಕ ವಿಭಜಕಕ್ಕೆ (ಉದಾ., AWS ಪ್ರದೇಶ, Google ಪ್ರಾಜೆಕ್ಟ್ )ಒಂದು ಯೂನಿಟ್ ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸೀಮಿತವಾಗಿರುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, terraform-aws-atlantis ಮಾಡ್ಯೂಲ್ AWS ಫಾರ್ಗೇಟ್‌ನಲ್ಲಿAtlantis ಅನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ infrastructure ಅನ್ನು ನಿರ್ವಹಿಸಲು terraform-aws-vpc ಮತ್ತು terraform-aws-security-groupನಂತಹ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ.

ಮತ್ತೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ, terraform-aws-cloudquery ಮಾಡ್ಯೂಲಿನಲ್ಲಿ terraform-aws-modules ನಂತಹ ಬಹು ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ infrastructure ನಿರ್ವಹಿಸಲು ಬಳಸಲಾಗುತ್ತಿದೆ ಮತ್ತುಡಾಕರ್ imagesಅನ್ನು ನಿರ್ಮಿಸಲು, ತಳ್ಳಲು ಮತ್ತು ನಿಯೋಜಿಸಲು ಡಾಕರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಲಾಗುತ್ತಿದೆ. ಎಲ್ಲಾ ಒಂದೇ ಸೆಟ್‌ನಲ್ಲಿ.

ಕಾಂಪೊಸಿಷನ್

ಕಾಂಪೊಸಿಷನ್ ಎನ್ನುವುದು infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳ ಸಂಗ್ರಹವಾಗಿದೆ, ಇದು ಹಲವಾರು ತಾರ್ಕಿಕವಾಗಿ ಬೇರ್ಪಟ್ಟ ಪ್ರದೇಶಗಳಲ್ಲಿ ವ್ಯಾಪಿಸಬಹುದು (ಉದಾ., AWS ಪ್ರದೇಶಗಳು, ಹಲವಾರು AWS ಖಾತೆಗಳು). ಸಂಪೂರ್ಣ ಸಂಸ್ಥೆ ಅಥವಾ ಪ್ರಾಜೆಕ್ಟ್-ಗೆ ಅಗತ್ಯವಿರುವ ಸಂಪೂರ್ಣ infrastructureಅನ್ನು ವಿವರಿಸಲು ಕಾಂಪೊಸಿಷನ್ ಬಳಸಲಾಗುತ್ತದೆ. ಕಾಂಪೊಸಿಷನ್ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅವು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ , ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳು ವೈಯಕ್ತಿಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ .

ಮಾಹಿತಿ (ಡೇಟಾ) ಮೂಲ

ಮಾಹಿತಿ ಮೂಲವು ಓದಲು-ಮಾತ್ರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪೂರೈಕೆದಾರರ ಕಾಂಫಿಗುರೇಶನ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಇದನ್ನು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ ಮತ್ತು infrastructure ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಮಾಹಿತಿ ಮೂಲ terraform_remote_state ಎನ್ನುವುದು ಉನ್ನತ ಮಟ್ಟದ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್-ಗಳ ನಡುವಿನ ಸೇತುವೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಬಾಹ್ಯ ಮಾಹಿತಿ ಮೂಲವು ಬಾಹ್ಯ ಪ್ರೋಗ್ರಾಮ್ ಅನ್ನು ಮಾಹಿತಿ ಮೂಲವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದರಿಂದ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಬೇರೆಡೆ ಬಳಕೆಗಾಗಿ ಅನಿಯಂತ್ರಿತ ಮಾಹಿತಿಯು ಲಭ್ಯವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗಾಗಿ terraform-aws-lambda module ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿಫೈಲ್ ಹೆಸರನ್ನು ಬಾಹ್ಯ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕರೆಯುವ ಮೂಲಕ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾಗುತ್ತದೆ.

http ಮಾಹಿತಿ ಮೂಲವು HTTP GET URL ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಬಂದ response ಅನ್ನು export ಮಾಡುತ್ತದೆ. ಇದು native ಟೆರಾಫಾರ್ಮ್ ಪೂರೈಕೆದಾರರು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಎಂಡ್ ಪಾಯಿಂಟ್ ಗಳಿಂದ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಉಪಯುಕ್ತವಾದ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿದೆ.

Remote (ರಿಮೋಟ್) ಸ್ಥಿತಿ

Infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಗಳು ತಮ್ಮ ಟೆರಾಫಾರ್ಮ್ ಸ್ಥಿತಿಯನ್ನು remote ಸ್ಥಳದಲ್ಲಿ ಲಭ್ಯವಾಗಿಸಬೇಕು. ಅದನ್ನು ಇತರರು ನಿಯಂತ್ರಿತ ರೀತಿಯಲ್ಲಿ ಹಿಂಪಡೆಯಬಹುದು (ಉದಾ., ACL, version ,ಲಾಗಿಂಗ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವಂತದ್ದು)

ಪೂರೈಕೆದಾರರು (Providers), ಒದಗಿಸುವವರು, ಇತ್ಯಾದಿ

ಪೂರೈಕೆದಾರರು, ಒದಗಿಸುವವರು ಮತ್ತು ಕೆಲವು ಇತರ ಪದಗಳನ್ನು ಅಧಿಕೃತ ದಾಖಲಾತಿಯಲ್ಲಿ ಚೆನ್ನಾಗಿ ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಇಲ್ಲಿ ಪುನರಾವರ್ತಿಸಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ನನ್ನ ಅಭಿಪ್ರಾಯದ ಪ್ರಕಾರ, ಉತ್ತಮ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಬರೆಯುವುದಕ್ಕೂ ಇದಕ್ಕೂ ಸಂಬಂಧವಿಲ್ಲ.

ಏಕೆ ಕಷ್ಟ?

Infrastructure ಅಲ್ಲಿ ವೈಯಕ್ತಿಕ ಸಂಪನ್ಮೂಲಗಳು ಪರಮಾಣುಗಳಂತೆ ಹಾಗು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳು ಅಣುಗಳಂತೆ (ಪರಮಾಣುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ). ಮಾಡ್ಯೂಲ್ ಎನ್ನುವುದು ಚಿಕ್ಕ ಆವೃತ್ತಿಯ ಮತ್ತು ಹಂಚಿಕೊಳ್ಳಬಹುದಾದ ಘಟಕವಾಗಿದೆ. ಇದು argumentಗಳ ನಿಖರವಾದ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದು , basic ಕಾರ್ಯವನ್ನು ಮಾಡಲು ಅಂತಹ ಘಟಕಕ್ಕೆ ಮೂಲಭೂತ ತರ್ಕವನ್ನು ಅಳವಡಿಸುತ್ತದೆ. e.g., terraform-aws-security-group ಮಾಡ್ಯೂಲ್‌ aws_security_group ಹಾಗು aws_security_group_rule ಸಂಪನ್ಮೂಲಗಳನ್ನು inputನ ಆಧಾರದ ಮೇಲೆ ಸೃಷ್ಟಿಸುತ್ತದೆ. This ಸಂಪನ್ಮೂಲಗ ಮಾಡ್ಯೂಲ್‌ ಅನ್ನು ಬೇರೆ ಮೊಡ್ಯೂಲ್ ಗಳ ಜೊತೆ infrastructure ಮೊಡ್ಯೂಲ್ ಸೃಷ್ಟಿಸಲು ಉಪಯೋಗಿಸಬಹುದಾಗಿದೆ.

ಅಣುಗಳಾದ್ಯಂತ (ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು) ಮಾಹಿತಿಯ ಪರಾಮರ್ಷಣೆಯನ್ನು ಮಾಡ್ಯೂಲ್‌ಗಳ ಔಟ್‌ಪುಟ್‌ಗಳು ಮತ್ತು ಮಾಹಿತಿ ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.

ಕಂಪೋಸಿಷನ್ ಗಳ ಪರಮರ್ಷಣೆಯನ್ನು ರಿಮೋಟ್ ಸ್ಟೇಟ್ ಮಾಹಿತಿ ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹೆಚ್ಚಾಗಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ನಡುವೆ ಮಾಹಿತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸೂಡೋ-ರಿಲೇಶನ್ ಗಳಲ್ಲಿ ಇರಿಸಿದಾಗ ಅದು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }
}

ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ವಿವರಿಸಿದ ಕೆಲವು ವಿಷಯಗಳನ್ನು ಅಭ್ಯಾಸ ಮಾಡಲು ಬಯಸುವ ಜನರಿಗೆ ಕಾರ್ಯಾಗಾರವೂ ಇದೆ.

ವಿಷಯ ಇಲ್ಲಿದೆ - https://github.com/antonbabenko/terraform-best-practices-workshop

ಮೂಲ:

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

• 2 AWS ಖಾತೆಗಳು

• 2 ಪ್ರತ್ಯೇಕ ಪರಿಸರಗಳು (prod ಮತ್ತು stage ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ). ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ.

• ಪ್ರತಿ ಪರಿಸರವು ಆಫ್-ದಿ-ಶೆಲ್ಫ್ infrastructure ಮಾಡ್ಯೂಲ್ (alb) ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ

• ಪ್ರತಿ ಪರಿಸರವು ಆಂತರಿಕ ಮಾಡ್ಯೂಲ್ modules/network ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹೊಂದಲ್ಪಟ್ಟಿದೆ.

ಸಂಪನ್ಮೂಲಗಳ ನಡುವೆ ಸ್ಪಷ್ಟವಾದ ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು locals(ಲೋಕಲ್ಸ್)ಅನ್ನು ಬಳಸಿ

ಟೆರ್ರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ಗಳಲ್ಲಿ ಯಾವುದೇ ನೇರ ಅವಲಂಬನೆ ಇಲ್ಲದಿರುವಾಗಲೂ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮೊದಲು ಅಳಿಸಬೇಕು ಎಂದು ಟೆರಾಫಾರ್ಮ್‌ಗೆ ಸುಳಿವು ನೀಡಲು ಸಹಾಯಕವಾದ ಮಾರ್ಗ.

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

ಟೆರಾಫಾರ್ಮ್ 0.12 - ಅಗತ್ಯ ಮತ್ತು ಐಚ್ಛಿಕ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳು

1. var.websiteಖಾಲಿ ನಕ್ಷೆಯಾಗಿರದಿದ್ದರೆ,ಅಗತ್ಯವಿರುವ ಆರ್ಗ್ಯುಮೆಂಟ್t index_documentಅನ್ನು ಸೆಟ್ ಮಾಡಬೇಕು.

2. ಐಚ್ಛಿಕ ಆರ್ಗ್ಯುಮೆಂಟ್ error_document ಅನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು.

variable "website" {
  type    = map(string)
  default = {}
}

resource "aws_s3_bucket" "this" {
  # omitted...

  dynamic "website" {
    for_each = length(keys(var.website)) == 0 ? [] : [var.website]

    content {
      index_document = website.value.index_document
      error_document = lookup(website.value, "error_document", null)
    }
  }
}

website = {
  index_document = "index.html"
}

https://twitter.com/antonbabenko/lists/terraform-experts - ಟೆರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ತುಂಬಾ ಸಕ್ರಿಯವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಜನರ ಪಟ್ಟಿ ಮತ್ತು ನಿಮಗೆ ಬಹಳಷ್ಟು ವಿಷಯವನ್ನು ಹೇಳಬಹುದು (ನೀವು ಅವರನ್ನು ಕೇಳಿದರೆ).

https://github.com/shuaibiyy/awesome-terraform - HashiCorp ನ ಟೆರಾಫಾರ್ಮ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳ ಕ್ಯುರೇಟೆಡ್ ಪಟ್ಟಿ.

http://bit.ly/terraform-youtube - "Your Weekly Dose of Terraform" ಆಂಟನ್ ಬಾಬೆಂಕೊ ಅವರ YouTube ಚಾನಲ್. ವಿಮರ್ಶೆಗಳು, ಸಂದರ್ಶನಗಳು, ಪ್ರಶ್ನೋತ್ತರಗಳು, ಲೈವ್ ಕೋಡಿಂಗ್ ಮತ್ತು ಟೆರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಕೆಲವು ಹ್ಯಾಕಿಂಗ್‌ಗಳೊಂದಿಗೆ ಲೈವ್ ಸ್ಟ್ರೀಮ್‌ಗಳು.

https://weekly.tf - ಟೆರಾಫಾರ್ಮ್ ಸಾಪ್ತಾಹಿಕ ಸುದ್ದಿಪತ್ರ. ಆಂಟನ್ ಬಾಬೆಂಕೊ ಅವರಿಂದ ಟೆರಾಫಾರ್ಮ್ ಜಗತ್ತಿನಲ್ಲಿ ವಿವಿಧ ಸುದ್ದಿಗಳು (ಯೋಜನೆಗಳು, ಪ್ರಕಟಣೆಗಳು, ಚರ್ಚೆಗಳು).

ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ರಚನೆಗಳು

Terragrunt code structures

ಡಾಕ್ಯುಮೆಂಟೇಷನ್

ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾದ ಡಾಕ್ಯುಮೆಂಟೇಷನ್

ಎನ್ನುವುದು ಬಹು-ಭಾಷಾ pre -commit-hook ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಚೌಕಟ್ಟಾಗಿದೆ. ಇದು ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಜಿಟ್ ರೆಪೊಸಿಟರಿಗೆ ಕಮಿಟ್ ಮಾಡುವ ಮೊದಲು ಡೆವಲಪರ್‌ನ ಯಂತ್ರದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಬಲ ಸಾಧನವಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇದನ್ನು ಲಿಂಟರ್‌ಗಳು ಮತ್ತು ಫಾರ್ಮ್ಯಾಟ್ ಕೋಡ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ ( ಗಳನ್ನು ನೋಡಿ).

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಷನ್ ಗಳೊಂದಿಗೆpre-commit ಅನ್ನು ಕೋಡ್ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲು ಮತ್ತು validate ಮಾಡಲು , ಹಾಗೆಯೇ ಡಾಕ್ಯುಮೆಂಟೇಷನ್ ನವೀಕರಿಸಲು ಬಳಸಬಹುದು.

ಅದರೊಂದಿಗೆ ನೀವು ಚಿರ-ಪರಿಚಿತರಾಗಲು ಯನ್ನೂ ಹಾಗು ಇದನ್ನು ಬಳಸಲಾದ, ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ರೆಪೊಸಿಟರಿಗಳನ್ನೂ (ಉದಾ, ) ಪರಿಶೀಲಿಸಿ.

ಟೆರ್ರಾಫಾರ್ಮ್-ಡಾಕ್ಸ್(terraform-docs)

ಎನ್ನುವುದು ವಿವಿಧ ಔಟ್‌ಪುಟ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳಲ್ಲಿ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳಿಂದ ಡಾಕ್ಯುಮೆಂಟೇಷನ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಧನವಾಗಿದೆ. ನೀವು ಅದನ್ನು ಮಾನ್ಯುಯಲ್ ಆಗಿ ಚಲಾಯಿಸಬಹುದು (ಪೂರ್ವ-ಕಮಿಟ್ ಕೊಕ್ಕೆಗಳಿಲ್ಲದೆ), ಅಥವಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಲು ಗಳನ್ನು ಬಳಸಬಹುದು.

@todo: Document module versions, release, GH actions

ಸಂಪನ್ಮೂಲಗಳು

3. ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಅವರಿಂದ:

ಮೂಲ:

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

• 2 AWS ಖಾತೆಗಳು

• 2 ಪ್ರದೇಶಗಳು

• 2 ಪ್ರತ್ಯೇಕ ಪರಿಸರಗಳು (prod ಮತ್ತು stage ಏನನ್ನೂ ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ). ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಪ್ರತ್ಯೇಕ AWS ಖಾತೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಮತ್ತು 2 ಪ್ರದೇಶಗಳ ನಡುವಿನ ವ್ಯಾಪ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳು

• ಪ್ರತಿ ಪರಿಸರವು ಆಫ್-ದಿ-ಶೆಲ್ಫ್ infrastructure ಮಾಡ್ಯೂಲ್ (alb) ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ

• ಪ್ರತಿ ಪರಿಸರವು ಆಂತರಿಕ ಮಾಡ್ಯೂಲ್ modules/network ಅದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹೊಂದಲ್ಪಟ್ಟಿದೆ.

ನಾನು ತಿಳಿದಿರಬೇಕಾದ ಮತ್ತು ಬಳಸಲು ಪರಿಗಣಿಸಬೇಕಾದ ಸಾಧನಗಳು ಯಾವುವು?

• ಟೆರಾಗ್ರಂಟ್ - ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಾಧನ

• tflint - ಕೋಡ್ ಲಿಂಟರ್

• tfenv - ವರ್ಷನ್ ಮ್ಯಾನೇಜರ್

• ಅಟ್ಲಾಂಟಿಸ್ - ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಆಟೋಮೇಷನ್

• pre-commit-terraform - pre-commit frameworkನೊಂದಿಗೆ ಬಳಸಲು ಟೆರಾಫಾರ್ಮ್‌ಗಾಗಿ git ಹುಕ್‌ಗಳ ಸಂಗ್ರಹ

• Infracost - ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಗಳಲ್ಲಿ ಟೆರಾಫಾರ್ಮ್‌ ಕ್ಲೌಡ್ ವೆಚ್ಚದ ಅಂದಾಜು. ಟೆರಾಗ್ರಂಟ್, ಅಟ್ಲಾಂಟಿಸ್ ಮತ್ತು ಪ್ರಿ-ಕಮಿಟ್-ಟೆರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಮಾಡ್ಯೂಲ್‌ಗಳ dependency hell ಗೆ ಪರಿಹಾರಗಳು ಯಾವುವು?

ಸಂಪನ್ಮೂಲ ಮತ್ತು infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳ version ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು. ಪೂರೈಕೆದಾರರನ್ನು ಮಾಡ್ಯೂಲ್‌ಗಳ ಹೊರಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು, ಆದರೆ ಕಂಪೋಸಿಷನ್ ಗಳಲ್ಲಿ ಮಾತ್ರ. ಪೂರೈಕೆದಾರರ version ಮತ್ತು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಸಹ ಲಾಕ್ ಮಾಡಬಹುದು.

ಯಾವುದೇ ಮಾಸ್ಟರ್ ಡೆಪೆಂಡೆನ್ಸಿ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಾಧನವಿಲ್ಲ, ಆದರೆ ಡೆಪೆಂಡೆನ್ಸಿ ಸ್ಪೆಸಿಫಿಕೇಷನ್ ಗಳ ಕ್ಲಿಷ್ಟತೆ ಕಡಿಮೆ ಮಾಡಲು ಕೆಲವು ಸಲಹೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಡೆಪೆಂಡೆನ್ಸಿ updateಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು Dependabot ಅನ್ನು ಬಳಸಬಹುದು. Dependabot ನಿಮ್ಮ ಡೆಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಮತ್ತು ಅಪ್-ಟು-ಡೇಟ್ ಆಗಿ ಇರಿಸಲು ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಗಳನ್ನು ರಚಿಸುತ್ತದೆ. Dependabot ಟೆರಾಫಾರ್ಮ್ ಸಂರಚನೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಜನರಲ್ conventionಗಳು

1. ಎಲ್ಲೆಡೆ - (ಡ್ಯಾಶ್) ಬದಲಿಗೆ _ (ಅಂಡರ್ಸ್ಕೋರ್) ಬಳಸಿ (ಸಂಪನ್ಮೂಲ ಹೆಸರುಗಳು, ಡೇಟಾ ಮೂಲ ಹೆಸರುಗಳು, ವೇರಿಯಬಲ್ ಹೆಸರುಗಳು, ಔಟ್ಪುಟ್ಗಳು, ಇತ್ಯಾದಿ).

2. Lowercase ಅಕ್ಷರಗಳು ಮತ್ತು ಸಂಖ್ಯೆಗಳನ್ನು ಬಳಸಲು ಆದ್ಯತೆ ನೀಡಿ (UTF-8 ಅನ್ನು ಬೆಂಬಲಿಸಿದರೂ ಸಹ).

ಸಂಪನ್ಮೂಲ ಮತ್ತು ಡೇಟಾ ಮೂಲ ಅರ್ಗುಮೆಂಟ್ ಗಳು (arguments)

1. ಸಂಪನ್ಮೂಲದ ಹೆಸರಿನಲ್ಲಿ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರವನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ (ಭಾಗಶಃವಾಗಿಯೂ ಅಲ್ಲ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿಯೂ ಅಲ್ಲ):

`resource "aws_route_table" "public" {}`

`resource "aws_route_table" "public_route_table" {}`

`resource "aws_route_table" "public_aws_route_table" {}`

1. ಹೆಚ್ಚಿನ ವಿವರಣಾತ್ಮಕ ಮತ್ತು ಸಾಮಾನ್ಯ ಹೆಸರು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ ಈ ಪ್ರಕಾರದ ಒಂದೇ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿದರೆ ಸಂಪನ್ಮೂಲ ಹೆಸರನ್ನುthis ಎಂದು ಹೆಸರಿಸಬೇಕು. (ಉದಾ, AWS VPC ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ aws_nat_gateway ಪ್ರಕಾರದ ಒಂದೇ ಸಂಪನ್ಮೂಲವಿದೆ ಮತ್ತು type aws_route_table ನ ಬಹು ಸಂಪನ್ಮೂಲಗಳು ಇವೆ . ಆದ್ದರಿಂದ aws_nat_gateway ಅನ್ನು this ಎಂದು ಹೆಸರಿಸಬೇಕು ಮತ್ತು aws_route_table ಹೆಚ್ಚು ವಿವರಣಾತ್ಮಕ ಹೆಸರುಗಳನ್ನು ಹೊಂದಿರಬೇಕು -(private, public, database).

2. ಹೆಸರುಗಳಿಗೆ ಯಾವಾಗಲೂ ಏಕವಚನ ನಾಮಪದಗಳನ್ನು ಬಳಸಿ.

3. ಬಳಕೆ: ಆರ್ಗ್ಯುಮೆಂಟ್‌ valueಗಳ ಒಳಗೆ. value ಮಾನವನಿಗೆ ಕಾಣುವ ಸ್ಥಳಗಳಲ್ಲಿಇರಬೇಕು(ಉದಾ, RDS ನಿದರ್ಶನದ DNS ಹೆಸರಿನ ಒಳಗೆ).

4. ಆರ್ಗ್ಯುಮೆಂಟ್ count / for_eachನ ಇನ್‌ಸೈಡ್ ರಿಸೋರ್ಸ್ ಅಥವಾ ಡೇಟಾ ಸೋರ್ಸ್ ಬ್ಲಾಕ್ ಅನ್ನು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮೊದಲ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಸೇರಿಸಿ, ಮತ್ತು ಅದರ ನಂತರ ಹೊಸ ಸಾಲಿನ ಮೂಲಕ ಪ್ರತ್ಯೇಕಿಸಿ.

5. ಆರ್ಗ್ಯುಮೆಂಟ್ tagsಗಳನ್ನು ಸೇರಿಸಿ, ಸಂಪನ್ಮೂಲದಿಂದ ಬೆಂಬಲಿಸಿದರೆ, ಕೊನೆಯ ನೈಜ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ, ಅವಶ್ಯವಿದ್ದಲ್ಲಿ depends_on ಮತ್ತು lifecycle ಅನ್ನು ಅನುಸರಿಸಿ. ಇವೆಲ್ಲವನ್ನೂ ಒಂದೇ ಖಾಲಿ ಲೈನ್ ನಿಂದ ಬೇರ್ಪಡಿಸಬೇಕು.

6. count / for_each ಆರ್ಗ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಷರತ್ತುಗಳನ್ನು ಬಳಸುವಾಗ length ಅಥವಾ ಇತರ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬಳಸುವ ಬದಲು, ಬೂಲಿಯನ್ ಮೌಲ್ಯಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ.

resource ಕೋಡ್ ಉದಾಹರಣೆಗಳು

count / for_eachನ ಬಳಕೆ

resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "private" {
  for_each = toset(["one", "two"])

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

tagsನಿಯೋಜನೆ

resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

countಅಲ್ಲಿ ಷರತ್ತುಗಳು

resource "aws_nat_gateway" "that" {    # Best
  count = var.create_public_subnets ? 1 : 0
}

resource "aws_nat_gateway" "this" {    # Good
  count = length(var.public_subnets) > 0 ? 1 : 0
}

ವೇರಿಯೇಬಲ್‌ಗಳು (Variables)

1. ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಬಹಳ ವಿಷಯಗಳನ್ನು ಮರು ಉಪಯೋಗಿಸಬಹುದು: ನೀವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ"Argument Reference" ವಿಭಾಗದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ name, description, ಮತ್ತು default ವೇರಿಯೇಬಲ್ ಗಳನ್ನು ಉಪಯೋಗಿಸಿರಿ.

2. ವೇರಿಯೇಬಲ್‌ಗಳಲ್ಲಿ ವ್ಯಾಲಿಡೇಷನ್ ಬೆಂಬಲವು ಸೀಮಿತವಾಗಿದೆ (ಉದಾ. ಇತರ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಆಕ್ಸೆಸ್ ಅಥವಾ ಲುಕಪ್‌ಗಳನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ). ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ ಈ ವೈಶಿಷ್ಟ್ಯವು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿರುವುದರಿಂದ ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಯೋಜಿಸಿ.

3. ಟೈಪ್ ಗಳು list(...) ಅಥವ map(...)ಆದಾಗ ವೇರಿಯಬಲ್ ಹೆಸರಿನಲ್ಲಿ ಬಹುವಚನ ರೂಪವನ್ನು ಬಳಸಿ.

4. ವೇರಿಯೇಬಲ್ ಬ್ಲಾಕ್ ಗಳಲ್ಲಿ ಕೀ ಗಳನ್ನು ಈ ರೀತಿಯಾಗಿ ಒಂದಾದ ಮೇಲೆ ಇನ್ನೊಂದರಂತೆ ವ್ಯವಸ್ತಿತಗೊಳಿಸಿ: description , type, default, validation.

5. ವೇರಿಯೇಬಲ್ ಗಳಲ್ಲಿ description ತಪ್ಪದೇ ಹಾಕಿರಿ, ಅದು ಸ್ಪಷ್ಟವಾಗಿದ್ದರೂ ಸಹ (ನಿಮಗೆ ಮುಂದೆ ಬೇಕಾಗುತ್ತದೆ).

6. ಪ್ರತಿ ಕೀಯಲ್ಲಿ ನೀವು ಕಟ್ಟುನಿಟ್ಟಾದ constraint ಗಳನ್ನು ಹೊಂದಿರಬೇಕಿಲ್ಲದಿದ್ದರೆ, ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರಕ್ಕಿಂತ (object()) ಸರಳ ಪ್ರಕಾರಗಳನ್ನು (number, string, list(...), map(...), any) ಬಳಸಲು ಆದ್ಯತೆ ನೀಡಿ.

7. ಮ್ಯಾಪ್ ನ ಎಲ್ಲಾ ಅಂಶಗಳು ಒಂದೇ ಟೈಪ್ ನವು (ಉದಾ:string) ಆಗಿದ್ದಲ್ಲಿ ಅಥವಾ ಪರಿವರ್ತಿಸಬಹುದಾಗಿದ್ದಲ್ಲಿ (ಉದಾ:number type can be converted to string) ನಿರ್ದಿಷ್ಟ ಟೈಪ್ ಗಳನ್ನು ಬಳಸಿ.

8. ನಿರ್ದಿಷ್ಟ ಆಳದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಟೈಪ್ ನ ವ್ಯಾಲಿಡೇಷನ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಅಥವ ಬಹು ಟೈಪ್ ಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕಾದಾಗ any ಪ್ರಕಾರವನ್ನು ಬಳಸಿ

9. {}ಎನ್ನುವುದು ಕೆಲವೊಂದು ಸಲ ಮ್ಯಾಪ್ ಆಗಿರಬಹುದು ಅಥವ ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರಬಹುದು. ಈ ತರಹ ಇದ್ದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನುtomap(...) ಬಳಸಿ ಮ್ಯಾಪ್ ಆಗಿ ಪರಿವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಆಬ್ಜೆಕ್ಟ್ ಮಾಡಲು ಆಗುವುದಿಲ್ಲ.

ಔಟ್‌ಪುಟ್‌ಗಳು

ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಅದರ ವ್ಯಾಪ್ತಿಯ ಹೊರಗೆ ಸ್ಥಿರವಾಗಿ ಮತ್ತು ಅರ್ಥವಾಗುವಂತೆ ಮಾಡಿ (ಒಬ್ಬ ಬಳಕೆದಾರರು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವಾಗ ಅದು ಯಾವ ಟೈಪ್ ಮತ್ತು ಅಟ್ರಿಬ್ಯೂಟ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು).

1. ಔಟ್‌ಪುಟ್‌ನ ಹೆಸರು ಅದು ಹೊಂದಿರುವ ಆಸ್ತಿಯನ್ನು ವಿವರಿಸಬೇಕು ಮತ್ತು ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಬಯಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಮುಕ್ತ-ರೂಪವಾಗಿರಬೇಕು.

2. ಔಟ್ಪುಟ್ ಹೆಸರಿನ ಉತ್ತಮ ರಚನೆಯು{name}_{type}_{attribute} ರೀತಿಯಲ್ಲಿ ಇರುತ್ತದೆ . ಇದರಲ್ಲಿ:

   1. {name}ಪೂರೈಕೆದಾರರ prefix ಇಲ್ಲದ ಸಂಪನ್ಮೂಲ ಅಥವಾ ಡೇಟಾ ಮೂಲದ ಹೆಸರು.aws_subnetಗೆ {name} subnet, ws_vpcಗೆ ಅದು vpc.

   2. {type}ಒಂದು ರೀತಿಯ ಸಂಪನ್ಮೂಲ ಮೂಲವಾಗಿದೆ

   3. {attribute}ಔಟ್ಪುಟ್ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಿದ ಅಟ್ರಿಬ್ಯೂಟ್ ಆಗಿದೆ

   4. ಉದಾ. ನೋಡಿ

3. ಔಟ್‌ಪುಟ್ ಇಂಟರ್‌ಪೋಲೇಷನ್ ಫಂಕ್ಷನ್‌ಗಳ ಮತ್ತು ಬಹು ಸಂಪನ್ಮೂಲಗಳ ಮೂಲಕ value ವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿದ್ದರೆ,{name} ಮತ್ತು {type} ಸಾಧ್ಯವಾದಷ್ಟು generic ಆಗಿರಬೇಕು (this ಅನ್ನು prefix ಆಗಿ ಬಿಟ್ಟುಬಿಡಬೇಕು) ಉದಾ. ನೋಡಿ

4. ಹಿಂತಿರುಗಿಸಿದ value ಲಿಸ್ಟ್ ಆಗಿದ್ದರೆ ಅದು ಬಹುವಚನ ಹೆಸರನ್ನು ಹೊಂದಿರಬೇಕು. ಉದಾ. ನೋಡಿ.

5. ಔಟ್‌ಪುಟ್‌ಗಳಲ್ಲಿ description ತಪ್ಪದೇ ಹಾಕಿರಿ, ಅದು ಸ್ಪಷ್ಟವಾಗಿದ್ದರೂ ಸಹ (ನಿಮಗೆ ಮುಂದೆ ಬೇಕಾಗುತ್ತದೆ).

6. ಎಲ್ಲಾ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಎಲ್ಲಾ ಸ್ಥಳಗಳಲ್ಲಿ ಈ ಔಟ್‌ಪುಟ್‌ನ ಬಳಕೆಯನ್ನು ನಿಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದಲ್ಲಿ sensitive ಆರ್ಗ್ಯುಮೆಂಟ್ ಗಳ ಬಳಕೆಯನ್ನು ತಪ್ಪಿಸಿ.

7. element(concat(...))(0.13ಗಿಂತ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳಿಗೆ) ಬದಲು try()ಗೆ ಆದ್ಯತೆ (ಟೆರಾಫಾರ್ಮ್ 0.13 ರಿಂದ ಲಭ್ಯವಿದೆ).

outputಕೋಡ್ ಉದಾಹರಣೆಗಳು

ಹೆಚ್ಚೆಂದರೆ ಭದ್ರತಾ ಗುಂಪಿನ ಒಂದು ID ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಿ :

output "security_group_id" {
  description = "The ID of the security group"
  value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}

ಒಂದೇ ರೀತಿಯ ಬಹು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವಾಗ,this ಅನ್ನು ಔಟ್‌ಪುಟ್ ಹೆಸರಿನಲ್ಲಿ ಬಿಟ್ಟುಬಿಡಬೇಕು:

output "this_security_group_id" {
  description = "The ID of the security group"
  value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}

ಹಿಂತಿರುಗಿಸುವ value, ಲಿಸ್ಟ್ ಆಗಿದ್ದರೆ, ಬಹುವಚನ ಹೆಸರನ್ನು ಬಳಸಿ

output "rds_cluster_instance_endpoints" {
  description = "A list of all cluster instance endpoints"
  value       = aws_rds_cluster_instance.this.*.endpoint
}

ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ರಚನೆಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆಗಳು ಸಮುದಾಯದಲ್ಲಿ ಆಗಾಗ್ಗೆ ಕಂಡುಬರುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವುದಾದರು ಹಂತದಲ್ಲಿ project ನ ಉತ್ತಮ ಕೋಡ್ ರಚನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಿರುತ್ತಾರೆ.

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ಗಳನ್ನು ನಾನು ಹೇಗೆ ರಚಿಸಬೇಕು?

ಸಾಕಷ್ಟು ಪರಿಹಾರಗಳು ಇರುವ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಇದೂ ಒಂದು, ಆದ್ದರಿಂದ ಸಾರ್ವತ್ರಿಕ ಸಲಹೆಯನ್ನು ನೀಡುವುದು ತುಂಬಾ ಕಷ್ಟ. ಹೀಗಾಗಿ ನಾವು ಏನು ವ್ಯವಹರಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸೋಣ.

• ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ complexity ಏನು?

  • ಸಂಬಂಧಿತ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ

  • ಟೆರಾಫಾರ್ಮ್ ಪೂರೈಕೆದಾರರ ಸಂಖ್ಯೆ ("ತಾರ್ಕಿಕ ಪೂರೈಕೆದಾರರ" ಕುರಿತು ಕೆಳಗಿನ ಟಿಪ್ಪಣಿಯನ್ನು ನೋಡಿ)

• ನಿಮ್ಮ infrastructure ಎಷ್ಟು ಬಾರಿ ಬದಲಾಗುತ್ತದೆ?

  • ತಿಂಗಳಿಗೆ/ವಾರಕ್ಕೆ/ದಿನಕ್ಕೊಮ್ಮೆ

  • ನಿರಂತರವಾಗಿ (ಹೊಸ ಬದ್ಧತೆ ಇದ್ದಾಗಲೆಲ್ಲಾ)

• ಕೋಡ್ ಬದಲಾವಣೆಯ initiator ಗಳು ? ಹೊಸ artifact ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ CI ಸರ್ವರ್ ರೆಪೊಸಿಟೋರಿಯನ್ನು ನವೀಕರಿಸಲು ನೀವು ಅನುಮತಿಸುತ್ತೀರಾ?

  • ಡೆವಲಪರ್‌ಗಳು ಮಾತ್ರ infrastructure ರೆಪೊಸಿಟೋರಿಗೆ ತಳ್ಳಬಹುದು

  • PR ಅನ್ನು ತೆರೆಯುವ ಮೂಲಕ ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವುದಕ್ಕೂ ಬದಲಾವಣೆಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಬಹುದು (CI ಸರ್ವರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯಗಳು ಸೇರಿದಂತೆ)

• ನೀವು ಯಾವ deployment ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅಥವಾ deployment ಸೇವೆಯನ್ನು ಬಳಸುತ್ತೀರಿ?

  • AWS CodeDeploy, Kubernetes, ಅಥವಾ OpenShiftಗೆ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ವಿಧಾನದ ಅಗತ್ಯವಿದೆ

• ಪರಿಸರಗಳನ್ನು ಹೇಗೆ ಗುಂಪು ಮಾಡಲಾಗಿದೆ?

  • ಪರಿಸರ, ಪ್ರದೇಶ, ಪ್ರಾಜೆಕ್ಟ್ ಮೂಲಕ

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ಗಳ ಬಗೆಗೆ

ನೀವು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವಾಗ ಅಥವಾ ಉದಾಹರಣೆ ಕೋಡ್ ಬರೆಯುವಾಗ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನುmain.tfನಲ್ಲಿ ಹಾಕುವುದು ಒಳ್ಳೆಯದು. ಇತರ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ನೀವು ಹಲವಾರು ಫೈಲ್‌ಗಳನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಈ ರೀತಿ ವಿಭಜಿಸಿದರೆ ಉತ್ತಮವಾಗಿರುತ್ತದೆ:

• main.tf - ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ಮಾಡ್ಯೂಲ್‌ಗಳು, locals ಮತ್ತು ಮಾಹಿತಿ ಮೂಲಗಳನ್ನು ಕರೆ ಮಾಡಿ

• variables.tf - main.tfನಲ್ಲಿ ಬಳಸಲಾದ variable ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

• outputs.tf - main.tfನಲ್ಲಿ ರಚಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

• versions.tf -ಟೆರಾಫಾರ್ಮ್ ಮತ್ತು ಪೂರೈಕೆದಾರರಿಗೆ version ಅವಶ್ಯಕತೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

terraform.tfvars ಅನ್ನುcomposition ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಿಯೂ ಬಳಸಬಾರದು.

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ರಚನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಹೇಗೆ?

ಕೋಡ್ ರಚನೆಗೆ ಸಾಮಾನ್ಯ ಶಿಫಾರಸುಗಳು

• ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಸುಲಭ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ

  • ಸಂಪನ್ಮೂಲಗಳ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲುterraform plan ಮತ್ತು terraform apply ಎರಡೂ ಕ್ಲೌಡ್ API ಕರೆಗಳನ್ನು ಮಾಡುತ್ತವೆ

  • ನಿಮ್ಮ ಸಂಪೂರ್ಣ infrastructure ಅನ್ನು ನೀವು ಒಂದೇ ಸಂಯೋಜನೆಯಲ್ಲಿ ಹೊಂದಿದ್ದರೆ ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು

• ಬ್ಲಾಸ್ಟ್ ರೇಡಿಯಸ್ (ಭದ್ರತಾ ಉಲ್ಲಂಘನೆಯ ಸಂದರ್ಭದಲ್ಲಿ) ಕಡಿಮೆ ಸಂಪನ್ಮೂಲಗಳಿದ್ದರೆ ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ

  • ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕಂಪೋಸಿಷನ್ಸ್ ಗಳಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

• ರಿಮೋಟ್ ಸ್ಥಿತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ ಏಕೆಂದರೆ:

  • ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ infrastructure ಮೂಲಕ್ಕೆ ಸ್ಥಳವಲ್ಲ

  • git ನಲ್ಲಿ tfstate ಫೈಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಒಂದು ದುಃಸ್ವಪ್ನವಾಗಿದೆ

  • ಮುಂದೆ infrastructure ಲೇಯರ್ ಗಳು ಅನೇಕ ದಿಕ್ಕುಗಳಲ್ಲಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ (ಅವಲಂಬನೆಗಳು ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ) ವಿಷಯಗಳನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡಲು ಸುಲಭವಾಗುತ್ತದೆ

• ಸ್ಥಿರವಾದ ಸ್ಟ್ರಕ್ಚರ್ ಮತ್ತು ನೇಮಿಂಗ್ conventionಗಳನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ:

  • ಪ್ರೊಸೀಜರ್ ಕೋಡ್‌ನಂತೆ, ಮೊದಲು ಓದಲು ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕು, ಆರು ತಿಂಗಳ ನಂತರ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಾಗ ಸ್ಥಿರತೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ

  • ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಫೈಲ್‌ನಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಿಸಲು ಸಾಧ್ಯವಿದೆ ಆದರೆ ನೀವು ಅಸಮಂಜಸವಾದ ಸ್ಟ್ರಕ್ಚರ್ ಮತ್ತು ನೇಮಿಂಗ್ conventionಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದನ್ನು ಮಾಡಲು ಕಷ್ಟವಾಗಬಹುದು

• ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಇರಿಸಿ

• ವೇರಿಯೇಬಲ್‌ಗಳಾಗಿ ರವಾನಿಸಬಹುದಾದ ಅಥವಾ ಡೇಟಾ ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಂಡುಹಿಡಿಯಬಹುದಾದ ಮೌಲ್ಯಗಳನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಬೇಡಿ

• ಕಾಂಪೊಸಿಷನ್ ಒಳಗಿನ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳ ನಡುವೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಡೇಟಾ ಮೂಲಗಳು ಮತ್ತು terraform_remote_state ಅನ್ನು ಸೇತುವೆಯಂತೆ ಬಳಸಿ

ಈ ಪುಸ್ತಕದಲ್ಲಿ, ಉದಾಹರಣೆ ಪ್ರಾಜೆಕ್ಟ್ ಗಳನ್ನು complexity ಅಡಿಯಲ್ಲಿ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ - ಸಣ್ಣದಿಂದ ಅತಿ ದೊಡ್ಡ ಮೂಲಸೌಕರ್ಯಗಳವರೆಗೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯು ಕಟ್ಟುನಿಟ್ಟಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಇತರ ಸ್ಟ್ರಕ್ಚರ್ ಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸಬಹುದು.

Infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಗಳ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ಸಣ್ಣ infrastructureಅನ್ನು ಹೊಂದಿರುವುದು ಎಂದರೆ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಸ್ವಲ್ಪವೇ ಸಂಪನ್ಮೂಲಗಳು. ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳೆದಂತೆ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ವಿಭಿನ್ನ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಒಳಗೆ value ಗಳನ್ನು ಪಾಸ್ ಮಾಡುವ ಅಗತ್ಯವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಬಳಸುವ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸೊಲ್ಯೂಷನ್ ಗಳು ಕನಿಷ್ಠ 5 ವಿಭಿನ್ನ ಗುಂಪುಗಳಿವೆ:

1. ಟೆರಾಫಾರ್ಮ್ ಮಾತ್ರ. ತುಂಬಾ ಸರಳವಾದದ್ದು, ಡೆವಲಪರ್‌ಗಳು ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಮಾತ್ರ ತಿಳಿದಿರಬೇಕು.

2. ಟೆರಾಗ್ರಂಟ್. ಸಂಪೂರ್ಣ infrastructureಅನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಳಸಬಹುದಾದ ಶುದ್ಧ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಾಧನ. Terragrunt ಲೋಕಲ್ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಕೋಡ್‌ನ ನಕಲು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

3. ಇನ್-ಹೌಸ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕಡೆಗೆ ಆರಂಭಿಕ ಹಂತವಾಗಿ ಮತ್ತು ಟೆರಾಗ್ರಂಟ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ.

4. ಅನ್ಸಿಬಲ್ ಅಥವಾ ಅಂತಹುದೇ ಜನರಲ್ ಸಾಧನ. Ansible ನಂತರ Terraform ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡಾಗ ಅಥವಾ Ansible UI ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

5. Crossplane ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್-ಪ್ರೇರಿತ ಸೊಲ್ಯೂಷನ್ ಗಳು. ಕೆಲವೊಮ್ಮೆ, ನಿಮ್ಮ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ಗಳ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ಸಾಧಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಮತ್ತು reconciliation ಲೂಪ್ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ Crossplane vs Terraform ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸಿ.

ಅದನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ಈ ಪುಸ್ತಕವು ಈ ಪ್ರಾಜೆಕ್ಟ್ ಗಳ ಮೊದಲ ಎರಡು ಬಿಲ್ಡ್ ಗಳನ್ನು ವಿಮರ್ಶಿಸುತ್ತದೆ, ಟೆರಾಫಾರ್ಮ್ ಮಾತ್ರ ಮತ್ತು ಟೆರಾಗ್ರಂಟ್.

ಮುಂದಿನ ಅಧ್ಯಾಯದಲ್ಲಿ Terraform ಅಥವಾ Terragrunt ಕೋಡ್ ರಚನೆಗಳ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡಿ

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

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