werf - Kubernetes ನಲ್ಲಿ CI/CD ಗಾಗಿ ನಮ್ಮ ಸಾಧನ (ವಿಮರ್ಶೆ ಮತ್ತು ವೀಡಿಯೊ ವರದಿ)

ಮೇ 27 ರಂದು ಉತ್ಸವದ ಭಾಗವಾಗಿ ನಡೆದ DevOpsConf 2019 ಸಮ್ಮೇಳನದ ಮುಖ್ಯ ಸಭಾಂಗಣದಲ್ಲಿ RIT++ 2019, “ನಿರಂತರ ವಿತರಣೆ” ವಿಭಾಗದ ಭಾಗವಾಗಿ, “ವೆರ್ಫ್ - ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ CI/CD ಗಾಗಿ ನಮ್ಮ ಸಾಧನ” ಎಂಬ ವರದಿಯನ್ನು ನೀಡಲಾಗಿದೆ. ಅದು ಅವರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಯೋಜಿಸುವಾಗ ಪ್ರತಿಯೊಬ್ಬರೂ ಎದುರಿಸುವ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಸವಾಲುಗಳು, ಹಾಗೆಯೇ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳ ಬಗ್ಗೆ ತಕ್ಷಣವೇ ಗಮನಿಸುವುದಿಲ್ಲ. ಸಂಭವನೀಯ ಪರಿಹಾರಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ, ಓಪನ್ ಸೋರ್ಸ್ ಟೂಲ್‌ನಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ werf.

ಪ್ರಸ್ತುತಿಯ ನಂತರ, ನಮ್ಮ ಉಪಯುಕ್ತತೆ (ಹಿಂದೆ ಡಪ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತಿತ್ತು) ಐತಿಹಾಸಿಕ ಮೈಲಿಗಲ್ಲನ್ನು ತಲುಪಿದೆ GitHub ನಲ್ಲಿ 1000 ನಕ್ಷತ್ರಗಳು - ಅದರ ಬೆಳೆಯುತ್ತಿರುವ ಬಳಕೆದಾರರ ಸಮುದಾಯವು ಅನೇಕ DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ಆದ್ದರಿಂದ, ನಾವು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇವೆ ವರದಿಯ ವೀಡಿಯೊ (~47 ನಿಮಿಷಗಳು, ಲೇಖನಕ್ಕಿಂತ ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ) ಮತ್ತು ಪಠ್ಯ ರೂಪದಲ್ಲಿ ಅದರ ಮುಖ್ಯ ಸಾರ. ಹೋಗು!

ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಕೋಡ್ ಅನ್ನು ತಲುಪಿಸಲಾಗುತ್ತಿದೆ

ಚರ್ಚೆಯು ಇನ್ನು ಮುಂದೆ ವರ್ಫ್ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ CI/CD ಬಗ್ಗೆ, ನಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. (ನಾನು ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇನೆ 2016 ರ ವರದಿ), ಮತ್ತು K8s ಅನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಚಲಾಯಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ (ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು 2017 ವರ್ಷ).

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ವಿತರಣೆಯು ಹೇಗಿರುತ್ತದೆ?

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

ಇಲ್ಲಿ ಕೆಲವು ಪ್ರಮುಖ ಟಿಪ್ಪಣಿಗಳಿವೆ:

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

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

ವೇದಿಕೆಯನ್ನು ನಿರ್ಮಿಸಿ

ಡಾಕರ್‌ಫೈಲ್‌ಗಳನ್ನು ಬರೆಯುವುದು ಮತ್ತು ರನ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಎಲ್ಲರಿಗೂ ತಿಳಿದಿರುವಾಗ ನೀವು 2019 ರಲ್ಲಿ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡಬಹುದು ಎಂದು ತೋರುತ್ತದೆ. docker build?.. ನಾನು ಗಮನ ಕೊಡಲು ಬಯಸುವ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಇಲ್ಲಿವೆ:

1. ಚಿತ್ರದ ತೂಕ ವಿಷಯಗಳು, ಆದ್ದರಿಂದ ಬಳಸಿ ಬಹು-ಹಂತಕಾರ್ಯಾಚರಣೆಗೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮಾತ್ರ ಚಿತ್ರದಲ್ಲಿ ಬಿಡಲು.
2. ಪದರಗಳ ಸಂಖ್ಯೆ ನ ಸರಪಳಿಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ ಕಡಿಮೆಗೊಳಿಸಬೇಕು RUN-ಅರ್ಥದ ಪ್ರಕಾರ ಆಜ್ಞೆಗಳು.
3. ಆದಾಗ್ಯೂ, ಇದು ಸಮಸ್ಯೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ ಡೀಬಗ್ ಮಾಡುವುದು, ಏಕೆಂದರೆ ಅಸೆಂಬ್ಲಿ ಕ್ರ್ಯಾಶ್ ಆದಾಗ, ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡಿದ ಸರಪಳಿಯಿಂದ ನೀವು ಸರಿಯಾದ ಆಜ್ಞೆಯನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು.
4. ಅಸೆಂಬ್ಲಿ ವೇಗ ಮುಖ್ಯವಾದ ಕಾರಣ ನಾವು ಬದಲಾವಣೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಹೊರತರಲು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಪ್ರತಿ ಬಾರಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದಾಗ ಭಾಷಾ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಅವಲಂಬನೆಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ.
5. ಸಾಮಾನ್ಯವಾಗಿ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಒಂದು Git ರೆಪೊಸಿಟರಿಯಿಂದ ಅನೇಕ ಚಿತ್ರಗಳು, ಇದನ್ನು ಡಾಕರ್‌ಫೈಲ್‌ಗಳ ಸೆಟ್ (ಅಥವಾ ಒಂದು ಫೈಲ್‌ನಲ್ಲಿ ಹಂತಗಳನ್ನು ಹೆಸರಿಸಲಾಗಿದೆ) ಮತ್ತು ಅವುಗಳ ಅನುಕ್ರಮ ಜೋಡಣೆಯೊಂದಿಗೆ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ಪರಿಹರಿಸಬಹುದು.

ಇದು ಎಲ್ಲರೂ ಎದುರಿಸುತ್ತಿರುವ ಮಂಜುಗಡ್ಡೆಯ ತುದಿ ಮಾತ್ರ. ಆದರೆ ಇತರ ಸಮಸ್ಯೆಗಳಿವೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ:

1. ಆಗಾಗ್ಗೆ ಅಸೆಂಬ್ಲಿ ಹಂತದಲ್ಲಿ ನಮಗೆ ಏನಾದರೂ ಬೇಕು ಆರೋಹಣ (ಉದಾಹರಣೆಗೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ apt ನಂತಹ ಆಜ್ಞೆಯ ಫಲಿತಾಂಶವನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿ).
2. ನಮಗೆ ಬೇಕು ಅನುಕಂಪ ಶೆಲ್‌ನಲ್ಲಿ ಬರೆಯುವ ಬದಲು.
3. ನಮಗೆ ಬೇಕು ಡಾಕರ್ ಇಲ್ಲದೆ ನಿರ್ಮಿಸಿ (ನಮಗೆ ಹೆಚ್ಚುವರಿ ವರ್ಚುವಲ್ ಯಂತ್ರ ಏಕೆ ಬೇಕು, ಇದಕ್ಕಾಗಿ ನಾವು ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ, ನಾವು ಈಗಾಗಲೇ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಅದರಲ್ಲಿ ನಾವು ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು?).
4. ಸಮಾನಾಂತರ ಜೋಡಣೆ, ಇದನ್ನು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಅರ್ಥೈಸಿಕೊಳ್ಳಬಹುದು: ಡಾಕರ್‌ಫೈಲ್‌ನಿಂದ ವಿಭಿನ್ನ ಆಜ್ಞೆಗಳು (ಬಹು-ಹಂತವನ್ನು ಬಳಸಿದರೆ), ಒಂದೇ ರೆಪೊಸಿಟರಿಯ ಹಲವಾರು ಕಮಿಟ್‌ಗಳು, ಹಲವಾರು ಡಾಕರ್‌ಫೈಲ್‌ಗಳು.
5. ವಿತರಿಸಿದ ಅಸೆಂಬ್ಲಿ: ನಾವು ಏಕೆಂದರೆ "ಅಶಾಶ್ವತ" ಪಾಡ್‌ಗಳಲ್ಲಿ ವಸ್ತುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತೇವೆ ಅವರ ಸಂಗ್ರಹವು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ, ಅಂದರೆ ಅದನ್ನು ಎಲ್ಲೋ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ.
6. ಅಂತಿಮವಾಗಿ, ನಾನು ಆಸೆಗಳ ಪರಾಕಾಷ್ಠೆಯನ್ನು ಹೆಸರಿಸಿದೆ ಸ್ವಯಂಚಾಲಿತ: ರೆಪೊಸಿಟರಿಗೆ ಹೋಗಿ, ಕೆಲವು ಆಜ್ಞೆಯನ್ನು ಟೈಪ್ ಮಾಡಿ ಮತ್ತು ಹೇಗೆ ಮತ್ತು ಸರಿಯಾಗಿ ಏನು ಮಾಡಬೇಕೆಂಬುದರ ಬಗ್ಗೆ ತಿಳುವಳಿಕೆಯೊಂದಿಗೆ ಜೋಡಿಸಲಾದ ರೆಡಿಮೇಡ್ ಚಿತ್ರವನ್ನು ಪಡೆಯಲು ಇದು ಸೂಕ್ತವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಊಹಿಸಬಹುದೆಂದು ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಖಚಿತವಿಲ್ಲ.

ಮತ್ತು ಯೋಜನೆಗಳು ಇಲ್ಲಿವೆ:

• moby/buildkit - ಡಾಕರ್ ಇಂಕ್‌ನಿಂದ ಬಿಲ್ಡರ್ (ಈಗಾಗಲೇ ಡಾಕರ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ), ಇದು ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ;
• ಕಣಿಕೋ - ಡಾಕರ್ ಇಲ್ಲದೆ ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ Google ನಿಂದ ಬಿಲ್ಡರ್;
• Buildpacks.io - ಸ್ವಯಂಚಾಲಿತ ಮ್ಯಾಜಿಕ್ ಮಾಡಲು ಸಿಎನ್‌ಸಿಎಫ್‌ನ ಪ್ರಯತ್ನ ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ, ಲೇಯರ್‌ಗಳಿಗೆ ರಿಬೇಸ್‌ನೊಂದಿಗೆ ಆಸಕ್ತಿದಾಯಕ ಪರಿಹಾರ;
• ಮತ್ತು ಇತರ ಉಪಯುಕ್ತತೆಗಳ ಸಮೂಹ, ಉದಾಹರಣೆಗೆ ಬಿಲ್ಡಾ, genuinetools/img...

... ಮತ್ತು ಅವರು GitHub ನಲ್ಲಿ ಎಷ್ಟು ನಕ್ಷತ್ರಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆಂದು ನೋಡಿ. ಅಂದರೆ, ಒಂದು ಕಡೆ, docker build ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಏನನ್ನಾದರೂ ಮಾಡಬಹುದು, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸಲಾಗಿಲ್ಲ - ಇದಕ್ಕೆ ಪುರಾವೆ ಪರ್ಯಾಯ ಸಂಗ್ರಾಹಕರ ಸಮಾನಾಂತರ ಅಭಿವೃದ್ಧಿಯಾಗಿದೆ, ಪ್ರತಿಯೊಂದೂ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ವರ್ಫ್‌ನಲ್ಲಿ ಅಸೆಂಬ್ಲಿ

ಆದ್ದರಿಂದ ನಾವು ಸಿಕ್ಕಿತು werf (ಹಿಂದೆ ಖ್ಯಾತ ದಪ್ಪನಂತೆ) - ಫ್ಲಾಂಟ್ ಕಂಪನಿಯಿಂದ ತೆರೆದ ಮೂಲ ಉಪಯುಕ್ತತೆ, ನಾವು ಹಲವು ವರ್ಷಗಳಿಂದ ತಯಾರಿಸುತ್ತಿದ್ದೇವೆ. ಇದು ಎಲ್ಲಾ 5 ವರ್ಷಗಳ ಹಿಂದೆ ಡಾಕರ್‌ಫೈಲ್‌ಗಳ ಜೋಡಣೆಯನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು ಮತ್ತು ಕಳೆದ 3 ವರ್ಷಗಳಿಂದ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಅಭಿವೃದ್ಧಿಯನ್ನು ತನ್ನದೇ ಆದ ಜಿಟ್ ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಒಂದು ಯೋಜನೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ ಕೈಗೊಳ್ಳಲಾಗಿದೆ. (ಮೊದಲು ರೂಬಿಯಲ್ಲಿ, ಮತ್ತು ನಂತರ ಪುನಃ ಬರೆಯಲಾಗಿದೆ ಹೋಗಲು, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಮರುಹೆಸರಿಸಲಾಗಿದೆ). ವರ್ಫ್‌ನಲ್ಲಿ ಯಾವ ಅಸೆಂಬ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲಾಗುತ್ತದೆ?

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

ನೋಂದಾವಣೆಯಲ್ಲಿ ಪ್ರಕಟಣೆಯ ಹಂತ (ಪ್ರಕಟಣೆ)

ನಾವು ಡಯಲ್ ಮಾಡಿದೆವು docker push... - ನೋಂದಾವಣೆಗೆ ಚಿತ್ರವನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವಲ್ಲಿ ಏನು ಕಷ್ಟವಾಗಬಹುದು? ತದನಂತರ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: "ನಾನು ಚಿತ್ರದ ಮೇಲೆ ಯಾವ ಟ್ಯಾಗ್ ಅನ್ನು ಹಾಕಬೇಕು?" ನಾವು ಹೊಂದಿರುವ ಕಾರಣಕ್ಕಾಗಿ ಇದು ಉದ್ಭವಿಸುತ್ತದೆ ಗಿಟ್ಫ್ಲೋ (ಅಥವಾ ಇತರ Git ತಂತ್ರ) ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್, ಮತ್ತು ಉದ್ಯಮವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು Git ನಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ. ಎಲ್ಲಾ ನಂತರ, Git ಸತ್ಯದ ನಮ್ಮ ಏಕೈಕ ಮೂಲವಾಗಿದೆ.

ಇದರಲ್ಲಿ ಕಷ್ಟವೇನು? ಪುನರುತ್ಪಾದನೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ: Git ನಲ್ಲಿನ ಬದ್ಧತೆಯಿಂದ, ಇದು ಸ್ವಭಾವದಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ (ಮಾರಲಾಗದ), ಡಾಕರ್ ಚಿತ್ರಕ್ಕೆ, ಅದನ್ನು ಹಾಗೆಯೇ ಇಡಬೇಕು.

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

