ಡಾಕರ್ ಮತ್ತು ಗಿಟ್ಲ್ಯಾಬ್ CI ನೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆ

Inventos ನಿಂದ ಅಲೆಕ್ಸಾಂಡರ್ ಸಿಗಾಚೆವ್ ಅವರ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ "ಡಾಕರ್ + ಗಿಟ್ಲಾಬ್ CI ನೊಂದಿಗೆ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆ"

ಡಾಕರ್ + ಗಿಟ್‌ಲ್ಯಾಬ್ CI ಆಧಾರಿತ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವವರು ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲಭೂತ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾರೆ. ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕು? ಸಂಘಟಿಸುವುದು ಹೇಗೆ? ಪರೀಕ್ಷೆ ಮಾಡುವುದು ಹೇಗೆ?

ಈ ವರದಿಯು ಉತ್ತಮವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಡಾಕರ್ ಮತ್ತು ಗಿಟ್ಲಾಬ್ CI ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ರಚನಾತ್ಮಕ ರೀತಿಯಲ್ಲಿ ಮಾತನಾಡುತ್ತದೆ. ವರದಿ ಸ್ವತಃ 2017 ರದ್ದಾಗಿದೆ. ಈ ವರದಿಯಿಂದ ನೀವು ಮೂಲಭೂತ, ವಿಧಾನ, ಕಲ್ಪನೆ, ಬಳಕೆಯ ಅನುಭವವನ್ನು ಕಲಿಯಬಹುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಯಾರು ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ, ದಯವಿಟ್ಟು ಬೆಕ್ಕಿನ ಕೆಳಗೆ.

ನನ್ನ ಹೆಸರು ಅಲೆಕ್ಸಾಂಡರ್ ಸಿಗಾಚೆವ್. ನಾನು ಇನ್ವೆಂಟೋಸ್‌ಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಡಾಕರ್ ಅನ್ನು ಬಳಸುವ ನನ್ನ ಅನುಭವದ ಬಗ್ಗೆ ಮತ್ತು ಕಂಪನಿಯಲ್ಲಿನ ಯೋಜನೆಗಳಲ್ಲಿ ನಾವು ಅದನ್ನು ಕ್ರಮೇಣ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ಪ್ರಸ್ತುತಿ ವಿಷಯ: ಡಾಕರ್ ಮತ್ತು ಗಿಟ್ಲಾಬ್ CI ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ.

ಡಾಕರ್ ಬಗ್ಗೆ ಇದು ನನ್ನ ಎರಡನೇ ಮಾತು. ಮೊದಲ ವರದಿಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಡೆವಲಪರ್ ಯಂತ್ರಗಳಲ್ಲಿ ಡೆವಲಪ್‌ನಲ್ಲಿ ಡಾಕರ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಿದ್ದೇವೆ. ಡಾಕರ್ ಬಳಸಿದ ಉದ್ಯೋಗಿಗಳ ಸಂಖ್ಯೆ ಸುಮಾರು 2-3 ಜನರು. ಕ್ರಮೇಣ, ಅನುಭವವನ್ನು ಪಡೆಯಿತು ಮತ್ತು ನಾವು ಸ್ವಲ್ಪ ಮುಂದೆ ಹೋದೆವು. ನಮ್ಮ ಲಿಂಕ್ ಮೊದಲ ವರದಿ.

ಈ ವರದಿಯಲ್ಲಿ ಏನಿರಲಿದೆ? ನಾವು ಯಾವ ಕುಂಟೆ ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ, ನಾವು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ. ಎಲ್ಲೆಡೆ ಅದು ಸುಂದರವಾಗಿಲ್ಲ, ಆದರೆ ಮುಂದುವರಿಯಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.

ನಮ್ಮ ಧ್ಯೇಯವಾಕ್ಯವೆಂದರೆ: ನಮ್ಮ ಕೈಗೆ ಸಿಗುವ ಎಲ್ಲವನ್ನೂ ಡಾಕ್ ಮಾಡಿ.

ನಾವು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೇವೆ?

ಕಂಪನಿಯಲ್ಲಿ ಹಲವಾರು ತಂಡಗಳು ಇದ್ದಾಗ, ಪ್ರೋಗ್ರಾಮರ್ ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲವಾಗಿದೆ. ಪ್ರೋಗ್ರಾಮರ್ ಅನ್ನು ಒಂದು ಯೋಜನೆಯಿಂದ ಹೊರತೆಗೆದು ಮತ್ತೊಂದು ಯೋಜನೆಗೆ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನೀಡಿದಾಗ ಹಂತಗಳಿವೆ.

ಪ್ರೋಗ್ರಾಮರ್ ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಅವರು ಯೋಜನೆಯ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪರಿಸರವನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು, ಇದು ಈ ಯೋಜನೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತಷ್ಟು ಚಲಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು ಮೊದಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಿದರೆ, ಯೋಜನೆಯಲ್ಲಿ ಕಡಿಮೆ ದಾಖಲಾತಿ ಇರುತ್ತದೆ. ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂಬ ಮಾಹಿತಿಯು ಹಳೆಯ ಕಾಲದವರಿಗೆ ಮಾತ್ರ ಲಭ್ಯವಿರುತ್ತದೆ. ಉದ್ಯೋಗಿಗಳು ಒಂದು ಅಥವಾ ಎರಡು ದಿನಗಳಲ್ಲಿ ತಮ್ಮ ಕೆಲಸದ ಸ್ಥಳವನ್ನು ತಾವಾಗಿಯೇ ಸ್ಥಾಪಿಸುತ್ತಾರೆ. ಇದನ್ನು ವೇಗಗೊಳಿಸಲು, ನಾವು ಡಾಕರ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ.

ಮುಂದಿನ ಕಾರಣವೆಂದರೆ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪ್ರಮಾಣೀಕರಣ. ನನ್ನ ಅನುಭವದಲ್ಲಿ, ಅಭಿವರ್ಧಕರು ಯಾವಾಗಲೂ ಉಪಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಪ್ರತಿ ಐದನೇ ಪ್ರಕರಣದಲ್ಲಿ, ಕಸ್ಟಮ್ ಡೊಮೇನ್ ಅನ್ನು ನಮೂದಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, vasya.dev. ಅವನ ಪಕ್ಕದಲ್ಲಿ ಕುಳಿತಿರುವುದು ಅವನ ನೆರೆಯ ಪೆಟ್ಯಾ, ಅವರ ಡೊಮೇನ್ petya.dev. ಅವರು ಈ ಡೊಮೇನ್ ಹೆಸರನ್ನು ಬಳಸಿಕೊಂಡು ವೆಬ್‌ಸೈಟ್ ಅಥವಾ ಸಿಸ್ಟಮ್‌ನ ಕೆಲವು ಘಟಕಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾರೆ.

ಸಿಸ್ಟಮ್ ಬೆಳೆದಾಗ ಮತ್ತು ಈ ಡೊಮೇನ್ ಹೆಸರುಗಳು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗೆ ಪ್ರವೇಶಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅಭಿವೃದ್ಧಿ ಪರಿಸರ ಸಂಘರ್ಷ ಉಂಟಾಗುತ್ತದೆ ಮತ್ತು ಸೈಟ್ ಮಾರ್ಗವನ್ನು ಪುನಃ ಬರೆಯಲಾಗುತ್ತದೆ.

ಡೇಟಾಬೇಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಅದೇ ಸಂಭವಿಸುತ್ತದೆ. ಯಾರೋ ಭದ್ರತೆಯ ಬಗ್ಗೆ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಖಾಲಿ ರೂಟ್ ಪಾಸ್‌ವರ್ಡ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. ಅನುಸ್ಥಾಪನೆಯ ಹಂತದಲ್ಲಿ, MySQL ಯಾರನ್ನಾದರೂ ಪಾಸ್‌ವರ್ಡ್‌ಗಾಗಿ ಕೇಳಿದೆ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ 123 ಆಗಿ ಹೊರಹೊಮ್ಮಿತು. ಡೆವಲಪರ್‌ನ ಬದ್ಧತೆಯನ್ನು ಅವಲಂಬಿಸಿ ಡೇಟಾಬೇಸ್ ಕಾನ್ಫಿಗರ್ ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುತ್ತದೆ. ಯಾರೋ ಸರಿಪಡಿಸಿದ್ದಾರೆ, ಯಾರಾದರೂ ಸಂರಚನೆಯನ್ನು ಸರಿಪಡಿಸಲಿಲ್ಲ. ನಾವು ಕೆಲವು ರೀತಿಯ ಪರೀಕ್ಷಾ ಸಂರಚನೆಯನ್ನು ತೆಗೆದುಕೊಂಡಾಗ ತಂತ್ರಗಳು ಇದ್ದವು .gitignore ಮತ್ತು ಪ್ರತಿ ಡೆವಲಪರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗಿತ್ತು. ಇದರಿಂದ ಪ್ರಾರಂಭಿಸಲು ಕಷ್ಟವಾಯಿತು. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಡೇಟಾಬೇಸ್ ಬಗ್ಗೆ ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು, ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ನಮೂದಿಸಬೇಕು, ಬಳಕೆದಾರರನ್ನು ನೋಂದಾಯಿಸಬೇಕು, ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಬೇಕು, ಇತ್ಯಾದಿ.

ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಗ್ರಂಥಾಲಯಗಳ ವಿವಿಧ ಆವೃತ್ತಿಗಳು. ಡೆವಲಪರ್ ವಿಭಿನ್ನ ಯೋಜನೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ. ಐದು ವರ್ಷಗಳ ಹಿಂದೆ ಪ್ರಾರಂಭವಾದ ಲೆಗಸಿ ಪ್ರಾಜೆಕ್ಟ್ ಇದೆ (2017 ರಿಂದ - ಸಂ. ಟಿಪ್ಪಣಿ). ಬಿಡುಗಡೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು MySQL 5.5 ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು MySQL ನ ಹೆಚ್ಚು ಆಧುನಿಕ ಆವೃತ್ತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಆಧುನಿಕ ಯೋಜನೆಗಳು ಸಹ ಇವೆ, ಉದಾಹರಣೆಗೆ, 5.7 ಅಥವಾ ಹಳೆಯದು (2017 ರಲ್ಲಿ - ಸಂ. ಟಿಪ್ಪಣಿ)

MySQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಯಾರಾದರೂ ಈ ಗ್ರಂಥಾಲಯಗಳು ತಮ್ಮೊಂದಿಗೆ ಅವಲಂಬನೆಗಳನ್ನು ತರುತ್ತವೆ ಎಂದು ತಿಳಿದಿದ್ದಾರೆ. 2 ಬೇಸ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಚಲಾಯಿಸಲು ಇದು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಕನಿಷ್ಠ, ಹಳೆಯ ಕ್ಲೈಂಟ್‌ಗಳು ಹೊಸ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿವೆ. ಇದು ಪ್ರತಿಯಾಗಿ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಡೆವಲಪರ್ ಸ್ಥಳೀಯ ಗಣಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ ಮುಂದಿನ ಸಮಸ್ಯೆ, ಅವರು ಸ್ಥಳೀಯ ಸಂಪನ್ಮೂಲಗಳು, ಸ್ಥಳೀಯ ಫೈಲ್ಗಳು, ಸ್ಥಳೀಯ RAM ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ಸಮಸ್ಯೆಗಳಿಗೆ ಪರಿಹಾರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಸಂವಹನಗಳನ್ನು ಅದು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ಚೌಕಟ್ಟಿನೊಳಗೆ ನಡೆಸಲಾಗುತ್ತದೆ. ನಾವು ಪ್ರೊಡಕ್ಷನ್ 3 ರಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ, ಮತ್ತು ಡೆವಲಪರ್ ಫೈಲ್‌ಗಳನ್ನು ರೂಟ್ ಡೈರೆಕ್ಟರಿಗೆ ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು nginx ಫೈಲ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅಂತಹ ಕೋಡ್ ಉತ್ಪಾದನೆಗೆ ಬಂದಾಗ, ಫೈಲ್ 3 ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ನ ದಿಕ್ಕು ಈಗ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ. ನಾವು ನಮ್ಮ ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪರಸ್ಪರ ಸಂವಹನ ಮಾಡುವ ಕೆಲವು ಸಣ್ಣ ಘಟಕಗಳಾಗಿ ವಿಂಗಡಿಸಿದಾಗ. ನಿರ್ದಿಷ್ಟ ಸ್ಟಾಕ್ ಕಾರ್ಯಗಳಿಗಾಗಿ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳ ನಡುವೆ ಕೆಲಸ ಮತ್ತು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಫ್ರಾಂಡೆಂಡ್-ಡೆವಲಪರ್, JS ನಲ್ಲಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದಿದ್ದು, ಬ್ಯಾಕೆಂಡ್ ಮೇಲೆ ಯಾವುದೇ ಪ್ರಭಾವ ಬೀರುವುದಿಲ್ಲ. ಬ್ಯಾಕೆಂಡ್ ಡೆವಲಪರ್, ಪ್ರತಿಯಾಗಿ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ರೂಬಿ ಆನ್ ರೈಲ್ಸ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಾನೆ ಮತ್ತು ಫ್ರಾಂಡೆಂಡ್‌ನೊಂದಿಗೆ ಮಧ್ಯಪ್ರವೇಶಿಸುವುದಿಲ್ಲ. ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು API ಬಳಸಿ ನಡೆಸಲಾಗುತ್ತದೆ.

ಬೋನಸ್ ಆಗಿ, ಡಾಕರ್ ಸಹಾಯದಿಂದ, ನಾವು ಸ್ಟೇಜಿಂಗ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು. ಪ್ರತಿಯೊಂದು ಯೋಜನೆಯು ಅದರ ನಿಶ್ಚಿತಗಳ ಕಾರಣದಿಂದಾಗಿ, ಕೆಲವು ಸೆಟ್ಟಿಂಗ್ಗಳ ಅಗತ್ಯವಿದೆ. ಭೌತಿಕವಾಗಿ, ವರ್ಚುವಲ್ ಸರ್ವರ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಅಥವಾ ಕೆಲವು ರೀತಿಯ ವೇರಿಯಬಲ್ ಪರಿಸರವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಮತ್ತು ಯೋಜನೆಗಳು ಗ್ರಂಥಾಲಯಗಳ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಪರಸ್ಪರ ಪ್ರಭಾವ ಬೀರಲು ಅಗತ್ಯವಾಗಿತ್ತು.

ಪರಿಕರಗಳು. ನಾವು ಏನು ಬಳಸುತ್ತೇವೆ?

• ಸ್ವತಃ ಡಾಕರ್. ಡಾಕರ್‌ಫೈಲ್ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಅವಲಂಬನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
• ಡಾಕರ್-ಕಂಪೋಸ್ ಎನ್ನುವುದು ನಮ್ಮ ಕೆಲವು ಡಾಕರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಬಂಡಲ್ ಆಗಿದೆ.
• ಮೂಲ ಕೋಡ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು GitLab ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
• ಸಿಸ್ಟಮ್ ಏಕೀಕರಣಕ್ಕಾಗಿ ನಾವು GitLab-CI ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ವರದಿಯು ಎರಡು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಡೆವಲಪರ್‌ಗಳ ಯಂತ್ರಗಳಲ್ಲಿ ಡಾಕರ್ ಅನ್ನು ಹೇಗೆ ಚಲಾಯಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮೊದಲ ಭಾಗವು ಮಾತನಾಡುತ್ತದೆ.

ಎರಡನೇ ಭಾಗವು GitLab ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುವುದು, ನಾವು ಪರೀಕ್ಷೆಗಳನ್ನು ಹೇಗೆ ನಡೆಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಹೇಗೆ ಸ್ಟೇಜಿಂಗ್‌ಗೆ ಹೊರಡುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ.

