ಮೊನೊರೆಪೊಸಿಟರಿಯ ವಿಷಯವನ್ನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಚರ್ಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಯಮದಂತೆ, ಅತ್ಯಂತ ಸಕ್ರಿಯ ಚರ್ಚೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ರಚಿಸಲಾಗುತ್ತಿದೆ Git ನಿಂದ ಡಾಕರ್ ಚಿತ್ರಗಳಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಧಾರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಓಪನ್ ಸೋರ್ಸ್ ಸಾಧನವಾಗಿ (ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ತಲುಪಿಸುವುದು), ಯಾವ ಆಯ್ಕೆಯು ಉತ್ತಮವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಹೆಚ್ಚು ಯೋಚಿಸುವುದಿಲ್ಲ. ನಮಗೆ, ವಿಭಿನ್ನ ಅಭಿಪ್ರಾಯಗಳ ಬೆಂಬಲಿಗರಿಗೆ ಅಗತ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಒದಗಿಸುವುದು ಪ್ರಾಥಮಿಕವಾಗಿದೆ (ಇದು ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ ವಿರೋಧಿಸದಿದ್ದರೆ, ಸಹಜವಾಗಿ).
werf ನಲ್ಲಿ ಮೊನೊ-ರೆಪೋಗೆ ಇತ್ತೀಚೆಗೆ ಪರಿಚಯಿಸಲಾದ ಬೆಂಬಲವು ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿದೆ. ಆದರೆ ಮೊದಲು, ಈ ಬೆಂಬಲವು ಸಾಮಾನ್ಯವಾಗಿ ವರ್ಫ್ ಬಳಕೆಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸಿದೆ ಮತ್ತು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯು ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ...
ಸಮಸ್ಯೆಗಳು
ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಊಹಿಸೋಣ. ಕಂಪನಿಯು ಸ್ವತಂತ್ರ ಯೋಜನೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಅನೇಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳನ್ನು ಹೊಂದಿದೆ. ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಕಂಟೈನರೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಧಾರಕಗಳು ಮತ್ತು ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ನೋಂದಾವಣೆ ಅಗತ್ಯವಿದೆ. ಕಂಪನಿಯು ಒಂದೇ ಖಾತೆಯೊಂದಿಗೆ ಡಾಕರ್ ಹಬ್ ಅನ್ನು ಅಂತಹ ನೋಂದಾವಣೆಯಾಗಿ ಬಳಸುತ್ತದೆ. COMPANY. ಹೆಚ್ಚಿನ ಮೂಲ ಕೋಡ್ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳಂತೆಯೇ, ರೆಪೊಸಿಟರಿಗಳ ನೆಸ್ಟೆಡ್ ಶ್ರೇಣಿಯನ್ನು ರಚಿಸಲು ಡಾಕರ್ ಹಬ್ ನಿಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ COMPANY/PROJECT/IMAGE. ಈ ಸಂದರ್ಭದಲ್ಲಿ... ಪ್ರತಿ ಯೋಜನೆಗೆ ಪ್ರತ್ಯೇಕ ಖಾತೆಯನ್ನು ರಚಿಸದೆಯೇ ನಾವು ಈ ಮಿತಿಯೊಂದಿಗೆ ನೋಂದಾವಣೆಯಲ್ಲಿ ಏಕಶಿಲೆಯಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಬಹುದು?
ಬಹುಶಃ ವಿವರಿಸಿದ ಪರಿಸ್ಥಿತಿಯು ಯಾರಿಗಾದರೂ ಮೊದಲ-ಕೈಯಿಂದ ಪರಿಚಿತವಾಗಿದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಆಯೋಜಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ನೋಡೋಣ, ಅಂದರೆ. ಮೇಲಿನ ಉದಾಹರಣೆ ಮತ್ತು ಡಾಕರ್ ಹಬ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸದೆ.
ಪರಿಹಾರಗಳು
ಅಪ್ಲಿಕೇಶನ್ ವೇಳೆ ಏಕಶಿಲೆಯಾಗಿ, ಒಂದು ಚಿತ್ರದಲ್ಲಿ ಬರುತ್ತದೆ, ನಂತರ ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಾವು ಪ್ರಾಜೆಕ್ಟ್‌ನ ಕಂಟೈನರ್ ನೋಂದಾವಣೆಯಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಉಳಿಸುತ್ತೇವೆ.
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಹು ಘಟಕಗಳಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಿದಾಗ, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು, ನಂತರ ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಧಾನವನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಎರಡು ಚಿತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ವಿಶಿಷ್ಟ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸುವುದು: frontend и backend - ಸಂಭವನೀಯ ಆಯ್ಕೆಗಳು:
- ಪ್ರತ್ಯೇಕ ನೆಸ್ಟೆಡ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ:
- ಎಲ್ಲವನ್ನೂ ಒಂದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ, ಮತ್ತು ಚಿತ್ರದ ಹೆಸರನ್ನು ಟ್ಯಾಗ್‌ನಲ್ಲಿ ಸೇರಿಸಿ, ಉದಾಹರಣೆಗೆ, ಈ ಕೆಳಗಿನಂತೆ:
NB: ವಾಸ್ತವವಾಗಿ, ವಿವಿಧ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಉಳಿಸುವ ಮತ್ತೊಂದು ಆಯ್ಕೆ ಇದೆ, PROJECT-frontend и PROJECT-backend, ಆದರೆ ಬೆಂಬಲ, ಸಂಘಟನೆ ಮತ್ತು ಬಳಕೆದಾರರ ನಡುವಿನ ಹಕ್ಕುಗಳ ವಿತರಣೆಯ ಸಂಕೀರ್ಣತೆಯಿಂದಾಗಿ ನಾವು ಅದನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ.
werf ಬೆಂಬಲ
ಆರಂಭದಲ್ಲಿ, werf ನೆಸ್ಟೆಡ್ ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಸೀಮಿತವಾಗಿತ್ತು - ಅದೃಷ್ಟವಶಾತ್, ಹೆಚ್ಚಿನ ನೋಂದಣಿಗಳು ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ. ಆವೃತ್ತಿಯಿಂದ , ನೋಂದಾವಣೆಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಗೂಡುಕಟ್ಟುವಿಕೆಗೆ ಬೆಂಬಲವಿಲ್ಲ, ಮತ್ತು ಡಾಕರ್ ಹಬ್ ಅವುಗಳಲ್ಲಿ ಒಂದು. ಈ ಕ್ಷಣದಿಂದ, ಅಪ್ಲಿಕೇಶನ್ ಚಿತ್ರಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುವುದು ಎಂಬುದರ ಆಯ್ಕೆಯನ್ನು ಬಳಕೆದಾರರು ಹೊಂದಿದ್ದರು.
ಆಯ್ಕೆಯ ಭಾಗವಾಗಿ ಅನುಷ್ಠಾನ ಲಭ್ಯವಿದೆ --images-repo-mode=multirepo|monorepo (ಡೀಫಾಲ್ಟ್ multirepo, ಅಂದರೆ ನೆಸ್ಟೆಡ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಸಂಗ್ರಹಣೆ). ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಯಾವ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಇದು ವಿವರಿಸುತ್ತದೆ. ಮೂಲಭೂತ ಆಜ್ಞೆಗಳನ್ನು ಬಳಸುವಾಗ ಬಯಸಿದ ಮೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಕು, ಮತ್ತು ಉಳಿದಂತೆ ಬದಲಾಗದೆ ಉಳಿಯುತ್ತದೆ.
ಹೆಚ್ಚಿನ ವೆರ್ಫ್ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿಸಬಹುದಾದ್ದರಿಂದ ಪರಿಸರ ಅಸ್ಥಿರ, CI/CD ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಶೇಖರಣಾ ಮೋಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪೂರ್ಣ ಯೋಜನೆಗಾಗಿ ಜಾಗತಿಕವಾಗಿ ಹೊಂದಿಸಲು ಸುಲಭವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, GitLab ವಿಷಯದಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಸೇರಿಸಿ: ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> CI / CD -> ಅಸ್ಥಿರ: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
ನಾವು ಚಿತ್ರಗಳನ್ನು ಪ್ರಕಟಿಸುವ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊರತರುವ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ (ಈ ಪ್ರಕ್ರಿಯೆಗಳ ಬಗ್ಗೆ ನೀವು ಸಂಬಂಧಿತ ದಸ್ತಾವೇಜನ್ನು ಲೇಖನಗಳಲ್ಲಿ ವಿವರವಾಗಿ ಓದಬಹುದು: и ), ನಂತರ ಮೋಡ್ ನೀವು ಚಿತ್ರದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ.
ದೆವ್ವವು ವಿವರಗಳಲ್ಲಿದೆ
ಹೊಸ ಶೇಖರಣಾ ವಿಧಾನವನ್ನು ಸೇರಿಸುವಾಗ ವ್ಯತ್ಯಾಸ ಮತ್ತು ಮುಖ್ಯ ತೊಂದರೆ ನೋಂದಾವಣೆ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದೆ (Werf ನಲ್ಲಿ ಬೆಂಬಲಿತವಾದ ಶುಚಿಗೊಳಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳು, ನೋಡಿ ).
ಶುಚಿಗೊಳಿಸುವಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾದ ಚಿತ್ರಗಳನ್ನು ಮತ್ತು ಬಳಕೆದಾರ-ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನೀತಿಗಳನ್ನು ವೆರ್ಫ್ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನೀತಿಗಳು ಟ್ಯಾಗ್‌ಗಳನ್ನು ಕಾರ್ಯತಂತ್ರಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೇಲೆ ಆಧಾರಿತವಾಗಿವೆ. ಪ್ರಸ್ತುತ ಬೆಂಬಲಿತ ತಂತ್ರಗಳು:
- ಟ್ಯಾಗ್, ಶಾಖೆ ಮತ್ತು ಬದ್ಧತೆಯಂತಹ Git ಮೂಲಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ 3 ತಂತ್ರಗಳು;
- ಕಸ್ಟಮ್ ಕಸ್ಟಮ್ ಟ್ಯಾಗ್‌ಗಳಿಗಾಗಿ 1 ತಂತ್ರ.
ಅಂತಿಮ ಚಿತ್ರದ ಲೇಬಲ್‌ಗಳಲ್ಲಿ ಚಿತ್ರವನ್ನು ಪ್ರಕಟಿಸುವಾಗ ನಾವು ಟ್ಯಾಗ್ ತಂತ್ರದ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಉಳಿಸುತ್ತೇವೆ. ಅರ್ಥವು ಸ್ವತಃ ಕರೆಯಲ್ಪಡುವದು ಮೆಟಾ ಟ್ಯಾಗ್ - ಕೆಲವು ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸಲು ಅವಶ್ಯಕ. ಉದಾಹರಣೆಗೆ, Git ರೆಪೊಸಿಟರಿಯಿಂದ ಶಾಖೆ ಅಥವಾ ಟ್ಯಾಗ್ ಅನ್ನು ಅಳಿಸುವಾಗ, ಸಂಬಂಧಿತವನ್ನು ಅಳಿಸುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ ಬಳಕೆಯಾಗದ ನಮ್ಮ ನೀತಿಗಳ ಭಾಗವಾಗಿ ಒಳಗೊಂಡಿರುವ ನೋಂದಾವಣೆಯಿಂದ ಚಿತ್ರಗಳು.
ಒಂದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಉಳಿಸುವಾಗ (monorepo), ಇಮೇಜ್ ಟ್ಯಾಗ್‌ನಲ್ಲಿ, ಮೆಟಾ ಟ್ಯಾಗ್ ಜೊತೆಗೆ, ಚಿತ್ರದ ಹೆಸರನ್ನು ಸಹ ಸಂಗ್ರಹಿಸಬಹುದು: PROJECT:frontend-META-TAG. ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ನಾವು ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ವಿಭಜಕವನ್ನು ಪರಿಚಯಿಸಲಿಲ್ಲ, ಆದರೆ ಪ್ರಕಟಿಸುವಾಗ ಅಂತಿಮ ಚಿತ್ರದ ಲೇಬಲ್‌ಗೆ ಅಗತ್ಯವಾದ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.
NB: ನೀವು werf ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ವಿವರಿಸಿರುವ ಎಲ್ಲವನ್ನೂ ನೋಡಲು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನಂತರ ಆರಂಭಿಕ ಹಂತವಾಗಿರಬಹುದು .
ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ನಮ್ಮ ವಿಧಾನದ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಸಮರ್ಥನೆಗೆ ಹೆಚ್ಚಿನ ಗಮನ ನೀಡುವುದಿಲ್ಲ: ಟ್ಯಾಗ್ ಮಾಡುವ ತಂತ್ರಗಳು, ಲೇಬಲ್‌ಗಳಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಕಾಶನ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ - ಇವೆಲ್ಲವನ್ನೂ ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್ ಅವರ ಇತ್ತೀಚಿನ ವರದಿಯಲ್ಲಿ ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ: “».
ಸಾರಾಂಶಿಸು
ಗೂಡುಕಟ್ಟುವ ಇಲ್ಲದೆ ನೋಂದಾವಣೆಗಳಿಗೆ ಬೆಂಬಲದ ಕೊರತೆಯು ನಮಗೆ ಅಥವಾ ನಮಗೆ ತಿಳಿದಿರುವ werf ಬಳಕೆದಾರರಿಗೆ ತಡೆಯುವ ಅಂಶವಾಗಿರಲಿಲ್ಲ - ಎಲ್ಲಾ ನಂತರ, ನೀವು ಯಾವಾಗಲೂ ಚಿತ್ರಗಳ ಪ್ರತ್ಯೇಕ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು (ಅಥವಾ Google ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಷರತ್ತುಬದ್ಧ ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ಬದಲಾಯಿಸಬಹುದು) ... ಆದಾಗ್ಯೂ , ವ್ಯಾಪಕವಾದ DevOps ಸಮುದಾಯಕ್ಕೆ ಉಪಕರಣವನ್ನು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿಸುವ ಸಲುವಾಗಿ ಅಂತಹ ನಿರ್ಬಂಧವನ್ನು ತೆಗೆದುಹಾಕುವುದು ತಾರ್ಕಿಕವೆಂದು ತೋರುತ್ತದೆ. ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಕಂಟೇನರ್ ನೋಂದಾವಣೆ ಶುಚಿಗೊಳಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಪುನರ್ನಿರ್ಮಿಸುವಲ್ಲಿ ನಾವು ಮುಖ್ಯ ತೊಂದರೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ಈಗ ಎಲ್ಲವೂ ಸಿದ್ಧವಾಗಿದೆ, ಇದು ಯಾರಿಗಾದರೂ ಸುಲಭವಾಗಿದೆ ಎಂದು ತಿಳಿಯುವುದು ಸಂತೋಷವಾಗಿದೆ ಮತ್ತು ನಾವು (ಯೋಜನೆಯ ಮುಖ್ಯ ಡೆವಲಪರ್‌ಗಳಾಗಿ) ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಮತ್ತಷ್ಟು ಬೆಂಬಲಿಸುವಲ್ಲಿ ಯಾವುದೇ ಗಮನಾರ್ಹ ತೊಂದರೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ.
ನಮ್ಮೊಂದಿಗೆ ಇರಿ ಮತ್ತು ಶೀಘ್ರದಲ್ಲೇ ನಾವು ಇತರ ಆವಿಷ್ಕಾರಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ !
ಪಿಎಸ್
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «».
ಮೂಲ: www.habr.com