werf 1.1 ಬಿಡುಗಡೆ: ಇಂದು ಬಿಲ್ಡರ್‌ಗೆ ಸುಧಾರಣೆಗಳು ಮತ್ತು ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು

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

ಬಿಡುಗಡೆಯ ಆಧಾರವು ವೇದಿಕೆಯ ಸಂಗ್ರಹಣೆಯ ಹೊಸ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಎರಡೂ ಸಂಗ್ರಾಹಕರ ಕೆಲಸದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಆಗಿದೆ (ಸ್ಟೇಪಲ್ ಮತ್ತು ಡಾಕರ್‌ಫೈಲ್‌ಗಾಗಿ). ಹೊಸ ಶೇಖರಣಾ ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಬಹು ಹೋಸ್ಟ್‌ಗಳು ಮತ್ತು ಸಮಾನಾಂತರ ಅಸೆಂಬ್ಲಿಗಳಿಂದ ವಿತರಿಸಲಾದ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ತೆರೆಯುತ್ತದೆ.

ಕೆಲಸದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಹಂತದ ಸಹಿಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಹಂತದಲ್ಲಿ ಅನಗತ್ಯ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ತೊಡೆದುಹಾಕುವುದು ಮತ್ತು ಫೈಲ್ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಈ ಆಪ್ಟಿಮೈಸೇಶನ್ ವರ್ಫ್ ಬಳಸಿ ಪ್ರಾಜೆಕ್ಟ್ ಬಿಲ್ಡ್‌ಗಳ ಸರಾಸರಿ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಮತ್ತು ಐಡಲ್ ಬಿಲ್ಡ್‌ಗಳು, ಸಂಗ್ರಹದಲ್ಲಿ ಎಲ್ಲಾ ಹಂತಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾಗ ಹಂತಗಳು-ಶೇಖರಣೆ, ಈಗ ನಿಜವಾಗಿಯೂ ವೇಗವಾಗಿದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಿರ್ಮಾಣವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು 1 ಸೆಕೆಂಡ್‌ಗಿಂತ ಕಡಿಮೆ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ! ತಂಡಗಳ ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳಿಗೂ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ. werf deploy и werf run.

ಈ ಬಿಡುಗಡೆಯಲ್ಲಿ, ವಿಷಯದ ಮೂಲಕ ಚಿತ್ರಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವ ತಂತ್ರವು ಕಾಣಿಸಿಕೊಂಡಿತು - ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್, ಇದು ಈಗ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಶಿಫಾರಸು ಮಾಡಲಾದ ಏಕೈಕ.

werf v1.1 ನಲ್ಲಿನ ಪ್ರಮುಖ ಆವಿಷ್ಕಾರಗಳನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಭವಿಷ್ಯದ ಯೋಜನೆಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿಸೋಣ.

werf v1.1 ನಲ್ಲಿ ಏನು ಬದಲಾಗಿದೆ?

ಸಂಗ್ರಹದಿಂದ ಹಂತಗಳನ್ನು ಆಯ್ಕೆಮಾಡಲು ಹೊಸ ಹಂತದ ಹೆಸರಿಸುವ ಸ್ವರೂಪ ಮತ್ತು ಅಲ್ಗಾರಿದಮ್

ಹೊಸ ವೇದಿಕೆಯ ಹೆಸರು ರಚನೆಯ ನಿಯಮ. ಈಗ ಪ್ರತಿ ಹಂತದ ನಿರ್ಮಾಣವು 2 ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದು ವಿಶಿಷ್ಟ ಹಂತದ ಹೆಸರನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ: ಒಂದು ಸಹಿ (ಅದು v1.0 ನಲ್ಲಿರುವಂತೆ) ಜೊತೆಗೆ ವಿಶಿಷ್ಟ ತಾತ್ಕಾಲಿಕ ಗುರುತಿಸುವಿಕೆ.

ಉದಾಹರಣೆಗೆ, ಪೂರ್ಣ ಹಂತದ ಚಿತ್ರದ ಹೆಸರು ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... ಅಥವಾ ಸಾಮಾನ್ಯವಾಗಿ:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ಇಲ್ಲಿ:

• SIGNATURE ಒಂದು ಹಂತದ ಸಹಿ, ಇದು ಹಂತದ ವಿಷಯದ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಮತ್ತು ಈ ವಿಷಯಕ್ಕೆ ಕಾರಣವಾದ Git ನಲ್ಲಿನ ಸಂಪಾದನೆಗಳ ಇತಿಹಾಸವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ;
• TIMESTAMP_MILLISEC ಹೊಸ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸುವ ಸಮಯದಲ್ಲಿ ರಚಿಸಲಾದ ಖಾತರಿಯ ಅನನ್ಯ ಇಮೇಜ್ ಐಡೆಂಟಿಫೈಯರ್ ಆಗಿದೆ.

ಸಂಗ್ರಹದಿಂದ ಹಂತಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅಲ್ಗಾರಿದಮ್ Git ಕಮಿಟ್‌ಗಳ ಸಂಬಂಧವನ್ನು ಪರಿಶೀಲಿಸುವುದನ್ನು ಆಧರಿಸಿದೆ:

