ಅನೇಕ ಜನರು ತಮ್ಮ ದೈನಂದಿನ ಕೆಲಸದಲ್ಲಿ ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಬಳಸುತ್ತಾರೆ, ಆದರೆ ಅದಕ್ಕಾಗಿ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಇನ್ನೂ ರೂಪುಗೊಂಡಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ತಂಡವು ತನ್ನದೇ ಆದ ವಿಧಾನಗಳು ಮತ್ತು ವಿಧಾನಗಳನ್ನು ಆವಿಷ್ಕರಿಸಬೇಕು.
ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ಬಹುತೇಕ ಸರಳವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು + ಕೆಲವು ಡೆವಲಪರ್‌ಗಳು. ಕಾಲಾನಂತರದಲ್ಲಿ, ಇದು ಎಲ್ಲಾ ರೀತಿಯ ದಿಕ್ಕುಗಳಲ್ಲಿ ಬೆಳೆಯುತ್ತದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಗುಂಪು ಮಾಡಲು, ಫೋಲ್ಡರ್‌ಗಳಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಸಂಘಟಿಸಲು ಮತ್ತು ಬೇರೆ ಏನು ತಪ್ಪಾಗಬಹುದು ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಾ? (ಜನಪ್ರಿಯವಾದ ಕೊನೆಯ ಮಾತುಗಳು)
ಸಮಯವು ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ನಿಮ್ಮ ಹೊಸ ಸಾಕುಪ್ರಾಣಿ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ, ಆದರೆ ಏಕೆ? ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ವಿವರಿಸಲಾಗದ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ನೀವು ಚಿಂತಿತರಾಗಿದ್ದೀರಿ, ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸಲು ನೀವು ಭಯಪಡುತ್ತೀರಿ - ಪರಿಣಾಮವಾಗಿ, ನೀವು ಹೊಸ ಕಾರ್ಯವನ್ನು ವಿಳಂಬಗೊಳಿಸುತ್ತೀರಿ ಅಥವಾ ಗುಣಮಟ್ಟವನ್ನು ಕಡಿಮೆಗೊಳಿಸುತ್ತೀರಿ...
ಗಿಥಬ್‌ನಲ್ಲಿನ AWS ಗಾಗಿ ಟೆರ್ರಾಫಾರ್ಮ್ ಸಮುದಾಯ ಮಾಡ್ಯೂಲ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ನಿರ್ವಹಿಸಿದ ಮೂರು ವರ್ಷಗಳ ನಂತರ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಟೆರ್ರಾಫಾರ್ಮ್‌ನ ದೀರ್ಘಕಾಲೀನ ನಿರ್ವಹಣೆಯ ನಂತರ, ಆಂಟನ್ ಬಾಬೆಂಕೊ ತನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸಿದ್ಧರಾಗಿದ್ದಾರೆ: ಭವಿಷ್ಯದಲ್ಲಿ ನೋಯಿಸದಂತೆ TF ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೇಗೆ ಬರೆಯುವುದು.
ಮಾತುಕತೆಯ ಅಂತ್ಯದ ವೇಳೆಗೆ, ಭಾಗವಹಿಸುವವರು ಟೆರಾಫಾರ್ಮ್‌ನಲ್ಲಿನ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ ತತ್ವಗಳು, ಟೆರಾಫಾರ್ಮ್‌ನಲ್ಲಿ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ನಿರ್ವಹಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲವು ನಿರಂತರ ಏಕೀಕರಣ ತತ್ವಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ಪರಿಚಿತರಾಗಿರುತ್ತಾರೆ.
ಹಕ್ಕುತ್ಯಾಗ: ಈ ವರದಿಯು ನವೆಂಬರ್ 2018 ರ ದಿನಾಂಕವಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ—ಈಗಾಗಲೇ 2 ವರ್ಷಗಳು ಕಳೆದಿವೆ. ವರದಿಯಲ್ಲಿ ಚರ್ಚಿಸಲಾದ Terraform 0.11 ಆವೃತ್ತಿಯು ಇನ್ನು ಮುಂದೆ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಕಳೆದ 2 ವರ್ಷಗಳಲ್ಲಿ, 2 ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ, ಇದು ಬಹಳಷ್ಟು ನಾವೀನ್ಯತೆಗಳು, ಸುಧಾರಣೆಗಳು ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ದಯವಿಟ್ಟು ಈ ಬಗ್ಗೆ ಗಮನಹರಿಸಿ ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಉಲ್ಲೇಖಗಳು:
- +
- - ಸ್ವಯಂ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಕೋಡ್ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು
- - ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳ ಜನರೇಟರ್ (WIP)
- - ದೃಶ್ಯ ರೇಖಾಚಿತ್ರಗಳಿಂದ ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ಜನರೇಟರ್ (WIP)
- www.terraform-best-practices.com
- (ಹೊಸ ಪೋಸ್ಟ್‌ಗಳು ನನ್ನ ವೈಯಕ್ತಿಕ ವೆಬ್‌ಸೈಟ್ www.antonbabenko.com/ ನಲ್ಲಿವೆ)
- @antonbabenko - ಟ್ವಿಟರ್, ಮತ್ತು ವಿವಿಧ ಸ್ಲಾಕ್ಸ್‌ಗಳ ಸಮೂಹ
ನನ್ನ ಹೆಸರು ಆಂಟನ್ ಬಾಬೆಂಕೊ. ನಿಮ್ಮಲ್ಲಿ ಕೆಲವರು ಬಹುಶಃ ನಾನು ಬರೆದ ಕೋಡ್ ಅನ್ನು ಬಳಸಿದ್ದಾರೆ. ನಾನು ಈಗ ಈ ಬಗ್ಗೆ ಎಂದಿಗಿಂತಲೂ ಹೆಚ್ಚು ವಿಶ್ವಾಸದಿಂದ ಮಾತನಾಡುತ್ತೇನೆ, ಏಕೆಂದರೆ ನನಗೆ ಅಂಕಿಅಂಶಗಳಿಗೆ ಪ್ರವೇಶವಿದೆ.
ನಾನು ಟೆರ್ರಾಫಾರ್ಮ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು 2015 ರಿಂದ ಟೆರಾಫಾರ್ಮ್ ಮತ್ತು ಅಮೆಜಾನ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ ಸಕ್ರಿಯ ಪಾಲ್ಗೊಳ್ಳುವವ ಮತ್ತು ಕೊಡುಗೆದಾರನಾಗಿದ್ದೇನೆ.
ಅಂದಿನಿಂದ ನಾನು ಅದನ್ನು ಆಸಕ್ತಿದಾಯಕ ರೀತಿಯಲ್ಲಿ ಹಾಕಲು ಸಾಕಷ್ಟು ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ. ಮತ್ತು ನಾನು ಈಗ ಇದರ ಬಗ್ಗೆ ಹೇಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ನಾನು ಟೆರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜಟಿಲತೆಗಳು ಮತ್ತು ನಿಶ್ಚಿತಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ. ಆದರೆ ಇದು ನಿಜವಾಗಿಯೂ ಹೈಲೋಡ್‌ನ ವಿಷಯವಲ್ಲ. ಮತ್ತು ಈಗ ನೀವು ಏಕೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಿರಿ.
ಕಾಲಾನಂತರದಲ್ಲಿ, ನಾನು ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಬಳಕೆದಾರರು ಪ್ರಶ್ನೆಗಳನ್ನು ಬರೆದರು, ನಾನು ಅವುಗಳನ್ನು ಪುನಃ ಬರೆದಿದ್ದೇನೆ. ನಂತರ ನಾನು ಪೂರ್ವ-ಕಮಿಟ್ ಹುಕ್, ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕೋಡ್ ಅನ್ನು ಫಾರ್ಮಾಟ್ ಮಾಡಲು ವಿವಿಧ ಉಪಯುಕ್ತತೆಗಳನ್ನು ಬರೆದಿದ್ದೇನೆ.
ಅನೇಕ ಆಸಕ್ತಿದಾಯಕ ಯೋಜನೆಗಳು ಇದ್ದವು. ನಾನು ಕೋಡ್ ಉತ್ಪಾದನೆಯನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ ಏಕೆಂದರೆ ಕಂಪ್ಯೂಟರ್ ನನಗೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಮರ್‌ಗಾಗಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಕೆಲಸ ಮಾಡಲು ಇಷ್ಟಪಡುತ್ತೇನೆ, ಆದ್ದರಿಂದ ನಾನು ಪ್ರಸ್ತುತ ದೃಶ್ಯ ರೇಖಾಚಿತ್ರಗಳಿಂದ ಟೆರ್ರಾಫಾರ್ಮ್ ಕೋಡ್ ಜನರೇಟರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಬಹುಶಃ ನಿಮ್ಮಲ್ಲಿ ಕೆಲವರು ಅವರನ್ನು ನೋಡಿರಬಹುದು. ಇವು ಬಾಣಗಳನ್ನು ಹೊಂದಿರುವ ಸುಂದರವಾದ ಪೆಟ್ಟಿಗೆಗಳಾಗಿವೆ. ಮತ್ತು ನೀವು "ರಫ್ತು" ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದರೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಕೋಡ್ ಆಗಿ ಪಡೆಯುವುದು ಉತ್ತಮ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.
ನಾನು ಉಕ್ರೇನ್‌ನಿಂದ ಬಂದಿದ್ದೇನೆ. ನಾನು ಅನೇಕ ವರ್ಷಗಳಿಂದ ನಾರ್ವೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೇನೆ.
ಅಲ್ಲದೆ, ನನ್ನ ಹೆಸರನ್ನು ತಿಳಿದಿರುವ ಮತ್ತು ಸಾಮಾಜಿಕ ಜಾಲತಾಣಗಳಲ್ಲಿ ನನ್ನನ್ನು ಹುಡುಕುವವರಿಂದ ಈ ವರದಿಗಾಗಿ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ನಾನು ಯಾವಾಗಲೂ ಅದೇ ಅಡ್ಡಹೆಸರನ್ನು ಹೊಂದಿದ್ದೇನೆ.
ನಾನು ಹೇಳಿದಂತೆ, ನಾನು ಟೆರಾಫಾರ್ಮ್ AWS ಮಾಡ್ಯೂಲ್‌ಗಳ ಮುಖ್ಯ ನಿರ್ವಾಹಕನಾಗಿದ್ದೇನೆ, ಇದು GitHub ನಲ್ಲಿನ ಅತಿದೊಡ್ಡ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಅಲ್ಲಿ ನಾವು ಸಾಮಾನ್ಯ ಕಾರ್ಯಗಳಿಗಾಗಿ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತೇವೆ: VPC, ಆಟೋಸ್ಕೇಲಿಂಗ್, RDS.
ಮತ್ತು ನೀವು ಈಗ ಕೇಳಿದ್ದು ಅತ್ಯಂತ ಮೂಲಭೂತವಾಗಿದೆ. ಟೆರಾಫಾರ್ಮ್ ಎಂದರೇನು ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದು ನೀವು ಅನುಮಾನಿಸಿದರೆ, ನಿಮ್ಮ ಸಮಯವನ್ನು ಬೇರೆಡೆ ಕಳೆಯುವುದು ಉತ್ತಮ. ಇಲ್ಲಿ ಸಾಕಷ್ಟು ತಾಂತ್ರಿಕ ಪದಗಳು ಇರುತ್ತವೆ. ಮತ್ತು ವರದಿಯ ಮಟ್ಟವನ್ನು ಅತ್ಯುನ್ನತ ಎಂದು ಘೋಷಿಸಲು ನಾನು ಹಿಂಜರಿಯಲಿಲ್ಲ. ಇದರರ್ಥ ನಾನು ಹೆಚ್ಚು ವಿವರಣೆಯಿಲ್ಲದೆ ಸಾಧ್ಯವಿರುವ ಎಲ್ಲಾ ಪದಗಳನ್ನು ಬಳಸಿ ಮಾತನಾಡಬಲ್ಲೆ.
ಟೆರ್ರಾಫಾರ್ಮ್ 2014 ರಲ್ಲಿ ಒಂದು ಉಪಯುಕ್ತತೆಯಾಗಿ ಕಾಣಿಸಿಕೊಂಡಿತು ಅದು ನಿಮಗೆ ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬರೆಯಲು, ಯೋಜಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಇಲ್ಲಿ ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಯು "ಕೋಡ್ ಆಗಿ ಮೂಲಸೌಕರ್ಯ" ಆಗಿದೆ.
ಎಲ್ಲಾ ದಸ್ತಾವೇಜನ್ನು, ನಾನು ಹೇಳಿದಂತೆ, ಬರೆಯಲಾಗಿದೆ . ಹೆಚ್ಚಿನ ಜನರು ಈ ಸೈಟ್ ಬಗ್ಗೆ ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಓದಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಹಾಗಿದ್ದಲ್ಲಿ, ನೀವು ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿದ್ದೀರಿ.
ನಿಯಮಿತವಾದ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ, ಅಲ್ಲಿ ನಾವು ಮೊದಲು ಕೆಲವು ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು "aws_region" ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ.
ನಂತರ ನಾವು ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ.
ಅವಲಂಬನೆಗಳು ಮತ್ತು ಪೂರೈಕೆದಾರರನ್ನು ಲೋಡ್ ಮಾಡಲು ನಾವು ಕೆಲವು ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸುತ್ತೇವೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ "ಟೆರ್ರಾಫಾರ್ಮ್ init".
ಮತ್ತು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಂರಚನೆಯು ನಾವು ರಚಿಸಿದ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ನಾವು “ಟೆರಾಫಾರ್ಮ್ ಅನ್ವಯಿಸು” ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುತ್ತೇವೆ. ನಾವು ಮೊದಲು ಏನನ್ನೂ ರಚಿಸದ ಕಾರಣ, ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ಟೆರಾಫಾರ್ಮ್ ನಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ.
ನಾವು ಇದನ್ನು ದೃಢೀಕರಿಸುತ್ತೇವೆ. ಹೀಗಾಗಿ ನಾವು ಸೀಸ್ನೇಲ್ ಎಂಬ ಬಕೆಟ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ.
ಇದೇ ರೀತಿಯ ಹಲವಾರು ಉಪಯುಕ್ತತೆಗಳಿವೆ. Amazon ಅನ್ನು ಬಳಸುವ ನಿಮ್ಮಲ್ಲಿ ಅನೇಕರಿಗೆ AWS CloudFormation ಅಥವಾ Google Cloud Deployment Manager ಅಥವಾ Azure Resource Manager ತಿಳಿದಿದೆ. ಈ ಪ್ರತಿಯೊಂದು ಸಾರ್ವಜನಿಕ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರೊಳಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಅನುಷ್ಠಾನವನ್ನು ಹೊಂದಿದೆ. ಟೆರಾಫಾರ್ಮ್ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು 100 ಪೂರೈಕೆದಾರರನ್ನು ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. (ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗಾಗಿ )
ಟೆರ್ರಾಫಾರ್ಮ್ ಮೊದಲಿನಿಂದಲೂ ಅನುಸರಿಸಿದ ಗುರಿಗಳು:
- ಟೆರಾಫಾರ್ಮ್ ಸಂಪನ್ಮೂಲಗಳ ಏಕ ನೋಟವನ್ನು ಒದಗಿಸುತ್ತದೆ.
- ಎಲ್ಲಾ ಆಧುನಿಕ ವೇದಿಕೆಗಳನ್ನು ಬೆಂಬಲಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
- ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಮೊದಲಿನಿಂದಲೂ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಮತ್ತು ನಿರೀಕ್ಷಿತವಾಗಿ ಬದಲಾಯಿಸಲು ಅನುಮತಿಸುವ ಉಪಯುಕ್ತತೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
2014 ರಲ್ಲಿ, "ಊಹಿಸಬಹುದಾದ" ಪದವು ಈ ಸಂದರ್ಭದಲ್ಲಿ ತುಂಬಾ ಅಸಾಮಾನ್ಯವಾಗಿದೆ.
ಟೆರಾಫಾರ್ಮ್ ಒಂದು ಸಾರ್ವತ್ರಿಕ ಉಪಯುಕ್ತತೆಯಾಗಿದೆ. ನೀವು API ಹೊಂದಿದ್ದರೆ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲವನ್ನೂ ನಿಯಂತ್ರಿಸಬಹುದು:
- ನಿಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ನಿರ್ವಹಿಸಲು ನೀವು 120 ಕ್ಕೂ ಹೆಚ್ಚು ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಬಹುದು.
- ಉದಾಹರಣೆಗೆ, ನೀವು GitHub ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ವಿವರಿಸಲು Terraform ಅನ್ನು ಬಳಸಬಹುದು.
- ನೀವು ಜಿರಾದಲ್ಲಿ ದೋಷಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಮುಚ್ಚಬಹುದು.
- ನೀವು ಹೊಸ ರೆಲಿಕ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು.
- ನೀವು ನಿಜವಾಗಿಯೂ ಬಯಸಿದರೆ ಡ್ರಾಪ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಫೈಲ್‌ಗಳನ್ನು ಸಹ ರಚಿಸಬಹುದು.
Go ನಲ್ಲಿ ವಿವರಿಸಬಹುದಾದ ತೆರೆದ API ಹೊಂದಿರುವ Terraform ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ.
ನಾನು ಹಿಂದಿನ ಸ್ಲೈಡ್‌ಗಳಲ್ಲಿ ತೋರಿಸಿದಂತೆ ನಾವು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಸೈಟ್‌ನಲ್ಲಿ ಕೆಲವು ದಾಖಲಾತಿಗಳನ್ನು ಓದಿದ್ದೇವೆ, ಕೆಲವು ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸಿದ್ದೇವೆ ಮತ್ತು main.tf ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ.
ಮತ್ತು ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ, ನೀವು VPC ಅನ್ನು ರಚಿಸುವ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ.
ನೀವು VPC ಅನ್ನು ರಚಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಸರಿಸುಮಾರು ಈ 12 ಸಾಲುಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ. ನೀವು ಯಾವ ಪ್ರದೇಶದಲ್ಲಿ ರಚಿಸಲು ಬಯಸುತ್ತೀರಿ, ಯಾವ cidr_block IP ವಿಳಾಸಗಳನ್ನು ಬಳಸಬೇಕೆಂದು ವಿವರಿಸಿ. ಅಷ್ಟೇ.
ನೈಸರ್ಗಿಕವಾಗಿ, ಯೋಜನೆಯು ಕ್ರಮೇಣ ಬೆಳೆಯುತ್ತದೆ.
ಮತ್ತು ನೀವು ಅಲ್ಲಿ ಹೊಸ ವಿಷಯಗಳ ಗುಂಪನ್ನು ಸೇರಿಸುವಿರಿ: ಸಂಪನ್ಮೂಲಗಳು, ಡೇಟಾ ಮೂಲಗಳು, ನೀವು ಹೊಸ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಸಂಯೋಜಿಸುವಿರಿ, ನಿಮ್ಮ GitHub ಖಾತೆಯಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ನಿರ್ವಹಿಸಲು ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೀರಿ, ಇತ್ಯಾದಿ. ನೀವು ವಿಭಿನ್ನವಾಗಿ ಬಳಸಲು ಬಯಸಬಹುದು DNS ಪೂರೈಕೆದಾರರು, ಎಲ್ಲವನ್ನೂ ದಾಟಿ. ಟೆರಾಫಾರ್ಮ್ ಇದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಕೆಳಗಿನ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.
ನೀವು ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವನ್ನು ಹೊಂದಲು ನಿಮ್ಮ VPC ಯಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಯಸುವ ಕಾರಣ ನೀವು ಕ್ರಮೇಣ internet_gateway ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಇದು ಒಳ್ಳೆಯ ಉಪಾಯ.
ಫಲಿತಾಂಶವು ಈ main.tf ಆಗಿದೆ:
ಇದು main.tf ನ ಮೇಲಿನ ಭಾಗವಾಗಿದೆ.
ಇದು main.tf ನ ಕೆಳಗಿನ ಭಾಗವಾಗಿದೆ.
ನಂತರ ನೀವು ಸಬ್ನೆಟ್ ಅನ್ನು ಸೇರಿಸಿ. ನೀವು NAT ಗೇಟ್‌ವೇಗಳು, ಮಾರ್ಗಗಳು, ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಇತರ ಸಬ್‌ನೆಟ್‌ಗಳ ಗುಂಪನ್ನು ಸೇರಿಸಲು ಬಯಸುವ ಸಮಯದಲ್ಲಿ, ನೀವು 38 ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದರೆ ಸರಿಸುಮಾರು 200-300 ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.
ಅಂದರೆ, ನಿಮ್ಮ main.tf ಫೈಲ್ ಕ್ರಮೇಣ ಬೆಳೆಯುತ್ತಿದೆ. ಮತ್ತು ಆಗಾಗ್ಗೆ ಜನರು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತಾರೆ. main.tf ನಲ್ಲಿ 10-20 Kb ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. 10-20 Kb ಪಠ್ಯ ವಿಷಯವಾಗಿದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಮತ್ತು ಎಲ್ಲವೂ ಎಲ್ಲದಕ್ಕೂ ಸಂಪರ್ಕ ಹೊಂದಿದೆ. ಇದರಿಂದ ಕೆಲಸ ಮಾಡುವುದು ಕ್ರಮೇಣ ಕಷ್ಟವಾಗುತ್ತಿದೆ. 10-20 Kb ಉತ್ತಮ ಬಳಕೆದಾರ ಪ್ರಕರಣವಾಗಿದೆ, ಕೆಲವೊಮ್ಮೆ ಹೆಚ್ಚು. ಮತ್ತು ಇದು ಕೆಟ್ಟದು ಎಂದು ಜನರು ಯಾವಾಗಲೂ ಯೋಚಿಸುವುದಿಲ್ಲ.
ನಿಯಮಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿರುವಂತೆ, ಅಂದರೆ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಅಲ್ಲ, ನಾವು ವಿವಿಧ ವರ್ಗಗಳು, ಪ್ಯಾಕೇಜುಗಳು, ಮಾಡ್ಯೂಲ್ಗಳು, ಗುಂಪುಗಳ ಗುಂಪನ್ನು ಬಳಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಟೆರಾಫಾರ್ಮ್ ನಿಮಗೆ ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.
- ಕೋಡ್ ಬೆಳೆಯುತ್ತಿದೆ.
- ಸಂಪನ್ಮೂಲಗಳ ನಡುವಿನ ಅವಲಂಬನೆಯೂ ಬೆಳೆಯುತ್ತಿದೆ.
ಮತ್ತು ನಮಗೆ ದೊಡ್ಡ, ದೊಡ್ಡ ಅವಶ್ಯಕತೆ ಇದೆ. ನಾವು ಇನ್ನು ಮುಂದೆ ಈ ರೀತಿ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ನಮ್ಮ ಕೋಡ್ ಅಪಾರವಾಗುತ್ತಿದೆ. 10-20 Kb, ಸಹಜವಾಗಿ, ತುಂಬಾ ವಿಶಾಲವಾಗಿಲ್ಲ, ಆದರೆ ನಾವು ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ ಬಗ್ಗೆ ಮಾತ್ರ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಅಂದರೆ ನೀವು ನೆಟ್ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸಿದ್ದೀರಿ. ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ನಿಯೋಜನೆ ES ಕ್ಲಸ್ಟರ್, ಕುಬರ್ನೆಟ್ಸ್ ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ, ಅಲ್ಲಿ 100 Kb ಅನ್ನು ಸುಲಭವಾಗಿ ನೇಯ್ಗೆ ಮಾಡಬಹುದು. ನೀವು ಇದನ್ನೆಲ್ಲ ಬರೆದರೆ, ಟೆರಾಫಾರ್ಮ್ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂದು ನೀವು ಶೀಘ್ರದಲ್ಲೇ ಕಲಿಯುವಿರಿ.
ಟೆರ್ರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ಗಳು ಸ್ವಯಂ-ಒಳಗೊಂಡಿರುವ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿದ್ದು, ಅದನ್ನು ಗುಂಪಿನಂತೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್‌ಗಳ ಬಗ್ಗೆ ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು ಅಷ್ಟೆ. ಅವರು ಸ್ಮಾರ್ಟ್ ಅಲ್ಲ, ಯಾವುದನ್ನಾದರೂ ಅವಲಂಬಿಸಿ ಯಾವುದೇ ಸಂಕೀರ್ಣ ಸಂಪರ್ಕಗಳನ್ನು ಮಾಡಲು ಅವರು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಇದೆಲ್ಲವೂ ಅಭಿವರ್ಧಕರ ಹೆಗಲ ಮೇಲೆ ಬೀಳುತ್ತದೆ. ಅಂದರೆ, ಇದು ನೀವು ಈಗಾಗಲೇ ಬರೆದಿರುವ ಕೆಲವು ರೀತಿಯ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿದೆ. ಮತ್ತು ನೀವು ಅದನ್ನು ಗುಂಪಾಗಿ ಕರೆಯಬಹುದು.
ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮ 10-20-30 Kb ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಆಪ್ಟಿಮೈಜ್ ಮಾಡುತ್ತೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ನಾವು ಕೆಲವು ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬಳಸಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಕ್ರಮೇಣ ಅರಿತುಕೊಳ್ಳುತ್ತಿದ್ದೇವೆ.
ನೀವು ಎದುರಿಸುವ ಮೊದಲ ವಿಧದ ಮಾಡ್ಯೂಲ್ಗಳು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ಗಳಾಗಿವೆ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ ಏನು, ನಿಮ್ಮ ವ್ಯಾಪಾರ ಏನು, ಎಲ್ಲೆಲ್ಲಿ ಮತ್ತು ಯಾವ ಪರಿಸ್ಥಿತಿಗಳಿವೆ ಎಂಬುದನ್ನು ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಇವುಗಳು ನಾನು, ಓಪನ್ ಸೋರ್ಸ್ ಸಮುದಾಯದೊಂದಿಗೆ ಒಟ್ಟಾಗಿ ನಿರ್ವಹಿಸುವ ಮಾಡ್ಯೂಲ್ಗಳಾಗಿವೆ ಮತ್ತು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಆರಂಭಿಕ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳಾಗಿ ನಾವು ಮುಂದಿಡುತ್ತೇವೆ.
ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ನ ಉದಾಹರಣೆ.
ನಾವು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಕರೆದಾಗ, ಅದರ ವಿಷಯಗಳನ್ನು ನಾವು ಯಾವ ಮಾರ್ಗದಿಂದ ಲೋಡ್ ಮಾಡಬೇಕೆಂದು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ.
ನಾವು ಯಾವ ಆವೃತ್ತಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಾವು ಸೂಚಿಸುತ್ತೇವೆ.
ನಾವು ಅಲ್ಲಿ ವಾದಗಳ ಗುಂಪನ್ನು ರವಾನಿಸುತ್ತೇವೆ. ಅಷ್ಟೇ. ನಾವು ಈ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುವಾಗ ನಾವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು ಅಷ್ಟೆ.
ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿದರೆ, ಎಲ್ಲವೂ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ ಎಂದು ಹಲವರು ಭಾವಿಸುತ್ತಾರೆ. ಆದರೆ ಇಲ್ಲ. ಮೂಲಸೌಕರ್ಯವನ್ನು ಆವೃತ್ತಿ ಮಾಡಬೇಕು; ಈ ಅಥವಾ ಆ ಘಟಕವನ್ನು ಯಾವ ಆವೃತ್ತಿಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ಸ್ಪಷ್ಟವಾಗಿ ಉತ್ತರಿಸಬೇಕು.
ಈ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿರುವ ಕೋಡ್ ಇಲ್ಲಿದೆ. ಭದ್ರತಾ ಗುಂಪು ಮಾಡ್ಯೂಲ್. ಇಲ್ಲಿ ಸ್ಕ್ರಾಲ್ 640 ನೇ ಸಾಲಿಗೆ ಹೋಗುತ್ತದೆ. ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಪ್ರತಿ ಸಂಭವನೀಯ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಸೆಕ್ಯುರಿಟಿ-ಕ್ರೂಪ್ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸುವುದು ಬಹಳ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಕಾರ್ಯವಾಗಿದೆ. ಭದ್ರತಾ ಗುಂಪನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಅದಕ್ಕೆ ಯಾವ ನಿಯಮಗಳನ್ನು ರವಾನಿಸಬೇಕೆಂದು ಹೇಳುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಇದು ತುಂಬಾ ಸರಳವಾಗಿರುತ್ತದೆ. ಅಮೆಜಾನ್ ಒಳಗೆ ಮಿಲಿಯನ್ ವಿಭಿನ್ನ ನಿರ್ಬಂಧಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಬಳಸಿದರೆ VPC ಅಂತಿಮ ಬಿಂದು, ಪೂರ್ವಪ್ರತ್ಯಯ ಪಟ್ಟಿ, ವಿವಿಧ APIಗಳು ಮತ್ತು ಇದೆಲ್ಲವನ್ನೂ ಎಲ್ಲವನ್ನೂ ಸಂಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ನಂತರ ಟೆರಾಫಾರ್ಮ್ ಇದನ್ನು ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಮತ್ತು Amazon API ಇದನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಈ ಎಲ್ಲಾ ಭಯಾನಕ ತರ್ಕವನ್ನು ಮಾಡ್ಯೂಲ್ನಲ್ಲಿ ಮರೆಮಾಡಬೇಕು ಮತ್ತು ಈ ರೀತಿ ಕಾಣುವ ಬಳಕೆದಾರರ ಕೋಡ್ ಅನ್ನು ನೀಡಬೇಕಾಗಿದೆ.
ಅದನ್ನು ಒಳಗೆ ಹೇಗೆ ತಯಾರಿಸಲಾಗುತ್ತದೆ ಎಂದು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಯಬೇಕಾಗಿಲ್ಲ.
ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಎರಡನೇ ವಿಧದ ಮಾಡ್ಯೂಲ್ಗಳು ನಿಮ್ಮ ವ್ಯಾಪಾರಕ್ಕೆ ಹೆಚ್ಚು ಅನ್ವಯವಾಗುವ ಸಮಸ್ಯೆಗಳನ್ನು ಈಗಾಗಲೇ ಪರಿಹರಿಸುತ್ತವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಟೆರಾಫಾರ್ಮ್‌ಗೆ ವಿಸ್ತರಣೆಯಾಗಿರುವ ಸ್ಥಳವಾಗಿದೆ ಮತ್ತು ಕಂಪನಿಯ ಮಾನದಂಡಗಳಿಗಾಗಿ ಟ್ಯಾಗ್‌ಗಳಿಗಾಗಿ ಕೆಲವು ಕಠಿಣ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಟೆರಾಫಾರ್ಮ್ ಪ್ರಸ್ತುತ ನಿಮಗೆ ಬಳಸಲು ಅನುಮತಿಸದ ಕಾರ್ಯವನ್ನು ನೀವು ಅಲ್ಲಿ ಸೇರಿಸಬಹುದು. ಇದು ಇದೀಗ ಆಗಿದೆ. ಈಗ ಆವೃತ್ತಿ 0.11, ಇದು ಹಿಂದಿನ ವಿಷಯವಾಗಲು ಹೊರಟಿದೆ. ಆದರೆ ಇನ್ನೂ, ಪ್ರಿಪ್ರೊಸೆಸರ್‌ಗಳು, jsonnet, ಕುಕೀಕಟರ್ ಮತ್ತು ಇತರ ವಸ್ತುಗಳ ಸಮೂಹವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಕೆಲಸಕ್ಕಾಗಿ ಬಳಸಬೇಕಾದ ಸಹಾಯಕ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ.
ಮುಂದೆ ನಾನು ಇದಕ್ಕೆ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ತೋರಿಸುತ್ತೇನೆ.
ಮೂಲಸೌಕರ್ಯ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ.
ವಿಷಯವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಮೂಲವನ್ನು ಸೂಚಿಸಲಾಗಿದೆ.
ಮೌಲ್ಯಗಳ ಗುಂಪನ್ನು ಈ ಮಾಡ್ಯೂಲ್‌ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ರವಾನಿಸಲಾಗುತ್ತದೆ.
ಮುಂದೆ, ಈ ಮಾಡ್ಯೂಲ್‌ನೊಳಗೆ, VPC ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ರಚಿಸಲು, ಅಥವಾ ಭದ್ರತಾ-ಗುಂಪನ್ನು ರಚಿಸಲು ಅಥವಾ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಕಂಟೈನರ್ ಸೇವಾ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳ ಗುಂಪನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ.
ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಎರಡು ವಿಧಗಳಿವೆ. ಈ ವರದಿಯಲ್ಲಿ ನಾನು ಗುಂಪು ಮಾಡಿದ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ದಸ್ತಾವೇಜನ್ನು ಬರೆಯಲಾಗಿಲ್ಲವಾದ್ದರಿಂದ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಮತ್ತು ಇದೀಗ ಟೆರಾಫಾರ್ಮ್‌ನಲ್ಲಿನ ದಸ್ತಾವೇಜನ್ನು ಸಾಕಷ್ಟು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ ಏಕೆಂದರೆ ಈ ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ ಎಂದು ಅದು ಹೇಳುತ್ತದೆ, ನೀವು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಆದರೆ ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು, ಅವುಗಳನ್ನು ಏಕೆ ಬಳಸುವುದು ಉತ್ತಮ ಎಂದು ಅವಳು ಹೇಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಜನರು ತಾವು ಬದುಕಲು ಸಾಧ್ಯವಾಗದಂತಹದನ್ನು ಬರೆಯುತ್ತಾರೆ.
ಮುಂದೆ ಈ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂದು ನೋಡೋಣ. ನಂತರ ಅವರನ್ನು ಹೇಗೆ ಕರೆಯುವುದು ಮತ್ತು ಕೋಡ್ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.
ಟೆರಾಫಾರ್ಮ್ ರಿಜಿಸ್ಟ್ರಿ -
ಸಲಹೆ #0 ಎಂದರೆ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬರೆಯದಿರುವುದು. ಈ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಈಗಾಗಲೇ ನಿಮಗಾಗಿ ಬರೆಯಲಾಗಿದೆ. ನಾನು ಹೇಳಿದಂತೆ, ಅವು ತೆರೆದ ಮೂಲಗಳಾಗಿವೆ, ಅವು ನಿಮ್ಮ ಯಾವುದೇ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಹೊಂದಿಲ್ಲ, ಅವು IP ವಿಳಾಸಗಳು, ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಇತ್ಯಾದಿಗಳಿಗೆ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾದ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಮಾಡ್ಯೂಲ್ ತುಂಬಾ ಮೃದುವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಈಗಾಗಲೇ ಬರೆಯಲಾಗಿದೆ. Amazon ನಿಂದ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಹಲವು ಮಾಡ್ಯೂಲ್‌ಗಳಿವೆ. ಸುಮಾರು 650. ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಉತ್ತಮ ಗುಣಮಟ್ಟದವುಗಳಾಗಿವೆ.
ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಯಾರಾದರೂ ನಿಮ್ಮ ಬಳಿಗೆ ಬಂದು ಹೇಳಿದರು, “ನಾನು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತೇನೆ. ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಚಿಸಿ ಇದರಿಂದ ನಾನು ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಬಹುದು." ವ್ಯಕ್ತಿಗೆ Amazon ಅಥವಾ Terraform ನ ಅನುಷ್ಠಾನದ ವಿವರಗಳು ತಿಳಿದಿಲ್ಲ. ಅವರು ಸರಳವಾಗಿ ಹೇಳುತ್ತಾರೆ: "ನಾನು MSSQL ಅನ್ನು ನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತೇನೆ." ಅಂದರೆ, ಅದು ನಮ್ಮ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಅಲ್ಲಿ ಎಂಜಿನ್ ಪ್ರಕಾರವನ್ನು ರವಾನಿಸುತ್ತದೆ ಮತ್ತು ಸಮಯ ವಲಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಮತ್ತು ಈ ಮಾಡ್ಯೂಲ್ನಲ್ಲಿ ನಾವು ಎರಡು ವಿಭಿನ್ನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ ಎಂದು ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತಿಳಿದಿರಬಾರದು: ಒಂದು MSSQL ಗೆ, ಎರಡನೆಯದು ಎಲ್ಲದಕ್ಕೂ, ಏಕೆಂದರೆ Terraform 0.11 ನಲ್ಲಿ ನೀವು ಸಮಯ ವಲಯ ಮೌಲ್ಯಗಳನ್ನು ಐಚ್ಛಿಕವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಮತ್ತು ಈ ಮಾಡ್ಯೂಲ್ನಿಂದ ನಿರ್ಗಮಿಸುವಾಗ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಸರಳವಾಗಿ ವಿಳಾಸವನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಯಾವ ಡೇಟಾಬೇಸ್‌ನಿಂದ, ಯಾವ ಸಂಪನ್ಮೂಲದಿಂದ ನಾವು ಇದನ್ನೆಲ್ಲ ಆಂತರಿಕವಾಗಿ ರಚಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದು ಅವನಿಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಇದು ಮರೆಮಾಚುವಿಕೆಯ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. ಮತ್ತು ಇದು ತೆರೆದ ಮೂಲದಲ್ಲಿ ಸಾರ್ವಜನಿಕವಾಗಿರುವ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಮಾತ್ರವಲ್ಲ, ನಿಮ್ಮ ಯೋಜನೆಗಳು ಮತ್ತು ತಂಡಗಳಲ್ಲಿ ನೀವು ಬರೆಯುವ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ.
ಇದು ಎರಡನೇ ವಾದವಾಗಿದೆ, ನೀವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ ಇದು ತುಂಬಾ ಮುಖ್ಯವಾಗಿದೆ. ನಿಮ್ಮ ಕಂಪನಿಗೆ ನಿಮ್ಮ ಎಲ್ಲಾ ಟೆರಾಫಾರ್ಮ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹಾಕುವ ರೆಪೊಸಿಟರಿಯನ್ನು ನೀವು ಹೊಂದಿದ್ದೀರಿ. ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಈ ಯೋಜನೆಯು ಒಂದು ಅಥವಾ ಎರಡು ಮೆಗಾಬೈಟ್‌ಗಳ ಗಾತ್ರಕ್ಕೆ ಬೆಳೆಯುವುದು ಸಾಮಾನ್ಯವಾಗಿದೆ. ಇದು ಚೆನ್ನಾಗಿದೆ.
ಆದರೆ ಟೆರಾಫಾರ್ಮ್ ಈ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೇಗೆ ಕರೆಯುತ್ತದೆ ಎಂಬುದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಲು ನೀವು ಮಾಡ್ಯೂಲ್‌ಗೆ ಕರೆ ಮಾಡಿದರೆ, Terraform ಮೊದಲು ಸಂಪೂರ್ಣ ರೆಪೊಸಿಟರಿಯನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ನಿರ್ದಿಷ್ಟ ಮಾಡ್ಯೂಲ್ ಇರುವ ಫೋಲ್ಡರ್‌ಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡುತ್ತದೆ. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ಪ್ರತಿ ಬಾರಿ ಒಂದು ಮೆಗಾಬೈಟ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತೀರಿ. ನೀವು 100 ಅಥವಾ 200 ಬಳಕೆದಾರರನ್ನು ನಿರ್ವಹಿಸಿದರೆ, ನೀವು 100 ಅಥವಾ 200 ಮೆಗಾಬೈಟ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತೀರಿ, ತದನಂತರ ಆ ಫೋಲ್ಡರ್‌ಗೆ ಹೋಗಿ. ಆದ್ದರಿಂದ ಸ್ವಾಭಾವಿಕವಾಗಿ ನೀವು "Terraform init" ಅನ್ನು ಒತ್ತಿದಾಗ ಪ್ರತಿ ಬಾರಿಯೂ ಒಂದು ಗುಂಪನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ.
ಈ ಸಮಸ್ಯೆಗೆ ಎರಡು ಪರಿಹಾರಗಳಿವೆ. ಮೊದಲನೆಯದು ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳನ್ನು ಬಳಸುವುದು. ಈ ರೀತಿಯಾಗಿ ನೀವು ಫೋಲ್ಡರ್ ಸ್ಥಳೀಯ (./) ಎಂದು ಕೋಡ್‌ನಲ್ಲಿ ಸೂಚಿಸುತ್ತೀರಿ. ಮತ್ತು ನೀವು ಏನನ್ನಾದರೂ ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು ಸ್ಥಳೀಯವಾಗಿ ಈ ರೆಪೊಸಿಟರಿಯ Git ಕ್ಲೋನ್ ಮಾಡಿ. ಈ ರೀತಿ ನೀವು ಒಮ್ಮೆ ಮಾಡಿ.
ಸಹಜವಾಗಿ, ಬಹಳಷ್ಟು ಅನಾನುಕೂಲತೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಇದು ಕೆಲವೊಮ್ಮೆ ಬದುಕಲು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಎರಡನೇ ಪರಿಹಾರ. ನೀವು ಬಹಳಷ್ಟು ಸಬ್‌ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ಕೆಲವು ರೀತಿಯ ಸ್ಥಾಪಿತ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ MBT ಯೋಜನೆ ಇದೆ, ಇದು ಮೊನೊರೆಪೊಸಿಟರಿಯಿಂದ ಹಲವಾರು ವಿಭಿನ್ನ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು S3 ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಬಹಳ ಒಳ್ಳೆಯ ಮಾರ್ಗವಾಗಿದೆ. ಹೀಗಾಗಿ, iam-user-1.0.0.zip ಫೈಲ್ ಕೇವಲ 1 Kb ತೂಗುತ್ತದೆ, ಏಕೆಂದರೆ ಈ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸುವ ಕೋಡ್ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಮತ್ತು ಇದು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಏನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ.
ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಇದು ಏಕೆ ಕೆಟ್ಟದು? ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಬಳಕೆದಾರರನ್ನು ಊಹಿಸುವುದು. ಬಳಕೆದಾರರು ವಿವಿಧ ಜನರು ಬಳಸಬಹುದಾದ ಪೂರೈಕೆದಾರರ ದೃಢೀಕರಣ ಆಯ್ಕೆಯಾಗಿದೆ ಎಂದು ಊಹಿಸಿ. ಉದಾಹರಣೆಗೆ, ನಾವೆಲ್ಲರೂ ಪಾತ್ರವನ್ನು ಸಂಯೋಜಿಸುತ್ತೇವೆ. ಇದರರ್ಥ ಟೆರ್ರಾಫಾರ್ಮ್ ಈ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ತದನಂತರ ಈ ಪಾತ್ರದೊಂದಿಗೆ ಅದು ಇತರ ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡುತ್ತದೆ.
ಮತ್ತು ದುಷ್ಟವೆಂದರೆ ವಾಸ್ಯಾ ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಮೆಜಾನ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಇಷ್ಟಪಟ್ಟರೆ, ಉದಾಹರಣೆಗೆ, ಡೀಫಾಲ್ಟ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ ಬಳಸಿ, ಮತ್ತು ಪೆಟ್ಯಾ ಅವರು ರಹಸ್ಯ ಸ್ಥಳದಲ್ಲಿ ಹೊಂದಿರುವ ಹಂಚಿದ ಕೀಲಿಯನ್ನು ಬಳಸಲು ಇಷ್ಟಪಟ್ಟರೆ, ನೀವು ಎರಡನ್ನೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಟೆರಾಫಾರ್ಮ್. ಮತ್ತು ಆದ್ದರಿಂದ ಅವರು ದುಃಖವನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ, ಮಾಡ್ಯೂಲ್ನಲ್ಲಿ ಈ ಬ್ಲಾಕ್ ಅನ್ನು ಸೂಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದನ್ನು ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಸೂಚಿಸಬೇಕು. ಅಂದರೆ, ನಾವು ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್, ಮೂಲಸೌಕರ್ಯ ಮಾಡ್ಯೂಲ್ ಮತ್ತು ಸಂಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಇದು ಎಲ್ಲೋ ಹೆಚ್ಚಿನದನ್ನು ಸೂಚಿಸಬೇಕು.
ಎರಡನೆಯ ದುಷ್ಟನು ಒದಗಿಸುವವನು. ಇಲ್ಲಿ ದುಷ್ಟವು ಅಷ್ಟು ಕ್ಷುಲ್ಲಕವಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ಕೋಡ್ ಅನ್ನು ಬರೆದರೆ ಮತ್ತು ಅದು ನಿಮಗಾಗಿ ಕೆಲಸ ಮಾಡಿದರೆ, ಅದು ಕೆಲಸ ಮಾಡಿದರೆ, ಅದನ್ನು ಏಕೆ ಬದಲಾಯಿಸಬೇಕು ಎಂದು ನೀವು ಯೋಚಿಸಬಹುದು.
ದುಷ್ಟತನವೆಂದರೆ, ಈ ಪೂರೈಕೆದಾರರನ್ನು ಯಾವಾಗ ಪ್ರಾರಂಭಿಸಲಾಗುವುದು ಎಂಬುದನ್ನು ನೀವು ಯಾವಾಗಲೂ ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ, ಮೊದಲನೆಯದಾಗಿ. ಮತ್ತು ಎರಡನೆಯದಾಗಿ, aws ec2 ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ನೀವು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ನಾವು ಈಗ ಲಿನಕ್ಸ್ ಅಥವಾ ವಿಂಡೋಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಆದ್ದರಿಂದ ನೀವು ವಿಭಿನ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂಗಳಲ್ಲಿ ಅಥವಾ ವಿಭಿನ್ನ ಬಳಕೆದಾರ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತಹದನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಅಧಿಕೃತ ದಾಖಲಾತಿಯಲ್ಲಿ ಸಹ ಸೂಚಿಸಲಾದ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಉದಾಹರಣೆಯೆಂದರೆ, ನೀವು aws_instance ಅನ್ನು ಬರೆದರೆ ಮತ್ತು ವಾದಗಳ ಗುಂಪನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ನೀವು ಅಲ್ಲಿ ಒದಗಿಸುವವರ "ಸ್ಥಳೀಯ-ಕಾರ್ಯನಿರ್ವಾಹಕ" ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ ಮತ್ತು ನಿಮ್ಮ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಚಲಾಯಿಸಿದರೆ ಅದರಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ- ಪ್ಲೇಬುಕ್.
ವಾಸ್ತವವಾಗಿ, ಹೌದು, ಅದರಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ. ಆದರೆ ಈ ಲೋಕಲ್-ಎಕ್ಸಿಕ್ ವಿಷಯ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ಅಕ್ಷರಶಃ ಶೀಘ್ರದಲ್ಲೇ ನೀವು ಅರಿತುಕೊಳ್ಳುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ, ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ.
ಮತ್ತು ನೀವು ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸಿದಾಗ ಮತ್ತು ನೀವು ಒಂದು ನಿದರ್ಶನದಿಂದ ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಗುಂಪನ್ನು ರಚಿಸಲು ಬಯಸಿದರೆ, ನಂತರ ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ "ಪ್ರೊವಿಶನರ್" ಎಂಬ ಪರಿಕಲ್ಪನೆಯಿಲ್ಲ. "ಬಳಕೆದಾರ ಡೇಟಾ" ಎಂಬ ಪರಿಕಲ್ಪನೆ ಇದೆ.
ಆದ್ದರಿಂದ, ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವಾಗಿದೆ. ಮತ್ತು ನಿದರ್ಶನವನ್ನು ಆನ್ ಮಾಡಿದಾಗ ಅಥವಾ ಅದೇ ಬಳಕೆದಾರ ಡೇಟಾದಲ್ಲಿ, ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಗುಂಪು ಈ ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸುವಾಗ ಅದನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.
ನೀವು ಇನ್ನೂ ಪ್ರೊವಿಶನರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಬಯಸಿದರೆ, ಏಕೆಂದರೆ ಅದು ಅಂಟಿಕೊಳ್ಳುವ ಅಂಶವಾಗಿದೆ, ಒಂದು ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿದಾಗ, ಆ ಕ್ಷಣದಲ್ಲಿ ನೀವು ನಿಮ್ಮ ಪ್ರಾವಿಶನರ್, ನಿಮ್ಮ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ಅಂತಹ ಸಂದರ್ಭಗಳು ಬಹಳಷ್ಟು ಇವೆ.
ಮತ್ತು ಇದಕ್ಕಾಗಿ ಅತ್ಯಂತ ಸರಿಯಾದ ಸಂಪನ್ಮೂಲವನ್ನು null_resource ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. Null_resource ಒಂದು ನಕಲಿ ಸಂಪನ್ಮೂಲವಾಗಿದ್ದು, ಅದು ನಿಜವಾಗಿ ಎಂದಿಗೂ ರಚಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಇದು ಯಾವುದನ್ನೂ ಮುಟ್ಟುವುದಿಲ್ಲ, API ಇಲ್ಲ, ಆಟೋಸ್ಕೇಲಿಂಗ್ ಇಲ್ಲ. ಆದರೆ ಆಜ್ಞೆಯನ್ನು ಯಾವಾಗ ಚಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಲು ಇದು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಲಾಗುತ್ತದೆ.
ಲಿಂಕ್
ಹಲವಾರು ಚಿಹ್ನೆಗಳು ಇವೆ. ನಾನು ಎಲ್ಲಾ ಚಿಹ್ನೆಗಳಿಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೋಗುವುದಿಲ್ಲ. ಇದರ ಬಗ್ಗೆ ಒಂದು ಲೇಖನವಿದೆ. ಆದರೆ ನೀವು ಟೆರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದರೆ ಅಥವಾ ಇತರ ಜನರ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬಳಸಿದ್ದರೆ, ಓಪನ್ ಸೋರ್ಸ್‌ನಲ್ಲಿರುವ ಹೆಚ್ಚಿನ ಕೋಡ್‌ಗಳಂತೆ ಅನೇಕ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಜನರು ತಮ್ಮ ಸ್ವಂತ ಅಗತ್ಯಗಳಿಗಾಗಿ ಬರೆಯುತ್ತಾರೆ ಎಂದು ನೀವು ಆಗಾಗ್ಗೆ ಗಮನಿಸಿದ್ದೀರಿ. ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅದನ್ನು ಬರೆದು ತನ್ನ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದನು. ನಾನು ಅದನ್ನು GitHub ನಲ್ಲಿ ಅಂಟಿಸಿದೆ, ಅದನ್ನು ಬದುಕಲು ಬಿಡಿ. ಅದು ಬದುಕುತ್ತದೆ, ಆದರೆ ಅಲ್ಲಿ ಯಾವುದೇ ದಾಖಲಾತಿ ಮತ್ತು ಉದಾಹರಣೆಗಳಿಲ್ಲದಿದ್ದರೆ, ಯಾರೂ ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಮತ್ತು ಅದರ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಪರಿಹರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಯಾವುದೇ ಕ್ರಿಯಾತ್ಮಕತೆ ಇಲ್ಲದಿದ್ದರೆ, ಯಾರೂ ಅದನ್ನು ಬಳಸುವುದಿಲ್ಲ. ಬಳಕೆದಾರರನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ.
ನೀವು ಏನನ್ನಾದರೂ ಬರೆಯಲು ಬಯಸಿದರೆ ಜನರು ಅದನ್ನು ಬಳಸುತ್ತಾರೆ, ನಂತರ ನಾನು ಈ ಚಿಹ್ನೆಗಳನ್ನು ಅನುಸರಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಇವುಗಳು:
- ದಾಖಲೆ ಮತ್ತು ಉದಾಹರಣೆಗಳು.
- ಪೂರ್ಣ ಕ್ರಿಯಾತ್ಮಕತೆ.
- ಸಮಂಜಸವಾದ ಡೀಫಾಲ್ಟ್‌ಗಳು.
- ಕ್ಲೀನ್ ಕೋಡ್.
- ಪರೀಕ್ಷೆಗಳು.
ಪರೀಕ್ಷೆಗಳು ವಿಭಿನ್ನ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ ಏಕೆಂದರೆ ಅವರು ಬರೆಯಲು ಸಾಕಷ್ಟು ಕಷ್ಟ. ನಾನು ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಉದಾಹರಣೆಗಳಲ್ಲಿ ಹೆಚ್ಚು ನಂಬುತ್ತೇನೆ.
ಆದ್ದರಿಂದ, ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೇಗೆ ಬರೆಯುವುದು ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ಎರಡು ವಾದಗಳಿವೆ. ಮೊದಲನೆಯದು, ಇದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದದ್ದು, ನಿಮಗೆ ಸಾಧ್ಯವಾದರೆ ಬರೆಯುವುದು ಅಲ್ಲ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಮುಂದೆ ಕೆಲವು ಜನರು ಈಗಾಗಲೇ ಈ ಕಾರ್ಯಗಳನ್ನು ಮಾಡಿದ್ದಾರೆ. ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ನೀವು ಇನ್ನೂ ನಿರ್ಧರಿಸಿದರೆ, ನಂತರ ಮಾಡ್ಯೂಲ್ಗಳು ಮತ್ತು ಪೂರೈಕೆದಾರರಲ್ಲಿ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸದಿರಲು ಪ್ರಯತ್ನಿಸಿ.
ಇದು ದಸ್ತಾವೇಜನ್ನು ಬೂದು ಭಾಗವಾಗಿದೆ. ನೀವು ಈಗ ಯೋಚಿಸುತ್ತಿರಬಹುದು: “ಏನೋ ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಮನವರಿಕೆಯಾಗಿಲ್ಲ." ಆದರೆ ಆರು ತಿಂಗಳಲ್ಲಿ ನೋಡೋಣ.
ಈಗ ಈ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಹೇಗೆ ಕರೆಯುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ.
ನಮ್ಮ ಕೋಡ್ ಕಾಲಾನಂತರದಲ್ಲಿ ಬೆಳೆಯುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಇನ್ನು ಮುಂದೆ ಒಂದು ಫೈಲ್ ಹೊಂದಿಲ್ಲ, ನಾವು ಈಗಾಗಲೇ 20 ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವೆಲ್ಲವೂ ಒಂದೇ ಫೋಲ್ಡರ್‌ನಲ್ಲಿವೆ. ಅಥವಾ ಬಹುಶಃ ಐದು ಫೋಲ್ಡರ್‌ಗಳು. ಬಹುಶಃ ನಾವು ಅವುಗಳನ್ನು ಹೇಗಾದರೂ ಪ್ರದೇಶದಿಂದ, ಕೆಲವು ಘಟಕಗಳಿಂದ ಒಡೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ. ಈಗ ನಾವು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ನ ಕೆಲವು ಮೂಲಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂದರೆ, ನಾವು ನೆಟ್ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ ನಾವು ಏನು ಮಾಡಬೇಕು, ನಮ್ಮ ಉಳಿದ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ನಾವು ಏನು ಮಾಡಬೇಕು, ಈ ಅವಲಂಬನೆಗಳನ್ನು ಹೇಗೆ ಉಂಟುಮಾಡುವುದು ಇತ್ಯಾದಿಗಳನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಎರಡು ವಿಪರೀತಗಳಿವೆ. ಮೊದಲ ವಿಪರೀತ ಎಲ್ಲವೂ ಒಂದರಲ್ಲಿದೆ. ನಾವು ಒಂದು ಮಾಸ್ಟರ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸದ್ಯಕ್ಕೆ, ಟೆರಾಫಾರ್ಮ್ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಇದು ಅಧಿಕೃತ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ.
ಆದರೆ ಈಗ ಅದನ್ನು ಅಸಮ್ಮತಿ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ಬರೆಯಲಾಗಿದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಟೆರಾಫಾರ್ಮ್ ಸಮುದಾಯವು ಇದು ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸದಿಂದ ದೂರವಿದೆ ಎಂದು ಅರಿತುಕೊಂಡಿತು, ಏಕೆಂದರೆ ಜನರು ಯೋಜನೆಯನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ಮತ್ತು ಸಮಸ್ಯೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಿದಾಗ. ನಾವು "ಟೆರ್ರಾಫಾರ್ಮ್ ಯೋಜನೆ" ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ ಸಂದರ್ಭಗಳಿವೆ ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ಸ್ಥಿತಿಗಳನ್ನು ನವೀಕರಿಸುವವರೆಗೆ, ಸಾಕಷ್ಟು ಸಮಯ ಹಾದುಹೋಗಬಹುದು.
ಬಹಳಷ್ಟು ಸಮಯ, ಉದಾಹರಣೆಗೆ, 5 ನಿಮಿಷಗಳು. ಕೆಲವರಿಗೆ ಇದು ಬಹಳ ಸಮಯ. ಇದು 15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡ ಪ್ರಕರಣಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. AWS API ಪ್ರತಿ ಸಂಪನ್ಮೂಲದ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು 15 ನಿಮಿಷಗಳನ್ನು ಕಳೆದಿದೆ. ಇದು ಬಹಳ ದೊಡ್ಡ ಪ್ರದೇಶವಾಗಿದೆ.
ಮತ್ತು, ಸ್ವಾಭಾವಿಕವಾಗಿ, ನೀವು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಬಯಸಿದಾಗ ಸಂಬಂಧಿತ ಸಮಸ್ಯೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ನಂತರ ನೀವು 15 ನಿಮಿಷ ಕಾಯಿರಿ ಮತ್ತು ಇದು ನಿಮಗೆ ಕೆಲವು ಬದಲಾವಣೆಗಳ ಕ್ಯಾನ್ವಾಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ಉಗುಳಿದ್ದೀರಿ, "ಹೌದು" ಎಂದು ಬರೆದಿದ್ದೀರಿ ಮತ್ತು ಏನೋ ತಪ್ಪಾಗಿದೆ. ಇದು ಬಹಳ ನೈಜ ಉದಾಹರಣೆಯಾಗಿದೆ. ಟೆರಾಫಾರ್ಮ್ ನಿಮ್ಮನ್ನು ಸಮಸ್ಯೆಗಳಿಂದ ರಕ್ಷಿಸಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ. ಅಂದರೆ, ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಬರೆಯಿರಿ. ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ - ನಿಮ್ಮ ಸಮಸ್ಯೆಗಳು. Terraform 0.11 ನಿಮಗೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿಲ್ಲ. 0.12 ರಲ್ಲಿ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಸ್ಥಳಗಳಿವೆ, ಅದು ನಿಮಗೆ ಹೇಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ: "ವಾಸ್ಯಾ, ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಇದು ಬೇಕು, ನಿಮ್ಮ ಪ್ರಜ್ಞೆಗೆ ಬರಬಹುದೇ?"
ಎರಡನೆಯ ಮಾರ್ಗವೆಂದರೆ ಈ ಪ್ರದೇಶವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಅಂದರೆ, ಒಂದು ಸ್ಥಳದಿಂದ ಕರೆಗಳನ್ನು ಮತ್ತೊಂದು ಸ್ಥಳದಿಂದ ಕಡಿಮೆ ಸಂಪರ್ಕಿಸಬಹುದು.
ಒಂದೇ ಸಮಸ್ಯೆ ಎಂದರೆ ನೀವು ಹೆಚ್ಚಿನ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ, ಅಂದರೆ ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಫೈಲ್‌ಗಳಲ್ಲಿ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ವಿವರಿಸಬೇಕು ಮತ್ತು ಇದನ್ನು ನವೀಕರಿಸಬೇಕು. ಕೆಲವರಿಗೆ ಇದು ಇಷ್ಟವಾಗುವುದಿಲ್ಲ. ಇದು ನನಗೆ ಸಹಜ. ಮತ್ತು ಕೆಲವರು ಯೋಚಿಸುತ್ತಾರೆ: "ಇದನ್ನು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಏಕೆ ಬರೆಯಿರಿ, ನಾನು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇಡುತ್ತೇನೆ." ಇದು ಸಾಧ್ಯ, ಆದರೆ ಇದು ಎರಡನೇ ವಿಪರೀತವಾಗಿದೆ.
ಇದೆಲ್ಲವೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ವಾಸಿಸುವವರು ಯಾರು? ಒಂದು, ಎರಡು, ಮೂರು ಜನರು, ಅಂದರೆ, ಯಾರಾದರೂ ಅದನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ.
ಮತ್ತು ಒಂದು ನಿರ್ದಿಷ್ಟ ಘಟಕ, ಒಂದು ಬ್ಲಾಕ್ ಅಥವಾ ಒಂದು ಮೂಲಸೌಕರ್ಯ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಯಾರು ಕರೆಯುತ್ತಾರೆ? ಐದರಿಂದ ಏಳು ಜನರು. ಇದು ತಂಪಾಗಿದೆ.
ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಉತ್ತರವು ಎಲ್ಲೋ ಮಧ್ಯದಲ್ಲಿದೆ. ಯೋಜನೆಯು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಯಾವುದೇ ಪರಿಹಾರವು ಸೂಕ್ತವಲ್ಲದ ಪರಿಸ್ಥಿತಿಯನ್ನು ನೀವು ಹೆಚ್ಚಾಗಿ ಹೊಂದಿರುತ್ತೀರಿ ಮತ್ತು ಎಲ್ಲವೂ ಅಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಮಿಶ್ರಣದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ. ಎರಡರಲ್ಲೂ ಪ್ರಯೋಜನಗಳಿವೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಇದರಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ.
ಸ್ಟಾಕ್ VPC ಯಲ್ಲಿ ಏನಾದರೂ ಬದಲಾಗಿದ್ದರೆ ಮತ್ತು ನೀವು EC2 ಗೆ ಈ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಬಯಸಿದರೆ, ಅಂದರೆ ನೀವು ಹೊಸ ಸಬ್ನೆಟ್ ಹೊಂದಿರುವ ಕಾರಣ ನೀವು ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಗುಂಪನ್ನು ನವೀಕರಿಸಲು ಬಯಸಿದರೆ, ನಾನು ಈ ರೀತಿಯ ಅವಲಂಬನೆ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಎಂದು ಕರೆಯುತ್ತೇನೆ. ಕೆಲವು ಪರಿಹಾರಗಳಿವೆ: ಯಾರು ಏನು ಬಳಸುತ್ತಾರೆ?
ಯಾವ ಪರಿಹಾರಗಳಿವೆ ಎಂದು ನಾನು ಸೂಚಿಸಬಲ್ಲೆ. ಮ್ಯಾಜಿಕ್ ಮಾಡಲು ನೀವು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಬಹುದು ಅಥವಾ ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ನೀವು ಮೇಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಮತ್ತು ಅಲ್ಲಿ ಏನಾದರೂ ಬದಲಾಗಿದೆಯೇ ಎಂದು ನೋಡಿ, ನೀವು ಅದನ್ನು ಇಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬಹುದು.
ಈ ನಿರ್ಧಾರವನ್ನು ನೀವು ಹೇಗೆ ಇಷ್ಟಪಡುತ್ತೀರಿ? ಇದು ತಂಪಾದ ಪರಿಹಾರ ಎಂದು ಯಾರಾದರೂ ನಂಬುತ್ತಾರೆಯೇ? ನಾನು ಒಂದು ಸ್ಮೈಲ್ ಅನ್ನು ನೋಡುತ್ತೇನೆ, ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮಾನಗಳು ಒಳಗೆ ಬಂದಿವೆ.
ಸಹಜವಾಗಿ, ಇದನ್ನು ಮನೆಯಲ್ಲಿ ಪ್ರಯತ್ನಿಸಬೇಡಿ. ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಎಂದಿಗೂ ಟೆರ್ರಾಫಾರ್ಮ್‌ನಿಂದ ಚಲಾಯಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ.
ಒಂದು ವರದಿಯಲ್ಲಿ ಅವರು ನನಗೆ ಹೇಳಿದರು: "ಇಲ್ಲ, ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ." ಇದು ಕೆಲಸ ಮಾಡಬಾರದು ಎಂಬುದು ಪಾಯಿಂಟ್. ನೀವು ಟೆರಾಫಾರ್ಮ್‌ನಿಂದ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ನಂತರ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಅದು ತುಂಬಾ ಪ್ರಭಾವಶಾಲಿಯಾಗಿ ಕಂಡುಬಂದರೂ, ನೀವು ಅದನ್ನು ಮಾಡಬಾರದು. ಟೆರಾಫಾರ್ಮ್ ಯಾವಾಗಲೂ ಸುಲಭವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಕು.
ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಏನಾದರೂ ಬದಲಾವಣೆಯಾದಾಗ ನಿಮಗೆ ಕರೆ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಅಗತ್ಯವಿದ್ದರೆ, ಆಗ Terragrunt ಇದೆ.
ಟೆರಾಗ್ರಂಟ್ ಒಂದು ಉಪಯುಕ್ತತೆಯಾಗಿದೆ, ಇದು ಟೆರಾಫಾರ್ಮ್‌ಗೆ ಆಡ್-ಆನ್ ಆಗಿದೆ, ಇದು ಮೂಲಸೌಕರ್ಯ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಕರೆಗಳನ್ನು ಸಂಘಟಿಸಲು ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ವಿಶಿಷ್ಟವಾದ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ನೀವು ಕರೆ ಮಾಡಲು ಬಯಸುವ ನಿರ್ದಿಷ್ಟ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ.
ಮಾಡ್ಯೂಲ್ ಯಾವ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆ?
ಮತ್ತು ಈ ಮಾಡ್ಯೂಲ್ ಯಾವ ವಾದಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಟೆರಾಗ್ರಂಟ್ ಬಗ್ಗೆ ತಿಳಿಯುವುದು ಇಷ್ಟೇ.
ದಾಖಲಾತಿ ಇದೆ, ಮತ್ತು GitHub ನಲ್ಲಿ 1 ನಕ್ಷತ್ರಗಳಿವೆ. ಆದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದದ್ದು ಇದು. ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವ ಕಂಪನಿಗಳಲ್ಲಿ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ತುಂಬಾ ಸುಲಭ.
ಆದ್ದರಿಂದ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಟೆರಾಗ್ರಂಟ್ ಆಗಿದೆ. ಇತರ ಆಯ್ಕೆಗಳಿವೆ.
ಕೋಡ್ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಈಗ ಮಾತನಾಡೋಣ.
ನಿಮ್ಮ ಕೋಡ್‌ಗೆ ನೀವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಬೇಕಾದರೆ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಸುಲಭವಾಗಿದೆ. ನೀವು ಹೊಸ ಸಂಪನ್ಮೂಲವನ್ನು ಬರೆಯುತ್ತಿದ್ದೀರಿ, ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ.
ನೀವು ಮುಂಚಿತವಾಗಿ ರಚಿಸಿದ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು AWS ಖಾತೆಯನ್ನು ತೆರೆದ ನಂತರ ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಲು ಬಯಸಿದ ನಂತರ ನೀವು Terraform ಕುರಿತು ಕಲಿತಿದ್ದೀರಿ, ನಂತರ ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ವಿಸ್ತರಿಸುವುದು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪನ್ಮೂಲಗಳ ಬಳಕೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ಮತ್ತು ಬ್ಲಾಕ್ ಸಂಪನ್ಮೂಲವನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸ ಸಂಪನ್ಮೂಲಗಳ ರಚನೆಯನ್ನು ಬೆಂಬಲಿಸಿದರು.
ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನಾವು ಬಳಸಿದ್ದನ್ನು ಅವಲಂಬಿಸಿ ಔಟ್ಪುಟ್ ಐಡಿಯನ್ನು ಯಾವಾಗಲೂ ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ.
ಟೆರಾಫಾರ್ಮ್ 0.11 ನಲ್ಲಿನ ಎರಡನೇ ಅತ್ಯಂತ ಮಹತ್ವದ ಸಮಸ್ಯೆಯು ಪಟ್ಟಿಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.
ನಾವು ಅಂತಹ ಬಳಕೆದಾರರ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದರೆ ತೊಂದರೆಯಾಗಿದೆ.
ಮತ್ತು ಬ್ಲಾಕ್ ಸಂಪನ್ಮೂಲವನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿದಾಗ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ನಡೆಯುತ್ತದೆ. ನಾವು ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ. ತದನಂತರ, ಉದಾಹರಣೆಗೆ, ಮಧ್ಯದಲ್ಲಿರುವ user3 ಅನ್ನು ಇಲ್ಲಿಂದ ತೆಗೆದುಹಾಕಬೇಕು, ನಂತರ ಅವನ ನಂತರ ರಚಿಸಲಾದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಸೂಚ್ಯಂಕವು ಬದಲಾಗುತ್ತದೆ.
ರಾಜ್ಯ ಪರಿಸರದಲ್ಲಿ ಪಟ್ಟಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು. ರಾಜ್ಯ ಪರಿಸರ ಎಂದರೇನು? ಈ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿದಾಗ ಹೊಸ ಮೌಲ್ಯವನ್ನು ರಚಿಸುವ ಪರಿಸ್ಥಿತಿ ಇದು. ಉದಾಹರಣೆಗೆ, AWS ಪ್ರವೇಶ ಕೀ ಅಥವಾ AWS ಸೀಕ್ರೆಟ್ ಕೀ, ಅಂದರೆ ನಾವು ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿದಾಗ, ನಾವು ಹೊಸ ಪ್ರವೇಶ ಅಥವಾ ರಹಸ್ಯ ಕೀಲಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಬಳಕೆದಾರರನ್ನು ಅಳಿಸಿದಾಗಲೆಲ್ಲಾ, ಈ ಬಳಕೆದಾರರು ಹೊಸ ಕೀಲಿಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಆದರೆ ಇದು ಫೆಂಗ್ ಶೂಯಿ ಅಲ್ಲ, ಏಕೆಂದರೆ ಯಾರಾದರೂ ತಂಡವನ್ನು ತೊರೆದಾಗಲೆಲ್ಲಾ ನಾವು ಅವನಿಗೆ ಹೊಸ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಿದರೆ ಬಳಕೆದಾರರು ನಮ್ಮೊಂದಿಗೆ ಸ್ನೇಹಿತರಾಗಲು ಬಯಸುವುದಿಲ್ಲ.
ಇದು ಪರಿಹಾರವಾಗಿದೆ. ಇದು Jsonnet ನಲ್ಲಿ ಬರೆದ ಕೋಡ್ ಆಗಿದೆ. Jsonnet Google ನಿಂದ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಭಾಷೆಯಾಗಿದೆ.
ಈ ಆಜ್ಞೆಯು ಈ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಔಟ್ಪುಟ್ ಆಗಿ ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್‌ಗೆ ಅನುಗುಣವಾಗಿ ಮಾಡಲಾದ json ಫೈಲ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
ಟೆಂಪ್ಲೇಟ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ಟೆರ್ರಾಫಾರ್ಮ್ ನಿಮಗೆ HCL ಮತ್ತು Json ಎರಡರೊಂದಿಗೂ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು Json ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಅದನ್ನು Terraform ಗೆ ಸ್ಲಿಪ್ ಮಾಡಬಹುದು. .tf.json ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ.
ತದನಂತರ ನಾವು ಎಂದಿನಂತೆ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ: ಟೆರಾಫಾರ್ಮ್ ಇನಿಟ್, ಟೆರಮಾರ್ಮ್ ಅನ್ವಯಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಎರಡು ಬಳಕೆದಾರರನ್ನು ರಚಿಸುತ್ತೇವೆ.
ಈಗ ಯಾರಾದರೂ ತಂಡವನ್ನು ತೊರೆದರೆ ನಾವು ಹೆದರುವುದಿಲ್ಲ. ನಾವು ಕೇವಲ json ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡುತ್ತೇವೆ. ವಾಸ್ಯಾ ಪುಪ್ಕಿನ್ ತೊರೆದರು, ಪೆಟ್ಯಾ ಪಯಾಟೊಚ್ಕಿನ್ ಇದ್ದರು. ಪೆಟ್ಯಾ ಪಯಾಟೊಚ್ಕಿನ್ ಹೊಸ ಕೀಲಿಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.
ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಇತರ ಪರಿಕರಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವುದು ನಿಜವಾಗಿಯೂ ಟೆರಾಫಾರ್ಮ್‌ನ ಕೆಲಸವಲ್ಲ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುವ ವೇದಿಕೆಯಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ. ಮತ್ತು ನಂತರ ಬರುವ ಎಲ್ಲವೂ ಟೆರಾಫಾರ್ಮ್‌ನ ಕಾಳಜಿಯಲ್ಲ. ಮತ್ತು ಅಲ್ಲಿ ಅದನ್ನು ನೇಯ್ಗೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಅನ್ಸಿಬಲ್ ಇದೆ, ಅದು ನಿಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತದೆ.
ಆದರೆ ನಾವು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ವಿಸ್ತರಿಸಲು ಮತ್ತು ಏನನ್ನಾದರೂ ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ ಕೆಲವು ಆಜ್ಞೆಯನ್ನು ಕರೆಯಲು ಬಯಸಿದಾಗ ಸಂದರ್ಭಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.
ಮೊದಲ ದಾರಿ. ನಾವು ಈ ಆಜ್ಞೆಯನ್ನು ಬರೆಯುವ ಔಟ್ಪುಟ್ ಅನ್ನು ನಾವು ರಚಿಸುತ್ತೇವೆ.
ತದನಂತರ ನಾವು ಶೆಲ್ ಟೆರಾಫಾರ್ಮ್ ಔಟ್‌ಪುಟ್‌ನಿಂದ ಈ ಆಜ್ಞೆಯನ್ನು ಕರೆಯುತ್ತೇವೆ ಮತ್ತು ನಮಗೆ ಬೇಕಾದ ಮೌಲ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ. ಹೀಗಾಗಿ, ಆಜ್ಞೆಯನ್ನು ಎಲ್ಲಾ ಬದಲಿ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇದು ತುಂಬಾ ಆರಾಮದಾಯಕವಾಗಿದೆ.
ಎರಡನೇ ದಾರಿ. ಇದು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಅವಲಂಬಿಸಿ ಶೂನ್ಯ_ಸಂಪನ್ಮೂಲದ ಬಳಕೆಯಾಗಿದೆ. ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳ ಐಡಿ ಬದಲಾದ ತಕ್ಷಣ ನಾವು ಅದೇ ಲೋಕಲ್-ಎಕ್ಸ್‌ಗೆ ಕರೆ ಮಾಡಬಹುದು.
ನೈಸರ್ಗಿಕವಾಗಿ, ಇದು ಎಲ್ಲಾ ಕಾಗದದ ಮೇಲೆ ಮೃದುವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಅಮೆಜಾನ್, ಎಲ್ಲಾ ಇತರ ಸಾರ್ವಜನಿಕ ಪೂರೈಕೆದಾರರಂತೆ, ತನ್ನದೇ ಆದ ಅಂಚಿನ ಪ್ರಕರಣಗಳನ್ನು ಹೊಂದಿದೆ.
ಸಾಮಾನ್ಯ ಅಂಚಿನ ಪ್ರಕರಣವೆಂದರೆ ನೀವು AWS ಖಾತೆಯನ್ನು ತೆರೆದಾಗ, ನೀವು ಯಾವ ಪ್ರದೇಶಗಳನ್ನು ಬಳಸುತ್ತೀರಿ ಎಂಬುದು ಮುಖ್ಯವಾಗುತ್ತದೆ; ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಅಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆಯೇ; ಬಹುಶಃ ನೀವು ಅದನ್ನು ಡಿಸೆಂಬರ್ 2013 ರ ನಂತರ ತೆರೆದಿರಬಹುದು; ಬಹುಶಃ ನೀವು VPC ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ. ಹಲವು ನಿರ್ಬಂಧಗಳಿವೆ. ಮತ್ತು ಅಮೆಜಾನ್ ಅವುಗಳನ್ನು ದಸ್ತಾವೇಜನ್ನು ಉದ್ದಕ್ಕೂ ಹರಡಿತು.
ತಪ್ಪಿಸಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುವ ಕೆಲವು ವಿಷಯಗಳಿವೆ.
ಪ್ರಾರಂಭಿಸಲು, Terraform ಯೋಜನೆ ಅಥವಾ Terraform CLI ಒಳಗೆ ಎಲ್ಲಾ ರಹಸ್ಯವಲ್ಲದ ವಾದಗಳನ್ನು ತಪ್ಪಿಸಿ. ಇದೆಲ್ಲವನ್ನೂ tfvars ಫೈಲ್‌ಗೆ ಅಥವಾ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗೆ ಹಾಕಬಹುದು.
ಆದರೆ ನೀವು ಈ ಸಂಪೂರ್ಣ ಮ್ಯಾಜಿಕ್ ಆಜ್ಞೆಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ. ಟೆರಾಫಾರ್ಮ್ ಯೋಜನೆ - var ಮತ್ತು ನಾವು ಹೋಗುತ್ತೇವೆ. ಮೊದಲ ವೇರಿಯೇಬಲ್ var, ಎರಡನೇ ವೇರಿಯೇಬಲ್ var, ಮೂರನೇ, ನಾಲ್ಕನೇ. ನಾನು ಹೆಚ್ಚಾಗಿ ಬಳಸುವ ಕೋಡ್‌ನಂತೆ ಮೂಲಭೂತ ಸೌಕರ್ಯದ ಪ್ರಮುಖ ತತ್ವವೆಂದರೆ ಕೋಡ್ ಅನ್ನು ನೋಡುವ ಮೂಲಕ, ಅಲ್ಲಿ ಏನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿ ಮತ್ತು ಯಾವ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ನಾನು ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು. ಹಾಗಾಗಿ ನಾನು ದಸ್ತಾವೇಜನ್ನು ಓದಬೇಕಾಗಿಲ್ಲ ಅಥವಾ ವಾಸ್ಯಾ ಅವರು ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ಯಾವ ನಿಯತಾಂಕಗಳನ್ನು ಬಳಸಿದರು ಎಂದು ಕೇಳಬೇಕಾಗಿಲ್ಲ. ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಸರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ tfvars ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ತೆರೆಯಬೇಕಾಗಿದೆ ಮತ್ತು ಅಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ನೋಡಿ.
ಅಲ್ಲದೆ, ವ್ಯಾಪ್ತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಗುರಿ ವಾದಗಳನ್ನು ಬಳಸಬೇಡಿ. ಇದಕ್ಕಾಗಿ ಸಣ್ಣ ಮೂಲಸೌಕರ್ಯ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬಳಸುವುದು ತುಂಬಾ ಸುಲಭ.
ಅಲ್ಲದೆ, ಸಮಾನಾಂತರತೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಮತ್ತು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು 150 ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನಾನು ಡೀಫಾಲ್ಟ್ 10 ರಿಂದ 100 ಗೆ ಅಮೆಜಾನ್ ಸಮಾನಾಂತರತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಬಯಸಿದರೆ, ಆಗ ಹೆಚ್ಚಾಗಿ ಏನಾದರೂ ತಪ್ಪಾಗುತ್ತದೆ. ಅಥವಾ ಈಗ ಅದು ಚೆನ್ನಾಗಿ ಹೋಗಬಹುದು, ಆದರೆ ನೀವು ಹೆಚ್ಚು ಕರೆಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು Amazon ಹೇಳಿದಾಗ, ನೀವು ತೊಂದರೆಗೆ ಒಳಗಾಗುತ್ತೀರಿ.
ಟೆರ್ರಾಫಾರ್ಮ್ ಈ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ಬಹುತೇಕ ಏನನ್ನೂ ಸಾಧಿಸುವುದಿಲ್ಲ. AWS API ಒಳಗೆ ಅಥವಾ Terraform ಪೂರೈಕೆದಾರರೊಳಗೆ ನೀವು ಕೆಲವು ದೋಷಗಳ ಮೇಲೆ ಎಡವಿ ಬಿದ್ದರೆ ಸಮಾನಾಂತರತೆ=1 ಅನ್ನು ಬಳಸುವುದು ಒಂದು ಪ್ರಮುಖ ವಿಷಯವಾಗಿದೆ. ತದನಂತರ ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗಿದೆ: ಸಮಾನಾಂತರತೆ=1 ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಒಂದು ಕರೆಯನ್ನು ಮುಗಿಸುವವರೆಗೆ ಕಾಯಿರಿ, ನಂತರ ಎರಡನೆಯದು, ನಂತರ ಮೂರನೆಯದು. ಅವನು ಅವುಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.
ಜನರು ಆಗಾಗ್ಗೆ ನನ್ನನ್ನು ಕೇಳುತ್ತಾರೆ, "ಟೆರಾಫಾರ್ಮ್ ಕಾರ್ಯಕ್ಷೇತ್ರಗಳು ಕೆಟ್ಟವು ಎಂದು ನಾನು ಏಕೆ ಭಾವಿಸುತ್ತೇನೆ?" ಮೂಲಸೌಕರ್ಯದ ತತ್ವವು ಕೋಡ್‌ನಂತೆ ಯಾವ ಮೂಲಸೌಕರ್ಯವನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ನೋಡುವುದು ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ.
ಕಾರ್ಯಸ್ಥಳಗಳನ್ನು ಬಳಕೆದಾರರಿಂದ ರಚಿಸಲಾಗಿಲ್ಲ. ಟೆರಾಫಾರ್ಮ್ ವರ್ಕ್‌ಸ್ಪೇಸ್ ಇಲ್ಲದೆ ನಾವು ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಬಳಕೆದಾರರು ಗಿಟ್‌ಹಬ್ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಬರೆದಿದ್ದಾರೆ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ. ಇಲ್ಲ ಈ ರೀತಿ ಅಲ್ಲ. ಟೆರಾಫಾರ್ಮ್ ಎಂಟರ್‌ಪ್ರೈಸ್ ಒಂದು ವಾಣಿಜ್ಯ ಪರಿಹಾರವಾಗಿದೆ. HashiCorp ನಿಂದ Terraform ನಮಗೆ ಕಾರ್ಯಕ್ಷೇತ್ರಗಳ ಅಗತ್ಯವಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಸಲ್ಲಿಸಿದ್ದೇವೆ. ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಹಾಕಲು ನನಗೆ ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ನಂತರ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಫೈಲ್‌ಗಳು ಇರುತ್ತವೆ, ಆದರೆ ಅದು ಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ.
ಕೋಡ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ? ವಾಸ್ತವವಾಗಿ, ಪಟ್ಟಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಮಾತ್ರ ನೋವು. ಮತ್ತು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಸುಲಭವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಿ. ಇದು ನಿಮಗೆ ಎಲ್ಲವನ್ನೂ ಉತ್ತಮವಾಗಿ ಮಾಡುವ ವಿಷಯವಲ್ಲ. ಅಲ್ಲಿ ದಾಖಲಾತಿಯಲ್ಲಿ ಬರೆದಿರುವ ಎಲ್ಲವನ್ನೂ ತಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ.
ವರದಿಯ ವಿಷಯವನ್ನು "ಭವಿಷ್ಯಕ್ಕಾಗಿ" ಬರೆಯಲಾಗಿದೆ. ನಾನು ಈ ಬಗ್ಗೆ ಬಹಳ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಮಾತನಾಡುತ್ತೇನೆ. ಭವಿಷ್ಯಕ್ಕಾಗಿ, ಇದರರ್ಥ 0.12 ಶೀಘ್ರದಲ್ಲೇ ಬಿಡುಗಡೆಯಾಗಲಿದೆ.
0.12 ಒಂದು ಟನ್ ಹೊಸ ವಿಷಯವಾಗಿದೆ. ನೀವು ನಿಯಮಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಿಂದ ಬಂದರೆ, ನೀವು ಎಲ್ಲಾ ರೀತಿಯ ಡೈನಾಮಿಕ್ ಬ್ಲಾಕ್‌ಗಳು, ಲೂಪ್‌ಗಳು, ಸರಿಯಾದ ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಹೋಲಿಕೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ಅಲ್ಲಿ ಎಡ ಮತ್ತು ಬಲ ಬದಿಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಲೆಕ್ಕಹಾಕಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ. ನೀವು ಅದನ್ನು ಬಹಳಷ್ಟು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ, ಆದ್ದರಿಂದ 0.12 ನಿಮಗಾಗಿ ಅದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಆದರೆ! ರೆಡಿಮೇಡ್ ಮಾಡ್ಯೂಲ್ಗಳು ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಕಡಿಮೆ ಮತ್ತು ಹೆಚ್ಚು ಸರಳವಾಗಿ ಬರೆದರೆ, ನಂತರ ನೀವು ಕಾಯಬೇಕಾಗಿಲ್ಲ ಮತ್ತು 0.12 ಬಂದು ನಿಮಗಾಗಿ ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತೀರಿ.
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನೀವು ಮೂಲಸೌಕರ್ಯವನ್ನು ಕೋಡ್‌ನಂತೆ ಮಾತನಾಡಿದ್ದೀರಿ ಮತ್ತು ಅಕ್ಷರಶಃ ಪರೀಕ್ಷೆಗಳ ಬಗ್ಗೆ ಒಂದು ಮಾತು ಹೇಳಿದ್ದೀರಿ. ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಪರೀಕ್ಷೆಗಳು ಅಗತ್ಯವಿದೆಯೇ? ಇದು ಯಾರ ಜವಾಬ್ದಾರಿ? ನಾನು ಅದನ್ನು ನಾನೇ ಬರೆಯಬೇಕೇ ಅಥವಾ ಮಾಡ್ಯೂಲ್‌ಗಳ ಜವಾಬ್ದಾರಿಯೇ?
ಮುಂದಿನ ವರ್ಷ ನಾವು ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಎಂಬ ವರದಿಗಳಿಂದ ತುಂಬಿರುತ್ತದೆ. ಯಾವುದನ್ನು ಪರೀಕ್ಷಿಸಬೇಕು ಎಂಬುದು ದೊಡ್ಡ ಪ್ರಶ್ನೆ. ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರಿಂದ ಬಹಳಷ್ಟು ಅವಲಂಬನೆಗಳು, ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಗಳಿವೆ. ನೀವು ಮತ್ತು ನಾನು ಮಾತನಾಡುತ್ತಿರುವಾಗ ಮತ್ತು "ನನಗೆ ಪರೀಕ್ಷೆಗಳು ಬೇಕು" ಎಂದು ನೀವು ಹೇಳಿದಾಗ ನಾನು ಕೇಳುತ್ತೇನೆ: "ನೀವು ಏನು ಪರೀಕ್ಷಿಸುತ್ತೀರಿ?" ನಿಮ್ಮ ಪ್ರದೇಶದಲ್ಲಿ ಪರೀಕ್ಷೆ ಮಾಡುವುದಾಗಿ ಹೇಳುತ್ತೀರಿ. ಆಗ ನನ್ನ ಪ್ರದೇಶದಲ್ಲಿ ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ಅಂದರೆ, ನಾವು ಇದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು ಸಹ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಸಾಕಷ್ಟು ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ಹೇಳಬಾರದು. ಅಂದರೆ, ಈ ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ಬರೆಯಬೇಕು ಇದರಿಂದ ಅವು ಸಮರ್ಪಕವಾಗಿರುತ್ತವೆ.
ನಾನು ಈ ವಿಷಯವನ್ನು ಸಕ್ರಿಯವಾಗಿ ಸಂಶೋಧಿಸುತ್ತಿದ್ದೇನೆ, ಅಂದರೆ ನೀವು ಬರೆದ ಮೂಲಸೌಕರ್ಯವನ್ನು ಆಧರಿಸಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೇಗೆ ರಚಿಸುವುದು. ಅಂದರೆ, ನೀವು ಈ ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದರೆ, ನಾನು ಅದನ್ನು ಚಲಾಯಿಸಬೇಕಾಗಿದೆ, ಇದರ ಆಧಾರದ ಮೇಲೆ ನಾನು ಪರೀಕ್ಷೆಗಳನ್ನು ರಚಿಸಬಹುದು.
ಟೆರಾಫಾರ್ಮ್‌ಗಾಗಿ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಹೆಚ್ಚಾಗಿ ಉಲ್ಲೇಖಿಸಲಾದ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಇದು ಉಪಯುಕ್ತತೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾನು DSL ಪ್ರಕಾರವನ್ನು ಆದ್ಯತೆ ನೀಡುತ್ತೇನೆ, ಉದಾಹರಣೆಗೆ, rspec.
ಆಂಟನ್, ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನ್ನ ಹೆಸರು ವ್ಯಾಲೆರಿ. ಸ್ವಲ್ಪ ತಾತ್ವಿಕ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತೇನೆ. ಷರತ್ತುಬದ್ಧವಾಗಿ, ನಿಬಂಧನೆ ಇದೆ, ನಿಯೋಜನೆ ಇದೆ. ಪ್ರಾವಿಶನಿಂಗ್ ನನ್ನ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ನಿಯೋಜನೆಯಲ್ಲಿ ನಾವು ಅದನ್ನು ಉಪಯುಕ್ತವಾದ ಯಾವುದನ್ನಾದರೂ ತುಂಬುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್‌ಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಇತ್ಯಾದಿ. ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಒದಗಿಸುವಿಕೆಗೆ ಹೆಚ್ಚು ಮತ್ತು ಅನ್ಸಿಬಲ್ ನಿಯೋಜನೆಗೆ ಹೆಚ್ಚು ಎಂದು ನನ್ನ ತಲೆಯಲ್ಲಿದೆ, ಏಕೆಂದರೆ ಅನ್ಸಿಬಲ್ ಭೌತಿಕ ಮೂಲಸೌಕರ್ಯಕ್ಕೂ ಆಗಿದೆ nginx, Postgres ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಅನ್ಸಿಬಲ್ ಒದಗಿಸುವಿಕೆಯನ್ನು ಅನುಮತಿಸುವಂತೆ ತೋರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಅಮೆಜಾನ್ ಅಥವಾ ಗೂಗಲ್ ಸಂಪನ್ಮೂಲಗಳು. ಆದರೆ ಟೆರಾಫಾರ್ಮ್ ಅದರ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕೆಲವು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಿಮ್ಮ ದೃಷ್ಟಿಕೋನದಿಂದ, ಟೆರಾಫಾರ್ಮ್ ಮತ್ತು ಅನ್ಸಿಬಲ್ ನಡುವೆ ಕೆಲವು ರೀತಿಯ ಗಡಿ ಇದೆಯೇ, ಎಲ್ಲಿ ಮತ್ತು ಯಾವುದನ್ನು ಬಳಸುವುದು ಉತ್ತಮ? ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಅನ್ಸಿಬಲ್ ಈಗಾಗಲೇ ಕಸ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ, ನೀವು ಎಲ್ಲದಕ್ಕೂ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು?
ಒಳ್ಳೆಯ ಪ್ರಶ್ನೆ, ವ್ಯಾಲೆರಿ. 2014 ರಿಂದ ಉದ್ದೇಶದ ವಿಷಯದಲ್ಲಿ ಟೆರಾಫಾರ್ಮ್ ಬದಲಾಗಿಲ್ಲ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಇದನ್ನು ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ ಸತ್ತಿದೆ. ನಾವು ಇನ್ನೂ ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆಯ ಅಗತ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಅನ್ಸಿಬಲ್. ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್ ಒಳಗೆ ಬಳಕೆದಾರರ ಡೇಟಾ ಇದೆ ಎಂಬುದು ಸವಾಲು. ಮತ್ತು ಅಲ್ಲಿ ನೀವು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಎಳೆಯಿರಿ, ಇತ್ಯಾದಿ. ಇದು ನಾನು ಹೆಚ್ಚು ಇಷ್ಟಪಡುವ ಪ್ರಮಾಣಿತ ವ್ಯತ್ಯಾಸವಾಗಿದೆ.
ನಾವು ಸುಂದರವಾದ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಈ ಚಿತ್ರವನ್ನು ಸಂಗ್ರಹಿಸುವ ಪ್ಯಾಕರ್‌ನಂತಹ ಉಪಯುಕ್ತತೆಗಳಿವೆ. ತದನಂತರ Terraform ಈ ಚಿತ್ರವನ್ನು ಹುಡುಕಲು ಮತ್ತು ಅದರ launch_configuration ಅನ್ನು ನವೀಕರಿಸಲು ಡೇಟಾ ಮೂಲವನ್ನು ಬಳಸುತ್ತದೆ. ಅಂದರೆ, ಈ ರೀತಿಯಾಗಿ ಪೈಪ್‌ಲೈನ್ ನಾವು ಮೊದಲು ಟ್ರ್ಯಾಕರ್ ಅನ್ನು ಎಳೆಯುತ್ತೇವೆ, ನಂತರ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಎಳೆಯುತ್ತೇವೆ. ಮತ್ತು ನಿರ್ಮಾಣ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಂತರ ಹೊಸ ಬದಲಾವಣೆ ಸಂಭವಿಸುತ್ತದೆ.
ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನ್ನ ಹೆಸರು ಮಿಶಾ, RBS ಕಂಪನಿ. ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸುವಾಗ ನೀವು ಪ್ರೊವಿಶನರ್ ಮೂಲಕ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಕರೆಯಬಹುದು. ಅನ್ಸಿಬಲ್ ಡೈನಾಮಿಕ್ ಇನ್ವೆಂಟರಿ ಎಂಬ ವಿಷಯವನ್ನು ಸಹ ಹೊಂದಿದೆ. ಮತ್ತು ನೀವು ಮೊದಲು ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಕರೆಯಬಹುದು, ತದನಂತರ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಕರೆಯಬಹುದು, ಅದು ರಾಜ್ಯದಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಯಾವುದು ಉತ್ತಮ?
ಜನರು ಎರಡನ್ನೂ ಸಮಾನ ಯಶಸ್ಸಿನೊಂದಿಗೆ ಬಳಸುತ್ತಾರೆ. ನಾವು ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗುಂಪಿನ ಬಗ್ಗೆ ಮಾತನಾಡದಿದ್ದರೆ ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಡೈನಾಮಿಕ್ ಇನ್ವೆಂಟರಿ ಅನುಕೂಲಕರ ವಿಷಯ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಏಕೆಂದರೆ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗುಂಪಿನಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ನಮ್ಮದೇ ಆದ ಟೂಲ್ಕಿಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದನ್ನು ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಾವು ಹೊಸ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿದಾಗ ಪ್ರಾರಂಭಿಸಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ನಾವು ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಅಮೆಜಾನ್‌ನೊಂದಿಗೆ, ಡೈನಾಮಿಕ್ ಇನ್ವೆಂಟರಿಯನ್ನು ಬಳಸುವುದು ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಟಿಎಸ್ ಫೈಲ್ ಅನ್ನು ಓದುವುದು, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಓವರ್‌ಕಿಲ್ ಆಗಿದೆ. ಮತ್ತು "ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗ್ರೂಪ್" ಎಂಬ ಪರಿಕಲ್ಪನೆಯಿಲ್ಲದ ಇತರ ಸಾಧನಗಳನ್ನು ನೀವು ಬಳಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು ಡಿಜಿಟಲ್ ಓಷನ್ ಅಥವಾ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಗುಂಪು ಇಲ್ಲದಿರುವ ಇತರ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿದರೆ, ಅಲ್ಲಿ ನೀವು API ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಎಳೆಯಬೇಕು, IP ವಿಳಾಸಗಳನ್ನು ಹುಡುಕಿ, ರಚಿಸಿ ಡೈನಾಮಿಕ್ ಇನ್ವೆಂಟರಿ ಫೈಲ್ , ಮತ್ತು ಅನ್ಸಿಬಲ್ ಈಗಾಗಲೇ ಅದರ ಮೂಲಕ ಅಲೆದಾಡುತ್ತದೆ. ಅಂದರೆ, ಅಮೆಜಾನ್‌ಗೆ ಲಾಂಚ್_ಕಾನ್ಫಿಗರೇಶನ್ ಇದೆ, ಮತ್ತು ಉಳಿದಂತೆ ಡೈನಾಮಿಕ್ ಇನ್ವೆಂಟರಿ ಇದೆ.
ಮೂಲ: www.habr.com