ProHoster > ಬ್ಲಾಗ್ > ಆಡಳಿತ > ಆವೃತ್ತಿಯ ದಾಖಲಾತಿ ಸೈಟ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ವರ್ಫ್‌ನೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಅಸೆಂಬ್ಲಿ ಮತ್ತು ಡಾಕರ್ ಚಿತ್ರಗಳ ನಿಯೋಜನೆ

ಆವೃತ್ತಿಯ ದಾಖಲಾತಿ ಸೈಟ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ವರ್ಫ್‌ನೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಅಸೆಂಬ್ಲಿ ಮತ್ತು ಡಾಕರ್ ಚಿತ್ರಗಳ ನಿಯೋಜನೆ

ನಾವು ಈಗಾಗಲೇ ನಮ್ಮ GitOps ಉಪಕರಣದ ಕುರಿತು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಮಾತನಾಡಿದ್ದೇವೆ. werf, ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಯೋಜನೆಯ ದಾಖಲಾತಿಯೊಂದಿಗೆ ಸೈಟ್ ಅನ್ನು ಜೋಡಿಸುವಲ್ಲಿ ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ - werf.io (ಅದರ ರಷ್ಯನ್ ಆವೃತ್ತಿ en.werf.io) ಇದು ಸಾಮಾನ್ಯ ಸ್ಥಿರ ತಾಣವಾಗಿದೆ, ಆದರೆ ಅದರ ಜೋಡಣೆಯು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಏಕೆಂದರೆ ಇದನ್ನು ಕ್ರಿಯಾತ್ಮಕ ಸಂಖ್ಯೆಯ ಕಲಾಕೃತಿಗಳನ್ನು ಬಳಸಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.

ಆವೃತ್ತಿಯ ದಾಖಲಾತಿ ಸೈಟ್‌ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ವರ್ಫ್‌ನೊಂದಿಗೆ ಡೈನಾಮಿಕ್ ಅಸೆಂಬ್ಲಿ ಮತ್ತು ಡಾಕರ್ ಚಿತ್ರಗಳ ನಿಯೋಜನೆ

ಸೈಟ್ ರಚನೆಯ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಹೋಗಿ: ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳಿಗೆ ಸಾಮಾನ್ಯ ಮೆನುವನ್ನು ರಚಿಸುವುದು, ಬಿಡುಗಡೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ಪುಟಗಳು ಇತ್ಯಾದಿ. - ನಾವು ಆಗುವುದಿಲ್ಲ. ಬದಲಿಗೆ, ಡೈನಾಮಿಕ್ ಅಸೆಂಬ್ಲಿಯ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಮತ್ತು ಅದರ ಜೊತೆಗಿನ CI/CD ಪ್ರಕ್ರಿಯೆಗಳ ಮೇಲೆ ಸ್ವಲ್ಪ ಗಮನಹರಿಸೋಣ.

ಪರಿಚಯ: ಸೈಟ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

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

  • ದಸ್ತಾವೇಜನ್ನು ನವೀಕರಿಸದೆ ಹೊಸ ವರ್ಫ್ ಕಾರ್ಯಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಾರದು ಮತ್ತು ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ದಾಖಲಾತಿಯಲ್ಲಿನ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ವರ್ಫ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯ ಬಿಡುಗಡೆಯನ್ನು ಸೂಚಿಸುತ್ತವೆ;
  • ಯೋಜನೆಯು ಸಾಕಷ್ಟು ತೀವ್ರವಾದ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೊಂದಿದೆ: ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ ಬಿಡುಗಡೆ ಮಾಡಬಹುದು;
  • ಹೊಸ ಆವೃತ್ತಿಯ ದಾಖಲಾತಿಯೊಂದಿಗೆ ಸೈಟ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಕಾರ್ಯಾಚರಣೆಗಳು ಕನಿಷ್ಠ ಬೇಸರದವು;
  • ಯೋಜನೆಯು ಲಾಕ್ಷಣಿಕ ವಿಧಾನವನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿದೆ ಆವೃತ್ತಿ, 5 ಸ್ಥಿರತೆ ಚಾನಲ್‌ಗಳೊಂದಿಗೆ. ಬಿಡುಗಡೆಯ ಪ್ರಕ್ರಿಯೆಯು ಸ್ಥಿರತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಸಲುವಾಗಿ ಚಾನಲ್‌ಗಳ ಮೂಲಕ ಆವೃತ್ತಿಗಳ ಅನುಕ್ರಮ ಅಂಗೀಕಾರವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: ಆಲ್ಫಾದಿಂದ ರಾಕ್-ಘನಕ್ಕೆ;
  • ಸೈಟ್ ರಷ್ಯಾದ ಭಾಷೆಯ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದೆ, ಇದು ಮುಖ್ಯ (ಅಂದರೆ, ಇಂಗ್ಲಿಷ್ ಭಾಷೆ) ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ "ಬದುಕುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತದೆ" (ಅಂದರೆ, ಅದರ ವಿಷಯವನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ).

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

ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿನ ಆವೃತ್ತಿ ಆಯ್ಕೆ ಮೆನುವಿನಲ್ಲಿ, ಪ್ರತಿ ಚಾನಲ್‌ನಲ್ಲಿ ವರ್ಫ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳು ಲಭ್ಯವಿದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ವಿಳಾಸದ ಮೂಲಕ werf.io/documentation ಇತ್ತೀಚಿನ ಬಿಡುಗಡೆಗಾಗಿ ಅತ್ಯಂತ ಸ್ಥಿರವಾದ ಚಾನಲ್‌ನ ಆವೃತ್ತಿಯು ತೆರೆಯುತ್ತದೆ - ಇದನ್ನು ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳು ಸಹ ಸೂಚಿಸುತ್ತವೆ. ಚಾನಲ್‌ಗಾಗಿ ದಾಖಲೆಗಳು ಪ್ರತ್ಯೇಕ ವಿಳಾಸಗಳಲ್ಲಿ ಲಭ್ಯವಿದೆ (ಉದಾಹರಣೆಗೆ, werf.io/v1.0-beta/documentation ಬೀಟಾ ಬಿಡುಗಡೆಗಾಗಿ 1.0).