1. ವರ್ಫ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದ ಸಹಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.
2. В ಹಂತಗಳು-ಶೇಖರಣೆ ಕೊಟ್ಟಿರುವ ಸಹಿಗಾಗಿ ಹಲವಾರು ಹಂತಗಳಿರಬಹುದು. ವರ್ಫ್ ಸಹಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ.
3. ಪ್ರಸ್ತುತ ಹಂತವನ್ನು Git ಗೆ ಲಿಂಕ್ ಮಾಡಿದ್ದರೆ (git-ಆರ್ಕೈವ್, Git ಪ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ಕಸ್ಟಮ್ ಹಂತ: install, beforeSetup, setup; ಅಥವಾ git-latest-patch), ನಂತರ werf ಪ್ರಸ್ತುತ ಕಮಿಟ್‌ನ ಪೂರ್ವಜವಾಗಿರುವ ಬದ್ಧತೆಗೆ ಸಂಬಂಧಿಸಿದ ಹಂತಗಳನ್ನು ಮಾತ್ರ ಆಯ್ಕೆಮಾಡುತ್ತದೆ (ಇದಕ್ಕಾಗಿ ಬಿಲ್ಡ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ).
4. ಉಳಿದ ಸೂಕ್ತ ಹಂತಗಳಿಂದ, ಒಂದನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ - ಸೃಷ್ಟಿ ದಿನಾಂಕದಿಂದ ಹಳೆಯದು.

ವಿಭಿನ್ನ Git ಶಾಖೆಗಳಿಗೆ ಒಂದು ಹಂತವು ಒಂದೇ ಸಹಿಯನ್ನು ಹೊಂದಿರಬಹುದು. ಆದರೆ ಸಹಿಗಳು ಹೊಂದಿಕೆಯಾಗಿದ್ದರೂ ಸಹ, ಈ ಶಾಖೆಗಳ ನಡುವೆ ವಿವಿಧ ಶಾಖೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಂಗ್ರಹವನ್ನು ಬಳಸದಂತೆ werf ತಡೆಯುತ್ತದೆ.

→ ದಾಖಲೆ.

ಹಂತದ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಹಂತಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ಉಳಿಸಲು ಹೊಸ ಅಲ್ಗಾರಿದಮ್

ಸಂಗ್ರಹದಿಂದ ಹಂತಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ, ವರ್ಫ್ ಸೂಕ್ತವಾದ ಹಂತವನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ, ಹೊಸ ಹಂತವನ್ನು ಜೋಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

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

ಹೊಸದಾಗಿ ಜೋಡಿಸಲಾದ ಚಿತ್ರವು ವಿಶಿಷ್ಟವಾದ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಲು ಖಾತರಿಪಡಿಸುತ್ತದೆ TIMESTAMP_MILLISEC (ಹೊಸ ಹಂತದ ಹೆಸರಿಸುವ ಸ್ವರೂಪವನ್ನು ನೋಡಿ). ಸಂದರ್ಭದಲ್ಲಿ ಹಂತಗಳು-ಶೇಖರಣೆ ಸೂಕ್ತವಾದ ಚಿತ್ರವು ಕಂಡುಬರುತ್ತದೆ, werf ಹೊಸದಾಗಿ ಸಂಕಲಿಸಿದ ಚಿತ್ರವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು ಸಂಗ್ರಹದಿಂದ ಚಿತ್ರವನ್ನು ಬಳಸುತ್ತದೆ.

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ: ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸುವ ಮೊದಲ ಪ್ರಕ್ರಿಯೆಯು (ವೇಗವಾದ ಒಂದು) ಅದನ್ನು ಹಂತಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಹಕ್ಕನ್ನು ಪಡೆಯುತ್ತದೆ-ಸಂಗ್ರಹಣೆ (ಮತ್ತು ನಂತರ ಈ ಒಂದೇ ಚಿತ್ರವು ಎಲ್ಲಾ ನಿರ್ಮಾಣಗಳಿಗೆ ಬಳಸಲ್ಪಡುತ್ತದೆ). ನಿಧಾನ ನಿರ್ಮಾಣ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಸ್ತುತ ಹಂತದ ನಿರ್ಮಾಣ ಫಲಿತಾಂಶಗಳನ್ನು ಉಳಿಸುವುದರಿಂದ ಮತ್ತು ಮುಂದಿನ ನಿರ್ಮಾಣಕ್ಕೆ ಚಲಿಸುವುದರಿಂದ ವೇಗವಾದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಎಂದಿಗೂ ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ.

→ ದಾಖಲೆ.

ಸುಧಾರಿತ ಡಾಕರ್‌ಫೈಲ್ ಬಿಲ್ಡರ್ ಕಾರ್ಯಕ್ಷಮತೆ

