ಹೇಗಾದರೂ ಒಂದು ಹಂತದಲ್ಲಿ ನಾನು ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳ ರೂಪದಲ್ಲಿ ವಿತರಣೆಯ ಕುರಿತು ಲೇಖನವನ್ನು ಬರೆಯಲು ನಿರ್ಧರಿಸಿದೆ, ಆದರೆ ನಾನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಕೆಲವು ಕಾರಣಗಳಿಂದಾಗಿ ನನ್ನನ್ನು ಮೊದಲ ವೈಯಕ್ತಿಕ ಕಂಪ್ಯೂಟರ್ಗಳು ಮತ್ತು ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ಗಳ ದೂರದ ಸಮಯಕ್ಕೆ ಹಿಂತಿರುಗಿಸಲಾಯಿತು. ಸಾಮಾನ್ಯವಾಗಿ, ಡಾಕರ್ ಮತ್ತು ಡೆಬ್‌ನ ಒಣ ಹೋಲಿಕೆಗಳ ಬದಲಿಗೆ, ವಿಕಾಸದ ವಿಷಯದ ಕುರಿತು ನಾವು ಈ ಆಲೋಚನೆಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದನ್ನು ನಾನು ನಿಮ್ಮ ಪರಿಗಣನೆಗೆ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ.
ಯಾವುದೇ ಉತ್ಪನ್ನ, ಅದು ಏನೇ ಇರಲಿ, ಹೇಗಾದರೂ ಉತ್ಪನ್ನ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗಬೇಕು, ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು ಮತ್ತು ಪ್ರಾರಂಭಿಸಬೇಕು. ಈ ಲೇಖನವು ಅದರ ಬಗ್ಗೆ ಇರುತ್ತದೆ.
ನಾನು ಐತಿಹಾಸಿಕ ಸನ್ನಿವೇಶದಲ್ಲಿ ಯೋಚಿಸುತ್ತೇನೆ, "ನಾನು ಏನು ನೋಡುತ್ತೇನೋ ಅದರ ಬಗ್ಗೆ ನಾನು ಹಾಡುತ್ತೇನೆ," ನಾನು ಮೊದಲು ಕೋಡ್ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ನಾನು ಏನು ನೋಡಿದೆ ಮತ್ತು ಈಗ ನಾನು ಏನು ಗಮನಿಸುತ್ತಿದ್ದೇನೆ, ನಾವು ಈ ಸಮಯದಲ್ಲಿ ಏನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಏಕೆ ಎಂದು ನಾನು ಯೋಚಿಸುತ್ತೇನೆ. ಲೇಖನವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಅಧ್ಯಯನದಂತೆ ನಟಿಸುವುದಿಲ್ಲ, ಕೆಲವು ಅಂಶಗಳು ತಪ್ಪಿಹೋಗಿವೆ, ಇದು ಏನಾಗಿತ್ತು ಮತ್ತು ಈಗ ಏನು ಎಂಬುದರ ಬಗ್ಗೆ ನನ್ನ ವೈಯಕ್ತಿಕ ದೃಷ್ಟಿಕೋನವಾಗಿದೆ.
ಆದ್ದರಿಂದ, ಉತ್ತಮ ಹಳೆಯ ದಿನಗಳಲ್ಲಿ... ನಾನು ಕಂಡುಕೊಂಡ ಆರಂಭಿಕ ವಿಧಾನವೆಂದರೆ ಟೇಪ್ ರೆಕಾರ್ಡರ್‌ಗಳಿಂದ ಕ್ಯಾಸೆಟ್ ಟೇಪ್‌ಗಳು. ನನ್ನ ಬಳಿ ಕಂಪ್ಯೂಟರ್ BK-0010.01 ಇತ್ತು...
ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ಗಳ ಯುಗ
ಇಲ್ಲ, ಇನ್ನೂ ಮುಂಚಿನ ಕ್ಷಣವಿತ್ತು, ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಕೂಡ ಇತ್ತು и .
ಹಾಗಾಗಿ ನಾನು ಹೊಂದಿದ್ದಾಗ , ನಂತರ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ವರ್ಗಾಯಿಸುವ ಮಾರ್ಗವು ಒಂದು ಪೆಟ್ಟಿಗೆಯಲ್ಲಿ ಒಂದು ಸಾಮಾನ್ಯ ಕಾಗದದ ತುಂಡುಯಾಗಿದ್ದು, ಅದರಲ್ಲಿ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬರೆಯಲಾಗಿದೆ, ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು ಕೈಯಾರೆ ಚಲಾಯಿಸಲು, ಕ್ಯಾಲ್ಕುಲೇಟರ್ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ನೀವು ಆಡಲು ಬಯಸಿದರೆ (ಹೌದು, ಈ ಆಂಟಿಡಿಲುವಿಯನ್ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಸಹ ಆಟಗಳನ್ನು ಹೊಂದಿತ್ತು) - ನೀವು ಕುಳಿತು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ಗೆ ನಮೂದಿಸಿ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಅನ್ನು ಆಫ್ ಮಾಡಿದಾಗ, ಪ್ರೋಗ್ರಾಂ ಮರೆವು ಆಗಿ ಕಣ್ಮರೆಯಾಯಿತು. ತನ್ನ ಕೈಯಲ್ಲಿ ಕಾಗದದ ಮೇಲೆ ಬರೆಯಲಾದ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಕೋಡ್‌ಗಳ ಜೊತೆಗೆ, ಕಾರ್ಯಕ್ರಮಗಳನ್ನು "ರೇಡಿಯೋ" ಮತ್ತು "ಟೆಕ್ನಾಲಜಿ ಫಾರ್ ಯೂತ್" ನಿಯತಕಾಲಿಕೆಗಳಲ್ಲಿ ಪ್ರಕಟಿಸಲಾಯಿತು ಮತ್ತು ಆ ಕಾಲದ ಪುಸ್ತಕಗಳಲ್ಲಿ ಸಹ ಪ್ರಕಟಿಸಲಾಯಿತು.
ಮುಂದಿನ ಮಾರ್ಪಾಡು ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಆಗಿತ್ತು , ಇದು ಈಗಾಗಲೇ ಬಾಷ್ಪಶೀಲವಲ್ಲದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಕೆಲವು ಹೋಲಿಕೆಯನ್ನು ಹೊಂದಿದೆ. ಈಗ ಆಟ ಅಥವಾ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಮೂದಿಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ಗುಂಡಿಗಳೊಂದಿಗೆ ಕೆಲವು ಮಾಂತ್ರಿಕ ಪಾಸ್ಗಳನ್ನು ನಿರ್ವಹಿಸಿದ ನಂತರ, ಅದು ಸ್ವತಃ ಲೋಡ್ ಆಗುತ್ತದೆ.
ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ನಲ್ಲಿನ ಅತಿದೊಡ್ಡ ಪ್ರೋಗ್ರಾಂನ ಗಾತ್ರವು 105 ಹಂತಗಳು ಮತ್ತು MK-52 ನಲ್ಲಿನ ಶಾಶ್ವತ ಮೆಮೊರಿಯ ಗಾತ್ರವು 512 ಹಂತಗಳು.
ಅಂದಹಾಗೆ, ಈ ಲೇಖನವನ್ನು ಓದುವ ಈ ಕ್ಯಾಲ್ಕುಲೇಟರ್‌ಗಳ ಅಭಿಮಾನಿಗಳು ಇದ್ದರೆ, ಲೇಖನವನ್ನು ಬರೆಯುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾನು ಆಂಡ್ರಾಯ್ಡ್‌ಗಾಗಿ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಎಮ್ಯುಲೇಟರ್ ಮತ್ತು ಅದಕ್ಕಾಗಿ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ. ಹಿಂದಿನದಕ್ಕೆ ಮುಂದಕ್ಕೆ!
MK-52 ಬಗ್ಗೆ ಒಂದು ಸಣ್ಣ ವಿಷಯ (ವಿಕಿಪೀಡಿಯಾದಿಂದ)
ಎಂಕೆ -52 ಸೋಯುಜ್ ಟಿಎಂ -7 ಬಾಹ್ಯಾಕಾಶ ನೌಕೆಯಲ್ಲಿ ಬಾಹ್ಯಾಕಾಶಕ್ಕೆ ಹಾರಿತು. ಆನ್-ಬೋರ್ಡ್ ಕಂಪ್ಯೂಟರ್ ವಿಫಲವಾದಲ್ಲಿ ಲ್ಯಾಂಡಿಂಗ್ ಪಥವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಇದನ್ನು ಬಳಸಬೇಕಿತ್ತು.
52 ರಿಂದ, ನ್ಯಾವಿಗೇಷನಲ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಕಿಟ್‌ನ ಭಾಗವಾಗಿ ನೌಕಾಪಡೆಯ ಹಡಗುಗಳಿಗೆ ಎಲೆಕ್ಟ್ರೋನಿಕಾ-ಆಸ್ಟ್ರೋ ಮೆಮೊರಿ ವಿಸ್ತರಣೆ ಘಟಕದೊಂದಿಗೆ MK-1988 ಅನ್ನು ಸರಬರಾಜು ಮಾಡಲಾಗಿದೆ.
ಮೊದಲ ವೈಯಕ್ತಿಕ ಕಂಪ್ಯೂಟರ್ಗಳು
ಸಮಯಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ . ಅಲ್ಲಿ ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಇತ್ತು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಕಾಗದದ ತುಂಡಿನಿಂದ ಕೋಡ್ ಅನ್ನು ಟೈಪ್ ಮಾಡುವುದು ಇನ್ನು ಮುಂದೆ ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ (ಆದರೂ ಮೊದಲಿಗೆ ನಾನು ಅದನ್ನು ಮಾಡಿದ್ದೇನೆ, ಏಕೆಂದರೆ ಬೇರೆ ಯಾವುದೇ ಮಾಧ್ಯಮವಿಲ್ಲ). ಟೇಪ್ ರೆಕಾರ್ಡರ್‌ಗಳಿಗಾಗಿ ಆಡಿಯೋ ಕ್ಯಾಸೆಟ್‌ಗಳು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ತಲುಪಿಸುವ ಮುಖ್ಯ ಸಾಧನವಾಗುತ್ತಿವೆ.
ಕ್ಯಾಸೆಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಣೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಅಥವಾ ಎರಡು ಬೈನರಿ ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿರುತ್ತದೆ, ಉಳಿದೆಲ್ಲವೂ ಒಳಗಿರುತ್ತದೆ. ವಿಶ್ವಾಸಾರ್ಹತೆ ತುಂಬಾ ಕಡಿಮೆಯಾಗಿತ್ತು, ನಾನು ಕಾರ್ಯಕ್ರಮದ 2-3 ಪ್ರತಿಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕಾಗಿತ್ತು. ಲೋಡ್ ಮಾಡುವ ಸಮಯವೂ ನಿರಾಶಾದಾಯಕವಾಗಿತ್ತು, ಮತ್ತು ಉತ್ಸಾಹಿಗಳು ಈ ನ್ಯೂನತೆಗಳನ್ನು ನಿವಾರಿಸಲು ವಿಭಿನ್ನ ಆವರ್ತನ ಎನ್‌ಕೋಡಿಂಗ್‌ಗಳನ್ನು ಪ್ರಯೋಗಿಸಿದರು. ಆ ಸಮಯದಲ್ಲಿ, ನಾನು ಇನ್ನೂ ವೃತ್ತಿಪರ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲ (ಬೇಸಿಕ್‌ನಲ್ಲಿ ಸರಳ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ), ಆದ್ದರಿಂದ, ದುರದೃಷ್ಟವಶಾತ್, ಎಲ್ಲವನ್ನೂ ಒಳಗೆ ಹೇಗೆ ಜೋಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾನು ನಿಮಗೆ ವಿವರವಾಗಿ ಹೇಳುವುದಿಲ್ಲ. ಕಂಪ್ಯೂಟರ್ ಬಹುಪಾಲು RAM ಅನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ ಎಂಬ ಅಂಶವು ಡೇಟಾ ಸಂಗ್ರಹಣಾ ಯೋಜನೆಯ ಸರಳತೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ದೊಡ್ಡ ಶೇಖರಣಾ ಮಾಧ್ಯಮದ ಹೊರಹೊಮ್ಮುವಿಕೆ
ನಂತರ, ಫ್ಲಾಪಿ ಡಿಸ್ಕ್ಗಳು ಕಾಣಿಸಿಕೊಂಡವು, ನಕಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸರಳಗೊಳಿಸಲಾಯಿತು ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆ ಹೆಚ್ಚಾಯಿತು.
ಆದರೆ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಗಳು HDD ಗಳ ರೂಪದಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಾಗ ಮಾತ್ರ ಪರಿಸ್ಥಿತಿಯು ನಾಟಕೀಯವಾಗಿ ಬದಲಾಗುತ್ತದೆ.
ವಿತರಣೆಯ ಪ್ರಕಾರವು ಮೂಲಭೂತವಾಗಿ ಬದಲಾಗುತ್ತಿದೆ: ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಅನುಸ್ಥಾಪಕ ಪ್ರೋಗ್ರಾಂಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಜೊತೆಗೆ ತೆಗೆದುಹಾಕುವಿಕೆಯ ನಂತರ ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಕೇವಲ ಮೆಮೊರಿಗೆ ಓದಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಈಗಾಗಲೇ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಗೆ ನಕಲಿಸಲಾಗುತ್ತದೆ, ಇದರಿಂದ ನೀವು ಮಾಡಬೇಕಾಗಿದೆ ಅಗತ್ಯವಿದ್ದರೆ ಅನಗತ್ಯ ವಿಷಯಗಳನ್ನು ತೆರವುಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಸರಬರಾಜು ಮಾಡಿದ ಸಾಫ್ಟ್ವೇರ್ನ ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚುತ್ತಿದೆ.
ವಿತರಣೆಯಲ್ಲಿನ ಫೈಲ್‌ಗಳ ಸಂಖ್ಯೆಯು ಕೆಲವು ನೂರಾರು ಮತ್ತು ಸಾವಿರಗಳಿಗೆ ಹೆಚ್ಚಾಗುತ್ತದೆ, ವಿವಿಧ ಪ್ರೋಗ್ರಾಂಗಳು ಒಂದೇ ಡೇಟಾವನ್ನು ಬಳಸಿದಾಗ ಲೈಬ್ರರಿ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಇತರ ಸಂತೋಷಗಳ ನಡುವಿನ ಸಂಘರ್ಷಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.
ಆ ಸಮಯದಲ್ಲಿ, ಲಿನಕ್ಸ್ ಅಸ್ತಿತ್ವವು ನನಗೆ ಇನ್ನೂ ತೆರೆದಿರಲಿಲ್ಲ; ನಾನು ಎಂಎಸ್ ಡಾಸ್ ಮತ್ತು ನಂತರ ವಿಂಡೋಸ್ ಜಗತ್ತಿನಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೆ ಮತ್ತು ಬೋರ್ಲ್ಯಾಂಡ್ ಪ್ಯಾಸ್ಕಲ್ ಮತ್ತು ಡೆಲ್ಫಿಯಲ್ಲಿ ಬರೆದಿದ್ದೇನೆ, ಕೆಲವೊಮ್ಮೆ ಸಿ ++ ಕಡೆಗೆ ನೋಡುತ್ತಿದ್ದೆ. ಆಗ ಉತ್ಪನ್ನಗಳನ್ನು ತಲುಪಿಸಲು ಅನೇಕ ಜನರು InstallShield ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರು. , ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಎಲ್ಲಾ ನಿಯೋಜಿಸಲಾದ ಕಾರ್ಯಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಹರಿಸಿದೆ.
ಇಂಟರ್ನೆಟ್ ಯುಗ
ಕ್ರಮೇಣ, ಸಾಫ್ಟ್‌ವೇರ್ ಸಿಸ್ಟಮ್‌ಗಳ ಸಂಕೀರ್ಣತೆಯು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿದೆ; ಏಕಶಿಲೆ ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು, ತೆಳುವಾದ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಿಗೆ ಪರಿವರ್ತನೆ ಇದೆ. ಈಗ ನೀವು ಕೇವಲ ಒಂದು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದು ಸೆಟ್, ಮತ್ತು ಆದ್ದರಿಂದ ಅವರು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ.
ಪರಿಕಲ್ಪನೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿತು, ಇಂಟರ್ನೆಟ್ ಬಂದಿತು, ಕ್ಲೌಡ್ ಸೇವೆಗಳ ಯುಗ ಬಂದಿತು. ಇಲ್ಲಿಯವರೆಗೆ, ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ, ವೆಬ್‌ಸೈಟ್‌ಗಳ ರೂಪದಲ್ಲಿ, ಯಾರೂ ವಿಶೇಷವಾಗಿ ಸೇವೆಗಳ ಬಗ್ಗೆ ಕನಸು ಕಂಡಿಲ್ಲ. ಆದರೆ ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ವಿತರಣೆ ಎರಡರಲ್ಲೂ ಒಂದು ಮಹತ್ವದ ತಿರುವು.
ನನಗಾಗಿ, ಆ ಕ್ಷಣದಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳ ತಲೆಮಾರುಗಳಲ್ಲಿ ಬದಲಾವಣೆಯಾಗಿದೆ ಎಂದು ನಾನು ಗಮನಿಸಿದ್ದೇನೆ (ಅಥವಾ ಅದು ನನ್ನ ಪರಿಸರದಲ್ಲಿ ಮಾತ್ರ), ಮತ್ತು ಎಲ್ಲಾ ಉತ್ತಮ ಹಳೆಯ ವಿತರಣಾ ವಿಧಾನಗಳು ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಮರೆತುಹೋಗಿವೆ ಮತ್ತು ಎಲ್ಲವೂ ಪ್ರಾರಂಭವಾದವು ಎಂಬ ಭಾವನೆ ಇತ್ತು. ಪ್ರಾರಂಭ: ಎಲ್ಲಾ ವಿತರಣೆಗಳು ಮೊಣಕಾಲು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು ಅದನ್ನು ಹೆಮ್ಮೆಯಿಂದ "ನಿರಂತರ ವಿತರಣೆ" ಎಂದು ಕರೆಯಲಾಯಿತು. ವಾಸ್ತವವಾಗಿ, ಅವ್ಯವಸ್ಥೆಯ ಅವಧಿಯು ಪ್ರಾರಂಭವಾಗಿದೆ, ಹಳೆಯದನ್ನು ಮರೆತು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಹೊಸದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.
ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ನಾನು ಕೆಲಸ ಮಾಡಿದ ಸಮಯಗಳು ನನಗೆ ನೆನಪಿದೆ (ನಾನು ಅದನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ), ಇರುವೆ ಮೂಲಕ ನಿರ್ಮಿಸುವ ಬದಲು (ಮಾವೆನ್ ಇನ್ನೂ ಜನಪ್ರಿಯವಾಗಿಲ್ಲ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ), ಜನರು ಸರಳವಾಗಿ IDE ಯಲ್ಲಿ ಜಾಡಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಶಾಂತವಾಗಿ ಬದ್ಧರಾಗಿದ್ದಾರೆ. ಇದು SVN ನಲ್ಲಿ. ಅಂತೆಯೇ, ನಿಯೋಜನೆಯು SVN ನಿಂದ ಫೈಲ್ ಅನ್ನು ಹಿಂಪಡೆಯುವುದು ಮತ್ತು SSH ಮೂಲಕ ಬಯಸಿದ ಯಂತ್ರಕ್ಕೆ ನಕಲಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇದು ತುಂಬಾ ಸರಳ ಮತ್ತು ವಿಕಾರವಾಗಿದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, PHP ಯಲ್ಲಿನ ಸರಳ ಸೈಟ್‌ಗಳ ವಿತರಣೆಯನ್ನು ಎಫ್‌ಟಿಪಿ ಮೂಲಕ ಸರಿಪಡಿಸಿದ ಫೈಲ್ ಅನ್ನು ಗುರಿ ಯಂತ್ರಕ್ಕೆ ಸರಳವಾಗಿ ನಕಲಿಸುವ ಮೂಲಕ ಅತ್ಯಂತ ಪ್ರಾಚೀನ ರೀತಿಯಲ್ಲಿ ಮಾಡಲಾಯಿತು. ಕೆಲವೊಮ್ಮೆ ಇದು ಹಾಗಲ್ಲ - ಉತ್ಪನ್ನ ಸರ್ವರ್‌ನಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಲೈವ್ ಆಗಿ ಸಂಪಾದಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲೋ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಇದ್ದಲ್ಲಿ ಅದು ವಿಶೇಷವಾಗಿ ಚಿಕ್ ಆಗಿರುತ್ತದೆ.
RPM ಮತ್ತು DEB ಪ್ಯಾಕೇಜುಗಳು
ಮತ್ತೊಂದೆಡೆ, ಇಂಟರ್ನೆಟ್‌ನ ಅಭಿವೃದ್ಧಿಯೊಂದಿಗೆ, UNIX ತರಹದ ವ್ಯವಸ್ಥೆಗಳು ಹೆಚ್ಚು ಹೆಚ್ಚು ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು, ನಿರ್ದಿಷ್ಟವಾಗಿ, ಆ ಸಮಯದಲ್ಲಿ ನಾನು ಸುಮಾರು 6 ರಲ್ಲಿ RedHat Linux 2000 ಅನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ತಲುಪಿಸಲು ಕೆಲವು ವಿಧಾನಗಳಿವೆ; ವಿಕಿಪೀಡಿಯಾದ ಪ್ರಕಾರ, RPM ಮುಖ್ಯ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಆಗಿ ಈಗಾಗಲೇ 1995 ರಲ್ಲಿ RedHat Linux 2.0 ಆವೃತ್ತಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಮತ್ತು ಅಂದಿನಿಂದ ಇಂದಿನವರೆಗೂ, ಸಿಸ್ಟಮ್ ಅನ್ನು RPM ಪ್ಯಾಕೇಜುಗಳ ರೂಪದಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಯಶಸ್ವಿಯಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದೆ.
ಡೆಬಿಯನ್ ಕುಟುಂಬದ ವಿತರಣೆಗಳು ಇದೇ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿದವು ಮತ್ತು ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳ ರೂಪದಲ್ಲಿ ವಿತರಣೆಯನ್ನು ಜಾರಿಗೆ ತಂದವು, ಇದು ಇಂದಿಗೂ ಬದಲಾಗದೆ ಉಳಿದಿದೆ.
ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳು ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನಗಳನ್ನು ಸ್ವತಃ ತಲುಪಿಸಲು, ಅನುಸ್ಥಾಪನ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು, ವಿಭಿನ್ನ ಪ್ಯಾಕೇಜ್‌ಗಳ ನಡುವೆ ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು, ಉತ್ಪನ್ನಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಮತ್ತು ಅನ್‌ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅನಗತ್ಯ ವಸ್ತುಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆ. ಬಹುಮಟ್ಟಿಗೆ, ಇದು ಬೇಕಾಗಿರುವುದು ಅಷ್ಟೆ, ಅದಕ್ಕಾಗಿಯೇ ಅವು ಹಲವಾರು ದಶಕಗಳವರೆಗೆ ವಾಸ್ತವಿಕವಾಗಿ ಬದಲಾಗದೆ ಉಳಿದಿವೆ.
ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ಭೌತಿಕ ಮಾಧ್ಯಮದಿಂದ ಮಾತ್ರವಲ್ಲದೆ ಕ್ಲೌಡ್ ರೆಪೊಸಿಟರಿಗಳಿಂದಲೂ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳಿಗೆ ಅನುಸ್ಥಾಪನೆಯನ್ನು ಸೇರಿಸಿದೆ, ಆದರೆ ಮೂಲಭೂತವಾಗಿ ಸ್ವಲ್ಪ ಬದಲಾಗಿದೆ.
ಗಮನಿಸಬೇಕಾದ ಅಂಶವೆಂದರೆ ಪ್ರಸ್ತುತ ಡೆಬ್‌ನಿಂದ ದೂರ ಸರಿಯಲು ಮತ್ತು ಸ್ನ್ಯಾಪ್ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಲು ಕೆಲವು ಚಲನೆಗಳಿವೆ, ಆದರೆ ಅದರ ನಂತರ ಇನ್ನಷ್ಟು.
ಆದ್ದರಿಂದ, DEB ಅಥವಾ RPM ಎರಡನ್ನೂ ತಿಳಿದಿಲ್ಲದ ಈ ಹೊಸ ಪೀಳಿಗೆಯ ಕ್ಲೌಡ್ ಡೆವಲಪರ್‌ಗಳು ಸಹ ನಿಧಾನವಾಗಿ ಬೆಳೆದರು, ಅನುಭವವನ್ನು ಪಡೆದರು, ಉತ್ಪನ್ನಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದವು ಮತ್ತು FTP, ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಅಂತಹುದೇ ವಿದ್ಯಾರ್ಥಿ ಕರಕುಶಲಗಳಿಗಿಂತ ಕೆಲವು ಹೆಚ್ಚು ಸಮಂಜಸವಾದ ವಿತರಣಾ ವಿಧಾನಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಮತ್ತು ಇಲ್ಲಿ ಡಾಕರ್ ಚಿತ್ರಕ್ಕೆ ಬರುತ್ತಾನೆ, ಒಂದು ರೀತಿಯ ವರ್ಚುವಲೈಸೇಶನ್ ಮಿಶ್ರಣ, ಸಂಪನ್ಮೂಲ ಡಿಲಿಮಿಟೇಶನ್ ಮತ್ತು ವಿತರಣಾ ವಿಧಾನ. ಇದು ಈಗ ಫ್ಯಾಶನ್ ಮತ್ತು ತಾರುಣ್ಯವಾಗಿದೆ, ಆದರೆ ಇದು ಎಲ್ಲದಕ್ಕೂ ಅಗತ್ಯವಿದೆಯೇ? ಇದು ರಾಮಬಾಣವೇ?
ನನ್ನ ಅವಲೋಕನಗಳಿಂದ, ಆಗಾಗ್ಗೆ ಡಾಕರ್ ಅನ್ನು ಸಮಂಜಸವಾದ ಆಯ್ಕೆಯಾಗಿ ಪ್ರಸ್ತಾಪಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಸರಳವಾಗಿ ಏಕೆಂದರೆ, ಒಂದು ಕಡೆ, ಇದನ್ನು ಸಮುದಾಯದಲ್ಲಿ ಮಾತನಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪ್ರಸ್ತಾಪಿಸುವವರಿಗೆ ಮಾತ್ರ ತಿಳಿದಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಬಹುಪಾಲು ಅವರು ಉತ್ತಮ ಹಳೆಯ ಪ್ಯಾಕೇಜಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳ ಬಗ್ಗೆ ಮೌನವಾಗಿರುತ್ತಾರೆ - ಅವರು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ತಮ್ಮ ಕೆಲಸವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮತ್ತು ಗಮನಿಸದೆ ಮಾಡುತ್ತಾರೆ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ನಿಜವಾಗಿಯೂ ಬೇರೆ ಆಯ್ಕೆಗಳಿಲ್ಲ - ಆಯ್ಕೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಡಾಕರ್.
ನಾವು ಡಾಕರ್ ಅನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದರ ಪರಿಣಾಮವಾಗಿ ಏನಾಯಿತು ಎಂಬುದರ ಕುರಿತು ನನ್ನ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.
ಸ್ವ-ಬರೆದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
ಆರಂಭದಲ್ಲಿ, ಅಗತ್ಯವಿರುವ ಯಂತ್ರಗಳಿಗೆ ಜಾರ್ ಆರ್ಕೈವ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಇದ್ದವು. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಜೆಂಕಿನ್ಸ್ ನಿರ್ವಹಿಸಿದರು. ಜಾರ್ ಆರ್ಕೈವ್ ಈಗಾಗಲೇ ತರಗತಿಗಳು, ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಅಸೆಂಬ್ಲಿ ಆಗಿರುವುದರಿಂದ ಇದು ಯಶಸ್ವಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ನೀವು ಎಲ್ಲವನ್ನೂ ಅದರಲ್ಲಿ ಗರಿಷ್ಠವಾಗಿ ಇರಿಸಿದರೆ, ಅದನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ವಿಸ್ತರಿಸುವುದು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ವಿಷಯವಲ್ಲ
ಆದರೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಹಲವಾರು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿವೆ:
- ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ತರಾತುರಿಯಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಅವು ಕೇವಲ ಒಂದು ಅತ್ಯುತ್ತಮ ಸನ್ನಿವೇಶವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಡೆವಲಪರ್ ತ್ವರಿತ ವಿತರಣೆಯಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಯೋಗ್ಯ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳ ಹೂಡಿಕೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದ ಇದು ಸುಗಮಗೊಳಿಸಲ್ಪಟ್ಟಿದೆ.
- ಹಿಂದಿನ ಬಿಂದುವಿನ ಪರಿಣಾಮವಾಗಿ, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಅಸ್ಥಾಪನೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ
- ಯಾವುದೇ ಸ್ಥಾಪಿತ ನವೀಕರಣ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ
- ಹೊಸ ಉತ್ಪನ್ನ ಕಾಣಿಸಿಕೊಂಡಾಗ, ನೀವು ಹೊಸ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗುತ್ತದೆ
- ಯಾವುದೇ ಅವಲಂಬನೆ ಬೆಂಬಲವಿಲ್ಲ
ಸಹಜವಾಗಿ, ನೀವು ಅತ್ಯಾಧುನಿಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆಯಬಹುದು, ಆದರೆ, ನಾನು ಮೇಲೆ ಬರೆದಂತೆ, ಇದು ಅಭಿವೃದ್ಧಿಯ ಸಮಯ, ಮತ್ತು ಕನಿಷ್ಠವಲ್ಲ, ಮತ್ತು, ನಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಯಾವಾಗಲೂ ಸಾಕಷ್ಟು ಸಮಯ ಇರುವುದಿಲ್ಲ.
ಇವೆಲ್ಲವೂ ನಿಸ್ಸಂಶಯವಾಗಿ ಈ ನಿಯೋಜನೆ ವಿಧಾನದ ಅನ್ವಯದ ವ್ಯಾಪ್ತಿಯನ್ನು ಸರಳವಾದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಇದನ್ನು ಬದಲಾಯಿಸುವ ಸಮಯ ಬಂದಿದೆ.
ಡಾಕರ್
ಕೆಲವು ಸಮಯದಲ್ಲಿ, ಹೊಸದಾಗಿ ತಯಾರಿಸಿದ ಮಧ್ಯವರ್ತಿಗಳು ನಮ್ಮ ಬಳಿಗೆ ಬರಲು ಪ್ರಾರಂಭಿಸಿದರು, ಆಲೋಚನೆಗಳೊಂದಿಗೆ ಕುಣಿಯುತ್ತಾರೆ ಮತ್ತು ಡಾಕರ್ ಬಗ್ಗೆ ರೇವಿಂಗ್ ಮಾಡಿದರು. ಸರಿ, ಕೈಯಲ್ಲಿ ಧ್ವಜ - ಅದನ್ನು ಮಾಡೋಣ! ಎರಡು ಪ್ರಯತ್ನಗಳಿದ್ದವು. ಎರಡೂ ವಿಫಲವಾದವು - ದೊಡ್ಡ ಮಹತ್ವಾಕಾಂಕ್ಷೆಗಳಿಂದಾಗಿ, ಆದರೆ ನಿಜವಾದ ಅನುಭವದ ಕೊರತೆಯಿಂದ ಹೇಳೋಣ. ಅದನ್ನು ಬಲವಂತಪಡಿಸಿ ಯಾವುದೇ ವಿಧಾನದಿಂದ ಮುಗಿಸುವ ಅಗತ್ಯವಿತ್ತೇ? ಇದು ಅಸಂಭವವಾಗಿದೆ - ಸೂಕ್ತವಾದ ಪರಿಕರಗಳನ್ನು ಬಳಸುವ ಮೊದಲು ತಂಡವು ಅಗತ್ಯ ಮಟ್ಟಕ್ಕೆ ವಿಕಸನಗೊಳ್ಳಬೇಕು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ರೆಡಿಮೇಡ್ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ಬಳಸುವಾಗ, ನೆಟ್‌ವರ್ಕ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ (ಇದು ಡಾಕರ್‌ನ ತೇವದಿಂದಾಗಿರಬಹುದು) ಅಥವಾ ಇತರ ಜನರ ಕಂಟೇನರ್‌ಗಳನ್ನು ವಿಸ್ತರಿಸಲು ಕಷ್ಟಕರವಾಗಿದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಆಗಾಗ್ಗೆ ಎದುರಿಸುತ್ತೇವೆ.
ನಾವು ಯಾವ ಅನಾನುಕೂಲತೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ?
- ಸೇತುವೆ ಮೋಡ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು
- ಕಂಟೇನರ್‌ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಅನಾನುಕೂಲವಾಗಿದೆ (ಹೋಸ್ಟ್ ಯಂತ್ರದ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸದಿದ್ದರೆ)
- ElasticSearch ಸಾಂದರ್ಭಿಕವಾಗಿ ಕಂಟೇನರ್ ಒಳಗೆ ವಿಚಿತ್ರವಾಗಿ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ, ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸಲಾಗಿಲ್ಲ, ಕಂಟೇನರ್ ಅಧಿಕೃತವಾಗಿದೆ
- ಕಂಟೇನರ್ ಒಳಗೆ ಶೆಲ್ ಅನ್ನು ಬಳಸುವುದು ಅವಶ್ಯಕ - ಎಲ್ಲವನ್ನೂ ತುಂಬಾ ತೆಗೆದುಹಾಕಲಾಗಿದೆ, ಯಾವುದೇ ಪರಿಚಿತ ಸಾಧನಗಳಿಲ್ಲ
- ಸಂಗ್ರಹಿಸಿದ ಪಾತ್ರೆಗಳ ದೊಡ್ಡ ಗಾತ್ರ - ಸಂಗ್ರಹಿಸಲು ದುಬಾರಿ
- ಧಾರಕಗಳ ದೊಡ್ಡ ಗಾತ್ರದ ಕಾರಣ, ಬಹು ಆವೃತ್ತಿಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು ಕಷ್ಟ
- ಇತರ ವಿಧಾನಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ (ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಅಥವಾ ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳು) ದೀರ್ಘ ನಿರ್ಮಾಣ ಸಮಯ
ಮತ್ತೊಂದೆಡೆ, ಅದೇ ಡೆಬ್ ಮೂಲಕ ಜಾರ್ ಆರ್ಕೈವ್ ರೂಪದಲ್ಲಿ ಸ್ಪ್ರಿಂಗ್ ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ಏಕೆ ಕೆಟ್ಟದಾಗಿದೆ? ಸಂಪನ್ಮೂಲ ಪ್ರತ್ಯೇಕತೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆಯೇ? ಸೇವೆಯನ್ನು ಹೆಚ್ಚು ಕಡಿಮೆಯಾದ ಕಂಟೇನರ್‌ನಲ್ಲಿ ತುಂಬುವ ಮೂಲಕ ಅನುಕೂಲಕರ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಪರಿಕರಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ?
ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ವಾಸ್ತವದಲ್ಲಿ ಇದು ಅಗತ್ಯವಿಲ್ಲ, 90% ಪ್ರಕರಣಗಳಲ್ಲಿ ಡೆಬ್ ಪ್ಯಾಕೇಜ್ ಸಾಕು.
ಉತ್ತಮ ಹಳೆಯ ಡೆಬ್ ಯಾವಾಗ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಮಗೆ ನಿಜವಾಗಿಯೂ ಡಾಕರ್ ಯಾವಾಗ ಬೇಕು?
ನಮಗೆ, ಇದು ಪೈಥಾನ್‌ನಲ್ಲಿ ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತಿದೆ. ಯಂತ್ರ ಕಲಿಕೆಗೆ ಅಗತ್ಯವಿರುವ ಬಹಳಷ್ಟು ಗ್ರಂಥಾಲಯಗಳು ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಪ್ರಮಾಣಿತ ವಿತರಣೆಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ (ಮತ್ತು ತಪ್ಪು ಆವೃತ್ತಿಗಳು ಇದ್ದವು), ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಹ್ಯಾಕ್‌ಗಳು, ಒಂದೇ ಹೋಸ್ಟ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ವಾಸಿಸುವ ವಿಭಿನ್ನ ಸೇವೆಗಳಿಗೆ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳ ಅಗತ್ಯವು ಕಾರಣವಾಯಿತು ಈ ಪರಮಾಣು ಮಿಶ್ರಣವನ್ನು ತಲುಪಿಸಲು ಏಕೈಕ ಸಮಂಜಸವಾದ ಮಾರ್ಗವೆಂದರೆ ಡಾಕರ್. ಡಾಕರ್ ಕಂಟೇನರ್ ಅನ್ನು ಜೋಡಿಸುವ ಕಾರ್ಮಿಕ ತೀವ್ರತೆಯು ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳಾಗಿ ಪ್ಯಾಕ್ ಮಾಡುವ ಕಲ್ಪನೆಗಿಂತ ಕಡಿಮೆಯಾಗಿದೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಅವರ ಸರಿಯಾದ ಮನಸ್ಸಿನಲ್ಲಿ ಯಾರೂ ಇದನ್ನು ಕೈಗೊಳ್ಳುವುದಿಲ್ಲ.
ಡಾಕರ್ ಅನ್ನು ಬಳಸಲು ಯೋಜಿಸಲಾದ ಎರಡನೇ ಅಂಶವೆಂದರೆ ನೀಲಿ-ಹಸಿರು ನಿಯೋಜನೆ ಯೋಜನೆಯ ಪ್ರಕಾರ ಸೇವೆಗಳನ್ನು ನಿಯೋಜಿಸುವುದು. ಆದರೆ ಇಲ್ಲಿ ನಾನು ಸಂಕೀರ್ಣತೆಯಲ್ಲಿ ಕ್ರಮೇಣ ಹೆಚ್ಚಳವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇನೆ: ಮೊದಲು, ಡೆಬ್ ಪ್ಯಾಕೇಜುಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ಅವುಗಳಿಂದ ಡಾಕರ್ ಕಂಟೇನರ್ ಅನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ.
ಸ್ನ್ಯಾಪ್ ಪ್ಯಾಕೇಜ್‌ಗಳು
ಸ್ನ್ಯಾಪ್ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗೋಣ. ಅವರು ಮೊದಲು ಅಧಿಕೃತವಾಗಿ ಉಬುಂಟು 16.04 ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರು. ಸಾಮಾನ್ಯ deb ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು rpm ಪ್ಯಾಕೇಜುಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, snap ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿದೆ. ಒಂದೆಡೆ, ಇದು ಲೈಬ್ರರಿ ಸಂಘರ್ಷಗಳನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತೊಂದೆಡೆ, ಪರಿಣಾಮವಾಗಿ ಪ್ಯಾಕೇಜ್ ಗಾತ್ರದಲ್ಲಿ ದೊಡ್ಡದಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇದು ಸಿಸ್ಟಂನ ಭದ್ರತೆಯ ಮೇಲೂ ಪರಿಣಾಮ ಬೀರಬಹುದು: ಸ್ನ್ಯಾಪ್ ವಿತರಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಒಳಗೊಂಡಿರುವ ಲೈಬ್ರರಿಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರಚಿಸುವ ಡೆವಲಪರ್ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು. ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಲ್ಲ ಮತ್ತು ಸಾರ್ವತ್ರಿಕ ಸಂತೋಷವು ಅವುಗಳನ್ನು ಬಳಸುವುದರಿಂದ ಬರುವುದಿಲ್ಲ. ಆದರೆ, ಅದೇನೇ ಇದ್ದರೂ, ಅದೇ ಡಾಕರ್ ಅನ್ನು ಪ್ಯಾಕೇಜಿಂಗ್ ಸಾಧನವಾಗಿ ಮಾತ್ರ ಬಳಸಿದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸಮಂಜಸವಾದ ಪರ್ಯಾಯವಾಗಿದೆ ಮತ್ತು ವರ್ಚುವಲೈಸೇಶನ್‌ಗಾಗಿ ಅಲ್ಲ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈಗ ಡೆಬ್ ಪ್ಯಾಕೇಜ್‌ಗಳು ಮತ್ತು ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ಸಮಂಜಸವಾದ ಸಂಯೋಜನೆಯಲ್ಲಿ ಬಳಸುತ್ತೇವೆ, ಬಹುಶಃ, ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ನಾವು ಸ್ನ್ಯಾಪ್ ಪ್ಯಾಕೇಜ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ.
ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. , ದಯವಿಟ್ಟು.
ವಿತರಣೆಗಾಗಿ ನೀವು ಏನು ಬಳಸುತ್ತೀರಿ?
-
ಸ್ವ-ಬರೆದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು
-
FTP ಗೆ ಹಸ್ತಚಾಲಿತವಾಗಿ ನಕಲಿಸಿ
-
deb ಪ್ಯಾಕೇಜುಗಳು
-
rpm ಪ್ಯಾಕೇಜುಗಳು
-
ಸ್ನ್ಯಾಪ್ ಪ್ಯಾಕೇಜುಗಳು
-
ಡಾಕರ್-ಚಿತ್ರಗಳು
-
ವರ್ಚುವಲ್ ಯಂತ್ರ ಚಿತ್ರಗಳು
-
ಸಂಪೂರ್ಣ HDD ಅನ್ನು ಕ್ಲೋನ್ ಮಾಡಿ
-
ಕೈಗೊಂಬೆ
-
ಉತ್ತರಿಸಬಲ್ಲ
-
ಇತರೆ
109 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 32 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.
ಮೂಲ: www.habr.com