ಹೆಲ್ಮ್‌ನೊಂದಿಗೆ ಬಹು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಾದ್ಯಂತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ

ಡೈಲಿಮೋಷನ್ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆ

ನಾವು ಡೈಲಿಮೋಷನ್‌ನಲ್ಲಿ 3 ವರ್ಷಗಳ ಹಿಂದೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಆದರೆ ಅನೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ವಿನೋದಮಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ನಾವು ನಮ್ಮ ಪರಿಕರಗಳು ಮತ್ತು ಕೆಲಸದ ಹರಿವುಗಳನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.

ಎಲ್ಲಿಂದ ಶುರುವಾಯಿತು

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

ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಕುಬರ್ನೆಟ್ಸ್ ವಸ್ತುಗಳನ್ನು ನಿಯೋಜಿಸಲು, ನಾವು ಬಳಸುತ್ತೇವೆ ಹೆಲ್ಮ್, ಮತ್ತು ನಮ್ಮ ಎಲ್ಲಾ ಚಾರ್ಟ್‌ಗಳನ್ನು ಒಂದೇ ಜಿಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಹಲವಾರು ಸೇವೆಗಳಿಂದ ಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟಾಕ್ ಅನ್ನು ನಿಯೋಜಿಸಲು, ನಾವು ಸಾರಾಂಶ ಚಾರ್ಟ್ ಎಂದು ಕರೆಯಲ್ಪಡುವದನ್ನು ಬಳಸುತ್ತೇವೆ. ಮೂಲಭೂತವಾಗಿ, ಇದು ಅವಲಂಬನೆಗಳನ್ನು ಘೋಷಿಸುವ ಚಾರ್ಟ್ ಆಗಿದೆ ಮತ್ತು API ಮತ್ತು ಅದರ ಸೇವೆಗಳನ್ನು ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಚೆಕ್‌ಗಳನ್ನು ಮಾಡಲು, ಚಾರ್ಟ್‌ಗಳನ್ನು ರಚಿಸಲು, ರಹಸ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಹೆಲ್ಮ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಸಣ್ಣ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಹ ಬರೆದಿದ್ದೇವೆ. ಈ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಡಾಕರ್ ಚಿತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಕೇಂದ್ರ CI ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.

ವಿಷಯಕ್ಕೆ ಬರೋಣ.

ಸೂಚನೆ. ನೀವು ಇದನ್ನು ಓದುತ್ತಿದ್ದಂತೆ, ಹೆಲ್ಮ್ 3 ಗಾಗಿ ಮೊದಲ ಬಿಡುಗಡೆಯ ಅಭ್ಯರ್ಥಿಯನ್ನು ಈಗಾಗಲೇ ಘೋಷಿಸಲಾಗಿದೆ. ನಾವು ಈ ಹಿಂದೆ ಎದುರಿಸಿದ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮುಖ್ಯ ಆವೃತ್ತಿಯು ಸಂಪೂರ್ಣ ಸುಧಾರಣೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಚಾರ್ಟ್ ಅಭಿವೃದ್ಧಿ ಕೆಲಸದ ಹರಿವು

ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಶಾಖೆಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಚಾರ್ಟ್‌ಗಳಿಗೆ ಅದೇ ವಿಧಾನವನ್ನು ಅನ್ವಯಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

• ಶಾಖೆ dev ಅಭಿವೃದ್ಧಿ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗುವ ಚಾರ್ಟ್‌ಗಳನ್ನು ರಚಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.
• ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿದಾಗ ಮಾಸ್ಟರ್, ಅವುಗಳನ್ನು ವೇದಿಕೆಯಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.
• ಅಂತಿಮವಾಗಿ, ಶಾಖೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ನಾವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ ಉತ್ಪನ್ನ ಮತ್ತು ಅವುಗಳನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅನ್ವಯಿಸಿ.

ಪ್ರತಿಯೊಂದು ಪರಿಸರವು ತನ್ನದೇ ಆದ ಖಾಸಗಿ ರೆಪೊಸಿಟರಿಯನ್ನು ಹೊಂದಿದ್ದು ಅದು ನಮ್ಮ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ನಾವು ಬಳಸುತ್ತೇವೆ ಚಾರ್ಟ್ ಮ್ಯೂಸಿಯಂ ಬಹಳ ಉಪಯುಕ್ತ API ಗಳೊಂದಿಗೆ. ಈ ರೀತಿಯಲ್ಲಿ ನಾವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಳಸುವ ಮೊದಲು ಚಾರ್ಟ್‌ಗಳ ಪರಿಸರಗಳು ಮತ್ತು ನೈಜ-ಪ್ರಪಂಚದ ಪರೀಕ್ಷೆಗಳ ನಡುವೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.