ಈ ಸಮಯದಲ್ಲಿ, ಡಾಕರ್‌ಫೈಲ್‌ನಿಂದ ನಿರ್ಮಿಸಲಾದ ಚಿತ್ರಕ್ಕಾಗಿ ಹಂತಗಳ ಪೈಪ್‌ಲೈನ್ ಒಂದು ಹಂತವನ್ನು ಒಳಗೊಂಡಿದೆ - dockerfile. ಸಹಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಾಗ, ಫೈಲ್ಗಳ ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ context, ಇದು ಅಸೆಂಬ್ಲಿ ಸಮಯದಲ್ಲಿ ಬಳಸಲ್ಪಡುತ್ತದೆ. ಈ ಸುಧಾರಣೆಯ ಮೊದಲು, werf ಪುನರಾವರ್ತಿತವಾಗಿ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳ ಮೂಲಕ ನಡೆದರು ಮತ್ತು ಪ್ರತಿ ಫೈಲ್‌ನ ಸಂದರ್ಭ ಮತ್ತು ಮೋಡ್ ಅನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಪಡೆದರು. V1.1 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ, werf Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಲೆಕ್ಕಾಚಾರದ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಬಳಸಬಹುದು.

ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆಧರಿಸಿದೆ git ls-ಟ್ರೀ. ಅಲ್ಗಾರಿದಮ್ ಖಾತೆಯಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ .dockerignore ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಫೈಲ್ ಟ್ರೀಯನ್ನು ಪುನರಾವರ್ತಿತವಾಗಿ ಚಲಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ನಾವು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಓದುವುದರಿಂದ ಮತ್ತು ಗಾತ್ರದ ಮೇಲೆ ಅಲ್ಗಾರಿದಮ್ನ ಅವಲಂಬನೆಯಿಂದ ಬೇರ್ಪಡಿಸಿದ್ದೇವೆ context ಗಮನಾರ್ಹವಲ್ಲ.

ಅಲ್ಗಾರಿದಮ್ ಟ್ರ್ಯಾಕ್ ಮಾಡದ ಫೈಲ್‌ಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಚೆಕ್‌ಸಮ್‌ನಲ್ಲಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಫೈಲ್‌ಗಳನ್ನು ಆಮದು ಮಾಡುವಾಗ ಸುಧಾರಿತ ಕಾರ್ಯಕ್ಷಮತೆ

werf v1.1 ನ ಆವೃತ್ತಿಗಳು ಯಾವಾಗ rsync ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತವೆ ಕಲಾಕೃತಿಗಳು ಮತ್ತು ಚಿತ್ರಗಳಿಂದ ಫೈಲ್‌ಗಳನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವುದು. ಹಿಂದೆ, ಹೋಸ್ಟ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಡೈರೆಕ್ಟರಿ ಮೌಂಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎರಡು ಹಂತಗಳಲ್ಲಿ ಆಮದು ಮಾಡಿಕೊಳ್ಳಲಾಗುತ್ತಿತ್ತು.

MacOS ನಲ್ಲಿನ ಆಮದು ಕಾರ್ಯಕ್ಷಮತೆ ಇನ್ನು ಮುಂದೆ ಡಾಕರ್ ಸಂಪುಟಗಳಿಂದ ಸೀಮಿತವಾಗಿರುವುದಿಲ್ಲ ಮತ್ತು Linux ಮತ್ತು Windows ನಂತೆಯೇ ಆಮದುಗಳು ಪೂರ್ಣಗೊಳ್ಳುತ್ತವೆ.

ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್

Werf v1.1 ಚಿತ್ರದ ವಿಷಯದ ಮೂಲಕ ಕರೆಯಲ್ಪಡುವ ಟ್ಯಾಗಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ - ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್. ಪರಿಣಾಮವಾಗಿ ಡಾಕರ್ ಚಿತ್ರಗಳ ಟ್ಯಾಗ್‌ಗಳು ಆ ಚಿತ್ರಗಳ ವಿಷಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುವಾಗ werf publish --tags-by-stages-signature ಅಥವಾ werf ci-env --tagging-strategy=stages-signature ಎಂದು ಕರೆಯಲ್ಪಡುವ ಚಿತ್ರಗಳನ್ನು ಪ್ರಕಟಿಸಿದರು ವೇದಿಕೆಯ ಸಹಿ ಚಿತ್ರ. ಪ್ರತಿಯೊಂದು ಚಿತ್ರವು ಈ ಚಿತ್ರದ ಹಂತಗಳ ತನ್ನದೇ ಆದ ಸಹಿಯೊಂದಿಗೆ ಟ್ಯಾಗ್ ಮಾಡಲ್ಪಟ್ಟಿದೆ, ಇದು ಪ್ರತಿ ಹಂತದ ನಿಯಮಿತ ಸಹಿಯಂತೆಯೇ ಅದೇ ನಿಯಮಗಳ ಪ್ರಕಾರ ಪ್ರತ್ಯೇಕವಾಗಿ ಲೆಕ್ಕಹಾಕಲ್ಪಡುತ್ತದೆ, ಆದರೆ ಚಿತ್ರದ ಸಾಮಾನ್ಯ ಗುರುತಿಸುವಿಕೆಯಾಗಿದೆ.