ಒಟ್ಟಾರೆಯಾಗಿ, ಸೈಟ್ ಕೆಳಗಿನ ಆವೃತ್ತಿಗಳನ್ನು ಲಭ್ಯವಿದೆ:

  1. ರೂಟ್ (ಡೀಫಾಲ್ಟ್ ಆಗಿ ತೆರೆಯುತ್ತದೆ),
  2. ಪ್ರತಿ ಬಿಡುಗಡೆಯ ಪ್ರತಿ ಸಕ್ರಿಯ ನವೀಕರಣ ಚಾನಲ್‌ಗೆ (ಉದಾಹರಣೆಗೆ, werf.io/v1.0-beta).

ಸೈಟ್ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸಲು, ಸಾಮಾನ್ಯವಾಗಿ, ಅದನ್ನು ಬಳಸಿಕೊಂಡು ಕಂಪೈಲ್ ಮಾಡಲು ಸಾಕು ಜೆಕಿಲ್ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಚಾಲನೆ ಮಾಡುವ ಮೂಲಕ /docs werf ರೆಪೊಸಿಟರಿ ಅನುಗುಣವಾದ ಆಜ್ಞೆ (jekyll build), ಅಗತ್ಯವಿರುವ ಆವೃತ್ತಿಯ Git ಟ್ಯಾಗ್‌ಗೆ ಬದಲಾಯಿಸಿದ ನಂತರ.

ಇದನ್ನು ಸೇರಿಸಲು ಮಾತ್ರ ಉಳಿದಿದೆ:

  • ಉಪಯುಕ್ತತೆಯನ್ನು ಸ್ವತಃ (ವರ್ಫ್) ಜೋಡಣೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ;
  • CI/CD ಪ್ರಕ್ರಿಯೆಗಳನ್ನು GitLab CI ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ;
  • ಮತ್ತು ಇದೆಲ್ಲವೂ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ.

ಕಾರ್ಯಗಳನ್ನು

ಈಗ ವಿವರಿಸಿದ ಎಲ್ಲಾ ನಿಶ್ಚಿತಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯಗಳನ್ನು ರೂಪಿಸೋಣ:

  1. ಯಾವುದೇ ಅಪ್‌ಡೇಟ್ ಚಾನಲ್‌ನಲ್ಲಿ ವರ್ಫ್ ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಸೈಟ್ನಲ್ಲಿನ ದಸ್ತಾವೇಜನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಬೇಕು.
  2. ಅಭಿವೃದ್ಧಿಗಾಗಿ ನೀವು ಕೆಲವೊಮ್ಮೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ ಸೈಟ್‌ನ ಪೂರ್ವವೀಕ್ಷಣೆ ಆವೃತ್ತಿಗಳನ್ನು ವೀಕ್ಷಿಸಿ.

ಅನುಗುಣವಾದ Git ಟ್ಯಾಗ್‌ಗಳಿಂದ ಯಾವುದೇ ಚಾನಲ್‌ನಲ್ಲಿ ಆವೃತ್ತಿಯನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಸೈಟ್ ಅನ್ನು ಮರುಸಂಕಲಿಸಬೇಕು, ಆದರೆ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ:

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

ಇದು ತಿರುಗುತ್ತದೆ ಅಸೆಂಬ್ಲಿ ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸುವುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

Реализация

ಒಂದು ವಿಧಾನವನ್ನು ಆಯ್ಕೆಮಾಡುವುದು

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

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

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

werf vs git ಕ್ಲೋನ್ ಮತ್ತು ಕಲಾಕೃತಿಗಳು

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

ಇಲ್ಲಿ ವರ್ಫ್ ಯುಟಿಲಿಟಿ ಸ್ವತಃ ನಮ್ಮ ನೆರವಿಗೆ ಬರುತ್ತದೆ, ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತದೆ ಸ್ಮಾರ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ಮತ್ತು ನೀವು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ ಬಾಹ್ಯ ರೆಪೊಸಿಟರಿಗಳು. ರೆಪೊಸಿಟರಿಯಿಂದ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸಲು werf ಅನ್ನು ಬಳಸುವುದು ನಿರ್ಮಾಣವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ werf ಮೂಲಭೂತವಾಗಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಒಮ್ಮೆ ಕ್ಲೋನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮಾತ್ರ fetch ಅಗತ್ಯವಿದ್ದರೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ರೆಪೊಸಿಟರಿಯಿಂದ ಡೇಟಾವನ್ನು ಸೇರಿಸುವಾಗ, ನಾವು ಅಗತ್ಯವಿರುವ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ಮಾತ್ರ ಆಯ್ಕೆ ಮಾಡಬಹುದು (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಡೈರೆಕ್ಟರಿಯಾಗಿದೆ docs), ಇದು ಸೇರಿಸಲಾದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಜೆಕಿಲ್ ಸ್ಥಿರ ಡೇಟಾವನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸಾಧನವಾಗಿರುವುದರಿಂದ ಮತ್ತು ಅಂತಿಮ ಚಿತ್ರದಲ್ಲಿ ಅಗತ್ಯವಿಲ್ಲದ ಕಾರಣ, ಇದು ಕಂಪೈಲ್ ಮಾಡಲು ತಾರ್ಕಿಕವಾಗಿದೆ ವರ್ಫ್ ಕಲಾಕೃತಿ, ಮತ್ತು ಅಂತಿಮ ಚಿತ್ರಕ್ಕೆ ಸಂಕಲನ ಫಲಿತಾಂಶವನ್ನು ಮಾತ್ರ ಆಮದು ಮಾಡಿಕೊಳ್ಳಿ.

