🥇ಧಾರಕ ಚಿತ್ರಗಳ "ಸ್ಮಾರ್ಟ್" ಕ್ಲೀನಿಂಗ್ ಸಮಸ್ಯೆ ಮತ್ತು ವರ್ಫ್‌ನಲ್ಲಿ ಅದರ ಪರಿಹಾರ

ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ವಿತರಿಸಲಾದ ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಆಧುನಿಕ CI/CD ಪೈಪ್‌ಲೈನ್‌ಗಳ ನೈಜತೆಗಳಲ್ಲಿ ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿಗಳಲ್ಲಿ (ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ ಮತ್ತು ಅದರ ಸಾದೃಶ್ಯಗಳು) ಸಂಗ್ರಹಗೊಳ್ಳುವ ಚಿತ್ರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ಲೇಖನವು ಚರ್ಚಿಸುತ್ತದೆ. ಚಿತ್ರಗಳ ಪ್ರಸ್ತುತತೆಗೆ ಮುಖ್ಯ ಮಾನದಂಡಗಳು ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಲ್ಲಿ ಉಂಟಾಗುವ ತೊಂದರೆಗಳು, ಜಾಗವನ್ನು ಉಳಿಸುವುದು ಮತ್ತು ತಂಡಗಳ ಅಗತ್ಯತೆಗಳನ್ನು ಪೂರೈಸುವುದು. ಅಂತಿಮವಾಗಿ, ನಿರ್ದಿಷ್ಟ ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು, ಈ ತೊಂದರೆಗಳನ್ನು ಹೇಗೆ ಜಯಿಸಬಹುದು ಎಂಬುದನ್ನು ನಾವು ನಿಮಗೆ ತಿಳಿಸುತ್ತೇವೆ.

ಪರಿಚಯ

ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿನ ಚಿತ್ರಗಳ ಸಂಖ್ಯೆಯು ವೇಗವಾಗಿ ಬೆಳೆಯಬಹುದು, ಹೆಚ್ಚು ಶೇಖರಣಾ ಸ್ಥಳವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಹೀಗಾಗಿ ಅದರ ವೆಚ್ಚವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. ನೋಂದಾವಣೆಯಲ್ಲಿ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಜಾಗದ ಸ್ವೀಕಾರಾರ್ಹ ಬೆಳವಣಿಗೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು, ಮಿತಿಗೊಳಿಸಲು ಅಥವಾ ನಿರ್ವಹಿಸಲು, ಇದನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ:

ಚಿತ್ರಗಳಿಗಾಗಿ ನಿಗದಿತ ಸಂಖ್ಯೆಯ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಬಳಸಿ;
ಕೆಲವು ರೀತಿಯಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ.