ಚಿತ್ರದ ಹಂತಗಳ ಸಹಿ ಅವಲಂಬಿಸಿರುತ್ತದೆ:

1. ಈ ಚಿತ್ರದ ವಿಷಯಗಳು;
2. ಈ ವಿಷಯಕ್ಕೆ ಕಾರಣವಾದ Git ಬದಲಾವಣೆಗಳ ಇತಿಹಾಸಗಳು.

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

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

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

ಪ್ರಮುಖ: ಈಗಿನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಹಂತಗಳು-ಸಹಿ - ಇದು ಶಿಫಾರಸು ಮಾಡಲಾದ ಏಕೈಕ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರ. ಇದನ್ನು ಆಜ್ಞೆಯಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ werf ci-env (ನೀವು ಬೇರೆ ಟ್ಯಾಗಿಂಗ್ ಸ್ಕೀಮ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸದ ಹೊರತು).

→ ದಾಖಲೆ. ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಪ್ರಕಟಣೆಯನ್ನು ಸಹ ಮೀಸಲಿಡಲಾಗುತ್ತದೆ. ನವೀಕರಿಸಲಾಗಿದೆ (ಏಪ್ರಿಲ್ 3): ವಿವರಗಳೊಂದಿಗೆ ಲೇಖನ ಪ್ರಕಟಿಸಲಾಗಿದೆ.

ಲಾಗಿಂಗ್ ಮಟ್ಟಗಳು

ಔಟ್ಪುಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಲು, ಲಾಗಿಂಗ್ ಮಟ್ಟವನ್ನು ಹೊಂದಿಸಲು ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಳಕೆದಾರರಿಗೆ ಈಗ ಅವಕಾಶವಿದೆ. ಆಯ್ಕೆಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ --log-quiet, --log-verbose, --log-debug.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಔಟ್ಪುಟ್ ಕನಿಷ್ಠ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ:

ವರ್ಬೋಸ್ ಔಟ್‌ಪುಟ್ ಬಳಸುವಾಗ (--log-verbose) ವರ್ಫ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು:

ವಿವರವಾದ ಔಟ್ಪುಟ್ (--log-debug), werf ಡೀಬಗ್ ಮಾಡುವ ಮಾಹಿತಿಯ ಜೊತೆಗೆ, ಬಳಸಿದ ಲೈಬ್ರರಿಗಳ ಲಾಗ್‌ಗಳನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ. ಉದಾಹರಣೆಗೆ, ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯೊಂದಿಗಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು ಮತ್ತು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ಕಳೆಯುವ ಸ್ಥಳಗಳನ್ನು ಸಹ ದಾಖಲಿಸಬಹುದು:

ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು

ಎಚ್ಚರಿಕೆ ಕೆಳಗೆ ವಿವರಿಸಿದ ಆಯ್ಕೆಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ v1.1 ಈ ಆವೃತ್ತಿಯಲ್ಲಿ ಲಭ್ಯವಾಗುತ್ತದೆ, ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಅವುಗಳಲ್ಲಿ ಹಲವು. ನವೀಕರಣಗಳು ಸ್ವಯಂ ನವೀಕರಣಗಳ ಮೂಲಕ ಬರುತ್ತವೆ ಮಲ್ಟಿವರ್ಫ್ ಬಳಸುವಾಗ. ಈ ವೈಶಿಷ್ಟ್ಯಗಳು v1.1 ಕಾರ್ಯಗಳ ಸ್ಥಿರ ಭಾಗದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ; ಅವುಗಳ ನೋಟವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಬಳಕೆದಾರ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ವಿವಿಧ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ ಅಳವಡಿಕೆಗಳಿಗೆ ಸಂಪೂರ್ಣ ಬೆಂಬಲ (ಹೊಸ)

• ಆವೃತ್ತಿ: v1.1
• ದಿನಾಂಕಗಳು: ಮಾರ್ಚ್
• ಸಮಸ್ಯೆ

werf ಅನ್ನು ಬಳಸುವಾಗ ಬಳಕೆದಾರರು ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ ಕಸ್ಟಮ್ ಅನುಷ್ಠಾನವನ್ನು ಬಳಸುವುದು ಗುರಿಯಾಗಿದೆ.

ಪ್ರಸ್ತುತ, ನಾವು ಸಂಪೂರ್ಣ ಬೆಂಬಲವನ್ನು ಖಾತರಿಪಡಿಸುವ ಕೆಳಗಿನ ಪರಿಹಾರಗಳ ಗುಂಪನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ:

• ಡೀಫಾಲ್ಟ್ (ಲೈಬ್ರರಿ/ರಿಜಿಸ್ಟ್ರಿ)*,
• AWS ECR
• ಅಜೂರ್*,
• ಡಾಕರ್ ಹಬ್
• GCR*,
• GitHub ಪ್ಯಾಕೇಜುಗಳು
• GitLab ರಿಜಿಸ್ಟ್ರಿ*,
• ಬಂದರು*,
• ಕ್ವೇ.