ನಾವು werf.yaml ಅನ್ನು ಬರೆಯುತ್ತೇವೆ

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

werf ನಿಮಗೆ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಗೆ ಹೋಗಿ ನಿಮ್ಮ ಸಂರಚನಾ ಕಡತದಲ್ಲಿ (werf.yaml), ಮತ್ತು ಇದು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಹಾರಾಡುತ್ತ ಸಂರಚನೆಯನ್ನು ರಚಿಸಿ ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿ (ನಿಮಗೆ ಬೇಕಾದುದನ್ನು!). ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಬಾಹ್ಯ ಡೇಟಾವು ಆವೃತ್ತಿಗಳು ಮತ್ತು ಬಿಡುಗಡೆಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯಾಗಿದೆ, ಅದರ ಆಧಾರದ ಮೇಲೆ ನಾವು ಅಗತ್ಯವಾದ ಸಂಖ್ಯೆಯ ಕಲಾಕೃತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ನಾವು ಎರಡು ಚಿತ್ರಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ: werf-doc и werf-dev ವಿವಿಧ ಸರ್ಕ್ಯೂಟ್ಗಳಲ್ಲಿ ಚಲಾಯಿಸಲು.

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

  • RELEASES - ಬಿಡುಗಡೆಗಳ ಪಟ್ಟಿ ಮತ್ತು ವರ್ಫ್‌ನ ಅನುಗುಣವಾದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಒಂದು ಸಾಲು, ಸ್ವರೂಪದಲ್ಲಿ ಮೌಲ್ಯಗಳ ಜಾಗದಿಂದ ಬೇರ್ಪಡಿಸಿದ ಪಟ್ಟಿಯ ರೂಪದಲ್ಲಿ <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>... ಉದಾಹರಣೆ: 1.0%v1.0.4-beta.20
  • CHANNELS - ಚಾನಲ್‌ಗಳ ಪಟ್ಟಿ ಮತ್ತು ವರ್ಫ್‌ನ ಅನುಗುಣವಾದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಒಂದು ಸಾಲು, ಸ್ವರೂಪದಲ್ಲಿ ಮೌಲ್ಯಗಳ ಜಾಗದಿಂದ ಬೇರ್ಪಡಿಸಿದ ಪಟ್ಟಿಯ ರೂಪದಲ್ಲಿ <КАНАЛ>%<НОМЕР_ВЕРСИИ>... ಉದಾಹರಣೆ: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
  • ROOT_VERSION — werf ಬಿಡುಗಡೆ ಆವೃತ್ತಿಯನ್ನು ಸೈಟ್‌ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ (ಹೆಚ್ಚಿನ ಬಿಡುಗಡೆ ಸಂಖ್ಯೆಯಿಂದ ದಸ್ತಾವೇಜನ್ನು ಪ್ರದರ್ಶಿಸಲು ಯಾವಾಗಲೂ ಅಗತ್ಯವಿಲ್ಲ). ಉದಾಹರಣೆ: v1.0.4-beta.20
  • REVIEW_SHA - ಪರೀಕ್ಷಾ ಲೂಪ್‌ಗಾಗಿ ನೀವು ಆವೃತ್ತಿಯನ್ನು ನಿರ್ಮಿಸಬೇಕಾದ ವಿಮರ್ಶೆ ಬದ್ಧತೆಯ ಹ್ಯಾಶ್.

ಈ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು GitLab CI ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ ತುಂಬಲಾಗುತ್ತದೆ ಮತ್ತು ಹೇಗೆ ನಿಖರವಾಗಿ ಕೆಳಗೆ ಬರೆಯಲಾಗಿದೆ.

ಮೊದಲನೆಯದಾಗಿ, ಅನುಕೂಲಕ್ಕಾಗಿ, ನಾವು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೇವೆ werf.yaml ಟೆಂಪ್ಲೇಟ್ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಹೋಗಿ, ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಿಂದ ಮೌಲ್ಯಗಳನ್ನು ನಿಯೋಜಿಸಿ:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

