ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಪಾವೆಲ್ ಅಗಾಲೆಟ್ಸ್ಕಿ. ನಾನು ಲಮೊಡಾ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ತಂಡದಲ್ಲಿ ತಂಡದ ನಾಯಕನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. 2018 ರಲ್ಲಿ, ನಾನು ಹೈಲೋಡ್ ++ ಸಮ್ಮೇಳನದಲ್ಲಿ ಮಾತನಾಡಿದ್ದೇನೆ ಮತ್ತು ಇಂದು ನನ್ನ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸುವಲ್ಲಿ ನಮ್ಮ ಕಂಪನಿಯ ಅನುಭವಕ್ಕೆ ನನ್ನ ವಿಷಯವನ್ನು ಸಮರ್ಪಿಸಲಾಗಿದೆ. ನಮ್ಮ ಇತಿಹಾಸಪೂರ್ವ ಕಾಲದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಾವು ಎಲ್ಲಾ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಿದಾಗ, ನೊಮಾಡ್ನಿಂದ ಕುಬರ್ನೆಟ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಗೆ ಕ್ರಮೇಣ ಪರಿವರ್ತನೆಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ನಾವು ಇದನ್ನು ಏಕೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಮಗೆ ಯಾವ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
VM ಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತಿದೆ
3 ವರ್ಷಗಳ ಹಿಂದೆ ಕಂಪನಿಯ ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ತಾಂತ್ರಿಕವಾಗಿ, ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳ ಎಲ್ಲಾ ಕೋಡ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತ ಅಸೆಂಬ್ಲಿ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಜೆಂಕಿನ್‌ಗಳನ್ನು ಬಳಸಿ ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಜೋಡಿಸುವ ರೀತಿಯಲ್ಲಿ ಇದನ್ನು ಆಯೋಜಿಸಲಾಗಿದೆ. ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಮ್ಮ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯಿಂದ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೊರತರಲಾಗಿದೆ. ಇದಲ್ಲದೆ, ನಮ್ಮ ಕಂಪನಿಯ ಪ್ರತಿಯೊಂದು ವ್ಯವಸ್ಥೆಯನ್ನು ಕನಿಷ್ಠ 2 ಸರ್ವರ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ: ಅವುಗಳಲ್ಲಿ ಒಂದು ತಲೆಯ ಮೇಲೆ, ಎರಡನೆಯದು ಬಾಲದಲ್ಲಿ. ಈ ಎರಡು ವ್ಯವಸ್ಥೆಗಳು ಅವುಗಳ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಪವರ್, ಕಾನ್ಫಿಗರೇಶನ್ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಪರಸ್ಪರ ಸಂಪೂರ್ಣವಾಗಿ ಹೋಲುತ್ತವೆ. ಅವುಗಳ ನಡುವಿನ ಏಕೈಕ ವ್ಯತ್ಯಾಸವೆಂದರೆ ತಲೆಯು ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯಿತು, ಆದರೆ ಬಾಲವು ಎಂದಿಗೂ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸಲಿಲ್ಲ.
ಇದನ್ನು ಏಕೆ ಮಾಡಲಾಯಿತು?
ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಬಿಡುಗಡೆಗಳನ್ನು ನಾವು ನಿಯೋಜಿಸಿದಾಗ, ತಡೆರಹಿತ ರೋಲ್‌ಔಟ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಅಂದರೆ, ಬಳಕೆದಾರರಿಗೆ ಗಮನಾರ್ಹ ಪರಿಣಾಮಗಳಿಲ್ಲದೆ. ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮುಂದಿನ ಸಂಕಲನ ಬಿಡುಗಡೆಯನ್ನು ಬಾಲಕ್ಕೆ ಹೊರತೆಗೆದ ಕಾರಣ ಇದನ್ನು ಸಾಧಿಸಲಾಗಿದೆ. ಅಲ್ಲಿ, ನಿಯೋಜನೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಜನರು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು: ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳು, ವಿಭಾಗಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ; ಅಗತ್ಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ಮನವರಿಕೆಯಾದ ನಂತರವೇ ಸಂಚಾರ ಬದಲಾಯಿಸಲಾಯಿತು. ಇದು ಹಿಂದೆ ಬಾಲವಾಗಿದ್ದ ಸರ್ವರ್‌ಗೆ ಹೋಗಲು ಪ್ರಾರಂಭಿಸಿತು. ಮತ್ತು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಿಂದಿನ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿರುವಾಗಲೂ ಹಿಂದಿನ ತಲೆಯು ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯಿಲ್ಲದೆ ಉಳಿಯಿತು.
ಆದ್ದರಿಂದ ಇದು ಬಳಕೆದಾರರಿಗೆ ತಡೆರಹಿತವಾಗಿತ್ತು. ಏಕೆಂದರೆ ಸ್ವಿಚಿಂಗ್ ತ್ವರಿತವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸರಳವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ ನೀವು ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಸುಲಭವಾಗಿ ಹಿಂತಿರುಗಬಹುದು. ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲೇ ಅಪ್ಲಿಕೇಶನ್ ಉತ್ಪಾದನೆಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬಹುದು, ಅದು ಸಾಕಷ್ಟು ಅನುಕೂಲಕರವಾಗಿದೆ.
ಈ ಎಲ್ಲದರಲ್ಲೂ ನಾವು ಯಾವ ಪ್ರಯೋಜನಗಳನ್ನು ನೋಡಿದ್ದೇವೆ?
- ಮೊದಲನೆಯದಾಗಿ, ಇದು ಸಾಕು ಇದು ಕೇವಲ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅಂತಹ ನಿಯೋಜನೆ ಯೋಜನೆಯು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರತಿಯೊಬ್ಬರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಜನರು ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಿದ್ದಾರೆ.
- ಇದು ಸಾಕು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ, ನಿಯೋಜನೆ ತಂತ್ರಜ್ಞಾನವು ಸರಳವಾಗಿರುವುದರಿಂದ, ಸಾವಿರಾರು ಕಂಪನಿಗಳಿಂದ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ. ಲಕ್ಷಾಂತರ ಸರ್ವರ್‌ಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಏನನ್ನಾದರೂ ಮುರಿಯುವುದು ಕಷ್ಟ.
- ಮತ್ತು ಅಂತಿಮವಾಗಿ ನಾವು ಪಡೆಯಬಹುದು ಪರಮಾಣು ನಿಯೋಜನೆಗಳು. ಹಳೆಯ ಆವೃತ್ತಿ ಮತ್ತು ಹೊಸದರ ನಡುವೆ ಬದಲಾಯಿಸುವ ಗಮನಾರ್ಹ ಹಂತವಿಲ್ಲದೆ ಬಳಕೆದಾರರಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಸಂಭವಿಸುವ ನಿಯೋಜನೆಗಳು.
ಆದರೆ ಈ ಎಲ್ಲದರಲ್ಲೂ ನಾವು ಹಲವಾರು ನ್ಯೂನತೆಗಳನ್ನು ನೋಡಿದ್ದೇವೆ:
- ಉತ್ಪಾದನಾ ಪರಿಸರದ ಜೊತೆಗೆ, ಅಭಿವೃದ್ಧಿ ಪರಿಸರ, ಇತರ ಪರಿಸರಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, qa ಮತ್ತು ಪೂರ್ವಉತ್ಪಾದನೆ. ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಅನೇಕ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಸುಮಾರು 60 ಸೇವೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ ಇದು ಅಗತ್ಯವಾಗಿತ್ತು ಪ್ರತಿ ಸೇವೆಗೆ, ಅದಕ್ಕಾಗಿ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ವಹಿಸಿ ವರ್ಚುವಲ್ ಯಂತ್ರ. ಇದಲ್ಲದೆ, ನೀವು ಲೈಬ್ರರಿಗಳನ್ನು ನವೀಕರಿಸಲು ಅಥವಾ ಹೊಸ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಇದನ್ನು ಎಲ್ಲಾ ಪರಿಸರದಲ್ಲಿ ಮಾಡಬೇಕಾಗಿದೆ. ಡೆವೊಪ್ಸ್ ಅಗತ್ಯ ಪರಿಸರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಮಯದೊಂದಿಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮುಂದಿನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಲು ಹೋಗುವ ಸಮಯವನ್ನು ಸಹ ನೀವು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಮ್ಮ ಪರಿಸರವು ಎಲ್ಲಾ ಪರಿಸರದಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿರುವ ಪರಿಸ್ಥಿತಿಗೆ ಬರುವುದು ಸುಲಭ. ಉದಾಹರಣೆಗೆ, QA ಪರಿಸರದಲ್ಲಿ ಲೈಬ್ರರಿಗಳ ಕೆಲವು ಆವೃತ್ತಿಗಳು ಇರುತ್ತವೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ವಿಭಿನ್ನವಾದವುಗಳಿರುತ್ತವೆ, ಅದು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
- ಅವಲಂಬನೆಗಳನ್ನು ನವೀಕರಿಸುವಲ್ಲಿ ತೊಂದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್. ಇದು ನಿಮ್ಮ ಮೇಲೆ ಅಲ್ಲ, ಆದರೆ ಇತರ ತಂಡದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅವುಗಳೆಂದರೆ, ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಡೆವೊಪ್ಸ್ ತಂಡದಿಂದ. ನೀವು ಅವರಿಗೆ ಸೂಕ್ತವಾದ ಕೆಲಸವನ್ನು ನೀಡಬೇಕು ಮತ್ತು ನೀವು ಏನು ಮಾಡಲು ಬಯಸುತ್ತೀರಿ ಎಂಬುದರ ವಿವರಣೆಯನ್ನು ನೀಡಬೇಕು.
- ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಹೊಂದಿರುವ ದೊಡ್ಡ ದೊಡ್ಡ ಏಕಶಿಲೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸಣ್ಣ ಸೇವೆಗಳಾಗಿ ವಿಂಗಡಿಸಲು ನಾವು ಬಯಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಇರುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಈಗಾಗಲೇ ಅವುಗಳಲ್ಲಿ 100 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರತಿ ಹೊಸ ಸೇವೆಗಾಗಿ, ಪ್ರತ್ಯೇಕ ಹೊಸ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು, ಅದನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು ನಿಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿಮಗೆ ಒಂದು ಕಾರು ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಕನಿಷ್ಠ ಎರಡು. ಈ ಎಲ್ಲದಕ್ಕೂ ಕ್ಯೂಎ ಪರಿಸರವನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಇದು ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಮತ್ತು ಹೊಸ ಸಿಸ್ಟಂಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಚಲಾಯಿಸಲು ನಿಮಗೆ ಕಷ್ಟವಾಗುತ್ತದೆ. ಸಂಕೀರ್ಣ, ದುಬಾರಿ ಮತ್ತು ಸುದೀರ್ಘ ಪ್ರಕ್ರಿಯೆ.
ಆದ್ದರಿಂದ, ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ನಿಯೋಜಿಸುವುದರಿಂದ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಡಾಕರ್ ಕಂಟೇನರ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನೀವು ಡಾಕರ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಕೇವಲ ಕಂಟೇನರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರನ್ ಮಾಡಬಹುದಾದ ಸಿಸ್ಟಮ್ ನಿಮಗೆ ಬೇಕಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಎಷ್ಟು ಕಂಟೇನರ್‌ಗಳನ್ನು ಎತ್ತಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಬಯಸುತ್ತೀರಿ ಇದರಿಂದ ಅವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಎತ್ತುತ್ತವೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ನಾವು ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿದೆ.
ಯಾವುದನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಎಂದು ನಾವು ಬಹಳ ಸಮಯ ಯೋಚಿಸಿದೆವು. ವಾಸ್ತವವೆಂದರೆ ಆ ಸಮಯದಲ್ಲಿ ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಈ ನಿಯೋಜನೆ ಸ್ಟಾಕ್ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಹಳೆಯದಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅವುಗಳು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಕೆಲವು ಹಂತದಲ್ಲಿ, FreeBSD ಸಹ ಇತ್ತು, ಅದು ಬೆಂಬಲಿಸಲು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ. ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಡಾಕರ್‌ಗೆ ವಲಸೆ ಹೋಗಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ನಮ್ಮ ಡೆವೊಪ್‌ಗಳು ತಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅನುಭವವನ್ನು ವಿಭಿನ್ನ ಪರಿಹಾರಗಳೊಂದಿಗೆ ನೋಡಿದರು ಮತ್ತು ನೊಮಾಡ್‌ನಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ಆರಿಸಿಕೊಂಡರು.
ಅಲೆಮಾರಿಗೆ ಬದಲಿಸಿ
ಅಲೆಮಾರಿ HashiCorp ನ ಉತ್ಪನ್ನವಾಗಿದೆ. ಅವರು ತಮ್ಮ ಇತರ ಪರಿಹಾರಗಳಿಗೆ ಹೆಸರುವಾಸಿಯಾಗಿದ್ದಾರೆ:
"ಕನ್ಸಲ್" ಸೇವೆಯ ಅನ್ವೇಷಣೆಗೆ ಒಂದು ಸಾಧನವಾಗಿದೆ.
"ಟೆರಾಫಾರ್ಮ್" - ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ವ್ಯವಸ್ಥೆಯು ಕಾನ್ಫಿಗರೇಶನ್ ಮೂಲಕ ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಮೂಲಸೌಕರ್ಯ-ಎಂದು-ಕೋಡ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ.
"ಅಲೆಮಾರಿ" ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳ ಮೂಲಕ ಸ್ಥಳೀಯವಾಗಿ ಅಥವಾ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ನಿಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಆ ಸಮಯದಲ್ಲಿ ಅಲೆಮಾರಿಗಳು ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ಬದಲಾಯಿಸದೆಯೇ ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸಬಹುದಾದ ಸರಳ ಪರಿಹಾರದಂತೆ ತೋರುತ್ತಿತ್ತು. ಜೊತೆಗೆ, ಇದು ಕಲಿಯಲು ಸಾಕಷ್ಟು ಸುಲಭ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದನ್ನು ನಮ್ಮ ಕಂಟೇನರ್‌ಗಾಗಿ ಶೋಧನೆ ವ್ಯವಸ್ಥೆಯಾಗಿ ಆರಿಸಿಕೊಂಡಿದ್ದೇವೆ.
ನೋಮಾಡ್‌ಗೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನೀವು ಏನು ಬೇಕು?
- ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮೊದಲ ಡಾಕರ್ ಚಿತ್ರ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್. ನೀವು ಅದನ್ನು ನಿರ್ಮಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಡಾಕರ್ ಇಮೇಜ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಇರಿಸಬೇಕು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಆರ್ಟಿಫ್ಯಾಕ್ಟರಿಯಾಗಿದೆ - ವಿಭಿನ್ನ ಪ್ರಕಾರದ ವಿವಿಧ ಕಲಾಕೃತಿಗಳನ್ನು ಅದರೊಳಗೆ ತಳ್ಳಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ವ್ಯವಸ್ಥೆ. ಇದು ಆರ್ಕೈವ್‌ಗಳು, ಡಾಕರ್ ಚಿತ್ರಗಳು, ಸಂಯೋಜಕ PHP ಪ್ಯಾಕೇಜುಗಳು, NPM ಪ್ಯಾಕೇಜುಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.
- ಸಹ ಅಗತ್ಯವಿದೆ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್, ಇದು ನೋಮಾಡ್‌ಗೆ ಏನು, ಎಲ್ಲಿ ಮತ್ತು ಯಾವ ಪ್ರಮಾಣದಲ್ಲಿ ನೀವು ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ತಿಳಿಸುತ್ತದೆ.
ನಾವು ನೊಮಾಡ್ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ಅದು HCL ಭಾಷೆಯನ್ನು ಅದರ ಮಾಹಿತಿ ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಆಗಿ ಬಳಸುತ್ತದೆ HashiCorp ಕಾನ್ಫಿಗರೇಶನ್ ಭಾಷೆ. ಇದು Yaml ನ ಸೂಪರ್‌ಸೆಟ್ ಆಗಿದ್ದು ಅದು ನಿಮ್ಮ ಸೇವೆಯನ್ನು ನೋಮಾಡ್ ಪದಗಳಲ್ಲಿ ವಿವರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ನೀವು ಎಷ್ಟು ಕಂಟೇನರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ, ಯಾವ ಚಿತ್ರಗಳಿಂದ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಅವುಗಳಿಗೆ ವಿವಿಧ ನಿಯತಾಂಕಗಳನ್ನು ರವಾನಿಸಬೇಕು ಎಂದು ಹೇಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ನೀವು ಈ ಫೈಲ್ ಅನ್ನು ನೋಮಾಡ್‌ಗೆ ಫೀಡ್ ಮಾಡಿ, ಮತ್ತು ಅದರ ಪ್ರಕಾರ ಉತ್ಪಾದನೆಗೆ ಧಾರಕಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿ ಸೇವೆಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ರೀತಿಯ HCL ಫೈಲ್‌ಗಳನ್ನು ಬರೆಯುವುದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಬಹಳಷ್ಟು ಸೇವೆಗಳಿವೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ನೀವು ಅವುಗಳನ್ನು ನವೀಕರಿಸಲು ಬಯಸುತ್ತೀರಿ. ಒಂದು ಸೇವೆಯನ್ನು ಒಂದು ನಿದರ್ಶನದಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ವಿಭಿನ್ನವಾದವುಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಾವು ಹೊಂದಿರುವ ಒಂದು ವ್ಯವಸ್ಥೆಯು ಉತ್ಪಾದನೆಯಲ್ಲಿ 100 ಕ್ಕೂ ಹೆಚ್ಚು ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿದೆ. ಅವು ಒಂದೇ ಚಿತ್ರಗಳಿಂದ ರನ್ ಆಗುತ್ತವೆ, ಆದರೆ ಕಾನ್ಫಿಗರೇಶನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ.
ಆದ್ದರಿಂದ, ಒಂದು ಸಾಮಾನ್ಯ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನಿಯೋಜನೆಗಾಗಿ ನಮ್ಮ ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಮಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಈ ರೀತಿಯಾಗಿ ಅವು ಗೋಚರಿಸುತ್ತವೆ: ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸುಲಭ ಮತ್ತು ನಾವು ಯಾವ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬಹುದು. ಅಗತ್ಯವಿದ್ದರೆ, ಏನನ್ನಾದರೂ ನವೀಕರಿಸಲು ಅಥವಾ ಬದಲಾಯಿಸಲು ಸಹ ಸುಲಭವಾಗಿದೆ. ಹೊಸ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸೇರಿಸುವುದು ಕಷ್ಟವೇನಲ್ಲ - ನೀವು ಹೊಸ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ಅದರೊಳಗೆ ಈ ಕೆಳಗಿನ ಫೈಲ್‌ಗಳಿವೆ: service.hcl, ಇದು ನಮ್ಮ ಸೇವೆಯ ವಿವರಣೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಕೆಲವು env ಫೈಲ್‌ಗಳು ಈ ಸೇವೆಯನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿರುವುದರಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ನಮ್ಮ ಕೆಲವು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಒಂದು ನಕಲಿನಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಹಲವಾರು ಏಕಕಾಲದಲ್ಲಿ. ಆದ್ದರಿಂದ, ಸಂರಚನೆಗಳನ್ನು ಅವುಗಳ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ನಮಗೆ ಅನುಕೂಲಕರವಾಗಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದರೆ ಅವುಗಳ ಟೆಂಪ್ಲೇಟ್ ರೂಪದಲ್ಲಿ. ಮತ್ತು ನಾವು ಆರಿಸಿದ್ದೇವೆ ಜಿಂಜಾ 2. ಈ ಸ್ವರೂಪದಲ್ಲಿ, ನಾವು ಸೇವೆಯ ಸಂರಚನೆಗಳನ್ನು ಮತ್ತು ಅದಕ್ಕೆ ಬೇಕಾದ env ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಎಲ್ಲಾ ಯೋಜನೆಗಳಿಗೆ ಸಾಮಾನ್ಯವಾದ ನಿಯೋಜನೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಇರಿಸಿದ್ದೇವೆ, ಇದು ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ, ಬಯಸಿದ ಪರಿಸರಕ್ಕೆ, ಬಯಸಿದ ಗುರಿಗೆ ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ನಿಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಒಂದು ವೇಳೆ ನಾವು ನಮ್ಮ HCL ಸಂರಚನೆಯನ್ನು ಟೆಂಪ್ಲೇಟ್ ಆಗಿ ಪರಿವರ್ತಿಸಿದಾಗ, ಮೊದಲು ಸಾಮಾನ್ಯ Nomad config ಆಗಿದ್ದ HCL ಫೈಲ್, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ಕಾಣಲಾರಂಭಿಸಿತು.
ಅಂದರೆ, env ಫೈಲ್‌ಗಳು ಅಥವಾ ಇತರ ಮೂಲಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾದ ಸೇರಿಸಲಾದ ವೇರಿಯೇಬಲ್‌ಗಳೊಂದಿಗೆ ನಾವು ಕೆಲವು ಕಾನ್ಫಿಗರ್ ಸ್ಥಳ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, HCL ಫೈಲ್‌ಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸಂಗ್ರಹಿಸಲು ನಮಗೆ ಅವಕಾಶ ಸಿಕ್ಕಿತು, ಅಂದರೆ, ನಾವು ಸಾಮಾನ್ಯ ವೇರಿಯಬಲ್ ಅಳವಡಿಕೆಗಳನ್ನು ಮಾತ್ರ ಬಳಸಬಹುದು. ಜಿಂಜಾ ಲೂಪ್‌ಗಳು ಮತ್ತು ಷರತ್ತುಗಳನ್ನು ಬೆಂಬಲಿಸುವುದರಿಂದ, ನೀವು ಅಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಸಹ ರಚಿಸಬಹುದು, ಅದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಖರವಾಗಿ ಎಲ್ಲಿ ನಿಯೋಜಿಸುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಬದಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಪೂರ್ವ-ಉತ್ಪಾದನೆ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಿ. ಪೂರ್ವ-ನಿರ್ಮಾಣದಲ್ಲಿ ನೀವು ಕ್ರಾನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ಹೇಳೋಣ, ಆದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸೇವೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಡೊಮೇನ್‌ನಲ್ಲಿ ನೋಡಲು ಬಯಸುತ್ತೀರಿ. ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸುವ ಯಾರಿಗಾದರೂ, ಪ್ರಕ್ರಿಯೆಯು ತುಂಬಾ ಸರಳ ಮತ್ತು ಪಾರದರ್ಶಕವಾಗಿ ಕಾಣುತ್ತದೆ. ನೀವು ಮಾಡಬೇಕಾಗಿರುವುದು deploy.sh ಫೈಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ, ನೀವು ಯಾವ ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಯಾವ ಗುರಿಗೆ ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. ಉದಾಹರಣೆಗೆ, ನೀವು ರಷ್ಯಾ, ಬೆಲಾರಸ್ ಅಥವಾ ಕಝಾಕಿಸ್ತಾನ್ಗೆ ನಿರ್ದಿಷ್ಟ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ. ಇದನ್ನು ಮಾಡಲು, ನಿಯತಾಂಕಗಳಲ್ಲಿ ಒಂದನ್ನು ಬದಲಾಯಿಸಿ, ಮತ್ತು ನೀವು ಸರಿಯಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.
ನೊಮಾಡ್ ಸೇವೆಯನ್ನು ಈಗಾಗಲೇ ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜಿಸಿದಾಗ, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.
ಮೊದಲಿಗೆ, ನಿಮಗೆ ಕೆಲವು ರೀತಿಯ ಬ್ಯಾಲೆನ್ಸರ್ ಹೊರಗೆ ಅಗತ್ಯವಿದೆ, ಅದು ಎಲ್ಲಾ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಇದು ಕಾನ್ಸುಲ್ ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಡೊಮೇನ್ ಹೆಸರಿಗೆ ಅನುಗುಣವಾದ ನಿರ್ದಿಷ್ಟ ಸೇವೆಯು ಎಲ್ಲಿ, ಯಾವ ನೋಡ್‌ನಲ್ಲಿ, ಯಾವ IP ವಿಳಾಸದಲ್ಲಿ ಇದೆ ಎಂದು ಕಂಡುಹಿಡಿಯುತ್ತದೆ. ಕಾನ್ಸುಲ್‌ನಲ್ಲಿನ ಸೇವೆಗಳು ನೊಮಾಡ್‌ನಿಂದಲೇ ಬರುತ್ತವೆ. ಇವುಗಳು ಒಂದೇ ಕಂಪನಿಯ ಉತ್ಪನ್ನಗಳಾಗಿರುವುದರಿಂದ, ಅವು ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿವೆ. ನೋಮಾಡ್ ಔಟ್ ಆಫ್ ದಿ ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಕಾನ್ಸಲ್ ಒಳಗೆ ನೋಂದಾಯಿಸಬಹುದು ಎಂದು ನಾವು ಹೇಳಬಹುದು.
ನಿಮ್ಮ ಫ್ರಂಟ್-ಎಂಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಯಾವ ಸೇವೆಗೆ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸಬೇಕೆಂದು ತಿಳಿದಿದ್ದರೆ, ಅದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಸೂಕ್ತವಾದ ಕಂಟೇನರ್ ಅಥವಾ ಬಹು ಕಂಟೈನರ್‌ಗಳಿಗೆ ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ನೈಸರ್ಗಿಕವಾಗಿ, ಸುರಕ್ಷತೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಸಹ ಅಗತ್ಯವಾಗಿದೆ. ಎಲ್ಲಾ ಸೇವೆಗಳು ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ವರ್ಚುವಲ್ ಗಣಕಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಸಹ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಸೇವೆಯಿಂದ ಯಾವುದೇ ಇತರ ಸೇವೆಗಳಿಗೆ ಉಚಿತ ಪ್ರವೇಶವನ್ನು ತಡೆಯುವ ಅಗತ್ಯವಿದೆ. ವಿಭಜನೆಯ ಮೂಲಕ ನಾವು ಇದನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ. ಪ್ರತಿಯೊಂದು ಸೇವೆಯನ್ನು ತನ್ನದೇ ಆದ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ಅದರ ಮೇಲೆ ರೂಟಿಂಗ್ ನಿಯಮಗಳು ಮತ್ತು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸುವ/ನಿರಾಕರಿಸುವ ನಿಯಮಗಳನ್ನು ಸೂಚಿಸಲಾಗಿದೆ. ಅವರು ಈ ಕ್ಲಸ್ಟರ್ ಒಳಗೆ ಮತ್ತು ಹೊರಗೆ ಎರಡೂ ನೆಲೆಗೊಂಡಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗೆ ಸೇವೆಯನ್ನು ಸಂಪರ್ಕಿಸುವುದನ್ನು ತಡೆಯಲು ನೀವು ಬಯಸಿದರೆ, ಇದನ್ನು ನೆಟ್ವರ್ಕ್-ಮಟ್ಟದ ವಿಭಾಗದ ಮೂಲಕ ಮಾಡಬಹುದು. ಅಂದರೆ, ತಪ್ಪಾಗಿಯೂ ಸಹ, ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಪರೀಕ್ಷಾ ಪರಿಸರದಿಂದ ನಿಮ್ಮ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಮಾನವ ಸಂಪನ್ಮೂಲದ ವಿಷಯದಲ್ಲಿ ಪರಿವರ್ತನೆಯು ನಮಗೆ ಎಷ್ಟು ವೆಚ್ಚವಾಯಿತು?
ಇಡೀ ಕಂಪನಿಯ ಪರಿವರ್ತನೆಯು ನೊಮಾಡ್‌ಗೆ ಸರಿಸುಮಾರು 5-6 ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ನಾವು ಸೇವೆಯಿಂದ ಸೇವೆಯ ಆಧಾರದ ಮೇಲೆ ತೆರಳಿದ್ದೇವೆ, ಆದರೆ ಸಾಕಷ್ಟು ವೇಗದಲ್ಲಿ. ಪ್ರತಿಯೊಂದು ತಂಡವು ಸೇವೆಗಳಿಗಾಗಿ ತಮ್ಮದೇ ಆದ ಪಾತ್ರೆಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿತ್ತು.
ಪ್ರತಿ ತಂಡವು ಸ್ವತಂತ್ರವಾಗಿ ತಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳ ಡಾಕರ್ ಚಿತ್ರಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವಂತಹ ವಿಧಾನವನ್ನು ನಾವು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. DevOps ನಿಯೋಜನೆಗೆ ಅಗತ್ಯವಾದ ಸಾಮಾನ್ಯ ಮೂಲಸೌಕರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅಂದರೆ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬೆಂಬಲ, CI ಸಿಸ್ಟಮ್‌ಗೆ ಬೆಂಬಲ, ಇತ್ಯಾದಿ. ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ, ನಾವು 60 ಕ್ಕೂ ಹೆಚ್ಚು ವ್ಯವಸ್ಥೆಗಳನ್ನು ನೋಮಾಡ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದ್ದೇವೆ, ಅದು ಸುಮಾರು 2 ಸಾವಿರ ಕಂಟೇನರ್‌ಗಳಷ್ಟಿತ್ತು.
ಡೆವೊಪ್ಸ್ ನಿಯೋಜನೆ ಮತ್ತು ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲದರ ಸಾಮಾನ್ಯ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಮತ್ತು ಪ್ರತಿ ಅಭಿವೃದ್ಧಿ ತಂಡವು ಅದರ ನಿರ್ದಿಷ್ಟ ವ್ಯವಸ್ಥೆಗಾಗಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ, ಏಕೆಂದರೆ ಇದು ನಿರ್ದಿಷ್ಟ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಬೇಕು ಎಂದು ತಿಳಿದಿರುವ ತಂಡವಾಗಿದೆ.
ಅಲೆಮಾರಿಗಳನ್ನು ತ್ಯಜಿಸಲು ಕಾರಣಗಳು
ಇತರರ ಪೈಕಿ ನೊಮಾಡ್ ಮತ್ತು ಡಾಕರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಿಯೋಜನೆಗೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ ನಾವು ಯಾವ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ?
- ನಾವು ಸಮಾನ ಷರತ್ತುಗಳನ್ನು ಒದಗಿಸಿದೆ ಎಲ್ಲಾ ಪರಿಸರಗಳಿಗೆ. ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, QA ಪರಿಸರ, ಪೂರ್ವ-ಉತ್ಪಾದನೆ, ಉತ್ಪಾದನೆ, ಅದೇ ಧಾರಕ ಚಿತ್ರಗಳನ್ನು ಅದೇ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ. ಅಂತೆಯೇ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದು ನೀವು ಈ ಹಿಂದೆ ಸ್ಥಳೀಯವಾಗಿ ಅಥವಾ ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದ್ದಲ್ಲ ಎಂದು ನಿಮಗೆ ವಾಸ್ತವಿಕವಾಗಿ ಯಾವುದೇ ಅವಕಾಶವಿಲ್ಲ.
- ನಮಗೂ ಸಾಕು ಅನ್ನಿಸಿತು ಹೊಸ ಸೇವೆಯನ್ನು ಸೇರಿಸಲು ಸುಲಭ. ನಿಯೋಜನೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಯಾವುದೇ ಹೊಸ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಸರಳವಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಸಂರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ರೆಪೊಸಿಟರಿಗೆ ಹೋಗಿ, ಅಲ್ಲಿ ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಾಗಿ ಮತ್ತೊಂದು ಸಂರಚನೆಯನ್ನು ಸೇರಿಸಿ ಮತ್ತು ನೀವು ಸಿದ್ಧರಾಗಿರುವಿರಿ. devops ನಿಂದ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನವಿಲ್ಲದೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಬಹುದು.
- ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು ಒಂದು ಸಾಮಾನ್ಯ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪರಿಶೀಲನೆಯಲ್ಲಿದೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ನಾವು ವರ್ಚುವಲ್ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿದ ಸಮಯದಲ್ಲಿ, ನಾವು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ಅದರಲ್ಲಿ ಸಂರಚನೆಗಳು ಒಂದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿವೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ಕೆಲಸ ಮಾಡಲು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿತ್ತು. ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ನೀವು ಸೇರಿಸಬೇಕಾದ ಸಂರಚನೆಗಳು ಮತ್ತು ಕೋಡ್‌ಗಳ ಪ್ರಮಾಣವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಜೊತೆಗೆ, ಅದನ್ನು ಸರಿಪಡಿಸಲು ಅಥವಾ ಬದಲಾಯಿಸಲು devops ಗೆ ತುಂಬಾ ಸುಲಭ. ಪರಿವರ್ತನೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ನೋಮಾಡ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗೆ, ಅವರು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರುವ ಎಲ್ಲಾ ಆಪರೇಟಿಂಗ್ ಫೈಲ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿ ನವೀಕರಿಸಬಹುದು.
ಆದರೆ ನಾವು ಹಲವಾರು ಅನಾನುಕೂಲಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ:
ನಾವು ಎಂದು ಬದಲಾಯಿತು ತಡೆರಹಿತ ನಿಯೋಜನೆಗಳನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಅಲೆಮಾರಿ ವಿಷಯದಲ್ಲಿ. ವಿಭಿನ್ನ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ರೋಲಿಂಗ್ ಮಾಡುವಾಗ, ಅದು ಚಾಲನೆಯಲ್ಲಿದೆ, ಮತ್ತು ನೊಮಾಡ್ ಅದನ್ನು ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಕಂಟೇನರ್ ಎಂದು ಗ್ರಹಿಸಿದರು. ಅದರೊಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅವಕಾಶವನ್ನು ಹೊಂದುವ ಮೊದಲು ಇದು ಸಂಭವಿಸಿದೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಸಿಸ್ಟಮ್ ಅಲ್ಪಾವಧಿಗೆ 500 ದೋಷಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸಿತು, ಏಕೆಂದರೆ ಸಂಚಾರವು ಅದನ್ನು ಸ್ವೀಕರಿಸಲು ಇನ್ನೂ ಸಿದ್ಧವಾಗಿಲ್ಲದ ಕಂಟೇನರ್ಗೆ ಹೋಗಲು ಪ್ರಾರಂಭಿಸಿತು.
ನಾವು ಕೆಲವನ್ನು ಎದುರಿಸಿದ್ದೇವೆ ದೋಷಗಳು. ನೀವು ಅನೇಕ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ನೊಮಾಡ್ ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂಬುದು ಅತ್ಯಂತ ಗಮನಾರ್ಹವಾದ ದೋಷವಾಗಿದೆ. ನಿರ್ವಹಣೆಗಾಗಿ ನೊಮಾಡ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ನೀವು ಹೊರತೆಗೆಯಲು ಬಯಸಿದಾಗ, ಕ್ಲಸ್ಟರ್ ತುಂಬಾ ಉತ್ತಮವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಕುಸಿಯುವ ಸಂಭವನೀಯತೆ ಹೆಚ್ಚು. ಕೆಲವು ಕಂಟೈನರ್‌ಗಳು, ಉದಾಹರಣೆಗೆ, ಬೀಳಬಹುದು ಮತ್ತು ಏರಿಕೆಯಾಗುವುದಿಲ್ಲ - ನಿಮ್ಮ ಎಲ್ಲಾ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳು ನೋಮಾಡ್ ನಿರ್ವಹಿಸುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿದ್ದರೆ ಇದು ನಿಮಗೆ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ.
ಆದ್ದರಿಂದ ನಾವು ಮುಂದೆ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಎಂದು ಯೋಚಿಸಲು ನಿರ್ಧರಿಸಿದೆವು. ಆ ಸಮಯದಲ್ಲಿ, ನಾವು ಏನನ್ನು ಸಾಧಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ನಮಗೆ ಹೆಚ್ಚು ಅರಿವು ಮೂಡಿತು. ಅವುಗಳೆಂದರೆ: ನಾವು ವಿಶ್ವಾಸಾರ್ಹತೆ, ನೊಮಾಡ್ ಒದಗಿಸುವುದಕ್ಕಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನ ಕಾರ್ಯಗಳನ್ನು ಮತ್ತು ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ, ಹೆಚ್ಚು ಸ್ಥಿರವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಯಸುತ್ತೇವೆ.
ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ನಮ್ಮ ಆಯ್ಕೆಯು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ವೇದಿಕೆಯಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಮೇಲೆ ಬಿದ್ದಿತು. ವಿಶೇಷವಾಗಿ ನಮ್ಮ ಕಂಟೈನರ್‌ಗಳ ಗಾತ್ರ ಮತ್ತು ಸಂಖ್ಯೆ ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಎಂದು ನೀಡಲಾಗಿದೆ. ಅಂತಹ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ನಾವು ನೋಡಬಹುದಾದ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಪರಿವರ್ತನೆ
ಕುಬರ್ನೆಟ್ಸ್ನ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳ ಬಗ್ಗೆ ಮತ್ತು ಅವರು ನೊಮಾಡ್ನಿಂದ ಹೇಗೆ ಭಿನ್ನರಾಗಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಸ್ವಲ್ಪ ಹೇಳುತ್ತೇನೆ.
ಮೊದಲನೆಯದಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿನ ಅತ್ಯಂತ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಯು ಪಾಡ್ನ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ. ಪಾಡ್ ಯಾವಾಗಲೂ ಒಟ್ಟಿಗೆ ಚಲಿಸುವ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕಂಟೇನರ್‌ಗಳ ಗುಂಪಾಗಿದೆ. ಮತ್ತು ಅವರು ಯಾವಾಗಲೂ ಒಂದು ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. ಅವರು ವಿವಿಧ ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ IP 127.0.0.1 ಮೂಲಕ ಪರಸ್ಪರ ಪ್ರವೇಶಿಸಬಹುದು.
ನೀವು nginx ಮತ್ತು php-fpm - ಕ್ಲಾಸಿಕ್ ಸ್ಕೀಮ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ PHP ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಭಾವಿಸೋಣ. ಹೆಚ್ಚಾಗಿ, ನೀವು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ nginx ಮತ್ತು php-fpm ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಇರಿಸಲು ಬಯಸುತ್ತೀರಿ. ಅವುಗಳನ್ನು ಒಂದು ಸಾಮಾನ್ಯ ಪಾಡ್ ಎಂದು ವಿವರಿಸುವ ಮೂಲಕ ಇದನ್ನು ಸಾಧಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನೊಮಾಡ್‌ನೊಂದಿಗೆ ನಾವು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗದಿರುವುದು ಇದನ್ನೇ.
ಎರಡನೆಯ ಪರಿಕಲ್ಪನೆ ನಿಯೋಜನೆ. ವಾಸ್ತವವೆಂದರೆ ಪಾಡ್ ಸ್ವತಃ ಅಲ್ಪಕಾಲಿಕ ವಸ್ತುವಾಗಿದೆ; ಅದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನೀವು ಮೊದಲು ನಿಮ್ಮ ಎಲ್ಲಾ ಹಿಂದಿನ ಕಂಟೈನರ್‌ಗಳನ್ನು ನಾಶಮಾಡಲು ಬಯಸುವಿರಾ, ತದನಂತರ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ಬಯಸುವಿರಾ ಅಥವಾ ಅವುಗಳನ್ನು ಕ್ರಮೇಣವಾಗಿ ಹೊರತರಲು ಬಯಸುವಿರಾ? ಇದು ನಿಯೋಜನೆಯ ಪರಿಕಲ್ಪನೆಯು ಜವಾಬ್ದಾರರಾಗಿರುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ನಿಮ್ಮ ಪಾಡ್‌ಗಳನ್ನು ನೀವು ಹೇಗೆ ನಿಯೋಜಿಸುತ್ತೀರಿ, ಯಾವ ಪ್ರಮಾಣದಲ್ಲಿ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ನವೀಕರಿಸಬೇಕು ಎಂಬುದನ್ನು ಇದು ವಿವರಿಸುತ್ತದೆ.
ಮೂರನೆಯ ಪರಿಕಲ್ಪನೆ ಸೇವೆ. ನಿಮ್ಮ ಸೇವೆಯು ವಾಸ್ತವವಾಗಿ ನಿಮ್ಮ ಸಿಸ್ಟಂ ಆಗಿದೆ, ಇದು ಕೆಲವು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ನಿಮ್ಮ ಸೇವೆಗೆ ಅನುಗುಣವಾಗಿ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಪಾಡ್‌ಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಅಂದರೆ, ಅಂತಹ ಮತ್ತು ಅಂತಹ ಸೇವೆಗೆ ಎಲ್ಲಾ ಒಳಬರುವ ದಟ್ಟಣೆಯನ್ನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಹೆಸರಿನೊಂದಿಗೆ ಈ ನಿರ್ದಿಷ್ಟ ಪಾಡ್‌ಗಳಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂದು ಹೇಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಇದು ನಿಮಗೆ ಸಂಚಾರ ಸಮತೋಲನವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಅಂದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಎರಡು ಪಾಡ್‌ಗಳನ್ನು ನೀವು ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಒಳಬರುವ ಟ್ರಾಫಿಕ್ ಈ ಸೇವೆಗೆ ಸಂಬಂಧಿಸಿದ ಪಾಡ್‌ಗಳ ನಡುವೆ ಸಮವಾಗಿ ಸಮತೋಲನದಲ್ಲಿರುತ್ತದೆ.
ಮತ್ತು ನಾಲ್ಕನೇ ಮೂಲ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ ಪ್ರವೇಶ. ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೇವೆಯಾಗಿದೆ. ಇದು ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. Kubernetes API ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಈ ವಿನಂತಿಗಳನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂಬುದನ್ನು Ingress ನಿರ್ಧರಿಸಬಹುದು. ಇದಲ್ಲದೆ, ಅವನು ಇದನ್ನು ಬಹಳ ಮೃದುವಾಗಿ ಮಾಡುತ್ತಾನೆ. ಈ ಹೋಸ್ಟ್‌ಗೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಮತ್ತು ಅಂತಹ ಮತ್ತು ಅಂತಹ URL ಅನ್ನು ಈ ಸೇವೆಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಹೇಳಬಹುದು. ಮತ್ತು ಈ ಹೋಸ್ಟ್‌ಗೆ ಮತ್ತು ಇನ್ನೊಂದು URL ಗೆ ಬರುವ ಈ ವಿನಂತಿಗಳನ್ನು ಮತ್ತೊಂದು ಸೇವೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಯಾರೊಬ್ಬರ ದೃಷ್ಟಿಕೋನದಿಂದ ತಂಪಾದ ವಿಷಯವೆಂದರೆ ನೀವು ಎಲ್ಲವನ್ನೂ ನೀವೇ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪ್ರವೇಶ ಸಂರಚನೆಯನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ, ನೀವು ಅಂತಹ ಮತ್ತು ಅಂತಹ API ಗೆ ಬರುವ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್‌ಗಳಿಗೆ ಕಳುಹಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, Go ನಲ್ಲಿ. ಆದರೆ ಈ ಟ್ರಾಫಿಕ್, ಅದೇ ಡೊಮೇನ್‌ಗೆ ಬರುತ್ತಿದೆ, ಆದರೆ ಬೇರೆ URL ಗೆ, PHP ನಲ್ಲಿ ಬರೆಯಲಾದ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಕಳುಹಿಸಬೇಕು, ಅಲ್ಲಿ ಸಾಕಷ್ಟು ತರ್ಕವಿದೆ, ಆದರೆ ಅವು ತುಂಬಾ ವೇಗವಾಗಿಲ್ಲ.
ಈ ಎಲ್ಲಾ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ನಾವು ನೊಮಾಡ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿದರೆ, ಮೊದಲ ಮೂರು ಪರಿಕಲ್ಪನೆಗಳು ಒಟ್ಟಿಗೆ ಸೇವೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಮತ್ತು ಕೊನೆಯ ಪರಿಕಲ್ಪನೆಯು ನೊಮಾಡ್‌ನಲ್ಲಿಯೇ ಇರುವುದಿಲ್ಲ. ನಾವು ಬಾಹ್ಯ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ: ಅದು ಹ್ಯಾಪ್ರಾಕ್ಸಿ, nginx, nginx+, ಇತ್ಯಾದಿ. ಘನದ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಈ ಹೆಚ್ಚುವರಿ ಪರಿಕಲ್ಪನೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಚಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನೀವು ಆಂತರಿಕವಾಗಿ ಪ್ರವೇಶವನ್ನು ನೋಡಿದರೆ, ಅದು nginx, haproxy ಅಥವಾ traefik ಆಗಿರುತ್ತದೆ, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.
ನಾನು ವಿವರಿಸಿದ ಎಲ್ಲಾ ಪರಿಕಲ್ಪನೆಗಳು, ವಾಸ್ತವವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಇರುವ ಸಂಪನ್ಮೂಲಗಳಾಗಿವೆ. ಕ್ಯೂಬ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ವಿವರಿಸಲು, ಯಾಮ್ಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ನೋಮಾಡ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ HCL ಫೈಲ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಓದಬಲ್ಲ ಮತ್ತು ಪರಿಚಿತವಾಗಿದೆ. ಆದರೆ ರಚನಾತ್ಮಕವಾಗಿ ಅವರು ಅದೇ ವಿಷಯವನ್ನು ವಿವರಿಸುತ್ತಾರೆ, ಉದಾಹರಣೆಗೆ, ಪಾಡ್. ಅವರು ಹೇಳುತ್ತಾರೆ - ನಾನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪಾಡ್‌ಗಳನ್ನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಚಿತ್ರಗಳೊಂದಿಗೆ, ಅಂತಹ ಮತ್ತು ಅಂತಹ ಪ್ರಮಾಣದಲ್ಲಿ ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರತಿಯೊಂದು ಸಂಪನ್ಮೂಲವನ್ನು ಕೈಯಿಂದ ರಚಿಸಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ: ನಿಯೋಜನೆ, ಸೇವೆಗಳು, ಪ್ರವೇಶ, ಇತ್ಯಾದಿ. ಬದಲಾಗಿ, ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಪ್ರತಿಯೊಂದು ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಕುಬರ್ನೆಟ್‌ಗಳ ಪರಿಭಾಷೆಯಲ್ಲಿ ವಿವರಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲ ಅವಲಂಬನೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮರುಸೃಷ್ಟಿಸಬೇಕಾಗಿಲ್ಲ. ಇದನ್ನು ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುವ ವ್ಯವಸ್ಥೆಯಾಗಿ ಹೆಲ್ಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ.
ಹೆಲ್ಮ್‌ನಲ್ಲಿನ ಮೂಲ ಪರಿಕಲ್ಪನೆಗಳು
ಹೆಲ್ಮ್ ಆಗಿದೆ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ. ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂಬುದರಂತೆಯೇ ಇದು ಹೋಲುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಿಯೋಜನೆ nginx, ನಿಯೋಜನೆ php-fpm, ಪ್ರವೇಶಕ್ಕಾಗಿ config, configmaps (ಇದು ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಾಗಿ env ಮತ್ತು ಇತರ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಒಂದು ಘಟಕವಾಗಿದೆ) ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸೇವೆಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಅವರು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ. ಚಾರ್ಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಲ್ಮ್ ಕುಬರ್ನೆಟ್ಸ್ ಮೇಲೆ ಓಡುತ್ತದೆ. ಅಂದರೆ, ಇದು ಪಕ್ಕಕ್ಕೆ ನಿಂತಿರುವ ಕೆಲವು ರೀತಿಯ ವ್ಯವಸ್ಥೆಯಲ್ಲ, ಆದರೆ ಘನದೊಳಗೆ ಮತ್ತೊಂದು ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಕನ್ಸೋಲ್ ಆಜ್ಞೆಯ ಮೂಲಕ ಅದರ API ಮೂಲಕ ನೀವು ಅದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತೀರಿ. ಇದರ ಅನುಕೂಲತೆ ಮತ್ತು ಸೌಂದರ್ಯವೆಂದರೆ ಚುಕ್ಕಾಣಿಯನ್ನು ಮುರಿದರೂ ಅಥವಾ ನೀವು ಅದನ್ನು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ತೆಗೆದುಹಾಕಿದರೂ, ನಿಮ್ಮ ಸೇವೆಗಳು ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಚುಕ್ಕಾಣಿಯನ್ನು ಮೂಲಭೂತವಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ನಂತರ ಸೇವೆಗಳ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಥಿತಿಗೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ.
ನಮಗೂ ಅರಿವಾಯಿತು ಟೆಂಪ್ಲೇಟೀಕರಣ, ನಮ್ಮ ಸಂರಚನೆಗಳಲ್ಲಿ ಜಿಂಜಾವನ್ನು ಪರಿಚಯಿಸುವ ಮೂಲಕ ನಾವು ಈ ಹಿಂದೆ ನಾವೇ ಮಾಡಲು ಒತ್ತಾಯಿಸಲಾಯಿತು, ಇದು ಚುಕ್ಕಾಣಿಯ ಮುಖ್ಯ ಲಕ್ಷಣಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ ನೀವು ರಚಿಸುವ ಎಲ್ಲಾ ಸಂರಚನೆಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್‌ಗಳ ರೂಪದಲ್ಲಿ ಚುಕ್ಕಾಣಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಜಿಂಜಾಗೆ ಸ್ವಲ್ಪ ಹೋಲುತ್ತದೆ, ಆದರೆ, ವಾಸ್ತವವಾಗಿ, ಗೋ ಭಾಷೆಯ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್‌ನಂತೆ ಚುಕ್ಕಾಣಿ ಬರೆಯಲಾಗಿದೆ.
ಹೆಲ್ಮ್ ನಮಗೆ ಇನ್ನೂ ಕೆಲವು ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.
ಚಾರ್ಟ್ - ಇದು ನಿಮ್ಮ ಸೇವೆಯ ವಿವರಣೆಯಾಗಿದೆ. ಇತರ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಪ್ಯಾಕೇಜ್, ಬಂಡಲ್ ಅಥವಾ ಅಂತಹುದೇ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಅದನ್ನು ಚಾರ್ಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ಮೌಲ್ಯಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಂದ ನಿಮ್ಮ ಸಂರಚನೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ನೀವು ಬಳಸಲು ಬಯಸುವ ಅಸ್ಥಿರಗಳಾಗಿವೆ.
ಬಿಡುಗಡೆ. ಪ್ರತಿ ಬಾರಿಯೂ ಚುಕ್ಕಾಣಿಯನ್ನು ಬಳಸಿ ನಿಯೋಜಿಸಲಾದ ಸೇವೆಯು ಬಿಡುಗಡೆಯ ಹೆಚ್ಚುತ್ತಿರುವ ಆವೃತ್ತಿಯನ್ನು ಪಡೆಯುತ್ತದೆ. ಹಿಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ ಸೇವೆಯ ಸಂರಚನೆ ಏನಾಗಿತ್ತು, ಅದಕ್ಕಿಂತ ಮೊದಲು ಬಿಡುಗಡೆ, ಇತ್ಯಾದಿಗಳನ್ನು ಹೆಲ್ಮ್ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಆದ್ದರಿಂದ, ನೀವು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಬೇಕಾದರೆ, ಹೆಲ್ಮ್ ಕಾಲ್‌ಬ್ಯಾಕ್ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ, ಅದನ್ನು ಹಿಂದಿನ ಬಿಡುಗಡೆ ಆವೃತ್ತಿಗೆ ಸೂಚಿಸಿ. ರೋಲ್‌ಬ್ಯಾಕ್ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಅನುಗುಣವಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ, ಹೆಲ್ಮ್ ಅದು ಏನೆಂದು ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿದ್ದ ಸ್ಥಿತಿಗೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡುತ್ತದೆ.
ನಾವು ಚುಕ್ಕಾಣಿ ಬಳಸುವಾಗ, ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ ನಿಯಮಿತ ಸಂರಚನೆಗಳು ಟೆಂಪ್ಲೇಟ್‌ಗಳಾಗಿ ಬದಲಾಗುತ್ತವೆ, ಇದರಲ್ಲಿ ಅಸ್ಥಿರಗಳು, ಕಾರ್ಯಗಳು ಮತ್ತು ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಸಾಧ್ಯವಿದೆ. ಈ ರೀತಿಯಾಗಿ ನೀವು ಪರಿಸರವನ್ನು ಅವಲಂಬಿಸಿ ನಿಮ್ಮ ಸೇವಾ ಸಂರಚನೆಯನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಾವು ನೊಮಾಡ್‌ನೊಂದಿಗೆ ಮಾಡುವುದಕ್ಕಿಂತ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿ ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನೊಮಾಡ್‌ನಲ್ಲಿ ನಮ್ಮ ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ಅಗತ್ಯವಿರುವ ನಿಯೋಜನೆ ಸಂರಚನೆಗಳು ಮತ್ತು ಎನ್-ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಒಂದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ್ದರೆ, ಇಲ್ಲಿ ನಾವು ಅವುಗಳನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿಗಳಾಗಿ ವಿಂಗಡಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. "ನಿಯೋಜನೆ" ರೆಪೊಸಿಟರಿಯು ನಿಯೋಜನೆಗೆ ಅಗತ್ಯವಿರುವ n-ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು "ಹೆಲ್ಮ್" ರೆಪೊಸಿಟರಿಯು ಸಂರಚನೆಗಳು ಅಥವಾ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಇದು ನಮಗೆ ಏನು ಕೊಟ್ಟಿತು?
ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ನಿಜವಾಗಿಯೂ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು. ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ರಹಸ್ಯವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ, ಎಲ್ಲರಿಗೂ ಪ್ರವೇಶವನ್ನು ನೀಡಲು ನಾವು ಬಯಸದ ಕೆಲವು ವಿಷಯಗಳು ಇನ್ನೂ ಇವೆ. ಆದ್ದರಿಂದ, "ನಿಯೋಜನೆ" ರೆಪೊಸಿಟರಿಯ ಪ್ರವೇಶವು ಹೆಚ್ಚು ಸೀಮಿತವಾಗಿದೆ, ಮತ್ತು "ಚುಕ್ಕಾಣಿ" ರೆಪೊಸಿಟರಿಯು ಸೇವೆಯ ವಿವರಣೆಯನ್ನು ಹೊಂದಿದೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಇದನ್ನು ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಜನರು ಸುರಕ್ಷಿತವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು.
ನಾವು ಉತ್ಪಾದನೆಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಇತರ ಪರಿಸರಗಳನ್ನೂ ಹೊಂದಿರುವುದರಿಂದ, ಈ ಪ್ರತ್ಯೇಕತೆಗೆ ಧನ್ಯವಾದಗಳು ನಾವು ಉತ್ಪಾದನೆಗೆ ಮಾತ್ರವಲ್ಲದೆ, ಉದಾಹರಣೆಗೆ, QA ಪರಿಸರಕ್ಕೆ ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸಲು ನಮ್ಮ ಚುಕ್ಕಾಣಿ ಚಾರ್ಟ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಸ್ಥಳೀಯವಾಗಿ ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ನಿಯೋಜಿಸಲು ಸಹ ಮಿನಿಕೂಬ್ - ಇದು ಸ್ಥಳೀಯವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಚಲಾಯಿಸುವ ವಿಷಯವಾಗಿದೆ.
ಪ್ರತಿ ರೆಪೊಸಿಟರಿಯ ಒಳಗೆ, ನಾವು ಪ್ರತಿ ಸೇವೆಗೆ ಪ್ರತ್ಯೇಕ ಡೈರೆಕ್ಟರಿಗಳಾಗಿ ವಿಭಾಗವನ್ನು ಬಿಟ್ಟಿದ್ದೇವೆ. ಅಂದರೆ, ಪ್ರತಿ ಡೈರೆಕ್ಟರಿಯೊಳಗೆ ಅನುಗುಣವಾದ ಚಾರ್ಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿವೆ ಮತ್ತು ನಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಚಲಾಯಿಸಲು ನಿಯೋಜಿಸಬೇಕಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಾವು "ನಿಯೋಜನೆ" ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಕೇವಲ envs ಅನ್ನು ಬಿಟ್ಟಿದ್ದೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಜಿಂಜಾವನ್ನು ಬಳಸಿಕೊಂಡು ಟೆಂಪ್ಲೇಟಿಂಗ್ ಅನ್ನು ಬಳಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ಹೆಲ್ಮ್ ಸ್ವತಃ ಪೆಟ್ಟಿಗೆಯ ಹೊರಗೆ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ - ಇದು ಅದರ ಮುಖ್ಯ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.
ನಾವು ನಿಯೋಜನೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಿಟ್ಟಿದ್ದೇವೆ - deploy.sh, ಇದು ಚುಕ್ಕಾಣಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿಯೋಜನೆಗಾಗಿ ಉಡಾವಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಮಾಣೀಕರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಿಯೋಜಿಸಲು ಬಯಸುವ ಯಾರಿಗಾದರೂ, ನಿಯೋಜನೆ ಇಂಟರ್ಫೇಸ್ ನೊಮಾಡ್ ಮೂಲಕ ನಿಯೋಜಿಸುವಾಗ ಮಾಡಿದಂತೆಯೇ ಕಾಣುತ್ತದೆ. ಅದೇ deploy.sh, ನಿಮ್ಮ ಸೇವೆಯ ಹೆಸರು ಮತ್ತು ನೀವು ಅದನ್ನು ಎಲ್ಲಿ ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ. ಇದು ಚುಕ್ಕಾಣಿಯನ್ನು ಆಂತರಿಕವಾಗಿ ಪ್ರಾರಂಭಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಪ್ರತಿಯಾಗಿ, ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಂದ ಸಂರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಅಗತ್ಯವಾದ ಮೌಲ್ಯಗಳ ಫೈಲ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ನಂತರ ಅವುಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ಸಂಶೋಧನೆಗಳು
ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯು ಅಲೆಮಾರಿಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ಇಲ್ಲಿ ಹೊರಹೋಗುವ ಸಂಚಾರ ಪ್ರವೇಶಕ್ಕೆ ಬರುತ್ತದೆ. ಇದು ಕೇವಲ ಮುಂಭಾಗದ ನಿಯಂತ್ರಕವಾಗಿದೆ, ಇದು ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಂತರ ವಿನಂತಿಯ ಡೇಟಾಗೆ ಅನುಗುಣವಾದ ಸೇವೆಗಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಚುಕ್ಕಾಣಿಯಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿವರಣೆಯ ಭಾಗವಾಗಿರುವ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮದೇ ಆದ ಮೇಲೆ ಹೊಂದಿಸುವ ಸಂರಚನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಇದು ಅವುಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸೇವೆಯು ತನ್ನ ಪಾಡ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಅಂದರೆ, ನಿರ್ದಿಷ್ಟ ಕಂಟೈನರ್‌ಗಳು, ಈ ಸೇವೆಗೆ ಸೇರಿದ ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳ ನಡುವೆ ಒಳಬರುವ ದಟ್ಟಣೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುತ್ತದೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ನಾವು ನೆಟ್ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ಭದ್ರತೆಯಿಂದ ಎಲ್ಲಿಯೂ ಹೋಗಬಾರದು ಎಂದು ನಾವು ಮರೆಯಬಾರದು. ಆದ್ದರಿಂದ, ವಿಭಾಗೀಕರಣವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಟ್ಯಾಗಿಂಗ್ ಅನ್ನು ಆಧರಿಸಿದೆ. ಎಲ್ಲಾ ಸೇವೆಗಳು ಕೆಲವು ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದು, ಕ್ಲಸ್ಟರ್‌ನ ಒಳಗೆ ಅಥವಾ ಹೊರಗೆ ಕೆಲವು ಬಾಹ್ಯ/ಆಂತರಿಕ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸೇವೆಗಳ ಪ್ರವೇಶ ಹಕ್ಕುಗಳು ಸಂಬಂಧಿಸಿವೆ.
ನಾವು ಸ್ಥಿತ್ಯಂತರವನ್ನು ಮಾಡುತ್ತಿದ್ದಂತೆ, ನಾವು ಹಿಂದೆ ಬಳಸಿದ ನೊಮಾಡ್‌ನ ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಹೊಂದಿದ್ದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಬಹಳಷ್ಟು ಹೊಸ ವಿಷಯಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಇದನ್ನು ಪ್ಲಗಿನ್‌ಗಳ ಮೂಲಕ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರಗಳ ಮೂಲಕ ವಿಸ್ತರಿಸಬಹುದು. ಅಂದರೆ, ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಕುಬರ್ನೆಟ್‌ಗಳೊಂದಿಗೆ ಬರುವ ಯಾವುದನ್ನಾದರೂ ಬಳಸಲು ನಿಮಗೆ ಅವಕಾಶವಿದೆ, ಆದರೆ ನಿಮ್ಮ ಸಂಪನ್ಮೂಲವನ್ನು ಓದುವ ನಿಮ್ಮ ಸ್ವಂತ ಸಂಪನ್ಮೂಲ ಮತ್ತು ಸೇವೆಯನ್ನು ರಚಿಸಲು. ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸದೆಯೇ ಮತ್ತು ಮಾರ್ಪಾಡುಗಳ ಅಗತ್ಯವಿಲ್ಲದೇ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿಸ್ತರಿಸಲು ಇದು ನಿಮಗೆ ಹೆಚ್ಚುವರಿ ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ.
ಅಂತಹ ಬಳಕೆಯ ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಒಳಗೆ ಚಲಿಸುವ ಪ್ರೊಮೆಥಿಯಸ್. ನಿರ್ದಿಷ್ಟ ಸೇವೆಯಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಸೇವಾ ವಿವರಣೆಗೆ ನಾವು ಹೆಚ್ಚುವರಿ ರೀತಿಯ ಸಂಪನ್ಮೂಲವನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ, ಸೇವೆಯ ಮಾನಿಟರ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಪ್ರಮೀತಿಯಸ್, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದಾಗ ಅದು ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರವನ್ನು ಓದಬಹುದು ಎಂಬ ಅಂಶದಿಂದಾಗಿ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಸ ಸಿಸ್ಟಮ್‌ನಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದು ಸಾಕಷ್ಟು ಅನುಕೂಲಕರವಾಗಿದೆ.
ನಾವು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಮೊದಲ ನಿಯೋಜನೆಯನ್ನು ಮಾರ್ಚ್ 2018 ರಲ್ಲಿ ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಅದರೊಂದಿಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಅನುಭವಿಸಲಿಲ್ಲ. ಗಮನಾರ್ಹ ದೋಷಗಳಿಲ್ಲದೆ ಇದು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಜೊತೆಗೆ, ನಾವು ಅದನ್ನು ಮತ್ತಷ್ಟು ವಿಸ್ತರಿಸಬಹುದು. ಇಂದು ನಾವು ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ನ ಅಭಿವೃದ್ಧಿಯ ವೇಗವನ್ನು ನಾವು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇವೆ. ಪ್ರಸ್ತುತ, 3000 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಂಟೈನರ್‌ಗಳು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿವೆ. ಕ್ಲಸ್ಟರ್ ಹಲವಾರು ನೋಡ್ಗಳನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಸೇವೆಯ, ಸ್ಥಿರ ಮತ್ತು ಬಹಳ ನಿಯಂತ್ರಿಸಬಲ್ಲದು.
ಮೂಲ: www.habr.com