ಪ್ರಸ್ತುತ werf ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಬೆಂಬಲಿತವಾಗಿರುವ ಪರಿಹಾರಗಳನ್ನು ನಕ್ಷತ್ರ ಚಿಹ್ನೆಯಿಂದ ಗುರುತಿಸಲಾಗಿದೆ. ಇತರರಿಗೆ ಬೆಂಬಲವಿದೆ, ಆದರೆ ಮಿತಿಗಳೊಂದಿಗೆ.

ಎರಡು ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಬಹುದು:

• ಕೆಲವು ಪರಿಹಾರಗಳು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ API ಬಳಸಿಕೊಂಡು ಟ್ಯಾಗ್ ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಬಳಕೆದಾರರು werf ನ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೀನಪ್ ಅನ್ನು ಬಳಸದಂತೆ ತಡೆಯುತ್ತದೆ. AWS ECR, ಡಾಕರ್ ಹಬ್ ಮತ್ತು GitHub ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಇದು ನಿಜ.
• ಕೆಲವು ಪರಿಹಾರಗಳು ನೆಸ್ಟೆಡ್ ರೆಪೊಸಿಟರಿಗಳನ್ನು (ಡಾಕರ್ ಹಬ್, ಗಿಟ್‌ಹಬ್ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು ಕ್ವೇ) ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಅಥವಾ ಮಾಡುತ್ತವೆ, ಆದರೆ ಬಳಕೆದಾರರು ಅವುಗಳನ್ನು UI ಅಥವಾ API (AWS ECR) ಬಳಸಿಕೊಂಡು ಹಸ್ತಚಾಲಿತವಾಗಿ ರಚಿಸಬೇಕು.

ಪರಿಹಾರಗಳ ಸ್ಥಳೀಯ API ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಮತ್ತು ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲಿದ್ದೇವೆ. ಈ ಕಾರ್ಯವು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ವರ್ಫ್ ಕಾರ್ಯಾಚರಣೆಯ ಪೂರ್ಣ ಚಕ್ರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.

ವಿತರಿಸಲಾದ ಚಿತ್ರ ನಿರ್ಮಾಣ (↑)

• ಆವೃತ್ತಿ: v1.2 v1.1 (ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಆದ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸಲಾಗಿದೆ)
• ದಿನಾಂಕಗಳು: ಮಾರ್ಚ್-ಏಪ್ರಿಲ್ ಮಾರ್ಚ್
• ಸಮಸ್ಯೆ

ಈ ಸಮಯದಲ್ಲಿ, werf v1.0 ಮತ್ತು v1.1 ಅನ್ನು ಕೇವಲ ಒಂದು ಮೀಸಲಾದ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮತ್ತು ಪ್ರಕಟಿಸುವ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು Kubernetes ಗೆ ನಿಯೋಜಿಸುವ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಬಳಸಬಹುದು.

ವರ್ಫ್‌ನ ವಿತರಣಾ ಕೆಲಸದ ಸಾಧ್ಯತೆಗಳನ್ನು ತೆರೆಯಲು, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಿರ್ಮಾಣ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ಹಲವಾರು ಅನಿಯಂತ್ರಿತ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದಾಗ ಮತ್ತು ಈ ಹೋಸ್ಟ್‌ಗಳು ತಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ಬಿಲ್ಡ್‌ಗಳ ನಡುವೆ (ತಾತ್ಕಾಲಿಕ ಓಟಗಾರರು) ಉಳಿಸುವುದಿಲ್ಲ, ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ವರ್ಫ್ ಅಗತ್ಯವಿದೆ ವೇದಿಕೆಯ ಅಂಗಡಿಯಾಗಿ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ.

ಹಿಂದೆ, ವರ್ಫ್ ಯೋಜನೆಯನ್ನು ಇನ್ನೂ ಡಪ್ ಎಂದು ಕರೆಯುತ್ತಿದ್ದಾಗ, ಅಂತಹ ಅವಕಾಶವನ್ನು ಹೊಂದಿತ್ತು. ಆದಾಗ್ಯೂ, werf ನಲ್ಲಿ ಈ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ.

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

GitHub ಕ್ರಿಯೆಗಳಿಗೆ ಅಧಿಕೃತ ಬೆಂಬಲ (ಹೊಸ)

• ಆವೃತ್ತಿ: v1.1
• ದಿನಾಂಕಗಳು: ಮಾರ್ಚ್
• ಸಮಸ್ಯೆ

ವರ್ಫ್ ದಸ್ತಾವೇಜನ್ನು ಒಳಗೊಂಡಿದೆ (ವಿಭಾಗಗಳು ಉಲ್ಲೇಖ и ಮಾರ್ಗದರ್ಶನ), ಹಾಗೆಯೇ ವರ್ಫ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅಧಿಕೃತ GitHub ಆಕ್ಷನ್.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇದು ಅಲ್ಪಕಾಲಿಕ ಓಟಗಾರರ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ವರ್ಫ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

