ಸೂಚನೆ. ಅನುವಾದ.: ಇತ್ತೀಚಿನ ಪ್ರಕಟಣೆಯ ನಂತರ GitOps ನಲ್ಲಿ ಪುಲ್ ಮತ್ತು ಪುಶ್ ವಿಧಾನಗಳ ಬಗ್ಗೆ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಮಾದರಿಯಲ್ಲಿ ಆಸಕ್ತಿಯನ್ನು ನೋಡಿದ್ದೇವೆ, ಆದರೆ ಈ ವಿಷಯದ ಬಗ್ಗೆ ಕೆಲವೇ ಕೆಲವು ರಷ್ಯನ್ ಭಾಷೆಯ ಪ್ರಕಟಣೆಗಳು ಇದ್ದವು (ಹಬ್ರೆಯಲ್ಲಿ ಸರಳವಾಗಿ ಯಾವುದೂ ಇಲ್ಲ). ಆದ್ದರಿಂದ, ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಮತ್ತೊಂದು ಲೇಖನದ ಅನುವಾದವನ್ನು ನೀಡಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ - ಸುಮಾರು ಒಂದು ವರ್ಷದ ಹಿಂದೆ! - ವೀವ್‌ವರ್ಕ್ಸ್‌ನಿಂದ, ಅದರ ಮುಖ್ಯಸ್ಥರು "GitOps" ಎಂಬ ಪದವನ್ನು ರಚಿಸಿದ್ದಾರೆ. ಪಠ್ಯವು ವಿಧಾನದ ಸಾರ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳಿಂದ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಒಂದು ವರ್ಷದ ಹಿಂದೆ ನಾವು ಪ್ರಕಟಿಸಿದ್ದೇವೆ . ಆಗ, Weaveworks ತಂಡವು ಸಂಪೂರ್ಣವಾಗಿ Kubernetes ಅನ್ನು ಆಧರಿಸಿ SaaS ಅನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಿತು ಮತ್ತು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜಿಸಲು, ನಿರ್ವಹಿಸುವುದಕ್ಕಾಗಿ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಪ್ರಿಸ್ಕ್ರಿಪ್ಟಿವ್ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳ ಗುಂಪನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ ಎಂಬುದನ್ನು ನಾವು ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ.
ಲೇಖನವು ಜನಪ್ರಿಯವಾಯಿತು. ಇತರ ಜನರು GitOps ಕುರಿತು ಮಾತನಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು ಮತ್ತು ಹೊಸ ಪರಿಕರಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು , , , , ಮತ್ತು ಇತ್ಯಾದಿ. ನಮ್ಮ ವೆಬ್‌ಸೈಟ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ ಪ್ರಕಟಣೆಗಳು ಮತ್ತು GitOps ಬಳಕೆಯ ಪ್ರಕರಣಗಳು. ಆದರೆ ಕೆಲವರಿಗೆ ಇನ್ನೂ ಪ್ರಶ್ನೆಗಳಿವೆ. ಮಾದರಿಯು ಸಾಂಪ್ರದಾಯಿಕದಿಂದ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ? ಮತ್ತು ನಿರಂತರ ವಿತರಣೆ ()? ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವುದು ಅಗತ್ಯವೇ?
ಹೊಸ ವಿವರಣೆಯ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಶೀಘ್ರದಲ್ಲೇ ಅರಿತುಕೊಂಡೆವು:
- ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಉದಾಹರಣೆಗಳು ಮತ್ತು ಕಥೆಗಳು;
- GitOps ನ ನಿರ್ದಿಷ್ಟ ವ್ಯಾಖ್ಯಾನ;
- ಸಾಂಪ್ರದಾಯಿಕ ನಿರಂತರ ವಿತರಣೆಯೊಂದಿಗೆ ಹೋಲಿಕೆ.
ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಈ ಎಲ್ಲಾ ವಿಷಯಗಳನ್ನು ಒಳಗೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಇದು GitOps ಮತ್ತು ಡೆವಲಪರ್ ಮತ್ತು CI/CD ದೃಷ್ಟಿಕೋನಕ್ಕೆ ನವೀಕರಿಸಿದ ಪರಿಚಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮಾದರಿಯನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಬಹುದಾದರೂ ನಾವು ಪ್ರಾಥಮಿಕವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ.
GitOps ಅನ್ನು ಭೇಟಿ ಮಾಡಿ
ಆಲಿಸ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಅವರು ಕೌಟುಂಬಿಕ ವಿಮೆಯನ್ನು ನಡೆಸುತ್ತಿದ್ದಾರೆ, ಇದು ಆರೋಗ್ಯ, ವಾಹನ, ಮನೆ ಮತ್ತು ಪ್ರಯಾಣ ವಿಮೆಯನ್ನು ನೀಡುತ್ತದೆ, ಇದು ಒಪ್ಪಂದಗಳ ಒಳ ಮತ್ತು ಹೊರಗನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ತುಂಬಾ ಕಾರ್ಯನಿರತವಾಗಿದೆ. ಆಲಿಸ್ ಬ್ಯಾಂಕಿನಲ್ಲಿ ಡೇಟಾ ಸೈಂಟಿಸ್ಟ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾಗ ಅವಳ ವ್ಯವಹಾರವು ಪಕ್ಕದ ಯೋಜನೆಯಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು. ಒಂದು ದಿನ ಅವಳು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ವಿಮಾ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ರೂಪಿಸಲು ಸುಧಾರಿತ ಕಂಪ್ಯೂಟರ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಬಹುದೆಂದು ಅರಿತುಕೊಂಡಳು. ಹೂಡಿಕೆದಾರರು ಯೋಜನೆಗೆ ಹಣಕಾಸು ಒದಗಿಸಿದರು, ಮತ್ತು ಈಗ ಅವರ ಕಂಪನಿಯು ವರ್ಷಕ್ಕೆ $20 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಆದಾಯವನ್ನು ತರುತ್ತದೆ ಮತ್ತು ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ. ಪ್ರಸ್ತುತ, ಇದು ವಿವಿಧ ಹುದ್ದೆಗಳಲ್ಲಿ 180 ಜನರನ್ನು ನೇಮಿಸಿಕೊಂಡಿದೆ. ಇದು ವೆಬ್‌ಸೈಟ್, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ, ನಿರ್ವಹಿಸುವ ಮತ್ತು ಗ್ರಾಹಕರ ನೆಲೆಯನ್ನು ವಿಶ್ಲೇಷಿಸುವ ತಂತ್ರಜ್ಞಾನ ತಂಡವನ್ನು ಒಳಗೊಂಡಿದೆ. 60 ಜನರ ತಂಡವನ್ನು ಕಂಪನಿಯ ತಾಂತ್ರಿಕ ನಿರ್ದೇಶಕ ಬಾಬ್ ನೇತೃತ್ವ ವಹಿಸಿದ್ದಾರೆ.
ಬಾಬ್ ತಂಡವು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಅವರ ಪ್ರಮುಖ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು GKE ನಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ, Google Cloud ನಲ್ಲಿ Kubernetes ನ ಲಾಭವನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತವೆ. ಜೊತೆಗೆ, ಅವರು ತಮ್ಮ ಕೆಲಸದಲ್ಲಿ ವಿವಿಧ ಡೇಟಾ ಮತ್ತು ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತಾರೆ.
ಫ್ಯಾಮಿಲಿ ಇನ್ಶೂರೆನ್ಸ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸಲು ಮುಂದಾಗಲಿಲ್ಲ, ಆದರೆ ಡಾಕರ್ ಉತ್ಸಾಹದಲ್ಲಿ ಸಿಕ್ಕಿಹಾಕಿಕೊಂಡಿತು. ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು GKE ಸುಲಭಗೊಳಿಸಿದೆ ಎಂದು ಕಂಪನಿಯು ಶೀಘ್ರದಲ್ಲೇ ಕಂಡುಹಿಡಿದಿದೆ. ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಸಂಘಟಿಸಲು CI ಮತ್ತು ಕ್ವೇಗಾಗಿ ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಸೇರಿಸಲಾಯಿತು, ಜೆಂಕಿನ್ಸ್‌ಗಾಗಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲಾಯಿತು ಅದು ಹೊಸ ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು GKE ಗೆ ತಳ್ಳಿತು.
ಸ್ವಲ್ಪ ಸಮಯ ಕಳೆದಿದೆ. ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ ಅವರು ಆಯ್ಕೆ ಮಾಡಿದ ವಿಧಾನದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವ್ಯಾಪಾರದ ಮೇಲೆ ಅದರ ಪ್ರಭಾವದಿಂದ ನಿರಾಶೆಗೊಂಡರು. ಕಂಟೈನರ್‌ಗಳ ಪರಿಚಯವು ತಂಡವು ನಿರೀಕ್ಷಿಸಿದಷ್ಟು ಉತ್ಪಾದಕತೆಯನ್ನು ಸುಧಾರಿಸಲಿಲ್ಲ. ಕೆಲವೊಮ್ಮೆ ನಿಯೋಜನೆಗಳು ಮುರಿಯುತ್ತವೆ ಮತ್ತು ಕೋಡ್ ಬದಲಾವಣೆಗಳು ಕಾರಣವೇ ಎಂಬುದು ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಸಂರಚನಾ ಬದಲಾವಣೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಸಹ ಕಷ್ಟಕರವಾಗಿದೆ. ಸಿಸ್ಟಮ್ ಆಗಿರುವ ಅವ್ಯವಸ್ಥೆಯನ್ನು ತೊಡೆದುಹಾಕಲು ಇದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿರುವುದರಿಂದ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ಮತ್ತು ಅದಕ್ಕೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸರಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದಂತೆ ಪರಿಸ್ಥಿತಿಯು ಹದಗೆಡುತ್ತದೆ ಎಂದು ಆಲಿಸ್ ಹೆದರುತ್ತಿದ್ದರು (ಜೊತೆಗೆ, ಯಂತ್ರ ಕಲಿಕೆಯ ಆಧಾರದ ಮೇಲೆ ಹೊಸ ಯೋಜನೆಯು ತಯಾರಿಸುತ್ತಿದೆ). ಬಾಬ್ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದ್ದಾನೆ ಮತ್ತು ಪೈಪ್ಲೈನ್ ಇನ್ನೂ ಅಸ್ಥಿರವಾಗಿದೆ, ಚೆನ್ನಾಗಿ ಅಳೆಯಲಿಲ್ಲ ಮತ್ತು ನಿಯತಕಾಲಿಕವಾಗಿ ಕೈಯಿಂದ ಮಧ್ಯಸ್ಥಿಕೆ ಅಗತ್ಯ ಏಕೆ ಎಂದು ಅರ್ಥವಾಗಲಿಲ್ಲ?
ನಂತರ ಅವರು GitOps ಬಗ್ಗೆ ಕಲಿತರು. ಈ ನಿರ್ಧಾರವು ಅವರು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಮುಂದುವರಿಯಲು ನಿಖರವಾಗಿ ಏನಾಯಿತು.
ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ Git, DevOps ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳ ಬಗ್ಗೆ ಕೋಡ್ ವರ್ಕ್‌ಫ್ಲೋಗಳಂತೆ ವರ್ಷಗಳಿಂದ ಕೇಳುತ್ತಿದ್ದಾರೆ. GitOps ನ ವಿಶಿಷ್ಟತೆ ಏನೆಂದರೆ, ಇದು ಕುಬರ್ನೆಟ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಈ ಆಲೋಚನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು-ನಿರ್ಣಾಯಕ ಮತ್ತು ಪ್ರಮಾಣಕ-ಎರಡೂ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ತರುತ್ತದೆ. ಈ ಥೀಮ್ , ಸೇರಿದಂತೆ .
ಕುಟುಂಬ ವಿಮೆಯು GitOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕಂಪನಿಯು ಈಗ ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯಾಚರಣೆಯ ಮಾದರಿಯನ್ನು ಹೊಂದಿದೆ, ಅದು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಸಂಯೋಜಿಸುತ್ತದೆ ವೇಗದ ರಿಂದ ಸ್ಥಿರತೆಏಕೆಂದರೆ ಅವರು:
- ಯಾರೂ ಹುಚ್ಚರಾಗದೆ ತಂಡದ ಉತ್ಪಾದಕತೆ ದ್ವಿಗುಣಗೊಂಡಿದೆ ಎಂದು ಕಂಡುಕೊಂಡರು;
- ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ನೀಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ. ಬದಲಿಗೆ, ಅವರು ಈಗ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬಹುದು ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಸುಧಾರಿಸಬಹುದು - ಉದಾಹರಣೆಗೆ, ಕ್ಯಾನರಿ ರೋಲ್‌ಔಟ್‌ಗಳನ್ನು ಅಳವಡಿಸುವುದು ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ಸುಧಾರಿಸುವುದು;
- ನಾವು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಧಾರಿಸಿದ್ದೇವೆ ಇದರಿಂದ ಅದು ವಿರಳವಾಗಿ ಒಡೆಯುತ್ತದೆ;
- ಹಸ್ತಚಾಲಿತ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಭಾಗಶಃ ವೈಫಲ್ಯಗಳ ನಂತರ ನಿಯೋಜನೆಗಳನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಅವಕಾಶ ಸಿಕ್ಕಿತು;
- ಬಳಸಿ ಖರೀದಿಸಲಾಗಿದೆоವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿಶ್ವಾಸ. ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ ಅವರು ತಂಡವನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ತಂಡಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು ಎಂದು ಕಂಡುಹಿಡಿದರು;
- ಪ್ರತಿ ಗುಂಪಿನ ಪ್ರಯತ್ನಗಳ ಮೂಲಕ ಪ್ರತಿದಿನ ಯೋಜನೆಗೆ 30-50 ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಹೊಸ ತಂತ್ರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು;
- ಹೊಸ ಡೆವಲಪರ್‌ಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಆಕರ್ಷಿಸುವುದು ಸುಲಭ, ಅವರು ಕೆಲವೇ ಗಂಟೆಗಳಲ್ಲಿ ಪುಲ್ ವಿನಂತಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಉತ್ಪಾದನೆಗೆ ನವೀಕರಣಗಳನ್ನು ಹೊರತರಲು ಅವಕಾಶವನ್ನು ಹೊಂದಿದ್ದಾರೆ;
- SOC2 ಚೌಕಟ್ಟಿನೊಳಗೆ ಸುಲಭವಾಗಿ ಆಡಿಟ್ ಪಾಸ್ (ಸುರಕ್ಷಿತ ಡೇಟಾ ನಿರ್ವಹಣೆಯ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಸೇವಾ ಪೂರೈಕೆದಾರರ ಅನುಸರಣೆಗಾಗಿ; ಹೆಚ್ಚು ಓದಿ, ಉದಾಹರಣೆಗೆ, - ಅಂದಾಜು ಅನುವಾದ.).
ಏನಾಯಿತು?
GitOps ಎರಡು ವಿಷಯಗಳು:
- ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯರಿಗೆ ಕಾರ್ಯಾಚರಣೆಯ ಮಾದರಿ. ಕಂಟೈನರೈಸ್ಡ್ ಕ್ಲಸ್ಟರ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು, ನಿರ್ವಹಿಸಲು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಇದು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳ ಗುಂಪನ್ನು ಒದಗಿಸುತ್ತದೆ. ರೂಪದಲ್ಲಿ ಸೊಗಸಾದ ವ್ಯಾಖ್ಯಾನ ರಿಂದ :
- ಡೆವಲಪರ್-ಕೇಂದ್ರಿತ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಣೆ ಪರಿಸರವನ್ನು ರಚಿಸುವ ಮಾರ್ಗ. ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಎರಡಕ್ಕೂ ನಾವು Git ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತೇವೆ. ಇದು ಕೇವಲ Git ಪುಶ್ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ CI/CD ಮತ್ತು UI/UX ಪರಿಕರಗಳ ಸಂಪೂರ್ಣ ಸೆಟ್ ಅನ್ನು ಸಂಘಟಿಸುವ ಬಗ್ಗೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ.
Git ಬಗ್ಗೆ ಕೆಲವು ಮಾತುಗಳು
ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು Git-ಆಧಾರಿತ ಕೆಲಸದ ಹರಿವು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಅವುಗಳ ಬಗ್ಗೆ ಕಲಿಯಲು ನಾವು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಶಾಖೆಗಳು ಮತ್ತು ಪುಲ್ ವಿನಂತಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಮೊದಲಿಗೆ ಕಪ್ಪು ಮ್ಯಾಜಿಕ್ನಂತೆ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಪ್ರಯೋಜನಗಳು ಪ್ರಯತ್ನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿವೆ. ಇಲ್ಲಿ ಆರಂಭಿಸಲು.
ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
ನಮ್ಮ ಕಥೆಯಲ್ಲಿ, ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆ ಕೆಲಸ ಮಾಡಿದ ನಂತರ GitOps ಗೆ ತಿರುಗಿದರು. ವಾಸ್ತವವಾಗಿ, GitOps ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ನಿಕಟ ಸಂಬಂಧ ಹೊಂದಿದೆ - ಇದು ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ಆಧರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಕಾರ್ಯಾಚರಣೆಯ ಮಾದರಿಯಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಬಳಕೆದಾರರಿಗೆ ಏನು ನೀಡುತ್ತದೆ?
ಕೆಲವು ಮುಖ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳು ಇಲ್ಲಿವೆ:
- ಕುಬರ್ನೆಟ್ಸ್ ಮಾದರಿಯಲ್ಲಿ, ಎಲ್ಲವನ್ನೂ ಘೋಷಣಾ ರೂಪದಲ್ಲಿ ವಿವರಿಸಬಹುದು.
- ಕುಬರ್ನೆಟ್ಸ್ API ಸರ್ವರ್ ಈ ಘೋಷಣೆಯನ್ನು ಇನ್‌ಪುಟ್ ಆಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಂತರ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಘೋಷಣೆಯಲ್ಲಿ ವಿವರಿಸಿದ ಸ್ಥಿತಿಗೆ ತರಲು ನಿರಂತರವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
- ವಿವಿಧ ರೀತಿಯ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ವಿವರಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಘೋಷಣೆಗಳು ಸಾಕಾಗುತ್ತದೆ-"ಅಪ್ಲಿಕೇಶನ್‌ಗಳು."
- ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳು ಈ ಕಾರಣದಿಂದಾಗಿ ಸಂಭವಿಸುತ್ತವೆ:
- ಕಂಟೇನರ್ ಚಿತ್ರಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳು;
- ಘೋಷಣಾತ್ಮಕ ವಿವರಣೆಗೆ ಬದಲಾವಣೆಗಳು;
- ಪರಿಸರದಲ್ಲಿ ದೋಷಗಳು - ಉದಾಹರಣೆಗೆ, ಕಂಟೇನರ್ ಕ್ರ್ಯಾಶ್ಗಳು.
ಕುಬರ್ನೆಟ್ಸ್ನ ಮಹಾನ್ ಒಮ್ಮುಖ ಸಾಮರ್ಥ್ಯಗಳು
ನಿರ್ವಾಹಕರು ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ, ಕುಬರ್ನೆಟ್ಸ್ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅದರ ಸ್ಥಿತಿ ಇರುವವರೆಗೆ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಹೊಸ ಸಂರಚನೆಯ ಹತ್ತಿರ ಬರುವುದಿಲ್ಲ. ಈ ಮಾದರಿಯು ಯಾವುದೇ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನಗಳೊಂದಿಗೆ (CRDs) ವಿಸ್ತರಿಸಬಹುದಾಗಿದೆ. ಆದ್ದರಿಂದ, ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆಗಳು ಈ ಕೆಳಗಿನ ಅದ್ಭುತ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ:
- ಆಟೊಮೇಷನ್: ಕುಬರ್ನೆಟ್ಸ್ ನವೀಕರಣಗಳು ಬದಲಾವಣೆಗಳನ್ನು ಆಕರ್ಷಕವಾಗಿ ಮತ್ತು ಸಮಯೋಚಿತವಾಗಿ ಅನ್ವಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತವೆ.
- ಒಮ್ಮುಖ: ಕುಬರ್ನೆಟ್ಸ್ ಯಶಸ್ವಿಯಾಗುವವರೆಗೆ ನವೀಕರಣಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
- ಐಡೆಂಪೊಟೆನ್ಸಿ: ಒಮ್ಮುಖದ ಪುನರಾವರ್ತಿತ ಅನ್ವಯಗಳು ಅದೇ ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ.
- ನಿರ್ಣಯವಾದ: ಸಂಪನ್ಮೂಲಗಳು ಸಾಕಷ್ಟಿರುವಾಗ, ನವೀಕರಿಸಿದ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯು ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಅವಲಂಬಿಸಿರುತ್ತದೆ.
GitOps ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
GitOps ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಕಲಿತಿದ್ದೇವೆ.
ಕುಟುಂಬ ವಿಮೆಯ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ತಂಡಗಳಿಗೆ ಹಿಂತಿರುಗೋಣ. ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಮಾಡಬೇಕು? ಕೆಳಗಿನ ಪಟ್ಟಿಯನ್ನು ನೋಡಿ (ಅದರಲ್ಲಿರುವ ಯಾವುದೇ ಐಟಂಗಳು ವಿಚಿತ್ರ ಅಥವಾ ಪರಿಚಯವಿಲ್ಲದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಟೀಕೆಗಳನ್ನು ತಡೆದುಕೊಳ್ಳಿ ಮತ್ತು ನಮ್ಮೊಂದಿಗೆ ಇರಿ). ಇವು ಜೆಂಕಿನ್ಸ್ ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋಗಳ ಉದಾಹರಣೆಗಳಾಗಿವೆ. ಇತರ ಸಾಧನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಅನೇಕ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳಿವೆ.
ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಪ್ರತಿ ನವೀಕರಣವು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು ಮತ್ತು Git ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. Git ಗೆ ಈ ಬದಲಾವಣೆಗಳು "GitOps ಆಪರೇಟರ್" ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸಲು ಕಾರಣವಾಗುತ್ತವೆ:
1.ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆ: "ಜೆಂಕಿನ್ಸ್ ನಿರ್ಮಿಸಲು - ಮಾಸ್ಟರ್ ಶಾಖೆ».
ಕಾರ್ಯ ಪಟ್ಟಿ:
- ಜೆಂಕಿನ್ಸ್ ಟ್ಯಾಗ್ ಮಾಡಲಾದ ಚಿತ್ರಗಳನ್ನು ಕ್ವೇಗೆ ತಳ್ಳುತ್ತಾನೆ;
- ಜೆಂಕಿನ್ಸ್ ಸಂರಚನೆ ಮತ್ತು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಮಾಸ್ಟರ್ ಸ್ಟೋರೇಜ್ ಬಕೆಟ್‌ಗೆ ತಳ್ಳುತ್ತಾನೆ;
- ಕ್ಲೌಡ್ ಕಾರ್ಯವು ಸಂರಚನೆ ಮತ್ತು ಚಾರ್ಟ್‌ಗಳನ್ನು ಮಾಸ್ಟರ್ ಶೇಖರಣಾ ಬಕೆಟ್‌ನಿಂದ ಮಾಸ್ಟರ್ ಜಿಟ್ ರೆಪೊಸಿಟರಿಗೆ ನಕಲಿಸುತ್ತದೆ;
- GitOps ಆಪರೇಟರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
2. ಜೆಂಕಿನ್ಸ್ ಬಿಲ್ಡ್ - ಬಿಡುಗಡೆ ಅಥವಾ ಹಾಟ್ಫಿಕ್ಸ್ ಶಾಖೆ:
- ಜೆಂಕಿನ್ಸ್ ಟ್ಯಾಗ್ ಮಾಡದ ಚಿತ್ರಗಳನ್ನು ಕ್ವೇಗೆ ತಳ್ಳುತ್ತಾನೆ;
- ಜೆಂಕಿನ್ಸ್ ಸಂರಚನೆ ಮತ್ತು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸ್ಟೇಜಿಂಗ್ ಸ್ಟೋರೇಜ್ ಬಕೆಟ್‌ಗೆ ತಳ್ಳುತ್ತಾನೆ;
- ಕ್ಲೌಡ್ ಕಾರ್ಯವು ಸಂರಚನೆ ಮತ್ತು ಚಾರ್ಟ್‌ಗಳನ್ನು ಸ್ಟೇಜಿಂಗ್ ಸ್ಟೋರೇಜ್ ಬಕೆಟ್‌ನಿಂದ ಸ್ಟೇಜಿಂಗ್ ಜಿಟ್ ರೆಪೊಸಿಟರಿಗೆ ನಕಲಿಸುತ್ತದೆ;
- GitOps ಆಪರೇಟರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
3. ಜೆಂಕಿನ್ಸ್ ನಿರ್ಮಿಸಲು - ಅಭಿವೃದ್ಧಿ ಅಥವಾ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆ:
- ಜೆಂಕಿನ್ಸ್ ಟ್ಯಾಗ್ ಮಾಡದ ಚಿತ್ರಗಳನ್ನು ಕ್ವೇಗೆ ತಳ್ಳುತ್ತಾನೆ;
- ಜೆಂಕಿನ್ಸ್ ಸಂರಚನೆ ಮತ್ತು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿ ಶೇಖರಣಾ ಬಕೆಟ್‌ಗೆ ತಳ್ಳುತ್ತಾರೆ;
- ಕ್ಲೌಡ್ ಕಾರ್ಯವು ಸಂರಚನೆ ಮತ್ತು ಚಾರ್ಟ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿ ಶೇಖರಣಾ ಬಕೆಟ್‌ನಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ Git ರೆಪೊಸಿಟರಿಗೆ ನಕಲಿಸುತ್ತದೆ;
- GitOps ಆಪರೇಟರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
4. ಹೊಸ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ:
- ಮ್ಯಾನೇಜರ್ ಅಥವಾ ನಿರ್ವಾಹಕರು (LCM/ops) ಆರಂಭದಲ್ಲಿ ಜಾಲಬಂಧ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು (NLBs) ನಿಯೋಜಿಸಲು ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು Gradle ಅನ್ನು ಕರೆಯುತ್ತಾರೆ;
- ನವೀಕರಣಗಳಿಗಾಗಿ ನಿಯೋಜನೆಯನ್ನು ತಯಾರಿಸಲು LCM/ops ಹೊಸ ಸಂರಚನೆಯನ್ನು ಮಾಡುತ್ತದೆ;
- GitOps ಆಪರೇಟರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ.
GitOps ನ ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆ
- ಪ್ರತಿ ಪರಿಸರಕ್ಕೆ ಘೋಷಣಾತ್ಮಕ ವಿಶೇಷಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ನ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ವಿವರಿಸಿ (ನಮ್ಮ ಕಥೆಯಲ್ಲಿ, ಬಾಬ್‌ನ ತಂಡವು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು Git ನಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ).
- Git ರೆಪೊಸಿಟರಿಯು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ಸಂಬಂಧಿಸಿದ ಸತ್ಯದ ಏಕೈಕ ಮೂಲವಾಗಿದೆ.
- ಬಯಸಿದ ಸ್ಥಿತಿಗೆ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು Git ನಲ್ಲಿ ಕಮಿಟ್‌ಗಳ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.
- ಎಲ್ಲಾ ಬಯಸಿದ ಕ್ಲಸ್ಟರ್ ನಿಯತಾಂಕಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಯೇ ಗಮನಿಸಬಹುದಾಗಿದೆ. ಈ ರೀತಿಯಾಗಿ ಅವು ಸೇರಿಕೊಳ್ಳುತ್ತವೆಯೇ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಬಹುದು (ಒಮ್ಮುಖವಾಗುವುದು, ಒಮ್ಮುಖವಾಗುವುದು) ಅಥವಾ ಭಿನ್ನತೆ (ವಿಭಿನ್ನಗೊಳಿಸು, ಬೇರೆಯಾಗುತ್ತವೆ) ಬಯಸಿದ ಮತ್ತು ಗಮನಿಸಿದ ರಾಜ್ಯಗಳು.
- ಬಯಸಿದ ಮತ್ತು ಗಮನಿಸಿದ ರಾಜ್ಯಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ, ನಂತರ:
- ಗುರಿ ಮತ್ತು ಗಮನಿಸಿದ ಸ್ಥಿತಿಗಳನ್ನು ಬೇಗ ಅಥವಾ ನಂತರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಒಮ್ಮುಖ ಕಾರ್ಯವಿಧಾನವಿದೆ. ಕ್ಲಸ್ಟರ್ ಒಳಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ.
- "ಬದಲಾವಣೆ ಬದ್ಧ" ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಯು ತಕ್ಷಣವೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
- ಕೆಲವು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಸಮಯದ ನಂತರ, ರಾಜ್ಯಗಳು ವಿಭಿನ್ನವಾಗಿದ್ದರೆ "ವ್ಯತ್ಯಾಸ" ಎಚ್ಚರಿಕೆಯನ್ನು ಕಳುಹಿಸಬಹುದು.
- ಈ ರೀತಿಯಲ್ಲಿ, Git ನಲ್ಲಿನ ಎಲ್ಲಾ ಕಮಿಟ್‌ಗಳು ಕ್ಲಸ್ಟರ್‌ಗೆ ಪರಿಶೀಲಿಸಬಹುದಾದ ಮತ್ತು ಐಡೆಂಪೋಟೆಂಟ್ ನವೀಕರಣಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
- ರೋಲ್ಬ್ಯಾಕ್ ಎನ್ನುವುದು ಹಿಂದೆ ಬಯಸಿದ ಸ್ಥಿತಿಗೆ ಒಮ್ಮುಖವಾಗಿದೆ.
- ಒಮ್ಮುಖವು ಅಂತಿಮವಾಗಿದೆ. ಇದರ ಸಂಭವವನ್ನು ಇವರಿಂದ ಸೂಚಿಸಲಾಗುತ್ತದೆ:
- ನಿರ್ದಿಷ್ಟ ಅವಧಿಗೆ ಯಾವುದೇ ವ್ಯತ್ಯಾಸ ಎಚ್ಚರಿಕೆಗಳಿಲ್ಲ.
- "ಒಮ್ಮುಖ" ಎಚ್ಚರಿಕೆ (ಉದಾ ವೆಬ್‌ಹೂಕ್, Git ರೈಟ್‌ಬ್ಯಾಕ್ ಈವೆಂಟ್).
ಭಿನ್ನತೆ ಎಂದರೇನು?
ಮತ್ತೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸೋಣ: ಎಲ್ಲಾ ಬಯಸಿದ ಕ್ಲಸ್ಟರ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಯೇ ಗಮನಿಸಬೇಕು.
ಭಿನ್ನಾಭಿಪ್ರಾಯದ ಕೆಲವು ಉದಾಹರಣೆಗಳು:
- Git ನಲ್ಲಿ ಶಾಖೆಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದರಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಬದಲಾವಣೆ.
- GUI ಕ್ಲೈಂಟ್ ಮಾಡಿದ Git ಬದ್ಧತೆಯ ಕಾರಣದಿಂದಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಬದಲಾವಣೆ.
- Git ನಲ್ಲಿನ PR ಕಾರಣದಿಂದಾಗಿ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ಬಹು ಬದಲಾವಣೆಗಳು ನಂತರ ಕಂಟೇನರ್ ಇಮೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ಸಂರಚನಾ ಬದಲಾವಣೆಗಳು.
- ದೋಷದಿಂದಾಗಿ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯಲ್ಲಿ ಬದಲಾವಣೆ, ಸಂಪನ್ಮೂಲ ಸಂಘರ್ಷ "ಕೆಟ್ಟ ನಡವಳಿಕೆ", ಅಥವಾ ಮೂಲ ಸ್ಥಿತಿಯಿಂದ ಸರಳವಾಗಿ ಯಾದೃಚ್ಛಿಕ ವಿಚಲನ.
ಒಮ್ಮುಖದ ಯಾಂತ್ರಿಕತೆ ಏನು?
ಕೆಲವು ಉದಾಹರಣೆಗಳು:
- ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ, ಒಮ್ಮುಖ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಒದಗಿಸಿದ್ದಾರೆ.
- ಕುಬರ್ನೆಟ್-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ವಿನ್ಯಾಸಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಅದೇ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಬಹುದು (ಉದಾಹರಣೆಗೆ ಇಸ್ಟಿಯೊ ಮತ್ತು ಕುಬೆಫ್ಲೋ).
- ಕುಬರ್ನೆಟ್ಸ್, ಇಮೇಜ್ ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು Git ನಡುವಿನ ಕಾರ್ಯಾಚರಣೆಯ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಕಾರ್ಯವಿಧಾನ , ಇದು ಭಾಗವಾಗಿದೆ .
- ಮೂಲ ಯಂತ್ರಗಳಿಗೆ, ಒಮ್ಮುಖ ಕಾರ್ಯವಿಧಾನವು ಘೋಷಣಾತ್ಮಕ ಮತ್ತು ಸ್ವಾಯತ್ತವಾಗಿರಬೇಕು. ನಮ್ಮ ಸ್ವಂತ ಅನುಭವದಿಂದ ನಾವು ಅದನ್ನು ಹೇಳಬಹುದು ಈ ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ, ಆದರೆ ಇನ್ನೂ ಮಾನವ ನಿಯಂತ್ರಣದ ಅಗತ್ಯವಿದೆ. ಈ ಅರ್ಥದಲ್ಲಿ, GitOps ಮೂಲಸೌಕರ್ಯದ ಸಂಪ್ರದಾಯವನ್ನು ಕೋಡ್ ಆಗಿ ವಿಸ್ತರಿಸುತ್ತದೆ.
GitOps ಶೋಷಣೆಗೆ ಮಾದರಿಯನ್ನು ಒದಗಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ನ ಅತ್ಯುತ್ತಮ ಒಮ್ಮುಖ ಎಂಜಿನ್‌ನೊಂದಿಗೆ Git ಅನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ.
GitOps ನಮಗೆ ಹೇಳಲು ಅನುಮತಿಸುತ್ತದೆ: ವಿವರಿಸಬಹುದಾದ ಮತ್ತು ಗಮನಿಸಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಮಾತ್ರ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತು ನಿಯಂತ್ರಿಸಬಹುದು.
GitOps ಸಂಪೂರ್ಣ ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಸ್ಟಾಕ್‌ಗಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಟೆರಾಫಾರ್ಮ್, ಇತ್ಯಾದಿ.)
GitOps ಕೇವಲ ಕುಬರ್ನೆಟ್ಸ್ ಅಲ್ಲ. ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಘೋಷಣಾತ್ಮಕವಾಗಿ ನಡೆಸಬೇಕು ಮತ್ತು ಒಮ್ಮುಖವನ್ನು ಬಳಸಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಸಂಪೂರ್ಣ ಸಿಸ್ಟಂ ಮೂಲಕ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆ ಕೆಲಸ ಮಾಡುವ ಪರಿಸರಗಳ ಸಂಗ್ರಹವನ್ನು ಅರ್ಥೈಸುತ್ತೇವೆ - ಉದಾಹರಣೆಗೆ, "ಡೆವ್ ಕ್ಲಸ್ಟರ್ 1", "ಪ್ರೊಡಕ್ಷನ್", ಇತ್ಯಾದಿ. ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ಯಂತ್ರಗಳು, ಕ್ಲಸ್ಟರ್‌ಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಡೇಟಾ, ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಒದಗಿಸುವ ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಮತ್ತು ಇತ್ಯಾದಿ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪಿಂಗ್ ಸಮಸ್ಯೆಗೆ ಟೆರಾಫಾರ್ಮ್ ಎಷ್ಟು ಮುಖ್ಯ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಎಲ್ಲೋ ನಿಯೋಜಿಸಬೇಕು ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸುವುದು ಎಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಆಧಾರವಾಗಿರುವ ನಿಯಂತ್ರಣ ಪದರವನ್ನು ರಚಿಸಲು ನಾವು ಅದೇ GitOps ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಅನ್ವಯಿಸಬಹುದು. ಇದು ಉಪಯುಕ್ತವಾದ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸವಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಮೇಲಿನ ಪದರಗಳಿಗೆ GitOps ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಅನ್ವಯಿಸುವಲ್ಲಿ ಬಲವಾದ ಗಮನವಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, Istio, Helm, Ksonnet, OpenFaaS ಮತ್ತು Kubeflow ಗಾಗಿ GitOps-ಮಾದರಿಯ ಪರಿಹಾರಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಪುಲುಮಿಗಾಗಿ, ಕ್ಲೌಡ್ ಸ್ಥಳೀಯಕ್ಕಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಪದರವನ್ನು ರಚಿಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ CI/CD: GitOps ಅನ್ನು ಇತರ ವಿಧಾನಗಳೊಂದಿಗೆ ಹೋಲಿಸುವುದು
ಹೇಳಿದಂತೆ, GitOps ಎರಡು ವಿಷಯಗಳು:
- ಮೇಲೆ ವಿವರಿಸಿದ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯರಿಗೆ ಆಪರೇಟಿಂಗ್ ಮಾಡೆಲ್.
- ಡೆವಲಪರ್-ಕೇಂದ್ರಿತ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಣೆ ಪರಿಸರಕ್ಕೆ ಮಾರ್ಗ.
ಅನೇಕರಿಗೆ, GitOps ಪ್ರಾಥಮಿಕವಾಗಿ Git ಪುಶ್‌ಗಳನ್ನು ಆಧರಿಸಿದ ಕೆಲಸದ ಹರಿವು. ನಮಗೂ ಅವನು ಇಷ್ಟ. ಆದರೆ ಅಷ್ಟೆ ಅಲ್ಲ: ಈಗ CI/CD ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ನೋಡೋಣ.
ಜಿಟ್ಆಪ್ಸ್ ಕುಬರ್ನೆಟ್ಸ್ಗಾಗಿ ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು (ಸಿಡಿ) ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ
GitOps ನಿರಂತರ ನಿಯೋಜನೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ನೀಡುತ್ತದೆ ಅದು ಪ್ರತ್ಯೇಕ "ನಿಯೋಜನೆ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳ" ಅಗತ್ಯವನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗಾಗಿ ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಾರೆ.
- ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸಲು Git ನಲ್ಲಿ ನವೀಕರಿಸುವ ಅಗತ್ಯವಿದೆ. ಇದು ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ವಹಿವಾಟಿನ ನವೀಕರಣವಾಗಿದೆ. ನವೀಕರಿಸಿದ ವಿವರಣೆಯ ಆಧಾರದ ಮೇಲೆ "ನಿಯೋಜನೆ" ಅನ್ನು ಕ್ಲಸ್ಟರ್‌ನೊಳಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.
- ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಸ್ವರೂಪದಿಂದಾಗಿ, ಈ ನವೀಕರಣಗಳು ಒಮ್ಮುಖವಾಗಿರುತ್ತವೆ. ಇದು ನಿರಂತರ ನಿಯೋಜನೆಗೆ ಯಾಂತ್ರಿಕತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಎಲ್ಲಾ ನವೀಕರಣಗಳು ಪರಮಾಣುಗಳಾಗಿವೆ.
- ಗಮನಿಸಿ: Git ಮತ್ತು Kubernetes ಅನ್ನು ಸಂಯೋಜಿಸುವ GitOps ಆಪರೇಟರ್ ಅನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನ ಅಪೇಕ್ಷಿತ ಮತ್ತು ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಸಮನ್ವಯಗೊಳಿಸುವ ಮೂಲಕ CD ಅನ್ನು ನಿರ್ವಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
kubectl ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಲ್ಲದೆ
ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸಲು ನೀವು Kubectl ಅನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಬೇಕು ಮತ್ತು ವಿಶೇಷವಾಗಿ kubectl ಆಜ್ಞೆಗಳನ್ನು ಗುಂಪು ಮಾಡಲು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಬೇಕು. ಬದಲಿಗೆ, GitOps ಪೈಪ್‌ಲೈನ್‌ನೊಂದಿಗೆ, ಬಳಕೆದಾರರು ತಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು Git ಮೂಲಕ ನವೀಕರಿಸಬಹುದು.
ಪ್ರಯೋಜನಗಳು ಸೇರಿವೆ:
- ಸರಿ. ನವೀಕರಣಗಳ ಗುಂಪನ್ನು ಅನ್ವಯಿಸಬಹುದು, ಒಮ್ಮುಖಗೊಳಿಸಬಹುದು ಮತ್ತು ಅಂತಿಮವಾಗಿ ಮೌಲ್ಯೀಕರಿಸಬಹುದು, ಪರಮಾಣು ನಿಯೋಜನೆಯ ಗುರಿಯ ಹತ್ತಿರ ನಮ್ಮನ್ನು ತರುತ್ತದೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುವುದು ಒಮ್ಮುಖದ ಯಾವುದೇ ಗ್ಯಾರಂಟಿಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ (ಇದರಲ್ಲಿ ಇನ್ನಷ್ಟು).
- ಭದ್ರತೆ. ಕೆಲ್ಸೆ ಹೈಟವರ್: "ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪರಿಕರಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಿ ಮತ್ತು ಅದನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಅಥವಾ ನಿರ್ವಹಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ನಿರ್ವಾಹಕರು." ಸಹ ನೋಡಿ ಸುರಕ್ಷತೆ ಮತ್ತು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಅನುಸರಣೆಯ ಬಗ್ಗೆ, ಹಾಗೆಯೇ ಅಜಾಗರೂಕತೆಯಿಂದ ಬರೆದ ಜೆಂಕಿನ್ಸ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಿಂದ ರುಜುವಾತುಗಳನ್ನು ಕದಿಯುವ ಮೂಲಕ.
- ಬಳಕೆದಾರರ ಅನುಭವ. ಕುಬೆಕ್ಟ್ಲ್ ಕುಬರ್ನೆಟ್ಸ್ ವಸ್ತು ಮಾದರಿಯ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಇದು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಬಳಕೆದಾರರು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಅಮೂರ್ತತೆಯಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬೇಕು. ಇಲ್ಲಿ ನಾನು ಮತ್ತೆ ಕೆಲ್ಸಿಯನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತೇನೆ ಮತ್ತು ವೀಕ್ಷಿಸಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ .
CI ಮತ್ತು CD ನಡುವಿನ ವ್ಯತ್ಯಾಸ
GitOps ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CI/CD ಮಾದರಿಗಳನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
ಆಧುನಿಕ CI ಸರ್ವರ್ ಒಂದು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಾಧನವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಇದು CI ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸಂಘಟಿಸಲು ಒಂದು ಸಾಧನವಾಗಿದೆ. ಇವುಗಳಲ್ಲಿ ನಿರ್ಮಾಣ, ಪರೀಕ್ಷೆ, ಟ್ರಂಕ್‌ಗೆ ವಿಲೀನಗೊಳಿಸುವಿಕೆ, ಇತ್ಯಾದಿ. CI ಸರ್ವರ್‌ಗಳು ಸಂಕೀರ್ಣ ಬಹು-ಹಂತದ ಪೈಪ್‌ಲೈನ್‌ಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತವೆ. ಕುಬರ್ನೆಟ್ಸ್ ನವೀಕರಣಗಳ ಸೆಟ್ ಅನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತಳ್ಳಲು ಪೈಪ್‌ಲೈನ್‌ನ ಭಾಗವಾಗಿ ರನ್ ಮಾಡುವುದು ಸಾಮಾನ್ಯ ಪ್ರಲೋಭನೆಯಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಇದನ್ನು ಅನೇಕ ತಜ್ಞರು ಮಾಡುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ಇದು ಸೂಕ್ತವಲ್ಲ, ಮತ್ತು ಇಲ್ಲಿ ಏಕೆ.
ಟ್ರಂಕ್‌ಗೆ ನವೀಕರಣಗಳನ್ನು ತಳ್ಳಲು CI ಅನ್ನು ಬಳಸಬೇಕು ಮತ್ತು CD ಯನ್ನು ಆಂತರಿಕವಾಗಿ ನಿರ್ವಹಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆ ನವೀಕರಣಗಳ ಆಧಾರದ ಮೇಲೆ ಸ್ವತಃ ಬದಲಾಗಬೇಕು. ನಾವು ಅದನ್ನು ಕರೆಯುತ್ತೇವೆ CI ಪುಶ್ ಮಾದರಿಯಂತಲ್ಲದೆ. ಸಿಡಿ ಭಾಗವಾಗಿದೆ ರನ್ಟೈಮ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್.
ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನೇರ ನವೀಕರಣಗಳ ಮೂಲಕ CI ಸರ್ವರ್‌ಗಳು ಏಕೆ CD ಗಳನ್ನು ಮಾಡಬಾರದು
CI ಉದ್ಯೋಗಗಳ ಒಂದು ಸೆಟ್ ಆಗಿ Kubernetes ಗೆ ನೇರ ನವೀಕರಣಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು CI ಸರ್ವರ್ ಅನ್ನು ಬಳಸಬೇಡಿ. ಇದು ನಾವು ಮಾತನಾಡುತ್ತಿರುವ ವಿರೋಧಿ ಮಾದರಿಯಾಗಿದೆ ನಿಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ.
ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್‌ಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ.
ಅವರು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದರು? ಬಾಬ್‌ನ CI ಸರ್ವರ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅದು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್ ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿದೆ (ಅಥವಾ ಇರಬೇಕು) ಅಥವಾ ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಬೇಕು ಎಂದು ಬಾಬ್‌ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಯಶಸ್ಸಿನ ವಿಷಯದಲ್ಲೂ ಅದೇ ನಿಜ.
ಬಾಬ್‌ನ ತಂಡವು ಹೊಸ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಿದೆ ಮತ್ತು ನಂತರ ಚಿತ್ರವನ್ನು ನಿಯೋಜಿಸಲು ಅವರ ನಿಯೋಜನೆಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡಿದೆ ಎಂದು ಭಾವಿಸೋಣ (ಎಲ್ಲಾ CI ಪೈಪ್‌ಲೈನ್‌ನಿಂದ).
ಚಿತ್ರವು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ಮಿಸಿದರೆ, ಆದರೆ ಪೈಪ್ಲೈನ್ ವಿಫಲವಾದರೆ, ತಂಡವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗುತ್ತದೆ:
- ನವೀಕರಣವನ್ನು ಹೊರತಂದಿದೆಯೇ?
- ನಾವು ಹೊಸ ನಿರ್ಮಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆಯೇ? ಇದು ಅನಾವಶ್ಯಕ ಅಡ್ಡ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ - ಒಂದೇ ಅಸ್ಥಿರ ಚಿತ್ರದ ಎರಡು ನಿರ್ಮಾಣಗಳನ್ನು ಹೊಂದಿರುವ ಸಾಧ್ಯತೆಯೊಂದಿಗೆ?
- ನಿರ್ಮಾಣವನ್ನು ಚಾಲನೆ ಮಾಡುವ ಮೊದಲು ನಾವು ಮುಂದಿನ ನವೀಕರಣಕ್ಕಾಗಿ ಕಾಯಬೇಕೇ?
- ನಿಖರವಾಗಿ ಏನು ತಪ್ಪಾಗಿದೆ? ಯಾವ ಹಂತಗಳನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕು (ಮತ್ತು ಯಾವುದು ಪುನರಾವರ್ತಿಸಲು ಸುರಕ್ಷಿತವಾಗಿದೆ)?
Git-ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದರಿಂದ ಬಾಬ್‌ನ ತಂಡವು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುವುದಿಲ್ಲ ಎಂದು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಕಮಿಟ್ ಪುಶ್, ಟ್ಯಾಗ್ ಅಥವಾ ಇತರ ಕೆಲವು ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಅವರು ಇನ್ನೂ ತಪ್ಪು ಮಾಡಬಹುದು; ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನವು ಇನ್ನೂ ಸ್ಪಷ್ಟವಾದ ಎಲ್ಲಾ ಅಥವಾ ಏನೂ ಇಲ್ಲದ ವಿಧಾನಕ್ಕೆ ಹೆಚ್ಚು ಹತ್ತಿರದಲ್ಲಿದೆ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, CI ಸರ್ವರ್‌ಗಳು CD ಯೊಂದಿಗೆ ಏಕೆ ವ್ಯವಹರಿಸಬಾರದು ಎಂಬುದು ಇಲ್ಲಿದೆ:
- ನವೀಕರಣ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಯಾವಾಗಲೂ ನಿರ್ಣಾಯಕವಾಗಿರುವುದಿಲ್ಲ; ಅವುಗಳಲ್ಲಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡುವುದು ಸುಲಭ.
- CI ಸರ್ವರ್‌ಗಳು ಘೋಷಣಾತ್ಮಕ ಕ್ಲಸ್ಟರ್ ಮಾದರಿಗೆ ಒಮ್ಮುಖವಾಗುವುದಿಲ್ಲ.
- ಅಸಮರ್ಥತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದು ಕಷ್ಟ. ಸಿಸ್ಟಮ್ನ ಆಳವಾದ ಶಬ್ದಾರ್ಥವನ್ನು ಬಳಕೆದಾರರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
- ಭಾಗಶಃ ವೈಫಲ್ಯದಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಕಷ್ಟ.
ಹೆಲ್ಮ್ ಬಗ್ಗೆ ಒಂದು ಟಿಪ್ಪಣಿ: ನೀವು ಹೆಲ್ಮ್ ಅನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ, ಅದನ್ನು GitOps ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ . ಇದು ಒಮ್ಮುಖವಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಹೆಲ್ಮ್ ಸ್ವತಃ ನಿರ್ಣಾಯಕ ಅಥವಾ ಪರಮಾಣು ಅಲ್ಲ.
ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ನಿರಂತರ ವಿತರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು GitOps ಅತ್ಯುತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ
ಆಲಿಸ್ ಮತ್ತು ಬಾಬ್ ಅವರ ತಂಡವು GitOps ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು, ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ ಎಂದು ಕಂಡುಹಿಡಿದಿದೆ. ಅವರ ಹೊಸ ವಿಧಾನವು ಹೇಗಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ವಿವರಣೆಯೊಂದಿಗೆ ಈ ಲೇಖನವನ್ನು ಕೊನೆಗೊಳಿಸೋಣ. ನಾವು ಹೆಚ್ಚಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ, ಆದರೆ ಸಂಪೂರ್ಣ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು GitOps ಅನ್ನು ಬಳಸಬಹುದು.
ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಆಪರೇಟಿಂಗ್ ಮಾಡೆಲ್
ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ನೋಡಿ. ಇದು Git ಮತ್ತು ಕಂಟೈನರ್ ಇಮೇಜ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಎರಡು ಆರ್ಕೆಸ್ಟ್ರೇಟೆಡ್ ಜೀವನಚಕ್ರಗಳಿಗೆ ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲಗಳಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ:
- Git ಗೆ ಫೈಲ್‌ಗಳನ್ನು ಓದುವ ಮತ್ತು ಬರೆಯುವ ಮತ್ತು ಕಂಟೈನರ್ ಚಿತ್ರಗಳ ರೆಪೊಸಿಟರಿಯನ್ನು ನವೀಕರಿಸಬಹುದಾದ ನಿರಂತರ ಏಕೀಕರಣ ಪೈಪ್ಲೈನ್.
- ನಿರ್ವಹಣೆ ಮತ್ತು ವೀಕ್ಷಣೆಯೊಂದಿಗೆ ನಿಯೋಜನೆಯನ್ನು ಸಂಯೋಜಿಸುವ ರನ್ಟೈಮ್ GitOps ಪೈಪ್ಲೈನ್. ಇದು Git ಗೆ ಫೈಲ್‌ಗಳನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಬರೆಯುತ್ತದೆ ಮತ್ತು ಕಂಟೈನರ್ ಚಿತ್ರಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು.
ಮುಖ್ಯ ಸಂಶೋಧನೆಗಳು ಯಾವುವು?
- ಕಾಳಜಿಗಳ ಪ್ರತ್ಯೇಕತೆ: ಎರಡೂ ಪೈಪ್‌ಲೈನ್‌ಗಳು Git ಅಥವಾ ಇಮೇಜ್ ರೆಪೊಸಿಟರಿಯನ್ನು ನವೀಕರಿಸುವ ಮೂಲಕ ಮಾತ್ರ ಸಂವಹನ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, CI ಮತ್ತು ರನ್ಟೈಮ್ ಪರಿಸರದ ನಡುವೆ ಫೈರ್ವಾಲ್ ಇದೆ. ನಾವು ಇದನ್ನು "ಅಸ್ಥಿರತೆಯ ಫೈರ್ವಾಲ್" ಎಂದು ಕರೆಯುತ್ತೇವೆ (ಅಸ್ಥಿರತೆ ಫೈರ್ವಾಲ್), ಎಲ್ಲಾ ರೆಪೊಸಿಟರಿ ನವೀಕರಣಗಳು ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ರಚಿಸುವುದರಿಂದ. ಈ ವಿಷಯದ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ, 72-87 ಸ್ಲೈಡ್‌ಗಳನ್ನು ನೋಡಿ .
- ನೀವು ಯಾವುದೇ CI ಮತ್ತು Git ಸರ್ವರ್ ಅನ್ನು ಬಳಸಬಹುದು: GitOps ಯಾವುದೇ ಘಟಕದೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಿಮ್ಮ ಮೆಚ್ಚಿನ CI ಮತ್ತು Git ಸರ್ವರ್‌ಗಳು, ಇಮೇಜ್ ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ಪರೀಕ್ಷಾ ಸೂಟ್‌ಗಳನ್ನು ಬಳಸುವುದನ್ನು ನೀವು ಮುಂದುವರಿಸಬಹುದು. ಮಾರುಕಟ್ಟೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಇತರ ನಿರಂತರ ವಿತರಣಾ ಸಾಧನಗಳಿಗೆ ತಮ್ಮದೇ ಆದ CI/Git ಸರ್ವರ್ ಅಥವಾ ಇಮೇಜ್ ರೆಪೊಸಿಟರಿ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇದು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸೀಮಿತಗೊಳಿಸುವ ಅಂಶವಾಗಬಹುದು. GitOps ನೊಂದಿಗೆ, ನೀವು ಪರಿಚಿತ ಪರಿಕರಗಳನ್ನು ಬಳಸಬಹುದು.
- ಏಕೀಕರಣ ಸಾಧನವಾಗಿ ಈವೆಂಟ್‌ಗಳು: Git ನಲ್ಲಿನ ಡೇಟಾವನ್ನು ನವೀಕರಿಸಿದ ತಕ್ಷಣ, ವೀವ್ ಫ್ಲಕ್ಸ್ (ಅಥವಾ ವೀವ್ ಕ್ಲೌಡ್ ಆಪರೇಟರ್) ರನ್ಟೈಮ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಬದಲಾವಣೆಯ ಸೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, Git ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಕೆಳಗೆ ತೋರಿಸಿರುವಂತೆ GitOps ಗಾಗಿ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ಸಂಘಟಿಸಲು ಇದು ಸರಳವಾದ ಏಕೀಕರಣ ಮಾದರಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ತೀರ್ಮಾನಕ್ಕೆ
GitOps ಯಾವುದೇ ಆಧುನಿಕ CI/CD ಟೂಲ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಬಲವಾದ ನವೀಕರಣ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:
- ಯಾಂತ್ರೀಕೃತಗೊಂಡ;
- ಒಮ್ಮುಖ;
- ಅಸಮರ್ಥತೆ;
- ನಿರ್ಣಾಯಕತೆ.
ಇದು ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಕಾರ್ಯಾಚರಣೆಯ ಮಾದರಿಯನ್ನು ನೀಡುವ ಕಾರಣ ಇದು ಮುಖ್ಯವಾಗಿದೆ.
- ವ್ಯವಸ್ಥೆಗಳ ನಿರ್ವಹಣೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಸಾಂಪ್ರದಾಯಿಕ ಉಪಕರಣಗಳು ರನ್‌ಬುಕ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಾರ್ಯಾಚರಣೆ ತಂಡಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿವೆ. (ವಾಡಿಕೆಯ ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ ಒಂದು ಸೆಟ್ - ಅಂದಾಜು. ಅನುವಾದ.), ನಿರ್ದಿಷ್ಟ ನಿಯೋಜನೆಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ.
- ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ನಿರ್ವಹಣೆಯಲ್ಲಿ, ನಿಯೋಜನೆಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಅಳೆಯಲು ವೀಕ್ಷಣಾ ಸಾಧನಗಳು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿದೆ ಇದರಿಂದ ಅಭಿವೃದ್ಧಿ ತಂಡವು ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು.
ವಿಭಿನ್ನ ಮೋಡಗಳಾದ್ಯಂತ ಹರಡಿರುವ ಅನೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳು ಮತ್ತು ತಮ್ಮದೇ ಆದ ತಂಡಗಳು ಮತ್ತು ನಿಯೋಜನೆ ಯೋಜನೆಗಳೊಂದಿಗೆ ಅನೇಕ ಸೇವೆಗಳನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಈ ಎಲ್ಲಾ ಸಮೃದ್ಧಿಯನ್ನು ನಿರ್ವಹಿಸಲು GitOps ಮಾಪಕ-ಅಸ್ಥಿರ ಮಾದರಿಯನ್ನು ನೀಡುತ್ತದೆ.
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. , ದಯವಿಟ್ಟು.
ಈ ಎರಡು ಅನುವಾದಗಳು Habré ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು GitOps ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ?
-
ಹೌದು, ನನಗೆ ಎಲ್ಲವೂ ತಿಳಿದಿತ್ತು
-
ಮೇಲ್ನೋಟಕ್ಕೆ ಮಾತ್ರ
-
ಯಾವುದೇ
35 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 10 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.
ಮೂಲ: www.habr.com