🥇ವರ್ಫ್ ಕಲೆಕ್ಟರ್‌ನಲ್ಲಿ ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್: ಅದು ಏಕೆ ಮತ್ತು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

werf ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ತಲುಪಿಸಲು ನಮ್ಮ ಮುಕ್ತ ಮೂಲ GitOps CLI ಉಪಯುಕ್ತತೆಯಾಗಿದೆ. IN ಬಿಡುಗಡೆ v1.1 ಚಿತ್ರ ಸಂಗ್ರಾಹಕದಲ್ಲಿ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ: ವಿಷಯದ ಮೂಲಕ ಚಿತ್ರಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವುದು ಅಥವಾ ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್. ಇಲ್ಲಿಯವರೆಗೆ, werf ನಲ್ಲಿ ವಿಶಿಷ್ಟವಾದ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಯು Git ಟ್ಯಾಗ್, Git ಶಾಖೆ ಅಥವಾ Git ಕಮಿಟ್ ಮೂಲಕ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆದರೆ ಈ ಎಲ್ಲಾ ಯೋಜನೆಗಳು ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದನ್ನು ಹೊಸ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ಅದರ ಬಗ್ಗೆ ವಿವರಗಳು ಮತ್ತು ಅದು ಏಕೆ ಒಳ್ಳೆಯದು ಎಂದು ಕಟ್ ಅಡಿಯಲ್ಲಿದೆ.

ಒಂದು Git ರೆಪೊಸಿಟರಿಯಿಂದ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಗುಂಪನ್ನು ಹೊರತರಲಾಗುತ್ತಿದೆ

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

ಸೇವೆಗಳು ನಿಜವಾಗಿಯೂ ಸ್ವತಂತ್ರವಾಗಿರುವಾಗ ಮತ್ತು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಸಂದರ್ಭಗಳಿವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಯೋಜನೆಗಳಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಯೋಜನೆಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕ CI/CD ಪ್ರಕ್ರಿಯೆಗಳ ಮೂಲಕ ಅವುಗಳ ಬಿಡುಗಡೆಯನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ವಾಸ್ತವದಲ್ಲಿ, ಡೆವಲಪರ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹಲವಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತಾರೆ, ಆದರೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿ ಮತ್ತು ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುವುದು ಸ್ಪಷ್ಟ ಮಿತಿಮೀರಿದ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು: ಅಂತಹ ಹಲವಾರು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಒಂದೇ ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿವೆ ಮತ್ತು CI/CD ಯಲ್ಲಿ ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಬಿಡುಗಡೆಗಳು ಸಂಭವಿಸುತ್ತವೆ.

Git ಶಾಖೆ ಮತ್ತು Git ಟ್ಯಾಗ್ ಮೂಲಕ ಟ್ಯಾಗ್ ಮಾಡುವುದು

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

ಹೊಸ Git ಟ್ಯಾಗ್ ಅನ್ನು ರಚಿಸಿದಾಗ-ಉದಾಹರಣೆಗೆ, ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗ-ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್ ಚಿತ್ರಗಳಿಗೆ ಹೊಸ ಡಾಕರ್ ಟ್ಯಾಗ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

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

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

ಪರಿಣಾಮವಾಗಿ, ಪ್ರಸ್ತುತ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಯೊಂದಿಗೆ ಹಲವಾರು ಪ್ರತ್ಯೇಕ Git ರೆಪೊಸಿಟರಿಗಳನ್ನು ಬೇಲಿ ಹಾಕುವುದು ಅವಶ್ಯಕವಾಗಿದೆ ಮತ್ತು ಈ ಹಲವಾರು ರೆಪೊಸಿಟರಿಗಳ ರೋಲ್‌ಔಟ್ ಅನ್ನು ಸಂಘಟಿಸುವಲ್ಲಿ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಅಂತಹ ಯೋಜನೆಯು ಓವರ್ಲೋಡ್ ಮತ್ತು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಅನೇಕ ಸೇವೆಗಳನ್ನು ಒಂದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಯೋಜಿಸುವುದು ಮತ್ತು ಡಾಕರ್ ಟ್ಯಾಗ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಉತ್ತಮ, ಇದರಿಂದ ಯಾವುದೇ ಅನಗತ್ಯ ಮರುಪ್ರಾರಂಭಗಳಿಲ್ಲ.