ಮೊದಲ ಮಿತಿಯು ಕೆಲವೊಮ್ಮೆ ಸಣ್ಣ ತಂಡಗಳಿಗೆ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರುತ್ತದೆ. ಡೆವಲಪರ್‌ಗಳು ಸಾಕಷ್ಟು ಶಾಶ್ವತ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (latest, main, test, boris ಇತ್ಯಾದಿ), ನೋಂದಾವಣೆ ಗಾತ್ರದಲ್ಲಿ ಊದಿಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ದೀರ್ಘಕಾಲದವರೆಗೆ ನೀವು ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ. ಎಲ್ಲಾ ನಂತರ, ಎಲ್ಲಾ ಅಪ್ರಸ್ತುತ ಚಿತ್ರಗಳನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಯಾವುದೇ ಕೆಲಸ ಉಳಿದಿಲ್ಲ (ಎಲ್ಲವನ್ನೂ ಸಾಮಾನ್ಯ ಕಸ ಸಂಗ್ರಾಹಕರಿಂದ ಮಾಡಲಾಗುತ್ತದೆ).

ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೆಚ್ಚು ಮಿತಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಆಧುನಿಕ CI/CD ಯೋಜನೆಗಳಿಗೆ ಅಪರೂಪವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ. ಅಭಿವೃದ್ಧಿಯ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ, ಇದು ಬಳಕೆದಾರರಿಗೆ ಹೊಸ ಕಾರ್ಯವನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಪರೀಕ್ಷಿಸಲು, ನಿಯೋಜಿಸಲು ಮತ್ತು ತಲುಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಎಲ್ಲಾ ಯೋಜನೆಗಳಲ್ಲಿ, ಪ್ರತಿ ಕಮಿಟ್‌ನೊಂದಿಗೆ CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ. ಅದರಲ್ಲಿ, ಚಿತ್ರವನ್ನು ಒಟ್ಟುಗೂಡಿಸಲಾಗುತ್ತದೆ, ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ, ಡೀಬಗ್ ಮಾಡಲು ಮತ್ತು ಉಳಿದ ಚೆಕ್‌ಗಳಿಗಾಗಿ ವಿವಿಧ ಕುಬರ್ನೆಟ್ಸ್ ಸರ್ಕ್ಯೂಟ್‌ಗಳಿಗೆ ಹೊರತರಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ಬದಲಾವಣೆಗಳು ಅಂತಿಮ ಬಳಕೆದಾರರನ್ನು ತಲುಪುತ್ತವೆ. ಮತ್ತು ಇದು ಇನ್ನು ಮುಂದೆ ರಾಕೆಟ್ ವಿಜ್ಞಾನವಲ್ಲ, ಆದರೆ ಅನೇಕರಿಗೆ ದೈನಂದಿನ ಘಟನೆಯಾಗಿದೆ - ನೀವು ಈ ಲೇಖನವನ್ನು ಓದುತ್ತಿರುವುದರಿಂದ ಹೆಚ್ಚಾಗಿ ನಿಮಗಾಗಿ.

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

ಆದರೆ ಚಿತ್ರವು ಪ್ರಸ್ತುತವಾಗಿದೆಯೇ ಎಂದು ನೀವು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತೀರಿ?

ಚಿತ್ರದ ಪ್ರಸ್ತುತತೆಯ ಮಾನದಂಡಗಳು

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮುಖ್ಯ ಮಾನದಂಡಗಳು ಹೀಗಿವೆ:

1. ಮೊದಲನೆಯದು (ಎಲ್ಲಕ್ಕಿಂತ ಹೆಚ್ಚು ಸ್ಪಷ್ಟ ಮತ್ತು ಅತ್ಯಂತ ವಿಮರ್ಶಾತ್ಮಕವಾದದ್ದು) ಚಿತ್ರಗಳು ಪ್ರಸ್ತುತ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಚಿತ್ರಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರಿಂದ ಗಮನಾರ್ಹವಾದ ಉತ್ಪಾದನಾ ಅಲಭ್ಯತೆಯ ವೆಚ್ಚಗಳು ಉಂಟಾಗಬಹುದು (ಉದಾಹರಣೆಗೆ, ಚಿತ್ರಗಳು ಪ್ರತಿರೂಪಕ್ಕೆ ಬೇಕಾಗಬಹುದು) ಅಥವಾ ಯಾವುದೇ ಲೂಪ್‌ಗಳಲ್ಲಿ ತಂಡದ ಡೀಬಗ್ ಮಾಡುವ ಪ್ರಯತ್ನಗಳನ್ನು ನಿರಾಕರಿಸಬಹುದು. (ಈ ಕಾರಣಕ್ಕಾಗಿ ನಾವು ವಿಶೇಷವನ್ನೂ ಸಹ ಮಾಡಿದ್ದೇವೆ ಪ್ರಮೀತಿಯಸ್ ರಫ್ತುದಾರ, ಯಾವುದೇ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅಂತಹ ಚಿತ್ರಗಳ ಅನುಪಸ್ಥಿತಿಯನ್ನು ಇದು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ.)