ವಿವಿಧ ಪರಿಸರದಲ್ಲಿ ಚಾರ್ಟ್ ರೆಪೊಸಿಟರಿಗಳು

ಡೆವಲಪರ್‌ಗಳು dev ಶಾಖೆಯನ್ನು ತಳ್ಳಿದಾಗ, ಅವರ ಚಾರ್ಟ್‌ನ ಆವೃತ್ತಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ dev Chartmuseum ಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. ಹೀಗಾಗಿ, ಎಲ್ಲಾ ಡೆವಲಪರ್‌ಗಳು ಒಂದೇ ಡೆವ್ ರೆಪೊಸಿಟರಿಯನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಆಕಸ್ಮಿಕವಾಗಿ ಬೇರೊಬ್ಬರ ಬದಲಾವಣೆಗಳನ್ನು ಬಳಸದಂತೆ ನಿಮ್ಮ ಚಾರ್ಟ್‌ನ ಆವೃತ್ತಿಯನ್ನು ನೀವು ಎಚ್ಚರಿಕೆಯಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗುತ್ತದೆ.

ಇದಲ್ಲದೆ, ನಮ್ಮ ಪುಟ್ಟ ಪೈಥಾನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಕುಬರ್ನೆಟ್ಸ್ ಓಪನ್ ಎಪಿಐ ವಿಶೇಷಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕುಬರ್ನೆಟ್ಸ್ ವಸ್ತುಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ ಕುಬೇವಲ್, ಅವುಗಳನ್ನು Chartmusem ನಲ್ಲಿ ಪ್ರಕಟಿಸುವ ಮೊದಲು.

ಚಾರ್ಟ್ ಅಭಿವೃದ್ಧಿ ಕೆಲಸದ ಹರಿವಿನ ಸಾಮಾನ್ಯ ವಿವರಣೆ

1. ನಿರ್ದಿಷ್ಟತೆಯ ಪ್ರಕಾರ ಪೈಪ್ಲೈನ್ ​​ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿಸುವುದು gazr.io ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ (ಲಿಂಟ್, ಯುನಿಟ್-ಟೆಸ್ಟ್).
2. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವ ಪೈಥಾನ್ ಪರಿಕರಗಳೊಂದಿಗೆ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ತಳ್ಳುವುದು.
3. ಶಾಖೆಯ ಹೆಸರಿನಿಂದ ಪರಿಸರವನ್ನು ಹೊಂದಿಸುವುದು.
4. Kubeval ಬಳಸಿಕೊಂಡು Kubernetes yaml ಫೈಲ್‌ಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗುತ್ತಿದೆ.
5. ಚಾರ್ಟ್ ಮತ್ತು ಅದರ ಮೂಲ ಚಾರ್ಟ್‌ಗಳ ಆವೃತ್ತಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚಿಸಿ (ಚಾರ್ಟ್ ಬದಲಾಗುತ್ತಿರುವ ಚಾರ್ಟ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ).
6. ಅದರ ಪರಿಸರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಚಾರ್ಟ್‌ಮ್ಯೂಸಿಯಂಗೆ ಚಾರ್ಟ್ ಅನ್ನು ಸಲ್ಲಿಸುವುದು

ಸಮೂಹಗಳಾದ್ಯಂತ ವ್ಯತ್ಯಾಸಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

ಸಮೂಹಗಳ ಒಕ್ಕೂಟ

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

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

ಜಿಯೋ-ವಿತರಣೆ ವೇದಿಕೆ

ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಪ್ರಸ್ತುತ 6 ಪ್ರದೇಶಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ - 3 ಸ್ಥಳೀಯವಾಗಿ ಮತ್ತು 3 ಕ್ಲೌಡ್‌ನಲ್ಲಿ.

ವಿತರಿಸಿದ ನಿಯೋಜನೆ

ಜಾಗತಿಕ ಹೆಲ್ಮ್ ಮೌಲ್ಯಗಳು

4 ಜಾಗತಿಕ ಹೆಲ್ಮ್ ಮೌಲ್ಯಗಳು ಕ್ಲಸ್ಟರ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಮ್ಮ ಎಲ್ಲಾ ಚಾರ್ಟ್‌ಗಳು ಡೀಫಾಲ್ಟ್ ಕನಿಷ್ಠ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿವೆ.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