ಟ್ಯಾಗಿಂಗ್ ತಂತ್ರಗಳು

ಮೊದಲನೆಯದು ಸರಳವಾಗಿದೆ git ದಿನ. ಎಂದು ಟ್ಯಾಗ್ ಮಾಡಲಾದ ಚಿತ್ರವನ್ನು ಹೊಂದಿರುವ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ 1.0. ಕುಬರ್ನೆಟ್ಸ್ ಹಂತ ಮತ್ತು ನಿರ್ಮಾಣವನ್ನು ಹೊಂದಿದೆ, ಅಲ್ಲಿ ಈ ಚಿತ್ರವನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ. Git ನಲ್ಲಿ ನಾವು ಬದ್ಧತೆಗಳನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ ನಾವು ಟ್ಯಾಗ್ ಮಾಡುತ್ತೇವೆ 2.0. ರೆಪೊಸಿಟರಿಯಿಂದ ಸೂಚನೆಗಳ ಪ್ರಕಾರ ನಾವು ಅದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಟ್ಯಾಗ್ನೊಂದಿಗೆ ನೋಂದಾವಣೆಯಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ 2.0. ನಾವು ಅದನ್ನು ಹಂತಕ್ಕೆ ಸುತ್ತಿಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ನಂತರ ಉತ್ಪಾದನೆಗೆ.

ಈ ವಿಧಾನದ ಸಮಸ್ಯೆಯೆಂದರೆ ನಾವು ಮೊದಲು ಟ್ಯಾಗ್ ಅನ್ನು ಹಾಕಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಹೊರತೆಗೆದಿದ್ದೇವೆ. ಏಕೆ? ಮೊದಲನೆಯದಾಗಿ, ಇದು ಸರಳವಾಗಿ ತರ್ಕಬದ್ಧವಲ್ಲ: ನಾವು ಇನ್ನೂ ಪರೀಕ್ಷಿಸದ ಸಾಫ್ಟ್‌ವೇರ್ ಆವೃತ್ತಿಯನ್ನು ನಾವು ನೀಡುತ್ತಿದ್ದೇವೆ (ನಾವು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಪರಿಶೀಲಿಸಲು, ನಾವು ಟ್ಯಾಗ್ ಅನ್ನು ಹಾಕಬೇಕಾಗಿದೆ). ಎರಡನೆಯದಾಗಿ, ಈ ಮಾರ್ಗವು Gitflow ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಎರಡನೇ ಆಯ್ಕೆ - git ಕಮಿಟ್ + ಟ್ಯಾಗ್. ಮಾಸ್ಟರ್ ಶಾಖೆಗೆ ಟ್ಯಾಗ್ ಇದೆ 1.0; ಅದಕ್ಕಾಗಿ ನೋಂದಾವಣೆಯಲ್ಲಿ - ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಲಾದ ಚಿತ್ರ. ಜೊತೆಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಪೂರ್ವವೀಕ್ಷಣೆ ಮತ್ತು ವೇದಿಕೆಯ ಬಾಹ್ಯರೇಖೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮುಂದೆ ನಾವು Gitflow ಅನ್ನು ಅನುಸರಿಸುತ್ತೇವೆ: ಅಭಿವೃದ್ಧಿಗಾಗಿ ಮುಖ್ಯ ಶಾಖೆಯಲ್ಲಿ (develop) ನಾವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮಾಡುತ್ತೇವೆ, ಇದು ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ ಬದ್ಧತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ #c1. ನಾವು ಅದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನೋಂದಾವಣೆಯಲ್ಲಿ ಪ್ರಕಟಿಸುತ್ತೇವೆ (#c1) ಅದೇ ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ ನಾವು ಪೂರ್ವವೀಕ್ಷಣೆಗೆ ಹೊರಡುತ್ತೇವೆ. ಬದ್ಧತೆಗಳೊಂದಿಗೆ ನಾವು ಅದೇ ರೀತಿ ಮಾಡುತ್ತೇವೆ #c2 и #c3.