ಡಾಕರ್ ಎನ್ನುವುದು ಅಗತ್ಯ ಘಟಕಗಳನ್ನು ವಿವರಿಸಲು (ಘೋಷಣಾ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು) ಅನುಮತಿಸುವ ತಂತ್ರಜ್ಞಾನವಾಗಿದೆ. ಇದು ಡಾಕರ್‌ಫೈಲ್‌ಗೆ ಉದಾಹರಣೆಯಾಗಿದೆ. ಇಲ್ಲಿ ನಾವು ಅಧಿಕೃತ ರೂಬಿ:2.3.0 ಡಾಕರ್ ಚಿತ್ರದಿಂದ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತಿದ್ದೇವೆ ಎಂದು ಘೋಷಿಸುತ್ತೇವೆ. ಇದು ರೂಬಿ ಆವೃತ್ತಿ 2.3 ಅನ್ನು ಸ್ಥಾಪಿಸಿದೆ. ನಾವು ಅಗತ್ಯವಿರುವ ಬಿಲ್ಡ್ ಲೈಬ್ರರಿಗಳನ್ನು ಮತ್ತು NodeJS ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ನಾವು ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ವಿವರಿಸುತ್ತೇವೆ /app. ಅಪ್ಲಿಕೇಶನ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ವರ್ಕಿಂಗ್ ಡೈರೆಕ್ಟರಿಯಾಗಿ ಹೊಂದಿಸಿ. ಈ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನಾವು ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ Gemfile ಮತ್ತು Gemfile.lock ಅನ್ನು ಇರಿಸುತ್ತೇವೆ. ನಂತರ ನಾವು ಈ ಅವಲಂಬನೆ ಚಿತ್ರವನ್ನು ಸ್ಥಾಪಿಸುವ ಯೋಜನೆಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ಕಂಟೇನರ್ ಬಾಹ್ಯ ಪೋರ್ಟ್ 3000 ನಲ್ಲಿ ಕೇಳಲು ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ನಾವು ಸೂಚಿಸುತ್ತೇವೆ. ಕೊನೆಯ ಆಜ್ಞೆಯು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೇರವಾಗಿ ಪ್ರಾರಂಭಿಸುವ ಆಜ್ಞೆಯಾಗಿದೆ. ನಾವು ಪ್ರಾಜೆಕ್ಟ್ ಸ್ಟಾರ್ಟ್ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಲು ಮತ್ತು ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಇದು ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್‌ಗೆ ಕನಿಷ್ಠ ಉದಾಹರಣೆಯಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡು ಧಾರಕಗಳ ನಡುವೆ ಸಂಪರ್ಕವಿದೆ ಎಂದು ನಾವು ತೋರಿಸುತ್ತೇವೆ. ಇದು ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್ ಸೇವೆ ಮತ್ತು ವೆಬ್ ಸೇವೆಯಲ್ಲಿದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ನಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ ಕೆಲವು ರೀತಿಯ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿರುತ್ತದೆ. ನಾವು MySQL ಅನ್ನು ಬಳಸುತ್ತಿರುವುದರಿಂದ, ಉದಾಹರಣೆ MySQL ನೊಂದಿಗೆ ಇದೆ - ಆದರೆ ಯಾವುದೂ ಇತರ ಡೇಟಾಬೇಸ್ (PostgreSQL, Redis) ಬಳಸದಂತೆ ನಮ್ಮನ್ನು ತಡೆಯುವುದಿಲ್ಲ.

ನಾವು ಡಾಕರ್ ಹಬ್‌ನಿಂದ ಅಧಿಕೃತ ಮೂಲದಿಂದ ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ MySQL 5.7.14 ನ ಚಿತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಪ್ರಸ್ತುತ ಡೈರೆಕ್ಟರಿಯಿಂದ ನಮ್ಮ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಚಿತ್ರವನ್ನು ನಾವು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಇದು ಮೊದಲ ಉಡಾವಣೆಯ ಸಮಯದಲ್ಲಿ ನಮಗಾಗಿ ಚಿತ್ರವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ನಂತರ ನಾವು ಇಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿರುವ ಆಜ್ಞೆಯನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ನಾವು ಹಿಂತಿರುಗಿದರೆ, ಪೂಮಾ ಮೂಲಕ ಉಡಾವಣಾ ಆಜ್ಞೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಪೂಮಾ ರೂಬಿಯಲ್ಲಿ ಬರೆದ ಸೇವೆಯಾಗಿದೆ. ಎರಡನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಅತಿಕ್ರಮಿಸುತ್ತೇವೆ. ಈ ಆಜ್ಞೆಯು ನಮ್ಮ ಅಗತ್ಯತೆಗಳು ಅಥವಾ ಕಾರ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ ನಿರಂಕುಶವಾಗಿರಬಹುದು.

ಕಂಟೈನರ್ ಪೋರ್ಟ್‌ನಲ್ಲಿ ನಮ್ಮ ಡೆವಲಪರ್ ಹೋಸ್ಟ್ ಯಂತ್ರದಲ್ಲಿ 3000 ರಿಂದ 3000 ವರೆಗೆ ನಾವು ಪೋರ್ಟ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ನಾವು ವಿವರಿಸುತ್ತೇವೆ. iptables ಮತ್ತು ಅದರ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ, ಇದನ್ನು ನೇರವಾಗಿ ಡಾಕರ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ.

ಡೆವಲಪರ್ ಮೊದಲಿನಂತೆ, ಲಭ್ಯವಿರುವ ಯಾವುದೇ IP ವಿಳಾಸವನ್ನು ಪ್ರವೇಶಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, 127.0.0.1 ಎಂಬುದು ಯಂತ್ರದ ಸ್ಥಳೀಯ ಅಥವಾ ಬಾಹ್ಯ IP ವಿಳಾಸವಾಗಿದೆ.

ವೆಬ್ ಕಂಟೇನರ್ ಡಿಬಿ ಕಂಟೇನರ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಎಂದು ಕೊನೆಯ ಸಾಲು ಹೇಳುತ್ತದೆ. ನಾವು ವೆಬ್ ಕಂಟೈನರ್‌ನ ಪ್ರಾರಂಭಕ್ಕೆ ಕರೆ ಮಾಡಿದಾಗ, ಡಾಕರ್-ಕಂಪೋಸ್ ಮೊದಲು ನಮಗಾಗಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈಗಾಗಲೇ ಡೇಟಾಬೇಸ್‌ನ ಪ್ರಾರಂಭದಲ್ಲಿ (ವಾಸ್ತವವಾಗಿ, ಕಂಟೇನರ್‌ನ ಪ್ರಾರಂಭದ ನಂತರ! ಇದು ಡೇಟಾಬೇಸ್‌ನ ಸನ್ನದ್ಧತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ) ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್.

ಡೇಟಾಬೇಸ್ ಅನ್ನು ತರದಿದ್ದಾಗ ಇದು ದೋಷಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್ ಕಂಟೇನರ್ ಅನ್ನು ನಿಲ್ಲಿಸಿದಾಗ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸುತ್ತದೆ, ಹೀಗಾಗಿ ಇತರ ಯೋಜನೆಗಳಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ.

ಯೋಜನೆಯಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಡಾಕರೈಸೇಶನ್ ಬಳಕೆಯನ್ನು ನಮಗೆ ಏನು ನೀಡುತ್ತದೆ. ನಾವು ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ MySQL ನ ಆವೃತ್ತಿಯನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ. ಆವೃತ್ತಿಗಳು ಭಿನ್ನವಾದಾಗ, ಸಿಂಟ್ಯಾಕ್ಸ್, ಕಾನ್ಫಿಗರೇಶನ್, ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಬದಲಾದಾಗ ಸಂಭವಿಸಬಹುದಾದ ಕೆಲವು ದೋಷಗಳನ್ನು ಇದು ತಪ್ಪಿಸುತ್ತದೆ. ಡೇಟಾಬೇಸ್, ಲಾಗಿನ್, ಪಾಸ್‌ವರ್ಡ್‌ಗಾಗಿ ಸಾಮಾನ್ಯ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಮೊದಲು ಹೊಂದಿದ್ದ ಸಂರಚನಾ ಫೈಲ್‌ಗಳಲ್ಲಿನ ಹೆಸರುಗಳು ಮತ್ತು ಸಂಘರ್ಷಗಳ ಮೃಗಾಲಯದಿಂದ ದೂರ ಹೋಗುತ್ತಿದ್ದೇವೆ.