2. ಎರಡನೆಯದು (ಕಡಿಮೆ ಸ್ಪಷ್ಟ, ಆದರೆ ಬಹಳ ಮುಖ್ಯ ಮತ್ತು ಮತ್ತೊಮ್ಮೆ ಶೋಷಣೆಗೆ ಸಂಬಂಧಿಸಿದೆ) - ಚಿತ್ರಗಳು ಗಂಭೀರ ಸಮಸ್ಯೆಗಳ ಪತ್ತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ರೋಲ್ಬ್ಯಾಕ್ ಅಗತ್ಯವಿದೆ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯಲ್ಲಿ. ಉದಾಹರಣೆಗೆ, ಹೆಲ್ಮ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಇವುಗಳು ಬಿಡುಗಡೆಯ ಉಳಿಸಿದ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಚಿತ್ರಗಳಾಗಿವೆ. (ಮೂಲಕ, ಹೆಲ್ಮ್‌ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮಿತಿಯು 256 ಪರಿಷ್ಕರಣೆಗಳು, ಆದರೆ ಯಾರಾದರೂ ನಿಜವಾಗಿಯೂ ಉಳಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ ಅಂತಹ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಆವೃತ್ತಿಗಳು?..) ಎಲ್ಲಾ ನಂತರ, ನಾವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಆವೃತ್ತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಇದರಿಂದ ನಾವು ಅವುಗಳನ್ನು ನಂತರ ಬಳಸಬಹುದು, ಅಂದರೆ. ಅಗತ್ಯವಿದ್ದರೆ ಅವರಿಗೆ "ಹಿಂತಿರುಗಿ".

3. ಮೂರನೇ - ಡೆವಲಪರ್ ಅಗತ್ಯತೆಗಳು: ಅವರ ಪ್ರಸ್ತುತ ಕೆಲಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಚಿತ್ರಗಳು. ಉದಾಹರಣೆಗೆ, ನಾವು PR ಅನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದರೆ, ಕೊನೆಯ ಕಮಿಟ್‌ಗೆ ಅನುಗುಣವಾದ ಚಿತ್ರವನ್ನು ಬಿಡಲು ಮತ್ತು ಹಿಂದಿನ ಬದ್ಧತೆಯನ್ನು ಹೇಳಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ: ಈ ರೀತಿಯಾಗಿ ಡೆವಲಪರ್ ಯಾವುದೇ ಕಾರ್ಯಕ್ಕೆ ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ಇತ್ತೀಚಿನ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.

4. ನಾಲ್ಕನೇ - ಚಿತ್ರಗಳು ಅದು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆವೃತ್ತಿಗಳಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತವೆ, ಅಂದರೆ ಅಂತಿಮ ಉತ್ಪನ್ನವಾಗಿದೆ: v1.0.0, 20.04.01/XNUMX/XNUMX, ಸಿಯೆರಾ, ಇತ್ಯಾದಿ.

NB: ಇಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಮಾನದಂಡಗಳನ್ನು ವಿವಿಧ ಕಂಪನಿಗಳಿಂದ ಡಜನ್‌ಗಟ್ಟಲೆ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ರೂಪಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಸಹಜವಾಗಿ, ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿನ ನಿಶ್ಚಿತಗಳು ಮತ್ತು ಬಳಸಿದ ಮೂಲಸೌಕರ್ಯವನ್ನು ಅವಲಂಬಿಸಿ (ಉದಾಹರಣೆಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ), ಈ ಮಾನದಂಡಗಳು ಭಿನ್ನವಾಗಿರಬಹುದು.

ಅರ್ಹತೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರಗಳು

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

* ನಿರ್ದಿಷ್ಟ ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿ ಅಳವಡಿಕೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಈ ಕೆಳಗಿನ ಪರಿಹಾರಗಳ ಸಾಧ್ಯತೆಗಳನ್ನು ನಾವು ಪರಿಗಣಿಸಿದ್ದೇವೆ: Azure CR, Docker Hub, ECR, GCR, GitHub ಪ್ಯಾಕೇಜುಗಳು, GitLab ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿ, ಹಾರ್ಬರ್ ರಿಜಿಸ್ಟ್ರಿ, JFrog ಆರ್ಟಿಫ್ಯಾಕ್ಟರಿ, Quay.io - ಸೆಪ್ಟೆಂಬರ್'2020 ರಂತೆ.