ಸೈಟ್‌ನ ಸ್ಥಿರ ಆವೃತ್ತಿಯನ್ನು ಕಂಪೈಲ್ ಮಾಡಲು ಕಲಾಕೃತಿಯ ವಿವರಣೆಯು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ (ರೂಟ್ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವುದು, ಹಾಗೆಯೇ ಡೆವ್ ಸರ್ಕ್ಯೂಟ್‌ನ ಆವೃತ್ತಿಯನ್ನು ಒಳಗೊಂಡಂತೆ) ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಕಾರ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಬ್ಲಾಕ್ಗೆ ಸರಿಸುತ್ತೇವೆ define - ನಂತರದ ಮರುಬಳಕೆಗಾಗಿ include. ನಾವು ಈ ಕೆಳಗಿನ ವಾದಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್‌ಗೆ ರವಾನಿಸುತ್ತೇವೆ:

  • Version - ರಚಿತವಾದ ಆವೃತ್ತಿ (ಟ್ಯಾಗ್ ಹೆಸರು);
  • Channel - ಕಲಾಕೃತಿಯನ್ನು ರಚಿಸಲಾದ ನವೀಕರಣ ಚಾನಲ್‌ನ ಹೆಸರು;
  • Commit - ಒಂದು ವೇಳೆ ಪರಿಶೀಲನಾ ಬದ್ಧತೆಗಾಗಿ ಕಲಾಕೃತಿಯನ್ನು ರಚಿಸಿದರೆ ಹ್ಯಾಶ್ ಅನ್ನು ಕಮಿಟ್ ಮಾಡಿ;
  • ಸಂದರ್ಭ.

ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಟೆಂಪ್ಲೇಟ್ ವಿವರಣೆ

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

ಕಲಾಕೃತಿಯ ಹೆಸರು ಅನನ್ಯವಾಗಿರಬೇಕು. ನಾವು ಇದನ್ನು ಸಾಧಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಚಾನಲ್ ಹೆಸರನ್ನು ಸೇರಿಸುವ ಮೂಲಕ (ವೇರಿಯಬಲ್ ಮೌಲ್ಯ .Channel) ಕಲಾಕೃತಿಯ ಹೆಸರಿಗೆ ಪ್ರತ್ಯಯವಾಗಿ: artifact: doc-{{ .Channel }}. ಆದರೆ ಕಲಾಕೃತಿಗಳಿಂದ ಆಮದು ಮಾಡಿಕೊಳ್ಳುವಾಗ, ನೀವು ಅದೇ ಹೆಸರುಗಳನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕಾಗುತ್ತದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

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

ಫೈಲ್ ಬಳಕೆಯನ್ನು ನೀವು ಗಮನಿಸಿರಬಹುದು releases.yml ವಿನಂತಿಸಿದ ಬಿಡುಗಡೆ ಡೇಟಾದೊಂದಿಗೆ YAML ಫೈಲ್ ಆಗಿದೆ Github.com (ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಪಡೆದ ಕಲಾಕೃತಿ). ಸೈಟ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುವಾಗ ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ, ಆದರೆ ಲೇಖನದ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ನಮಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಏಕೆಂದರೆ ಅದು ಅದರ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಕೇವಲ ಒಂದು ಕಲಾಕೃತಿಯ ಮರುಜೋಡಣೆ - ಸೈಟ್‌ನ ಮೂಲ ಆವೃತ್ತಿಯ ಕಲಾಕೃತಿ (ಇತರ ಕಲಾಕೃತಿಗಳಲ್ಲಿ ಇದು ಅಗತ್ಯವಿಲ್ಲ).

ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ if ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ವಿನ್ಯಾಸಗಳಿಗೆ ಹೋಗಿ {{ $Root.Files.Get "releases.yml" | sha256sum }} ಹಂತದಲ್ಲಿ ಹಂತಗಳು. ಇದು ಈ ಕೆಳಗಿನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಮೂಲ ಆವೃತ್ತಿಗಾಗಿ ಕಲಾಕೃತಿಯನ್ನು ನಿರ್ಮಿಸುವಾಗ (ವೇರಿಯಬಲ್ .Channel ಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ root) ಫೈಲ್ ಹ್ಯಾಶ್ releases.yml ಸಂಪೂರ್ಣ ಹಂತದ ಸಹಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಅನ್ಸಿಬಲ್ ಕಾರ್ಯದ ಹೆಸರಿನ ಭಾಗವಾಗಿದೆ (ಪ್ಯಾರಾಮೀಟರ್ name) ಹೀಗಾಗಿ, ಬದಲಾಯಿಸುವಾಗ ವಿಷಯ ಫೈಲ್ releases.yml ಅನುಗುಣವಾದ ಕಲಾಕೃತಿಯನ್ನು ಪುನಃ ಜೋಡಿಸಲಾಗುವುದು.

ಬಾಹ್ಯ ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ದಯವಿಟ್ಟು ಗಮನ ಕೊಡಿ. ನಿಂದ ಕಲಾಕೃತಿಯ ಚಿತ್ರದಲ್ಲಿ werf ರೆಪೊಸಿಟರಿ, ಡೈರೆಕ್ಟರಿಯನ್ನು ಮಾತ್ರ ಸೇರಿಸಲಾಗಿದೆ /docs, ಮತ್ತು ಪಾಸ್ ಮಾಡಿದ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಅಗತ್ಯವಿರುವ ಟ್ಯಾಗ್ ಅಥವಾ ರಿವ್ಯೂ ಕಮಿಟ್‌ನ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಚಾನೆಲ್‌ಗಳು ಮತ್ತು ಬಿಡುಗಡೆಗಳ ವರ್ಗಾವಣೆಗೊಂಡ ಆವೃತ್ತಿಗಳ ಕಲಾಕೃತಿಯ ವಿವರಣೆಯನ್ನು ರಚಿಸಲು ಕಲಾಕೃತಿ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬಳಸಲು, ನಾವು ವೇರಿಯೇಬಲ್‌ನಲ್ಲಿ ಲೂಪ್ ಅನ್ನು ಆಯೋಜಿಸುತ್ತೇವೆ .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