ಅಭಿವೃದ್ಧಿ ಪರಿಸರಕ್ಕಾಗಿ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಸಂರಚನೆಯನ್ನು ಬಳಸಲು ನಮಗೆ ಅವಕಾಶವಿದೆ, ಅದು ಡೀಫಾಲ್ಟ್‌ನಿಂದ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. MySQL ಅನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ದುರ್ಬಲ ಯಂತ್ರಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆ ತುಂಬಾ ಕಳಪೆಯಾಗಿದೆ.

ಅಪೇಕ್ಷಿತ ಆವೃತ್ತಿಯ ಪೈಥಾನ್, ರೂಬಿ, ನೋಡ್ಜೆಎಸ್, ಪಿಎಚ್ಪಿ ಇಂಟರ್ಪ್ರಿಟರ್ ಅನ್ನು ಬಳಸಲು ಡಾಕರ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಕೆಲವು ರೀತಿಯ ಆವೃತ್ತಿ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಬಳಸುವ ಅಗತ್ಯವನ್ನು ನಾವು ತೊಡೆದುಹಾಕುತ್ತೇವೆ. ಹಿಂದೆ, ರೂಬಿ ಒಂದು rpm ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸಿದ್ದು ಅದು ಯೋಜನೆಯ ಆಧಾರದ ಮೇಲೆ ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಇದು ಡಾಕರ್ ಕಂಟೇನರ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ಕೋಡ್ ಅನ್ನು ಸರಾಗವಾಗಿ ಸ್ಥಳಾಂತರಿಸಲು ಮತ್ತು ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಆವೃತ್ತಿಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಇಂಟರ್ಪ್ರಿಟರ್ ಮತ್ತು ಕೋಡ್ ಎರಡರ ಆವೃತ್ತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ನಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆ ಇಲ್ಲ. ಆವೃತ್ತಿಯನ್ನು ನವೀಕರಿಸಲು, ಹಳೆಯ ಕಂಟೇನರ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿ ಮತ್ತು ಹೊಸ ಕಂಟೇನರ್ ಅನ್ನು ಮೇಲಕ್ಕೆತ್ತಿ. ಏನಾದರೂ ತಪ್ಪಾದಲ್ಲಿ, ನಾವು ಹೊಸ ಕಂಟೇನರ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು, ಹಳೆಯ ಕಂಟೇನರ್ ಅನ್ನು ಮೇಲಕ್ಕೆತ್ತಬಹುದು.

ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಿದ ನಂತರ, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಉತ್ಪಾದನೆ ಎರಡರಲ್ಲೂ ಧಾರಕಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ. ದೊಡ್ಡ ಅನುಸ್ಥಾಪನೆಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಸತ್ಯವಾಗಿದೆ.

ಮುಂಭಾಗದಲ್ಲಿ ನಾವು JavaScipt ಮತ್ತು NodeJS ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಈಗ ನಾವು ReacJS ನಲ್ಲಿ ಕೊನೆಯ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಡೆವಲಪರ್ ಕಂಟೇನರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಓಡಿಸಿದ್ದಾರೆ ಮತ್ತು ಹಾಟ್-ರೀಲೋಡ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ.

ಮುಂದೆ, JavaScipt ಅಸೆಂಬ್ಲಿ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಟ್ಯಾಟಿಕ್ಸ್ ಆಗಿ ಸಂಕಲಿಸಲಾದ ಕೋಡ್ ಅನ್ನು nginx ಉಳಿತಾಯ ಸಂಪನ್ಮೂಲಗಳ ಮೂಲಕ ನೀಡಲಾಗುತ್ತದೆ.

ಇಲ್ಲಿ ನಾನು ನಮ್ಮ ಕೊನೆಯ ಯೋಜನೆಯ ಯೋಜನೆಯನ್ನು ನೀಡಿದ್ದೇನೆ.

ಯಾವ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ? ಮೊಬೈಲ್ ಸಾಧನಗಳು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಈ ಸಾಧನಕ್ಕೆ ಪುಶ್ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸುವುದು ಒಂದು ಸಾಧ್ಯತೆಯಾಗಿದೆ.

ಇದಕ್ಕಾಗಿ ನಾವೇನು ​​ಮಾಡಿದ್ದೇವೆ?

ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಂತಹ ಘಟಕಗಳನ್ನು ವಿಂಗಡಿಸಿದ್ದೇವೆ: JS ನಲ್ಲಿ ನಿರ್ವಾಹಕ ಭಾಗ, ಬ್ಯಾಕೆಂಡ್, ರೂಬಿ ಆನ್ ರೈಲ್ಸ್ ಅಡಿಯಲ್ಲಿ REST ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಬ್ಯಾಕೆಂಡ್ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಉತ್ಪತ್ತಿಯಾಗುವ ಫಲಿತಾಂಶವನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಲಾಗುತ್ತದೆ. ನಿರ್ವಾಹಕ ಫಲಕವು ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ REST ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.

ನಮಗೆ ಪುಶ್ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸುವ ಅಗತ್ಯವೂ ಇತ್ತು. ಅದಕ್ಕೂ ಮೊದಲು, ಮೊಬೈಲ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ತಲುಪಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಜಾರಿಗೊಳಿಸುವ ಯೋಜನೆಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.

ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ: ಬ್ರೌಸರ್‌ನಿಂದ ನಿರ್ವಾಹಕರು ನಿರ್ವಾಹಕ ಫಲಕದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ, ನಿರ್ವಾಹಕ ಫಲಕವು ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ, ಕಾರ್ಯವು ಪುಶ್ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸುವುದು.

NodeJS ನಲ್ಲಿ ಅಳವಡಿಸಲಾದ ಮತ್ತೊಂದು ಘಟಕದೊಂದಿಗೆ ಪುಶ್ ಅಧಿಸೂಚನೆಗಳು ಸಂವಹನ ನಡೆಸುತ್ತವೆ.

ಸರತಿ ಸಾಲುಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ನಂತರ ಅವುಗಳ ಕಾರ್ಯವಿಧಾನದ ಪ್ರಕಾರ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಎರಡು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಇಲ್ಲಿ ಚಿತ್ರಿಸಲಾಗಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಡಾಕರ್ ಸಹಾಯದಿಂದ, ನಾವು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಸಂಬಂಧಿಸದ 2 ಸ್ವತಂತ್ರ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅವರು ಸಾಮಾನ್ಯ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಭೌತಿಕ ಡೇಟಾವನ್ನು ಡೆವಲಪರ್ ಯಂತ್ರದಲ್ಲಿ ವಿವಿಧ ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.

ಅದೇ ಆದರೆ ಸಂಖ್ಯೆಯಲ್ಲಿ. ಇಲ್ಲಿ ಕೋಡ್ ಮರುಬಳಕೆ ಮುಖ್ಯವಾಗಿದೆ.

ಲೈಬ್ರರಿಗಳ ರೂಪದಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಬಗ್ಗೆ ನಾವು ಮೊದಲೇ ಮಾತನಾಡಿದರೆ, ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಪುಶ್ ಅಧಿಸೂಚನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ನಮ್ಮ ಸೇವೆಯನ್ನು ಸಂಪೂರ್ಣ ಸರ್ವರ್ ಆಗಿ ಮರುಬಳಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮತ್ತು ನಮ್ಮ ಹೊಸ ಅಭಿವೃದ್ಧಿ ಈಗಾಗಲೇ ಅದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಿದೆ.

