ಗ್ರಾಹಕರ ವೇದಿಕೆಯಲ್ಲಿ ನಿರಂತರ ನಿಯೋಜನೆಯ ನಮ್ಮ ಅನುಷ್ಠಾನ

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

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

ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ನಿರಂತರ ನಿಯೋಜನೆ (ಸಿಡಿ) ಪ್ರಕ್ರಿಯೆಯ ಎಲ್ಲಾ ಹಂತಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ, ಅಥವಾ ಗ್ರಾಹಕರ ವೇದಿಕೆಗೆ ನವೀಕರಣಗಳ ವಿತರಣೆ:

1. ಈ ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ?
2. ಗ್ರಾಹಕರ Git ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್,
3. ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗದ ಜೋಡಣೆ,
4. ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆ,
5. ಉತ್ಪನ್ನಕ್ಕೆ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ.

ನಾವು ಸೆಟಪ್ ವಿವರಗಳನ್ನು ದಾರಿಯುದ್ದಕ್ಕೂ ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.

1. CD ಪ್ರಾರಂಭಿಸಿ

ಡೆವಲಪರ್ ನಮ್ಮ Git ರೆಪೊಸಿಟರಿಯ ಬಿಡುಗಡೆ ಶಾಖೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ತಳ್ಳುವುದರೊಂದಿಗೆ ನಿರಂತರ ನಿಯೋಜನೆಯು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಒಂದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಬದಲಾಯಿಸಿದ್ದರೂ ಸಹ, ಎಲ್ಲಾ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ.

ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ನಾವು ಒಂದು ರೆಪೊಸಿಟರಿಯ ಮೂಲಕ ಕೆಲಸವನ್ನು ಆಯೋಜಿಸಿದ್ದೇವೆ:

• ಅಭಿವೃದ್ಧಿಯ ಸುಲಭ - ಅಪ್ಲಿಕೇಶನ್ ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಎಲ್ಲಾ ಕೋಡ್‌ಗಳೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು.
• ಒಂದೇ CI/CD ಪೈಪ್‌ಲೈನ್ ಒಂದೇ ಸಿಸ್ಟಮ್ ಆಗಿ ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕರ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ತಲುಪಿಸುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸುತ್ತದೆ.
• ನಾವು ಆವೃತ್ತಿಗಳಲ್ಲಿನ ಗೊಂದಲವನ್ನು ನಿವಾರಿಸುತ್ತೇವೆ - ನಾವು ಮೈಕ್ರೋ ಸರ್ವಿಸ್ ಆವೃತ್ತಿಗಳ ನಕ್ಷೆಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗಿಲ್ಲ ಮತ್ತು ಹೆಲ್ಮ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಲ್ಲಿ ಪ್ರತಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗೆ ಅದರ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ವಿವರಿಸಬೇಕಾಗಿಲ್ಲ.

2. ಗ್ರಾಹಕರ ಮೂಲ ಕೋಡ್‌ನ Git ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್

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

ನಾವು ಗ್ರಾಹಕರ ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಏಕೆಂದರೆ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷೆಗಾಗಿ ನಮಗೆ ನಮ್ಮದೇ ಆದ ಪರಿಸರಗಳು ಬೇಕಾಗುತ್ತವೆ. ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ನಮ್ಮ Git ರೆಪೊಸಿಟರಿಯನ್ನು ಬಳಸುತ್ತೇವೆ - ಅದನ್ನು ಅವರ Git ರೆಪೊಸಿಟರಿಯೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ. ನಮ್ಮ ರೆಪೊಸಿಟರಿಯ ಸೂಕ್ತ ಶಾಖೆಗೆ ಡೆವಲಪರ್ ಪೋಸ್ಟ್ ಮಾಡಿದ ತಕ್ಷಣ, GitLab ತಕ್ಷಣವೇ ಈ ಬದಲಾವಣೆಗಳನ್ನು ಗ್ರಾಹಕರಿಗೆ ತಳ್ಳುತ್ತದೆ.