ಏಕೆಂದರೆ ಲೂಪ್ ಹಲವಾರು ಕಲಾಕೃತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ (ನಾವು ಭಾವಿಸುತ್ತೇವೆ), ಅವುಗಳ ನಡುವಿನ ವಿಭಜಕವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ - ಅನುಕ್ರಮ --- (ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ, ನೋಡಿ ದಸ್ತಾವೇಜನ್ನು) ಮೊದಲೇ ವ್ಯಾಖ್ಯಾನಿಸಿದಂತೆ, ಲೂಪ್‌ನಲ್ಲಿ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಕರೆಯುವಾಗ, ನಾವು ಆವೃತ್ತಿ ನಿಯತಾಂಕಗಳು, URL ಮತ್ತು ಮೂಲ ಸಂದರ್ಭವನ್ನು ರವಾನಿಸುತ್ತೇವೆ.

ಅಂತೆಯೇ, ಆದರೆ ಲೂಪ್ ಇಲ್ಲದೆ, ನಾವು "ವಿಶೇಷ ಸಂದರ್ಭಗಳಲ್ಲಿ" ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಕರೆಯುತ್ತೇವೆ: ರೂಟ್ ಆವೃತ್ತಿಗಾಗಿ, ಹಾಗೆಯೇ ವಿಮರ್ಶೆ ಬದ್ಧತೆಯಿಂದ ಆವೃತ್ತಿ:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸಿದರೆ ಮಾತ್ರ ಪರಿಶೀಲನಾ ಬದ್ಧತೆಯ ಕಲಾಕೃತಿಯನ್ನು ನಿರ್ಮಿಸಲಾಗುವುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ .WerfReviewCommit.

ಕಲಾಕೃತಿಗಳು ಸಿದ್ಧವಾಗಿವೆ - ಆಮದು ಮಾಡಿಕೊಳ್ಳಲು ಇದು ಸಮಯ!

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಅಂತಿಮ ಚಿತ್ರವು ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಸೇರಿಸುವ ಸಾಮಾನ್ಯ NGINX ಆಗಿದೆ nginx.conf ಮತ್ತು ಕಲಾಕೃತಿಗಳಿಂದ ಸ್ಥಿರ. ಸೈಟ್ನ ಮೂಲ ಆವೃತ್ತಿಯ ಕಲಾಕೃತಿಯ ಜೊತೆಗೆ, ನಾವು ವೇರಿಯಬಲ್ನಲ್ಲಿ ಲೂಪ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕಾಗಿದೆ .WerfVersions ಚಾನಲ್‌ನ ಕಲಾಕೃತಿಗಳನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಆವೃತ್ತಿಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು + ನಾವು ಮೊದಲು ಅಳವಡಿಸಿಕೊಂಡ ಕಲಾಕೃತಿ ಹೆಸರಿಸುವ ನಿಯಮವನ್ನು ಅನುಸರಿಸಿ. ಪ್ರತಿಯೊಂದು ಕಲಾಕೃತಿಯು ಎರಡು ಭಾಷೆಗಳಿಗೆ ಸೈಟ್‌ನ ಆವೃತ್ತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದರಿಂದ, ನಾವು ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ ಒದಗಿಸಿದ ಸ್ಥಳಗಳಿಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ.

ಅಂತಿಮ ಚಿತ್ರದ ವಿವರಣೆ werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

ಡೆವ್ ಸರ್ಕ್ಯೂಟ್‌ನಲ್ಲಿ ಮುಖ್ಯವಾದವುಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲಾದ ಹೆಚ್ಚುವರಿ ಚಿತ್ರವು ಸೈಟ್‌ನ ಎರಡು ಆವೃತ್ತಿಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿದೆ: ವಿಮರ್ಶೆ ಕಮಿಟ್‌ನ ಆವೃತ್ತಿ ಮತ್ತು ಸೈಟ್‌ನ ಮೂಲ ಆವೃತ್ತಿ (ಸಾಮಾನ್ಯ ಸ್ವತ್ತುಗಳಿವೆ ಮತ್ತು ನಿಮಗೆ ನೆನಪಿದ್ದರೆ , ಬಿಡುಗಡೆ ಡೇಟಾ). ಹೀಗಾಗಿ, ಹೆಚ್ಚುವರಿ ಚಿತ್ರವು ಆಮದು ವಿಭಾಗದಲ್ಲಿ ಮಾತ್ರ ಮುಖ್ಯಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತದೆ (ಮತ್ತು, ಸಹಜವಾಗಿ, ಹೆಸರಿನಲ್ಲಿ):

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

ಮೇಲೆ ಗಮನಿಸಿದಂತೆ, ಸೆಟ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ ಅನ್ನು ರನ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ವಿಮರ್ಶೆ ಬದ್ಧತೆಯ ಕಲಾಕೃತಿಯನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ REVIEW_SHA. ಯಾವುದೇ ಪರಿಸರ ವೇರಿಯೇಬಲ್ ಇಲ್ಲದಿದ್ದರೆ werf-dev ಚಿತ್ರವನ್ನು ರಚಿಸದೇ ಇರಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ REVIEW_SHA, ಆದರೆ ಸಲುವಾಗಿ ನೀತಿಗಳ ಮೂಲಕ ಸ್ವಚ್ಛಗೊಳಿಸುವುದು werf ನಲ್ಲಿನ ಡಾಕರ್ ಚಿತ್ರಗಳು werf-dev ಚಿತ್ರಕ್ಕಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಪೈಪ್‌ಲೈನ್ ರಚನೆಯನ್ನು ಸರಳಗೊಳಿಸಲು ನಾವು ಅದನ್ನು ಮೂಲ ಆವೃತ್ತಿಯ ಕಲಾಕೃತಿಯೊಂದಿಗೆ ಮಾತ್ರ ನಿರ್ಮಿಸಲು ಬಿಡುತ್ತೇವೆ (ಅದನ್ನು ಹೇಗಾದರೂ ನಿರ್ಮಿಸಲಾಗಿದೆ).