ಸಾಕಷ್ಟು ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಾಗ, ನಾವು ಎಲ್ಲವನ್ನೂ ಸ್ಥಿರಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. Git ನಲ್ಲಿ ಶಾಖೆಯನ್ನು ರಚಿಸಿ release_1.1 (ಆಧಾರದ ಮೇಲೆ #c3 ನಿಂದ develop) ಈ ಬಿಡುಗಡೆಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ... ಇದನ್ನು ಹಿಂದಿನ ಹಂತದಲ್ಲಿ ಮಾಡಲಾಯಿತು. ಆದ್ದರಿಂದ, ನಾವು ಅದನ್ನು ಸರಳವಾಗಿ ವೇದಿಕೆಗೆ ಸುತ್ತಿಕೊಳ್ಳಬಹುದು. ನಾವು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ #c4 ಮತ್ತು ಅದೇ ರೀತಿ ವೇದಿಕೆಗೆ ಹೊರಳಿಕೊಳ್ಳಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಭಿವೃದ್ಧಿ ನಡೆಯುತ್ತಿದೆ develop, ಬದಲಾವಣೆಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ release_1.1. ಕೆಲವು ಹಂತದಲ್ಲಿ, ನಾವು ಬದ್ಧತೆಯನ್ನು ಸಂಕಲಿಸುತ್ತೇವೆ ಮತ್ತು ಸ್ಟೇಜಿಂಗ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತೇವೆ, ಅದು ನಮಗೆ ಸಂತೋಷವಾಗಿದೆ (#c25).

ನಂತರ ನಾವು ಬಿಡುಗಡೆ ಶಾಖೆಯನ್ನು (ಫಾಸ್ಟ್-ಫಾರ್ವರ್ಡ್ನೊಂದಿಗೆ) ವಿಲೀನಗೊಳಿಸುತ್ತೇವೆ (release_1.1) ಮಾಸ್ಟರ್ ನಲ್ಲಿ. ಈ ಕಮಿಟ್‌ನಲ್ಲಿ ನಾವು ಹೊಸ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಟ್ಯಾಗ್ ಅನ್ನು ಹಾಕುತ್ತೇವೆ (1.1) ಆದರೆ ಈ ಚಿತ್ರವನ್ನು ಈಗಾಗಲೇ ನೋಂದಾವಣೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮತ್ತೆ ಸಂಗ್ರಹಿಸದಿರಲು, ನಾವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಚಿತ್ರಕ್ಕೆ ಎರಡನೇ ಟ್ಯಾಗ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ (ಈಗ ಅದು ನೋಂದಾವಣೆಯಲ್ಲಿ ಟ್ಯಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ #c25 и 1.1) ಅದರ ನಂತರ, ನಾವು ಅದನ್ನು ಉತ್ಪಾದನೆಗೆ ಸುತ್ತಿಕೊಳ್ಳುತ್ತೇವೆ.

ಕೇವಲ ಒಂದು ಚಿತ್ರವನ್ನು ವೇದಿಕೆಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಎಂಬ ನ್ಯೂನತೆಯಿದೆ (#c25), ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಇದು ವಿಭಿನ್ನವಾಗಿದೆ (1.1), ಆದರೆ "ದೈಹಿಕವಾಗಿ" ಇವುಗಳು ನೋಂದಾವಣೆಯಿಂದ ಒಂದೇ ಚಿತ್ರವೆಂದು ನಮಗೆ ತಿಳಿದಿದೆ.

ನಿಜವಾದ ಅನನುಕೂಲವೆಂದರೆ ವಿಲೀನ ಬದ್ಧತೆಗಳಿಗೆ ಯಾವುದೇ ಬೆಂಬಲವಿಲ್ಲ, ನೀವು ಫಾಸ್ಟ್-ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು.

ನಾವು ಮುಂದೆ ಹೋಗಿ ಒಂದು ಟ್ರಿಕ್ ಮಾಡಬಹುದು... ಸರಳವಾದ ಡಾಕರ್‌ಫೈಲ್‌ನ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ಕೆಳಗಿನ ತತ್ತ್ವದ ಪ್ರಕಾರ ಅದರಿಂದ ಫೈಲ್ ಅನ್ನು ನಿರ್ಮಿಸೋಣ:

• ಬಳಸಿದ ಚಿತ್ರಗಳ ಗುರುತಿಸುವಿಕೆಯಿಂದ SHA256 (ruby:2.3 и nginx:alpine), ಅವುಗಳ ವಿಷಯಗಳ ಚೆಕ್ಸಮ್ಗಳಾಗಿವೆ;
• ಎಲ್ಲಾ ತಂಡಗಳು (RUN, CMD ಮತ್ತು ಇತ್ಯಾದಿ.);
• ಸೇರಿಸಲಾದ ಫೈಲ್‌ಗಳಿಂದ SHA256.

... ಮತ್ತು ಅಂತಹ ಫೈಲ್‌ನಿಂದ ಚೆಕ್‌ಸಮ್ (ಮತ್ತೆ SHA256) ತೆಗೆದುಕೊಳ್ಳಿ. ಈ ಸಹಿ ಡಾಕರ್ ಚಿತ್ರದ ವಿಷಯಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಎಲ್ಲವೂ.

ರೇಖಾಚಿತ್ರಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ ಮತ್ತು ಬದ್ಧತೆಗಳ ಬದಲಿಗೆ ನಾವು ಅಂತಹ ಸಹಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಅಂದರೆ ಸಹಿಗಳೊಂದಿಗೆ ಚಿತ್ರಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡಿ.

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

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

ವರ್ಫ್‌ನಲ್ಲಿ ಟ್ಯಾಗ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ವರ್ಫ್‌ನಲ್ಲಿ ನಾವು ಇನ್ನೂ ಮುಂದೆ ಹೋದೆವು ಮತ್ತು ಒಂದು ಗಣಕದಲ್ಲಿ ಸಂಗ್ರಹಿಸದ ಸಂಗ್ರಹದೊಂದಿಗೆ ವಿತರಣಾ ನಿರ್ಮಾಣವನ್ನು ಮಾಡಲು ತಯಾರಿ ನಡೆಸುತ್ತಿದ್ದೇವೆ ... ಆದ್ದರಿಂದ, ನಾವು ಎರಡು ರೀತಿಯ ಡಾಕರ್ ಚಿತ್ರಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ, ನಾವು ಅವುಗಳನ್ನು ಕರೆಯುತ್ತೇವೆ ಹಂತ и ಚಿತ್ರ.

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

ಇದರ ನಂತರ ಹೊಸ ಕಮಿಟ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಅದರಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಲಾಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ. ಏನಾಗುವುದೆಂದು? ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಗಾಗಿ, ಪ್ಯಾಚ್ ಅನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಹಂತದ ಚಿತ್ರವನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತದೆ. ಅದರ ಸಹಿಯನ್ನು ಹಳೆಯ ಹಂತದ ಚಿತ್ರ ಮತ್ತು ಹೊಸ ಪ್ಯಾಚ್‌ನ ಚೆಕ್‌ಸಮ್ ಎಂದು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ಈ ಚಿತ್ರದಿಂದ ಹೊಸ ಅಂತಿಮ ಚಿತ್ರ ರಚನೆಯಾಗುತ್ತದೆ. ಇತರ ಹಂತಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಇದೇ ರೀತಿಯ ನಡವಳಿಕೆಯು ಸಂಭವಿಸುತ್ತದೆ.

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

ನೋಂದಾವಣೆ ಸ್ವಚ್ಛಗೊಳಿಸುವುದು

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

ಶುಚಿಗೊಳಿಸುವ ತಂತ್ರಗಳು ಯಾವುವು?

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

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

ನಾವು ಯಾವುದಕ್ಕೆ ಬಂದಿದ್ದೇವೆ werf? ನಾವು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ:

1. Git head: ಎಲ್ಲಾ ಟ್ಯಾಗ್‌ಗಳು, ಎಲ್ಲಾ ಶಾಖೆಗಳು - ಚಿತ್ರಗಳಲ್ಲಿ Git ನಲ್ಲಿ ಟ್ಯಾಗ್ ಮಾಡಲಾದ ಎಲ್ಲವೂ ನಮಗೆ ಬೇಕು ಎಂದು ಊಹಿಸಿ (ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ಅದನ್ನು Git ನಲ್ಲಿಯೇ ಅಳಿಸಬೇಕಾಗಿದೆ);
2. ಪ್ರಸ್ತುತ ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಪಂಪ್ ಮಾಡಲಾದ ಎಲ್ಲಾ ಬೀಜಕೋಶಗಳು;
3. ಹಳೆಯ ರೆಪ್ಲಿಕಾಸೆಟ್‌ಗಳು (ಇತ್ತೀಚೆಗೆ ಬಿಡುಗಡೆಯಾದವು), ಮತ್ತು ನಾವು ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲು ಮತ್ತು ಅಲ್ಲಿ ಇತ್ತೀಚಿನ ಚಿತ್ರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಯೋಜಿಸುತ್ತೇವೆ.

... ಮತ್ತು ಈ ಸೆಟ್‌ನಿಂದ ಶ್ವೇತಪಟ್ಟಿಯನ್ನು ಮಾಡಿ - ನಾವು ಅಳಿಸದ ಚಿತ್ರಗಳ ಪಟ್ಟಿ. ನಾವು ಎಲ್ಲವನ್ನೂ ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತೇವೆ, ಅದರ ನಂತರ ನಾವು ಅನಾಥ ಹಂತದ ಚಿತ್ರಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅಳಿಸುತ್ತೇವೆ.

ಹಂತವನ್ನು ನಿಯೋಜಿಸಿ

ವಿಶ್ವಾಸಾರ್ಹ ಘೋಷಣೆ

ನಿಯೋಜನೆಯಲ್ಲಿ ನಾನು ಗಮನ ಸೆಳೆಯಲು ಬಯಸುವ ಮೊದಲ ಅಂಶವೆಂದರೆ ಘೋಷಣಾತ್ಮಕವಾಗಿ ಘೋಷಿಸಲಾದ ನವೀಕರಿಸಿದ ಸಂಪನ್ಮೂಲ ಸಂರಚನೆಯ ರೋಲ್ಔಟ್. Kubernetes ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿವರಿಸುವ ಮೂಲ YAML ಡಾಕ್ಯುಮೆಂಟ್ ಯಾವಾಗಲೂ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಫಲಿತಾಂಶಕ್ಕಿಂತ ಬಹಳ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಸಂರಚನೆಗೆ ಸೇರಿಸುತ್ತಾನೆ:

1. ಗುರುತಿಸುವಿಕೆಗಳು;
2. ಸೇವಾ ಮಾಹಿತಿ;
3. ಅನೇಕ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು;
4. ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯೊಂದಿಗೆ ವಿಭಾಗ;
5. ಪ್ರವೇಶ ವೆಬ್‌ಹೂಕ್‌ನ ಭಾಗವಾಗಿ ಮಾಡಿದ ಬದಲಾವಣೆಗಳು;
6. ವಿವಿಧ ನಿಯಂತ್ರಕಗಳ (ಮತ್ತು ಶೆಡ್ಯೂಲರ್) ಕೆಲಸದ ಫಲಿತಾಂಶ.

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

ಈ ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ 2-ವೇ ವಿಲೀನ. ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಹೆಲ್ಮ್ನಲ್ಲಿ.

ಕೂಡ ಇದೆ 3-ವೇ ವಿಲೀನ, ಅದರಲ್ಲಿ ಭಿನ್ನವಾಗಿದೆ:

• ಹೋಲಿಸುವುದು ಕೊನೆಯದಾಗಿ ಅನ್ವಯಿಸಲಾಗಿದೆ и ಹೊಸ, ಏನು ಅಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ;
• ಹೋಲಿಸುವುದು ಹೊಸ и ಲೈವ್, ಏನನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಅಥವಾ ಬದಲಾಯಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ;
• ಸಾರಾಂಶದ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ ಲೈವ್.

ನಾವು ಹೆಲ್ಮ್‌ನೊಂದಿಗೆ 1000+ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ನಿಜವಾಗಿಯೂ 2-ವೇ ವಿಲೀನದೊಂದಿಗೆ ವಾಸಿಸುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, ಇದು ನಮ್ಮ ಪ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ನಾವು ಪರಿಹರಿಸಿದ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ, ಇದು ಹೆಲ್ಮ್ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ನಿಜವಾದ ರೋಲ್ಔಟ್ ಸ್ಥಿತಿ

ಮುಂದಿನ ಈವೆಂಟ್‌ನ ಆಧಾರದ ಮೇಲೆ ನಮ್ಮ CI ಸಿಸ್ಟಮ್ ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ಅದು ಅದನ್ನು ಬಳಕೆಗೆ ರವಾನಿಸುತ್ತದೆ (ಅನ್ವಯಿಸು) ಒಂದು ಕ್ಲಸ್ಟರ್‌ಗೆ - ಹೆಲ್ಮ್ ಬಳಸಿ ಅಥವಾ kubectl apply. ಮುಂದೆ, ಈಗಾಗಲೇ ವಿವರಿಸಿದ N-ವೇ ವಿಲೀನವು ಸಂಭವಿಸುತ್ತದೆ, ಇದಕ್ಕೆ Kubernetes API CI ಸಿಸ್ಟಮ್‌ಗೆ ಮತ್ತು ಅದರ ಬಳಕೆದಾರರಿಗೆ ಅನುಮೋದಿಸುವಂತೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

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

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

ವರ್ಫ್ ಮಟ್ಟದಲ್ಲಿ ಈ ಟ್ರ್ಯಾಕರ್‌ನ ನಡವಳಿಕೆಯನ್ನು ನಿಯೋಜನೆಗಳು ಅಥವಾ ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳಲ್ಲಿ ಇರಿಸಲಾಗಿರುವ ಟಿಪ್ಪಣಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಮುಖ್ಯ ಟಿಪ್ಪಣಿ - fail-mode - ಕೆಳಗಿನ ಅರ್ಥಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ:

• IgnoreAndContinueDeployProcess - ಈ ಘಟಕವನ್ನು ರೋಲಿಂಗ್ ಮಾಡುವ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ನಿರ್ಲಕ್ಷಿಸುತ್ತೇವೆ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ;
• FailWholeDeployProcessImmediately - ಈ ಘಟಕದಲ್ಲಿನ ದೋಷವು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ;
• HopeUntilEndOfDeployProcess - ನಿಯೋಜನೆಯ ಅಂತ್ಯದ ವೇಳೆಗೆ ಈ ಘಟಕವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ಉದಾಹರಣೆಗೆ, ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಟಿಪ್ಪಣಿ ಮೌಲ್ಯಗಳ ಈ ಸಂಯೋಜನೆ fail-mode:

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

ವರ್ಫ್‌ನಲ್ಲಿ ಕುಬೆಡಾಗ್‌ಗೆ ಇನ್ನೂ ಎರಡು ಟಿಪ್ಪಣಿಗಳಿವೆ:

• failures-allowed-per-replica - ಪ್ರತಿ ಪ್ರತಿಕೃತಿಗೆ ಅನುಮತಿಸಲಾದ ಫಾಲ್ಸ್ ಸಂಖ್ಯೆ;
• show-logs-until - ಎಲ್ಲಾ ರೋಲ್ಡ್ ಔಟ್ ಪಾಡ್‌ಗಳಿಂದ (stdout ನಲ್ಲಿ) ಲಾಗ್‌ಗಳನ್ನು werf ತೋರಿಸುವ ಕ್ಷಣವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ PodIsReady (ಪಾಡ್‌ಗೆ ಸಂಚಾರ ಪ್ರಾರಂಭವಾದಾಗ ನಾವು ಬಯಸದ ಸಂದೇಶಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು), ಆದರೆ ಮೌಲ್ಯಗಳು ಸಹ ಮಾನ್ಯವಾಗಿರುತ್ತವೆ: ControllerIsReady и EndOfDeploy.

ನಿಯೋಜನೆಯಿಂದ ನಮಗೆ ಇನ್ನೇನು ಬೇಕು?

ಈಗಾಗಲೇ ವಿವರಿಸಿದ ಎರಡು ಅಂಶಗಳ ಜೊತೆಗೆ, ನಾವು ಬಯಸುತ್ತೇವೆ:

• ನೋಡಲು ದಾಖಲೆಗಳು - ಮತ್ತು ಅಗತ್ಯವಿರುವವುಗಳು ಮಾತ್ರ, ಮತ್ತು ಸತತವಾಗಿ ಎಲ್ಲವೂ ಅಲ್ಲ;
• ಟ್ರ್ಯಾಕ್ ಪ್ರಗತಿ, ಏಕೆಂದರೆ ಕೆಲಸವು ಹಲವಾರು ನಿಮಿಷಗಳ ಕಾಲ "ಮೌನವಾಗಿ" ಸ್ಥಗಿತಗೊಂಡರೆ, ಅಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮುಖ್ಯವಾಗಿದೆ;
• ಹೊಂದಿವೆ ಸ್ವಯಂಚಾಲಿತ ರೋಲ್ಬ್ಯಾಕ್ ಯಾವುದೋ ತಪ್ಪು ಸಂಭವಿಸಿದಲ್ಲಿ (ಮತ್ತು ಆದ್ದರಿಂದ ನಿಯೋಜನೆಯ ನೈಜ ಸ್ಥಿತಿಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ). ರೋಲ್ಔಟ್ ಪರಮಾಣು ಆಗಿರಬೇಕು: ಒಂದೋ ಅದು ಕೊನೆಯವರೆಗೂ ಹೋಗುತ್ತದೆ, ಅಥವಾ ಎಲ್ಲವೂ ಅದರ ಹಿಂದಿನ ಸ್ಥಿತಿಗೆ ಮರಳುತ್ತದೆ.

ಫಲಿತಾಂಶಗಳು

ಕಂಪನಿಯಾಗಿ ನಮಗೆ, ವಿತರಣೆಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ವಿವರಿಸಿದ ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು (ನಿರ್ಮಿಸಲು, ಪ್ರಕಟಿಸಿ, ನಿಯೋಜಿಸಲು), CI ವ್ಯವಸ್ಥೆ ಮತ್ತು ಉಪಯುಕ್ತತೆ ಸಾಕು. werf.

ತೀರ್ಮಾನಕ್ಕೆ ಬದಲಾಗಿ:

werf ಸಹಾಯದಿಂದ, DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ನಾವು ಉತ್ತಮ ಪ್ರಗತಿಯನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ ಮತ್ತು ವಿಶಾಲ ಸಮುದಾಯವು ಕನಿಷ್ಠ ಈ ಉಪಯುಕ್ತತೆಯನ್ನು ಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ರಯತ್ನಿಸಿದರೆ ಸಂತೋಷವಾಗುತ್ತದೆ. ಒಟ್ಟಿಗೆ ಉತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ.

ವೀಡಿಯೊಗಳು ಮತ್ತು ಸ್ಲೈಡ್‌ಗಳು

ಪ್ರದರ್ಶನದಿಂದ ವೀಡಿಯೊ (~47 ನಿಮಿಷಗಳು):

ವರದಿಯ ಮಂಡನೆ:

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಕುರಿತು ಇತರ ವರದಿಗಳು:

• «ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಏಪ್ರಿಲ್ 27, 2019 "ಸ್ಟ್ರೈಕ್" ನಲ್ಲಿ);
• «ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದು ಮತ್ತು ಪೂರಕಗೊಳಿಸುವುದು» (ಆಂಡ್ರೆ ಪೊಲೊವೊವ್; ಏಪ್ರಿಲ್ 8, 2019 ಸೇಂಟ್ ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಡೇಟಾಬೇಸ್‌ಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 8, 2018 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಮೇ 28, 2018 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ);
• «ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು GitLab ನೊಂದಿಗೆ CI/CD ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 7, 2017 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಸಣ್ಣ ಯೋಜನೆಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆಗಿನ ನಮ್ಮ ಅನುಭವ» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಜೂನ್ 6, 2017 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ).

ಮೂಲ: www.habr.com