ನಾವು (ಮತ್ತು ನಾವು ಮಾತ್ರವಲ್ಲ) ಬಹಳ ಸಮಯದಿಂದ ಕಾಯುತ್ತಿರುವುದು ಸಂಭವಿಸಿದೆ: , ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ತಲುಪಿಸಲು ನಮ್ಮ ಓಪನ್ ಸೋರ್ಸ್ ಉಪಯುಕ್ತತೆ, ಈಗ 3-ವೇ ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ! ಇದರ ಜೊತೆಗೆ, ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡದೆಯೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ K8s ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಅಳವಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿದೆ.
ಇದು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ನಾವು ಹಾಕುತ್ತೇವೆ WERF_THREE_WAY_MERGE=enabled - ನಾವು ನಿಯೋಜನೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ "ಇನ್‌ನಂತೆ kubectl apply", ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹೆಲ್ಮ್ 2 ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಇನ್ನೂ ಸ್ವಲ್ಪ ಹೆಚ್ಚು.
ಆದರೆ ಸಿದ್ಧಾಂತದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ: ನಿಖರವಾಗಿ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳು ಯಾವುವು, ಜನರು ಅವುಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ವಿಧಾನವನ್ನು ಹೇಗೆ ಕಂಡುಕೊಂಡಿದ್ದಾರೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್-ಆಧಾರಿತ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ CI/CD ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಅವು ಏಕೆ ಮುಖ್ಯವಾಗಿವೆ? ಮತ್ತು ಅದರ ನಂತರ, 3-ವೇ-ವಿಲೀನವು werf ನಲ್ಲಿ ಏನಿದೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಯಾವ ವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂದು ನೋಡೋಣ.
3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್ ಎಂದರೇನು?
ಆದ್ದರಿಂದ, YAML ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಲ್ಲಿ ವಿವರಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಹೊರತರುವ ಕಾರ್ಯದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ.
ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ಕುಬರ್ನೆಟ್ಸ್ API ಕೆಳಗಿನ ಮೂಲಭೂತ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನೀಡುತ್ತದೆ: ರಚಿಸಿ, ಪ್ಯಾಚ್ ಮಾಡಿ, ಬದಲಿಸಿ ಮತ್ತು ಅಳಿಸಿ. ಅವರ ಸಹಾಯದಿಂದ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳ ಅನುಕೂಲಕರ ನಿರಂತರ ರೋಲ್ಔಟ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಅವಶ್ಯಕ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ. ಹೇಗೆ?
kubectl ಕಡ್ಡಾಯ ಆಜ್ಞೆಗಳು
ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ರಚಿಸಲು, ಮಾರ್ಪಡಿಸಲು ಮತ್ತು ಅಳಿಸಲು kubectl ಕಡ್ಡಾಯ ಆಜ್ಞೆಗಳನ್ನು ಬಳಸುವುದು Kubernetes ನಲ್ಲಿ ವಸ್ತುಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮೊದಲ ವಿಧಾನವಾಗಿದೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ:
- ತಂಡ
kubectl runನೀವು ನಿಯೋಜನೆ ಅಥವಾ ಉದ್ಯೋಗವನ್ನು ಚಲಾಯಿಸಬಹುದು:kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE - ತಂಡ
kubectl scale- ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸಿ:kubectl scale --replicas=3 deployment/mysql - ಮತ್ತು ಹೀಗೆ.
ಈ ವಿಧಾನವು ಮೊದಲ ನೋಟದಲ್ಲಿ ಅನುಕೂಲಕರವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆದಾಗ್ಯೂ ಸಮಸ್ಯೆಗಳಿವೆ:
- ಇದು ಕಷ್ಟ ಸ್ವಯಂಚಾಲಿತ.
- ಹೇಗೆ ಸಂರಚನೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ Git ನಲ್ಲಿ? ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಆಗುತ್ತಿರುವ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು?
- ಹೇಗೆ ಒದಗಿಸುವುದು ಪುನರುತ್ಪಾದನೆ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು?
- ...
ಈ ವಿಧಾನವು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ಕೋಡ್ (IaC; ಅಥವಾ ಸಹ) ಶೇಖರಿಸುವುದರೊಂದಿಗೆ ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಹೆಚ್ಚು ಆಧುನಿಕ ಆಯ್ಕೆಯಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಜನಪ್ರಿಯತೆಯನ್ನು ಗಳಿಸುತ್ತಿದೆ). ಆದ್ದರಿಂದ, ಈ ಆಜ್ಞೆಗಳು kubectl ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಅಭಿವೃದ್ಧಿಯನ್ನು ಪಡೆಯಲಿಲ್ಲ.
ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ರಚಿಸಿ, ಪಡೆಯಿರಿ, ಬದಲಿಸಿ ಮತ್ತು ಅಳಿಸಿ
ಪ್ರಾಥಮಿಕ ಜೊತೆ ಸೃಷ್ಟಿ ಇದು ಸರಳವಾಗಿದೆ: ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಕಾರ್ಯಾಚರಣೆಗೆ ಕಳುಹಿಸಿ create kube api ಮತ್ತು ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಲಾಗಿದೆ. ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ YAML ಪ್ರಾತಿನಿಧ್ಯವನ್ನು Git ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು ಮತ್ತು ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ರಚಿಸಬಹುದು kubectl create -f manifest.yaml.
С ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ ಸಹ ಸರಳ: ಅದೇ ಬದಲಿ manifest.yaml Git ನಿಂದ ತಂಡಕ್ಕೆ kubectl delete -f manifest.yaml.
ಕಾರ್ಯಾಚರಣೆ replace ಸಂಪನ್ಮೂಲವನ್ನು ಮರುಸೃಷ್ಟಿಸದೆ ಸಂಪನ್ಮೂಲ ಸಂರಚನೆಯನ್ನು ಹೊಸದರೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದರರ್ಥ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಬದಲಾವಣೆ ಮಾಡುವ ಮೊದಲು, ಕಾರ್ಯಾಚರಣೆಯೊಂದಿಗೆ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಶ್ನಿಸಲು ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ get, ಅದನ್ನು ಬದಲಾಯಿಸಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯೊಂದಿಗೆ ನವೀಕರಿಸಿ replace. kube apiserver ಅನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು, ಶಸ್ತ್ರಚಿಕಿತ್ಸೆಯ ನಂತರ get ವಸ್ತುವು ಬದಲಾಗಿದೆ, ನಂತರ ಕಾರ್ಯಾಚರಣೆ replace ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
Git ನಲ್ಲಿ ಸಂರಚನೆಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಬದಲಿ ಬಳಸಿಕೊಂಡು ಅದನ್ನು ನವೀಕರಿಸಲು, ನೀವು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ get, Git ನಿಂದ ನಾವು ಸ್ವೀಕರಿಸಿದ ಸಂರಚನೆಯನ್ನು ವಿಲೀನಗೊಳಿಸಿ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಿ replace. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, kubectl ನಿಮಗೆ ಆಜ್ಞೆಯನ್ನು ಬಳಸಲು ಮಾತ್ರ ಅನುಮತಿಸುತ್ತದೆ kubectl replace -f manifest.yamlಅಲ್ಲಿ manifest.yaml — ಈಗಾಗಲೇ ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಲೀನಗೊಂಡ) ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ. ಬಳಕೆದಾರರು ವಿಲೀನ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ ಮತ್ತು ಇದು ಕ್ಷುಲ್ಲಕವಲ್ಲದ ವಿಷಯವಾಗಿದೆ...
ಆದರೂ ಸಹ ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ manifest.yaml ಮತ್ತು Git ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುವುದು ಅಥವಾ ಅದನ್ನು ನವೀಕರಿಸುವುದು ಅಗತ್ಯವೇ ಎಂಬುದನ್ನು ನಾವು ಮುಂಚಿತವಾಗಿ ತಿಳಿದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ - ಇದನ್ನು ಬಳಕೆದಾರ ಸಾಫ್ಟ್ವೇರ್ನಿಂದ ಮಾಡಬೇಕು.
ಒಟ್ಟು: ನಾವು ನಿರಂತರ ರೋಲ್ಔಟ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದೇ? ಕೋಡ್ ಮತ್ತು ಅನುಕೂಲಕರ CI/CD ಜೊತೆಗೆ ಮೂಲಸೌಕರ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು Git ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ರಚಿಸಿ, ಬದಲಿಸಿ ಮತ್ತು ಅಳಿಸುವುದನ್ನು ಮಾತ್ರ ಬಳಸುವುದೇ?
ತಾತ್ವಿಕವಾಗಿ, ನಾವು ಮಾಡಬಹುದು ... ಇದಕ್ಕಾಗಿ ನೀವು ವಿಲೀನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ ಪ್ರಣಾಳಿಕೆಗಳು ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಬೈಂಡಿಂಗ್:
- ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಸ್ತುವಿನ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ,
- ಆರಂಭಿಕ ಸಂಪನ್ಮೂಲ ರಚನೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ,
- ಅದನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಅಳಿಸುತ್ತದೆ.
ನವೀಕರಿಸುವಾಗ, ದಯವಿಟ್ಟು ಗಮನಿಸಿ ಸಂಪನ್ಮೂಲ ಬದಲಾಗಿರಬಹುದು ಕೊನೆಯಿಂದಲೂ get ಮತ್ತು ಆಶಾವಾದಿ ಲಾಕಿಂಗ್ ಪ್ರಕರಣವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಿ - ಪುನರಾವರ್ತಿತ ನವೀಕರಣ ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಿ.
ಆದಾಗ್ಯೂ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ನವೀಕರಿಸಲು kube-apiserver ಮತ್ತೊಂದು ಮಾರ್ಗವನ್ನು ನೀಡಿದಾಗ ಚಕ್ರವನ್ನು ಏಕೆ ಮರುಶೋಧಿಸಬೇಕು: ಕಾರ್ಯಾಚರಣೆ patch, ಇದು ವಿವರಿಸಿದ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಂದ ಬಳಕೆದಾರರನ್ನು ನಿವಾರಿಸುತ್ತದೆ?
ಪ್ಯಾಚ್
ಈಗ ನಾವು ಪ್ಯಾಚ್‌ಗಳಿಗೆ ಹೋಗುತ್ತೇವೆ.
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಸ್ತುಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಪ್ಯಾಚ್‌ಗಳು ಪ್ರಾಥಮಿಕ ಮಾರ್ಗವಾಗಿದೆ. ಕಾರ್ಯಾಚರಣೆ patch ಇದು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
- kube-apiserver ಬಳಕೆದಾರರು JSON ರೂಪದಲ್ಲಿ ಪ್ಯಾಚ್ ಅನ್ನು ಕಳುಹಿಸಬೇಕು ಮತ್ತು ವಸ್ತುವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು,
- ಮತ್ತು ಎಪಿಸರ್ವರ್ ಸ್ವತಃ ವಸ್ತುವಿನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಅಗತ್ಯವಿರುವ ರೂಪಕ್ಕೆ ತರುತ್ತದೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಆಶಾವಾದಿ ಲಾಕಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ. ಈ ಕಾರ್ಯಾಚರಣೆಯು ಬದಲಿಗಿಂತ ಹೆಚ್ಚು ಘೋಷಣಾತ್ಮಕವಾಗಿದೆ, ಆದರೂ ಮೊದಲಿಗೆ ಅದು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕಾಣಿಸಬಹುದು.
ಹೀಗೆ:
- ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಳಸುವುದು
createನಾವು Git ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಪ್ರಕಾರ ವಸ್ತುವನ್ನು ರಚಿಸುತ್ತೇವೆ, - ಸಹಾಯದಿಂದ
delete- ವಸ್ತುವು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅಳಿಸಿ, - ಸಹಾಯದಿಂದ
patch— ನಾವು ವಸ್ತುವನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ, ಅದನ್ನು Git ನಲ್ಲಿ ವಿವರಿಸಿದ ರೂಪಕ್ಕೆ ತರುತ್ತೇವೆ.
ಆದಾಗ್ಯೂ, ಇದನ್ನು ಮಾಡಲು, ನೀವು ರಚಿಸಬೇಕಾಗಿದೆ ಸರಿಯಾದ ಪ್ಯಾಚ್!
ಹೆಲ್ಮ್ 2 ರಲ್ಲಿ ಪ್ಯಾಚ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ: 2-ವೇ-ಮರ್ಜ್
ನೀವು ಮೊದಲು ಬಿಡುಗಡೆಯನ್ನು ಸ್ಥಾಪಿಸಿದಾಗ, ಹೆಲ್ಮ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ create ಚಾರ್ಟ್ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ.
ಪ್ರತಿ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಯನ್ನು ನವೀಕರಿಸುವಾಗ:
- ಹಿಂದಿನ ಚಾರ್ಟ್ ಮತ್ತು ಪ್ರಸ್ತುತ ಚಾರ್ಟ್ ಆವೃತ್ತಿಯಿಂದ ಸಂಪನ್ಮೂಲ ಆವೃತ್ತಿಯ ನಡುವಿನ ಪ್ಯಾಚ್ ಅನ್ನು ಪರಿಗಣಿಸುತ್ತದೆ,
- ಈ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.
ನಾವು ಇದನ್ನು ಪ್ಯಾಚ್ ಎಂದು ಕರೆಯುತ್ತೇವೆ 2-ವೇ ವಿಲೀನ ಪ್ಯಾಚ್, ಏಕೆಂದರೆ 2 ಪ್ರಣಾಳಿಕೆಗಳು ಅದರ ರಚನೆಯಲ್ಲಿ ತೊಡಗಿಕೊಂಡಿವೆ:
- ಹಿಂದಿನ ಬಿಡುಗಡೆಯಿಂದ ಸಂಪನ್ಮೂಲ ಮ್ಯಾನಿಫೆಸ್ಟ್,
- ಪ್ರಸ್ತುತ ಸಂಪನ್ಮೂಲದಿಂದ ಸಂಪನ್ಮೂಲ ಮ್ಯಾನಿಫೆಸ್ಟ್.
ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತೆಗೆದುಹಾಕುವಾಗ delete kube apiserver ನಲ್ಲಿ ಹಿಂದಿನ ಬಿಡುಗಡೆಯಲ್ಲಿ ಘೋಷಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಪ್ರಸ್ತುತದಲ್ಲಿ ಘೋಷಿಸಲಾಗಿಲ್ಲ.
2 ವೇ ವಿಲೀನ ಪ್ಯಾಚ್ ವಿಧಾನವು ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ: ಇದು ಕಾರಣವಾಗುತ್ತದೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಸಂಪನ್ಮೂಲದ ನೈಜ ಸ್ಥಿತಿ ಮತ್ತು Git ನಲ್ಲಿನ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ ಆಗಿಲ್ಲ.
ಉದಾಹರಣೆಯೊಂದಿಗೆ ಸಮಸ್ಯೆಯ ವಿವರಣೆ
- Git ನಲ್ಲಿ, ಒಂದು ಚಾರ್ಟ್ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಅದರಲ್ಲಿ ಕ್ಷೇತ್ರ
imageನಿಯೋಜನೆ ವಿಷಯಗಳುubuntu:18.04. - ಮೂಲಕ ಬಳಕೆದಾರ
kubectl editಗೆ ಈ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆubuntu:19.04. - ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಅನ್ನು ಮರು ನಿಯೋಜಿಸುವಾಗ ಪ್ಯಾಚ್ ಅನ್ನು ರಚಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಷೇತ್ರ
imageಬಿಡುಗಡೆಯ ಹಿಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಮತ್ತು ಪ್ರಸ್ತುತ ಚಾರ್ಟ್‌ನಲ್ಲಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ. - ಮರು ನಿಯೋಜನೆಯ ನಂತರ
imageಉಳಿದಿದೆubuntu:19.04, ಚಾರ್ಟ್ ಹೇಳುತ್ತಿದ್ದರೂubuntu:18.04.
ನಾವು ಡಿಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಘೋಷಣೆಯನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ.
ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಸಂಪನ್ಮೂಲ ಎಂದರೇನು?
ಸಾಮಾನ್ಯವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪೂರ್ಣಗೊಂಡಿದೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಸಂಪನ್ಮೂಲ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಮತ್ತು Git ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್ ನಡುವಿನ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪಡೆಯುವುದು ಅಸಾಧ್ಯ. ಏಕೆಂದರೆ ನಿಜವಾದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಸೇವಾ ಟಿಪ್ಪಣಿಗಳು/ಲೇಬಲ್‌ಗಳು, ಹೆಚ್ಚುವರಿ ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ಇತರ ಡೇಟಾವನ್ನು ಕೆಲವು ನಿಯಂತ್ರಕಗಳಿಂದ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸಂಪನ್ಮೂಲದಿಂದ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ನಾವು Git ನಲ್ಲಿ ಈ ಡೇಟಾವನ್ನು ಇರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಬಯಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಾವು Git ನಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಕ್ಷೇತ್ರಗಳು ರೋಲ್ಔಟ್ ಆದ ನಂತರ ಸೂಕ್ತವಾದ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.
ಇದು ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಸಂಪನ್ಮೂಲ ನಿಯಮ: ಸಂಪನ್ಮೂಲವನ್ನು ಹೊರತರುವಾಗ, Git ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ (ಅಥವಾ ಹಿಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮತ್ತು ಈಗ ಅಳಿಸಲಾದ) ಕ್ಷೇತ್ರಗಳನ್ನು ಮಾತ್ರ ನೀವು ಬದಲಾಯಿಸಬಹುದು ಅಥವಾ ಅಳಿಸಬಹುದು.
3-ವೇ ವಿಲೀನ ಪ್ಯಾಚ್
ಮುಖ್ಯ ಕಲ್ಪನೆ : ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, Git ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ಕೊನೆಯ ಅನ್ವಯಿಕ ಆವೃತ್ತಿ ಮತ್ತು Git ನಿಂದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ಗುರಿ ಆವೃತ್ತಿಯ ನಡುವೆ ಪ್ಯಾಚ್ ಅನ್ನು ರಚಿಸಿ. ಪರಿಣಾಮವಾಗಿ ಪ್ಯಾಚ್ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾದ ಸಂಪನ್ಮೂಲ ನಿಯಮವನ್ನು ಅನುಸರಿಸಬೇಕು:
- ಗುರಿ ಆವೃತ್ತಿಗೆ ಸೇರಿಸಲಾದ ಹೊಸ ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ಯಾಚ್ ಬಳಸಿ ಸೇರಿಸಲಾಗುತ್ತದೆ;
- ಕೊನೆಯ ಅನ್ವಯಿಕ ಆವೃತ್ತಿಯಲ್ಲಿ ಈ ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಷೇತ್ರಗಳು ಮತ್ತು ಗುರಿ ಆವೃತ್ತಿಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ;
- ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ಗುರಿ ಆವೃತ್ತಿಯಿಂದ ಭಿನ್ನವಾಗಿರುವ ವಸ್ತುವಿನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯಲ್ಲಿನ ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ಯಾಚ್ ಬಳಸಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
ಈ ತತ್ತ್ವದ ಮೇಲೆ ಅದು ತೇಪೆಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ kubectl apply:
- ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ಕೊನೆಯ ಅನ್ವಯಿಕ ಆವೃತ್ತಿಯನ್ನು ವಸ್ತುವಿನ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ,
- ಗುರಿ - ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ YAML ಫೈಲ್‌ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ,
- ಪ್ರಸ್ತುತವು ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಬಂದಿದೆ.
ಈಗ ನಾವು ಸಿದ್ಧಾಂತವನ್ನು ವಿಂಗಡಿಸಿದ್ದೇವೆ, ನಾವು ವರ್ಫ್‌ನಲ್ಲಿ ಏನು ಮಾಡಿದ್ದೇವೆ ಎಂದು ಹೇಳಲು ಸಮಯವಾಗಿದೆ.
werf ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತಿದೆ
ಹಿಂದೆ, ಹೆಲ್ಮ್ 2 ನಂತಹ ವರ್ಫ್, 2-ವೇ-ಮರ್ಜ್ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಳಸಿದೆ.
ದುರಸ್ತಿ ಪ್ಯಾಚ್
ಹೊಸ ರೀತಿಯ ಪ್ಯಾಚ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಲು - 3-ವೇ-ವಿಲೀನ - ಮೊದಲ ಹಂತವನ್ನು ನಾವು ಪರಿಚಯಿಸಿದ್ದೇವೆ ದುರಸ್ತಿ ತೇಪೆಗಳು.
ನಿಯೋಜಿಸುವಾಗ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ 2-ವೇ-ಮರ್ಜ್ ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ werf ಹೆಚ್ಚುವರಿಯಾಗಿ ಒಂದು ಪ್ಯಾಚ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಅದು Git ನಲ್ಲಿ ಬರೆಯಲಾದ ಸಂಪನ್ಮೂಲದ ನೈಜ ಸ್ಥಿತಿಯನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತದೆ (ಅಂತಹ ಪ್ಯಾಚ್ ಅನ್ನು ಮೇಲೆ ವಿವರಿಸಿದ ಅದೇ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಸಂಪನ್ಮೂಲ ನಿಯಮವನ್ನು ಬಳಸಿ ರಚಿಸಲಾಗಿದೆ) .
ಡಿಸಿಂಕ್ರೊನೈಸೇಶನ್ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಿಯೋಜನೆಯ ಕೊನೆಯಲ್ಲಿ ಬಳಕೆದಾರರು ಅನುಗುಣವಾದ ಸಂದೇಶದೊಂದಿಗೆ ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ರೂಪಕ್ಕೆ ಸಂಪನ್ಮೂಲವನ್ನು ತರಲು ಅನ್ವಯಿಸಬೇಕಾದ ಪ್ಯಾಚ್. ಈ ಪ್ಯಾಚ್ ಅನ್ನು ವಿಶೇಷ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಸಹ ದಾಖಲಿಸಲಾಗಿದೆ werf.io/repair-patch. ಇದು ಬಳಕೆದಾರರ ಕೈಗಳು ಎಂದು ಊಹಿಸಲಾಗಿದೆ сам ಈ ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ: werf ಇದನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
ರಿಪೇರಿ ಪ್ಯಾಚ್‌ಗಳನ್ನು ರಚಿಸುವುದು ತಾತ್ಕಾಲಿಕ ಅಳತೆಯಾಗಿದ್ದು ಅದು 3-ವೇ-ವಿಲೀನ ತತ್ವದ ಆಧಾರದ ಮೇಲೆ ಪ್ಯಾಚ್‌ಗಳ ರಚನೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಈ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನ್ವಯಿಸಬೇಡಿ. ಈ ಸಮಯದಲ್ಲಿ, ಈ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ.
ಹೊಸ ಬಿಡುಗಡೆಗಳಿಗೆ ಮಾತ್ರ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್
ಡಿಸೆಂಬರ್ 1, 2019 ರಿಂದ, ವರ್ಫ್‌ನ ಬೀಟಾ ಮತ್ತು ಆಲ್ಫಾ ಆವೃತ್ತಿಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ವರ್ಫ್ ಮೂಲಕ ಹೊರತಂದಿರುವ ಹೊಸ ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗಳಿಗೆ ಮಾತ್ರ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಪೂರ್ಣ ಪ್ರಮಾಣದ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಳಸಿ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಿಡುಗಡೆಗಳು 2-ವೇ-ಮರ್ಜ್ + ರಿಪೇರಿ ಪ್ಯಾಚ್‌ಗಳ ವಿಧಾನವನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ.
ಈ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಸ್ಪಷ್ಟವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ಈಗ.
ಹೇಳಿಕೆಯನ್ನು: ವೈಶಿಷ್ಟ್ಯವು ಹಲವಾರು ಬಿಡುಗಡೆಗಳಲ್ಲಿ ವರ್ಫ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ: ಆಲ್ಫಾ ಚಾನಲ್‌ನಲ್ಲಿ ಇದು ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸಿದ್ಧವಾಯಿತು , ಮತ್ತು ಬೀಟಾ ಚಾನಲ್‌ನಲ್ಲಿ - ಜೊತೆಗೆ .
ಎಲ್ಲಾ ಬಿಡುಗಡೆಗಳಿಗೆ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್
ಡಿಸೆಂಬರ್ 15, 2019 ರಿಂದ, werf ನ ಬೀಟಾ ಮತ್ತು ಆಲ್ಫಾ ಆವೃತ್ತಿಗಳು ಎಲ್ಲಾ ಬಿಡುಗಡೆಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪೂರ್ಣ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ.
ಈ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಸ್ಪಷ್ಟವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು WERF_THREE_WAY_MERGE_MODE=enabled ಈಗ.
ಸಂಪನ್ಮೂಲ ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು?
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ 2 ವಿಧದ ಆಟೋಸ್ಕೇಲಿಂಗ್ಗಳಿವೆ: HPA (ಸಮತಲ) ಮತ್ತು VPA (ಲಂಬ).
ಸಮತಲವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಲಂಬ - ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ. ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ಅಗತ್ಯತೆಗಳೆರಡನ್ನೂ ಸಂಪನ್ಮೂಲ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ (ಸಂಪನ್ಮೂಲ ಮ್ಯಾನಿಫೆಸ್ಟ್ ನೋಡಿ). spec.replicas ಅಥವಾ spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и ).
ಸಮಸ್ಯೆ: ಬಳಕೆದಾರರು ಚಾರ್ಟ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೆ ಅದು ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಕೆಲವು ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ ಅಥವಾ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಮತ್ತು ಆಟೋಸ್ಕೇಲರ್‌ಗಳನ್ನು ಈ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, ನಂತರ ಪ್ರತಿ ನಿಯೋಜನೆಯೊಂದಿಗೆ ವರ್ಫ್ ಈ ಮೌಲ್ಯಗಳನ್ನು ಚಾರ್ಟ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಬರೆಯಲಾದ ಮೌಲ್ಯಗಳಿಗೆ ಮರುಹೊಂದಿಸುತ್ತದೆ. .
ಸಮಸ್ಯೆಗೆ ಎರಡು ಪರಿಹಾರಗಳಿವೆ. ಮೊದಲಿಗೆ, ಚಾರ್ಟ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಸ್ವಯಂಪ್ರೇರಿತ ಮೌಲ್ಯಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸುವುದನ್ನು ತಪ್ಪಿಸುವುದು ಉತ್ತಮ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಈ ಆಯ್ಕೆಯು ಸೂಕ್ತವಲ್ಲದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ, ಆರಂಭಿಕ ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳನ್ನು ಮತ್ತು ಚಾರ್ಟ್‌ನಲ್ಲಿನ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸಲು ಅನುಕೂಲಕರವಾಗಿದೆ), ನಂತರ werf ಈ ಕೆಳಗಿನ ಟಿಪ್ಪಣಿಗಳನ್ನು ನೀಡುತ್ತದೆ:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
ಅಂತಹ ಟಿಪ್ಪಣಿ ಇದ್ದರೆ, werf ಪ್ರತಿ ನಿಯೋಜನೆಯಲ್ಲಿ ಅನುಗುಣವಾದ ಮೌಲ್ಯಗಳನ್ನು ಮರುಹೊಂದಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸಂಪನ್ಮೂಲವನ್ನು ಆರಂಭದಲ್ಲಿ ರಚಿಸಿದಾಗ ಮಾತ್ರ ಅವುಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ.
ಹೆಚ್ಚಿನ ವಿವರಗಳಿಗಾಗಿ, ಯೋಜನೆಯ ದಸ್ತಾವೇಜನ್ನು ನೋಡಿ и .
3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್ ಬಳಕೆಯನ್ನು ನಿಷೇಧಿಸಿ
ಪರಿಸರ ವೇರಿಯೇಬಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು werf ನಲ್ಲಿ ಹೊಸ ಪ್ಯಾಚ್‌ಗಳ ಬಳಕೆಯನ್ನು ಬಳಕೆದಾರರು ಪ್ರಸ್ತುತ ನಿಷೇಧಿಸಬಹುದು WERF_THREE_WAY_MERGE_MODE=disabled. ಆದಾಗ್ಯೂ, ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ ಮಾರ್ಚ್ 1, 2020 ರಿಂದ, ಈ ನಿಷೇಧವು ಇನ್ನು ಮುಂದೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಮತ್ತು 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ವರ್ಫ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳ ಅಳವಡಿಕೆ
3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವ ವಿಧಾನವನ್ನು ಮಾಸ್ಟರಿಂಗ್ ಮಾಡುವುದರಿಂದ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗೆ ಅಳವಡಿಸಿಕೊಳ್ಳುವಂತಹ ವೈಶಿಷ್ಟ್ಯವನ್ನು ತಕ್ಷಣವೇ ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
ಹೆಲ್ಮ್ 2 ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ: ಮೊದಲಿನಿಂದ ಈ ಸಂಪನ್ಮೂಲವನ್ನು ಮರುಸೃಷ್ಟಿಸದೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಚಾರ್ಟ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಿಗೆ ನೀವು ಸಂಪನ್ಮೂಲವನ್ನು ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ (ನೋಡಿ. , ) ಬಿಡುಗಡೆಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ನಾವು ವರ್ಫ್‌ಗೆ ಕಲಿಸಿದ್ದೇವೆ. ಇದನ್ನು ಮಾಡಲು, ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯಲ್ಲಿ ನೀವು ಟಿಪ್ಪಣಿಯನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಬಳಸಿ kubectl edit):
"werf.io/allow-adoption-by-release": RELEASE_NAMEಈಗ ಸಂಪನ್ಮೂಲವನ್ನು ಚಾರ್ಟ್‌ನಲ್ಲಿ ವಿವರಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಮುಂದಿನ ಬಾರಿ werf ಸೂಕ್ತ ಹೆಸರಿನೊಂದಿಗೆ ಬಿಡುಗಡೆಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಪನ್ಮೂಲವನ್ನು ಈ ಬಿಡುಗಡೆಗೆ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ನಿಯಂತ್ರಣದಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. ಇದಲ್ಲದೆ, ಬಿಡುಗಡೆಗಾಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ಸ್ವೀಕರಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ವರ್ಫ್ ಅದೇ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳು ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಸಂಪನ್ಮೂಲ ನಿಯಮವನ್ನು ಬಳಸಿಕೊಂಡು ಚಾರ್ಟ್‌ನಲ್ಲಿ ವಿವರಿಸಿದ ಸ್ಥಿತಿಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ತರುತ್ತದೆ.
ಹೇಳಿಕೆಯನ್ನು: ಸೆಟ್ಟಿಂಗ್ WERF_THREE_WAY_MERGE_MODE ಸಂಪನ್ಮೂಲಗಳ ಅಳವಡಿಕೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ - ಅಳವಡಿಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ, 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್ ಅನ್ನು ಯಾವಾಗಲೂ ಬಳಸಲಾಗುತ್ತದೆ.
ವಿವರಗಳು - ರಲ್ಲಿ .
ತೀರ್ಮಾನಗಳು ಮತ್ತು ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು
ಈ ಲೇಖನದ ನಂತರ 3-ವೇ-ವಿಲೀನ ಪ್ಯಾಚ್‌ಗಳು ಯಾವುವು ಮತ್ತು ಅವುಗಳು ಏಕೆ ಬಂದವು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ವರ್ಫ್ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯ ಪ್ರಾಯೋಗಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅವರ ಅನುಷ್ಠಾನವು ಹೆಲ್ಮ್ ತರಹದ ನಿಯೋಜನೆಯನ್ನು ಸುಧಾರಿಸುವ ಮತ್ತೊಂದು ಹಂತವಾಗಿದೆ. ಈಗ ನೀವು ಹೆಲ್ಮ್ 2 ಅನ್ನು ಬಳಸುವಾಗ ಹೆಚ್ಚಾಗಿ ಉದ್ಭವಿಸಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಮರೆತುಬಿಡಬಹುದು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಈಗಾಗಲೇ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾದ ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಹೊಸ ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಗೆ ಸೇರಿಸಲಾಗಿದೆ.
ಗೋ ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಬಳಕೆಯಂತಹ ಹೆಲ್ಮ್ ತರಹದ ನಿಯೋಜನೆಗಳೊಂದಿಗೆ ಇನ್ನೂ ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಸವಾಲುಗಳಿವೆ, ಅದನ್ನು ನಾವು ಪರಿಹರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.
ಸಂಪನ್ಮೂಲ ನವೀಕರಣ ವಿಧಾನಗಳು ಮತ್ತು ಅಳವಡಿಕೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಹ ಇಲ್ಲಿ ಕಾಣಬಹುದು .
ಹೆಲ್ಮ್ 3
ವಿಶೇಷ ಗಮನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿದೆ ಇನ್ನೊಂದು ದಿನ ಹೆಲ್ಮ್‌ನ ಹೊಸ ಪ್ರಮುಖ ಆವೃತ್ತಿ - v3 - ಇದು 3-ವೇ-ಮರ್ಜ್ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಸಹ ಬಳಸುತ್ತದೆ ಮತ್ತು ಟಿಲ್ಲರ್ ಅನ್ನು ತೊಡೆದುಹಾಕುತ್ತದೆ. ಹೆಲ್ಮ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗೆ ಅಗತ್ಯವಿದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅನುಸ್ಥಾಪನೆಗಳನ್ನು ಹೊಸ ಬಿಡುಗಡೆಯ ಶೇಖರಣಾ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಲು.
ವರ್ಫ್, ಅದರ ಭಾಗವಾಗಿ, ಪ್ರಸ್ತುತ ಟಿಲ್ಲರ್ ಬಳಸುವುದನ್ನು ತೊಡೆದುಹಾಕಿದೆ, 3-ವೇ-ಮರ್ಜ್‌ಗೆ ಬದಲಾಯಿಸಿದೆ ಮತ್ತು ಸೇರಿಸಲಾಗಿದೆ , ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹೆಲ್ಮ್ 2 ಸ್ಥಾಪನೆಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತಿರುವಾಗ (ಯಾವುದೇ ವಲಸೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ). ಆದ್ದರಿಂದ, werf ಹೆಲ್ಮ್ 3 ಗೆ ಬದಲಾಯಿಸುವವರೆಗೆ, werf ಬಳಕೆದಾರರು ಹೆಲ್ಮ್ 3 ಗಿಂತ ಹೆಲ್ಮ್ 2 ನ ಮುಖ್ಯ ಅನುಕೂಲಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ (werf ಸಹ ಅವುಗಳನ್ನು ಹೊಂದಿದೆ).
ಆದಾಗ್ಯೂ, ಹೆಲ್ಮ್ 3 ಕೋಡ್‌ಬೇಸ್‌ಗೆ ವರ್ಫ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಅನಿವಾರ್ಯವಾಗಿದೆ ಮತ್ತು ಇದು ಮುಂದಿನ ದಿನಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ಪ್ರಾಯಶಃ ಇದು werf 1.1 ಅಥವಾ werf 1.2 ಆಗಿರುತ್ತದೆ (ಈ ಸಮಯದಲ್ಲಿ, werf ನ ಮುಖ್ಯ ಆವೃತ್ತಿ 1.0 ಆಗಿದೆ; werf ಆವೃತ್ತಿಯ ಸಾಧನದ ಕುರಿತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ, ನೋಡಿ ) ಈ ಸಮಯದಲ್ಲಿ, ಹೆಲ್ಮ್ 3 ಸ್ಥಿರಗೊಳಿಸಲು ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಪಿಎಸ್
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- ವರ್ಫ್‌ನಲ್ಲಿನ ನಾವೀನ್ಯತೆಗಳ ಕುರಿತು ಟಿಪ್ಪಣಿಗಳ ಸರಣಿ:
- «";
- «";
- «».
- «";
- «";
- «».
ಮೂಲ: www.habr.com