ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಿರ್ದಿಷ್ಟವಾಗಿ "ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ" ಅಥವಾ ಸರಳವಾಗಿ "ಕ್ಲೌಡ್" ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಅವುಗಳನ್ನು ವಿಶಿಷ್ಟವಾಗಿ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾದ ಸಡಿಲವಾಗಿ ಜೋಡಿಸಲಾದ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳ ಗುಂಪಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇವುಗಳನ್ನು ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಿಂದ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ವೈಫಲ್ಯಗಳಿಗೆ ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಗಂಭೀರ ಮೂಲಸೌಕರ್ಯ-ಮಟ್ಟದ ವೈಫಲ್ಯಗಳ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಅವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಅಳೆಯುತ್ತವೆ. ನಾಣ್ಯದ ಇನ್ನೊಂದು ಬದಿಯು ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವಿಧಿಸುವ ನಿರ್ಬಂಧಗಳ (ಒಪ್ಪಂದಗಳು) ಆಗಿದೆ.
ಕ್ಲೌಡ್-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಚಲಿಸುವ ಅಗತ್ಯತೆ ಮತ್ತು ಪ್ರಾಮುಖ್ಯತೆಯ ಬಗ್ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿರುವಾಗ, ಅನೇಕ ಸಂಸ್ಥೆಗಳಿಗೆ ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ. ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅನುಸರಿಸಿದರೆ, ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಸಾಮರ್ಥ್ಯವನ್ನು ಅರಿತುಕೊಳ್ಳಲು ಮತ್ತು ಐಟಿ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಗಂಭೀರ ವೈಫಲ್ಯಗಳ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಸಹ ವಿಶ್ವಾಸಾರ್ಹ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸಾಧಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಹಲವಾರು ತತ್ವಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಮಟ್ಟದ. ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಬಹುದಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದನ್ನು ಕಲಿಯುವುದು ಇಲ್ಲಿ ವಿವರಿಸಿರುವ ತತ್ವಗಳ ಅಂತಿಮ ಗುರಿಯಾಗಿದೆ.
ಸಾಫ್ಟ್ವೇರ್ ವಿನ್ಯಾಸ ತತ್ವಗಳು
ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಜಗತ್ತಿನಲ್ಲಿ, ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಅನುಸರಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ ನಿಯಮಗಳನ್ನು ತತ್ವಗಳು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. ಯಾವುದೇ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಅವುಗಳನ್ನು ಬಳಸಬಹುದು. ಪ್ರತಿಯೊಂದು ತತ್ವವು ತನ್ನದೇ ಆದ ಗುರಿಗಳನ್ನು ಹೊಂದಿದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳನ್ನು ಸಾಧಿಸುವ ಸಾಧನಗಳು. ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ರಚಿಸಲು ಹಲವಾರು ಮೂಲಭೂತ ತತ್ವಗಳಿವೆ, ಇದರಿಂದ ಉಳಿದೆಲ್ಲವೂ ಹರಿಯುತ್ತವೆ. ಮೂಲಭೂತ ತತ್ವಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳು ಇಲ್ಲಿವೆ:
- (ಅದನ್ನು ಸರಳವಾಗಿ ಇರಿಸಿ, ಮೂರ್ಖತನ) - ಅದನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸಬೇಡಿ;
- (ನಿಮ್ಮನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ) - ನೀವೇ ಪುನರಾವರ್ತಿಸಬೇಡಿ;
- (ನಿಮಗೆ ಇದು ಅಗತ್ಯವಿಲ್ಲ) - ತಕ್ಷಣವೇ ಅಗತ್ಯವಿಲ್ಲದ ಯಾವುದನ್ನಾದರೂ ರಚಿಸಬೇಡಿ;
- ಕಾಳಜಿಗಳ ಪ್ರತ್ಯೇಕತೆ - ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಿ.
ನೀವು ನೋಡುವಂತೆ, ಈ ತತ್ವಗಳು ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರಾಯೋಗಿಕ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಸಾಮಾನ್ಯ ಜ್ಞಾನದ ಪರಿಗಣನೆಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ ವರ್ಗಕ್ಕೆ ಸೇರಿವೆ, ಇದನ್ನು ಅನೇಕ ಅಭಿವರ್ಧಕರು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅವರು ನಿಯಮಿತವಾಗಿ ಉಲ್ಲೇಖಿಸುತ್ತಾರೆ.
ಇದಲ್ಲದೆ, ಇದೆ - ರಾಬರ್ಟ್ ಮಾರ್ಟಿನ್ ರೂಪಿಸಿದ ವಸ್ತು-ಆಧಾರಿತ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮತ್ತು ವಿನ್ಯಾಸದ ಮೊದಲ ಐದು ತತ್ವಗಳ ಒಂದು ಸೆಟ್. SOLID ವಿಶಾಲವಾದ, ಮುಕ್ತ-ಮುಕ್ತ, ಪೂರಕ ತತ್ವಗಳನ್ನು ಒಳಗೊಂಡಿದೆ-ಒಟ್ಟಿಗೆ ಅನ್ವಯಿಸಿದಾಗ-ಉತ್ತಮ ಸಾಫ್ಟ್ವೇರ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ.
SOLID ತತ್ವಗಳು OOP ಕ್ಷೇತ್ರಕ್ಕೆ ಸೇರಿವೆ ಮತ್ತು ತರಗತಿಗಳು, ಇಂಟರ್ಫೇಸ್‌ಗಳು ಮತ್ತು ಆನುವಂಶಿಕತೆಯಂತಹ ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ಪರಿಕಲ್ಪನೆಗಳ ಭಾಷೆಯಲ್ಲಿ ರೂಪಿಸಲಾಗಿದೆ. ಸಾದೃಶ್ಯದ ಮೂಲಕ, ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅಭಿವೃದ್ಧಿ ತತ್ವಗಳನ್ನು ಸಹ ರೂಪಿಸಬಹುದು, ಇಲ್ಲಿ ಮೂಲಭೂತ ಅಂಶವು ವರ್ಗವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಕಂಟೇನರ್. ಈ ತತ್ವಗಳನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ, ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಗುರಿಗಳು ಮತ್ತು ಉದ್ದೇಶಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಪೂರೈಸುವ ಕಂಟೈನರೈಸ್ಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನೀವು ರಚಿಸಬಹುದು.
ಕ್ಲೌಡ್-ಸ್ಥಳೀಯ ಕಂಟೈನರ್‌ಗಳು: Red Hat ವಿಧಾನ
ಇಂದು, ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತುಲನಾತ್ಮಕವಾಗಿ ಸುಲಭವಾಗಿ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಬಹುದು. ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು, ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿದೆ.
ಕೆಳಗೆ ವಿವರಿಸಿದ ವಿಚಾರಗಳಿಗೆ ಆಧಾರವು ವಿಧಾನವಾಗಿದೆ ಮತ್ತು ಮೂಲ ಕೋಡ್ ನಿರ್ವಹಣೆಯಿಂದ ಸ್ಕೇಲಿಂಗ್ ಮಾಡೆಲ್‌ಗಳವರೆಗೆ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ವಿವಿಧ ಅಂಶಗಳ ಕುರಿತು ಅನೇಕ ಇತರ ಕೆಲಸಗಳು. ವಿವರಿಸಿದ ತತ್ವಗಳು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕಂಟೈನರೈಸ್ಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತವೆ. ನಮ್ಮ ಚರ್ಚೆಯಲ್ಲಿನ ಮೂಲ ಅಂಶವೆಂದರೆ ಕಂಟೇನರ್ ಚಿತ್ರ, ಮತ್ತು ಟಾರ್ಗೆಟ್ ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಕಂಟೇನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಗಿದೆ. ಪ್ರಸ್ತಾವಿತ ತತ್ವಗಳ ಗುರಿಯು ಧಾರಕಗಳನ್ನು ರಚಿಸುವುದು, ಇದಕ್ಕಾಗಿ ವೇಳಾಪಟ್ಟಿ, ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಕಾರ್ಯಗಳನ್ನು ಹೆಚ್ಚಿನ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು. ತತ್ವಗಳನ್ನು ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿಲ್ಲ.
ಏಕ ಕಾಳಜಿ ತತ್ವ (SCP)
ಈ ತತ್ವವು ಅನೇಕ ವಿಧಗಳಲ್ಲಿ ಏಕ ಹೊಣೆಗಾರಿಕೆಯ ತತ್ವವನ್ನು ಹೋಲುತ್ತದೆ. ), ಇದು SOLID ಸೆಟ್‌ನ ಭಾಗವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ವಸ್ತುವು ಒಂದು ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರಬೇಕು ಮತ್ತು ಆ ಜವಾಬ್ದಾರಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವರ್ಗದಲ್ಲಿ ಆವರಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. SRP ಯ ಅಂಶವೆಂದರೆ ಪ್ರತಿಯೊಂದು ಜವಾಬ್ದಾರಿಯು ಬದಲಾವಣೆಗೆ ಕಾರಣವಾಗಿದೆ, ಮತ್ತು ಒಂದು ವರ್ಗವು ಬದಲಾವಣೆಗೆ ಒಂದೇ ಒಂದು ಕಾರಣವನ್ನು ಹೊಂದಿರಬೇಕು.
SCP ಯಲ್ಲಿ, OOP ವರ್ಗಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಕಂಟೈನರ್‌ನ ಉನ್ನತ ಮಟ್ಟದ ಅಮೂರ್ತತೆ ಮತ್ತು ವಿಶಾಲ ಉದ್ದೇಶವನ್ನು ಸೂಚಿಸಲು ನಾವು "ಜವಾಬ್ದಾರಿ" ಪದದ ಬದಲಿಗೆ "ಕಾಳಜಿ" ಎಂಬ ಪದವನ್ನು ಬಳಸುತ್ತೇವೆ. ಮತ್ತು SRP ಯ ಗುರಿಯು ಬದಲಾವಣೆಗೆ ಒಂದೇ ಒಂದು ಕಾರಣವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ SCP ಯ ಹಿಂದೆ ಕಂಟೇನರ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಮತ್ತು ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ವಿಸ್ತರಿಸುವ ಬಯಕೆಯಿದೆ. SRP ಅನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ ಮತ್ತು ಒಂದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸಂಪೂರ್ಣ ರೀತಿಯಲ್ಲಿ ಮಾಡುವ ಕಂಟೇನರ್ ಅನ್ನು ರಚಿಸುವ ಮೂಲಕ, ನೀವು ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಸಂದರ್ಭಗಳಲ್ಲಿ ಆ ಕಂಟೇನರ್ ಚಿತ್ರವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಸಾಧ್ಯತೆಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತೀರಿ.
SCP ತತ್ವವು ಪ್ರತಿ ಕಂಟೇನರ್ ಒಂದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಉತ್ತಮವಾಗಿ ಮಾಡಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಇದಲ್ಲದೆ, OOP ಜಗತ್ತಿನಲ್ಲಿ SRP ಗಿಂತ ಕಂಟೇನರ್ ಜಗತ್ತಿನಲ್ಲಿ SCP ಸಾಧಿಸಲು ಸುಲಭವಾಗಿದೆ, ಏಕೆಂದರೆ ಕಂಟೇನರ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಡೆಸುತ್ತವೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಮಯ ಈ ಪ್ರಕ್ರಿಯೆಯು ಒಂದೇ ಕೆಲಸವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಕಂಟೇನರ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪರಿಹರಿಸಬೇಕಾದರೆ, ಅದನ್ನು ಏಕ-ಕಾರ್ಯ ಕಂಟೇನರ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು ಮತ್ತು ಸೈಡ್‌ಕಾರ್ ಮತ್ತು ಇನಿಟ್ ಕಂಟೇನರ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಪಾಡ್‌ನಲ್ಲಿ (ಕಂಟೇನರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿಯೋಜನೆಯ ಒಂದು ಘಟಕ) ಸಂಯೋಜಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, SCP ಹಳೆಯ ಧಾರಕವನ್ನು (ವೆಬ್ ಸರ್ವರ್ ಅಥವಾ ಸಂದೇಶ ಬ್ರೋಕರ್‌ನಂತಹ) ಹೊಸದರೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಅದು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಆದರೆ ವಿಸ್ತರಿತ ಕಾರ್ಯವನ್ನು ಅಥವಾ ಉತ್ತಮ ಮಾಪಕಗಳನ್ನು ಹೊಂದಿದೆ.
ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆಯ ತತ್ವ (HOP)
ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಮಾಡಲು ಮತ್ತು ರನ್ ಮಾಡಲು ಕಂಟೈನರ್‌ಗಳನ್ನು ಏಕೀಕೃತ ಮಾರ್ಗವಾಗಿ ಬಳಸಿದಾಗ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸ್ವತಃ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಇವು ಕ್ಲೌಡ್ ಕಂಟೇನರ್‌ಗಳಾಗಿದ್ದರೆ, ಕಂಟೇನರ್‌ಗಳ ಆರೋಗ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ರನ್‌ಟೈಮ್‌ಗೆ ವಿಶೇಷ API ಗಳನ್ನು ಒದಗಿಸಬೇಕು ಮತ್ತು ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ಸೂಕ್ತ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಇದು ಇಲ್ಲದೆ, ಕಂಟೇನರ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ಮತ್ತು ಅವುಗಳ ಜೀವನ ಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸುವ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಏಕೀಕರಣವನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಇದು ಸಾಫ್ಟ್ವೇರ್ ಸಿಸ್ಟಮ್‌ನ ಸ್ಥಿರತೆ ಮತ್ತು ಉಪಯುಕ್ತತೆಯನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಕಂಟೈನರೈಸ್ಡ್ ಅಪ್ಲಿಕೇಶನ್, ಕನಿಷ್ಠ, ವಿವಿಧ ರೀತಿಯ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳಿಗೆ API ಹೊಂದಿರಬೇಕು: ಜೀವಂತಿಕೆ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ಸಿದ್ಧತೆ ಪರೀಕ್ಷೆಗಳು. ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡುವುದಾಗಿ ಹೇಳಿಕೊಂಡರೆ, ಅದು ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಇತರ ವಿಧಾನಗಳನ್ನು ಒದಗಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, Fluentd, Logstash ಮತ್ತು ಇತರ ರೀತಿಯ ಸಾಧನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಲಾಗ್ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಗಾಗಿ STDERR ಮತ್ತು STDOUT ಮೂಲಕ ಪ್ರಮುಖ ಈವೆಂಟ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡುವುದು. ಟ್ರೇಸಿಂಗ್ ಮತ್ತು ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆ ಗ್ರಂಥಾಲಯಗಳೊಂದಿಗೆ ಏಕೀಕರಣ, ಉದಾಹರಣೆಗೆ OpenTracing, Prometheus, ಇತ್ಯಾದಿ.
ಸಾಮಾನ್ಯವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಇನ್ನೂ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿ ಪರಿಗಣಿಸಬಹುದು, ಆದರೆ ಅದನ್ನು ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಪ್ಲ್ಯಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ API ಗಳನ್ನು ಒದಗಿಸಬೇಕು.
ಜೀವನ ಚಕ್ರದ ಅನುಸರಣೆ ತತ್ವ (LCP)
LCP ಎಂಬುದು HOP ಯ ವಿರೋಧಿಯಾಗಿದೆ. ಕಂಟೇನರ್ ರೀಡ್ API ಗಳನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಬಹಿರಂಗಪಡಿಸಬೇಕು ಎಂದು HOP ಹೇಳುತ್ತದೆ, LCP ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿದೆ. ಇದಲ್ಲದೆ, ಕಂಟೇನರ್ ಈವೆಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಮಾತ್ರವಲ್ಲ, ಹೊಂದಿಕೊಳ್ಳಬೇಕು, ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಅವುಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಆದ್ದರಿಂದ ತತ್ವದ ಹೆಸರು, ಇದು API ಗಳನ್ನು ಬರೆಯುವುದರೊಂದಿಗೆ ವೇದಿಕೆಯನ್ನು ಒದಗಿಸುವ ಅವಶ್ಯಕತೆಯೆಂದು ಪರಿಗಣಿಸಬಹುದು.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಕಂಟೇನರ್‌ನ ಜೀವನಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸಲು ಸಹಾಯ ಮಾಡಲು ವಿವಿಧ ರೀತಿಯ ಈವೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಿವೆ. ಆದರೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬಿಟ್ಟದ್ದು.
ಕೆಲವು ಘಟನೆಗಳು ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ಮಹತ್ವದ್ದಾಗಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್‌ಗಳನ್ನು ಚೆನ್ನಾಗಿ ಸಹಿಸದಿದ್ದರೆ, ಅದು ಸಿಗ್ನಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬೇಕು: (SIGTERM) ಸಂದೇಶಗಳನ್ನು ಕೊನೆಗೊಳಿಸಿ ಮತ್ತು ಸಿಗ್ನಲ್ ಅನ್ನು ಹಿಡಿಯಲು ಅದರ ಮುಕ್ತಾಯದ ದಿನಚರಿಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪ್ರಾರಂಭಿಸಬೇಕು: SIGTERM ನಂತರ ಬರುವ ಕೊಲ್ಲು (SIGKILL).
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪೋಸ್ಟ್‌ಸ್ಟಾರ್ಟ್ ಮತ್ತು ಪ್ರಿಸ್ಟಾಪ್‌ನಂತಹ ಈವೆಂಟ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ಜೀವನಚಕ್ರಕ್ಕೆ ಪ್ರಮುಖವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಮೊದಲು ಅದಕ್ಕೆ ಸ್ವಲ್ಪ ಅಭ್ಯಾಸದ ಸಮಯ ಬೇಕಾಗಬಹುದು. ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಮುಚ್ಚುವಾಗ ಕೆಲವು ವಿಶೇಷ ರೀತಿಯಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕು.
ಇಮೇಜ್ ಇಮ್ಯುಟಬಿಲಿಟಿ ಪ್ರಿನ್ಸಿಪಲ್ (IIP)
ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿದ ನಂತರವೂ ಬದಲಾಗದೆ ಉಳಿಯಬೇಕು ಎಂದು ಸಾಮಾನ್ಯವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳಲಾಗಿದೆ, ಅವುಗಳು ವಿಭಿನ್ನ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಸಹ. ಇದು ರನ್ಟೈಮ್ನಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಾಹ್ಯೀಕರಿಸುವ ಅಗತ್ಯವನ್ನು ಹೊಂದಿದೆ (ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಇದಕ್ಕಾಗಿ ಬಾಹ್ಯ ಸಾಧನಗಳನ್ನು ಬಳಸಲು) ಮತ್ತು ಪ್ರತಿ ಪರಿಸರಕ್ಕೆ ಅನನ್ಯ ಧಾರಕಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಅಥವಾ ರಚಿಸುವ ಬದಲು ಬಾಹ್ಯ, ರನ್ಟೈಮ್-ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಅವಲಂಬಿಸುವುದು. ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳ ನಂತರ, ಕಂಟೇನರ್ ಚಿತ್ರವನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಬೇಕು ಮತ್ತು ಬಳಸಿದ ಎಲ್ಲಾ ಪರಿಸರಗಳಿಗೆ ನಿಯೋಜಿಸಬೇಕು. ಮೂಲಕ, ಐಟಿ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗ, ಇದೇ ರೀತಿಯ ತತ್ವವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ಸರ್ವರ್ಗಳು ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳ ಅಸ್ಥಿರತೆಯ ತತ್ವ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
IIP ಯ ಗುರಿಯು ವಿಭಿನ್ನ ರನ್ಟೈಮ್ ಪರಿಸರಗಳಿಗಾಗಿ ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್ ಚಿತ್ರಗಳನ್ನು ರಚಿಸುವುದನ್ನು ತಡೆಯುವುದು ಮತ್ತು ಸೂಕ್ತವಾದ ಪರಿಸರ-ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆಯೊಂದಿಗೆ ಎಲ್ಲೆಡೆ ಒಂದೇ ಚಿತ್ರವನ್ನು ಬಳಸುವುದು. ಈ ತತ್ವವನ್ನು ಅನುಸರಿಸುವುದರಿಂದ ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ದೃಷ್ಟಿಕೋನದಿಂದ ರೋಲ್-ಬ್ಯಾಕ್ ಮತ್ತು ರೋಲ್-ಫಾರ್ವರ್ಡ್ ಅಪ್ಲಿಕೇಶನ್ ನವೀಕರಣಗಳಂತಹ ಪ್ರಮುಖ ಅಭ್ಯಾಸಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಪ್ರಕ್ರಿಯೆ ಡಿಸ್ಪೋಸಬಿಲಿಟಿ ಪ್ರಿನ್ಸಿಪಲ್ (PDP)
ಕಂಟೇನರ್‌ನ ಪ್ರಮುಖ ಲಕ್ಷಣವೆಂದರೆ ಅದರ ಅಲ್ಪಕಾಲಿಕತೆ: ಕಂಟೇನರ್‌ನ ನಿದರ್ಶನವನ್ನು ರಚಿಸಲು ಸುಲಭ ಮತ್ತು ನಾಶಮಾಡಲು ಸುಲಭ, ಆದ್ದರಿಂದ ಅದನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಮತ್ತೊಂದು ನಿದರ್ಶನದೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಬಹುದು. ಅಂತಹ ಬದಲಿಗಾಗಿ ಹಲವು ಕಾರಣಗಳಿರಬಹುದು: ಸೇವೆಯ ಪರೀಕ್ಷೆಯ ವೈಫಲ್ಯ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ಕೇಲಿಂಗ್, ಮತ್ತೊಂದು ಹೋಸ್ಟ್‌ಗೆ ವರ್ಗಾವಣೆ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸಂಪನ್ಮೂಲಗಳ ಬಳಲಿಕೆ ಅಥವಾ ಇತರ ಸಂದರ್ಭಗಳು.
ಪರಿಣಾಮವಾಗಿ, ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕೆಲವು ಬಾಹ್ಯ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ತಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಬೇಕು ಅಥವಾ ಇದಕ್ಕಾಗಿ ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ಆಂತರಿಕ ವಿತರಣೆ ಯೋಜನೆಗಳನ್ನು ಬಳಸಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ತ್ವರಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಮತ್ತು ತ್ವರಿತವಾಗಿ ಮುಚ್ಚಬೇಕು ಮತ್ತು ಹಠಾತ್ ಮಾರಣಾಂತಿಕ ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯಕ್ಕೆ ಸಿದ್ಧರಾಗಿರಬೇಕು.
ಈ ತತ್ವವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುವ ಒಂದು ಅಭ್ಯಾಸವೆಂದರೆ ಧಾರಕಗಳನ್ನು ಚಿಕ್ಕದಾಗಿಸುವುದು. ಕಂಟೇನರ್ ನಿದರ್ಶನವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಕ್ಲೌಡ್ ಪರಿಸರಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೋಸ್ಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಕಂಟೇನರ್ ಚಿಕ್ಕದಾಗಿದೆ, ಅದು ವೇಗವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ - ಇದು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಗುರಿ ಹೋಸ್ಟ್‌ಗೆ ವೇಗವಾಗಿ ನಕಲಿಸುತ್ತದೆ.
ಸ್ವಯಂ ನಿಯಂತ್ರಣ ತತ್ವ (S-CP)
ಈ ತತ್ತ್ವದ ಪ್ರಕಾರ, ಅಸೆಂಬ್ಲಿ ಹಂತದಲ್ಲಿ, ಎಲ್ಲಾ ಅಗತ್ಯ ಘಟಕಗಳನ್ನು ಧಾರಕದಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಶುದ್ಧ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಅನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ ಎಂಬ ಊಹೆಯ ಮೇಲೆ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಕು, ಆದ್ದರಿಂದ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಹೆಚ್ಚುವರಿ ಲೈಬ್ರರಿಗಳನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿಯೇ ಇರಿಸಬೇಕು. ಇದು ಅನುಗುಣವಾದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ರನ್ಟೈಮ್, ಅಪ್ಲಿಕೇಶನ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ (ಅಗತ್ಯವಿದ್ದರೆ), ಮತ್ತು ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಅಗತ್ಯವಿರುವ ಇತರ ಅವಲಂಬನೆಗಳಂತಹ ವಿಷಯಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿರಬೇಕು.
ಪರಿಸರದಿಂದ ಪರಿಸರಕ್ಕೆ ಬದಲಾಗುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗೆ ವಿನಾಯಿತಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ ಒದಗಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಮೂಲಕ.
ಅಪ್ಲಿಕೇಶನ್ ಹಲವಾರು ಧಾರಕ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು, ಉದಾಹರಣೆಗೆ, ಕಂಟೈನರೈಸ್ಡ್ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ DBMS ಕಂಟೇನರ್. ಎಸ್-ಸಿಪಿ ತತ್ವದ ಪ್ರಕಾರ, ಈ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಂದಾಗಿ ಸಂಯೋಜಿಸಬಾರದು, ಆದರೆ ಡಿಬಿಎಂಎಸ್ ಕಂಟೇನರ್ ಡೇಟಾಬೇಸ್‌ನ ಕಾರ್ಯಾಚರಣೆಗೆ ಅಗತ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿರುವಂತೆ ಮಾಡಬೇಕು ಮತ್ತು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್ ವೆಬ್‌ನ ಕಾರ್ಯಾಚರಣೆಗೆ ಅಗತ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿದೆ. ಅಪ್ಲಿಕೇಶನ್, ಅದೇ ವೆಬ್ ಸರ್ವರ್ . ಪರಿಣಾಮವಾಗಿ, ರನ್ಟೈಮ್ನಲ್ಲಿ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್ DBMS ಕಂಟೇನರ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿರುವಂತೆ ಅದನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ.
ರನ್ಟೈಮ್ ಕನ್ಫೈನ್ಮೆಂಟ್ ಪ್ರಿನ್ಸಿಪಲ್ (RCP)
S-CP ತತ್ವವು ಕಂಟೇನರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಬೇಕು ಮತ್ತು ಚಿತ್ರ ಬೈನರಿ ಏನನ್ನು ಒಳಗೊಂಡಿರಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆದರೆ ಕಂಟೇನರ್ ಕೇವಲ "ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ" ಅಲ್ಲ, ಅದು ಕೇವಲ ಒಂದು ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿದೆ - ಫೈಲ್ ಗಾತ್ರ. ಮರಣದಂಡನೆಯ ಸಮಯದಲ್ಲಿ, ಕಂಟೇನರ್ ಇತರ ಆಯಾಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಬಳಸಿದ ಮೆಮೊರಿಯ ಪ್ರಮಾಣ, CPU ಸಮಯ ಮತ್ತು ಇತರ ಸಿಸ್ಟಮ್ ಸಂಪನ್ಮೂಲಗಳು.
ಮತ್ತು ಇಲ್ಲಿ RCP ತತ್ವವು ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ, ಅದರ ಪ್ರಕಾರ ಕಂಟೇನರ್ ಸಿಸ್ಟಮ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಅದರ ಅವಶ್ಯಕತೆಗಳನ್ನು ಶಿರಚ್ಛೇದ ಮಾಡಬೇಕು ಮತ್ತು ಅವುಗಳನ್ನು ವೇದಿಕೆಗೆ ವರ್ಗಾಯಿಸಬೇಕು. ಪ್ರತಿ ಕಂಟೇನರ್‌ನ ಸಂಪನ್ಮೂಲ ಪ್ರೊಫೈಲ್‌ಗಳೊಂದಿಗೆ (ಅದಕ್ಕೆ ಎಷ್ಟು CPU, ಮೆಮೊರಿ, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್ ಸಂಪನ್ಮೂಲಗಳು ಬೇಕು), ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅತ್ಯುತ್ತಮವಾಗಿ ವೇಳಾಪಟ್ಟಿ ಮತ್ತು ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, IT ಸಾಮರ್ಥ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕಂಟೇನರ್‌ಗಳಿಗಾಗಿ SLA ಮಟ್ಟವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಕಂಟೇನರ್‌ನ ಸಂಪನ್ಮೂಲ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವುದರ ಜೊತೆಗೆ, ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ಗಡಿಗಳನ್ನು ಮೀರಿ ಹೋಗದಿರುವುದು ಸಹ ಮುಖ್ಯವಾಗಿದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಸಂಪನ್ಮೂಲದ ಕೊರತೆಯು ಸಂಭವಿಸಿದಾಗ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅದನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸಬೇಕಾದ ಅಥವಾ ಸ್ಥಳಾಂತರಿಸಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಸೇರಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ.
ನಾವು ಕ್ಲೌಡ್-ಫಸ್ಟ್ ಎಂದು ಮಾತನಾಡುವಾಗ, ನಾವು ಕೆಲಸ ಮಾಡುವ ವಿಧಾನದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.
ಮೇಲೆ, ಕ್ಲೌಡ್ ಪರಿಸರಕ್ಕಾಗಿ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಕಂಟೇನರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಕ್ರಮಶಾಸ್ತ್ರೀಯ ಅಡಿಪಾಯವನ್ನು ಹೊಂದಿಸುವ ಹಲವಾರು ಸಾಮಾನ್ಯ ತತ್ವಗಳನ್ನು ನಾವು ರೂಪಿಸಿದ್ದೇವೆ.
ಈ ಸಾಮಾನ್ಯ ತತ್ವಗಳ ಜೊತೆಗೆ, ಕಂಟೇನರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಿಮಗೆ ಹೆಚ್ಚುವರಿ ಸುಧಾರಿತ ವಿಧಾನಗಳು ಮತ್ತು ತಂತ್ರಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಕೆಲವು ಸಣ್ಣ ಶಿಫಾರಸುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿರುತ್ತವೆ ಮತ್ತು ಪರಿಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಅನ್ವಯಿಸಬೇಕು (ಅಥವಾ ಅನ್ವಯಿಸುವುದಿಲ್ಲ):
- ಚಿತ್ರಗಳ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ: ತಾತ್ಕಾಲಿಕ ಫೈಲ್‌ಗಳನ್ನು ಅಳಿಸಿ ಮತ್ತು ಅನಗತ್ಯ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಡಿ - ಕಂಟೇನರ್ ಗಾತ್ರವು ಚಿಕ್ಕದಾಗಿದೆ, ಅದನ್ನು ವೇಗವಾಗಿ ಜೋಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಗುರಿ ಹೋಸ್ಟ್‌ಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ.
- ನಿರಂಕುಶ ಬಳಕೆದಾರ-ID ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿ: ನಿಮ್ಮ ಕಂಟೈನರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು sudo ಆಜ್ಞೆಯನ್ನು ಅಥವಾ ಯಾವುದೇ ವಿಶೇಷ userid ಅನ್ನು ಬಳಸಬೇಡಿ.
- ಪ್ರಮುಖ ಪೋರ್ಟ್‌ಗಳನ್ನು ಗುರುತಿಸಿ: ನೀವು ರನ್ಟೈಮ್ನಲ್ಲಿ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿಸಬಹುದು, ಆದರೆ ಎಕ್ಸ್‌ಪೋಸ್ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ಉತ್ತಮ - ಇದು ನಿಮ್ಮ ಚಿತ್ರಗಳನ್ನು ಬಳಸಲು ಇತರ ಜನರಿಗೆ ಮತ್ತು ಪ್ರೋಗ್ರಾಂಗಳಿಗೆ ಸುಲಭವಾಗುತ್ತದೆ.
- ಸಂಪುಟಗಳಲ್ಲಿ ನಿರಂತರ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ: ಕಂಟೇನರ್ ನಾಶವಾದ ನಂತರ ಉಳಿಯಬೇಕಾದ ಡೇಟಾವನ್ನು ಸಂಪುಟಗಳಿಗೆ ಬರೆಯಬೇಕು.
- ಇಮೇಜ್ ಮೆಟಾಡೇಟಾವನ್ನು ಬರೆಯಿರಿ: ಟ್ಯಾಗ್‌ಗಳು, ಲೇಬಲ್‌ಗಳು ಮತ್ತು ಟಿಪ್ಪಣಿಗಳು ಚಿತ್ರಗಳನ್ನು ಬಳಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ - ಇತರ ಡೆವಲಪರ್‌ಗಳು ನಿಮಗೆ ಧನ್ಯವಾದಗಳು.
- ಹೋಸ್ಟ್ ಮತ್ತು ಚಿತ್ರಗಳನ್ನು ಸಿಂಕ್ ಮಾಡಿ: ಕೆಲವು ಕಂಟೈನರೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಮಯ ಅಥವಾ ಯಂತ್ರದ ID ಯಂತಹ ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ ಮಾಡಲು ಕಂಟೇನರ್ ಅಗತ್ಯವಿರುತ್ತದೆ.
- ಕೊನೆಯಲ್ಲಿ, ಮೇಲೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ತತ್ವಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ನಾವು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ:
ಜೂನ್ 11 ರಂದು 11.00 ಕ್ಕೆ
ನೀವು ಏನು ಕಲಿಯುವಿರಿ:
- ಬದಲಾಗದ Red Hat Enterprise Linux CoreOS
- ಓಪನ್‌ಶಿಫ್ಟ್ ಸೇವಾ ಜಾಲರಿ
- ಆಪರೇಟರ್ ಫ್ರೇಮ್ವರ್ಕ್
- ಸ್ಥಳೀಯ ಚೌಕಟ್ಟು
ಮೂಲ: www.habr.com