ಆ ಸಮಯದಲ್ಲಿ, ನಾವು NodeJS ನ ಆವೃತ್ತಿ 4 ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೆವು. ಈಗ (2017 ರಲ್ಲಿ - ಆವೃತ್ತಿ ಟಿಪ್ಪಣಿ) ಇತ್ತೀಚಿನ ಬೆಳವಣಿಗೆಗಳಲ್ಲಿ ನಾವು NodeJS ನ ಆವೃತ್ತಿ 7 ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಲೈಬ್ರರಿಗಳ ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಹೊಸ ಘಟಕಗಳಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆ ಇಲ್ಲ.

ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ಪುಶ್ ಅಧಿಸೂಚನೆ ಸೇವೆಯಿಂದ NodeJS ಆವೃತ್ತಿಯನ್ನು ಮರುಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚಿಸಬಹುದು.

ಮತ್ತು ನಾವು API ಹೊಂದಾಣಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಬಹುದಾದರೆ, ಅದನ್ನು ಹಿಂದೆ ಬಳಸಿದ ಇತರ ಯೋಜನೆಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಡಾಕರ್ ಅನ್ನು ಸೇರಿಸಲು ನೀವು ಏನು ಬೇಕು? ನಾವು ನಮ್ಮ ರೆಪೊಸಿಟರಿಗೆ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಇದು ಅಗತ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಘಟಕಗಳನ್ನು ತಾರ್ಕಿಕವಾಗಿ ವಿಭಜಿಸಲಾಗಿದೆ. ಇದು ಬ್ಯಾಕೆಂಡ್ ಡೆವಲಪರ್‌ನ ಕನಿಷ್ಠ ಸೆಟ್ ಆಗಿದೆ.

ಹೊಸ ಯೋಜನೆಯನ್ನು ರಚಿಸುವಾಗ, ನಾವು ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ, ಬಯಸಿದ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವರಿಸುತ್ತೇವೆ (ಪೈಥಾನ್, ರೂಬಿ, ನೋಡ್‌ಜೆಎಸ್). ಡಾಕರ್-ಕಂಪೋಸ್ನಲ್ಲಿ, ಇದು ಅಗತ್ಯ ಅವಲಂಬನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ - ಡೇಟಾಬೇಸ್. ನಮಗೆ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಆವೃತ್ತಿಯ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ವಿವರಿಸುತ್ತೇವೆ, ಅಲ್ಲಿ ಮತ್ತು ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ.

ಸ್ಥಿರವಾಗಿ ಸೇವೆ ಸಲ್ಲಿಸಲು ನಾವು nginx ನೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಮೂರನೇ ಕಂಟೇನರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಚಿತ್ರಗಳನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ. ಬ್ಯಾಕೆಂಡ್ ಅವುಗಳನ್ನು ಪೂರ್ವ-ತಯಾರಾದ ಪರಿಮಾಣದಲ್ಲಿ ಇರಿಸುತ್ತದೆ, ಇದು nginx ನೊಂದಿಗೆ ಕಂಟೇನರ್ನಲ್ಲಿ ಸಹ ಜೋಡಿಸಲ್ಪಡುತ್ತದೆ, ಇದು ಸ್ಥಿರತೆಯನ್ನು ನೀಡುತ್ತದೆ.

nginx, mysql ಸಂರಚನೆಯನ್ನು ಸಂಗ್ರಹಿಸಲು, ನಾವು ಅಗತ್ಯ ಸಂರಚನೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಡಾಕರ್ ಫೋಲ್ಡರ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಡೆವಲಪರ್ ತನ್ನ ಗಣಕದಲ್ಲಿ ರೆಪೊಸಿಟರಿಯ ಜಿಟ್ ಕ್ಲೋನ್ ಮಾಡಿದಾಗ, ಅವನು ಈಗಾಗಲೇ ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಗೆ ಸಿದ್ಧವಾಗಿರುವ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದಾನೆ. ಯಾವ ಪೋರ್ಟ್ ಅಥವಾ ಯಾವ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಯೇ ಇಲ್ಲ.

ಮುಂದೆ, ನಾವು ಹಲವಾರು ಘಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: ನಿರ್ವಾಹಕ, ಮಾಹಿತಿ-API, ಪುಶ್ ಅಧಿಸೂಚನೆಗಳು.

ಇದೆಲ್ಲವನ್ನೂ ಪ್ರಾರಂಭಿಸಲು, ನಾವು ಮತ್ತೊಂದು ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಡಾಕರ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ. ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಪ್ರತಿ ಘಟಕದ ಮೊದಲು ಹಲವಾರು ರೆಪೊಸಿಟರಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಅವು ಕೇವಲ ತಾರ್ಕಿಕವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ - GitLab ನಲ್ಲಿ ಇದು ಫೋಲ್ಡರ್‌ನಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಡೆವಲಪರ್‌ನ ಯಂತ್ರದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಗಾಗಿ ಫೋಲ್ಡರ್. ಒಂದು ಹಂತದ ಕೆಳಗೆ ಸಂಯೋಜಿಸಲ್ಪಡುವ ಘಟಕಗಳಾಗಿವೆ.

ಇದು ಡಾಕರ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿಷಯಗಳ ಉದಾಹರಣೆಯಾಗಿದೆ. ನಾವು ಡಾಕರ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ಸಹ ಇಲ್ಲಿಗೆ ತರುತ್ತೇವೆ, ಇದರಲ್ಲಿ ಎಲ್ಲಾ ಘಟಕಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ನಾವು ಭರ್ತಿ ಮಾಡುತ್ತೇವೆ. ಯೋಜನೆಯನ್ನು ಹೇಗೆ ಚಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುವ README.md ಇದೆ.

ಇಲ್ಲಿ ನಾವು ಎರಡು ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್‌ಗಳನ್ನು ಅನ್ವಯಿಸಿದ್ದೇವೆ. ಹಂತಗಳಲ್ಲಿ ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಡೆವಲಪರ್ ಕೋರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಅವನಿಗೆ ಪುಶ್ ಅಧಿಸೂಚನೆಗಳ ಅಗತ್ಯವಿಲ್ಲ, ಅವನು ಸರಳವಾಗಿ ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಸಂಪನ್ಮೂಲವನ್ನು ಉಳಿಸಲಾಗುತ್ತದೆ.

ಪುಶ್ ಅಧಿಸೂಚನೆಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದ್ದರೆ, ಡಾಕರ್-ಕಂಪೋಸ್.ಯಾಮ್ಲ್ ಮತ್ತು ಡಾಕರ್-ಕಂಪೋಸ್-ಪುಶ್.ಯಾಮ್ಲ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

docker-compose.yaml ಮತ್ತು docker-compose-push.yaml ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ, ಒಂದೇ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲ್ಪಡುತ್ತದೆ.

ಘಟಕಗಳ ವಿವರಣೆ. ಇದು ಹೆಚ್ಚು ಸುಧಾರಿತ ಫೈಲ್ ಆಗಿದ್ದು ಅದು ಘಟಕಗಳ ಸಂಗ್ರಹಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಇಲ್ಲಿ ಗಮನಾರ್ಹವಾದುದು ಏನು? ಇಲ್ಲಿ ನಾವು ಬ್ಯಾಲೆನ್ಸರ್ ಘಟಕವನ್ನು ಪರಿಚಯಿಸುತ್ತೇವೆ.

ಇದು nginx ಅನ್ನು ರನ್ ಮಾಡುವ ರೆಡಿಮೇಡ್ ಡಾಕರ್ ಚಿತ್ರವಾಗಿದೆ ಮತ್ತು ಡಾಕರ್ ಸಾಕೆಟ್‌ನಲ್ಲಿ ಆಲಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ. ಡೈನಾಮಿಕ್, ಕಂಟೇನರ್‌ಗಳನ್ನು ಆನ್ ಮತ್ತು ಆಫ್ ಮಾಡಿರುವುದರಿಂದ, ಇದು nginx ಕಾನ್ಫಿಗರ್ ಅನ್ನು ಪುನರುತ್ಪಾದಿಸುತ್ತದೆ. ನಾವು ಮೂರನೇ ಹಂತದ ಡೊಮೇನ್ ಹೆಸರುಗಳ ಮೂಲಕ ಘಟಕಗಳ ನಿರ್ವಹಣೆಯನ್ನು ವಿತರಿಸುತ್ತೇವೆ.