ಅಸೆಂಬ್ಲಿ ಸಿದ್ಧವಾಗಿದೆ! CI/CD ಮತ್ತು ಪ್ರಮುಖ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಹೋಗೋಣ.

GitLab CI ನಲ್ಲಿ ಪೈಪ್‌ಲೈನ್ ಮತ್ತು ಡೈನಾಮಿಕ್ ಬಿಲ್ಡ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳು

ನಿರ್ಮಾಣವನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗ ನಾವು ಬಳಸಿದ ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ werf.yaml. ಇದು REVIEW_SHA ವೇರಿಯೇಬಲ್‌ಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, GitHub ಹುಕ್‌ನಿಂದ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಕರೆ ಮಾಡುವಾಗ ನಾವು ಹೊಂದಿಸುತ್ತೇವೆ.

ನಾವು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಅಗತ್ಯವಾದ ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ರಚಿಸುತ್ತೇವೆ generate_artifacts, ಇದು ಎರಡು GitLab ಪೈಪ್‌ಲೈನ್ ಕಲಾಕೃತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ:

  • ಫೈಲ್ releases.yml ಬಿಡುಗಡೆಯ ಮಾಹಿತಿಯೊಂದಿಗೆ,
  • ಫೈಲ್ common_envs.sh, ರಫ್ತು ಮಾಡಬೇಕಾದ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಫೈಲ್ ವಿಷಯಗಳು generate_artifacts ನೀವು ನಮ್ಮಲ್ಲಿ ಕಾಣಬಹುದು ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ರೆಪೊಸಿಟರಿಗಳು. ಡೇಟಾವನ್ನು ಸ್ವತಃ ಸ್ವೀಕರಿಸುವುದು ಲೇಖನದ ವಿಷಯವಲ್ಲ, ಆದರೆ ಫೈಲ್ common_envs.sh ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ವರ್ಫ್ನ ಕೆಲಸವು ಅದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅದರ ವಿಷಯದ ಉದಾಹರಣೆ:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

ನೀವು ಅಂತಹ ಸ್ಕ್ರಿಪ್ಟ್ನ ಔಟ್ಪುಟ್ ಅನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಷ್ ಕಾರ್ಯವನ್ನು ಬಳಸಿ source.

ಈಗ ಮೋಜಿನ ಭಾಗ ಬರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿರ್ಮಾಣ ಮತ್ತು ನಿಯೋಜನೆ ಎರಡಕ್ಕೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ಅದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ werf.yaml ಆಗಿತ್ತು ಅದೇ ಕನಿಷ್ಠ ಒಂದು ಪೈಪ್ಲೈನ್ನಲ್ಲಿ. ಈ ಸ್ಥಿತಿಯನ್ನು ಪೂರೈಸದಿದ್ದರೆ, ಅಸೆಂಬ್ಲಿ ಸಮಯದಲ್ಲಿ ವರ್ಫ್ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಹಂತಗಳ ಸಹಿಗಳು ಮತ್ತು ಉದಾಹರಣೆಗೆ, ನಿಯೋಜನೆಯು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಇದು ನಿಯೋಜನೆ ದೋಷಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ... ನಿಯೋಜನೆಗೆ ಅಗತ್ಯವಿರುವ ಚಿತ್ರವು ಕಾಣೆಯಾಗಿದೆ.

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

ಪೀಳಿಗೆಯಾದರೆ werf.yaml ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳ ಪಟ್ಟಿ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ), ನಂತರ ಅಂತಹ ಡೇಟಾದ ಸಂಯೋಜನೆ ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಪೈಪ್ಲೈನ್ನಲ್ಲಿ ದಾಖಲಿಸಬೇಕು. ಬಾಹ್ಯ ನಿಯತಾಂಕಗಳು ಆಗಾಗ್ಗೆ ಬದಲಾದರೆ ಇದು ಮುಖ್ಯವಾಗಿದೆ.

ನಾವು ಮಾಡುತ್ತೇವೆ ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು ರೆಕಾರ್ಡ್ ಮಾಡಿ GitLab ನಲ್ಲಿ ಪೈಪ್‌ಲೈನ್‌ನ ಮೊದಲ ಹಂತದಲ್ಲಿ (ಪೂರ್ವನಿರ್ಮಾಣ) ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತಷ್ಟು ರೂಪದಲ್ಲಿ ರವಾನಿಸಿ GitLab CI ಕಲಾಕೃತಿ. ಇದೇ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ಪೈಪ್‌ಲೈನ್ ಕೆಲಸಗಳನ್ನು (ನಿರ್ಮಿಸಲು, ನಿಯೋಜಿಸಲು, ಸ್ವಚ್ಛಗೊಳಿಸಲು) ರನ್ ಮಾಡಲು ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ werf.yaml.