ಜಾಗತಿಕ ಮೌಲ್ಯಗಳು

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

• "Cloud": ನಮ್ಮಲ್ಲಿ ಹೈಬ್ರಿಡ್ ಕುಬರ್ನೆಟ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಇದೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ API ಅನ್ನು GCP ವಲಯಗಳಲ್ಲಿ ಮತ್ತು ನಮ್ಮ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ.
• "env": ಉತ್ಪಾದನೆಯಲ್ಲದ ಪರಿಸರಕ್ಕೆ ಕೆಲವು ಮೌಲ್ಯಗಳು ಬದಲಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನಗಳು ಮತ್ತು ಆಟೋಸ್ಕೇಲಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು.
• "region": ಈ ಮಾಹಿತಿಯು ಕ್ಲಸ್ಟರ್‌ನ ಸ್ಥಳವನ್ನು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬಾಹ್ಯ ಸೇವೆಗಳಿಗಾಗಿ ಹತ್ತಿರದ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ನಿರ್ಧರಿಸಲು ಬಳಸಬಹುದು.
• "clusterName": ಒಂದು ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ನಾವು ಮೌಲ್ಯವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಬಯಸಿದರೆ ಮತ್ತು ಯಾವಾಗ.

ಒಂದು ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

ಹೆಲ್ಮ್ ಟೆಂಪ್ಲೇಟ್ ಉದಾಹರಣೆ

ಕುಬರ್ನೆಟ್ಸ್ YAML ಅನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಈ ತರ್ಕವನ್ನು ಸಹಾಯಕ ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕಟಣೆ

ನಮ್ಮ ನಿಯೋಜನೆ ಪರಿಕರಗಳು ಬಹು YAML ಫೈಲ್‌ಗಳನ್ನು ಆಧರಿಸಿವೆ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸೇವೆ ಮತ್ತು ಅದರ ಸ್ಕೇಲಿಂಗ್ ಟೋಪೋಲಜಿ (ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ) ಅನ್ನು ನಾವು ಹೇಗೆ ಘೋಷಿಸುತ್ತೇವೆ ಎಂಬುದರ ಉದಾಹರಣೆ ಕೆಳಗೆ ಇದೆ.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

ಸೇವೆಯ ವ್ಯಾಖ್ಯಾನ

ಇದು ನಮ್ಮ ನಿಯೋಜನೆ ಕೆಲಸದ ಹರಿವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಎಲ್ಲಾ ಹಂತಗಳ ರೂಪರೇಖೆಯಾಗಿದೆ. ಕೊನೆಯ ಹಂತವು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ವರ್ಕರ್ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.

ಜೆಂಕಿನ್ಸ್ ನಿಯೋಜನೆ ಹಂತಗಳು

ರಹಸ್ಯಗಳ ಬಗ್ಗೆ ಏನು?

ಭದ್ರತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾವು ವಿವಿಧ ಸ್ಥಳಗಳಿಂದ ಎಲ್ಲಾ ರಹಸ್ಯಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅನನ್ಯ ವಾಲ್ಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ವಾಲ್ಟ್ ಪ್ಯಾರೀಸಿನಲ್ಲಿ.

ನಮ್ಮ ನಿಯೋಜನೆ ಸಾಧನಗಳು ವಾಲ್ಟ್‌ನಿಂದ ರಹಸ್ಯ ಮೌಲ್ಯಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತವೆ ಮತ್ತು ನಿಯೋಜನೆ ಸಮಯ ಬಂದಾಗ, ಅವುಗಳನ್ನು ಹೆಲ್ಮ್‌ಗೆ ಸೇರಿಸಿ.

ಇದನ್ನು ಮಾಡಲು, ವಾಲ್ಟ್‌ನಲ್ಲಿರುವ ರಹಸ್ಯಗಳು ಮತ್ತು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ರಹಸ್ಯಗಳ ನಡುವಿನ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ನಾವು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದೇವೆ:

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