Git ಬದ್ಧತೆಯಿಂದ ಟ್ಯಾಗ್ ಮಾಡಲಾಗುತ್ತಿದೆ

werf Git ಕಮಿಟ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರವನ್ನು ಸಹ ಹೊಂದಿದೆ.

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

ಆದಾಗ್ಯೂ, Git ಕಮಿಟ್‌ನಿಂದ ಟ್ಯಾಗ್ ಮಾಡುವಿಕೆಯು Git ಶಾಖೆಗಳು ಅಥವಾ Git ಟ್ಯಾಗ್‌ಗಳಿಂದ ಟ್ಯಾಗ್ ಮಾಡುವಿಕೆಯಂತೆಯೇ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ:

ಯಾವುದೇ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸದ ಖಾಲಿ ಕಮಿಟ್ ಅನ್ನು ರಚಿಸಬಹುದು, ಆದರೆ ಚಿತ್ರದ ಡಾಕರ್ ಟ್ಯಾಗ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ.
ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸದ ವಿಲೀನ ಬದ್ಧತೆಯನ್ನು ರಚಿಸಬಹುದು, ಆದರೆ ಚಿತ್ರದ ಡಾಕರ್ ಟ್ಯಾಗ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ.
ಇಮೇಜ್‌ಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳದ Git ನಲ್ಲಿನ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವ ಬದ್ಧತೆಯನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಚಿತ್ರದ ಡಾಕರ್ ಟ್ಯಾಗ್ ಅನ್ನು ಮತ್ತೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ.

Git ಶಾಖೆಯ ಹೆಸರನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವುದು ಚಿತ್ರದ ಆವೃತ್ತಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವುದಿಲ್ಲ

Git ಶಾಖೆಗಳಿಗೆ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಇದೆ.

ಶಾಖೆಯ ಹೆಸರಿನಿಂದ ಟ್ಯಾಗ್ ಮಾಡುವುದು ಆ ಶಾಖೆಯಲ್ಲಿನ ಕಮಿಟ್‌ಗಳನ್ನು ಕಾಲಾನುಕ್ರಮದಲ್ಲಿ ಅನುಕ್ರಮವಾಗಿ ಸಂಗ್ರಹಿಸುವವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದು ಶಾಖೆಯೊಳಗೆ ಅಲ್ಪಾವಧಿಯ ಅವಧಿಯೊಂದಿಗೆ ಸತತವಾಗಿ ತಳ್ಳುವಿಕೆಯೊಂದಿಗೆ, ಹಳೆಯ ಕಮಿಟ್ ಅನ್ನು ಹೊಸದಕ್ಕಿಂತ ನಂತರ ಸಂಕಲಿಸಬಹುದು: ಚಿತ್ರದ ಹಳೆಯ ಆವೃತ್ತಿಯು Git ಶಾಖೆಯ ಟ್ಯಾಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸದನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡುತ್ತದೆ. ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು CI/CD ವ್ಯವಸ್ಥೆಯಿಂದ ಪರಿಹರಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, GitLab CI ನಲ್ಲಿ ನಂತರದ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಕಮಿಟ್‌ಗಳ ಸರಣಿಗಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ). ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳು ಇದನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅಂತಹ ಮೂಲಭೂತ ಸಮಸ್ಯೆಯನ್ನು ತಡೆಗಟ್ಟಲು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವಿರಬೇಕು.

ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್ ಎಂದರೇನು?

ಆದ್ದರಿಂದ, ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್ ಎಂದರೇನು - ವಿಷಯದ ಮೂಲಕ ಚಿತ್ರಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವುದು.

ಡಾಕರ್ ಟ್ಯಾಗ್‌ಗಳನ್ನು ರಚಿಸಲು, ಇದು Git ಪ್ರೈಮಿಟಿವ್ಸ್ (Git ಶಾಖೆ, Git ಟ್ಯಾಗ್...) ಅಲ್ಲ, ಆದರೆ ಇದರೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಚೆಕ್‌ಸಮ್:

ಚಿತ್ರದ ವಿಷಯಗಳು. ಚಿತ್ರದ ID ಟ್ಯಾಗ್ ಅದರ ವಿಷಯವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ಮಿಸುವಾಗ, ಚಿತ್ರದಲ್ಲಿನ ಫೈಲ್‌ಗಳು ಬದಲಾಗದಿದ್ದರೆ ಈ ಗುರುತಿಸುವಿಕೆ ಬದಲಾಗುವುದಿಲ್ಲ;
Git ನಲ್ಲಿ ಈ ಚಿತ್ರವನ್ನು ರಚಿಸುವ ಇತಿಹಾಸ. ವಿಭಿನ್ನ Git ಶಾಖೆಗಳೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಚಿತ್ರಗಳು ಮತ್ತು werf ಮೂಲಕ ವಿಭಿನ್ನ ನಿರ್ಮಾಣ ಇತಿಹಾಸವು ವಿಭಿನ್ನ ID ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಅಂತಹ ಗುರುತಿಸುವಿಕೆಯ ಟ್ಯಾಗ್ ಅನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಚಿತ್ರದ ಹಂತದ ಸಹಿ.

ಪ್ರತಿಯೊಂದು ಚಿತ್ರವು ಹಂತಗಳ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿದೆ: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch ಇತ್ಯಾದಿ ಪ್ರತಿಯೊಂದು ಹಂತವು ಅದರ ವಿಷಯಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿದೆ - ವೇದಿಕೆಯ ಸಹಿ (ಹಂತದ ಸಹಿ).

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

ಸಂರಚನೆಯಿಂದ ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ werf.yaml ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ತನ್ನದೇ ಆದ ಸಹಿ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಡಾಕರ್ ಟ್ಯಾಗ್ ಇರುತ್ತದೆ.

ವೇದಿಕೆಯ ಸಹಿ ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ:

ಖಾಲಿ Git ಕಮಿಟ್‌ಗಳಿಗೆ ನಿರೋಧಕ.
ಚಿತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸದ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವ Git ಗೆ ನಿರೋಧಕವಾಗಿದೆ.
ಶಾಖೆಯ ಹಳೆಯ Git ಕಮಿಟ್‌ಗಳಿಗಾಗಿ ಬಿಲ್ಡ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವಾಗ ಚಿತ್ರದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಕೂಲಂಕಷವಾಗಿ ಪರಿಶೀಲಿಸುವ ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ.

ಇದು ಈಗ ಶಿಫಾರಸು ಮಾಡಲಾದ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರವಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ CI ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ werf ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ.

ವರ್ಫ್‌ನಲ್ಲಿ ಹೇಗೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು ಬಳಸುವುದು

ಆಜ್ಞೆಯು ಈಗ ಅನುಗುಣವಾದ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದೆ werf publish: --tag-by-stages-signature=true|false

CI ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರವನ್ನು ಆಜ್ಞೆಯಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗುತ್ತದೆ werf ci-env. ಹಿಂದೆ, ಅದಕ್ಕೆ ನಿಯತಾಂಕವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ werf ci-env --tagging-strategy=tag-or-branch. ಈಗ, ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ werf ci-env --tagging-strategy=stages-signature ಅಥವಾ ಈ ಆಯ್ಕೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಡಿ, werf ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರವನ್ನು ಬಳಸುತ್ತದೆ stages-signature. ತಂಡ werf ci-env ಆಜ್ಞೆಗೆ ಅಗತ್ಯವಾದ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸುತ್ತದೆ werf build-and-publish (ಅಥವಾ werf publish), ಆದ್ದರಿಂದ ಈ ಆಜ್ಞೆಗಳಿಗೆ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಆಯ್ಕೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ, ಆಜ್ಞೆ:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...ಈ ಕೆಳಗಿನ ಚಿತ್ರಗಳನ್ನು ರಚಿಸಬಹುದು:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