ವೇದಿಕೆಯ ವಿಷಯಗಳು ಪೂರ್ವನಿರ್ಮಾಣ ಫೈಲ್ .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

ಕಲಾಕೃತಿಯಲ್ಲಿ ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಸೆರೆಹಿಡಿದ ನಂತರ, ನೀವು ಪ್ರಮಾಣಿತ GitLab CI ಪೈಪ್‌ಲೈನ್ ಹಂತಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಮಿಸಬಹುದು ಮತ್ತು ನಿಯೋಜಿಸಬಹುದು: ನಿರ್ಮಿಸಿ ಮತ್ತು ನಿಯೋಜಿಸಿ. ನಾವು werf GitHub ರೆಪೊಸಿಟರಿಯಿಂದ ಕೊಕ್ಕೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಸ್ವತಃ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ (ಅಂದರೆ, GitHub ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಬದಲಾವಣೆಗಳು ಇದ್ದಾಗ). ವಿಭಾಗದಲ್ಲಿನ GitLab ಪ್ರಾಜೆಕ್ಟ್ ಗುಣಲಕ್ಷಣಗಳಲ್ಲಿ ಅವರಿಗೆ ಡೇಟಾವನ್ನು ಕಾಣಬಹುದು CI/CD ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> ಪೈಪ್‌ಲೈನ್ ಟ್ರಿಗ್ಗರ್‌ಗಳು, ತದನಂತರ GitHub ನಲ್ಲಿ ಅನುಗುಣವಾದ Webhook ಅನ್ನು ರಚಿಸಿ (ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> ವೆಬ್‌ಹೂಕ್ಸ್).

ನಿರ್ಮಾಣ ಹಂತವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab ಹಂತದಿಂದ ನಿರ್ಮಾಣ ಹಂತಕ್ಕೆ ಎರಡು ಕಲಾಕೃತಿಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ ಪೂರ್ವನಿರ್ಮಾಣ, ಆದ್ದರಿಂದ ನಾವು ರಚನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಸಿದ್ಧಪಡಿಸಿದ ಇನ್‌ಪುಟ್ ಡೇಟಾದೊಂದಿಗೆ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ರಫ್ತು ಮಾಡುತ್ತೇವೆ source common_envs.sh. ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಪೈಪ್ಲೈನ್ ​​ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ, ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ನಾವು ನಿರ್ಮಾಣ ಹಂತವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ, ನಾವು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಪೈಪ್ಲೈನ್ ​​ಅನ್ನು ನಡೆಸುತ್ತೇವೆ - ಈ ಸಂದರ್ಭದಲ್ಲಿ ಜೋಡಣೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ನಿಯೋಜನೆ ಹಂತದಲ್ಲಿ, ನಾವು ಎರಡು ಕಾರ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತೇವೆ - ಪ್ರತ್ಯೇಕವಾಗಿ ಉತ್ಪಾದನೆ ಮತ್ತು ಡೆವ್ ಸರ್ಕ್ಯೂಟ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲು, YAML ಟೆಂಪ್ಲೇಟ್ ಬಳಸಿ:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

ವರ್ಫ್ ನಿಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸಬೇಕಾದ ಕ್ಲಸ್ಟರ್ ಸಂದರ್ಭವನ್ನು ಸೂಚಿಸುವಲ್ಲಿ ಮಾತ್ರ ಕಾರ್ಯಗಳು ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ (WERF_KUBE_CONTEXT), ಮತ್ತು ಲೂಪ್ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು (environment.name и environment.url), ನಂತರ ಇದನ್ನು ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಾವು ಟೆಂಪ್ಲೇಟ್‌ಗಳ ವಿಷಯಗಳನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ... ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ವಿಷಯಕ್ಕೆ ಆಸಕ್ತಿದಾಯಕ ಏನೂ ಇಲ್ಲ, ಆದರೆ ನೀವು ಅವುಗಳನ್ನು ಕಾಣಬಹುದು ಲೇಖನಕ್ಕಾಗಿ ರೆಪೊಸಿಟರಿಗಳು.

ಅಂತಿಮ ಟಚ್

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

ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿಮಗೆ ಅಗತ್ಯವಿರುತ್ತದೆ:

  • ಶುಚಿಗೊಳಿಸುವ ಹಂತವನ್ನು ಸೇರಿಸಿ .gitlab-ci.yml;
  • ಶುಚಿಗೊಳಿಸುವ ಕಾರ್ಯದ ಆವರ್ತಕ ಮರಣದಂಡನೆಯನ್ನು ಸೇರಿಸಿ;
  • ಬರಹ ಪ್ರವೇಶ ಟೋಕನ್‌ನೊಂದಿಗೆ ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸಿ.

ಶುಚಿಗೊಳಿಸುವ ಹಂತವನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

ನಾವು ಈಗಾಗಲೇ ಸ್ವಲ್ಪ ಹೆಚ್ಚಿನದನ್ನು ನೋಡಿದ್ದೇವೆ - ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಮಾತ್ರ ನೀವು ಮೊದಲು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಅಳಿಸುವ ಹಕ್ಕನ್ನು ಹೊಂದಿರುವ ಟೋಕನ್‌ನೊಂದಿಗೆ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ (ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನೀಡಿದ GitLab CI ಟಾಸ್ಕ್ ಟೋಕನ್ ಮಾಡುವುದಿಲ್ಲ ಅಂತಹ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿವೆ). ಟೋಕನ್ ಅನ್ನು ಮುಂಚಿತವಾಗಿ GitLab ನಲ್ಲಿ ರಚಿಸಬೇಕು ಮತ್ತು ಅದರ ಮೌಲ್ಯವನ್ನು ಪರಿಸರ ವೇರಿಯಬಲ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು WERF_IMAGES_CLEANUP_PASSWORD ಯೋಜನೆ (CI/CD ಸೆಟ್ಟಿಂಗ್‌ಗಳು -> ಅಸ್ಥಿರ).