• ವಾಲ್ಟ್‌ನಲ್ಲಿ ರಹಸ್ಯಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡುವಾಗ ಅನುಸರಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ ನಿಯಮಗಳನ್ನು ನಾವು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದೇವೆ.
• ರಹಸ್ಯವು ಅನ್ವಯಿಸಿದರೆ ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭ ಅಥವಾ ಕ್ಲಸ್ಟರ್‌ಗೆ, ನೀವು ನಿರ್ದಿಷ್ಟ ನಮೂದನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ. (ಇಲ್ಲಿ ಸಂದರ್ಭ ಕ್ಲಸ್ಟರ್1 ರಹಸ್ಯ ಸ್ಟಾಕ್-ಅಪ್ಲಿಕೇಶನ್1-ಪಾಸ್‌ವರ್ಡ್‌ಗಾಗಿ ತನ್ನದೇ ಆದ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ).
• ಇಲ್ಲದಿದ್ದರೆ, ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ.
• ಈ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಐಟಂಗೆ ಕುಬರ್ನೆಟ್ಸ್ ರಹಸ್ಯ ಕೀ-ಮೌಲ್ಯದ ಜೋಡಿಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಮ್ಮ ಚಾರ್ಟ್‌ಗಳಲ್ಲಿನ ರಹಸ್ಯ ಟೆಂಪ್ಲೇಟ್ ತುಂಬಾ ಸರಳವಾಗಿದೆ.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

ತೊಂದರೆಗಳು ಮತ್ತು ಮಿತಿಗಳು

ಬಹು ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲಾಗುತ್ತಿದೆ

ಈಗ ನಾವು ಚಾರ್ಟ್‌ಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ. ಇದರರ್ಥ ಡೆವಲಪರ್‌ಗಳು ಎರಡು ಜಿಟ್ ರೆಪೊಸಿಟರಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕು: ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮತ್ತು ಇನ್ನೊಂದು ಅದರ ನಿಯೋಜನೆಯನ್ನು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲು. 2 ಜಿಟ್ ರೆಪೊಸಿಟರಿಗಳು ಎಂದರೆ 2 ವರ್ಕ್‌ಫ್ಲೋಗಳು ಮತ್ತು ಹೊಸಬರು ಗೊಂದಲಕ್ಕೊಳಗಾಗುವುದು ಸುಲಭ.

ಸಾಮಾನ್ಯೀಕೃತ ಚಾರ್ಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಒಂದು ಜಗಳವಾಗಿದೆ

ನಾವು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಅವಲಂಬನೆಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಬಹು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ನಿಯೋಜಿಸಲು ಜೆನೆರಿಕ್ ಚಾರ್ಟ್‌ಗಳು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿವೆ. ಆದರೆ ನಾವು ಬಳಸುತ್ತೇವೆ --reuse-valuesಈ ಸಾಮಾನ್ಯೀಕೃತ ಚಾರ್ಟ್‌ನ ಭಾಗವಾಗಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಾವು ನಿಯೋಜಿಸಿದಾಗಲೆಲ್ಲಾ ಎಲ್ಲಾ ಮೌಲ್ಯಗಳನ್ನು ರವಾನಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು.

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

ಬಹು ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ

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

ವಾಲ್ಟ್‌ನಲ್ಲಿ ಜೆಂಕಿನ್ಸ್ ಅನುಮತಿಗಳನ್ನು ತುಂಬಾ ವಿಸ್ತರಿಸಲಾಗಿದೆ

ಈಗ ನಾವು ಒಂದನ್ನು ಹೊಂದಿದ್ದೇವೆ AppRole, ಇದು ವಾಲ್ಟ್‌ನಿಂದ ಎಲ್ಲಾ ರಹಸ್ಯಗಳನ್ನು ಓದುತ್ತದೆ.

ರೋಲ್ಬ್ಯಾಕ್ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿಲ್ಲ

ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡಲು, ನೀವು ಹಲವಾರು ಕ್ಲಸ್ಟರ್ಗಳಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಇದು ದೋಷಗಳಿಂದ ತುಂಬಿದೆ. ಸರಿಯಾದ ಆವೃತ್ತಿಯ ಐಡಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಈ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತೇವೆ.

ನಾವು GitOps ಕಡೆಗೆ ಚಲಿಸುತ್ತಿದ್ದೇವೆ

ನಮ್ಮ ಗುರಿ

ನಾವು ಚಾರ್ಟ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ರೆಪೊಸಿಟರಿಗೆ ಹಿಂತಿರುಗಿಸಲು ಬಯಸುತ್ತೇವೆ.