ಇದರ ನಂತರ ನೀವು ಜೋಡಣೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಇದು ಹಲವಾರು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗದ ಜೋಡಣೆ, ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ವಿತರಣೆ.

3. ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗವನ್ನು ಜೋಡಿಸುವುದು

ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮುಂಭಾಗವನ್ನು ನಿರ್ಮಿಸುವುದು GitLab ರನ್ನರ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಿರ್ವಹಿಸುವ ಎರಡು ಸಮಾನಾಂತರ ಕಾರ್ಯಗಳಾಗಿವೆ. ಅದರ ಮೂಲ ಜೋಡಣೆಯ ಸಂರಚನೆಯು ಅದೇ ರೆಪೊಸಿಟರಿಯಲ್ಲಿದೆ.

GitLab ನಲ್ಲಿ ನಿರ್ಮಿಸಲು YAML ಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯಲು ಟ್ಯುಟೋರಿಯಲ್.

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

ಡಾಕರ್‌ನಲ್ಲಿ ಪ್ರಕಟವಾಗುವ ಬಿಡುಗಡೆಯ ಆವೃತ್ತಿಯೊಂದಿಗೆ ನಾವು ನಮ್ಮ ಚಿತ್ರಗಳ ಆವೃತ್ತಿಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುತ್ತೇವೆ. ಸುಗಮ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ನಾವು ಹಲವಾರು ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ:

1. ಪರೀಕ್ಷಾ ಪರಿಸರ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದ ನಡುವೆ ಕಂಟೇನರ್‌ಗಳನ್ನು ಮರುನಿರ್ಮಿಸಲಾಗುವುದಿಲ್ಲ. ನಾವು ನಿಯತಾಂಕಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ ಒಂದೇ ಕಂಟೇನರ್ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಾ ಪರಿಸರದಲ್ಲಿ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮರುನಿರ್ಮಾಣವಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

2. ಹೆಲ್ಮ್ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸಲು, ನೀವು ಅದರ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು. ನಾವು ಬ್ಯಾಕೆಂಡ್, ಮುಂಭಾಗವನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ - ಇವು ಮೂರು ವಿಭಿನ್ನ ಕಾರ್ಯಗಳಾಗಿವೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದೇ ಆವೃತ್ತಿಯನ್ನು ಎಲ್ಲೆಡೆ ಬಳಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಈ ಕಾರ್ಯಕ್ಕಾಗಿ, ನಾವು Git ಇತಿಹಾಸದಿಂದ ಡೇಟಾವನ್ನು ಬಳಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ನಮ್ಮ K8S ಕ್ಲಸ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿವೆ.

ಕಮಾಂಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಫಲಿತಾಂಶಗಳಿಂದ ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಆವೃತ್ತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ
git describe --tags --abbrev=7.

4. ಪರೀಕ್ಷಾ ಪರಿಸರಕ್ಕೆ (UAT) ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ

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

ಕ್ಲಸ್ಟರ್ ನವೀಕರಣವನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಹೆಲ್ಮ್ ನವೀಕರಣ. ಪರಿಣಾಮವಾಗಿ, ಯೋಜನೆಯ ಪ್ರಕಾರ ಏನಾದರೂ ಹೋಗದಿದ್ದರೆ, ಹೆಲ್ಮ್ ತನ್ನ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತು ಸ್ವತಂತ್ರವಾಗಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಅವನ ಕೆಲಸವನ್ನು ನಿಯಂತ್ರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ನಾವು ಅಸೆಂಬ್ಲಿ ಜೊತೆಗೆ K8S ಕ್ಲಸ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪೂರೈಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಅದನ್ನು ನವೀಕರಿಸುವುದು ಮುಂದಿನ ಹಂತವಾಗಿದೆ: ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ಗಳು, ನಿಯೋಜನೆಗಳು, ಸೇವೆಗಳು, ರಹಸ್ಯಗಳು ಮತ್ತು ನಾವು ಬದಲಾಯಿಸಿದ ಯಾವುದೇ ಇತರ K8S ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು.

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

