ಸೂಚನೆ. ಅನುವಾದ.: ಕುಬರ್ನೆಟ್ಸ್ ಸಮುದಾಯದಲ್ಲಿ, GitOps ಎಂಬ ಪ್ರವೃತ್ತಿಯು ಸ್ಪಷ್ಟವಾದ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸುತ್ತಿದೆ, ನಾವು ವೈಯಕ್ತಿಕವಾಗಿ ನೋಡಿದಂತೆ, ಕುಬೆಕಾನ್ ಯುರೋಪ್ 2019. ಈ ಪದವು ತುಲನಾತ್ಮಕವಾಗಿ ಇತ್ತೀಚಿನದು ವೀವ್‌ವರ್ಕ್ಸ್‌ನ ಮುಖ್ಯಸ್ಥರಿಂದ - ಅಲೆಕ್ಸಿಸ್ ರಿಚರ್ಡ್‌ಸನ್ - ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ (ಪ್ರಾಥಮಿಕವಾಗಿ Git, ಆದ್ದರಿಂದ ಹೆಸರು) ಪರಿಚಿತ ಪರಿಕರಗಳ ಬಳಕೆ ಎಂದರ್ಥ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾವು ಅದರ ಸಂರಚನೆಗಳನ್ನು Git ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬದಲಾವಣೆಗಳನ್ನು ಹೊರತರುವ ಮೂಲಕ ಕುಬರ್ನೆಟ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಮ್ಯಾಥಿಯಾಸ್ ಜೆಜಿ ಈ ಲೇಖನದಲ್ಲಿ ಈ ರೋಲ್‌ಔಟ್‌ಗೆ ಎರಡು ವಿಧಾನಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಾರೆ.
ಕಳೆದ ವರ್ಷದಲ್ಲಿ (ವಾಸ್ತವವಾಗಿ, ಇದು ಔಪಚಾರಿಕವಾಗಿ ಆಗಸ್ಟ್ 2017 ರಲ್ಲಿ ಸಂಭವಿಸಿತು - ಅಂದಾಜು. ಅನುವಾದ.) ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಹೊಸ ವಿಧಾನವಿದೆ. ಇದನ್ನು GitOps ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು Git ರೆಪೊಸಿಟರಿಯ ಸುರಕ್ಷಿತ ಪರಿಸರದಲ್ಲಿ ನಿಯೋಜನೆ ಆವೃತ್ತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬ ಮೂಲ ಕಲ್ಪನೆಯನ್ನು ಆಧರಿಸಿದೆ.
ಈ ವಿಧಾನದ ಮುಖ್ಯ ಅನುಕೂಲಗಳು ಈ ಕೆಳಗಿನಂತಿವೆ::
- ನಿಯೋಜನೆ ಆವೃತ್ತಿ ಮತ್ತು ಬದಲಾವಣೆ ಇತಿಹಾಸ. ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಿತಿಯನ್ನು Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಯೋಜನೆಗಳನ್ನು ಕಮಿಟ್‌ಗಳ ಮೂಲಕ ಮಾತ್ರ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಮಿಟ್ ಇತಿಹಾಸವನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು.
- ಪರಿಚಿತ Git ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ರೋಲ್ಬ್ಯಾಕ್ಗಳು... ಸರಳ
git resetನಿಯೋಜನೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಮರುಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ಹಿಂದಿನ ರಾಜ್ಯಗಳು ಯಾವಾಗಲೂ ಲಭ್ಯವಿವೆ. - ಸಿದ್ಧ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ. ವಿಶಿಷ್ಟವಾಗಿ, Git ವ್ಯವಸ್ಥೆಯು ಬಹಳಷ್ಟು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚಿನ ಕಂಪನಿಗಳು ಅದನ್ನು ರಕ್ಷಿಸಲು ವಿಶೇಷ ಗಮನವನ್ನು ನೀಡುತ್ತವೆ. ಅಂತೆಯೇ, ಈ ರಕ್ಷಣೆಯು ನಿಯೋಜನೆಗಳೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸಹ ಅನ್ವಯಿಸುತ್ತದೆ.
- ನಿಯೋಜನೆಗಾಗಿ ನೀತಿಗಳು. ಹೆಚ್ಚಿನ Git ಸಿಸ್ಟಮ್‌ಗಳು ಸ್ಥಳೀಯವಾಗಿ ಶಾಖೆಯ ಮೂಲಕ-ಶಾಖೆಯ ನೀತಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ-ಉದಾಹರಣೆಗೆ, ಪುಲ್ ವಿನಂತಿಗಳು ಮಾತ್ರ ಮಾಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಇನ್ನೊಬ್ಬ ತಂಡದ ಸದಸ್ಯರು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಸ್ವೀಕರಿಸಬೇಕು. ಪ್ರವೇಶ ನಿಯಂತ್ರಣದಂತೆ, ಅದೇ ನೀತಿಗಳು ನಿಯೋಜನೆ ನವೀಕರಣಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತವೆ.
ನೀವು ನೋಡುವಂತೆ, GitOps ವಿಧಾನಕ್ಕೆ ಹಲವು ಪ್ರಯೋಜನಗಳಿವೆ. ಕಳೆದ ವರ್ಷದಲ್ಲಿ, ಎರಡು ವಿಧಾನಗಳು ನಿರ್ದಿಷ್ಟ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸಿವೆ. ಒಂದು ಪುಶ್ ಬೇಸ್ಡ್, ಇನ್ನೊಂದು ಪುಲ್ ಬೇಸ್ಡ್. ನಾವು ಅವುಗಳನ್ನು ನೋಡುವ ಮೊದಲು, ವಿಶಿಷ್ಟವಾದ ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆಗಳು ಹೇಗಿವೆ ಎಂಬುದನ್ನು ಮೊದಲು ನೋಡೋಣ.
ನಿಯೋಜನೆ ವಿಧಾನಗಳು
ಇತ್ತೀಚಿನ ವರ್ಷಗಳಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆಗಳಿಗಾಗಿ ವಿವಿಧ ವಿಧಾನಗಳು ಮತ್ತು ಸಾಧನಗಳನ್ನು ಸ್ಥಾಪಿಸಿದ್ದಾರೆ:
- ಸ್ಥಳೀಯ Kubernetes/Kustomize ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಆಧರಿಸಿದೆ. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಇದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಡೆವಲಪರ್ ಮೂಲ YAML ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತಾರೆ. ಅದೇ ಟೆಂಪ್ಲೆಟ್ಗಳನ್ನು ನಿರಂತರವಾಗಿ ಪುನಃ ಬರೆಯುವುದನ್ನು ತೊಡೆದುಹಾಕಲು, ಕಸ್ಟೊಮೈಜ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ (ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಟೆಂಪ್ಲೆಟ್ಗಳನ್ನು ಮಾಡ್ಯೂಲ್ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ). ಸೂಚನೆ. ಅನುವಾದ.: Kustomize ಅನ್ನು kubectl ಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ .
- ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳು. ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳು ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಸೆಟ್‌ಗಳು, init ಕಂಟೈನರ್‌ಗಳು, ಸೈಡ್‌ಕಾರ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತದೆ, ಇವುಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್ ಆಧಾರಿತ ವಿಧಾನಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಗ್ರಾಹಕೀಕರಣ ಆಯ್ಕೆಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನವು ಟೆಂಪ್ಲೇಟ್ ಮಾಡಿದ YAML ಫೈಲ್‌ಗಳನ್ನು ಆಧರಿಸಿದೆ. ಹೆಲ್ಮ್ ಅವುಗಳನ್ನು ವಿವಿಧ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳೊಂದಿಗೆ ತುಂಬುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜಿಸುವ ಕ್ಲಸ್ಟರ್ ಘಟಕವಾದ ಟಿಲ್ಲರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ನವೀಕರಣಗಳು ಮತ್ತು ರೋಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಹೆಲ್ಮ್ ಮೂಲಭೂತವಾಗಿ ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಸಾಂಪ್ರದಾಯಿಕ ವಿಧಾನದಲ್ಲಿ ಮಾಡಿದ ರೀತಿಯಲ್ಲಿಯೇ ಅನ್ವಯಿಸುತ್ತದೆ. (ಇದೆಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮಲ್ಲಿ ನೀವು ಅದನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಿ - ಅಂದಾಜು ಅನುವಾದ.). ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ವಿವಿಧ ರೆಡಿಮೇಡ್ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳಿವೆ.
- ಪರ್ಯಾಯ ಪರಿಕರಗಳು. ಅನೇಕ ಪರ್ಯಾಯ ಸಾಧನಗಳಿವೆ. ಅವರೆಲ್ಲರಿಗೂ ಸಾಮಾನ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಅವರು ಕೆಲವು ಟೆಂಪ್ಲೇಟ್ ಫೈಲ್‌ಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್-ಓದಬಲ್ಲ YAML ಫೈಲ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ.
ನಮ್ಮ ಕೆಲಸದಲ್ಲಿ, ಪ್ರಮುಖ ಪರಿಕರಗಳಿಗಾಗಿ ನಾವು ನಿರಂತರವಾಗಿ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ (ಅವರು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ವಿಷಯಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದಾರೆ, ಇದು ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ) ಮತ್ತು ನಮ್ಮ ಸ್ವಂತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು "ಶುದ್ಧ" ಕುಬರ್ನೆಟ್ಸ್ YAML ಫೈಲ್‌ಗಳನ್ನು.
ಎಳೆ ತಳ್ಳು
ನನ್ನ ಇತ್ತೀಚಿನ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ, ನಾನು ಉಪಕರಣವನ್ನು ಪರಿಚಯಿಸಿದೆ , ಇದು ನಿಮಗೆ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು Git ರೆಪೊಸಿಟರಿಗೆ ಒಪ್ಪಿಸಲು ಮತ್ತು ಕಂಟೇನರ್‌ನ ಪ್ರತಿ ಕಮಿಟ್ ಅಥವಾ ಪುಶ್ ನಂತರ ನಿಯೋಜನೆಯನ್ನು ನವೀಕರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಪುಲ್ ವಿಧಾನವನ್ನು ಉತ್ತೇಜಿಸುವಲ್ಲಿ ಈ ಉಪಕರಣವು ಮುಖ್ಯವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಎಂದು ನನ್ನ ಅನುಭವವು ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಉಲ್ಲೇಖಿಸುತ್ತೇನೆ. ಅದನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದರ ಕುರಿತು ನೀವು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ಇಲ್ಲಿ .
ಎನ್ಬಿ! GitOps ಅನ್ನು ಬಳಸುವ ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳು ಎರಡೂ ವಿಧಾನಗಳಿಗೆ ಒಂದೇ ಆಗಿರುತ್ತವೆ.
ಪುಲ್ ಆಧಾರಿತ ವಿಧಾನ
ಪುಲ್ ವಿಧಾನವು ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್ ಒಳಗಿನಿಂದ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿದೆ. ಕ್ಲಸ್ಟರ್‌ನೊಳಗೆ ಒಬ್ಬ ನಿರ್ವಾಹಕರಿದ್ದು, ಅವರು ಸಂಬಂಧಿತ Git ಮತ್ತು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿ ರೆಪೊಸಿಟರಿಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಾರೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಆಂತರಿಕವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರ ಹಕ್ಕುಗಳಿಗೆ ಯಾವುದೇ ಬಾಹ್ಯ ಕ್ಲೈಂಟ್ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರದ ಕಾರಣ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಸುರಕ್ಷಿತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಒಳಿತು:
- ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಯಾವುದೇ ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ಗೆ ಹಕ್ಕುಗಳಿಲ್ಲ; ಎಲ್ಲಾ ನವೀಕರಣಗಳನ್ನು ಒಳಗಿನಿಂದ ಹೊರತರಲಾಗುತ್ತದೆ.
- ಕೆಲವು ಪರಿಕರಗಳು ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ನವೀಕರಣಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಲಿಂಕ್ ಮಾಡಲು ಸಹ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
- ಹೊಸ ಆವೃತ್ತಿಗಳಿಗಾಗಿ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಬಹುದು. ಹೊಸ ಚಿತ್ರ ಲಭ್ಯವಿದ್ದರೆ, Git ರೆಪೊಸಿಟರಿ ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ಹೊಸ ಆವೃತ್ತಿಗೆ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
- ವಿವಿಧ Git ರೆಪೊಸಿಟರಿಗಳು ಮತ್ತು ಅನುಮತಿಗಳೊಂದಿಗೆ ವಿವಿಧ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಲ್ಲಿ ಪುಲ್ ಟೂಲ್‌ಗಳನ್ನು ವಿತರಿಸಬಹುದು. ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಮಲ್ಟಿಟೆನೆಂಟ್ ಮಾದರಿಯನ್ನು ಬಳಸಬಹುದು. ಉದಾಹರಣೆಗೆ, A ತಂಡವು ನೇಮ್‌ಸ್ಪೇಸ್ A ಅನ್ನು ಬಳಸಬಹುದು, ತಂಡ B ನೇಮ್‌ಸ್ಪೇಸ್ B ಅನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ತಂಡವು ಜಾಗತಿಕ ಸ್ಥಳವನ್ನು ಬಳಸಬಹುದು.
- ನಿಯಮದಂತೆ, ಉಪಕರಣಗಳು ತುಂಬಾ ಹಗುರವಾಗಿರುತ್ತವೆ.
- ಆಪರೇಟರ್‌ನಂತಹ ಸಾಧನಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ , ರಹಸ್ಯಗಳನ್ನು Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದಾಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹಿಂಪಡೆಯಬಹುದು.
- ಸಿಡಿ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಯಾವುದೇ ಸಂಪರ್ಕವಿಲ್ಲ ಏಕೆಂದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಗಳು ಸಂಭವಿಸುತ್ತವೆ.
ಮಿನುಸು:
- ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳಿಂದ ನಿಯೋಜನೆ ರಹಸ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ನಿಯಮಿತವಾದವುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಮೊದಲು ಮೊಹರು ಮಾಡಿದ ರಹಸ್ಯಗಳ ರೂಪದಲ್ಲಿ ರಚಿಸಬೇಕು, ನಂತರ ಆಂತರಿಕ ಆಪರೇಟರ್‌ನಿಂದ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬೇಕು ಮತ್ತು ಅದರ ನಂತರವೇ ಅವು ಪುಲ್ ಟೂಲ್‌ಗೆ ಲಭ್ಯವಾಗುತ್ತವೆ. ನಂತರ ನೀವು ಈಗಾಗಲೇ ನಿಯೋಜಿಸಲಾದ ರಹಸ್ಯಗಳಲ್ಲಿನ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಹೆಲ್ಮ್‌ನಲ್ಲಿ ಬಿಡುಗಡೆಯನ್ನು ಚಲಾಯಿಸಬಹುದು. ನಿಯೋಜನೆಗಾಗಿ ಬಳಸಲಾಗುವ ಎಲ್ಲಾ ಹೆಲ್ಮ್ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ರಹಸ್ಯವನ್ನು ರಚಿಸುವುದು, ಅದನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು Git ಗೆ ಒಪ್ಪಿಸುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ.
- ನೀವು ಪುಲ್ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಂಡಾಗ, ನೀವು ಉಪಕರಣಗಳನ್ನು ಎಳೆಯಲು ಬಂಧಿಸಲ್ಪಡುತ್ತೀರಿ. ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಅಂತಿಮ ಟೆಂಪ್ಲೇಟ್‌ಗಳು Git ಗೆ ಬದ್ಧವಾಗುವ ಮೊದಲು ಅದನ್ನು ಚಲಾಯಿಸಬೇಕು ಎಂಬ ಅಂಶದಿಂದ ಕಸ್ಟಮೈಜ್ ಸಂಕೀರ್ಣವಾಗಿದೆ. ನೀವು ಸ್ವತಂತ್ರ ಪರಿಕರಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತಿಲ್ಲ, ಆದರೆ ನಿಮ್ಮ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟ.
ಪುಶ್ ಆಧಾರಿತ ವಿಧಾನ
ಪುಶ್ ವಿಧಾನದಲ್ಲಿ, ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯು (ಮುಖ್ಯವಾಗಿ CD ಪೈಪ್‌ಲೈನ್‌ಗಳು) Git ರೆಪೊಸಿಟರಿಗೆ ಬದ್ಧವಾದ ನಂತರ ಅಥವಾ ಹಿಂದಿನ CI ಪೈಪ್‌ಲೈನ್ ಯಶಸ್ವಿಯಾದರೆ ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿಯೋಜನೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈ ವಿಧಾನದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದೆ.
ಪ್ಲೂಸ್:
- ಭದ್ರತೆಯನ್ನು Git ರೆಪೊಸಿಟರಿ ಮತ್ತು ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್ ನಿರ್ಧರಿಸುತ್ತದೆ.
- ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಸುಲಭ ಮತ್ತು ಹೆಲ್ಮ್ ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
- ರಹಸ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದೆ ಏಕೆಂದರೆ ರಹಸ್ಯಗಳನ್ನು ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ಬಳಸಬಹುದು ಮತ್ತು Git ನಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದಾಗಿದೆ (ಬಳಕೆದಾರರ ಆದ್ಯತೆಗಳನ್ನು ಅವಲಂಬಿಸಿ).
- ನಿರ್ದಿಷ್ಟ ಉಪಕರಣಕ್ಕೆ ಯಾವುದೇ ಸಂಪರ್ಕವಿಲ್ಲ, ಏಕೆಂದರೆ ಯಾವುದೇ ಪ್ರಕಾರವನ್ನು ಬಳಸಬಹುದು.
- ಕಂಟೈನರ್ ಆವೃತ್ತಿ ನವೀಕರಣಗಳನ್ನು ನಿರ್ಮಾಣ ಪೈಪ್‌ಲೈನ್ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಬಹುದು.
ಮಿನುಸು:
- ಕ್ಲಸ್ಟರ್ ಪ್ರವೇಶ ಡೇಟಾವು ಬಿಲ್ಡ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿದೆ.
- ಪುಲ್ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ನಿಯೋಜನೆ ಕಂಟೇನರ್‌ಗಳನ್ನು ನವೀಕರಿಸುವುದು ಇನ್ನೂ ಸುಲಭವಾಗಿದೆ.
- CD ವ್ಯವಸ್ಥೆಯ ಮೇಲೆ ಭಾರೀ ಅವಲಂಬನೆ, ಏಕೆಂದರೆ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಮೂಲತಃ Gitlab ರನ್ನರ್‌ಗಳಿಗಾಗಿ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ನಂತರ ತಂಡವು Azure DevOps ಅಥವಾ Jenkins ಗೆ ತೆರಳಲು ನಿರ್ಧರಿಸುತ್ತದೆ... ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಬೇಕಾಗುತ್ತದೆ.
ಫಲಿತಾಂಶಗಳು: ಪುಶ್ ಅಥವಾ ಪುಲ್?
ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವಿಸಿದಂತೆ, ಪ್ರತಿಯೊಂದು ವಿಧಾನವು ಅದರ ಬಾಧಕಗಳನ್ನು ಹೊಂದಿದೆ. ಕೆಲವು ಕಾರ್ಯಗಳು ಒಂದರಿಂದ ಸಾಧಿಸಲು ಸುಲಭ ಮತ್ತು ಇನ್ನೊಂದರಿಂದ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ. ಮೊದಲಿಗೆ ನಾನು ನಿಯೋಜನೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡುತ್ತಿದ್ದೆ, ಆದರೆ ವೀವ್ ಫ್ಲಕ್ಸ್ ಕುರಿತು ಕೆಲವು ಲೇಖನಗಳನ್ನು ಕಂಡ ನಂತರ, ಎಲ್ಲಾ ಯೋಜನೆಗಳಿಗೆ GitOps ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ಮೂಲ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಗೆ ಇದು ಸುಲಭವಾಗಿದೆ, ಆದರೆ ನಂತರ ನಾನು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳೊಂದಿಗೆ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಆ ಸಮಯದಲ್ಲಿ, ವೀವ್ ಫ್ಲಕ್ಸ್ ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಆಪರೇಟರ್‌ನ ಮೂಲ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ನೀಡಿತು, ಆದರೆ ಈಗಲೂ ಕೆಲವು ಕಾರ್ಯಗಳು ಹಸ್ತಚಾಲಿತವಾಗಿ ರಹಸ್ಯಗಳನ್ನು ರಚಿಸುವ ಮತ್ತು ಅವುಗಳನ್ನು ಅನ್ವಯಿಸುವ ಅಗತ್ಯತೆಯಿಂದಾಗಿ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. ಕ್ಲಸ್ಟರ್‌ನ ರುಜುವಾತುಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ನ ಹೊರಗೆ ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ ಪುಲ್ ವಿಧಾನವು ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ನೀವು ವಾದಿಸಬಹುದು, ಇದು ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿದೆ.
ಸ್ವಲ್ಪ ಯೋಚಿಸಿದ ನಂತರ, ಇದು ಹಾಗಲ್ಲ ಎಂದು ನಾನು ಅನಿರೀಕ್ಷಿತ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದೆ. ನಾವು ಗರಿಷ್ಠ ರಕ್ಷಣೆಯ ಅಗತ್ಯವಿರುವ ಘಟಕಗಳ ಕುರಿತು ಮಾತನಾಡಿದರೆ, ಈ ಪಟ್ಟಿಯು ರಹಸ್ಯ ಸಂಗ್ರಹಣೆ, CI/CD ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು Git ರೆಪೊಸಿಟರಿಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅವುಗಳೊಳಗಿನ ಮಾಹಿತಿಯು ತುಂಬಾ ದುರ್ಬಲವಾಗಿದೆ ಮತ್ತು ಗರಿಷ್ಠ ರಕ್ಷಣೆಯ ಅಗತ್ಯವಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಯಾರಾದರೂ ನಿಮ್ಮ Git ರೆಪೊಸಿಟರಿಯನ್ನು ಪ್ರವೇಶಿಸಿದರೆ ಮತ್ತು ಅಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ತಳ್ಳಲು ಸಾಧ್ಯವಾದರೆ, ಅವರು ತಮಗೆ ಬೇಕಾದುದನ್ನು ನಿಯೋಜಿಸಬಹುದು (ಅದು ಪುಲ್ ಅಥವಾ ಪುಶ್ ಆಗಿರಲಿ) ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನುಸುಳಬಹುದು. ಹೀಗಾಗಿ, ರಕ್ಷಿಸಬೇಕಾದ ಪ್ರಮುಖ ಅಂಶಗಳೆಂದರೆ Git ರೆಪೊಸಿಟರಿ ಮತ್ತು CI/CD ವ್ಯವಸ್ಥೆಗಳು, ಕ್ಲಸ್ಟರ್ ರುಜುವಾತುಗಳಲ್ಲ. ಈ ರೀತಿಯ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ನೀವು ಉತ್ತಮವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನೀತಿಗಳು ಮತ್ತು ಭದ್ರತಾ ನಿಯಂತ್ರಣಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ರುಜುವಾತುಗಳನ್ನು ರಹಸ್ಯವಾಗಿ ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಹೊರತೆಗೆಯಲಾಗುತ್ತದೆ, ಪುಲ್ ವಿಧಾನದ ಹೆಚ್ಚುವರಿ ಭದ್ರತೆಯು ಮೂಲತಃ ಯೋಚಿಸಿದಷ್ಟು ಮೌಲ್ಯಯುತವಾಗಿರುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ಎಳೆಯುವ ವಿಧಾನವು ಹೆಚ್ಚು ಶ್ರಮದಾಯಕವಾಗಿದ್ದರೆ ಮತ್ತು ಭದ್ರತಾ ಪ್ರಯೋಜನವನ್ನು ಒದಗಿಸದಿದ್ದರೆ, ಪುಶ್ ವಿಧಾನವನ್ನು ಮಾತ್ರ ಬಳಸುವುದು ತಾರ್ಕಿಕವಲ್ಲವೇ? ಆದರೆ ಪುಶ್ ವಿಧಾನದಲ್ಲಿ ನೀವು ಸಿಡಿ ಸಿಸ್ಟಮ್‌ಗೆ ತುಂಬಾ ಸಂಬಂಧ ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಬಹುಶಃ ಇದನ್ನು ಮಾಡದಿರುವುದು ಉತ್ತಮ ಎಂದು ಯಾರಾದರೂ ವಾದಿಸಬಹುದು ಇದರಿಂದ ಭವಿಷ್ಯದಲ್ಲಿ ವಲಸೆಯನ್ನು ಕೈಗೊಳ್ಳುವುದು ಸುಲಭವಾಗುತ್ತದೆ.
ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ (ಯಾವಾಗಲೂ), ನೀವು ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಕ್ಕೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾದದ್ದನ್ನು ಬಳಸಬೇಕು ಅಥವಾ ಸಂಯೋಜಿಸಬೇಕು. ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು ಎರಡೂ ವಿಧಾನಗಳನ್ನು ಬಳಸುತ್ತೇನೆ: ನಮ್ಮದೇ ಆದ ಸೇವೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪುಲ್-ಆಧಾರಿತ ನಿಯೋಜನೆಗಳಿಗಾಗಿ ವೀವ್ ಫ್ಲಕ್ಸ್ ಮತ್ತು ಹೆಲ್ಮ್ ಮತ್ತು ಪ್ಲಗಿನ್‌ಗಳೊಂದಿಗಿನ ಪುಶ್ ವಿಧಾನ, ಇದು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ರಹಸ್ಯಗಳನ್ನು ಮನಬಂದಂತೆ ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಪ್ರಕರಣಗಳಿಗೆ ಸೂಕ್ತವಾದ ಒಂದೇ ಪರಿಹಾರವು ಎಂದಿಗೂ ಇರುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಯಾವಾಗಲೂ ಬಹಳಷ್ಟು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ ಮತ್ತು ಅವು ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಹೇಳುವುದಾದರೆ, ನಾನು GitOps ಅನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ - ಇದು ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸುರಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಪ್ರಕಾರದ ನಿಯೋಜನೆಗೆ ಯಾವ ವಿಧಾನವು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಈ ವಿಷಯದ ಕುರಿತು ನನ್ನ ಅನುಭವವು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ನಿಮ್ಮ ಅಭಿಪ್ರಾಯವನ್ನು ಕೇಳಲು ನನಗೆ ಸಂತೋಷವಾಗುತ್ತದೆ.
ಅನುವಾದಕರಿಂದ PS ಟಿಪ್ಪಣಿ
ಪುಲ್ ಮಾಡೆಲ್‌ನ ದುಷ್ಪರಿಣಾಮವೆಂದರೆ ರೆಂಡರ್ ಮಾಡಲಾದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು Git ಗೆ ಹಾಕುವುದು ಕಷ್ಟ, ಆದರೆ ಪುಲ್ ಮಾಡೆಲ್‌ನಲ್ಲಿರುವ CD ಪೈಪ್‌ಲೈನ್ ರೋಲ್‌ಔಟ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ವಾಸಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲಭೂತವಾಗಿ ಒಂದು ವರ್ಗ ಪೈಪ್‌ಲೈನ್ ಆಗುತ್ತದೆ ಎಂದು ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲ. ನಿರಂತರ ಅನ್ವಯಿಸು. ಆದ್ದರಿಂದ, ಎಲ್ಲಾ ನಿಯೋಜನೆಗಳಿಂದ ಅವರ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಹೇಗಾದರೂ ಲಾಗ್‌ಗಳು/ಸ್ಥಿತಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲು ಇನ್ನೂ ಹೆಚ್ಚಿನ ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿದೆ, ಮೇಲಾಗಿ CD ಸಿಸ್ಟಮ್‌ಗೆ ಉಲ್ಲೇಖಿಸಿ.
ಈ ಅರ್ಥದಲ್ಲಿ, ಪುಶ್ ಮಾದರಿಯು ರೋಲ್‌ಔಟ್‌ನ ಕನಿಷ್ಠ ಕೆಲವು ಗ್ಯಾರಂಟಿಗಳನ್ನು ಒದಗಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪೈಪ್‌ಲೈನ್‌ನ ಜೀವಿತಾವಧಿಯನ್ನು ರೋಲ್‌ಔಟ್‌ನ ಜೀವಿತಾವಧಿಗೆ ಸಮನಾಗಿ ಮಾಡಬಹುದು.
ನಾವು ಎರಡೂ ಮಾದರಿಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಮತ್ತು ಲೇಖನದ ಲೇಖಕರಂತೆಯೇ ಅದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ:
- ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಸಿಸ್ಟಮ್ ಘಟಕಗಳ ನವೀಕರಣಗಳನ್ನು ಸಂಘಟಿಸಲು ಪುಲ್ ಮಾದರಿಯು ನಮಗೆ ಸೂಕ್ತವಾಗಿದೆ (ನೋಡಿ. ).
- GitLab CI ಆಧಾರಿತ ಪುಶ್ ಮಾದರಿಯು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊರತರಲು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಉಪಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ಪೈಪ್ಲೈನ್ಗಳೊಳಗೆ ನಿಯೋಜನೆಗಳ ರೋಲ್ಔಟ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ . ಅಂದಹಾಗೆ, ನಮ್ಮ ಈ ಯೋಜನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, KubeCon Europe'19 ನಲ್ಲಿನ ನಮ್ಮ ಸ್ಟ್ಯಾಂಡ್‌ನಲ್ಲಿ DevOps ಎಂಜಿನಿಯರ್‌ಗಳ ಒತ್ತುವ ಸಮಸ್ಯೆಗಳನ್ನು ಚರ್ಚಿಸಿದಾಗ ನಾವು ನಿರಂತರ “GitOps” ಅನ್ನು ಕೇಳಿದ್ದೇವೆ.
ಅನುವಾದಕರಿಂದ PPS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «";
- «».
ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. , ದಯವಿಟ್ಟು.
ನೀವು GitOps ಬಳಸುತ್ತಿರುವಿರಾ?
-
ಹೌದು, ವಿಧಾನವನ್ನು ಎಳೆಯಿರಿ
-
ಹೌದು, ತಳ್ಳು
-
ಹೌದು, ಪುಲ್ + ಪುಶ್
-
ಹೌದು, ಬೇರೆ ಏನೋ
-
ಯಾವುದೇ
30 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 10 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.
ಮೂಲ: www.habr.com