ಅಭಿವೃದ್ಧಿ ಪರಿಸರಕ್ಕಾಗಿ, ನಾವು .dev ಡೊಮೇನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ - api.informer.dev. ಡೆವಲಪರ್‌ನ ಸ್ಥಳೀಯ ಗಣಕದಲ್ಲಿ .dev ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಲಭ್ಯವಿವೆ.

ಇದಲ್ಲದೆ, ಪ್ರತಿ ಯೋಜನೆಗೆ ಸಂರಚನೆಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಯೋಜನೆಗಳನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಟ್ಟಿಗೆ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ಸಚಿತ್ರವಾಗಿ, ಕ್ಲೈಂಟ್ ನಮ್ಮ ಬ್ರೌಸರ್ ಅಥವಾ ನಾವು ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುವ ಕೆಲವು ಸಾಧನವಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

ಡೊಮೇನ್ ನೇಮ್ ಬ್ಯಾಲೆನ್ಸರ್ ಯಾವ ಕಂಟೇನರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಇದು nginx ಆಗಿರಬಹುದು, ಇದು ನಿರ್ವಾಹಕ JS ಅನ್ನು ನೀಡುತ್ತದೆ. ಇದು nginx ಆಗಿರಬಹುದು, ಇದು API ಅನ್ನು ನೀಡುತ್ತದೆ ಅಥವಾ ಚಿತ್ರ ಅಪ್‌ಲೋಡ್‌ಗಳ ರೂಪದಲ್ಲಿ nginx ಗೆ ನೀಡಲಾದ ಸ್ಥಿರ ಫೈಲ್‌ಗಳು.

ಕಂಟೇನರ್‌ಗಳನ್ನು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಹಿಂದೆ ಮರೆಮಾಡಲಾಗಿದೆ ಎಂದು ರೇಖಾಚಿತ್ರವು ತೋರಿಸುತ್ತದೆ.

ಡೆವಲಪರ್ ಯಂತ್ರದಲ್ಲಿ, ನೀವು IP ಅನ್ನು ತಿಳಿದುಕೊಳ್ಳುವ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಬಹುದು, ಆದರೆ ತಾತ್ವಿಕವಾಗಿ ನಾವು ಇದನ್ನು ಬಳಸುವುದಿಲ್ಲ. ನೇರ ಪ್ರವೇಶಕ್ಕೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಡಾಕರೈಸ್ ಮಾಡಲು ಯಾವ ಉದಾಹರಣೆಯನ್ನು ನೋಡಬೇಕು? ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, MySQL ಗಾಗಿ ಅಧಿಕೃತ ಡಾಕರ್ ಚಿತ್ರವು ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ.

ಇದು ಸಾಕಷ್ಟು ಸವಾಲಾಗಿದೆ. ಹಲವು ಆವೃತ್ತಿಗಳಿವೆ. ಆದರೆ ಅದರ ಕಾರ್ಯವು ಮುಂದಿನ ಅಭಿವೃದ್ಧಿಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಉದ್ಭವಿಸಬಹುದಾದ ಅನೇಕ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಸಮಯವನ್ನು ಕಳೆದರೆ ಮತ್ತು ಅದು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದರೆ, ಸ್ವಯಂ-ಅನುಷ್ಠಾನದಲ್ಲಿ ನಿಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

Hub.docker.com ಸಾಮಾನ್ಯವಾಗಿ github.com ಗೆ ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಇದು ನೇರವಾಗಿ ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದರಿಂದ ನೀವೇ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಬಹುದು.

ಈ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಡಾಕರ್-ಎಂಡ್‌ಪಾಯಿಂಟ್.ಎಸ್ ಸ್ಕ್ರಿಪ್ಟ್ ಇದೆ, ಇದು ಆರಂಭಿಕ ಪ್ರಾರಂಭಕ್ಕೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಲಾಂಚ್‌ನ ಹೆಚ್ಚಿನ ಪ್ರಕ್ರಿಯೆಗೆ ಕಾರಣವಾಗಿದೆ.

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂರಚಿಸುವ ಸಾಮರ್ಥ್ಯವಿದೆ. ಒಂದೇ ಕಂಟೇನರ್ ಅನ್ನು ಚಲಾಯಿಸುವಾಗ ಅಥವಾ ಡಾಕರ್-ಕಂಪೋಸ್ ಮೂಲಕ ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೂಲಕ, ಡಾಕರ್‌ಗೆ MySQL ಅಥವಾ ನಮಗೆ ಬೇಕಾದುದನ್ನು ರೂಟ್ ಮಾಡಲು ನಾವು ಖಾಲಿ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ ಎಂದು ಹೇಳಬಹುದು.

ಯಾದೃಚ್ಛಿಕ ಪಾಸ್ವರ್ಡ್ ರಚಿಸಲು ಒಂದು ಆಯ್ಕೆ ಇದೆ. ನಮಗೆ ಬಳಕೆದಾರರ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ, ನಾವು ಬಳಕೆದಾರರಿಗೆ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ.

ನಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ, ನಾವು ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಏಕೀಕರಿಸಿದ್ದೇವೆ, ಇದು ಪ್ರಾರಂಭಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳ ವಿಸ್ತರಣೆಯನ್ನು ಮಾಡಲು ನಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ. ಇದು ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಕನ್ಸೋಲ್‌ನಿಂದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸರಳವಾಗಿ ರಚಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ರೂಬಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ರಚಿಸಲು, ಮಾರ್ಪಡಿಸಲು ಮತ್ತು ಅಳಿಸಲು ಆಜ್ಞೆಯನ್ನು ಹೊಂದಿವೆ.

Github.com ನಲ್ಲಿ MySQL ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಇದು ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ನೀವು ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ತೆರೆಯಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ಅನುಸ್ಥಾಪನೆಯು ಹೇಗೆ ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು.

docker-endpoint.sh ಪ್ರವೇಶ ಬಿಂದುವಿಗೆ ಜವಾಬ್ದಾರಿಯುತ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ. ಆರಂಭಿಕ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ, ಕೆಲವು ಪೂರ್ವಸಿದ್ಧತಾ ಹಂತಗಳ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಈ ಎಲ್ಲಾ ಕ್ರಿಯೆಗಳನ್ನು ಕೇವಲ ಇನಿಶಿಯಲೈಸೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.

ಎರಡನೇ ಭಾಗಕ್ಕೆ ಹೋಗೋಣ.

ಮೂಲ ಕೋಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ನಾವು ಗಿಟ್‌ಲ್ಯಾಬ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಇದು ದೃಶ್ಯ ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.

Gitlab ನ ಘಟಕಗಳಲ್ಲಿ ಒಂದು Gitlab CI ಆಗಿದೆ. ಕೋಡ್ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಂಘಟಿಸಲು ಅಥವಾ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸಲು ನಂತರ ಬಳಸಲಾಗುವ ಆದೇಶಗಳ ಅನುಕ್ರಮವನ್ನು ವಿವರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

Gitlab CI 2 ಚರ್ಚೆ https://goo.gl/uohKjI - ರೂಬಿ ರಷ್ಯಾ ಕ್ಲಬ್‌ನಿಂದ ವರದಿ - ಸಾಕಷ್ಟು ವಿವರವಾದ ಮತ್ತು ಬಹುಶಃ ಇದು ನಿಮಗೆ ಆಸಕ್ತಿಯನ್ನುಂಟು ಮಾಡುತ್ತದೆ.

ಈಗ ನಾವು Gitlab CI ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಏನು ಬೇಕು ಎಂದು ನೋಡೋಣ. Gitlab CI ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು, ನಾವು ಯೋಜನೆಯ ಮೂಲದಲ್ಲಿ .gitlab-ci.yml ಫೈಲ್ ಅನ್ನು ಹಾಕಬೇಕಾಗಿದೆ.