ಇದು 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ಚಿತ್ರದ ಹಂತಗಳ ಸಹಿಯಾಗಿದೆ backendಮತ್ತು f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ಚಿತ್ರ ಹಂತಗಳ ಸಹಿ frontend.

ವಿಶೇಷ ಕಾರ್ಯಗಳನ್ನು ಬಳಸುವಾಗ werf_container_image и werf_container_env ಹೆಲ್ಮ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಏನನ್ನೂ ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ: ಈ ಕಾರ್ಯಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸರಿಯಾದ ಚಿತ್ರದ ಹೆಸರುಗಳನ್ನು ರಚಿಸುತ್ತವೆ.

CI ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಉದಾಹರಣೆ ಸಂರಚನೆ:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ಸಂರಚನೆಯ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯು ದಸ್ತಾವೇಜನ್ನು ಲಭ್ಯವಿದೆ:

ಒಟ್ಟು

ಹೊಸ ಆಯ್ಕೆ werf publish --tag-by-stages-signature=true|false.
ಹೊಸ ಆಯ್ಕೆಯ ಮೌಲ್ಯ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ ಆಗಿರುತ್ತದೆ stages-signature).
ನೀವು ಈ ಹಿಂದೆ Git ಕಮಿಟ್‌ಗಳಿಗಾಗಿ ಟ್ಯಾಗಿಂಗ್ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಿದ್ದರೆ (WERF_TAG_GIT_COMMIT ಅಥವಾ ಆಯ್ಕೆ werf publish --tag-git-commit COMMIT), ನಂತರ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರಕ್ಕೆ ಬದಲಾಯಿಸಲು ಮರೆಯದಿರಿ ಹಂತಗಳು-ಸಹಿ.
ಹೊಸ ಯೋಜನೆಗಳನ್ನು ತಕ್ಷಣವೇ ಹೊಸ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಗೆ ಬದಲಾಯಿಸುವುದು ಉತ್ತಮ.
werf 1.1 ಗೆ ವರ್ಗಾಯಿಸುವಾಗ, ಹಳೆಯ ಯೋಜನೆಗಳನ್ನು ಹೊಸ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಗೆ ಬದಲಾಯಿಸಲು ಸಲಹೆ ನೀಡಲಾಗುತ್ತದೆ, ಆದರೆ ಹಳೆಯದು ಟ್ಯಾಗ್-ಅಥವಾ-ಶಾಖೆ ಈಗಲೂ ಬೆಂಬಲಿತವಾಗಿದೆ.

ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್ ಲೇಖನದಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ:

ಖಾಲಿ Git ಕಮಿಟ್‌ಗಳಿಗೆ ಡಾಕರ್ ಟ್ಯಾಗ್ ಹೆಸರು ಪ್ರತಿರೋಧ.
Git ಗೆ ಡಾಕರ್ ಟ್ಯಾಗ್ ಹೆಸರಿನ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವು ಚಿತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸದ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
Git ಶಾಖೆಗಳಿಗೆ ಹಳೆಯ Git ಕಮಿಟ್‌ಗಳಿಗಾಗಿ ಬಿಲ್ಡ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವಾಗ ಚಿತ್ರದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಕೂಲಂಕಷವಾಗಿ ಪರಿಶೀಲಿಸುವ ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ.

ಅದನ್ನು ಬಳಸಿ! ಮತ್ತು ನಮ್ಮನ್ನು ಭೇಟಿ ಮಾಡಲು ಮರೆಯಬೇಡಿ GitHubಸಮಸ್ಯೆಯನ್ನು ರಚಿಸಲು ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದನ್ನು ಹುಡುಕಲು, ಪ್ಲಸ್ ಸೇರಿಸಿ, PR ಅನ್ನು ರಚಿಸಿ ಅಥವಾ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯನ್ನು ವೀಕ್ಷಿಸಿ.

ಪಿಎಸ್

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

ಮೂಲ: www.habr.com

ವರ್ಫ್ ಬಿಲ್ಡರ್‌ನಲ್ಲಿ ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್: ಅದು ಏಕೆ ಮತ್ತು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?