ಇಂದು ನಾನು ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೇಗೆ ಬರೆಯಬೇಕು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯತೆಗಳು ಯಾವುವು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡಲು ನಾನು ಯೋಜಿಸುತ್ತೇನೆ. ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಯಾವುದೇ ತಲೆನೋವುಗಳಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಅದರ ಸುತ್ತಲೂ ಯಾವುದೇ "ಕ್ರ್ಯಾಚ್‌ಗಳನ್ನು" ಆವಿಷ್ಕರಿಸಲು ಮತ್ತು ನಿರ್ಮಿಸಬೇಕಾಗಿಲ್ಲ - ಮತ್ತು ಎಲ್ಲವೂ ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ಉದ್ದೇಶಿಸಿರುವ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಈ ಉಪನ್ಯಾಸವು "" ಸಂಜೆ ಶಾಲೆಯ ಮುಕ್ತ ಸೈದ್ಧಾಂತಿಕ ಉಪನ್ಯಾಸಗಳನ್ನು ನೀವು ವೀಕ್ಷಿಸಬಹುದು . ವೀಡಿಯೊಗಿಂತ ಪಠ್ಯವನ್ನು ಆದ್ಯತೆ ನೀಡುವವರಿಗೆ, ನಾವು ಈ ಲೇಖನವನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ.
ನನ್ನ ಹೆಸರು ಪಾವೆಲ್ ಸೆಲಿವನೋವ್, ಪ್ರಸ್ತುತ ನಾನು Mail.ru ಕ್ಲೌಡ್ ಸೊಲ್ಯೂಷನ್ಸ್‌ನಲ್ಲಿ ಪ್ರಮುಖ DevOps ಇಂಜಿನಿಯರ್ ಆಗಿದ್ದೇನೆ, ನಾವು ಮೋಡಗಳನ್ನು ತಯಾರಿಸುತ್ತೇವೆ, ನಾವು ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಹೀಗೆ. ನನ್ನ ಕಾರ್ಯಗಳು ಈಗ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಹಾಯವನ್ನು ಒಳಗೊಂಡಿವೆ, ಈ ಮೋಡಗಳನ್ನು ಹೊರತರುವುದು, ನಾವು ಬರೆಯುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೊರತರುವುದು ಮತ್ತು ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ನಾವು ಒದಗಿಸುವ ಸಾಧನಗಳನ್ನು ನೇರವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು.
ನಾನು DevOps ಮಾಡುತ್ತಿದ್ದೇನೆ, ಕಳೆದ, ಬಹುಶಃ, ಮೂರು ವರ್ಷಗಳಿಂದ ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದರೆ, ತಾತ್ವಿಕವಾಗಿ, ನಾನು ಈಗ ಸುಮಾರು ಐದು ವರ್ಷಗಳಿಂದ DevOps ಮಾಡುವುದನ್ನು ಮಾಡುತ್ತಿದ್ದೇನೆ. ಅದಕ್ಕೂ ಮೊದಲು, ನಾನು ಹೆಚ್ಚಾಗಿ ನಿರ್ವಾಹಕರ ವಿಷಯಗಳಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದೆ. ನಾನು ಬಹಳ ಹಿಂದೆಯೇ ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ - ಬಹುಶಃ ನಾನು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ ಸುಮಾರು ನಾಲ್ಕು ವರ್ಷಗಳು ಕಳೆದಿವೆ.
ಸಾಮಾನ್ಯವಾಗಿ, ನಾನು ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿ 1.3 ಆಗಿದ್ದಾಗ ಪ್ರಾರಂಭಿಸಿದೆ, ಬಹುಶಃ, ಮತ್ತು ಬಹುಶಃ 1.2 - ಅದು ಇನ್ನೂ ಶೈಶವಾವಸ್ಥೆಯಲ್ಲಿದ್ದಾಗ. ಈಗ ಅದು ಶೈಶವಾವಸ್ಥೆಯಲ್ಲಿಲ್ಲ - ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಮಾಡಲು ಬಯಸುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಭಾರಿ ಬೇಡಿಕೆಯಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಮತ್ತು ಅಂತಹ ಜನರಿಗೆ ಕಂಪನಿಗಳು ಹೆಚ್ಚಿನ ಬೇಡಿಕೆಯನ್ನು ಹೊಂದಿವೆ. ಆದ್ದರಿಂದ, ವಾಸ್ತವವಾಗಿ, ಈ ಉಪನ್ಯಾಸ ಕಾಣಿಸಿಕೊಂಡಿತು.
ನಾನು ಏನು ಮಾತನಾಡುತ್ತೇನೆ ಎಂಬ ಯೋಜನೆಯ ಪ್ರಕಾರ ನಾವು ಮಾತನಾಡಿದರೆ, ಅದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ, ಬ್ರಾಕೆಟ್‌ಗಳಲ್ಲಿ ಇದನ್ನು ಬರೆಯಲಾಗಿದೆ (ಟಿಎಲ್; ಡಿಆರ್) - “ತುಂಬಾ ಉದ್ದವಾಗಿದೆ; ಓದಬೇಡ". ಇಂದು ನನ್ನ ಪ್ರಸ್ತುತಿಯು ಅಂತ್ಯವಿಲ್ಲದ ಪಟ್ಟಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ವಾಸ್ತವವಾಗಿ, ಅಂತಹ ಪ್ರಸ್ತುತಿಗಳನ್ನು ತಯಾರಿಸಿದಾಗ ನಾನೇ ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಅಂತಹ ವಿಷಯವಾಗಿದೆ, ನಾನು ಈ ಪ್ರಸ್ತುತಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ, ಈ ಮಾಹಿತಿಯನ್ನು ವಿಭಿನ್ನವಾಗಿ ಹೇಗೆ ಸಂಘಟಿಸುವುದು ಎಂದು ನಾನು ನಿಜವಾಗಿಯೂ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಿಲ್ಲ.
ಏಕೆಂದರೆ, ಒಟ್ಟಾರೆಯಾಗಿ, ಈ ಮಾಹಿತಿಯು “ctrl+c, ctrl+v” ಆಗಿದೆ, ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, DevOps ವಿಭಾಗದಲ್ಲಿನ ನಮ್ಮ ವಿಕಿ, ಅಲ್ಲಿ ನಾವು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅವಶ್ಯಕತೆಗಳನ್ನು ಬರೆದಿದ್ದೇವೆ: “ಹುಡುಗರೇ, ನಾವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಕುಬರ್ನೆಟ್ಸ್, ಇದು ಹೀಗಿರಬೇಕು."
ಅದಕ್ಕಾಗಿಯೇ ಪ್ರಸ್ತುತಿ ದೊಡ್ಡ ಪಟ್ಟಿಯಾಗಿ ಹೊರಹೊಮ್ಮಿತು. ಕ್ಷಮಿಸಿ. ಸಾಧ್ಯವಾದರೆ ಬೇಸರವಾಗದಂತೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹೇಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ನಾವು ಈಗ ಏನು ನೋಡಲಿದ್ದೇವೆ:
- ಇವುಗಳು, ಮೊದಲನೆಯದಾಗಿ, ಲಾಗ್‌ಗಳು (ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್‌ಗಳು?), ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅವುಗಳನ್ನು ಏನು ಮಾಡಬೇಕು, ಅವುಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು, ಅವು ಏನಾಗಿರಬೇಕು;
- ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿನ ಕಾನ್ಫಿಗರೇಶನ್ಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು, ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಉತ್ತಮ ಮತ್ತು ಕೆಟ್ಟ ಮಾರ್ಗಗಳು ಯಾವುವು;
- ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರವೇಶಿಸುವಿಕೆ ಪರಿಶೀಲನೆಗಳು ಯಾವುವು, ಅವುಗಳು ಹೇಗಿರಬೇಕು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ;
- ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ ಏನು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ;
- ಮತ್ತೆ ಸಂಪನ್ಮೂಲಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ;
- ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ವಿಷಯವನ್ನು ಮತ್ತೊಮ್ಮೆ ಸ್ಪರ್ಶಿಸೋಣ;
- ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಈ ನಿಗೂಢ ಕ್ಲೌಡ್-ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್ ಎಂಬ ಪದವನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. Cloudnativeness, ಈ ಪದದ ವಿಶೇಷಣವಾಗಿ.
ದಾಖಲೆಗಳು
ಲಾಗ್ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ - ಈ ಲಾಗ್ಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಎಲ್ಲಿ ತಳ್ಳಬೇಕು. ಈಗ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೀರಿ. ಕ್ಲಾಸಿಕ್ಸ್ ಪ್ರಕಾರ, ಹಿಂದಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಯಾವಾಗಲೂ ಫೈಲ್‌ನಲ್ಲಿ ಎಲ್ಲೋ ಲಾಗ್ಗಳನ್ನು ಬರೆಯುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಡೆವಲಪರ್‌ನ ಹೋಮ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ ಫೈಲ್‌ಗೆ ಕೆಟ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಲಾಗ್ಗಳನ್ನು ಬರೆದವು. ಉತ್ತಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಎಲ್ಲೋ ಫೈಲ್‌ಗೆ ಲಾಗ್ಗಳನ್ನು ಬರೆದಿವೆ /var/log.
ಅಂತೆಯೇ, ಮುಂದೆ, ಉತ್ತಮ ನಿರ್ವಾಹಕರು ತಮ್ಮ ಮೂಲಸೌಕರ್ಯಗಳಲ್ಲಿ ಈ ಲಾಗ್ಗಳನ್ನು ತಿರುಗಿಸಬಹುದಾದ ಕೆಲವು ವಿಷಯಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ - ಅದೇ rsyslog, ಈ ಲಾಗ್ಗಳನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಏನಾದರೂ ಸಂಭವಿಸಿದಾಗ, ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ, ಅದು ಬ್ಯಾಕಪ್ ಪ್ರತಿಗಳನ್ನು ರಚಿಸುತ್ತದೆ , ಲಾಗ್ಗಳನ್ನು ಅಲ್ಲಿ ಇರಿಸುತ್ತದೆ , ಹಳೆಯ ಫೈಲ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ, ಒಂದು ವಾರಕ್ಕಿಂತ ಹೆಚ್ಚು, ಆರು ತಿಂಗಳುಗಳು ಮತ್ತು ಇನ್ನೂ ಕೆಲವು. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ನಾವು ನಿಬಂಧನೆಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್ಗಳನ್ನು ಬರೆಯುವುದರಿಂದ, ಉತ್ಪಾದನಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಸ್ಥಳವು (ಯುದ್ಧ ಸರ್ವರ್‌ಗಳು?) ಖಾಲಿಯಾಗುವುದಿಲ್ಲ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ದಾಖಲೆಗಳ ಕಾರಣದಿಂದಾಗಿ ಸಂಪೂರ್ಣ ಉತ್ಪಾದನೆಯು ನಿಲ್ಲಲಿಲ್ಲ.
ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಜಗತ್ತಿಗೆ ತೆರಳಿದಾಗ ಮತ್ತು ಅಲ್ಲಿ ಅದೇ ವಿಷಯವನ್ನು ಚಲಾಯಿಸಿದಾಗ, ನೀವು ಗಮನ ಹರಿಸಬಹುದಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಜನರು ಫೈಲ್‌ನಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಬರೆದಂತೆ, ಅವುಗಳನ್ನು ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ.
ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ಡಾಕರ್ ಕಂಟೇನರ್‌ನಿಂದ ಎಲ್ಲೋ ಲಾಗ್ಗಳನ್ನು ಬರೆಯಲು ಸರಿಯಾದ ಸ್ಥಳವೆಂದರೆ ಅವುಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ Stdout/Stderr ಎಂದು ಕರೆಯುವವರೆಗೆ ಬರೆಯುವುದು, ಅಂದರೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಪ್ರಮಾಣಿತ ಔಟ್ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳು, ಪ್ರಮಾಣಿತ ದೋಷ ಔಟ್ಪುಟ್. ಡಾಕರ್‌ನಲ್ಲಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕುಬರ್ನೆಟಿಸ್‌ನಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ತಾತ್ವಿಕವಾಗಿ ಹಾಕಲು ಇದು ಅತ್ಯಂತ ಸರಿಯಾದ, ಸರಳ ಮತ್ತು ಅತ್ಯಂತ ತಾರ್ಕಿಕ ಮಾರ್ಗವಾಗಿದೆ. ಏಕೆಂದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ Stdout/Stderr ಗೆ ಲಾಗ್ಗಳನ್ನು ಬರೆದರೆ, ಈ ಲಾಗ್ಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಡಾಕರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಆಡ್-ಆನ್‌ಗೆ ಬಿಟ್ಟದ್ದು. ಡಾಕರ್ ಡೀಫಾಲ್ಟ್ ಆಗಿ ತನ್ನ ವಿಶೇಷ ಫೈಲ್‌ಗಳನ್ನು JSON ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತದೆ.
ಇಲ್ಲಿ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ, ಈ ಲಾಗ್ಗಳೊಂದಿಗೆ ನೀವು ಮುಂದೆ ಏನು ಮಾಡುತ್ತೀರಿ? ಸುಲಭವಾದ ಮಾರ್ಗವು ಸ್ಪಷ್ಟವಾಗಿದೆ, ನಾವು ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ kubectl logs ಮತ್ತು ಈ "ಪಾಡ್‌ಗಳ" ಲಾಗ್ಗಳನ್ನು ನೋಡಿ. ಆದರೆ, ಬಹುಶಃ, ಇದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿಲ್ಲ - ಲಾಗ್ಗಳೊಂದಿಗೆ ಬೇರೆ ಏನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ.
ಸದ್ಯಕ್ಕೆ, ನಾವು ಲಾಗ್ಗಳ ವಿಷಯದ ಬಗ್ಗೆ ಸ್ಪರ್ಶಿಸಿರುವುದರಿಂದ, ಲಾಗ್‌ಗಳಂತಹ ವಿಷಯದ ಬಗ್ಗೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಮಾತನಾಡೋಣ. ಅಂದರೆ, ಇದು ನೇರವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಲಾಗ್ಗಳೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಈ ಬಗ್ಗೆಯೂ ಯೋಚಿಸುವುದು ಒಳ್ಳೆಯದು.
ನಮಗೆ ಸೌಹಾರ್ದಯುತ ರೀತಿಯಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಸಾಧನ ಬೇಕು, ಅದು ನಮ್ಮ ಡಾಕರ್ ತನ್ನ ಫೈಲ್‌ಗಳಲ್ಲಿ ಇರಿಸುವ ಈ ಲಾಗ್ಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಎಲ್ಲೋ ಕಳುಹಿಸುತ್ತದೆ. ದೊಡ್ಡದಾಗಿ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್‌ನೊಳಗೆ ಕೆಲವು ರೀತಿಯ ಏಜೆಂಟ್ ಅನ್ನು ಡೇಮನ್‌ಸೆಟ್ ರೂಪದಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ - ಲಾಗ್ ಕಲೆಕ್ಟರ್, ಡಾಕರ್ ಸಂಗ್ರಹಿಸುವ ಲಾಗ್‌ಗಳು ಎಲ್ಲಿವೆ ಎಂದು ಸರಳವಾಗಿ ಹೇಳಲಾಗುತ್ತದೆ. ಮತ್ತು ಈ ಸಂಗ್ರಹಿಸುವ ಏಜೆಂಟ್ ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಬಹುಶಃ ಹೇಗಾದರೂ ಅವುಗಳನ್ನು ದಾರಿಯುದ್ದಕ್ಕೂ ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, ಬಹುಶಃ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಮೆಟಾ-ಮಾಹಿತಿಯೊಂದಿಗೆ ಅವುಗಳನ್ನು ಪುಷ್ಟೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಅವುಗಳನ್ನು ಎಲ್ಲೋ ಶೇಖರಣೆಗಾಗಿ ಕಳುಹಿಸುತ್ತದೆ. ಅಲ್ಲಿ ಮಾರ್ಪಾಡುಗಳು ಈಗಾಗಲೇ ಸಾಧ್ಯ. ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದದ್ದು ಬಹುಶಃ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವಾಗಿದೆ, ಅಲ್ಲಿ ನೀವು ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಅಲ್ಲಿಂದ ನೀವು ಅವುಗಳನ್ನು ಅನುಕೂಲಕರವಾಗಿ ಹಿಂಪಡೆಯಬಹುದು. ನಂತರ, ವಿನಂತಿಯನ್ನು ಬಳಸಿ, ಕಿಬಾನಾ ಬಳಸಿ, ಉದಾಹರಣೆಗೆ, ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿ, ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ಮಿಸಿ, ಇತ್ಯಾದಿ.
ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಚಾರವೆಂದರೆ, ನಾನು ಅದನ್ನು ಮತ್ತೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸಲು ಬಯಸುತ್ತೇನೆ, ಡಾಕರ್ ಒಳಗೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ, ನಿಮ್ಮ ಲಾಗ್ಗಳನ್ನು ಫೈಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು ತುಂಬಾ ಕೆಟ್ಟ ಆಲೋಚನೆಯಾಗಿದೆ.
ಏಕೆಂದರೆ ಮೊದಲನೆಯದಾಗಿ, ಫೈಲ್‌ನಲ್ಲಿ ಕಂಟೇನರ್‌ನೊಳಗೆ ಲಾಗ್ಗಳನ್ನು ಪಡೆಯುವುದು ಕಷ್ಟ. ನೀವು ಮೊದಲು ಕಂಟೇನರ್‌ಗೆ ಹೋಗಬೇಕು, ಅಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಿ, ತದನಂತರ ಲಾಗ್ಗಳನ್ನು ನೋಡಬೇಕು. ಮುಂದಿನ ಅಂಶವೆಂದರೆ ನೀವು ಫೈಲ್‌ನಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕಂಟೇನರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕನಿಷ್ಠ ಪರಿಸರವನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಲಾಗ್ಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಕೆಲಸಕ್ಕಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಉಪಯುಕ್ತತೆಗಳಿಲ್ಲ. ಅವುಗಳನ್ನು ಸಮಾಧಿ ಮಾಡಿ, ಅವುಗಳನ್ನು ನೋಡಿ, ಅವುಗಳನ್ನು ಪಠ್ಯ ಸಂಪಾದಕದಲ್ಲಿ ತೆರೆಯಿರಿ. ಮುಂದಿನ ಕ್ಷಣದಲ್ಲಿ ನಾವು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಫೈಲ್‌ನಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ಈ ಕಂಟೇನರ್ ಅನ್ನು ಅಳಿಸಿದರೆ, ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ, ಅದರೊಂದಿಗೆ ಲಾಗ್‌ಗಳು ಸಾಯುತ್ತವೆ. ಅಂತೆಯೇ, ಕಂಟೇನರ್‌ನ ಯಾವುದೇ ಮರುಪ್ರಾರಂಭವು ಯಾವುದೇ ಲಾಗ್‌ಗಳಿಲ್ಲ ಎಂದರ್ಥ. ಮತ್ತೆ, ಕೆಟ್ಟ ಆಯ್ಕೆ.
ಮತ್ತು ಕೊನೆಯ ಅಂಶವೆಂದರೆ ಧಾರಕಗಳ ಒಳಗೆ ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಅಷ್ಟೆ - ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಏಕೈಕ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ನಿಮ್ಮ ಲಾಗ್ಗಳೊಂದಿಗೆ ಫೈಲ್‌ಗಳನ್ನು ತಿರುಗಿಸುವ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಯ ಕುರಿತು ಯಾವುದೇ ಚರ್ಚೆ ಇಲ್ಲ. ಲಾಗ್ಗಳನ್ನು ಫೈಲ್‌ಗೆ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣ, ಇದರರ್ಥ, ಕ್ಷಮಿಸಿ, ನಾವು ಉತ್ಪಾದನಾ ಸರ್ವರ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಏಕೆಂದರೆ, ಮೊದಲನೆಯದಾಗಿ, ಅವುಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ, ಯಾರೂ ಅವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದಿಲ್ಲ, ಜೊತೆಗೆ ಯಾರೂ ಅವುಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ - ಅದರ ಪ್ರಕಾರ, ಸರ್ವರ್‌ನಲ್ಲಿನ ಸ್ಥಳವು ಖಾಲಿಯಾಗುವವರೆಗೆ ಫೈಲ್ ಅನಂತವಾಗಿ ಬೆಳೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ, ಡಾಕರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಫೈಲ್‌ಗೆ ಲಾಗಿನ್ ಮಾಡುವುದು ಕೆಟ್ಟ ಕಲ್ಪನೆ ಎಂದು ನಾನು ಮತ್ತೊಮ್ಮೆ ಹೇಳುತ್ತೇನೆ.
ಮುಂದಿನ ಹಂತ, ಇಲ್ಲಿ ನಾನು ಈ ಬಗ್ಗೆ ಮತ್ತೊಮ್ಮೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ - ನಾವು ಲಾಗ್ಗಳ ವಿಷಯದ ಮೇಲೆ ಸ್ಪರ್ಶಿಸುತ್ತಿರುವುದರಿಂದ, ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅನುಕೂಲಕರವಾಗುವಂತೆ ಲಾಗ್‌ಗಳು ಹೇಗೆ ಕಾಣಬೇಕು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುವುದು ಒಳ್ಳೆಯದು. ನಾನು ಹೇಳಿದಂತೆ, ವಿಷಯವು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸಿಲ್ಲ, ಆದರೆ ಇದು DevOps ವಿಷಯಕ್ಕೆ ಚೆನ್ನಾಗಿ ಸಂಬಂಧಿಸಿದೆ. ಅಭಿವೃದ್ಧಿ ಸಂಸ್ಕೃತಿ ಮತ್ತು ಈ ಎರಡು ವಿಭಿನ್ನ ಇಲಾಖೆಗಳ ನಡುವಿನ ಸ್ನೇಹದ ವಿಷಯದ ಕುರಿತು - ದೇವ್ ಮತ್ತು ಆಪ್ಸ್, ಇದರಿಂದ ಎಲ್ಲರೂ ಆರಾಮದಾಯಕವಾಗಿದ್ದಾರೆ.
ಇದರರ್ಥ ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಇಂದು, ಲಾಗ್ಗಳನ್ನು JSON ಸ್ವರೂಪದಲ್ಲಿ ಬರೆಯಬೇಕು. ನಿಮ್ಮದೇ ಆದ ಕೆಲವು ಗ್ರಹಿಸಲಾಗದ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನೀವು ಹೊಂದಿದ್ದರೆ, ಅದು ಗ್ರಹಿಸಲಾಗದ ಸ್ವರೂಪಗಳಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಬರೆಯುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ಕೆಲವು ರೀತಿಯ ಮುದ್ರಣವನ್ನು ಅಥವಾ ಅಂತಹದನ್ನು ಸೇರಿಸಿದರೆ, ಸಾಮಾನ್ಯ ಲಾಗಿಂಗ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಕೆಲವು ರೀತಿಯ ಫ್ರೇಮ್‌ವರ್ಕ್, ಕೆಲವು ರೀತಿಯ ಹೊದಿಕೆಯನ್ನು ಗೂಗಲ್ ಮಾಡುವ ಸಮಯ; ಅಲ್ಲಿ JSON ನಲ್ಲಿ ಲಾಗಿಂಗ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ಏಕೆಂದರೆ JSON ಸರಳ ಸ್ವರೂಪವಾಗಿದೆ, ಅದನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡುವುದು ಸರಳವಾಗಿದೆ.
ನಿಮ್ಮ JSON ಕೆಲವು ಮಾನದಂಡಗಳ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ, ಯಾರಿಗೂ ಏನು ತಿಳಿದಿಲ್ಲ, ನಂತರ ಪಾರ್ಸ್ ಮಾಡಬಹುದಾದ ಸ್ವರೂಪದಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಬರೆಯಿರಿ. ಇಲ್ಲಿ, ಬದಲಿಗೆ, ನೀವು ಧಾರಕಗಳ ಗುಂಪನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ ಅಥವಾ nginx ನೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ಲಾಗಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ನಿಮಗೆ ತುಂಬಾ ಅನಾನುಕೂಲವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಅವುಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ. ಏಕೆಂದರೆ ಪ್ರತಿ ಹೊಸ nginx ನಿದರ್ಶನಕ್ಕೆ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಪಾರ್ಸರ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ, ಏಕೆಂದರೆ ಅವರು ಲಾಗ್ಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಬರೆಯುತ್ತಾರೆ. ಮತ್ತೊಮ್ಮೆ, ಈ ಎಲ್ಲಾ nginx ನಿದರ್ಶನಗಳು ಒಂದೇ ಲಾಗಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಅವುಗಳ ಎಲ್ಲಾ ಲಾಗ್ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಏಕರೂಪವಾಗಿ ಬರೆಯಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ.
ಕೊನೆಯಲ್ಲಿ, ನಾನು ಬೆಂಕಿಗೆ ಇಂಧನವನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೇನೆ, ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಬಹು-ಸಾಲಿನ ಸ್ವರೂಪದ ಲಾಗ್ಗಳನ್ನು ತಪ್ಪಿಸಬೇಕು. ಇಲ್ಲಿ ವಿಷಯ ಇಲ್ಲಿದೆ, ನೀವು ಎಂದಾದರೂ ಲಾಗ್ ಸಂಗ್ರಾಹಕರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದರೆ, ಅವರು ನಿಮಗೆ ಏನು ಭರವಸೆ ನೀಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದ್ದೀರಿ, ಅವರು ಬಹು-ಸಾಲಿನ ಲಾಗ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು, ಅವುಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಬೇಕು ಎಂದು ತಿಳಿಯಿರಿ ಮತ್ತು ಹೀಗೆ. ವಾಸ್ತವವಾಗಿ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇಂದು ಒಂದೇ ಸಂಗ್ರಾಹಕ ಬಹು-ಸಾಲಿನ ಲಾಗ್ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ, ಸಂಪೂರ್ಣವಾಗಿ ಮತ್ತು ದೋಷಗಳಿಲ್ಲದೆ ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮಾನವ ರೀತಿಯಲ್ಲಿ, ಇದು ಅನುಕೂಲಕರ ಮತ್ತು ದೋಷ-ಮುಕ್ತವಾಗಿದೆ.
ಆದರೆ ಸ್ಟಾಕ್ ಟ್ರೇಸ್ ಯಾವಾಗಲೂ ಬಹು-ಸಾಲಿನ ದಾಖಲೆಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ತಪ್ಪಿಸುವುದು. ಇಲ್ಲಿರುವ ಪ್ರಶ್ನೆಯೆಂದರೆ, ಲಾಗ್ ಈವೆಂಟ್‌ನ ದಾಖಲೆಯಾಗಿದೆ ಮತ್ತು ಸ್ಟ್ಯಾಕ್ಟ್ರೇಸ್ ವಾಸ್ತವವಾಗಿ ಲಾಗ್ ಅಲ್ಲ. ನಾವು ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಅವುಗಳನ್ನು ಎಲ್ಲೋ ಇಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್‌ನಲ್ಲಿ ಇರಿಸಿ ನಂತರ ಅವುಗಳಿಂದ ಗ್ರಾಫ್‌ಗಳನ್ನು ರಚಿಸಿದರೆ, ನಿಮ್ಮ ಸೈಟ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರ ಚಟುವಟಿಕೆಯ ಕೆಲವು ವರದಿಗಳನ್ನು ನಿರ್ಮಿಸಿದರೆ, ನಂತರ ನೀವು ಸ್ಟಾಕ್ ಟ್ರೇಸ್ ಅನ್ನು ಪಡೆದಾಗ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಯಾವುದೋ ಅನಿರೀಕ್ಷಿತ ಪರಿಸ್ಥಿತಿ ನಡೆಯುತ್ತಿದೆ ಎಂದರ್ಥ. ಮತ್ತು ಸ್ಟಾಕ್ ಟ್ರೇಸ್ ಅನ್ನು ಎಲ್ಲೋ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅವುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದಾದ ಸಿಸ್ಟಮ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.
ಇದು ಸಾಫ್ಟ್‌ವೇರ್ (ಅದೇ ಸೆಂಟ್ರಿ) ಇದನ್ನು ಸ್ಟಾಕ್ ಟ್ರೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಿರ್ದಿಷ್ಟವಾಗಿ ತಯಾರಿಸಲಾಗುತ್ತದೆ. ಇದು ತಕ್ಷಣವೇ ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯಗಳನ್ನು ರಚಿಸಬಹುದು, ಅವುಗಳನ್ನು ಯಾರಿಗಾದರೂ ನಿಯೋಜಿಸಬಹುದು, ಸ್ಟ್ಯಾಕ್ಟ್ರೇಸ್ಗಳು ಸಂಭವಿಸಿದಾಗ ಎಚ್ಚರಿಸಬಹುದು, ಈ ಸ್ಟ್ಯಾಕ್ಟ್ರೇಸ್ಗಳನ್ನು ಒಂದು ಪ್ರಕಾರದ ಮೂಲಕ ಗುಂಪು ಮಾಡಬಹುದು, ಇತ್ಯಾದಿ. ತಾತ್ವಿಕವಾಗಿ, ನಾವು ಲಾಗ್ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ ಸ್ಟ್ಯಾಕ್ಟ್ರೇಸ್ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಹೆಚ್ಚು ಅರ್ಥವಿಲ್ಲ, ಏಕೆಂದರೆ ಇವುಗಳು ಎಲ್ಲಾ ನಂತರ, ವಿಭಿನ್ನ ಉದ್ದೇಶಗಳೊಂದಿಗೆ ವಿಭಿನ್ನ ವಿಷಯಗಳಾಗಿವೆ.
ಸಂರಚನೆ
ಮುಂದೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ: ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ಸಾಮಾನ್ಯವಾಗಿ, ಡಾಕರ್ ಧಾರಕಗಳ ಬಗ್ಗೆ ಅಲ್ಲ ಎಂದು ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುತ್ತೇನೆ. ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳ ಬಗ್ಗೆ ಎಲ್ಲರಿಗೂ ತಿಳಿದಿದೆ, ಡಾಕರ್‌ನೊಂದಿಗೆ ಹೆಚ್ಚು ಕೆಲಸ ಮಾಡದವರೂ ಸಹ. ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ, ಡಾಕರ್ ಪಾತ್ರೆಗಳ ಬಗ್ಗೆ ಅಲ್ಲ.
ಡಾಕರ್, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಮಾನದಂಡಗಳ ಬಗ್ಗೆ. ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಎಲ್ಲದಕ್ಕೂ ಮಾನದಂಡಗಳಿವೆ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಮಾನದಂಡಗಳು, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮಾನದಂಡಗಳು.
ಮತ್ತು ಈ ವಿಷಯ - ನಾವು ಇದನ್ನು ಮೊದಲು ಬಳಸಿದ್ದೇವೆ, ಇದು ಧಾರಕಗಳ ಆಗಮನದೊಂದಿಗೆ ವಿಶೇಷವಾಗಿ ಜನಪ್ರಿಯವಾಯಿತು - ಈ ವಿಷಯವನ್ನು ENV (ಪರಿಸರ) ಅಸ್ಥಿರ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಅಂದರೆ, ನಿಮ್ಮ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನಲ್ಲಿರುವ ಪರಿಸರ ಅಸ್ಥಿರಗಳು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸೂಕ್ತವಾದ ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು JAVA, Python, Go, Perl, God forbid ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅವರೆಲ್ಲರೂ ಡೇಟಾಬೇಸ್ ಹೋಸ್ಟ್, ಡೇಟಾಬೇಸ್ ಬಳಕೆದಾರ, ಡೇಟಾಬೇಸ್ ಪಾಸ್‌ವರ್ಡ್ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಓದಬಹುದು, ಆಗ ಅದು ಸೂಕ್ತವಾಗಿದೆ. ಡೇಟಾಬೇಸ್ ಯೋಜನೆಯಲ್ಲಿ ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ನಾಲ್ಕು ವಿಭಿನ್ನ ಭಾಷೆಗಳಲ್ಲಿ ನೀವು ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಹೆಚ್ಚು ವಿಭಿನ್ನ ಸಂರಚನೆಗಳಿಲ್ಲ.
ENV ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, ನಿಯೋಜನೆಯೊಳಗೆ ENV ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಘೋಷಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಿದೆ. ಅಂತೆಯೇ, ನಾವು ರಹಸ್ಯ ಡೇಟಾದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ನಾವು ತಕ್ಷಣವೇ ENV ವೇರಿಯೇಬಲ್‌ಗಳಿಂದ (ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಇತ್ಯಾದಿ) ರಹಸ್ಯ ಡೇಟಾವನ್ನು ರಹಸ್ಯವಾಗಿ ತಳ್ಳಬಹುದು, ರಹಸ್ಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ನಾವು ನೇರವಾಗಿ ಘೋಷಿಸುವುದಿಲ್ಲ ಎಂದು ನಿಯೋಜನೆಯಲ್ಲಿನ ENV ವಿವರಣೆಯಲ್ಲಿ ಸೂಚಿಸಬಹುದು. ಈ ವೇರಿಯಬಲ್‌ನ ಮೌಲ್ಯ ಮತ್ತು ಈ ಡೇಟಾಬೇಸ್ ಪಾಸ್‌ವರ್ಡ್ ವೇರಿಯಬಲ್‌ನ ಮೌಲ್ಯವನ್ನು ರಹಸ್ಯದಿಂದ ಓದಲಾಗುತ್ತದೆ. ಇದು ಪ್ರಮಾಣಿತ ಕುಬರ್ನೆಟ್ ನಡವಳಿಕೆಯಾಗಿದೆ. ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಇದು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ, ಮತ್ತೆ ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು DevOps ಆಗಿದ್ದರೆ, ನೀವು ಹೀಗೆ ಕೇಳಬಹುದು: “ಹುಡುಗರೇ, ಪರಿಸರದ ಅಸ್ಥಿರಗಳನ್ನು ಓದಲು ದಯವಿಟ್ಟು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಲಿಸಿ. ಮತ್ತು ನಾವೆಲ್ಲರೂ ಸಂತೋಷವಾಗಿರುತ್ತೇವೆ. ”
ಕಂಪನಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಅದೇ ಹೆಸರಿನ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಓದಿದರೆ, ಅದು ಅದ್ಭುತವಾಗಿದೆ. ಆದ್ದರಿಂದ ಕೆಲವರು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ, ಇತರರು ಡೇಟಾಬೇಸ್ ಹೆಸರಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ, ಇತರರು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಕಾಯುತ್ತಿದ್ದಾರೆ, ಇತರರು ಕೆಲವು ರೀತಿಯ ಡಿಬಿಎನ್‌ಗಾಗಿ ಕಾಯುತ್ತಿದ್ದಾರೆ, ಆದ್ದರಿಂದ, ಅದರ ಪ್ರಕಾರ, ಏಕರೂಪತೆ ಇರುತ್ತದೆ.
ನೀವು ನಿಯೋಜನೆಯನ್ನು ತೆರೆಯುವಷ್ಟು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಸಮಸ್ಯೆ ಬರುತ್ತದೆ - ಮತ್ತು ಪರಿಸರದ ಅಸ್ಥಿರಗಳ ಐದು ನೂರು ಸಾಲುಗಳಿವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಸರಳವಾಗಿ ಬೆಳೆದ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ - ಮತ್ತು ನೀವು ಇನ್ನು ಮುಂದೆ ನಿಮ್ಮನ್ನು ಹಿಂಸಿಸಬೇಕಾಗಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂರಚನೆಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಅಂದರೆ, ಸಂರಚನೆಗಳನ್ನು ಬಳಸಲು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತರಬೇತಿ ಮಾಡಿ.
ಒಂದೇ ಪ್ರಶ್ನೆಯೆಂದರೆ ಸಂರಚನೆಗಳು ನೀವು ಅಂದುಕೊಂಡಂತೆ ಅಲ್ಲ. Config.pi ಬಳಸಲು ಅನುಕೂಲಕರವಾದ ಸಂರಚನೆಯಲ್ಲ. ಅಥವಾ ನಿಮ್ಮ ಸ್ವಂತ ಸ್ವರೂಪದಲ್ಲಿ ಕೆಲವು ಸಂರಚನೆಗಳು, ಪರ್ಯಾಯವಾಗಿ ಉಡುಗೊರೆಯಾಗಿವೆ - ಇದು ನನ್ನ ಪ್ರಕಾರ ಸಂರಚನೆಯಲ್ಲ.
ನಾನು ಮಾತನಾಡುತ್ತಿರುವುದು ಸ್ವೀಕಾರಾರ್ಹ ಸ್ವರೂಪಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಆಗಿದೆ, ಅಂದರೆ, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಮಾನದಂಡವೆಂದರೆ .yaml ಮಾನದಂಡ. ಅದನ್ನು ಹೇಗೆ ಓದುವುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಇದು ಮಾನವ ಓದಬಲ್ಲದು, ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಅದನ್ನು ಹೇಗೆ ಓದುವುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಅಂತೆಯೇ, YAML ಜೊತೆಗೆ, ನೀವು JSON ಅನ್ನು ಸಹ ಬಳಸಬಹುದು, ಅಲ್ಲಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಓದುವ ವಿಷಯದಲ್ಲಿ ಪಾರ್ಸಿಂಗ್ YAML ನಂತೆ ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ. ಜನರು ಓದಲು ಇದು ಹೆಚ್ಚು ಅನಾನುಕೂಲವಾಗಿದೆ. ನೀವು ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು, ಎ ಲಾ ಇನಿ. ಮಾನವ ದೃಷ್ಟಿಕೋನದಿಂದ ಓದಲು ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಆದರೆ ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅನಾನುಕೂಲವಾಗಬಹುದು, ಅಂದರೆ ನೀವು ಎಂದಾದರೂ ನಿಮ್ಮ ಸ್ವಂತ ಸಂರಚನೆಗಳನ್ನು ರಚಿಸಲು ಬಯಸಿದರೆ, ಇನಿ ಸ್ವರೂಪವು ಈಗಾಗಲೇ ರಚಿಸಲು ಅನಾನುಕೂಲವಾಗಬಹುದು.
ಆದರೆ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಯಾವುದೇ ಸ್ವರೂಪವನ್ನು ಆರಿಸಿಕೊಂಡರೂ, ಕುಬರ್ನೆಟ್ಸ್ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ. ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಸಂರಚನೆಯನ್ನು ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ, ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ನಲ್ಲಿ ಇರಿಸಬಹುದು. ತದನಂತರ ಈ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ನಿಮ್ಮ ಪಾಡ್‌ನೊಳಗೆ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಜೋಡಿಸಲು ಕೇಳಿ, ಅಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಈ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ನಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕೇವಲ ಫೈಲ್‌ನಂತೆ ಓದುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ನೀವು ಸಾಕಷ್ಟು ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಮಾಡುವುದು ಒಳ್ಳೆಯದು. ಅಥವಾ ಇದು ಕೇವಲ ಕೆಲವು ರೀತಿಯ ಸಂಕೀರ್ಣ ರಚನೆಯಾಗಿದೆ, ಗೂಡುಕಟ್ಟುವಿದೆ.
ನೀವು ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೀವು ಚೆನ್ನಾಗಿ ಕಲಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಅನ್ನು ಅಳವಡಿಸಲಾಗಿರುವ ಫೈಲ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ಕಾನ್ಫಿಗ್‌ಗಳು ಬದಲಾದಾಗ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಲೋಡ್ ಮಾಡಿ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಆದರ್ಶ ಆಯ್ಕೆಯಾಗಿದೆ.
ಮತ್ತೆ, ನಾನು ಈಗಾಗಲೇ ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇನೆ - ರಹಸ್ಯ ಮಾಹಿತಿಯು ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್ನಲ್ಲಿಲ್ಲ, ರಹಸ್ಯ ಮಾಹಿತಿಯು ವೇರಿಯೇಬಲ್ಗಳಲ್ಲಿಲ್ಲ, ರಹಸ್ಯ ಮಾಹಿತಿಯು ರಹಸ್ಯಗಳಲ್ಲಿಲ್ಲ. ಅಲ್ಲಿಂದ, ಈ ರಹಸ್ಯ ಮಾಹಿತಿಯನ್ನು ರಾಜತಾಂತ್ರಿಕತೆಗೆ ಸಂಪರ್ಕಿಸಿ. ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ವಸ್ತುಗಳು, ನಿಯೋಜನೆಗಳು, ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ಗಳು, ಸೇವೆಗಳ ಎಲ್ಲಾ ವಿವರಣೆಗಳನ್ನು ಜಿಟ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಅದರಂತೆ, ನೀವು ಕಂಪನಿಯಲ್ಲಿ ಆಂತರಿಕವಾಗಿ ಹೊಂದಿರುವ ನಿಮ್ಮ ಜಿಟ್ ಆಗಿದ್ದರೂ ಸಹ, ಡೇಟಾಬೇಸ್‌ಗೆ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಜಿಟ್ನಲ್ಲಿ ಹಾಕುವುದು ಕೆಟ್ಟ ಕಲ್ಪನೆ. ಏಕೆಂದರೆ, ಕನಿಷ್ಠ, git ಎಲ್ಲವನ್ನೂ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ.
ಆರೋಗ್ಯ ತಪಾಸಣೆ
ಮುಂದಿನ ಅಂಶವೆಂದರೆ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಎಂಬ ವಿಷಯ. ಸಾಮಾನ್ಯವಾಗಿ, ಆರೋಗ್ಯ ತಪಾಸಣೆಯು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಹೆಚ್ಚಾಗಿ ಕೆಲವು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ, ಆರೋಗ್ಯ ತಪಾಸಣೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ (ಇಲ್ಲಿ ಮತ್ತು ಮತ್ತಷ್ಟು ಅನುವಾದಿಸದಿರುವುದು ಉತ್ತಮ) ಇದು ಕೆಲವು ವಿಶೇಷ URL ಆಗಿರುತ್ತದೆ, ಅದನ್ನು ಅವರು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ ಒಂದು ಪ್ರಮಾಣಿತ, ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡುತ್ತಾರೆ /health.
ಈ URL ಅನ್ನು ಪ್ರವೇಶಿಸುವಾಗ, ಅದರ ಪ್ರಕಾರ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ "ಹೌದು, ಸರಿ, ನನ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ, 200" ಅಥವಾ "ಇಲ್ಲ, ನನ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಸರಿಯಾಗಿಲ್ಲ, ಸುಮಾರು 500" ಎಂದು ಹೇಳುತ್ತದೆ. ಅಂತೆಯೇ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ http ಅಲ್ಲ, ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲ, ನಾವು ಈಗ ಕೆಲವು ರೀತಿಯ ಡೀಮನ್ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು. ಅಂದರೆ, ಇದು ಅನಿವಾರ್ಯವಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ http ಇಲ್ಲದಿದ್ದರೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆ ಇಲ್ಲದೆ ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಇದನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ನೀವು ನಿಯತಕಾಲಿಕವಾಗಿ ಫೈಲ್‌ನಲ್ಲಿ ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸಬಹುದು, ನಿಮ್ಮ ಡೀಮನ್‌ಗಾಗಿ ನೀವು ಕೆಲವು ವಿಶೇಷ ಆಜ್ಞೆಯೊಂದಿಗೆ ಬರಬಹುದು, ಉದಾಹರಣೆಗೆ, daemon status, ಅದು "ಹೌದು, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ, ಡೀಮನ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಅದು ಜೀವಂತವಾಗಿದೆ" ಎಂದು ಹೇಳುತ್ತದೆ.
ಇದು ಯಾವುದಕ್ಕಾಗಿ? ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ವಿಷಯವೆಂದರೆ ಬಹುಶಃ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಏಕೆ ಬೇಕು - ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ಅಂದರೆ, ಇದು ಕೇವಲ ಮೂರ್ಖತನ, ಈಗ ಅದು ಎದ್ದಾಗ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ತೋರುತ್ತಿದೆ, ಆದ್ದರಿಂದ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ಹೇಳಬಹುದು. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಕಂಟೇನರ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ನಿದರ್ಶನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ - ಮತ್ತು ನಂತರ ಬಳಕೆದಾರರು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಫೋನ್ ಸಂಖ್ಯೆಗಳನ್ನು ತಾಂತ್ರಿಕ ಬೆಂಬಲದಿಂದ ಕಡಿತಗೊಳಿಸಿದ್ದಾರೆ ಮತ್ತು "ನೀವು ಏನು ..., ನೀವು ನಿದ್ರೆಗೆ ಜಾರಿದೆ, ಏನೂ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ.
ಆರೋಗ್ಯ ತಪಾಸಣೆಯು ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ವಿಧಾನಗಳಲ್ಲಿ ಒಂದು. ಇದನ್ನು ಹೀಗೆ ಹೇಳೋಣ. ಕುಬರ್ನೆಟ್ಸ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅಪ್ಲಿಕೇಶನ್ ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಇದು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಕಂಟೇನರ್ ಅನ್ನು ಯಾವಾಗ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ಈ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೇರವಾಗಿ ಪ್ರಾರಂಭಿಸಿದಾಗ ವ್ಯತ್ಯಾಸವಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಏಕೆಂದರೆ ನಾವು ಕೆಲವು ಸರಾಸರಿ ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಡಾಕ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಂತರ ನಲವತ್ತು ಸೆಕೆಂಡುಗಳು, ಅಥವಾ ಒಂದು ನಿಮಿಷ, ಅಥವಾ ಹತ್ತು, ಅದು ಉತ್ತಮವಾಗಿ ಪ್ರಾರಂಭಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಕನಿಷ್ಟ ಅದರ ಬಂದರುಗಳನ್ನು ನಾಕ್ ಮಾಡಬಹುದು, ಅದು ಅಲ್ಲಿ ಉತ್ತರಿಸುವುದಿಲ್ಲ, ಅಂದರೆ, ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಲು ಇನ್ನೂ ಸಿದ್ಧವಾಗಿಲ್ಲ.
ಮತ್ತೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆಯ ಸಹಾಯದಿಂದ ಮತ್ತು ನಾವು ಇಲ್ಲಿಗೆ ತಿರುಗುತ್ತಿದ್ದೇವೆ ಎಂಬ ಅಂಶದ ಸಹಾಯದಿಂದ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕಂಟೇನರ್ ಏರಿದೆ ಮಾತ್ರವಲ್ಲ, ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಪ್ರಾರಂಭವಾಗಿದೆ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು, ಅದು ಈಗಾಗಲೇ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಆರೋಗ್ಯ ತಪಾಸಣೆ, ಅಂದರೆ ನಾವು ಅಲ್ಲಿಗೆ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸಬಹುದು.
ನಾನು ಈಗ ಮಾತನಾಡುತ್ತಿರುವುದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿನ ಸಿದ್ಧತೆ/ಜೀವನದ ಪರೀಕ್ಷೆಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ; ಅದರ ಪ್ರಕಾರ, ಸಮತೋಲನದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಲಭ್ಯತೆಗೆ ನಮ್ಮ ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆಗಳು ಕಾರಣವಾಗಿವೆ. ಅಂದರೆ, ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದರೆ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ, ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಸನ್ನದ್ಧತೆಯ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಸರಳವಾಗಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ, ಈ ನಿರ್ದಿಷ್ಟ ನಿದರ್ಶನವು ಸಮತೋಲನದಲ್ಲಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ, ಅದನ್ನು ಸಮತೋಲನದಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ದಟ್ಟಣೆಯು ಹರಿಯುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಗಳು ಅಗತ್ಯವಿದೆ ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಸಿಲುಕಿಕೊಂಡರೆ, ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಘೋಷಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬ್ಯಾಲೆನ್ಸಿಂಗ್‌ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗುವುದಿಲ್ಲ, ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ಇಲ್ಲಿ ನಾನು ನಮೂದಿಸಲು ಬಯಸುವ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ: ಪ್ರಾಯೋಗಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸನ್ನದ್ಧತೆಯ ಪರೀಕ್ಷೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಅಂದರೆ, ಸನ್ನದ್ಧತೆ ಮತ್ತು ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಸರಳವಾಗಿ ಆಲೋಚನೆಯಿಲ್ಲದೆ ಘೋಷಿಸುವುದು, ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಅದು ಮಾಡಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಬಳಸೋಣ, ಅದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ. ಏಕೆ ಎಂದು ನಾನು ವಿವರಿಸುತ್ತೇನೆ. ಏಕೆಂದರೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆ ಎರಡು ನಿಮ್ಮ ಆರೋಗ್ಯ ತಪಾಸಣೆಯಲ್ಲಿ ಆಧಾರವಾಗಿರುವ ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಒಳ್ಳೆಯದು. ಇದರರ್ಥ ನೀವು ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ನೀಡುವ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಹೊಂದಿದ್ದರೆ, ಅದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಎಲ್ಲಿಂದಲೋ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ. ಸರಿ, ಇದು ಈ REST API ಗೆ ಬರುವ ಮಾಹಿತಿಯನ್ನು ಅದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಸುತ್ತದೆ. ನಂತರ, ಅದರ ಪ್ರಕಾರ, ನಿಮ್ಮ ಆರೋಗ್ಯ ತಪಾಸಣೆಯು ಸಂಪರ್ಕಿಸಲಾದ ಸ್ಲಾಶ್‌ಹೆಲ್ತ್‌ನಂತೆ ಸರಳವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ “200, ಸರಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ” ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆ ಅಪ್ಲಿಕೇಶನ್ “200, ಸರಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ” - ಇದು ಕೆಟ್ಟ ಆರೋಗ್ಯ ತಪಾಸಣೆ. ಈ ರೀತಿ ಕೆಲಸ ಮಾಡಬಾರದು.
ಅಂದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್, ಅದಕ್ಕೆ ವಿನಂತಿ ಬಂದಾಗ /health, ಅದು ಕೇವಲ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ, “200, ಸರಿ”, ಅದು ಮೊದಲು ಹೋಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ಗೆ, ಅದನ್ನು ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಮೂಲಭೂತವಾಗಿ ಮಾಡುತ್ತದೆ, ಒಂದನ್ನು ಆರಿಸಿ, ಅದರಲ್ಲಿ ಸಂಪರ್ಕವಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಮತ್ತು ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸಬಹುದು. ಇದೆಲ್ಲವೂ ಯಶಸ್ವಿಯಾದರೆ, ಉತ್ತರವು "200, ಸರಿ." ಅದು ಯಶಸ್ವಿಯಾಗದಿದ್ದರೆ, ದೋಷವಿದೆ, ಡೇಟಾಬೇಸ್ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಅದು ಹೇಳುತ್ತದೆ.
ಆದ್ದರಿಂದ, ಈ ನಿಟ್ಟಿನಲ್ಲಿ, ನಾನು ಮತ್ತೊಮ್ಮೆ ಸನ್ನದ್ಧತೆ/ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಗಳಿಗೆ ಹಿಂತಿರುಗುತ್ತೇನೆ - ನಿಮಗೆ ಹೆಚ್ಚಾಗಿ ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆ ಏಕೆ ಬೇಕು, ಆದರೆ ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಯು ಪ್ರಶ್ನೆಯಲ್ಲಿದೆ. ಏಕೆಂದರೆ ನೀವು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ನಾನು ಹೇಳಿದಂತೆ ನಿಖರವಾಗಿ ವಿವರಿಸಿದರೆ, ಅದು ನಿದರ್ಶನ ಭಾಗದಲ್ಲಿ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ತಿರುಗುತ್ತದೆ.в или со всех instanceಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ. ನೀವು ಸನ್ನದ್ಧತೆಯ ಪರೀಕ್ಷೆಯನ್ನು ಘೋಷಿಸಿದಾಗ, ನಮ್ಮ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು ಅದರ ಪ್ರಕಾರ ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶಿಸಲಾಗದ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದರಿಂದ ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಆಫ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ನಿರ್ಲಕ್ಷಿತ ಸ್ಥಿತಿಯಲ್ಲಿ "ಹ್ಯಾಂಗ್" ಮಾಡಿ ಮತ್ತು ಅವುಗಳ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ಕಾಯಿರಿ. ಕೆಲಸ.
ನಾವು ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಯನ್ನು ಘೋಷಿಸಿದ್ದರೆ, ಊಹಿಸಿಕೊಳ್ಳಿ, ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಎಲ್ಲವೂ ಪುನರಾರಂಭಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಇದರರ್ಥ ನೀವು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ. ಇದು ನಿಮಗೆ ಬೇಕಾದುದಲ್ಲ, ಅಭ್ಯಾಸದಲ್ಲಿ ನನಗೆ ವೈಯಕ್ತಿಕ ಅನುಭವವೂ ಇತ್ತು. ನಾವು JS ನಲ್ಲಿ ಬರೆಯಲಾದ ಚಾಟ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಮೊಂಗೊ ಡೇಟಾಬೇಸ್‌ಗೆ ಫೀಡ್ ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು ಸಮಸ್ಯೆಯೆಂದರೆ ಅದು ಕುಬರ್ನೆಟ್ಸ್ ಅವರೊಂದಿಗಿನ ನನ್ನ ಕೆಲಸದ ಆರಂಭದಲ್ಲಿದೆ, ಕುಬರ್ನೆಟ್ಸ್ ಇದನ್ನು ಮಾಡಬಹುದು ಎಂಬ ತತ್ತ್ವದ ಮೇಲೆ ಪರೀಕ್ಷೆಗಳ ಸಿದ್ಧತೆ, ಜೀವಂತಿಕೆಯನ್ನು ನಾವು ವಿವರಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ. ಅಂತೆಯೇ, ಕೆಲವು ಹಂತದಲ್ಲಿ ಮೊಂಗೊ ಸ್ವಲ್ಪ "ಮಂದ" ಆಯಿತು ಮತ್ತು ಮಾದರಿಯು ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿತು. ಅದರಂತೆ, ಮಳೆಯ ಪರೀಕ್ಷೆಯ ಪ್ರಕಾರ, ಬೀಜಕೋಶಗಳು "ಕೊಲ್ಲಲು" ಪ್ರಾರಂಭಿಸಿದವು.
ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಅವರು "ಕೊಲ್ಲಲ್ಪಟ್ಟಾಗ", ಇದು ಚಾಟ್ ಆಗಿದೆ, ಅಂದರೆ, ಅದರ ಮೇಲೆ ನೇತಾಡುವ ಗ್ರಾಹಕರಿಂದ ಸಾಕಷ್ಟು ಸಂಪರ್ಕಗಳಿವೆ. ಅವರು "ಕೊಲ್ಲಲ್ಪಟ್ಟಿದ್ದಾರೆ" - ಇಲ್ಲ, ಗ್ರಾಹಕರಲ್ಲ, ಸಂಪರ್ಕಗಳು ಮಾತ್ರ - ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, ಮತ್ತು ಅವರು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಕೊಲ್ಲಲ್ಪಟ್ಟಿಲ್ಲ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ, ಕೆಲವು ಮೊದಲು, ಕೆಲವು ನಂತರ, ಅವರು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ ಸಮಯ. ಜೊತೆಗೆ ಪ್ರಮಾಣಿತ ಯಾದೃಚ್ಛಿಕ, ನಾವು ಪ್ರತಿ ಬಾರಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಾರಂಭದ ಸಮಯವನ್ನು ಮಿಲಿಸೆಕೆಂಡ್ ನಿಖರತೆಯೊಂದಿಗೆ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವರು ಅದನ್ನು ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ನಿದರ್ಶನವನ್ನು ಮಾಡುತ್ತಾರೆ. ಒಂದು ಇನ್ಫೋಸ್ಪಾಟ್ ಏರುತ್ತದೆ, ಸಮತೋಲನಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಎಲ್ಲಾ ಗ್ರಾಹಕರು ಅಲ್ಲಿಗೆ ಬರುತ್ತಾರೆ, ಅದು ಅಂತಹ ಹೊರೆಯನ್ನು ತಡೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಏಕಾಂಗಿಯಾಗಿದೆ, ಮತ್ತು ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅಲ್ಲಿ ಒಂದು ಡಜನ್ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅದು ಬೀಳುತ್ತದೆ. ಮುಂದಿನವನು ಏರುತ್ತಾನೆ, ಸಂಪೂರ್ಣ ಹೊರೆ ಅವನ ಮೇಲೆ, ಅವನೂ ಬೀಳುತ್ತಾನೆ. ಸರಿ, ಈ ಜಲಪಾತಗಳು ಕ್ಯಾಸ್ಕೇಡ್ ಆಗುತ್ತಲೇ ಇರುತ್ತವೆ. ಕೊನೆಯಲ್ಲಿ, ಇದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಲಾಗಿದೆ - ನಾವು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಲ್ಲಿಸಬೇಕಾಗಿತ್ತು, ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಏರಿಕೆಯಾಗಲಿ ಮತ್ತು ನಂತರ ಎಲ್ಲಾ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಿ ಇದರಿಂದ ಅದನ್ನು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಹತ್ತು ನಿದರ್ಶನಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ.
ಈ ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಯನ್ನು ಘೋಷಿಸದಿದ್ದರೆ, ಅದು ಎಲ್ಲವನ್ನೂ ಮರುಪ್ರಾರಂಭಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಿತ್ತು. ಆದರೆ ಸಮತೋಲನದಿಂದ ಎಲ್ಲವನ್ನೂ ನಮಗೆ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ಡೇಟಾಬೇಸ್ಗಳು ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆದಾರರು "ಬಿದ್ದುಹೋದರು". ನಂತರ, ಈ ಡೇಟಾಬೇಸ್ ಲಭ್ಯವಾದಾಗ, ಎಲ್ಲವನ್ನೂ ಸಮತೋಲನದಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುವ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಇದರಲ್ಲಿ ಸಮಯ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಅವರೆಲ್ಲರೂ ಈಗಾಗಲೇ ಇಲ್ಲಿದ್ದಾರೆ, ಅವರು ಸಂಚಾರಕ್ಕೆ ಸಿದ್ಧರಾಗಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ದಟ್ಟಣೆಯು ತೆರೆಯುತ್ತದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ - ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳದಲ್ಲಿದೆ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ.
ಆದ್ದರಿಂದ, ಸನ್ನದ್ಧತೆ ಮತ್ತು ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಗಳು ವಿಭಿನ್ನವಾಗಿವೆ, ಮೇಲಾಗಿ, ನೀವು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ವಿವಿಧ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಬಹುದು, ಒಂದು ವಿಧದ ತ್ರಿಜ್ಯಗಳು, ಒಂದು ರೀತಿಯ ಲಿವ್, ಉದಾಹರಣೆಗೆ, ಮತ್ತು ವಿವಿಧ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆಗಳ ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಮತ್ತು ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಲೈವ್ನೆಸ್ ಪರೀಕ್ಷೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಮಾತ್ರ ಎಂದು ನೀವು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಅದು ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಾದರೆ.
ಏಕೆಂದರೆ ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಯು ದೊಡ್ಡದಾಗಿ, ನಾವು "ಅಂಟಿಕೊಂಡಾಗ" ಆಗಿರುತ್ತದೆ. ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ ಪ್ರಾರಂಭವಾಗಿದೆ ಅಥವಾ ಯಾವುದೋ - ಮತ್ತು ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಹ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ - ಮತ್ತು ಅವುಗಳಲ್ಲಿ ವಿಭಿನ್ನ ತರ್ಕವನ್ನು ಅಳವಡಿಸಿ.
ನೀವು ಪರೀಕ್ಷೆಯನ್ನು ಹೊಂದಿರುವಾಗ, ನೀವು ಆರೋಗ್ಯ ತಪಾಸಣೆ ಮಾಡುವಾಗ ನೀವು ಏನು ಉತ್ತರಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು. ಇದು ನಿಜವಾಗಿಯೂ ನೋವು. ಇದನ್ನು ತಿಳಿದಿರುವವರು ಬಹುಶಃ ನಗುತ್ತಾರೆ - ಆದರೆ ಗಂಭೀರವಾಗಿ, ನನ್ನ ಜೀವನದಲ್ಲಿ 200% ಪ್ರಕರಣಗಳಲ್ಲಿ “XNUMX” ಎಂದು ಉತ್ತರಿಸುವ ಸೇವೆಗಳನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ. ಅಂದರೆ, ಯಾರು ಯಶಸ್ವಿಯಾಗುತ್ತಾರೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯ ದೇಹದಲ್ಲಿ ಅವರು "ಅಂತಹ ಮತ್ತು ಅಂತಹ ದೋಷ" ಎಂದು ಬರೆಯುತ್ತಾರೆ.
ಅಂದರೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಥಿತಿ ನಿಮಗೆ ಬರುತ್ತದೆ - ಎಲ್ಲವೂ ಯಶಸ್ವಿಯಾಗಿದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ದೇಹವನ್ನು ಪಾರ್ಸ್ ಮಾಡಬೇಕು, ಏಕೆಂದರೆ ದೇಹವು "ಕ್ಷಮಿಸಿ, ವಿನಂತಿಯು ದೋಷದಿಂದ ಕೊನೆಗೊಂಡಿದೆ" ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಇದು ಕೇವಲ ವಾಸ್ತವವಾಗಿದೆ. ನಾನು ಇದನ್ನು ನಿಜ ಜೀವನದಲ್ಲಿ ನೋಡಿದ್ದೇನೆ.
ಮತ್ತು ಕೆಲವು ಜನರು ಅದನ್ನು ತಮಾಷೆಯಾಗಿ ಕಾಣುವುದಿಲ್ಲ, ಮತ್ತು ಇತರರು ಅದನ್ನು ತುಂಬಾ ನೋವಿನಿಂದ ಕಾಣುತ್ತಾರೆ, ಇದು ಇನ್ನೂ ಸರಳ ನಿಯಮಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ. ಆರೋಗ್ಯ ತಪಾಸಣೆಯಲ್ಲಿ, ಮತ್ತು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ತಾತ್ವಿಕವಾಗಿ.
ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ನಡೆದರೆ, ಇನ್ನೂರನೇ ಉತ್ತರದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ. ತಾತ್ವಿಕವಾಗಿ, ಯಾವುದೇ ಎರಡು ನೂರನೇ ಉತ್ತರವು ನಿಮಗೆ ಸರಿಹೊಂದುತ್ತದೆ. ನೀವು ರಾಗ್ಸಿಯನ್ನು ಚೆನ್ನಾಗಿ ಓದಿದರೆ ಮತ್ತು ಕೆಲವು ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಥಿತಿಗಳು ಇತರರಿಂದ ಭಿನ್ನವಾಗಿರುತ್ತವೆ ಎಂದು ತಿಳಿದಿದ್ದರೆ, ಸೂಕ್ತವಾದವುಗಳೊಂದಿಗೆ ಉತ್ತರಿಸಿ: 204, 5, 10, 15, ಏನೇ ಇರಲಿ. ಅದು ಉತ್ತಮವಾಗಿಲ್ಲದಿದ್ದರೆ, ಕೇವಲ "ಎರಡು ಶೂನ್ಯ ಶೂನ್ಯ". ಎಲ್ಲವೂ ಕೆಟ್ಟದಾಗಿ ಹೋದರೆ ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸದಿದ್ದರೆ, ಯಾವುದೇ ಐನೂರನೇ ಜೊತೆ ಉತ್ತರಿಸಿ. ಮತ್ತೊಮ್ಮೆ, ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ವಿಭಿನ್ನ ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಥಿತಿಗಳು ಪರಸ್ಪರ ಹೇಗೆ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ನಿಮಗೆ ಅರ್ಥವಾಗದಿದ್ದರೆ, ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ ಆರೋಗ್ಯ ತಪಾಸಣೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು 502 ನಿಮ್ಮ ಆಯ್ಕೆಯಾಗಿದೆ.
ಇದು ಮತ್ತೊಂದು ಅಂಶವಾಗಿದೆ, ಆಧಾರವಾಗಿರುವ ಸೇವೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಬಗ್ಗೆ ನಾನು ಸ್ವಲ್ಪ ಹಿಂತಿರುಗಲು ಬಯಸುತ್ತೇನೆ. ನೀವು ಪ್ರಾರಂಭಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಿಂದೆ ನಿಂತಿರುವ ಎಲ್ಲಾ ಆಧಾರವಾಗಿರುವ ಸೇವೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು - ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವೂ. ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ದೃಷ್ಟಿಕೋನದಿಂದ ನಾವು ಏನನ್ನು ಪಡೆಯುತ್ತೇವೆ, ನಾವು "ಕಡಿಮೆ ಜೋಡಣೆ" ಯಂತಹ ಪರಿಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಅಂದರೆ, ನಿಮ್ಮ ಸೇವೆಗಳು ಪರಸ್ಪರ ಕನಿಷ್ಠವಾಗಿ ಅವಲಂಬಿತವಾಗಿದ್ದಾಗ. ಅವುಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ, ಈ ಕಾರ್ಯವನ್ನು ಹೊಂದಿರದ ಇತರರು ಸರಳವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ. ಕೆಲವು ಕಾರ್ಯಚಟುವಟಿಕೆಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ನೀವು ಎಲ್ಲಾ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಒಂದಕ್ಕೊಂದು ಜೋಡಿಸಿದರೆ, ನೀವು ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಬೀಳುವ ಒಂದು ವಿಷಯದೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವಿರಿ, ಮತ್ತು ಅದು ಬಿದ್ದ ಕಾರಣ, ಎಲ್ಲಾ ಸೇವೆಗಳ ಎಲ್ಲಾ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ - ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚಿನ ಮೂಲಸೌಕರ್ಯಗಳಿವೆ. ಸಂಪೂರ್ಣ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ನಂ. ಅಲ್ಲಿ ಎಲ್ಲವೂ ಕತ್ತಲೆಯಾಯಿತು.
ಆದ್ದರಿಂದ, ನೀವು ಆಧಾರವಾಗಿರುವ ಸೇವೆಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾನು ಇದನ್ನು ಮತ್ತೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸಲು ಬಯಸುತ್ತೇನೆ, ಅದು ಇಲ್ಲದೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನೂರು ಪ್ರತಿಶತ ಪ್ರಕರಣಗಳಲ್ಲಿ ಅದರ ಕೆಲಸವನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂದರೆ, ಬಳಕೆದಾರರು ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸುವ ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹಿಂಪಡೆಯುವ ಮೂಲಕ ನೀವು REST API ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಡೇಟಾಬೇಸ್ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ನಿಮ್ಮ ಬಳಕೆದಾರರೊಂದಿಗೆ ಕೆಲಸವನ್ನು ನೀವು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ.
ಆದರೆ ನಿಮ್ಮ ಬಳಕೆದಾರರು, ನೀವು ಅವುಗಳನ್ನು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹೊರತೆಗೆದಾಗ, ಮುಂಭಾಗಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ನೀವು ನಮೂದಿಸುವ ಮತ್ತೊಂದು ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಕೆಲವು ಇತರ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ಪುಷ್ಟೀಕರಿಸಿದರೆ - ಮತ್ತು ಈ ಬ್ಯಾಕೆಂಡ್ ಲಭ್ಯವಿಲ್ಲ, ಇದರರ್ಥ ನೀವು ನಿಮ್ಮ ಮೆಟಾಡೇಟಾದ ಯಾವುದೇ ಭಾಗವಿಲ್ಲದೆ ಉತ್ತರಿಸಿ.
ಮುಂದೆ, ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ನಾವು ನೋವಿನ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ವಾಸ್ತವವಾಗಿ, ಇದು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುವುದಿಲ್ಲ; ಕೆಲವು ರೀತಿಯ ಸಾಮೂಹಿಕ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ DevOps ಸಂಸ್ಕೃತಿಯು ಕುಬರ್ನೆಟ್ಸ್ನಂತೆಯೇ ಅದೇ ಸಮಯದಲ್ಲಿ ಹರಡಲು ಪ್ರಾರಂಭಿಸಿತು. ಆದ್ದರಿಂದ, ದೊಡ್ಡದಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಇಲ್ಲದೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೀವು ಆಕರ್ಷಕವಾಗಿ ಮುಚ್ಚಬೇಕಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಮೊದಲು, ಜನರು ಇದನ್ನು ಮಾಡಿದರು, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಆಗಮನದೊಂದಿಗೆ, ನಾವು ಅದರ ಬಗ್ಗೆ ಸಾಮೂಹಿಕವಾಗಿ ಮಾತನಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ
ಸಾಮಾನ್ಯವಾಗಿ, ಗ್ರೇಸ್‌ಫುಲ್ ಶಟ್‌ಡೌನ್ ಎಂದರೇನು ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು? ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್ ಆದಾಗ, ನೀವು ಮಾಡಬೇಕಾದುದು ಇದು app stop - ಅಥವಾ ನೀವು ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಸಿಗ್ನಲ್, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ SIGTERM ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಮತ್ತು "SIGTERM, ನಾವು ಸ್ಥಗಿತಗೊಳ್ಳೋಣ, ಕೆಲಸ ಮಾಡೋಣ, ಏನನ್ನೂ ಮಾಡಬೇಡಿ" ಎಂಬಂತೆ ಕೆಟ್ಟ ಸನ್ನಿವೇಶವು ಸಹಜವಾಗಿದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಟ್ಟ ಆಯ್ಕೆಯಾಗಿದೆ.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ SIGTERM ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಅದು ಸರಿಸುಮಾರು ಸಮಾನವಾದ ಕೆಟ್ಟ ಆಯ್ಕೆಯಾಗಿದೆ ಮತ್ತು “ಅವರು ಸೆಗ್ಟರ್ಮ್ ಎಂದು ಹೇಳಿದರು, ಅಂದರೆ ನಾವು ಕೊನೆಗೊಳ್ಳುತ್ತಿದ್ದೇವೆ, ನಾನು ನೋಡಿಲ್ಲ, ನನಗೆ ಯಾವುದೇ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳು ತಿಳಿದಿಲ್ಲ, ಯಾವ ರೀತಿಯದು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ ನಾನು ಇದೀಗ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ವಿನಂತಿಗಳು, ಅವರು SIGTERM ಎಂದು ಹೇಳಿದರು, ಅಂದರೆ ನಾವು ಕೊನೆಗೊಳ್ಳುತ್ತಿದ್ದೇವೆ " ಇದು ಕೂಡ ಕೆಟ್ಟ ಆಯ್ಕೆಯಾಗಿದೆ.
ಯಾವ ಆಯ್ಕೆ ಒಳ್ಳೆಯದು? ಕಾರ್ಯಾಚರಣೆಗಳ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಮೊದಲ ಅಂಶವಾಗಿದೆ. ನಿಮ್ಮ ಸರ್ವರ್ SIGTERM ಅನ್ನು ಸ್ವೀಕರಿಸಿದರೆ ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಇನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ.
SIGTERM ಮೃದುವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯಾಗಿದೆ, ಇದನ್ನು ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಅದನ್ನು ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ ಪ್ರತಿಬಂಧಿಸಬಹುದು, ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು, ಈಗ ಹೇಳು, ನಿರೀಕ್ಷಿಸಿ, ನಾವು ಮೊದಲು ನಮ್ಮಲ್ಲಿರುವ ಕೆಲಸವನ್ನು ಮುಗಿಸುತ್ತೇವೆ, ನಂತರ ನಾವು ನಿರ್ಗಮಿಸುತ್ತೇವೆ.
ಕುಬರ್ನೆಟ್ಸ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪಾಡ್‌ಗೆ, "ದಯವಿಟ್ಟು ನಿಲ್ಲಿಸಿ, ದೂರ ಹೋಗು" ಎಂದು ಹೇಳಿದಾಗ ಅಥವಾ ನಾವು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ ಅಥವಾ ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಿದಾಗ ನವೀಕರಣ ಸಂಭವಿಸಿದಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗೆ ಅದೇ SIGTERM ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಸ್ವಲ್ಪ ಸಮಯ, ಮತ್ತು , ಇದು ಅವನು ಕಾಯುವ ಸಮಯ, ಇದನ್ನು ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಡಿಪ್ಲೋಮಾಗಳಲ್ಲಿ ಅಂತಹ ವಿಶೇಷ ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ ಮತ್ತು ಅದನ್ನು ಗ್ರೇಸ್‌ಫುಲ್ ಶಟ್‌ಡೌನ್‌ಟೈಮ್‌ಔಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಅದನ್ನು ಯಾವುದಕ್ಕೂ ಕರೆಯಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ನಾವು ಈಗ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿರುವುದು ಯಾವುದಕ್ಕೂ ಅಲ್ಲ.
ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ SIGTERM ಅನ್ನು ಕಳುಹಿಸುವ ಸಮಯದ ನಡುವೆ ನಾವು ಎಷ್ಟು ಸಮಯ ಕಾಯಬೇಕು ಎಂದು ನಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳಬಹುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಯಾವುದೋ ಹುಚ್ಚು ಹಿಡಿದಿದೆ ಅಥವಾ "ಅಂಟಿಕೊಂಡಿದೆ" ಮತ್ತು ಅದು ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಾಗ - ಮತ್ತು ನಮಗೆ ಅಗತ್ಯವಿದೆ ಅದನ್ನು SIGKILL ಎಂದು ಕಳುಹಿಸಿ, ಅಂದರೆ, ಅದರ ಕೆಲಸವನ್ನು ಕಷ್ಟಪಟ್ಟು ಪೂರ್ಣಗೊಳಿಸಿ. ಅಂದರೆ, ಅದರ ಪ್ರಕಾರ, ನಾವು ಕೆಲವು ರೀತಿಯ ಡೀಮನ್ ಚಾಲನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಡೀಮನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸರಾಸರಿ ನಮ್ಮ ಕಾರ್ಯಾಚರಣೆಗಳು ಒಂದು ಸಮಯದಲ್ಲಿ 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಅಂತೆಯೇ, SIGTERM ಬಂದಾಗ, ನಮ್ಮ ಡೀಮನ್ SIGTERM ನಂತರ 30 ಸೆಕೆಂಡುಗಳನ್ನು ಮುಗಿಸಬಹುದು ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ನಾವು ಅದನ್ನು ಬರೆಯುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಕೇವಲ 45 ಸೆಕೆಂಡುಗಳು ಮತ್ತು SIGTERM ಎಂದು ಹೇಳುತ್ತೇವೆ. ಅದರ ನಂತರ ನಾವು 45 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯುತ್ತೇವೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಈ ಸಮಯದಲ್ಲಿ ರಾಕ್ಷಸನು ತನ್ನ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಬೇಕು ಮತ್ತು ಸ್ವತಃ ಕೊನೆಗೊಳ್ಳಬೇಕು. ಆದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಅದು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅದು ಹೆಚ್ಚಾಗಿ ಸಿಲುಕಿಕೊಂಡಿದೆ ಎಂದರ್ಥ-ಇದು ಇನ್ನು ಮುಂದೆ ನಮ್ಮ ವಿನಂತಿಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಿಲ್ಲ. ಮತ್ತು 45 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನೀವು ಸುರಕ್ಷಿತವಾಗಿ, ವಾಸ್ತವವಾಗಿ, ಅವನನ್ನು ಕೆಳಗೆ ಉಗುರು ಮಾಡಬಹುದು.
ಮತ್ತು ಇಲ್ಲಿ, ವಾಸ್ತವವಾಗಿ, 2 ಅಂಶಗಳನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಮೊದಲನೆಯದಾಗಿ, ನೀವು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ನೀವು ಹೇಗಾದರೂ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೀರಿ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಲಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ಆದರೆ ನೀವು SIGTERM ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೀರಿ. ಅದನ್ನು ಪರಿಷ್ಕರಿಸಲು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಉತ್ತರವನ್ನು ನೀಡಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಈ ನಿಟ್ಟಿನಲ್ಲಿ ಇದು ಪಾಯಿಂಟ್ ನಂಬರ್ ಒನ್. ಇಲ್ಲಿ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆ ಎರಡು ಏನೆಂದರೆ, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬರೆದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ನೀವು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವ ರೀತಿಯಲ್ಲಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, ನಂತರ ನೀವು ಕೆಲವು ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಎಲ್ಲಿಂದಲಾದರೂ ಫೈಲ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಏನು ಅಲ್ಲ. - ಅದು. ಸಾಮಾನ್ಯವಾಗಿ, ನಿಮ್ಮ ಬಳಕೆದಾರ, ನಿಮ್ಮ ವಿನಂತಿಯು ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನೀವು ಅವನಿಗೆ ಉತ್ತರಿಸಲು ಕಾಯುತ್ತದೆ - ನಂತರ, ಹೆಚ್ಚಾಗಿ, ನೀವು ವಾಸ್ತುಶಿಲ್ಪದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಅಂದರೆ, ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣೆಗಳು ಚಿಕ್ಕದಾಗಿದ್ದರೆ, SIGTERM ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಮತ್ತು ಅದನ್ನು ಮಾರ್ಪಡಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ ಎಂಬ ಸಾಮಾನ್ಯ ಜ್ಞಾನವನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ. ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣೆಗಳು ದೀರ್ಘವಾಗಿದ್ದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ SIGTERM ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಅಂತಹ ದೀರ್ಘ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ತಪ್ಪಿಸಲು ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಆದ್ದರಿಂದ ಬಳಕೆದಾರರು ಸುಮ್ಮನೆ ಸುತ್ತಾಡುವುದಿಲ್ಲ ಮತ್ತು ಕಾಯುವುದಿಲ್ಲ. ನನಗೆ ಗೊತ್ತಿಲ್ಲ, ಅಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ವೆಬ್‌ಸಾಕೆಟ್ ಮಾಡಿ, ನಿಮ್ಮ ಸರ್ವರ್ ಈಗಾಗಲೇ ಕ್ಲೈಂಟ್‌ಗೆ ಕಳುಹಿಸುವ ರಿವರ್ಸ್ ಕೊಕ್ಕೆಗಳನ್ನು ಮಾಡಿ, ಬೇರೆ ಯಾವುದನ್ನಾದರೂ, ಆದರೆ ಬಳಕೆದಾರರನ್ನು ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ ಸ್ಥಗಿತಗೊಳಿಸಲು ಒತ್ತಾಯಿಸಬೇಡಿ ಮತ್ತು ನೀವು ತನಕ ಸೆಷನ್‌ಗಾಗಿ ಕಾಯಿರಿ ಅವನಿಗೆ ಉತ್ತರಿಸು. ಏಕೆಂದರೆ ಅದು ಎಲ್ಲಿ ಮುರಿಯಬಹುದು ಎಂದು ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮುಕ್ತಾಯಗೊಂಡಾಗ, ನೀವು ಕೆಲವು ಸೂಕ್ತವಾದ ನಿರ್ಗಮನ ಕೋಡ್ ಅನ್ನು ಒದಗಿಸಬೇಕು. ಅಂದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮುಚ್ಚಲು, ನಿಲ್ಲಿಸಲು ಕೇಳಿದರೆ ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವತಃ ನಿಲ್ಲಿಸಲು ಸಾಧ್ಯವಾದರೆ, ನೀವು ಕೆಲವು ರೀತಿಯ ನಿರ್ಗಮನ ಕೋಡ್ 1,5,255 ಮತ್ತು ಮುಂತಾದವುಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಶೂನ್ಯ ಕೋಡ್ ಅಲ್ಲ, ಕನಿಷ್ಠ ಲಿನಕ್ಸ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ, ನನಗೆ ಇದು ಖಚಿತವಾಗಿದೆ, ಅದನ್ನು ವಿಫಲವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ದೋಷದೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಅಂತೆಯೇ, ಸೌಹಾರ್ದಯುತ ರೀತಿಯಲ್ಲಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ದೋಷವಿಲ್ಲದೆ ಪೂರ್ಣಗೊಂಡರೆ, ನೀವು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ 0 ಎಂದು ಹೇಳುತ್ತೀರಿ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾದರೆ, ನೀವು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ 0 ಅಲ್ಲ ಎಂದು ಹೇಳುತ್ತೀರಿ. ಮತ್ತು ನೀವು ಈ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.
ಮತ್ತು ಕೊನೆಯ ಆಯ್ಕೆ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದಾಗ ಮತ್ತು ನೀವು ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ ಸ್ಥಗಿತಗೊಂಡಾಗ ಅದು ಕೆಟ್ಟದಾಗಿದೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, ಕ್ಲೈಂಟ್ನ ಕಡೆಯಿಂದ ಸಾಮಾನ್ಯವಾಗಿ ಮೌಲ್ಯಯುತವಾದದ್ದು ಎಂಬುದರ ಬಗ್ಗೆ ನಾನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ನೀವು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್, ಫ್ರಂಟ್-ಎಂಡ್ ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಬಳಕೆದಾರರ ಅಧಿವೇಶನವನ್ನು ಕೊನೆಗೊಳಿಸಬಹುದು, ಏನು ಬೇಕಾದರೂ ಆಗಬಹುದು ಎಂದು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ. ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಹಿಂತಿರುಗಿಲ್ಲ. ನಿಮ್ಮ ಮುಂಭಾಗ ಅಥವಾ ನಿಮ್ಮ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ - ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಮುಂಭಾಗ, ಅದನ್ನು ಹಾಗೆ ಇಡೋಣ - ಇದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ನೀವು ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನಾನು ಹೊಂದಿದ್ದ ಅತ್ಯಂತ ಕೆಟ್ಟ ನೋವು.
ಕೆಲವು ಸಾಮಾನ್ಯ ಚಾಟ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅದು ತಿಳಿದಿಲ್ಲದಿದ್ದಾಗ, ವೆಬ್‌ಸಾಕೆಟ್ ಮುರಿಯಬಹುದು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಅವರಿಗೆ, ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಏನಾದರೂ ಸಂಭವಿಸಿದಾಗ, ನಾವು ಕೇವಲ ಸಂರಚನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ಮರುಲೋಡ್ ಮಾಡುತ್ತದೆ. ನೈಸರ್ಗಿಕವಾಗಿ, ಎಲ್ಲಾ ದೀರ್ಘಾವಧಿಯ ಅವಧಿಗಳು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಹರಿದಿವೆ. ಡೆವಲಪರ್‌ಗಳು ನಮ್ಮ ಬಳಿಗೆ ಓಡಿ ಬಂದು ಹೇಳುತ್ತಾರೆ: "ಗೈಸ್, ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ, ನಮ್ಮ ಎಲ್ಲಾ ಗ್ರಾಹಕರಿಗೆ ಚಾಟ್ ಮುರಿದುಹೋಗಿದೆ!" ನಾವು ಅವರಿಗೆ ಹೇಳುತ್ತೇವೆ: "ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ? ನಿಮ್ಮ ಗ್ರಾಹಕರು ಮರುಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲವೇ? ಅವರು ಹೇಳುತ್ತಾರೆ: "ಇಲ್ಲ, ನಮಗೆ ಸೆಷನ್‌ಗಳು ಹರಿದು ಹೋಗಬಾರದು." ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಇದು ವಾಸ್ತವವಾಗಿ ಅಸಂಬದ್ಧವಾಗಿದೆ. ಗ್ರಾಹಕರ ಬದಿಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ವಿಶೇಷವಾಗಿ, ನಾನು ಹೇಳುವಂತೆ, ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳಂತಹ ದೀರ್ಘಾವಧಿಯ ಸೆಷನ್‌ಗಳೊಂದಿಗೆ, ಅದು ಮುರಿಯಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರಿಂದ ಗಮನಿಸದೆ, ನೀವು ಅಂತಹ ಸೆಷನ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ತದನಂತರ ಎಲ್ಲವೂ ಪರಿಪೂರ್ಣವಾಗಿದೆ.
ಸಂಪನ್ಮೂಲಗಳು
ವಾಸ್ತವವಾಗಿ, ಇಲ್ಲಿ ನಾನು ನಿಮಗೆ ನೇರವಾದ ಕಥೆಯನ್ನು ಹೇಳುತ್ತೇನೆ. ಮತ್ತೆ ನಿಜ ಜೀವನದಿಂದ. ಸಂಪನ್ಮೂಲಗಳ ಬಗ್ಗೆ ನಾನು ಕೇಳಿದ ಕೆಟ್ಟ ವಿಷಯ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳು, ನನ್ನ ಪ್ರಕಾರ, ಕೆಲವು ರೀತಿಯ ವಿನಂತಿಗಳು, ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ನೀವು ಪಾಡ್‌ಗಳನ್ನು ಹಾಕಬಹುದಾದ ಮಿತಿಗಳು. ಡೆವಲಪರ್‌ನಿಂದ ನಾನು ಕೇಳಿದ ತಮಾಷೆಯ ವಿಷಯ... ಹಿಂದಿನ ಕೆಲಸದ ಸ್ಥಳದಲ್ಲಿ ನನ್ನ ಸಹ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಒಮ್ಮೆ ಹೇಳಿದರು: "ನನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ." ಅದು ಪ್ರಾರಂಭವಾಗುತ್ತಿಲ್ಲ ಎಂದು ನಾನು ನೋಡಿದೆ, ಆದರೆ ಅದು ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ, ಅಥವಾ ಅವರು ಬಹಳ ಸಣ್ಣ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದ್ದರು. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಸಂಪನ್ಮೂಲಗಳ ಕಾರಣದಿಂದಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುವುದಿಲ್ಲ. ನಾನು ಹೇಳುತ್ತೇನೆ: "ಇದು ಸಂಪನ್ಮೂಲಗಳಿಂದ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ, ನಿಮಗೆ ಎಷ್ಟು ಬೇಕು ಮತ್ತು ಸಾಕಷ್ಟು ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಿ." ಅವರು ಹೇಳುತ್ತಾರೆ: "ಯಾವ ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳು?" ಕುಬರ್ನೆಟ್ಸ್, ವಿನಂತಿಗಳ ಮೇಲಿನ ಮಿತಿಗಳು ಮತ್ತು ಬ್ಲಾ, ಬ್ಲಾ, ಬ್ಲಾ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾನು ಅವರಿಗೆ ವಿವರಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಆ ವ್ಯಕ್ತಿ ಐದು ನಿಮಿಷಗಳ ಕಾಲ ಆಲಿಸಿ, ತಲೆಯಾಡಿಸಿ ಹೇಳಿದರು: “ನಾನು ಡೆವಲಪರ್ ಆಗಿ ಕೆಲಸ ಮಾಡಲು ಇಲ್ಲಿಗೆ ಬಂದಿದ್ದೇನೆ, ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳ ಬಗ್ಗೆ ನಾನು ಏನನ್ನೂ ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುವುದಿಲ್ಲ. ನಾನು ಕೋಡ್ ಬರೆಯಲು ಇಲ್ಲಿಗೆ ಬಂದಿದ್ದೇನೆ ಮತ್ತು ಅಷ್ಟೆ." ಇದು ದುಃಖಕರವಾಗಿದೆ. ಡೆವಲಪರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ತುಂಬಾ ದುಃಖಕರ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ. ವಿಶೇಷವಾಗಿ ಆಧುನಿಕ ಜಗತ್ತಿನಲ್ಲಿ, ಮಾತನಾಡಲು, ಪ್ರಗತಿಪರ ಡೆವೊಪ್ಸ್.
ಸಂಪನ್ಮೂಲಗಳು ಏಕೆ ಬೇಕು? ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ 2 ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳಿವೆ. ಕೆಲವನ್ನು ವಿನಂತಿಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಇತರರನ್ನು ಮಿತಿಗಳು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಮೂಲಭೂತವಾಗಿ ಯಾವಾಗಲೂ ಕೇವಲ ಎರಡು ಮೂಲಭೂತ ನಿರ್ಬಂಧಗಳಿವೆ ಎಂದು ಸಂಪನ್ಮೂಲಗಳ ಮೂಲಕ ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂದರೆ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗಾಗಿ CPU ಸಮಯ ಮಿತಿಗಳು ಮತ್ತು RAM ಮಿತಿಗಳು.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲವನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದರ ಮೇಲೆ ಮಿತಿಯು ಹೆಚ್ಚಿನ ಮಿತಿಯನ್ನು ಇರಿಸುತ್ತದೆ. ಅಂದರೆ, ಅದರ ಪ್ರಕಾರ, ನೀವು ಮಿತಿಗಳಲ್ಲಿ 1GB RAM ಅನ್ನು ಹೇಳಿದರೆ, ನಂತರ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ 1GB RAM ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಅವನು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಬಯಸಿದರೆ ಮತ್ತು ಇದನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಓಮ್ ಕಿಲ್ಲರ್ ಎಂಬ ಪ್ರಕ್ರಿಯೆಯು ನೆನಪಿಲ್ಲದೆ, ಅಂದರೆ, ಬಂದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕೊಲ್ಲುತ್ತದೆ - ಅಂದರೆ, ಅದು ಸರಳವಾಗಿ ಮರುಪ್ರಾರಂಭಗೊಳ್ಳುತ್ತದೆ. CPU ಆಧರಿಸಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮರುಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. CPU ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಮಿತಿಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಳಸಲು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಯತ್ನಿಸಿದರೆ, CPU ಅನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ. ಇದು ಮಿತಿ - ಇದು ಮೇಲಿನ ಮಿತಿ.
ಮತ್ತು ಒಂದು ವಿನಂತಿ ಇದೆ. ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನೋಡ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಜನಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿವೆ ಎಂಬುದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಎಂಬುದು ವಿನಂತಿಯಾಗಿದೆ. ಅಂದರೆ, ವಿನಂತಿಯು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದು ರೀತಿಯ ಬದ್ಧತೆಯಾಗಿದೆ. ನಾನು ಏನನ್ನು ಬಳಸಬೇಕೆಂದು ಅದು ಹೇಳುತ್ತದೆ: "ನೀವು ನನಗೆ ಇಷ್ಟು CPU ಮತ್ತು ಇಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಕಾಯ್ದಿರಿಸಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ." ಅಂತಹ ಸರಳ ಸಾದೃಶ್ಯ. ನಾವು ಹೊಂದಿರುವ ನೋಡ್ ಹೊಂದಿದ್ದರೆ ಏನು, ನನಗೆ ಗೊತ್ತಿಲ್ಲ, ಒಟ್ಟು 8 ಸಿಪಿಯುಗಳು. ಮತ್ತು ಒಂದು ಪಾಡ್ ಅಲ್ಲಿಗೆ ಬರುತ್ತದೆ, ಅದರ ವಿನಂತಿಗಳು 1 CPU ಎಂದು ಹೇಳುತ್ತವೆ, ಅಂದರೆ ನೋಡ್‌ನಲ್ಲಿ 7 CPU ಗಳು ಉಳಿದಿವೆ. ಅಂದರೆ, ಅದರ ಪ್ರಕಾರ, ಈ ನೋಡ್‌ಗೆ 8 ಪಾಡ್‌ಗಳು ಬಂದ ತಕ್ಷಣ, ಪ್ರತಿಯೊಂದೂ ತಮ್ಮ ವಿನಂತಿಗಳಲ್ಲಿ 1 ಸಿಪಿಯು ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ, ನೋಡ್, ಕುಬರ್ನೆಟ್ಸ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸಿಪಿಯು ಮುಗಿದಿದೆ ಮತ್ತು ವಿನಂತಿಗಳೊಂದಿಗೆ ಹೆಚ್ಚಿನ ಪಾಡ್‌ಗಳು ಇರುವಂತಿಲ್ಲ ಈ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಎಲ್ಲಾ ನೋಡ್‌ಗಳು CPU ಖಾಲಿಯಾದರೆ, CPU ಖಾಲಿಯಾದ ಕಾರಣ ನಿಮ್ಮ ಪಾಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸೂಕ್ತ ನೋಡ್‌ಗಳಿಲ್ಲ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ ಹೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.
ವಿನಂತಿಗಳು ಏಕೆ ಬೇಕು ಮತ್ತು ವಿನಂತಿಗಳಿಲ್ಲದೆಯೇ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಏನನ್ನೂ ಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ? ಒಂದು ಕಾಲ್ಪನಿಕ ಪರಿಸ್ಥಿತಿಯನ್ನು ಊಹಿಸೋಣ. ನೀವು ವಿನಂತಿಗಳಿಲ್ಲದೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ, ಕುಬರ್ನೆಟ್ಸ್ ನಿಮ್ಮ ಬಳಿ ಎಷ್ಟು ಇದೆ, ಯಾವ ನೋಡ್‌ಗಳಿಗೆ ನೀವು ಅದನ್ನು ತಳ್ಳಬಹುದು ಎಂದು ತಿಳಿದಿಲ್ಲ. ಸರಿ, ಅವನು ನೋಡ್ಗಳ ಮೇಲೆ ತಳ್ಳುತ್ತಾನೆ, ತಳ್ಳುತ್ತಾನೆ, ತಳ್ಳುತ್ತಾನೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನೀವು ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಒಂದು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಮಿತಿಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಹತ್ತಿರದಲ್ಲಿ ಮತ್ತೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಇದೆ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ನೋಡ್ ವಾಸ್ತವವಾಗಿ ಭೌತಿಕವಾಗಿ ಸಂಪನ್ಮೂಲಗಳಿಂದ ಹೊರಗುಳಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, OP. ನೋಡ್ ವಾಸ್ತವವಾಗಿ ಭೌತಿಕವಾಗಿ ಸಂಪನ್ಮೂಲಗಳಿಂದ ಹೊರಗುಳಿಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಯಾದೃಚ್ಛಿಕ ಪ್ರವೇಶ ಮೆಮೊರಿ (RAM). ನೋಡ್‌ನ ಶಕ್ತಿಯು ಖಾಲಿಯಾದಾಗ, ಮೊದಲು ಡಾಕರ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ನಂತರ ಕ್ಯೂಬ್ಲೆಟ್, ನಂತರ ಓಎಸ್. ಅವರು ಸುಮ್ಮನೆ ಪ್ರಜ್ಞಾಹೀನರಾಗುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲವೂ ಖಂಡಿತವಾಗಿಯೂ ನಿಮಗಾಗಿ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಅಂದರೆ, ಇದು ನಿಮ್ಮ ನೋಡ್ ಸಿಲುಕಿಕೊಳ್ಳಲು ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಗುತ್ತದೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಪರಿಸ್ಥಿತಿ ತುಂಬಾ ಉತ್ತಮವಾಗಿಲ್ಲ.
ಮತ್ತು ನೀವು ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿರುವಾಗ, ಮಿತಿಗಳು ತುಂಬಾ ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ, ಕನಿಷ್ಠ ಮಿತಿಗಳು ಅಥವಾ ವಿನಂತಿಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಪಟ್ಟು ಹೆಚ್ಚಿಲ್ಲ, ನಂತರ ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಾಮಾನ್ಯ, ತರ್ಕಬದ್ಧ ಭರ್ತಿಯನ್ನು ಹೊಂದಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕುಬರ್ನೆಟೆಸ್‌ಗೆ ಅದು ಎಲ್ಲಿ ಎಷ್ಟು ಹಾಕುತ್ತದೆ, ಯಾವುದನ್ನು ಎಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅಂದಾಜು ತಿಳಿದಿರುತ್ತದೆ. ಅಂದರೆ, ಇದು ಕೇವಲ ಅಂತಹ ಕ್ಷಣವಾಗಿದೆ. ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ. ಮತ್ತು ಇದನ್ನು ಸೂಚಿಸಲಾಗಿದೆ ಎಂದು ನಿಯಂತ್ರಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಡೇಟಾ ಸಂಗ್ರಹಣೆ
ನಮ್ಮ ಮುಂದಿನ ಅಂಶವು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಬಗ್ಗೆ. ಅವರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಿರಂತರತೆಯಿಂದ ಏನು ಮಾಡಬೇಕು?
ಮತ್ತೊಮ್ಮೆ, ನಮ್ಮೊಳಗೆ ನಾನು ಭಾವಿಸುತ್ತೇನೆ , ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಬಗ್ಗೆ ಒಂದು ವಿಷಯವಿತ್ತು. ಮತ್ತು "ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವೇ?" ಎಂದು ಕೇಳಿದಾಗ ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ನಿಮಗೆ ಏನು ಹೇಳಿದರು ಎಂದು ನನಗೆ ಸ್ಥೂಲವಾಗಿ ತಿಳಿದಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವೇ ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ನೀವು ಕೇಳುತ್ತಿದ್ದರೆ, ಅದು ಅಸಾಧ್ಯವೆಂದು ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ನಿಮಗೆ ಹೇಳಬೇಕೆಂದು ನನಗೆ ತೋರುತ್ತದೆ.
ಇಲ್ಲಿ ತರ್ಕ ಸರಳವಾಗಿದೆ. ಒಂದು ವೇಳೆ, ನಾನು ಮತ್ತೊಮ್ಮೆ ವಿವರಿಸುತ್ತೇನೆ, ನೀವು ವಿತರಿಸಿದ ನೆಟ್‌ವರ್ಕ್ ಸಂಗ್ರಹಣೆಯ ಸಾಕಷ್ಟು ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವ ನಿಜವಾಗಿಯೂ ತಂಪಾದ ವ್ಯಕ್ತಿಯಾಗಿದ್ದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು, ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ. ಹೆಚ್ಚಾಗಿ, ಅದನ್ನು ಹೇಗೆ ಚಲಾಯಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಿಮಗೆ ಯಾವುದೇ ಪ್ರಶ್ನೆಯಿಲ್ಲ. ನೀವು ಅಂತಹ ಪ್ರಶ್ನೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಮತ್ತು ಅದು ಎಲ್ಲಾ ತೆರೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಾವಿಗೆ ಸರಿಯಾಗಿ ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಬೀಳುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ಬಯಸಿದರೆ, ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ. ಈ ವಿಧಾನದಿಂದ ನಿಮ್ಮನ್ನು ಪಾದದಲ್ಲಿ ಶೂಟ್ ಮಾಡುವುದು ಖಾತರಿಯಾಗಿದೆ. ಹಾಗಾಗಿ ಮಾಡದಿರುವುದು ಉತ್ತಮ.
ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಂಗ್ರಹಿಸಲು ಬಯಸುವ ಡೇಟಾ, ಬಳಕೆದಾರರು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಕೆಲವು ಚಿತ್ರಗಳು, ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಉತ್ಪಾದಿಸುವ ಕೆಲವು ವಿಷಯಗಳು, ಉದಾಹರಣೆಗೆ ಪ್ರಾರಂಭದಲ್ಲಿ ನಾವು ಏನು ಮಾಡಬೇಕು? ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅವರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?
ಸಾಮಾನ್ಯವಾಗಿ, ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಹೌದು, ಸಹಜವಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಆರಂಭದಲ್ಲಿ ಸ್ಥಿತಿಯಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಕಲ್ಪಿಸಲಾಗಿದೆ. ಅಂದರೆ, ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ. ಇದು ಆದರ್ಶವಾಗಿದೆ.
ಆದರೆ, ಸಹಜವಾಗಿ, ಆದರ್ಶ ಆಯ್ಕೆಯು ಯಾವಾಗಲೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಏನೀಗ? ಮೊದಲ ಮತ್ತು ಸರಳವಾದ ಅಂಶವೆಂದರೆ ಕೆಲವು ರೀತಿಯ S3 ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು, ಕೇವಲ ಮನೆಯಲ್ಲಿ ತಯಾರಿಸಿದ ಒಂದಲ್ಲ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಅಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ಕೆಲವು ಪೂರೈಕೆದಾರರಿಂದ. ಉತ್ತಮ, ಸಾಮಾನ್ಯ ಪೂರೈಕೆದಾರ - ಮತ್ತು S3 ಅನ್ನು ಬಳಸಲು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಲಿಸಿ. ಅಂದರೆ, ನಿಮ್ಮ ಬಳಕೆದಾರರು ಫೈಲ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಬಯಸಿದಾಗ, "ಇಲ್ಲಿ, ದಯವಿಟ್ಟು, ಅದನ್ನು S3 ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ" ಎಂದು ಹೇಳಿ. ಅವನು ಅದನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸಿದಾಗ, ಹೇಳಿ: "ಇಲ್ಲಿ S3 ಗೆ ಲಿಂಕ್ ಇದೆ ಮತ್ತು ಅದನ್ನು ಇಲ್ಲಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ." ಇದು ಆದರ್ಶವಾಗಿದೆ.
ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಕೆಲವು ಕಾರಣಗಳಿಂದ ಈ ಆದರ್ಶ ಆಯ್ಕೆಯು ಸೂಕ್ತವಲ್ಲದಿದ್ದರೆ, ನೀವು ಬರೆಯದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೀವು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದಿಲ್ಲ, ಅಥವಾ ಇದು ಕೆಲವು ರೀತಿಯ ಭಯಾನಕ ಪರಂಪರೆಯಾಗಿದೆ, ಇದು S3 ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬೇಕು ಸ್ಥಳೀಯ ಫೋಲ್ಡರ್‌ಗಳು. ಹೆಚ್ಚು ಕಡಿಮೆ ಸರಳವಾದದ್ದನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ನಿಯೋಜಿಸಿ. ಅಂದರೆ, ಕೆಲವು ಕನಿಷ್ಠ ಕಾರ್ಯಗಳಿಗಾಗಿ ತಕ್ಷಣವೇ ಸೆಫ್ ಅನ್ನು ಬೇಲಿ ಹಾಕುವುದು, ನನಗೆ ತೋರುತ್ತದೆ, ಇದು ಕೆಟ್ಟ ಕಲ್ಪನೆಯಾಗಿದೆ. ಏಕೆಂದರೆ Ceph, ಸಹಜವಾಗಿ, ಒಳ್ಳೆಯದು ಮತ್ತು ಫ್ಯಾಶನ್ ಆಗಿದೆ. ಆದರೆ ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಅರ್ಥವಾಗದಿದ್ದರೆ, ಒಮ್ಮೆ ನೀವು ಸೆಫ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಹಾಕಿದರೆ, ನೀವು ಅದನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ಸರಳವಾಗಿ ಅಲ್ಲಿಂದ ಎಂದಿಗೂ ಹೊರತೆಗೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಏಕೆಂದರೆ, ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, Ceph ತನ್ನ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬೈನರಿ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಸರಳ ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಅಲ್ಲ. ಆದ್ದರಿಂದ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ Ceph ಕ್ಲಸ್ಟರ್ ಮುರಿದುಹೋದರೆ, ನಂತರ ನೀವು ಅಲ್ಲಿಂದ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಎಂದಿಗೂ ಪಡೆಯುವುದಿಲ್ಲ ಎಂಬ ಸಂಪೂರ್ಣ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯಿದೆ.
ನಾವು Ceph ನಲ್ಲಿ ಕೋರ್ಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನೀವು ಮಾಡಬಹುದು .
ಆದ್ದರಿಂದ, NFS ಸರ್ವರ್‌ನಂತಹ ಸರಳವಾದದ್ದನ್ನು ಮಾಡುವುದು ಉತ್ತಮ. ಕುಬರ್ನೆಟ್ಸ್ ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು, ನೀವು NFS ಸರ್ವರ್ ಅಡಿಯಲ್ಲಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ಆರೋಹಿಸಬಹುದು - ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಂತೆಯೇ ಇರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ವಾಭಾವಿಕವಾಗಿ, ನೀವು ಮತ್ತೆ, ನಿಮ್ಮ NFS ನೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಕೆಲವೊಮ್ಮೆ ಅದು ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಏನು ಮಾಡುತ್ತೀರಿ ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಗಣಿಸಬೇಕು ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಬಹುಶಃ ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಗಣಕದಲ್ಲಿ ಎಲ್ಲೋ ಬ್ಯಾಕಪ್ ಮಾಡಬೇಕು.
ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲವು ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸಿದರೆ ಏನು ಮಾಡಬೇಕೆಂದು ನಾನು ಮಾತನಾಡಿದ ಮುಂದಿನ ಅಂಶವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಅದು ಪ್ರಾರಂಭವಾದಾಗ, ಇದು ಕೆಲವು ಸ್ಥಿರ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಸ್ವೀಕರಿಸುವ ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಆಧರಿಸಿದೆ. ಎಂತಹ ಕ್ಷಣ. ಅಂತಹ ಹೆಚ್ಚಿನ ಡೇಟಾ ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ತಲೆಕೆಡಿಸಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ, ನಿಮಗಾಗಿ ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ಕೆಲಸ ಮಾಡಿ. ಇಲ್ಲಿ ಒಂದೇ ಪ್ರಶ್ನೆ ಏನು, ನೋಡಿ. ಆಗಾಗ್ಗೆ, ವರ್ಡ್ಪ್ರೆಸ್ ಮತ್ತು ಮುಂತಾದ ಎಲ್ಲಾ ರೀತಿಯ ಪರಂಪರೆ ವ್ಯವಸ್ಥೆಗಳು, ವಿಶೇಷವಾಗಿ ಮಾರ್ಪಡಿಸಿದ ಕೆಲವು ರೀತಿಯ ಕುತಂತ್ರ ಪ್ಲಗಿನ್‌ಗಳು, ಕುತಂತ್ರ ಪಿಎಚ್‌ಪಿ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ, ಅವರು ಅದನ್ನು ಹೇಗೆ ತಯಾರಿಸಬೇಕೆಂದು ತಿಳಿದಿರುತ್ತಾರೆ ಇದರಿಂದ ಅವರು ತಮಗಾಗಿ ಕೆಲವು ರೀತಿಯ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತಾರೆ. ಅದರಂತೆ, ಒಂದು ಫೈಲ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಎರಡನೇ ಫೈಲ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಅವರು ವಿಭಿನ್ನವಾಗಿವೆ. ಕ್ಲೈಂಟ್‌ಗಳ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಮತೋಲನವು ಆಕಸ್ಮಿಕವಾಗಿ ಸಂಭವಿಸುತ್ತದೆ. ಅಂತೆಯೇ, ಉದಾಹರಣೆಗೆ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿಲ್ಲ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಒಬ್ಬರು ಒಂದು ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತಾರೆ, ಇನ್ನೊಂದು ಬಳಕೆದಾರರಿಗೆ ಮತ್ತೊಂದು ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಇದು ನೀವು ತಪ್ಪಿಸಬೇಕಾದ ವಿಷಯ. ಅಂದರೆ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ, ನೀವು ಪ್ರಾರಂಭಿಸುವ ಎಲ್ಲವೂ ಬಹು ನಿದರ್ಶನಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿದೆ. ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಚಲಿಸುವ ವಸ್ತುವಾಗಿದೆ. ಅದರಂತೆ, ಅವನು ತನಗೆ ಬೇಕಾದಾಗ, ಯಾರನ್ನೂ ಕೇಳದೆ ಏನು ಬೇಕಾದರೂ ಚಲಿಸಬಹುದು. ಆದ್ದರಿಂದ, ನೀವು ಇದನ್ನು ಲೆಕ್ಕ ಹಾಕಬೇಕು. ಒಂದು ನಿದರ್ಶನದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದ ಎಲ್ಲವೂ ಬೇಗ ಅಥವಾ ನಂತರ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ನೀವು ಹೆಚ್ಚು ಮೀಸಲಾತಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಉತ್ತಮ. ಆದರೆ ಮತ್ತೆ, ನಾನು ಹೇಳುತ್ತೇನೆ, ನೀವು ಅಂತಹ ಕೆಲವು ಫೈಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಅವುಗಳನ್ನು ನಿಮ್ಮ ಕೆಳಗೆ ಇಡಬಹುದು, ಅವು ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ತೂಗುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಇದ್ದರೆ, ನೀವು ಬಹುಶಃ ಅವುಗಳನ್ನು ಕಂಟೇನರ್ ಒಳಗೆ ತಳ್ಳಬಾರದು.
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಂತಹ ಅದ್ಭುತ ವಿಷಯವಿದೆ ಎಂದು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ, ನೀವು ಪರಿಮಾಣವನ್ನು ಬಳಸಬಹುದು. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಟೈಪ್ ಖಾಲಿ ಡಿರ್ ಪರಿಮಾಣವಿದೆ. ಅಂದರೆ, ನೀವು ಪ್ರಾರಂಭಿಸಿದ ಸರ್ವರ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ತನ್ನ ಸೇವಾ ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸುತ್ತದೆ. ಮತ್ತು ಅವನು ಅದನ್ನು ನಿಮಗೆ ಕೊಡುತ್ತಾನೆ ಇದರಿಂದ ನೀವು ಅದನ್ನು ಬಳಸಬಹುದು. ಒಂದೇ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಿದೆ. ಅಂದರೆ, ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ, ಬದಲಿಗೆ ನೀವು ಚಾಲನೆಯಲ್ಲಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ. ಇದಲ್ಲದೆ, ಕುಬರ್ನೆಟ್ಸ್ ಸಾಮಾನ್ಯ ಸಂರಚನೆಯ ಅಡಿಯಲ್ಲಿ ಅಂತಹ ಖಾಲಿ ಡಿರ್ಗಳನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು ಮತ್ತು ಅವುಗಳ ಗರಿಷ್ಠ ಗಾತ್ರವನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮೀರಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಒಂದೇ ಅಂಶವೆಂದರೆ ನೀವು ಖಾಲಿ ಡಿರ್‌ನಲ್ಲಿ ಬರೆದದ್ದು ಪಾಡ್ ಮರುಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ. ಅಂದರೆ, ನಿಮ್ಮ ಪಾಡ್ ತಪ್ಪಾಗಿ ಬಿದ್ದು ಮತ್ತೆ ಮೇಲೆದ್ದರೆ, ಖಾಲಿ ದಿರ್‌ನಲ್ಲಿರುವ ಮಾಹಿತಿಯು ಎಲ್ಲಿಯೂ ಹೋಗುವುದಿಲ್ಲ. ಅವನು ಅದನ್ನು ಹೊಸ ಪ್ರಾರಂಭದಲ್ಲಿ ಮತ್ತೆ ಬಳಸಬಹುದು - ಮತ್ತು ಅದು ಒಳ್ಳೆಯದು. ನಿಮ್ಮ ಪಾಡ್ ಎಲ್ಲೋ ಬಿಟ್ಟರೆ, ಸ್ವಾಭಾವಿಕವಾಗಿ ಅವನು ಡೇಟಾ ಇಲ್ಲದೆ ಹೋಗುತ್ತಾನೆ. ಅಂದರೆ, ಖಾಲಿ ಡಿರ್‌ನೊಂದಿಗೆ ಲಾಂಚ್ ಮಾಡಿದ ನೋಡ್‌ನಿಂದ ಪಾಡ್ ಕಣ್ಮರೆಯಾದ ತಕ್ಷಣ, ಖಾಲಿ ಡಿರ್ ಅನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ.
ಖಾಲಿ ದಿರ್‌ನಲ್ಲಿ ಇನ್ನೇನು ಒಳ್ಳೆಯದು? ಉದಾಹರಣೆಗೆ, ಇದನ್ನು ಸಂಗ್ರಹವಾಗಿ ಬಳಸಬಹುದು. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಹಾರಾಡುತ್ತ ಏನನ್ನಾದರೂ ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ನೀಡುತ್ತದೆ ಮತ್ತು ದೀರ್ಘಕಾಲದವರೆಗೆ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸೋಣ. ಆದ್ದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್, ಉದಾಹರಣೆಗೆ, ಅದನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ನೀಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂದಿನ ಬಾರಿ ಬಳಕೆದಾರರು ಅದೇ ವಿಷಯಕ್ಕೆ ಬಂದಾಗ, ಅದನ್ನು ತಕ್ಷಣವೇ ರಚಿಸುವುದು ವೇಗವಾಗಿರುತ್ತದೆ. ಮೆಮೊರಿಯಲ್ಲಿ ರಚಿಸಲು ಖಾಲಿ ಡಿರ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಕೇಳಬಹುದು. ಹೀಗಾಗಿ, ನಿಮ್ಮ ಸಂಗ್ರಹಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮಿಂಚಿನ ವೇಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು - ಡಿಸ್ಕ್ ಪ್ರವೇಶ ವೇಗದ ವಿಷಯದಲ್ಲಿ. ಅಂದರೆ, ನೀವು ಮೆಮೊರಿಯಲ್ಲಿ ಖಾಲಿ ಡಿರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, OS ನಲ್ಲಿ ಅದನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ನಿಮಗಾಗಿ, ಪಾಡ್‌ನೊಳಗಿನ ಬಳಕೆದಾರರಿಗೆ, ಇದು ಕೇವಲ ಸ್ಥಳೀಯ ಡೈರೆಕ್ಟರಿಯಂತೆ ಕಾಣುತ್ತದೆ. ಯಾವುದೇ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕಲಿಸಲು ನಿಮಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ನೇರವಾಗಿ ತೆಗೆದುಕೊಂಡು ನಿಮ್ಮ ಫೈಲ್ ಅನ್ನು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಇರಿಸಿ, ಆದರೆ, ವಾಸ್ತವವಾಗಿ, OS ನಲ್ಲಿ ಮೆಮೊರಿಯಲ್ಲಿ. ಕುಬರ್ನೆಟ್ಸ್ ವಿಷಯದಲ್ಲಿ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
Minio ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ? ಮಿನಿಯೊದ ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ಈ ವಿಷಯವು ಕೆಲಸ ಮಾಡಲು, ಅದು ಎಲ್ಲೋ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಇರಬೇಕು, ಅಂದರೆ, ಸಂಗ್ರಹಣೆ. ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಸೆಫ್ ಹೊಂದಿರುವ ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ. ಅಂದರೆ, ಮಿನಿಯೊ ತನ್ನ ಫೈಲ್‌ಗಳನ್ನು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಬೇಕು. ಇದು ಕೇವಲ ನಿಮ್ಮ ಫೈಲ್‌ಗಳಿಗೆ HTTP ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆ. ಇದಲ್ಲದೆ, ಅಮೆಜಾನ್‌ನ S3 ಗಿಂತ ಕ್ರಿಯಾತ್ಮಕತೆಯು ಸ್ಪಷ್ಟವಾಗಿ ಕಳಪೆಯಾಗಿದೆ. ಹಿಂದೆ, ಇದು ಬಳಕೆದಾರರನ್ನು ಸರಿಯಾಗಿ ಅಧಿಕೃತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಈಗ, ನನಗೆ ತಿಳಿದಿರುವಂತೆ, ಇದು ಈಗಾಗಲೇ ವಿಭಿನ್ನ ಅಧಿಕಾರಗಳೊಂದಿಗೆ ಬಕೆಟ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು, ಆದರೆ ಮತ್ತೊಮ್ಮೆ, ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ಮಾತನಾಡಲು, ಕನಿಷ್ಠ ಆಧಾರವಾಗಿರುವ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.
ಮೆಮೊರಿಯಲ್ಲಿನ ಖಾಲಿ ಡಿರ್ ಮಿತಿಗಳ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ? ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಮಿತಿಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಇದು ಹೋಸ್ಟ್‌ನ ಸ್ಮರಣೆಯಲ್ಲಿದೆ ಮತ್ತು ನಿಮ್ಮ ಕಂಟೇನರ್‌ನ ಸ್ಮರಣೆಯಲ್ಲಿ ಅಲ್ಲ. ಅಂದರೆ, ನಿಮ್ಮ ಕಂಟೈನರ್ ಮೆಮೊರಿಯಲ್ಲಿ ಖಾಲಿ ಡಿರ್ ಅನ್ನು ಅದರ ಆಕ್ರಮಿತ ಮೆಮೊರಿಯ ಭಾಗವಾಗಿ ನೋಡುವುದಿಲ್ಲ. ಹೋಸ್ಟ್ ಇದನ್ನು ನೋಡುತ್ತಾನೆ. ಅಂತೆಯೇ, ಹೌದು, ಕುಬರ್ನೆಟ್‌ಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ, ನೀವು ಇದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನೀವು ನಿಮ್ಮ ಸ್ಮರಣೆಯ ಭಾಗವನ್ನು ಖಾಲಿ ಡಿರ್‌ಗೆ ವಿನಿಯೋಗಿಸುತ್ತಿರುವಿರಿ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು. ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದಾಗಿ ಮೆಮೊರಿಯು ಖಾಲಿಯಾಗಬಹುದು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ಆದರೆ ಯಾರಾದರೂ ಈ ಖಾಲಿ ಡಿರ್‌ಗಳಿಗೆ ಬರೆಯುತ್ತಾರೆ.
ಮೇಘಸ್ವರೂಪತೆ
ಮತ್ತು ಕ್ಲೌಡ್ನೇಟಿವ್ ಎಂದರೇನು ಎಂಬುದು ಅಂತಿಮ ಉಪವಿಷಯವಾಗಿದೆ. ಅದು ಏಕೆ ಬೇಕು? ಕ್ಲೌಡ್ನೇಟಿವ್ನೆಸ್ ಮತ್ತು ಹೀಗೆ.
ಅಂದರೆ, ಆಧುನಿಕ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಸಮರ್ಥವಾಗಿರುವ ಮತ್ತು ಬರೆಯಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು. ಆದರೆ, ವಾಸ್ತವವಾಗಿ, ಕ್ಲೌಡ್ನೇಟಿವ್ ಅಂತಹ ಇನ್ನೊಂದು ಅಂಶವನ್ನು ಹೊಂದಿದೆ. ಇದು ಆಧುನಿಕ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯದ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಮಾತ್ರವಲ್ಲ, ಆದರೆ ಈ ಆಧುನಿಕ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿದೆ, ಈ ಮೋಡಗಳಲ್ಲಿ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ಅಂಶದ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳ ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳಿ. ಕೇವಲ ಅತಿರೇಕಕ್ಕೆ ಹೋಗಬೇಡಿ ಮತ್ತು ಮೋಡಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಡಿ, ಆದರೆ ಮೋಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರಯೋಜನಗಳ ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳಿ.
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಯಾವಾಗಲೂ ಅಥವಾ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಿರ್ವಾಹಕರು ಯಾವಾಗಲೂ ಸೇವಾ ಖಾತೆಯನ್ನು ರಚಿಸಬಹುದು. ಅಂದರೆ, ಅದರ ಸರ್ವರ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿಯೇ ದೃಢೀಕರಣಕ್ಕಾಗಿ ಖಾತೆ. ಅಲ್ಲಿ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕೆಲವು ಹಕ್ಕುಗಳನ್ನು ಸೇರಿಸಿ. ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದಲೇ ನೀವು ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸಬಹುದು. ನೀವು ಈ ರೀತಿಯಲ್ಲಿ ಏನು ಮಾಡಬಹುದು? ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ, ನಿಮ್ಮ ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಇತರ ರೀತಿಯ ನಿದರ್ಶನಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದರ ಕುರಿತು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಹೇಗಾದರೂ ಕ್ಲಸ್ಟರ್, ಅಂತಹ ಅಗತ್ಯವಿದ್ದಲ್ಲಿ.
ಮತ್ತೊಮ್ಮೆ, ನಾವು ಅಕ್ಷರಶಃ ಇತ್ತೀಚೆಗೆ ಒಂದು ಪ್ರಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸರದಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಒಬ್ಬ ನಿಯಂತ್ರಕವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಈ ಸರದಿಯಲ್ಲಿ ಕೆಲವು ಹೊಸ ಕಾರ್ಯಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅದು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಹೋಗುತ್ತದೆ - ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ ಅದು ಹೊಸ ಪಾಡ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಈ ಪಾಡ್‌ಗೆ ಕೆಲವು ಹೊಸ ಕೆಲಸವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಈ ಪಾಡ್‌ನ ಚೌಕಟ್ಟಿನೊಳಗೆ, ಪಾಡ್ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ನಿಯಂತ್ರಕಕ್ಕೆ ಸ್ವತಃ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ನಿಯಂತ್ರಕವು ಈ ಮಾಹಿತಿಯೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಇದು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅಂದರೆ, ಮತ್ತೊಮ್ಮೆ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂಬ ಅಂಶದ ಪ್ಲಸ್ ಆಗಿದೆ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯವನ್ನು ಹೇಗಾದರೂ ವಿಸ್ತರಿಸಲು ಮತ್ತು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿಸಲು ನಾವು ಅಂತರ್ನಿರ್ಮಿತ ಕುಬರ್ನೆಟ್ಸ್ ಕಾರ್ಯವನ್ನು ಬಳಸಬಹುದು. ಅಂದರೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು, ಕೆಲಸಗಾರನನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ರೀತಿಯ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಮರೆಮಾಡಬೇಡಿ. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲ್ಪಟ್ಟಿದ್ದರೆ ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ.
ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಮೀರಿ ಹೋದರೆ ಅದೇ ಅನ್ವಯಿಸುತ್ತದೆ. ನಮ್ಮ ಕುಬರ್ನೆಟ್ಗಳು ಎಲ್ಲೋ ಓಡುತ್ತಿದ್ದಾರೆ - ಅದು ಕೆಲವು ರೀತಿಯ ಮೋಡದಲ್ಲಿದ್ದರೆ ಒಳ್ಳೆಯದು. ಮತ್ತೊಮ್ಮೆ, ನಾವು ಚಾಲನೆಯಲ್ಲಿರುವ ಮೋಡದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಾವು ಬಳಸಬಹುದು ಮತ್ತು ಬಳಸಬೇಕು ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಮೋಡವು ನಮಗೆ ಒದಗಿಸುವ ಪ್ರಾಥಮಿಕ ವಿಷಯಗಳಿಂದ. ಸಮತೋಲನ, ಅಂದರೆ, ನಾವು ಕ್ಲೌಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಇದು ನಾವು ಬಳಸಬಹುದಾದ ನೇರ ಪ್ರಯೋಜನವಾಗಿದೆ. ಏಕೆಂದರೆ ಕ್ಲೌಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್, ಮೊದಲನೆಯದಾಗಿ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ನಮ್ಮಿಂದ ಜವಾಬ್ದಾರಿಯನ್ನು ಮೂರ್ಖತನದಿಂದ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಜೊತೆಗೆ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಾಮಾನ್ಯ ಕುಬರ್ನೆಟ್ಗಳು ಮೋಡಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು.
ಅದೇ ಸ್ಕೇಲಿಂಗ್ಗೆ ಹೋಗುತ್ತದೆ. ನಿಯಮಿತ ಕುಬರ್ನೆಟ್ಗಳು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು. ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳಿಂದ ಖಾಲಿಯಾಗಿದ್ದರೆ, ಅಂದರೆ, ನೋಡ್ ಸ್ಪೇಸ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ನೀವು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ತಿಳಿದಿದೆ - ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಅಂದರೆ, ನಿಮ್ಮ ಹೊರೆ ಬಂದಾಗ, ಒಲೆಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾಗಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಈ ಪಾಡ್‌ಗಳಿಗೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ನೋಡ್‌ಗಳು ಖಾಲಿಯಾದಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯು ಇನ್ನೂ ಹೆಚ್ಚಾಗಬಹುದು. ಮತ್ತು ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ. ಫ್ಲೈನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಅಳೆಯಲು ಇದು ನೇರ ಅವಕಾಶವಾಗಿದೆ. ತುಂಬಾ ವೇಗವಾಗಿಲ್ಲ, ಅದು ಸೆಕೆಂಡ್ ಅಲ್ಲ ಎಂಬ ಅರ್ಥದಲ್ಲಿ, ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಇದು ಒಂದು ನಿಮಿಷದಂತಿದೆ.
ಆದರೆ ನನ್ನ ಅನುಭವದಿಂದ, ಮತ್ತೊಮ್ಮೆ, ಇದು ನಾನು ನೋಡಿದ ತಂಪಾದ ವಿಷಯವಾಗಿದೆ. ದಿನದ ಸಮಯವನ್ನು ಆಧರಿಸಿ ಕ್ಲೌಡ್ನೇಟಿವ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಕೇಲ್ ಮಾಡಿದಾಗ. ಇದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯಾಗಿದ್ದು ಅದನ್ನು ಬ್ಯಾಕ್ ಆಫೀಸ್‌ನಲ್ಲಿ ಜನರು ಬಳಸುತ್ತಿದ್ದರು. ಅಂದರೆ, ಅವರು ಬೆಳಿಗ್ಗೆ 9 ಗಂಟೆಗೆ ಕೆಲಸಕ್ಕೆ ಬರುತ್ತಾರೆ, ಸಿಸ್ಟಮ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಕ್ಲೌಡ್ನೇಟಿವ್ ಕ್ಲಸ್ಟರ್, ಎಲ್ಲವೂ ಚಾಲನೆಯಲ್ಲಿದೆ, ಊದಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಇದರಿಂದ ಕೆಲಸಕ್ಕೆ ಬರುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಅವರು 8 ಗಂಟೆಗೆ ಅಥವಾ ಸಂಜೆ 6 ಗಂಟೆಗೆ ಕೆಲಸವನ್ನು ತೊರೆದಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಯಾರೂ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತಿಲ್ಲ ಎಂದು ಗಮನಿಸುತ್ತಾರೆ ಮತ್ತು ಕುಗ್ಗಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. 30 ರಷ್ಟು ಉಳಿತಾಯ ಖಾತರಿಯಾಗಿದೆ. ಅದು ಆ ಸಮಯದಲ್ಲಿ ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿತು; ಆ ಸಮಯದಲ್ಲಿ ರಷ್ಯಾದಲ್ಲಿ ಅದನ್ನು ಉತ್ತಮವಾಗಿ ಮಾಡುವವರು ಯಾರೂ ಇರಲಿಲ್ಲ.
ನಾನು ನಿಮಗೆ ನೇರವಾಗಿ ಹೇಳುತ್ತೇನೆ, ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಮತ್ತು ಕ್ಲೌಡ್ನ ಸಾಮರ್ಥ್ಯಗಳ ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳುವುದರಿಂದ ಉಳಿತಾಯವು 30 ಪ್ರತಿಶತದಷ್ಟು ಇರುತ್ತದೆ. ಈಗ ಇದನ್ನು ರಷ್ಯಾದಲ್ಲಿ ಮಾಡಬಹುದು. ನಾನು ಯಾರಿಗೂ ಜಾಹೀರಾತು ನೀಡುವುದಿಲ್ಲ, ಆದರೆ ಇದನ್ನು ಮಾಡಬಹುದಾದ ಪೂರೈಕೆದಾರರು ಇದ್ದಾರೆ ಎಂದು ಹೇಳೋಣ, ಅದನ್ನು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಬಟನ್‌ನೊಂದಿಗೆ ಒದಗಿಸಿ.
ನಾನು ನಿಮ್ಮ ಗಮನವನ್ನು ಸೆಳೆಯಲು ಬಯಸುವ ಕೊನೆಯ ಅಂಶವಿದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್, ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ಕ್ಲೌಡ್ನೇಟಿವ್ ಆಗಲು, ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಎಂಬ ವಿಧಾನವನ್ನು ಕೋಡ್‌ನಂತೆ ಅಳವಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಅಂದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಬದಲಿಗೆ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ನಿಮ್ಮ ವಿವರಣೆಯ ಕೋಡ್‌ನಂತೆಯೇ ಅಗತ್ಯವಿದೆ. ಅಪ್ಲಿಕೇಶನ್, ಕೋಡ್ ರೂಪದಲ್ಲಿ ನಿಮ್ಮ ವ್ಯಾಪಾರ ತರ್ಕ. ಮತ್ತು ಅದರೊಂದಿಗೆ ಕೋಡ್ ಆಗಿ ಕೆಲಸ ಮಾಡಿ, ಅಂದರೆ, ಅದನ್ನು ಪರೀಕ್ಷಿಸಿ, ಅದನ್ನು ರೋಲ್ ಮಾಡಿ, ಅದನ್ನು ಜಿಟ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ, ಅದಕ್ಕೆ CICD ಅನ್ನು ಅನ್ವಯಿಸಿ.
ಮತ್ತು ಇದು ನಿಖರವಾಗಿ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಮೇಲೆ ಯಾವಾಗಲೂ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಲು, ಅದು ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಯಾವಾಗಲೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ಎರಡನೆಯದಾಗಿ, ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡುವ ಹಸ್ತಚಾಲಿತ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ತಪ್ಪಿಸಿ. ಮೂರನೆಯದಾಗಿ, ನೀವು ನಿರಂತರವಾಗಿ ಅದೇ ಹಸ್ತಚಾಲಿತ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾದಾಗ ವಹಿವಾಟು ಎಂದು ಕರೆಯುವುದನ್ನು ತಪ್ಪಿಸಿ. ನಾಲ್ಕನೆಯದಾಗಿ, ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ರಷ್ಯಾದಲ್ಲಿ, ನಾನು ಈ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗಲೆಲ್ಲಾ, "ಹೌದು, ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ ನಿಮಗೆ ವಿಧಾನಗಳಿವೆ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಯಾವುದನ್ನೂ ಸರಿಪಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ" ಎಂದು ಹೇಳುವ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಜನರು ಯಾವಾಗಲೂ ಇರುತ್ತಾರೆ. ಆದರೂ ಇದು ನಿಜ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಏನಾದರೂ ಮುರಿದುಹೋದರೆ, ಕ್ಲೌಡ್ನೇಟಿವ್ ವಿಧಾನದ ದೃಷ್ಟಿಕೋನದಿಂದ ಮತ್ತು ಕೋಡ್‌ನಂತೆ ಮೂಲಸೌಕರ್ಯಗಳ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅದನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು, ಸರ್ವರ್‌ಗೆ ಹೋಗುವುದು, ಮುರಿದುಹೋಗಿರುವುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮತ್ತು ಸರಿಪಡಿಸುವುದು ಸುಲಭ. ಸರ್ವರ್ ಅನ್ನು ಅಳಿಸಲು ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ರಚಿಸಲು. ಮತ್ತು ನಾನು ಇದೆಲ್ಲವನ್ನೂ ಪುನಃಸ್ಥಾಪಿಸುತ್ತೇನೆ.
ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಚರ್ಚಿಸಲಾಗಿದೆ . ಲಿಂಕ್ ಅನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ ನೀವು ಪ್ರೋಗ್ರಾಂ ಮತ್ತು ಷರತ್ತುಗಳೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಬಹುದು. ಅನುಕೂಲಕರ ವಿಷಯವೆಂದರೆ ನೀವು ದಿನಕ್ಕೆ 1-2 ಗಂಟೆಗಳ ಕಾಲ ಮನೆಯಿಂದ ಅಥವಾ ಕೆಲಸದಿಂದ ಅಧ್ಯಯನ ಮಾಡುವ ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಮೂಲ: www.habr.com