ಅಗತ್ಯವಿರುವ ವೇಳಾಪಟ್ಟಿಯೊಂದಿಗೆ ಶುಚಿಗೊಳಿಸುವ ಕಾರ್ಯವನ್ನು ಸೇರಿಸುವುದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ CI/CD ->
ವೇಳಾಪಟ್ಟಿಗಳು.

ಅಷ್ಟೆ: ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿನ ಯೋಜನೆಯು ಬಳಕೆಯಾಗದ ಚಿತ್ರಗಳಿಂದ ನಿರಂತರವಾಗಿ ಬೆಳೆಯುವುದಿಲ್ಲ.

ಪ್ರಾಯೋಗಿಕ ಭಾಗದ ಕೊನೆಯಲ್ಲಿ, ಲೇಖನದಿಂದ ಪೂರ್ಣ ಪಟ್ಟಿಗಳು ಲಭ್ಯವಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ ಹೋಗಿ:

ಪರಿಣಾಮವಾಗಿ

  1. ನಾವು ತಾರ್ಕಿಕ ಅಸೆಂಬ್ಲಿ ರಚನೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ: ಪ್ರತಿ ಆವೃತ್ತಿಗೆ ಒಂದು ಕಲಾಕೃತಿ.
  2. ಅಸೆಂಬ್ಲಿ ಸಾರ್ವತ್ರಿಕವಾಗಿದೆ ಮತ್ತು werf ನ ಹೊಸ ಆವೃತ್ತಿಗಳು ಬಿಡುಗಡೆಯಾದಾಗ ಹಸ್ತಚಾಲಿತ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ: ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿನ ದಸ್ತಾವೇಜನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
  3. ವಿಭಿನ್ನ ಬಾಹ್ಯರೇಖೆಗಳಿಗಾಗಿ ಎರಡು ಚಿತ್ರಗಳನ್ನು ಜೋಡಿಸಲಾಗಿದೆ.
  4. ಇದು ತ್ವರಿತವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬಳಸಲಾಗುತ್ತದೆ - ವರ್ಫ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗ ಅಥವಾ ವಿಮರ್ಶೆ ಬದ್ಧತೆಗೆ GitHub ಹುಕ್ ಅನ್ನು ಕರೆದಾಗ, ಬದಲಾದ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಅನುಗುಣವಾದ ಕಲಾಕೃತಿಯನ್ನು ಮಾತ್ರ ಮರುನಿರ್ಮಾಣ ಮಾಡಲಾಗುತ್ತದೆ.
  5. ಬಳಕೆಯಾಗದ ಚಿತ್ರಗಳನ್ನು ಅಳಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ: ವರ್ಫ್ ನೀತಿಗಳ ಪ್ರಕಾರ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಕ್ರಮವಾಗಿ ಇರಿಸುತ್ತದೆ.

ಸಂಶೋಧನೆಗಳು

  • werf ಅನ್ನು ಬಳಸುವುದರಿಂದ ಅಸೆಂಬ್ಲಿ ಸ್ವತಃ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದರಿಂದ ಮತ್ತು ಬಾಹ್ಯ ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದರಿಂದ ಅಸೆಂಬ್ಲಿ ತ್ವರಿತವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.
  • ಬಾಹ್ಯ Git ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ಪ್ರತಿ ಬಾರಿ ಸಂಪೂರ್ಣ ರೆಪೊಸಿಟರಿಯನ್ನು ಕ್ಲೋನ್ ಮಾಡುವ ಅಥವಾ ಟ್ರಿಕಿ ಆಪ್ಟಿಮೈಸೇಶನ್ ತರ್ಕದೊಂದಿಗೆ ಚಕ್ರವನ್ನು ಮರುಶೋಧಿಸುವ ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. werf ಸಂಗ್ರಹವನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೋನಿಂಗ್ ಅನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಬಳಸುತ್ತದೆ fetch ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ.
  • ಬಿಲ್ಡ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಗೋ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯ werf.yaml ಬಾಹ್ಯ ಡೇಟಾವನ್ನು ಅವಲಂಬಿಸಿರುವ ಅಸೆಂಬ್ಲಿಯನ್ನು ವಿವರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
  • ವರ್ಫ್‌ನಲ್ಲಿ ಮೌಂಟ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಕಲಾಕೃತಿಗಳ ಸಂಗ್ರಹಣೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ - ಸಂಗ್ರಹದಿಂದಾಗಿ, ಇದು ಎಲ್ಲಾ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ.
  • werf ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಇದು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ನಿರ್ಮಿಸುವಾಗ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ.

ಪಿಎಸ್

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

ಮೂಲ: www.habr.com

DDoS ರಕ್ಷಣೆ, VPS VDS ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸೈಟ್‌ಗಳಿಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ಖರೀದಿಸಿ 🔥 DDoS ರಕ್ಷಣೆ, VPS VDS ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ವಿಶ್ವಾಸಾರ್ಹ ವೆಬ್‌ಸೈಟ್ ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ಖರೀದಿಸಿ | ProHoster