ಈ ನಿಯತಾಂಕಗಳ ಸೆಟ್ ನಾಲ್ಕನೇ ಮಾನದಂಡವನ್ನು ಪೂರೈಸಲು ಸಾಕಷ್ಟು ಸಾಕು - ಅಂದರೆ, ಆವೃತ್ತಿಗಳಿಗೆ ಅನುಗುಣವಾದ ಚಿತ್ರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು. ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಇತರ ಮಾನದಂಡಗಳಿಗೆ, ಒಬ್ಬರು ಕೆಲವು ರೀತಿಯ ರಾಜಿ ಪರಿಹಾರವನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ (ಕಠಿಣವಾದ ಅಥವಾ, ಬದಲಾಗಿ, ಹೆಚ್ಚು ಮೃದುವಾದ ನೀತಿ) - ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಹಣಕಾಸಿನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ.

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

ಮೊದಲ ಎರಡು ಮಾನದಂಡಗಳೊಂದಿಗಿನ ಪರಿಸ್ಥಿತಿಯು ಹೋಲುತ್ತದೆ: ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸದೆ ಅವುಗಳನ್ನು ತೃಪ್ತಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ - ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗಿರುವ ಒಂದು (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್).

Git ನಲ್ಲಿ ಕೆಲಸದ ಹರಿವಿನ ವಿವರಣೆ

ನೀವು Git ನಲ್ಲಿ ಈ ರೀತಿಯ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ:

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

ಶುದ್ಧೀಕರಣ ನೀತಿಗಳು ಚಿತ್ರಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಮಾತ್ರ ಅನುಮತಿಸಿದರೆ ಏನಾಗುತ್ತದೆ (ಅಳಿಸಲಾಗಿಲ್ಲ) ಕೊಟ್ಟಿರುವ ಟ್ಯಾಗ್ ಹೆಸರುಗಳಿಂದ?

ನಿಸ್ಸಂಶಯವಾಗಿ, ಅಂತಹ ಸನ್ನಿವೇಶವು ಯಾರನ್ನೂ ಸಂತೋಷಪಡಿಸುವುದಿಲ್ಲ.

ಚಿತ್ರಗಳನ್ನು ಅಳಿಸದಂತೆ ನೀತಿಗಳು ಅನುಮತಿಸಿದರೆ ಏನು ಬದಲಾಗುತ್ತದೆ? ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಮಧ್ಯಂತರ / ಕೊನೆಯ ಕಮಿಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಪ್ರಕಾರ?

ಫಲಿತಾಂಶವು ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಇನ್ನೂ ಆದರ್ಶದಿಂದ ದೂರವಿದೆ. ಎಲ್ಲಾ ನಂತರ, ದೋಷಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ನೋಂದಾವಣೆಯಲ್ಲಿ (ಅಥವಾ K8 ಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾದ) ಚಿತ್ರಗಳ ಅಗತ್ಯವಿರುವ ಡೆವಲಪರ್‌ಗಳನ್ನು ನಾವು ಇನ್ನೂ ಹೊಂದಿದ್ದೇವೆ...

ಪ್ರಸ್ತುತ ಮಾರುಕಟ್ಟೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳಲು: ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ ಕಾರ್ಯಗಳು ಸ್ವಚ್ಛಗೊಳಿಸುವಾಗ ಸಾಕಷ್ಟು ನಮ್ಯತೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಇದಕ್ಕೆ ಮುಖ್ಯ ಕಾರಣವೆಂದರೆ ಹೊರಗಿನ ಪ್ರಪಂಚದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಅಂತಹ ನಮ್ಯತೆ ಅಗತ್ಯವಿರುವ ತಂಡಗಳು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ API (ಅಥವಾ ಅನುಗುಣವಾದ ಅನುಷ್ಠಾನದ ಸ್ಥಳೀಯ API) ಅನ್ನು ಬಳಸಿಕೊಂಡು "ಹೊರಗಿನಿಂದ" ಚಿತ್ರ ಅಳಿಸುವಿಕೆಯನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.

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

ಸಾರ್ವತ್ರಿಕ ಚಿತ್ರ ಶುದ್ಧೀಕರಣಕ್ಕೆ ನಮ್ಮ ಮಾರ್ಗ