CI ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಬಳಕೆದಾರರ ಸಂವಹನದ ಯಂತ್ರಶಾಸ್ತ್ರವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಲು/ರೋಲ್ ಔಟ್ ಮಾಡಲು ಕೆಲವು ಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪುಲ್ ವಿನಂತಿಗಳ ಮೇಲೆ ಲೇಬಲ್‌ಗಳನ್ನು ಇರಿಸುವುದನ್ನು ಆಧರಿಸಿದೆ.

ವರ್ಫ್ (↓) ನೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ನಿಯೋಜನೆ

• ಆವೃತ್ತಿ: v1.1
• ದಿನಾಂಕಗಳು: ಜನವರಿ-ಫೆಬ್ರವರಿ ಏಪ್ರಿಲ್
• ಸಮಸ್ಯೆ

ಸಂಕೀರ್ಣ ಕ್ರಿಯೆಗಳಿಲ್ಲದೆ, ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಸ್ಥಳೀಯವಾಗಿ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಒಂದೇ ಏಕೀಕೃತ ಸಂರಚನೆಯನ್ನು ಸಾಧಿಸುವುದು ಮುಖ್ಯ ಗುರಿಯಾಗಿದೆ.

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

ಹೊಸ ಕ್ಲೀನಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ (ಹೊಸ)

• ಆವೃತ್ತಿ: v1.1
• ದಿನಾಂಕಗಳು: ಏಪ್ರಿಲ್
• ಸಮಸ್ಯೆ

ಕಾರ್ಯವಿಧಾನದಲ್ಲಿ werf v1.1 ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯಲ್ಲಿ cleanup ವಿಷಯ-ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಗಾಗಿ ಚಿತ್ರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಯಾವುದೇ ಅವಕಾಶವಿಲ್ಲ - ಈ ಚಿತ್ರಗಳು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ.

ಅಲ್ಲದೆ, werf ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯು (v1.0 ಮತ್ತು v1.1) ಟ್ಯಾಗಿಂಗ್ ಸ್ಕೀಮ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ಪ್ರಕಟಿಸಲಾದ ಚಿತ್ರಗಳಿಗಾಗಿ ವಿಭಿನ್ನ ಕ್ಲೀನಪ್ ನೀತಿಗಳನ್ನು ಬಳಸುತ್ತದೆ: Git ಶಾಖೆ, Git ಟ್ಯಾಗ್ ಅಥವಾ Git ಬದ್ಧತೆ.

Git ನಲ್ಲಿನ ಕಮಿಟ್‌ಗಳ ಇತಿಹಾಸವನ್ನು ಆಧರಿಸಿ ಚಿತ್ರಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಹೊಸ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಿದೆ, ಎಲ್ಲಾ ಟ್ಯಾಗಿಂಗ್ ಯೋಜನೆಗಳಿಗೆ ಏಕೀಕೃತವಾಗಿದೆ:

• ಪ್ರತಿ git HEAD (ಶಾಖೆಗಳು ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳು) ಗಾಗಿ N1 ಇತ್ತೀಚಿನ ಕಮಿಟ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ N2 ಚಿತ್ರಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಇರಿಸಬೇಡಿ.
• ಪ್ರತಿ git HEAD (ಶಾಖೆಗಳು ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳು) ಗಾಗಿ N1 ಅತ್ಯಂತ ಇತ್ತೀಚಿನ ಕಮಿಟ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ N2 ಹಂತದ ಚಿತ್ರಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಸಂಗ್ರಹಿಸಬೇಡಿ.
• ಯಾವುದೇ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ ಬಳಸಲಾದ ಎಲ್ಲಾ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ (ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳ ಎಲ್ಲಾ ಕ್ಯೂಬ್ ಸಂದರ್ಭಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲಾಗುತ್ತದೆ; ನೀವು ಈ ನಡವಳಿಕೆಯನ್ನು ವಿಶೇಷ ಆಯ್ಕೆಗಳೊಂದಿಗೆ ಮಿತಿಗೊಳಿಸಬಹುದು).
• ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಉಳಿಸಲಾದ ಸಂಪನ್ಮೂಲ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾದ ಎಲ್ಲಾ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ.
• ಜಿಟ್‌ನಿಂದ ಯಾವುದೇ HEAD ನೊಂದಿಗೆ ಸಂಬಂಧವಿಲ್ಲದಿದ್ದರೆ ಚಿತ್ರವನ್ನು ಅಳಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಅನುಗುಣವಾದ HEAD ಅನ್ನು ಸ್ವತಃ ಅಳಿಸಲಾಗಿದೆ) ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಮತ್ತು ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಯಾವುದೇ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ.

ಸಮಾನಾಂತರ ಚಿತ್ರ ಕಟ್ಟಡ (↓)

• ಆವೃತ್ತಿ: v1.1
• ದಿನಾಂಕಗಳು: ಜನವರಿ-ಫೆಬ್ರವರಿ ಏಪ್ರಿಲ್*