ಪರೀಕ್ಷೆ, ನಿಯೋಜನೆಯಂತಹ ರಾಜ್ಯಗಳ ಅನುಕ್ರಮವನ್ನು ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ಇಲ್ಲಿ ನಾವು ವಿವರಿಸುತ್ತೇವೆ.

ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಡಾಕರ್-ಕಂಪೋಸ್ ಅನ್ನು ನೇರವಾಗಿ ಕರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ಇದು ಕೇವಲ ಬ್ಯಾಕೆಂಡ್ ಉದಾಹರಣೆಯಾಗಿದೆ.

ಮುಂದೆ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಲು ವಲಸೆಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಅವಶ್ಯಕ ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ.

ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ ಮತ್ತು ದೋಷ ಕೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸದಿದ್ದರೆ, ನಂತರ ಸಿಸ್ಟಮ್ ನಿಯೋಜನೆಯ ಎರಡನೇ ಹಂತಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತದೆ.

ನಿಯೋಜನೆ ಹಂತವನ್ನು ಪ್ರಸ್ತುತ ವೇದಿಕೆಗಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ. ನಾವು ಶೂನ್ಯ ಡೌನ್‌ಟೈಮ್ ಮರುಪ್ರಾರಂಭವನ್ನು ಆಯೋಜಿಸಿಲ್ಲ.

ನಾವು ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳನ್ನು ಬಲವಂತವಾಗಿ ನಂದಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ನಾವು ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳನ್ನು ಮತ್ತೆ ಹೆಚ್ಚಿಸುತ್ತೇವೆ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಮೊದಲ ಹಂತದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ.

ಡೆವಲಪರ್‌ಗಳು ಬರೆದ ಡೇಟಾಬೇಸ್ ವಲಸೆಗಳ ಪ್ರಸ್ತುತ ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ಗಾಗಿ ನಾವು ಓಡುತ್ತಿದ್ದೇವೆ.

ಇದು ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬ ಟಿಪ್ಪಣಿ ಇದೆ.

ಇತರ ಶಾಖೆಗಳನ್ನು ಬದಲಾಯಿಸುವಾಗ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.

ಶಾಖೆಗಳ ಮೂಲಕ ರೋಲ್ಔಟ್ಗಳನ್ನು ಆಯೋಜಿಸಲು ಸಾಧ್ಯವಿದೆ.

ಇದನ್ನು ಮತ್ತಷ್ಟು ಸಂಘಟಿಸಲು, ನಾವು Gitlab ರನ್ನರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ.

ಈ ಉಪಯುಕ್ತತೆಯನ್ನು ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಗೋಲಾಂಗ್ ಜಗತ್ತಿನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿರುವಂತೆ ಇದು ಒಂದೇ ಫೈಲ್ ಆಗಿದೆ, ಇದಕ್ಕೆ ಯಾವುದೇ ಅವಲಂಬನೆಗಳ ಅಗತ್ಯವಿಲ್ಲ.

ಪ್ರಾರಂಭದಲ್ಲಿ, ನಾವು Gitlab ರನ್ನರ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತೇವೆ.

ನಾವು Gitlab ವೆಬ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ನಂತರ ನಾವು ಆಜ್ಞಾ ಸಾಲಿನಲ್ಲಿ ಆರಂಭಿಸುವ ಆಜ್ಞೆಯನ್ನು ಕರೆಯುತ್ತೇವೆ.

ಗಿಟ್‌ಲ್ಯಾಬ್ ರನ್ನರ್ ಅನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗಿ ಹೊಂದಿಸಿ (ಶೆಲ್, ಡಾಕರ್, ವರ್ಚುವಲ್‌ಬಾಕ್ಸ್, ಎಸ್‌ಎಸ್‌ಹೆಚ್)

Gitlab ರನ್ನರ್‌ನಲ್ಲಿರುವ ಕೋಡ್ .gitlab-ci.yml ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರತಿ ಕಮಿಟ್‌ನಲ್ಲಿಯೂ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ.

ವೆಬ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಗಿಟ್‌ಲ್ಯಾಬ್‌ನಲ್ಲಿ ಅದು ಹೇಗೆ ದೃಷ್ಟಿಗೋಚರವಾಗಿ ಕಾಣುತ್ತದೆ. ನಾವು GITlab CI ಅನ್ನು ಸಂಪರ್ಕಿಸಿದ ನಂತರ, ನಾವು ಈ ಕ್ಷಣದಲ್ಲಿ ನಿರ್ಮಾಣದ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುವ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

4 ನಿಮಿಷಗಳ ಹಿಂದೆ ಬದ್ಧತೆಯನ್ನು ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ, ಅದು ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣರಾದರು ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಲಿಲ್ಲ.

ನಾವು ನಿರ್ಮಾಣಗಳನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡಬಹುದು. ಇಲ್ಲಿ ನಾವು ಎರಡು ರಾಜ್ಯಗಳು ಈಗಾಗಲೇ ಹಾದುಹೋಗಿರುವುದನ್ನು ನೋಡುತ್ತೇವೆ. ವೇದಿಕೆಯಲ್ಲಿ ಸ್ಥಿತಿ ಮತ್ತು ನಿಯೋಜನೆ ಸ್ಥಿತಿಯನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ.

ನಾವು ನಿರ್ದಿಷ್ಟ ನಿರ್ಮಾಣದ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದರೆ, ನಂತರ .gitlab-ci.yml ಪ್ರಕಾರ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ರನ್ ಮಾಡಿದ ಆಜ್ಞೆಗಳ ಕನ್ಸೋಲ್ ಔಟ್‌ಪುಟ್ ಇರುತ್ತದೆ.

ನಮ್ಮ ಉತ್ಪನ್ನ ಇತಿಹಾಸವು ಹೀಗಿದೆ. ಯಶಸ್ವಿ ಪ್ರಯತ್ನಗಳು ನಡೆದಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಪರೀಕ್ಷೆಗಳನ್ನು ಸಲ್ಲಿಸಿದಾಗ, ಅದು ಮುಂದಿನ ಹಂತಕ್ಕೆ ಮುಂದುವರಿಯುವುದಿಲ್ಲ ಮತ್ತು ಸ್ಟೇಜಿಂಗ್ ಕೋಡ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ.

ನಾವು ಡಾಕರ್ ಅನ್ನು ಅಳವಡಿಸಿದಾಗ ವೇದಿಕೆಯಲ್ಲಿ ನಾವು ಯಾವ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ? ನಮ್ಮ ಸಿಸ್ಟಂ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಮತ್ತು ನಾವು ಮರುಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ನವೀಕರಿಸಿದ ಘಟಕಗಳ ಭಾಗ ಮಾತ್ರ, ಮತ್ತು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಅಲ್ಲ.

ಇದನ್ನು ಮಾಡಲು, ನಾವು ಎಲ್ಲವನ್ನೂ ಪ್ರತ್ಯೇಕ ಫೋಲ್ಡರ್ಗಳಾಗಿ ಸ್ಮ್ಯಾಶ್ ಮಾಡಬೇಕಾಗಿತ್ತು.

ನಾವು ಇದನ್ನು ಮಾಡಿದ ನಂತರ, ಡಾಕರ್-ಕಂಪೋಸ್ ಪ್ರತಿ ಡ್ಯಾಡಿಗೆ ತನ್ನದೇ ಆದ ನೆಟ್‌ವರ್ಕ್ ಜಾಗವನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ನೆರೆಹೊರೆಯವರ ಘಟಕಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ನಮಗೆ ಸಮಸ್ಯೆ ಎದುರಾಗಿದೆ.

ಸುತ್ತಾಡಲು, ನಾವು ಡಾಕರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ರಚಿಸಿದ್ದೇವೆ. ಈ ಯೋಜನೆಗಾಗಿ ನೀವು ಅಂತಹ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸುತ್ತೀರಿ ಎಂದು ಡಾಕರ್-ಕಂಪೋಸ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ.