ಈ ಅಗತ್ಯ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ? ವಾಸ್ತವವೆಂದರೆ ನಾವು ಡೆವಲಪರ್‌ಗಳ ಪ್ರತ್ಯೇಕ ಗುಂಪಿನಲ್ಲ, ಆದರೆ ಸಿಐ/ಸಿಡಿ ಸಮಸ್ಯೆಗಳನ್ನು ಸಮಗ್ರವಾಗಿ ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುವ ಅನೇಕರಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಸೇವೆ ಸಲ್ಲಿಸುವ ತಂಡವಾಗಿದೆ. ಮತ್ತು ಇದಕ್ಕಾಗಿ ಮುಖ್ಯ ತಾಂತ್ರಿಕ ಸಾಧನವೆಂದರೆ ಓಪನ್ ಸೋರ್ಸ್ ಉಪಯುಕ್ತತೆ werf. ಇದರ ವಿಶಿಷ್ಟತೆಯು ಒಂದೇ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ನಿರಂತರ ವಿತರಣಾ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಇರುತ್ತದೆ: ಜೋಡಣೆಯಿಂದ ನಿಯೋಜನೆಯವರೆಗೆ.

ರಿಜಿಸ್ಟ್ರಿಗೆ ಚಿತ್ರಗಳನ್ನು ಪ್ರಕಟಿಸುವುದು* (ಅವುಗಳನ್ನು ನಿರ್ಮಿಸಿದ ತಕ್ಷಣ) ಅಂತಹ ಉಪಯುಕ್ತತೆಯ ಸ್ಪಷ್ಟ ಕಾರ್ಯವಾಗಿದೆ. ಮತ್ತು ಚಿತ್ರಗಳನ್ನು ಶೇಖರಣೆಗಾಗಿ ಅಲ್ಲಿ ಇರಿಸಲಾಗಿರುವುದರಿಂದ - ನಿಮ್ಮ ಸಂಗ್ರಹಣೆಯು ಅನಿಯಮಿತವಾಗಿಲ್ಲದಿದ್ದರೆ - ಅವರ ನಂತರದ ಶುಚಿಗೊಳಿಸುವಿಕೆಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರಬೇಕು. ಇದರಲ್ಲಿ ನಾವು ಹೇಗೆ ಯಶಸ್ಸನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ, ಎಲ್ಲಾ ನಿಗದಿತ ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸುತ್ತೇವೆ, ಮುಂದೆ ಚರ್ಚಿಸಲಾಗುವುದು.

* ನೋಂದಾವಣೆಗಳು ವಿಭಿನ್ನವಾಗಿದ್ದರೂ (ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ, ಗಿಟ್‌ಲ್ಯಾಬ್ ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿ, ಹಾರ್ಬರ್, ಇತ್ಯಾದಿ), ಅವರ ಬಳಕೆದಾರರು ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತಾರೆ. ನಮ್ಮ ಪ್ರಕರಣದಲ್ಲಿ ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವು ನೋಂದಾವಣೆಯ ಅನುಷ್ಠಾನವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನೋಂದಾವಣೆಗಳ ಹೊರಗೆ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲರಿಗೂ ಒಂದೇ ರೀತಿಯ ನಡವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ.