ವರ್ಫ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯು ವಿವರಿಸಿದ ಚಿತ್ರಗಳು ಮತ್ತು ಕಲಾಕೃತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ werf.yaml, ಅನುಕ್ರಮವಾಗಿ. ಚಿತ್ರಗಳು ಮತ್ತು ಕಲಾಕೃತಿಗಳ ಸ್ವತಂತ್ರ ಹಂತಗಳನ್ನು ಜೋಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಮಾನಾಂತರಗೊಳಿಸುವುದು ಅಗತ್ಯವಾಗಿದೆ, ಜೊತೆಗೆ ಅನುಕೂಲಕರ ಮತ್ತು ತಿಳಿವಳಿಕೆ ಔಟ್ಪುಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.

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

ಹೆಲ್ಮ್ 3 ಗೆ ಪರಿವರ್ತನೆ (↓)

• ಆವೃತ್ತಿ: v1.2
• ದಿನಾಂಕಗಳು: ಫೆಬ್ರವರಿ-ಮಾರ್ಚ್ ಮೇ*

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

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

ಕುಬರ್ನೆಟ್ಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ವಿವರಿಸಲು Jsonnet (↓)

• ಆವೃತ್ತಿ: v1.2
• ದಿನಾಂಕಗಳು: ಜನವರಿ-ಫೆಬ್ರವರಿ ಏಪ್ರಿಲ್-ಮೇ

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

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

ಇತರ ಕುಬರ್ನೆಟ್ಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ವಿವರಣೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ಕಸ್ಟಮೈಜ್) ಪರಿಚಯಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಸಹ ಪರಿಗಣಿಸಲಾಗುತ್ತಿದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ ಕೆಲಸ (↓)

• ಆವೃತ್ತಿ: v1.2
• ದಿನಾಂಕಗಳು: ಏಪ್ರಿಲ್-ಮೇ ಮೇ-ಜೂನ್

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

ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನೀವು ಮೊದಲು ವಿತರಿಸಿದ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ (ಮೇಲಿನ ಪಾಯಿಂಟ್ ನೋಡಿ).

ಇದು ಡಾಕರ್ ಸರ್ವರ್ ಇಲ್ಲದೆಯೇ ಬಿಲ್ಡರ್‌ನ ಆಪರೇಟಿಂಗ್ ಮೋಡ್‌ಗೆ ಬೆಂಬಲದ ಅಗತ್ಯವಿದೆ (ಅಂದರೆ ಕನಿಕೋ ತರಹದ ಬಿಲ್ಡ್ ಅಥವಾ ಯೂಸರ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸುವುದು).

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

ಮುಕ್ತ ಅಭಿವೃದ್ಧಿಯತ್ತ ಒಂದು ಹೆಜ್ಜೆ

ನಾವು ನಮ್ಮ ಸಮುದಾಯವನ್ನು ಪ್ರೀತಿಸುತ್ತೇವೆ (GitHub, ಟೆಲಿಗ್ರಾಂ) ಮತ್ತು ಹೆಚ್ಚು ಹೆಚ್ಚು ಜನರು ವರ್ಫ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡಲು, ನಾವು ಚಲಿಸುತ್ತಿರುವ ದಿಕ್ಕನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಭಾಗವಹಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ.

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

• ದಾಖಲೆ ಮತ್ತು ಸೈಟ್;
• ಪರೀಕ್ಷೆ;
• ದೋಷಗಳು ಮತ್ತು ಕೆಟ್ಟ UX;
• 1.1.

ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡಲಾಗಿದೆ:

• ಅಪ್ರಸ್ತುತವಾದವುಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ.
• ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ಸಾಕಷ್ಟು ಸಂಖ್ಯೆಯ ವಿವರಗಳು ಮತ್ತು ವಿವರಗಳೊಂದಿಗೆ ಒಂದೇ ಸ್ವರೂಪಕ್ಕೆ ತರಲಾಗುತ್ತದೆ.
• ಆಲೋಚನೆಗಳು ಮತ್ತು ಸಲಹೆಗಳೊಂದಿಗೆ ಹೊಸ ಸಮಸ್ಯೆಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ.

ಆವೃತ್ತಿ v1.1 ಅನ್ನು ಹೇಗೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು

ಆವೃತ್ತಿಯು ಪ್ರಸ್ತುತದಲ್ಲಿ ಲಭ್ಯವಿದೆ ಚಾನಲ್ 1.1 ಇಎ (ಚಾನೆಲ್‌ಗಳಲ್ಲಿ ಅಚಲವಾದ и ಬಂಡೆಯಷ್ಟು ಗಟ್ಟಿ ಆದಾಗ್ಯೂ, ಸ್ಥಿರೀಕರಣವು ಸಂಭವಿಸಿದಂತೆ ಬಿಡುಗಡೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ea ಇದು ಈಗಾಗಲೇ ಬಳಕೆಗೆ ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿದೆ, ಏಕೆಂದರೆ ಚಾನಲ್ಗಳ ಮೂಲಕ ಹೋದರು ಆಲ್ಫಾ и ಬೀಟಾ) ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮಲ್ಟಿವರ್ಫ್ ಮೂಲಕ ಕೆಳಗಿನ ರೀತಿಯಲ್ಲಿ:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

ತೀರ್ಮಾನಕ್ಕೆ