ಹೀಗಾಗಿ, ಈ ಜಾಲರಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುವ ಪ್ರತಿಯೊಂದು ಘಟಕವು ವ್ಯವಸ್ಥೆಯ ಇತರ ಭಾಗಗಳಲ್ಲಿನ ಘಟಕಗಳನ್ನು ನೋಡುತ್ತದೆ.

ಮುಂದಿನ ಸಂಚಿಕೆಯು ಬಹು ಯೋಜನೆಗಳಲ್ಲಿ ಹಂತವನ್ನು ವಿಭಜಿಸುವುದು.

ಇದೆಲ್ಲವೂ ಸುಂದರವಾಗಿ ಕಾಣಲು ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಾಗಲು, ಪೋರ್ಟ್ 80 ಅಥವಾ 443 ಅನ್ನು ಬಳಸುವುದು ಒಳ್ಳೆಯದು, ಇದನ್ನು ವೆಬ್‌ನಲ್ಲಿ ಎಲ್ಲೆಡೆ ಬಳಸಲಾಗುತ್ತದೆ.

ನಾವು ಅದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಿದ್ದೇವೆ? ನಾವು ಎಲ್ಲಾ ಪ್ರಮುಖ ಯೋಜನೆಗಳಿಗೆ ಒಬ್ಬ ಗಿಟ್ಲಾಬ್ ರನ್ನರ್ ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ.

Gitlab ನಿಮಗೆ ಹಲವಾರು ವಿತರಿಸಿದ Gitlab ರನ್ನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಇದು ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಅಸ್ತವ್ಯಸ್ತವಾಗಿರುವ ರೀತಿಯಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ನಮಗೆ ಮನೆ ಇಲ್ಲ, ನಾವು ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಗುಂಪನ್ನು ಒಂದು ಗಿಟ್ಲಾಬ್ ರನ್ನರ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿದ್ದೇವೆ, ಅದು ನಮ್ಮ ಸಂಪುಟಗಳೊಂದಿಗೆ ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ನಿಭಾಯಿಸುತ್ತದೆ.

ನಾವು nginx-proxy ಅನ್ನು ಪ್ರತ್ಯೇಕ ಆರಂಭಿಕ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಸರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದರಲ್ಲಿರುವ ಎಲ್ಲಾ ಯೋಜನೆಗಳಿಗೆ ಗ್ರಿಡ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.

ನಮ್ಮ ಯೋಜನೆಯು ಒಂದು ಗ್ರಿಡ್ ಅನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಬ್ಯಾಲೆನ್ಸರ್ ಯೋಜನೆಯ ಹೆಸರುಗಳ ಮೂಲಕ ಹಲವಾರು ಗ್ರಿಡ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು ಡೊಮೇನ್ ಹೆಸರುಗಳ ಮೂಲಕ ಮತ್ತಷ್ಟು ಪ್ರಾಕ್ಸಿ ಮಾಡಬಹುದು.

ನಮ್ಮ ವಿನಂತಿಗಳು ಪೋರ್ಟ್ 80 ನಲ್ಲಿನ ಡೊಮೇನ್ ಮೂಲಕ ಬರುತ್ತವೆ ಮತ್ತು ಈ ಡೊಮೇನ್‌ಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಕಂಟೇನರ್ ಗುಂಪಿನಲ್ಲಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.

ಬೇರೆ ಯಾವ ಸಮಸ್ಯೆಗಳಿದ್ದವು? ಡೀಫಾಲ್ಟ್ ಆಗಿ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳು ರೂಟ್ ಆಗಿ ರನ್ ಆಗುವುದು ಇದನ್ನೇ. ಇದು ವ್ಯವಸ್ಥೆಯ ಮೂಲ ಹೋಸ್ಟ್‌ಗೆ ಅಸಮಾನವಾಗಿದೆ.

ಆದಾಗ್ಯೂ, ನೀವು ಕಂಟೇನರ್ ಅನ್ನು ನಮೂದಿಸಿದರೆ, ಅದು ರೂಟ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಈ ಕಂಟೇನರ್‌ನಲ್ಲಿ ನಾವು ರಚಿಸುವ ಫೈಲ್ ರೂಟ್ ಹಕ್ಕುಗಳನ್ನು ಪಡೆಯುತ್ತದೆ.

ಡೆವಲಪರ್ ಕಂಟೇನರ್ ಅನ್ನು ನಮೂದಿಸಿದರೆ ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಕೆಲವು ಆಜ್ಞೆಗಳನ್ನು ಅಲ್ಲಿ ಮಾಡಿದರೆ, ನಂತರ ಧಾರಕವನ್ನು ಬಿಟ್ಟರೆ, ನಂತರ ಅವನು ತನ್ನ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅವನು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿಲ್ಲದ ಫೈಲ್ ಅನ್ನು ಹೊಂದಿದ್ದಾನೆ.

ಅದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬಹುದು? ಕಂಟೇನರ್‌ನಲ್ಲಿರುವ ಬಳಕೆದಾರರನ್ನು ನೀವು ಸೇರಿಸಬಹುದು.

ನಾವು ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸಿದಾಗ ಯಾವ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದವು?

ಬಳಕೆದಾರರನ್ನು ರಚಿಸುವಾಗ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಗುಂಪು ID (UID) ಮತ್ತು ಬಳಕೆದಾರ ID (GID) ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ.

ಕಂಟೇನರ್‌ನಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ID 1000 ಹೊಂದಿರುವ ಬಳಕೆದಾರರನ್ನು ಬಳಸುತ್ತೇವೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಬಹುತೇಕ ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳು ಉಬುಂಟು ಓಎಸ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬ ಅಂಶದೊಂದಿಗೆ ಇದು ಹೊಂದಿಕೆಯಾಯಿತು. ಮತ್ತು ಉಬುಂಟುನಲ್ಲಿ, ಮೊದಲ ಬಳಕೆದಾರರು 1000 ರ ಐಡಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ.

ನಮ್ಮಲ್ಲಿ ಯೋಜನೆಗಳಿವೆಯೇ?

ಡಾಕರ್ ದಸ್ತಾವೇಜನ್ನು ಓದಿ. ಯೋಜನೆಯು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ, ದಸ್ತಾವೇಜನ್ನು ಬದಲಾಗುತ್ತಿದೆ. ಎರಡು ಅಥವಾ ಮೂರು ತಿಂಗಳ ಹಿಂದೆ ಸ್ವೀಕರಿಸಿದ ಡೇಟಾ ಈಗಾಗಲೇ ನಿಧಾನವಾಗಿ ಹಳೆಯದು.

ನಾವು ಪರಿಹರಿಸಿದ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಈಗಾಗಲೇ ಪ್ರಮಾಣಿತ ವಿಧಾನಗಳಿಂದ ಪರಿಹರಿಸಲಾಗಿದೆ.

ಹಾಗಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಷನ್ಗೆ ನೇರವಾಗಿ ಹೋಗಲು ನಾನು ಈಗಾಗಲೇ ಮುಂದೆ ಹೋಗಲು ಬಯಸುತ್ತೇನೆ.

ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಡಾಕರ್‌ನ ಅಂತರ್ನಿರ್ಮಿತ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯು ಡಾಕರ್ ಸ್ವಾರ್ಮ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ, ಇದು ಪೆಟ್ಟಿಗೆಯಿಂದ ಹೊರಬರುತ್ತದೆ. ನಾನು ಡಾಕರ್ ಸ್ವಾರ್ಮ್ ತಂತ್ರಜ್ಞಾನದ ಆಧಾರದ ಮೇಲೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಚಲಾಯಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಮೊಟ್ಟೆಯಿಡುವ ಕಂಟೇನರ್‌ಗಳು ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅನಾನುಕೂಲವಾಗಿಸುತ್ತದೆ. ಈಗ ದಾಖಲೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ. ಅವು ಧಾರಕಗಳಲ್ಲಿ ಹರಡಿಕೊಂಡಿವೆ. ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಲಾಗ್‌ಗಳಿಗೆ ಅನುಕೂಲಕರ ಪ್ರವೇಶವನ್ನು ಮಾಡುವುದು ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ಮೂಲ: www.habr.com