ನಾವು ವರ್ಫ್ ಅನ್ನು ಉದಾಹರಣೆ ಅನುಷ್ಠಾನಕ್ಕೆ ಬಳಸುತ್ತಿದ್ದರೂ, ಬಳಸಿದ ವಿಧಾನಗಳು ಇದೇ ರೀತಿಯ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸುತ್ತಿರುವ ಇತರ ತಂಡಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗುತ್ತವೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ಹಾಗಾಗಿ ನಾವು ಕಾರ್ಯನಿರತರಾದೆವು ಬಾಹ್ಯ ಚಿತ್ರಗಳನ್ನು ಶುಚಿಗೊಳಿಸುವ ಕಾರ್ಯವಿಧಾನದ ಅನುಷ್ಠಾನ - ಕಂಟೇನರ್‌ಗಳಿಗಾಗಿ ಈಗಾಗಲೇ ದಾಖಲಾತಿಗಳಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಸಾಮರ್ಥ್ಯಗಳ ಬದಲಿಗೆ. ಟ್ಯಾಗ್‌ಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಅವುಗಳ ರಚನೆಯ ಸಮಯಕ್ಕೆ (ಮೇಲೆ ತಿಳಿಸಲಾಗಿದೆ) ಅದೇ ಪ್ರಾಚೀನ ನೀತಿಗಳನ್ನು ರಚಿಸಲು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ API ಅನ್ನು ಬಳಸುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಅವರಿಗೆ ಸೇರಿಸಲಾಗಿದೆ ನಿಯೋಜಿಸಲಾದ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಬಳಸಿದ ಚಿತ್ರಗಳ ಆಧಾರದ ಮೇಲೆ ಪಟ್ಟಿಯನ್ನು ಅನುಮತಿಸಿ, ಅಂದರೆ ಕುಬರ್ನೆಟ್ಸ್. ಎರಡನೆಯದಕ್ಕೆ, ಎಲ್ಲಾ ನಿಯೋಜಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳ ಮೂಲಕ ಪುನರಾವರ್ತನೆ ಮಾಡಲು ಮತ್ತು ಮೌಲ್ಯಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಲು ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಬಳಸುವುದು ಸಾಕು. image.

ಈ ಕ್ಷುಲ್ಲಕ ಪರಿಹಾರವು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದೆ (ಮಾನದಂಡ ಸಂಖ್ಯೆ 1), ಆದರೆ ಶುಚಿಗೊಳಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಸುಧಾರಿಸಲು ನಮ್ಮ ಪ್ರಯಾಣದ ಪ್ರಾರಂಭ ಮಾತ್ರ. ಮುಂದಿನ - ಮತ್ತು ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ - ಹಂತವು ನಿರ್ಧಾರವಾಗಿತ್ತು Git ಇತಿಹಾಸದೊಂದಿಗೆ ಪ್ರಕಟಿಸಿದ ಚಿತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸಿ.

ಟ್ಯಾಗ್ ಮಾಡುವ ಯೋಜನೆಗಳು

ಮೊದಲಿಗೆ, ಅಂತಿಮ ಚಿತ್ರವು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಅಗತ್ಯವಾದ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾದ ವಿಧಾನವನ್ನು ನಾವು ಆರಿಸಿದ್ದೇವೆ ಮತ್ತು ಟ್ಯಾಗಿಂಗ್ ಸ್ಕೀಮ್‌ಗಳಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ಚಿತ್ರವನ್ನು ಪ್ರಕಟಿಸುವಾಗ, ಬಳಕೆದಾರರು ನಿರ್ದಿಷ್ಟ ಟ್ಯಾಗಿಂಗ್ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿಕೊಂಡರು (git-branch, git-commit ಅಥವಾ git-tag) ಮತ್ತು ಅನುಗುಣವಾದ ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗಿದೆ. CI ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಈ ಮೌಲ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ ಅಂತಿಮ ಚಿತ್ರವು ನಿರ್ದಿಷ್ಟ Git ಪ್ರೈಮಿಟಿವ್‌ನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ, ಲೇಬಲ್‌ಗಳಲ್ಲಿ ಸ್ವಚ್ಛಗೊಳಿಸಲು ಅಗತ್ಯವಾದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು.

ಈ ವಿಧಾನವು Git ಅನ್ನು ಸತ್ಯದ ಏಕೈಕ ಮೂಲವಾಗಿ ಬಳಸಲು ಅನುಮತಿಸುವ ನೀತಿಗಳ ಗುಂಪಿಗೆ ಕಾರಣವಾಯಿತು:

Git ನಲ್ಲಿನ ಶಾಖೆ/ಟ್ಯಾಗ್ ಅನ್ನು ಅಳಿಸುವಾಗ, ನೋಂದಾವಣೆಯಲ್ಲಿರುವ ಸಂಬಂಧಿತ ಚಿತ್ರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಳಿಸಲಾಗುತ್ತದೆ.
Git ಟ್ಯಾಗ್‌ಗಳು ಮತ್ತು ಕಮಿಟ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಚಿತ್ರಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿದ ಸ್ಕೀಮಾದಲ್ಲಿ ಬಳಸಲಾದ ಟ್ಯಾಗ್‌ಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಸಂಬಂಧಿತ ಕಮಿಟ್ ಅನ್ನು ರಚಿಸಲಾದ ಸಮಯದಿಂದ ನಿಯಂತ್ರಿಸಬಹುದು.

ಒಟ್ಟಾರೆಯಾಗಿ, ಪರಿಣಾಮವಾಗಿ ಅನುಷ್ಠಾನವು ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಿದೆ, ಆದರೆ ಶೀಘ್ರದಲ್ಲೇ ಹೊಸ ಸವಾಲು ನಮಗೆ ಕಾಯುತ್ತಿದೆ. ವಾಸ್ತವವೆಂದರೆ Git ಮೂಲಗಳನ್ನು ಆಧರಿಸಿ ಟ್ಯಾಗಿಂಗ್ ಸ್ಕೀಮ್‌ಗಳನ್ನು ಬಳಸುವಾಗ, ನಾವು ಹಲವಾರು ನ್ಯೂನತೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. (ಅವರ ವಿವರಣೆಯು ಈ ಲೇಖನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿರುವುದರಿಂದ, ಪ್ರತಿಯೊಬ್ಬರೂ ವಿವರಗಳೊಂದಿಗೆ ತಮ್ಮನ್ನು ತಾವು ಪರಿಚಿತರಾಗಬಹುದು ಇಲ್ಲಿ.) ಆದ್ದರಿಂದ, ಟ್ಯಾಗಿಂಗ್ (ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್) ಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ವಿಧಾನಕ್ಕೆ ಬದಲಾಯಿಸಲು ನಿರ್ಧರಿಸಿದ ನಂತರ, ನಾವು ಇಮೇಜ್ ಕ್ಲೀನಿಂಗ್ ಅನುಷ್ಠಾನವನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕಾಗಿತ್ತು.

ಹೊಸ ಅಲ್ಗಾರಿದಮ್

ಏಕೆ? ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್‌ನೊಂದಿಗೆ, ಪ್ರತಿ ಟ್ಯಾಗ್ Git ನಲ್ಲಿ ಬಹು ಕಮಿಟ್‌ಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ. ಚಿತ್ರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವಾಗ, ನೀವು ಇನ್ನು ಮುಂದೆ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮಾತ್ರ ಹೊಸ ಟ್ಯಾಗ್ ಅನ್ನು ರಿಜಿಸ್ಟ್ರಿಗೆ ಸೇರಿಸಲಾದ ಕಮಿಟ್‌ನಿಂದ.

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

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

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

ಅಂತಿಮ ಸಂರಚನೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಅಲ್ಗಾರಿದಮ್

ಶುಚಿಗೊಳಿಸುವಿಕೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ, ಬಳಕೆದಾರರು ಈಗ ಪ್ರಸ್ತುತ ಚಿತ್ರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ನೀತಿಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಅಂತಹ ಪ್ರತಿಯೊಂದು ನೀತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ:

ಅನೇಕ ಉಲ್ಲೇಖಗಳು, ಅಂದರೆ. ಸ್ಕ್ಯಾನಿಂಗ್ ಸಮಯದಲ್ಲಿ ಬಳಸಲಾಗುವ Git ಟ್ಯಾಗ್‌ಗಳು ಅಥವಾ Git ಶಾಖೆಗಳು;
ಮತ್ತು ಸೆಟ್‌ನಿಂದ ಪ್ರತಿ ಉಲ್ಲೇಖಕ್ಕಾಗಿ ಹುಡುಕಲಾದ ಚಿತ್ರಗಳ ಮಿತಿ.

ವಿವರಿಸಲು, ಡೀಫಾಲ್ಟ್ ನೀತಿ ಸಂರಚನೆಯು ಈ ರೀತಿ ಕಾಣಲಾರಂಭಿಸಿತು:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ಈ ಸಂರಚನೆಯು ಈ ಕೆಳಗಿನ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುವ ಮೂರು ನೀತಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