ಕೆಲಸದ ಹರಿವು ಅಭಿವೃದ್ಧಿಯಂತೆಯೇ ಇರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಶಾಖೆಯನ್ನು ಮಾಸ್ಟರ್‌ಗೆ ತಳ್ಳಿದಾಗ, ನಿಯೋಜನೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಚೋದಿಸಲ್ಪಡುತ್ತದೆ. ಈ ವಿಧಾನ ಮತ್ತು ಪ್ರಸ್ತುತ ಕೆಲಸದ ಹರಿವಿನ ನಡುವಿನ ಪ್ರಮುಖ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅದು ಎಲ್ಲವನ್ನೂ git ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ (ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಮತ್ತು ಅದನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸುವ ವಿಧಾನ).

ಹಲವಾರು ಅನುಕೂಲಗಳಿವೆ:

• ಹೆಚ್ಚು ಸ್ಪಷ್ಟ ಡೆವಲಪರ್‌ಗಾಗಿ. ಸ್ಥಳೀಯ ಚಾರ್ಟ್‌ನಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸಬೇಕು ಎಂಬುದನ್ನು ಕಲಿಯುವುದು ಸುಲಭವಾಗಿದೆ.
• ಸೇವೆಯ ನಿಯೋಜನೆಯ ವ್ಯಾಖ್ಯಾನವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು ಕೋಡ್ನಂತೆಯೇ ಅದೇ ಸ್ಥಳ ಸೇವೆ.
• ಸಾಮಾನ್ಯೀಕೃತ ಚಾರ್ಟ್‌ಗಳ ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು. ಸೇವೆಯು ತನ್ನದೇ ಆದ ಹೆಲ್ಮ್ ಬಿಡುಗಡೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇತರ ಸೇವೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ, ಚಿಕ್ಕ ಮಟ್ಟದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಜೀವನಚಕ್ರವನ್ನು (ರೋಲ್‌ಬ್ಯಾಕ್, ಅಪ್‌ಗ್ರೇಡ್) ನಿರ್ವಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
• ಜಿಟ್‌ನ ಪ್ರಯೋಜನಗಳು ಚಾರ್ಟ್ ನಿರ್ವಹಣೆಗಾಗಿ: ಬದಲಾವಣೆಗಳನ್ನು ರದ್ದುಗೊಳಿಸಿ, ಆಡಿಟ್ ಲಾಗ್, ಇತ್ಯಾದಿ. ನೀವು ಚಾರ್ಟ್‌ಗೆ ಬದಲಾವಣೆಯನ್ನು ರದ್ದುಗೊಳಿಸಬೇಕಾದರೆ, ನೀವು ಇದನ್ನು git ಬಳಸಿ ಮಾಡಬಹುದು. ನಿಯೋಜನೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
• ಅಂತಹ ಸಾಧನಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಅಭಿವೃದ್ಧಿ ಕೆಲಸದ ಹರಿವನ್ನು ಸುಧಾರಿಸಲು ನೀವು ಪರಿಗಣಿಸಬಹುದು ಸ್ಕ್ಯಾಫೋಲ್ಡ್, ಇದರೊಂದಿಗೆ ಡೆವಲಪರ್‌ಗಳು ಉತ್ಪಾದನೆಗೆ ಹತ್ತಿರವಿರುವ ಸನ್ನಿವೇಶದಲ್ಲಿ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು.

ಎರಡು ಹಂತದ ವಲಸೆ

ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಈಗ 2 ವರ್ಷಗಳಿಂದ ಈ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ವಲಸೆಯು ಸಾಧ್ಯವಾದಷ್ಟು ನೋವುರಹಿತವಾಗಿರಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಗುರಿಯ ಹಾದಿಯಲ್ಲಿ ಮಧ್ಯಂತರ ಹಂತವನ್ನು ಸೇರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಮೊದಲ ಹಂತವು ಸರಳವಾಗಿದೆ:

• ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆಯನ್ನು ಹೊಂದಿಸಲು ನಾವು ಒಂದೇ ರೀತಿಯ ರಚನೆಯನ್ನು ಇರಿಸುತ್ತೇವೆ, ಆದರೆ ಡೈಲಿಮೋಷನ್ ರಿಲೀಸ್ ಎಂಬ ಒಂದೇ ವಸ್ತುವಿನಲ್ಲಿ.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

• ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ 1 ಬಿಡುಗಡೆ (ಸಾಮಾನ್ಯೀಕೃತ ಚಾರ್ಟ್‌ಗಳಿಲ್ಲದೆ).
• ಅಪ್ಲಿಕೇಶನ್‌ನ ಜಿಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಚಾರ್ಟ್‌ಗಳು.

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

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

ಮೂಲ: www.habr.com