ಸ್ಟೇಪಲ್ ಮತ್ತು ಡಾಕರ್‌ಫೈಲ್ ಬಿಲ್ಡರ್‌ಗಳಿಗೆ ಹೊಸ ಹಂತದ ಶೇಖರಣಾ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಬಿಲ್ಡರ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು ವರ್ಫ್‌ನಲ್ಲಿ ವಿತರಿಸಿದ ಮತ್ತು ಸಮಾನಾಂತರ ನಿರ್ಮಾಣಗಳನ್ನು ಅಳವಡಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ತೆರೆಯುತ್ತದೆ. ಈ ವೈಶಿಷ್ಟ್ಯಗಳು ಶೀಘ್ರದಲ್ಲೇ ಅದೇ v1.1 ಬಿಡುಗಡೆಯಲ್ಲಿ ಗೋಚರಿಸುತ್ತವೆ ಮತ್ತು ಸ್ವಯಂ-ಅಪ್‌ಡೇಟ್ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲಭ್ಯವಾಗುತ್ತವೆ (ಬಳಕೆದಾರರಿಗೆ ಮಲ್ಟಿವರ್ಫ್).

ಈ ಬಿಡುಗಡೆಯಲ್ಲಿ, ಚಿತ್ರದ ವಿಷಯದ ಆಧಾರದ ಮೇಲೆ ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರವನ್ನು ಸೇರಿಸಲಾಗಿದೆ - ವಿಷಯ ಆಧಾರಿತ ಟ್ಯಾಗಿಂಗ್, ಇದು ಡೀಫಾಲ್ಟ್ ತಂತ್ರವಾಗಿದೆ. ಮುಖ್ಯ ಕಮಾಂಡ್ ಲಾಗ್ ಅನ್ನು ಸಹ ಮರು ಕೆಲಸ ಮಾಡಲಾಗಿದೆ: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

ವಿತರಿಸಿದ ಅಸೆಂಬ್ಲಿಗಳನ್ನು ಸೇರಿಸುವುದು ಮುಂದಿನ ಮಹತ್ವದ ಹಂತವಾಗಿದೆ. ವಿ1.0 ರಿಂದ ಸಮಾನಾಂತರ ನಿರ್ಮಾಣಗಳಿಗಿಂತ ವಿತರಣಾ ನಿರ್ಮಾಣಗಳು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳು ವರ್ಫ್‌ಗೆ ಹೆಚ್ಚಿನ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸುತ್ತವೆ: ಬಿಲ್ಡರ್‌ಗಳ ಲಂಬ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ವಿವಿಧ CI/CD ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಅಲ್ಪಕಾಲಿಕ ಬಿಲ್ಡರ್‌ಗಳಿಗೆ ಬೆಂಬಲ, ಹಾಗೆಯೇ GitHub ಕ್ರಿಯೆಗಳಿಗೆ ಅಧಿಕೃತ ಬೆಂಬಲವನ್ನು ನೀಡುವ ಸಾಮರ್ಥ್ಯ . ಆದ್ದರಿಂದ, ಸಮಾನಾಂತರ ಅಸೆಂಬ್ಲಿಗಳ ಅನುಷ್ಠಾನದ ಗಡುವನ್ನು ಬದಲಾಯಿಸಲಾಯಿತು. ಆದಾಗ್ಯೂ, ನಾವು ಎರಡೂ ಸಾಧ್ಯತೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ.

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

ಪಿಎಸ್

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

• «werf 1.0 ಸ್ಥಿರತೆಯನ್ನು ಪರಿಚಯಿಸಲಾಗುತ್ತಿದೆ: GitOps ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು, ಸ್ಥಿತಿ ಮತ್ತು ಯೋಜನೆಗಳು»
• «werf - Kubernetes ನಲ್ಲಿ CI/CD ಗಾಗಿ ನಮ್ಮ ಸಾಧನ (ವಿಮರ್ಶೆ ಮತ್ತು ವೀಡಿಯೊ ವರದಿ)";
• ವರ್ಫ್‌ನಲ್ಲಿನ ನಾವೀನ್ಯತೆಗಳ ಕುರಿತು ಟಿಪ್ಪಣಿಗಳ ಸರಣಿ:
  • «ವರ್ಫ್‌ಗೆ 3-ವೇ ವಿಲೀನ: ಹೆಲ್ಮ್‌ನೊಂದಿಗೆ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಯೋಜನೆ "ಸ್ಟೆರಾಯ್ಡ್‌ಗಳಲ್ಲಿ"";
  • «ಸಂಕೀರ್ಣ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಹೊರತರಲು ವರ್ಫ್ ಅನ್ನು ಬಳಸುವುದು";
  • «ವರ್ಫ್‌ನಲ್ಲಿ ಮೊನೊರೆಪೊ ಮತ್ತು ಮಲ್ಟಿರೆಪೊಗೆ ಬೆಂಬಲ ಮತ್ತು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು";
  • «ಸಾಮಾನ್ಯ ಡಾಕರ್‌ಫೈಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ಈಗ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ವರ್ಫ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಬಹುದು».

ಮೂಲ: www.habr.com