ಕೊನೆಯ 10 Git ಟ್ಯಾಗ್‌ಗಳಿಗಾಗಿ ಚಿತ್ರವನ್ನು ಉಳಿಸಿ (ಟ್ಯಾಗ್ ರಚನೆಯ ದಿನಾಂಕದಿಂದ).
ಕಳೆದ ವಾರದ ಚಟುವಟಿಕೆಯೊಂದಿಗೆ 2 ಥ್ರೆಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಇರದಂತೆ ಕಳೆದ ವಾರದಲ್ಲಿ ಪ್ರಕಟಿಸಲಾದ 10 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಚಿತ್ರಗಳನ್ನು ಉಳಿಸಬೇಡಿ.
ಶಾಖೆಗಳಿಗಾಗಿ 10 ಚಿತ್ರಗಳನ್ನು ಉಳಿಸಿ main, staging и production.

ಅಂತಿಮ ಅಲ್ಗಾರಿದಮ್ ಈ ಕೆಳಗಿನ ಹಂತಗಳಿಗೆ ಕುದಿಯುತ್ತದೆ:

ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿಯಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ಹಿಂಪಡೆಯಲಾಗುತ್ತಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಚಿತ್ರಗಳನ್ನು ಹೊರತುಪಡಿಸಿ, ಏಕೆಂದರೆ K8s API ಅನ್ನು ಪೋಲಿಂಗ್ ಮಾಡುವ ಮೂಲಕ ನಾವು ಈಗಾಗಲೇ ಅವರನ್ನು ಮೊದಲೇ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ.
Git ಇತಿಹಾಸವನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವುದು ಮತ್ತು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನೀತಿಗಳ ಆಧಾರದ ಮೇಲೆ ಚಿತ್ರಗಳನ್ನು ಹೊರತುಪಡಿಸಿ.
ಉಳಿದ ಚಿತ್ರಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ.

ನಮ್ಮ ವಿವರಣೆಗೆ ಹಿಂತಿರುಗಿ, ಇದು ವರ್ಫ್‌ನೊಂದಿಗೆ ಸಂಭವಿಸುತ್ತದೆ:

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

ತೀರ್ಮಾನಕ್ಕೆ

ಶೀಘ್ರದಲ್ಲೇ ಅಥವಾ ನಂತರ, ಹೆಚ್ಚಿನ ತಂಡಗಳು ನೋಂದಾವಣೆ ಓವರ್‌ಫ್ಲೋ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತವೆ.
ಪರಿಹಾರಗಳನ್ನು ಹುಡುಕುವಾಗ, ಚಿತ್ರದ ಪ್ರಸ್ತುತತೆಯ ಮಾನದಂಡವನ್ನು ನಿರ್ಧರಿಸಲು ಇದು ಮೊದಲು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಜನಪ್ರಿಯ ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿ ಸೇವೆಗಳು ನೀಡುವ ಪರಿಕರಗಳು "ಹೊರಗಿನ ಪ್ರಪಂಚ" ವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದ ಅತ್ಯಂತ ಸರಳವಾದ ಶುಚಿಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಂಘಟಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ: ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಬಳಸಿದ ಚಿತ್ರಗಳು ಮತ್ತು ತಂಡದ ಕೆಲಸದ ಹರಿವಿನ ವಿಶಿಷ್ಟತೆಗಳು.
ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಅಲ್ಗಾರಿದಮ್ CI/CD ಪ್ರಕ್ರಿಯೆಗಳ ತಿಳುವಳಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು ಮತ್ತು ಡಾಕರ್ ಇಮೇಜ್ ಡೇಟಾದೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಕಂಟೇನರ್ ಚಿತ್ರಗಳ "ಸ್ಮಾರ್ಟ್" ಶುಚಿಗೊಳಿಸುವ ಸಮಸ್ಯೆ ಮತ್ತು ವರ್ಫ್ನಲ್ಲಿ ಅದರ ಪರಿಹಾರ