5. ಉತ್ಪನ್ನಕ್ಕೆ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆ

ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ನವೀಕರಣವನ್ನು ನಿಯೋಜಿಸಲು, ನೀವು GitLab ನಲ್ಲಿ ಒಂದು ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ - ಮತ್ತು ಕಂಟೇನರ್‌ಗಳನ್ನು ತಕ್ಷಣವೇ ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ.

ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಪುನರ್ನಿರ್ಮಾಣವಿಲ್ಲದೆ ವಿವಿಧ ಪರಿಸರದಲ್ಲಿ-ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು. ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಏನನ್ನೂ ಬದಲಾಯಿಸದೆ ನಾವು ಅದೇ ಕಲಾಕೃತಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ನಿಯತಾಂಕಗಳನ್ನು ಬಾಹ್ಯವಾಗಿ ಹೊಂದಿಸುತ್ತೇವೆ.

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

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

ಅಪ್ಲಿಕೇಶನ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಅವುಗಳ ಮೌಲ್ಯಗಳನ್ನು ಕೆ 8 ಎಸ್ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಬಳಸಿ ಕಂಟೈನರ್‌ಗಳಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ, ಇದನ್ನು ಗೋ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಬಳಸಿ ಟೆಂಪ್ಲೇಟ್ ಮಾಡಲಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಡೊಮೇನ್ ಹೆಸರಿಗೆ ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಈ ರೀತಿ ಮಾಡಬಹುದು:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - ಈ ವೇರಿಯಬಲ್ ಪರಿಸರದ ಹೆಸರನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ (ಉತ್ಪನ್ನ, ಹಂತ, UAT).
.Values.app.properties.app_external_domain – ಈ ವೇರಿಯೇಬಲ್‌ನಲ್ಲಿ ನಾವು ಬಯಸಿದ ಡೊಮೇನ್ ಅನ್ನು .Values.yaml ಫೈಲ್‌ನಲ್ಲಿ ಹೊಂದಿಸುತ್ತೇವೆ

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸುವಾಗ, ಹೆಲ್ಮ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಂದ configmap.yaml ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅಪ್‌ಡೇಟ್ ಪ್ರಾರಂಭವಾಗುವ ಪರಿಸರವನ್ನು ಅವಲಂಬಿಸಿ ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯದೊಂದಿಗೆ APP_EXTERNAL_DOMAIN ಮೌಲ್ಯವನ್ನು ತುಂಬುತ್ತದೆ. ಈ ವೇರಿಯಬಲ್ ಅನ್ನು ಈಗಾಗಲೇ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ. ಇದನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಪ್ರವೇಶಿಸಬಹುದು, ಆದ್ದರಿಂದ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಪರಿಸರವು ಈ ವೇರಿಯಬಲ್‌ಗೆ ವಿಭಿನ್ನ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

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

ಒಟ್ಟು

ಆದ್ದರಿಂದ, ನಿರಂತರ ನಿಯೋಜನೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಎಲ್ಲಾ ನವೀಕರಣಗಳು ಒಂದು ಕೀಸ್ಟ್ರೋಕ್ನೊಂದಿಗೆ ಸಂಭವಿಸುತ್ತವೆ. ಉತ್ಪನ್ನ ಪರಿಸರಕ್ಕೆ ಬದಲಾವಣೆಗಳ ವಿತರಣೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿರುತ್ತದೆ. ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ನವೀಕರಣಗಳು ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ.

ಭವಿಷ್ಯದ ಯೋಜನೆಗಳು: ಸ್ವಯಂಚಾಲಿತ ಡೇಟಾಬೇಸ್ ವಲಸೆ

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

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

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

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

ಮೂಲ: www.habr.com