Linux ನಲ್ಲಿ .NET ಕೋರ್, ಕುದುರೆಯ ಮೇಲೆ DevOps

ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ DevOps ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ನಮ್ಮಲ್ಲಿ 8 ಮಂದಿ ಇದ್ದೆವು, ಮತ್ತು ವಾಸ್ಯಾ ವಿಂಡೋಸ್‌ನಲ್ಲಿ ತಂಪಾಗಿದ್ದರು. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ವಾಸ್ಯಾ ಹೊರಟುಹೋದರು, ಮತ್ತು ವಿಂಡೋಸ್ ಅಭಿವೃದ್ಧಿಯಿಂದ ಒದಗಿಸಲಾದ ಹೊಸ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಕಾರ್ಯವನ್ನು ನಾನು ಹೊಂದಿದ್ದೇನೆ. ನಾನು ಸಂಪೂರ್ಣ ವಿಂಡೋಸ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸ್ಟಾಕ್ ಅನ್ನು ಮೇಜಿನ ಮೇಲೆ ಎಸೆದಾಗ, ಪರಿಸ್ಥಿತಿಯು ನೋವಿನಿಂದ ಕೂಡಿದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ ...

ಕಥೆ ಆರಂಭವಾಗುವುದು ಹೀಗೆ ಅಲೆಕ್ಸಾಂಡ್ರಾ ಸಿಂಚಿನೋವಾ ಮೇಲೆ DevOpsConf. ಪ್ರಮುಖ ವಿಂಡೋಸ್ ತಜ್ಞರು ಕಂಪನಿಯನ್ನು ತೊರೆದಾಗ, ಅಲೆಕ್ಸಾಂಡರ್ ಈಗ ಏನು ಮಾಡಬೇಕೆಂದು ಯೋಚಿಸಿದನು. ಲಿನಕ್ಸ್‌ಗೆ ಬದಲಿಸಿ, ಸಹಜವಾಗಿ! 100 ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಪೂರ್ಣಗೊಂಡ ಯೋಜನೆಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ವಿಂಡೋಸ್ ಅಭಿವೃದ್ಧಿಯ ಭಾಗವನ್ನು ಲಿನಕ್ಸ್‌ಗೆ ಹೇಗೆ ಪೂರ್ವನಿದರ್ಶನವನ್ನು ರಚಿಸಲು ಮತ್ತು ವರ್ಗಾಯಿಸಲು ಅವರು ನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆಂದು ಅಲೆಕ್ಸಾಂಡರ್ ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ.

TFS, Puppet, Linux .NET ಕೋರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು RPM ಗೆ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಮತ್ತು ಸಲೀಸಾಗಿ ತಲುಪಿಸುವುದು ಹೇಗೆ? ಡೆವಲಪ್‌ಮೆಂಟ್ ತಂಡವು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಮತ್ತು ಫ್ಲೈವೇ ಪದಗಳನ್ನು ಮೊದಲ ಬಾರಿಗೆ ಕೇಳಿದರೆ ಮತ್ತು ಗಡುವು ನಾಳೆಯ ನಂತರದ ದಿನವಾಗಿದ್ದರೆ ಪ್ರಾಜೆಕ್ಟ್ ಡೇಟಾಬೇಸ್‌ನ ಆವೃತ್ತಿಯನ್ನು ಹೇಗೆ ಬೆಂಬಲಿಸುವುದು? ಡಾಕರ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂಯೋಜಿಸುವುದು? ಪಪಿಟ್ ಮತ್ತು ಲಿನಕ್ಸ್ ಪರವಾಗಿ ವಿಂಡೋಸ್ ಮತ್ತು ಸ್ಮೂಥಿಗಳನ್ನು ತ್ಯಜಿಸಲು .NET ಡೆವಲಪರ್‌ಗಳನ್ನು ಪ್ರೇರೇಪಿಸುವುದು ಹೇಗೆ? ಉತ್ಪಾದನೆಯಲ್ಲಿ ವಿಂಡೋಸ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಶಕ್ತಿ, ಬಯಕೆ ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳು ಇಲ್ಲದಿದ್ದರೆ ಸೈದ್ಧಾಂತಿಕ ಸಂಘರ್ಷಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು? ಇದರ ಬಗ್ಗೆ, ಹಾಗೆಯೇ ವೆಬ್ ಡಿಪ್ಲೋಯ್, ಟೆಸ್ಟಿಂಗ್, ಸಿಐ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯೋಜನೆಗಳಲ್ಲಿ TFS ಅನ್ನು ಬಳಸುವ ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಮತ್ತು, ಸಹಜವಾಗಿ, ಮುರಿದ ಊರುಗೋಲುಗಳು ಮತ್ತು ಕೆಲಸದ ಪರಿಹಾರಗಳ ಬಗ್ಗೆ, ಅಲೆಕ್ಸಾಂಡರ್ ವರದಿಯ ಪ್ರತಿಲೇಖನದಲ್ಲಿ.

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

ನಾವು DevOps ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವುದರಿಂದ, ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಲುಪಿಸುವ ವಿಧಾನದಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ. ಒಂದೇ ಒಂದು ಪರಿಹಾರವಿತ್ತು - ಸಾಧ್ಯವಾದರೆ, ಎಲ್ಲವನ್ನೂ ಲಿನಕ್ಸ್‌ಗೆ ವರ್ಗಾಯಿಸಿ. ಗೂಗಲ್ ನನಗೆ ಸಹಾಯ ಮಾಡಿತು - ಆ ಸಮಯದಲ್ಲಿ .ನೆಟ್ ಅನ್ನು ಈಗಾಗಲೇ ಲಿನಕ್ಸ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಇದು ಪರಿಹಾರವಾಗಿದೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ!

ಲಿನಕ್ಸ್ ಜೊತೆಗೆ .NET ಕೋರ್ ಏಕೆ?

ಇದಕ್ಕೆ ಹಲವಾರು ಕಾರಣಗಳಿದ್ದವು. “ಹಣವನ್ನು ಪಾವತಿಸಿ” ಮತ್ತು “ಪಾವತಿಸಬೇಡಿ” ನಡುವೆ, ಬಹುಪಾಲು ಜನರು ಎರಡನೆಯದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ - ನನ್ನಂತೆ. MSDB ಗಾಗಿ ಪರವಾನಗಿಯು ಸುಮಾರು $1 ವೆಚ್ಚವಾಗುತ್ತದೆ; ವಿಂಡೋಸ್ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಸಮೂಹವನ್ನು ನಿರ್ವಹಿಸಲು ನೂರಾರು ಡಾಲರ್‌ಗಳು ವೆಚ್ಚವಾಗುತ್ತದೆ. ದೊಡ್ಡ ಕಂಪನಿಗೆ ಇದು ದೊಡ್ಡ ವೆಚ್ಚವಾಗಿದೆ. ಅದಕ್ಕೇ ಉಳಿತಾಯ - ಮೊದಲ ಕಾರಣ. ಮುಖ್ಯವಲ್ಲ, ಆದರೆ ಗಮನಾರ್ಹವಾದವುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

ವಿಂಡೋಸ್ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ತಮ್ಮ ಲಿನಕ್ಸ್ ಸಹೋದರರಿಗಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ - ಅವು ಭಾರವಾಗಿವೆ. ದೊಡ್ಡ ಕಂಪನಿಯ ಪ್ರಮಾಣವನ್ನು ಗಮನಿಸಿದರೆ, ನಾವು ಲಿನಕ್ಸ್ ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ.

ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CI ಗೆ ಸರಳವಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ. ನಾವು ನಮ್ಮನ್ನು ಪ್ರಗತಿಪರ DevOps ಎಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ, ನಾವು ಬಿದಿರು, ಜೆಂಕಿನ್ಸ್ ಮತ್ತು GitLab CI ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಮ್ಮ ಹೆಚ್ಚಿನ ಕೆಲಸವು Linux ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ.

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

ಅವಶ್ಯಕತೆಗಳನ್ನು

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

ಹೊಸ ಯೋಜನೆಯ ಅಗತ್ಯವಿದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CI ಗೆ ಸಂಯೋಜಿಸಿ. ಹಳಿಗಳು ಈಗಾಗಲೇ ಅಲ್ಲಿದ್ದವು ಮತ್ತು ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆ, ಅಂಗೀಕೃತ ವಿತರಣಾ ಮಾನದಂಡಗಳು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ನಿಯತಾಂಕಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು.

ಬೆಂಬಲ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಸುಲಭ, ವಿವಿಧ ವಿಭಾಗಗಳು ಮತ್ತು ಬೆಂಬಲ ಇಲಾಖೆಯಿಂದ ಎಲ್ಲಾ ಹೊಸ ಭಾಗವಹಿಸುವವರಿಗೆ ಕನಿಷ್ಠ ಪ್ರವೇಶ ಮಿತಿಗೆ ಷರತ್ತು.

ಕೊನೆಯ ದಿನಾಂಕ - ನಿನ್ನೆ.

ಅಭಿವೃದ್ಧಿ ಗುಂಪನ್ನು ಗೆಲ್ಲಿರಿ

ಆಗ ವಿಂಡೋಸ್ ತಂಡವು ಏನು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು?

ಈಗ ನಾನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಹೇಳಬಲ್ಲೆ ಐಡೆಂಟಿಟಿ ಸರ್ವರ್ 4 ಒಂದೇ ರೀತಿಯ ಸಾಮರ್ಥ್ಯಗಳೊಂದಿಗೆ ADFS ಗೆ ಉಚಿತ ಪರ್ಯಾಯವಾಗಿದೆ, ಅಥವಾ ಏನು ಎಂಟಿಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕೋರ್ - ಡೆವಲಪರ್‌ಗಾಗಿ ಸ್ವರ್ಗ, ಅಲ್ಲಿ ನೀವು SQL ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯಲು ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ OOP ನಿಯಮಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿವರಿಸಿ. ಆದರೆ ನಂತರ, ಕ್ರಿಯಾ ಯೋಜನೆಯ ಚರ್ಚೆಯ ಸಮಯದಲ್ಲಿ, ನಾನು ಈ ಸ್ಟಾಕ್ ಅನ್ನು ಸುಮೇರಿಯನ್ ಕ್ಯೂನಿಫಾರ್ಮ್ ಎಂದು ನೋಡಿದೆ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಮತ್ತು ಜಿಟ್ ಅನ್ನು ಮಾತ್ರ ಗುರುತಿಸಿದೆ.

ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತಿದ್ದೆವು ಬೊಂಬೆ ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿ. ನಮ್ಮ ಹೆಚ್ಚಿನ ಯೋಜನೆಗಳಲ್ಲಿ ನಾವು ಬಳಸಿದ್ದೇವೆ ಗಿಟ್ಲ್ಯಾಬ್ ಸಿಐ, ಸ್ಥಿತಿಸ್ಥಾಪಕ, ಸಮತೋಲಿತ ಹೆಚ್ಚಿನ ಲೋಡ್ ಸೇವೆಗಳನ್ನು ಬಳಸಿ HAProxy ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದರು ಜಬ್ಬಿಕ್ಸ್, ಅಸ್ಥಿರಜ್ಜುಗಳು ಗ್ರಾಫಾನಾ и ಪ್ರಮೀತಿಯಸ್, ಜೇಗರ್, ಮತ್ತು ಇದೆಲ್ಲವೂ ಕಬ್ಬಿಣದ ತುಂಡುಗಳ ಮೇಲೆ ತಿರುಗುತ್ತಿತ್ತು HP c ESXi ಮೇಲೆ ವರೆ. ಎಲ್ಲರಿಗೂ ಇದು ತಿಳಿದಿದೆ - ಪ್ರಕಾರದ ಶ್ರೇಷ್ಠ.

ನಾವು ಈ ಎಲ್ಲಾ ಮಧ್ಯಸ್ಥಿಕೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೋಡೋಣ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸೋಣ.

ಏನಾಯಿತು

TFS ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು ಅದು ಡೆವಲಪರ್‌ನಿಂದ ಅಂತಿಮ ಉತ್ಪಾದನಾ ಯಂತ್ರಕ್ಕೆ ಕೋಡ್ ಅನ್ನು ತಲುಪಿಸುತ್ತದೆ, ಆದರೆ ವಿವಿಧ ಸೇವೆಗಳೊಂದಿಗೆ ಅತ್ಯಂತ ಹೊಂದಿಕೊಳ್ಳುವ ಏಕೀಕರಣಕ್ಕಾಗಿ ಒಂದು ಸೆಟ್ ಅನ್ನು ಹೊಂದಿದೆ - ಕ್ರಾಸ್-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮಟ್ಟದಲ್ಲಿ CI ಅನ್ನು ಒದಗಿಸಲು.

ಹಿಂದೆ, ಇವು ಘನ ಕಿಟಕಿಗಳಾಗಿದ್ದವು. TFS ಹಲವಾರು ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸಿದೆ, ಇದನ್ನು ಅನೇಕ ಯೋಜನೆಗಳನ್ನು ಜೋಡಿಸಲು ಬಳಸಲಾಗುತ್ತಿತ್ತು. ಪ್ರತಿ ಏಜೆಂಟ್ ಕಾರ್ಯಗಳನ್ನು ಸಮಾನಾಂತರಗೊಳಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು 3-4 ಕೆಲಸಗಾರರನ್ನು ಹೊಂದಿದೆ. ನಂತರ, ಬಿಡುಗಡೆಯ ಯೋಜನೆಗಳ ಪ್ರಕಾರ, TFS ಹೊಸದಾಗಿ ಬೇಯಿಸಿದ ಬಿಲ್ಡ್ ಅನ್ನು ವಿಂಡೋಸ್ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗೆ ತಲುಪಿಸಿತು.

ನಾವು ಏನನ್ನು ಸಾಧಿಸಲು ಬಯಸಿದ್ದೇವೆ?

ನಾವು ವಿತರಣೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಗಾಗಿ TFS ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು Linux ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನಲ್ಲಿ ರನ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಕೆಲವು ರೀತಿಯ ಮ್ಯಾಜಿಕ್ ಇರುತ್ತದೆ. ಈ ಮ್ಯಾಜಿಕ್ ಬಾಕ್ಸ್ ಮತ್ತು ಮುಂದೆ ಕೆಲಸದ ಉಪ್ಪು ಇದೆ. ನಾನು ಅದನ್ನು ಬೇರ್ಪಡಿಸುವ ಮೊದಲು, ನಾನು ಒಂದು ಹೆಜ್ಜೆ ಪಕ್ಕಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಕೆಲವು ಮಾತುಗಳನ್ನು ಹೇಳುತ್ತೇನೆ.

ಯೋಜನೆಯು

ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಿಪೇಯ್ಡ್ ಕಾರ್ಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್

ಎರಡು ರೀತಿಯ ಬಳಕೆದಾರರಿದ್ದರು. ಮೊದಲನೆಯದು SSL SHA-2 ಪ್ರಮಾಣಪತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಲಾಗ್ ಇನ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರವೇಶವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ. ಯು ಎರಡನೇ ಲಾಗಿನ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಬಳಸಿ ಪ್ರವೇಶವಿತ್ತು.

ಹ್ಯಾಪ್ರೊಕ್ಸಿ

ನಂತರ ಕ್ಲೈಂಟ್ ವಿನಂತಿಯು HAProxy ಗೆ ಹೋಯಿತು, ಅದು ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದೆ:

• ಪ್ರಾಥಮಿಕ ಅಧಿಕಾರ;
• SSL ಮುಕ್ತಾಯ;
• HTTP ವಿನಂತಿಗಳನ್ನು ಶ್ರುತಿಗೊಳಿಸುವುದು;
• ಪ್ರಸಾರ ವಿನಂತಿಗಳು.

ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸರಣಿಯ ಉದ್ದಕ್ಕೂ ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ನಾವು - ಅಧಿಕಾರ ಮತ್ತು ನಾವು ಇದನ್ನು ನಿಭಾಯಿಸಬಹುದು, ಏಕೆಂದರೆ ನಾವು ಸೇವಾ ಗ್ರಾಹಕರಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡುತ್ತೇವೆ.

ಮೂರನೇ ಅಂಶಕ್ಕೆ ಗಮನ ಕೊಡಿ, ನಾವು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಹಿಂತಿರುಗುತ್ತೇವೆ.

ಬ್ಯಾಕೆಂಡ್

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

HAProxy ನೊಂದಿಗೆ ಉಳಿತಾಯ

ಪ್ರತಿ ಕ್ಲೈಂಟ್ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಿದ ಎರಡು ಸಂದರ್ಭಗಳ ಜೊತೆಗೆ, ಗುರುತಿನ ಸಂದರ್ಭವೂ ಇತ್ತು. ಐಡೆಂಟಿಟಿ ಸರ್ವರ್ 4 ಲಾಗ್ ಇನ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಇದು ಉಚಿತ ಮತ್ತು ಶಕ್ತಿಯುತ ಅನಲಾಗ್ ಆಗಿದೆ ADFS - ಸಕ್ರಿಯ ಡೈರೆಕ್ಟರಿ ಫೆಡರೇಶನ್ ಸೇವೆಗಳು.

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

ಎರಡನೇ ಹಂತ - ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ IdentityServer ನಲ್ಲಿ ದೃಢೀಕರಣ ಪುಟಕ್ಕೆ, ಅಲ್ಲಿ ಕ್ಲೈಂಟ್ ನೋಂದಾಯಿಸಲಾಗಿದೆ, ಮತ್ತು ಆ ಬಹುನಿರೀಕ್ಷಿತ ಟೋಕನ್ ಐಡೆಂಟಿಟಿ ಸರ್ವರ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು.

ಮೂರನೇ ಹಂತ - ಕ್ಲೈಂಟ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗಿದೆ ಬಂದ ಸಂದರ್ಭಕ್ಕೆ.

IdentityServer4 ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ: ಇದು HTTP ಮೂಲಕ ರಿಟರ್ನ್ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸಲು ನಾವು ಎಷ್ಟೇ ಹೆಣಗಾಡಿದ್ದರೂ, ದಾಖಲಾತಿಯೊಂದಿಗೆ ನಾವು ಎಷ್ಟೇ ಪ್ರಬುದ್ಧರಾಗಿದ್ದರೂ, ಪ್ರತಿ ಬಾರಿಯೂ ನಾವು HTTPS ಮೂಲಕ ಬಂದ URL ನೊಂದಿಗೆ ಆರಂಭಿಕ ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು IdentityServer ಅದೇ ಸಂದರ್ಭವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ, ಆದರೆ HTTP ಯೊಂದಿಗೆ. ನಮಗೆ ಆಘಾತವಾಯಿತು! ಮತ್ತು ನಾವು ಇದನ್ನೆಲ್ಲ ಗುರುತಿನ ಸಂದರ್ಭದ ಮೂಲಕ HAProxy ಗೆ ವರ್ಗಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಹೆಡರ್‌ಗಳಲ್ಲಿ ನಾವು HTTP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು HTTPS ಗೆ ಮಾರ್ಪಡಿಸಬೇಕಾಗಿತ್ತು.

ಸುಧಾರಣೆ ಏನು ಮತ್ತು ನೀವು ಎಲ್ಲಿ ಉಳಿಸಿದ್ದೀರಿ?

ನಾವು ಐಡೆಂಟಿಟಿ ಸರ್ವರ್ 4 ಅನ್ನು ಪ್ರತ್ಯೇಕ ವಿಭಾಗದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ನೋಡ್‌ನಂತೆ ಇರಿಸದ ಕಾರಣ, ಬಳಕೆದಾರರು, ಸಂಪನ್ಮೂಲಗಳ ಗುಂಪನ್ನು ಅಧಿಕೃತಗೊಳಿಸಲು ಉಚಿತ ಪರಿಹಾರವನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಹಣವನ್ನು ಉಳಿಸಿದ್ದೇವೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬ್ಯಾಕೆಂಡ್ ಚಲಿಸುವ ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಒಟ್ಟಿಗೆ ಬಳಸಿದ್ದೇವೆ. .

ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕು

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

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

ವಿತರಣಾ ವಿಧಾನ. ಮಾನದಂಡವು RPM ಆಗಿದೆ. ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ನೀವು ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಪ್ರತಿಯೊಬ್ಬರೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ, ಆದರೆ ಯೋಜನೆಯು ಸ್ವತಃ, ಅಸೆಂಬ್ಲಿ ನಂತರ, ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ DLL ಫೈಲ್‌ಗಳ ಗುಂಪಾಗಿದೆ. ಅವುಗಳಲ್ಲಿ ಸುಮಾರು 150 ಇದ್ದವು, ಯೋಜನೆಯು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿತ್ತು. ಈ ಬೈನರಿಯನ್ನು RPM ಗೆ ಪ್ಯಾಕೇಜ್ ಮಾಡುವುದು ಮತ್ತು ಅದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಮಾತ್ರ ಸಾಮರಸ್ಯದ ಪರಿಹಾರವಾಗಿದೆ.

ಆವೃತ್ತಿ. ನಾವು ಆಗಾಗ್ಗೆ ಬಿಡುಗಡೆ ಮಾಡಬೇಕಾಗಿತ್ತು ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಹೆಸರನ್ನು ಹೇಗೆ ರೂಪಿಸಬೇಕು ಎಂಬುದನ್ನು ನಾವು ನಿರ್ಧರಿಸಬೇಕಾಗಿತ್ತು. ಇದು TFS ನೊಂದಿಗೆ ಏಕೀಕರಣದ ಮಟ್ಟದ ಪ್ರಶ್ನೆಯಾಗಿದೆ. ನಾವು Linux ನಲ್ಲಿ ಬಿಲ್ಡ್ ಏಜೆಂಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. TFS ಒಂದು ಕಾರ್ಯವನ್ನು ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ - ವರ್ಕರ್‌ಗೆ - ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗೆ ಕಳುಹಿಸಿದಾಗ, ಅದು ಹ್ಯಾಂಡ್ಲರ್ ಪ್ರಕ್ರಿಯೆಯ ಪರಿಸರದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಅಸ್ಥಿರಗಳ ಗುಂಪನ್ನು ಸಹ ರವಾನಿಸುತ್ತದೆ. ಈ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳು ಬಿಲ್ಡ್ ಹೆಸರು, ಆವೃತ್ತಿಯ ಹೆಸರು ಮತ್ತು ಇತರ ಅಸ್ಥಿರಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. "ಆರ್‌ಪಿಎಂ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು" ವಿಭಾಗದಲ್ಲಿ ಇದರ ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಿ.

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

ಐಡೆಂಟಿಟಿ ಸರ್ವರ್. ADFS ನಮ್ಮ ಮಾರ್ಗವಲ್ಲ, ನಾವು ಓಪನ್ ಸೋರ್ಸ್‌ಗೆ ಹೋಗುತ್ತಿದ್ದೇವೆ.

ಘಟಕಗಳ ಮೂಲಕ ಹೋಗೋಣ.

ಮ್ಯಾಜಿಕ್ ಬಾಕ್ಸ್

ನಾಲ್ಕು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಲಿನಕ್ಸ್ ಬಿಲ್ಡ್ ಏಜೆಂಟ್. ಲಿನಕ್ಸ್, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ - ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ. ಈ ಭಾಗವನ್ನು ಮೂರು ಹಂತಗಳಲ್ಲಿ ಮಾಡಲಾಗಿದೆ.

• ಕೆಲಸಗಾರರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು ಏಕಾಂಗಿಯಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಯೋಜನೆಯಲ್ಲಿ ವಿತರಿಸಲಾದ ಕೆಲಸವನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ.
• .NET ಕೋರ್ 1.x ಅನ್ನು ಸ್ಥಾಪಿಸಿ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ 1 ಈಗಾಗಲೇ ಲಭ್ಯವಿರುವಾಗ 2.0.x ಏಕೆ? ಏಕೆಂದರೆ ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಸ್ಥಿರ ಆವೃತ್ತಿಯು 1.09 ಆಗಿತ್ತು ಮತ್ತು ಅದರ ಆಧಾರದ ಮೇಲೆ ಯೋಜನೆಯನ್ನು ಮಾಡಲು ನಿರ್ಧರಿಸಲಾಯಿತು.
• Git 2.x.

RPM-ರೆಪೊಸಿಟರಿ. RPM ಪ್ಯಾಕೇಜುಗಳನ್ನು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ. ಎಲ್ಲಾ Linux ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಲಭ್ಯವಿರುವ ಅದೇ ಕಾರ್ಪೊರೇಟ್ RPM ರೆಪೊಸಿಟರಿಯನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ ಎಂದು ಊಹಿಸಲಾಗಿದೆ. ಅವರು ಮಾಡಿದ್ದು ಅದನ್ನೇ. ರೆಪೊಸಿಟರಿ ಸರ್ವರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ವೆಬ್‌ಹುಕ್ ಇದು ಅಗತ್ಯವಿರುವ RPM ಪ್ಯಾಕೇಜ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸ್ಥಳದಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದೆ. ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಯನ್ನು ಬಿಲ್ಡ್ ಏಜೆಂಟ್ ಮೂಲಕ ವೆಬ್‌ಹೂಕ್‌ಗೆ ವರದಿ ಮಾಡಲಾಗಿದೆ.

ಗಿಟ್ಲ್ಯಾಬ್. ಗಮನ! ಇಲ್ಲಿ GitLab ಅನ್ನು ಡೆವಲಪರ್‌ಗಳು ಬಳಸುವುದಿಲ್ಲ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಆವೃತ್ತಿಗಳು, ಪ್ಯಾಕೇಜ್ ಆವೃತ್ತಿಗಳು, ಎಲ್ಲಾ ಲಿನಕ್ಸ್ ಯಂತ್ರಗಳ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಕಾರ್ಯಾಚರಣೆಗಳ ವಿಭಾಗವು ಬಳಸುತ್ತದೆ ಮತ್ತು ಇದು ಪಾಕವಿಧಾನವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ - ಎಲ್ಲಾ ಪಪಿಟ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳು.

ಬೊಂಬೆ - ಎಲ್ಲಾ ವಿವಾದಾತ್ಮಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು Gitlab ನಿಂದ ನಮಗೆ ಬೇಕಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿಖರವಾಗಿ ನೀಡುತ್ತದೆ.

ನಾವು ಧುಮುಕಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. RPM ಗೆ DLL ಡೆಲಿವರಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

DDL ಅನ್ನು RPM ಗೆ ತಲುಪಿಸಿ

ನಮ್ಮಲ್ಲಿ .NET ಡೆವಲಪ್‌ಮೆಂಟ್ ರಾಕ್‌ಸ್ಟಾರ್ ಇದೆ ಎಂದು ಹೇಳೋಣ. ಇದು ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋವನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಬಿಡುಗಡೆ ಶಾಖೆಯನ್ನು ರಚಿಸುತ್ತದೆ. ಅದರ ನಂತರ, ಅದು ಅದನ್ನು Git ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು Git ಇಲ್ಲಿ ಒಂದು TFS ಅಸ್ತಿತ್ವವಾಗಿದೆ, ಅಂದರೆ, ಇದು ಡೆವಲಪರ್ ಕೆಲಸ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ರೆಪೊಸಿಟರಿಯಾಗಿದೆ.

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

ಬಿಲ್ಡ್ ಏಜೆಂಟ್ ಮೂಲಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅಗತ್ಯವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಅವಲಂಬನೆಗಳು .NET ರೆಪೊಸಿಟರಿಯಿಂದ, npm, ಇತ್ಯಾದಿ. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ ಮತ್ತು ನಂತರದ ಪ್ಯಾಕೇಜಿಂಗ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ ನಂತರ, RPM ಪ್ಯಾಕೇಜ್ ಅನ್ನು RPM ರೆಪೊಸಿಟರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ.

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

ಎಲ್ಲವೂ ಪದಗಳಲ್ಲಿ ಸರಳವಾಗಿದೆ, ಆದರೆ ಬಿಲ್ಡ್ ಏಜೆಂಟ್ ಒಳಗೆ ಏನಾಗುತ್ತದೆ?

ಪ್ಯಾಕೇಜಿಂಗ್ DLL RPM

TFS ನಿಂದ ಪ್ರಾಜೆಕ್ಟ್ ಮೂಲಗಳು ಮತ್ತು ನಿರ್ಮಾಣ ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ. ಬಿಲ್ಡ್ ಏಜೆಂಟ್ ಮೂಲಗಳಿಂದ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಜೋಡಿಸಲಾದ ಯೋಜನೆಯು ಒಂದು ಸೆಟ್ ಆಗಿ ಲಭ್ಯವಿದೆ DLL ಫೈಲ್‌ಗಳು, ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಜಿಪ್ ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ.

ZIP ಆರ್ಕೈವ್ ಅನ್ನು ಎಸೆಯಲಾಗಿದೆ RPM ಪ್ಯಾಕೇಜ್ ಬಿಲ್ಡ್ ಡೈರೆಕ್ಟರಿಗೆ. ಮುಂದೆ, ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಬಿಲ್ಡ್ ಆವೃತ್ತಿ, ಪ್ರಾಜೆಕ್ಟ್ ಆವೃತ್ತಿ, ಬಿಲ್ಡ್ ಡೈರೆಕ್ಟರಿಯ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು RPM-ಬಿಲ್ಡ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ನಿರ್ಮಾಣ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ ಸ್ಥಳೀಯ ಭಂಡಾರ, ಇದು ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ನಲ್ಲಿದೆ.

ಮುಂದೆ, ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ನಿಂದ RPM ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸರ್ವರ್‌ಗೆ JSON ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ ಆವೃತ್ತಿ ಮತ್ತು ನಿರ್ಮಾಣದ ಹೆಸರನ್ನು ಸೂಚಿಸುತ್ತದೆ. ನಾನು ಮೊದಲೇ ಮಾತನಾಡಿದ ವೆಬ್‌ಹೂಕ್, ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ನಲ್ಲಿನ ಸ್ಥಳೀಯ ರೆಪೊಸಿಟರಿಯಿಂದ ಈ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹೊಸ ಜೋಡಣೆಯನ್ನು ಅನುಸ್ಥಾಪನೆಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ.

RPM ರೆಪೊಸಿಟರಿಗೆ ಈ ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೇಜ್ ವಿತರಣಾ ಯೋಜನೆ ಏಕೆ? ನಾನು ತಕ್ಷಣವೇ ಜೋಡಿಸಲಾದ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರೆಪೊಸಿಟರಿಗೆ ಏಕೆ ಕಳುಹಿಸಬಾರದು? ಸತ್ಯವೆಂದರೆ ಇದು ಸುರಕ್ಷತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಸ್ಥಿತಿಯಾಗಿದೆ. ಈ ಸನ್ನಿವೇಶವು ಎಲ್ಲಾ ಲಿನಕ್ಸ್ ಯಂತ್ರಗಳಿಗೆ ಪ್ರವೇಶಿಸಬಹುದಾದ ಸರ್ವರ್‌ಗೆ ಅನಧಿಕೃತ ಜನರು RPM ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಸಾಧ್ಯತೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

ಡೇಟಾಬೇಸ್ ಆವೃತ್ತಿ

ಅಭಿವೃದ್ಧಿ ತಂಡದೊಂದಿಗಿನ ಸಮಾಲೋಚನೆಯಲ್ಲಿ, ಹುಡುಗರು MS SQL ಗೆ ಹತ್ತಿರವಾಗಿದ್ದಾರೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ವಿಂಡೋಸ್ ಅಲ್ಲದ ಯೋಜನೆಗಳಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಅವರ ಎಲ್ಲಾ ಶಕ್ತಿಯೊಂದಿಗೆ PostgreSQL ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ. ಪಾವತಿಸಿದ ಎಲ್ಲವನ್ನೂ ತ್ಯಜಿಸಲು ನಾವು ಈಗಾಗಲೇ ನಿರ್ಧರಿಸಿದ್ದರಿಂದ, ನಾವು ಇಲ್ಲಿಯೂ PostgreSQL ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಈ ಭಾಗದಲ್ಲಿ ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೇಗೆ ಆವೃತ್ತಿ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಫ್ಲೈವೇ ಮತ್ತು ಎಂಟಿಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕೋರ್ ನಡುವೆ ನಾವು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಎಂದು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಅವರ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ನೋಡೋಣ.

ಮಿನುಸು

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

ಫ್ಲೈವೇ ನಮಗೆ ಕೆಲವು ರೀತಿಯ ಹೊದಿಕೆಯ ಅಗತ್ಯವಿದೆಆದ್ದರಿಂದ ಹುಡುಗರು ಬರೆಯುವುದಿಲ್ಲ SQL ಪ್ರಶ್ನೆಗಳು. ಅವರು OOP ನಿಯಮಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಹತ್ತಿರದಲ್ಲಿದ್ದಾರೆ. ಡೇಟಾಬೇಸ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಾವು ಸೂಚನೆಗಳನ್ನು ಬರೆದಿದ್ದೇವೆ, SQL ಪ್ರಶ್ನೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ. ಡೇಟಾಬೇಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿ ಸಿದ್ಧವಾಗಿದೆ, ಪರೀಕ್ಷಿಸಲಾಗಿದೆ - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

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

ಪ್ಲೂಸ್

ಎಂಟಿಟಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕೋರ್ ಬಾಕ್ಸ್ ಹೊರಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸುಲಭವಾಗಿದೆ, ಮತ್ತು ಫ್ಲೈವೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CI ಗೆ ಸುಲಭವಾಗಿ ಸಂಯೋಜಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ಅದನ್ನು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನುಕೂಲಕರವಾಗಿಸುತ್ತೇವೆ :)

ರೋಲ್-ಅಪ್ ಕಾರ್ಯವಿಧಾನ

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

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

TFS ಸಮಸ್ಯೆಗಳು

ಎಲ್ಲವೂ ನಿಜವಾಗಿಯೂ ನಮಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿ ಮತ್ತು ಅರಿತುಕೊಂಡ ನಂತರ, ಇತರ ಯೋಜನೆಗಳಲ್ಲಿ ವಿನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ವಿಭಾಗಕ್ಕೆ ಒಟ್ಟಾರೆಯಾಗಿ TFS ನಲ್ಲಿ ಅಸೆಂಬ್ಲಿಗಳೊಂದಿಗೆ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ - ನಾವು ತ್ವರಿತವಾಗಿ ನಿರ್ಮಿಸುತ್ತೇವೆ/ಬಿಡುಗಡೆ ಮಾಡುತ್ತಿದ್ದೇವೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ, ಮತ್ತು ವೇಗದಲ್ಲಿ ಗಮನಾರ್ಹ ಸಮಸ್ಯೆಗಳನ್ನು ಕಂಡುಹಿಡಿದಿದೆ.

ಮುಖ್ಯ ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಜೋಡಿಸಲು 12-15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಅದು ಬಹಳ ಸಮಯ, ನೀವು ಹಾಗೆ ಬದುಕಲು ಸಾಧ್ಯವಿಲ್ಲ. ತ್ವರಿತ ವಿಶ್ಲೇಷಣೆಯು I/O ನಲ್ಲಿ ಒಂದು ಭಯಾನಕ ಡ್ರಾಡೌನ್ ಅನ್ನು ತೋರಿಸಿದೆ ಮತ್ತು ಇದು ಸರಣಿಗಳಲ್ಲಿದೆ.

ಘಟಕದ ಮೂಲಕ ಘಟಕವನ್ನು ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ, ನಾನು ಮೂರು ಕೇಂದ್ರಗಳನ್ನು ಗುರುತಿಸಿದೆ. ಪ್ರಥಮ - "ಕ್ಯಾಸ್ಪರ್ಸ್ಕಿ ಆಂಟಿವೈರಸ್", ಇದು ಎಲ್ಲಾ ವಿಂಡೋಸ್ ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ ಮೂಲಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ. ಎರಡನೇ - ವಿಂಡೋಸ್ ಸೂಚ್ಯಂಕ. ಇದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ನೈಜ ಸಮಯದಲ್ಲಿ ಸೂಚಿಕೆ ಮಾಡಲಾಗಿದೆ.

ಮೂರನೇ - Npm ಸ್ಥಾಪನೆ. ಹೆಚ್ಚಿನ ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ನಾವು ಈ ನಿಖರವಾದ ಸನ್ನಿವೇಶವನ್ನು ಬಳಸಿದ್ದೇವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಅವನು ಯಾಕೆ ಕೆಟ್ಟವನು? ಅವಲಂಬನೆ ವೃಕ್ಷವು ರೂಪುಗೊಂಡಾಗ Npm ಅನುಸ್ಥಾಪನಾ ವಿಧಾನವನ್ನು ರನ್ ಮಾಡಲಾಗುತ್ತದೆ pack-lock.json, ಅಲ್ಲಿ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಲು ಬಳಸಲಾಗುವ ಪ್ಯಾಕೇಜುಗಳ ಆವೃತ್ತಿಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ತೊಂದರೆಯೆಂದರೆ Npm ಸ್ಥಾಪನೆಯು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯ ಪ್ಯಾಕೇಜುಗಳನ್ನು ಪ್ರತಿ ಬಾರಿ ಎಳೆಯುತ್ತದೆ ಮತ್ತು ಇದು ದೊಡ್ಡ ಯೋಜನೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

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

ನಿರ್ಧಾರವನ್ನು

• AV ವಿನಾಯಿತಿಗಳಲ್ಲಿ ಮೂಲಗಳು.
• ಇಂಡೆಕ್ಸಿಂಗ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ.
• ಗೆ ಹೋಗಿ npm ci.

npm ci ನ ಅನುಕೂಲಗಳು ನಾವು ನಾವು ಅವಲಂಬಿತ ಮರವನ್ನು ಒಮ್ಮೆ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಮತ್ತು ಡೆವಲಪರ್ ಅನ್ನು ಒದಗಿಸಲು ನಾವು ಅವಕಾಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ ಪ್ರಸ್ತುತ ಪ್ಯಾಕೇಜ್‌ಗಳ ಪಟ್ಟಿ, ಅದರೊಂದಿಗೆ ಅವರು ಸ್ಥಳೀಯವಾಗಿ ಅವರು ಇಷ್ಟಪಡುವಷ್ಟು ಪ್ರಯೋಗ ಮಾಡಬಹುದು. ಈ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತದೆ ಕೋಡ್ ಬರೆಯುವ ಅಭಿವರ್ಧಕರು.

ಸಂರಚನೆ

ಈಗ ರೆಪೊಸಿಟರಿ ಕಾನ್ಫಿಗರೇಶನ್ ಬಗ್ಗೆ ಸ್ವಲ್ಪ. ಐತಿಹಾಸಿಕವಾಗಿ ನಾವು ಬಳಸುತ್ತೇವೆ ನೆಕ್ಸಸ್ ಸೇರಿದಂತೆ ರೆಪೊಸಿಟರಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದಕ್ಕಾಗಿ ಆಂತರಿಕ REPO. ಈ ಆಂತರಿಕ ರೆಪೊಸಿಟರಿಯು ಆಂತರಿಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಬಳಸುವ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಉದಾಹರಣೆಗೆ, ಸ್ವಯಂ-ಲಿಖಿತ ಮೇಲ್ವಿಚಾರಣೆ.

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

ಪರಿಣಾಮವಾಗಿ

ನಾವು ಬಿಲ್ಡ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ನಂತರ, ಸರಾಸರಿ ನಿರ್ಮಾಣ ಸಮಯವನ್ನು 12 ನಿಮಿಷಗಳಿಂದ 7 ಕ್ಕೆ ಇಳಿಸಲಾಗಿದೆ.

ನಾವು ವಿಂಡೋಸ್‌ಗಾಗಿ ಬಳಸಬಹುದಾದ ಎಲ್ಲಾ ಯಂತ್ರಗಳನ್ನು ಎಣಿಸಿದರೆ, ಆದರೆ ಈ ಯೋಜನೆಯಲ್ಲಿ ಲಿನಕ್ಸ್‌ಗೆ ಬದಲಾಯಿಸಿದರೆ, ನಾವು ಸುಮಾರು $10 ಉಳಿಸಿದ್ದೇವೆ. ಮತ್ತು ಅದು ಕೇವಲ ಪರವಾನಗಿಗಳ ಮೇಲೆ ಮಾತ್ರ, ಮತ್ತು ನಾವು ವಿಷಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರೆ ಇನ್ನಷ್ಟು.

ಯೋಜನೆಗಳು

ಮುಂದಿನ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ, ಕೋಡ್ ವಿತರಣೆಯನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ನಾವು ಕೆಲಸ ಮಾಡಲು ಯೋಜಿಸಿದ್ದೇವೆ.

ಪ್ರಿಬಿಲ್ಡ್ ಡಾಕರ್ ಚಿತ್ರಕ್ಕೆ ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ. TFS ಅನೇಕ ಪ್ಲಗ್‌ಇನ್‌ಗಳೊಂದಿಗೆ ಉತ್ತಮ ವಿಷಯವಾಗಿದ್ದು ಅದು ಡಾಕರ್ ಚಿತ್ರದ ಪ್ರಚೋದಕ-ಆಧಾರಿತ ಜೋಡಣೆಯನ್ನು ಒಳಗೊಂಡಂತೆ ಪೈಪ್‌ಲೈನ್‌ಗೆ ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ನಾವು ಈ ಪ್ರಚೋದಕವನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ pack-lock.json. ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಲು ಬಳಸಿದ ಘಟಕಗಳ ಸಂಯೋಜನೆಯು ಹೇಗಾದರೂ ಬದಲಾದರೆ, ನಾವು ಹೊಸ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ನಂತರ ಜೋಡಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಕಂಟೇನರ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ಈಗ ಅಲ್ಲ, ಆದರೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಮೈಕ್ರೊ ಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಬದಲಾಯಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ, ಇದು ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ ಮತ್ತು ದೀರ್ಘಕಾಲದವರೆಗೆ ಉತ್ಪಾದನಾ ಪರಿಹಾರಗಳನ್ನು ನೀಡುತ್ತಿದೆ.

ಸಾರಾಂಶ

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

ಅಲೆಕ್ಸಾಂಡರ್ ಸಿಂಚಿನೋವ್ ಅವರ ಸ್ಪೀಕರ್ ಪ್ರೊಫೈಲ್ GitHub ನಲ್ಲಿ.

DevOps ಕಾನ್ಫರೆನ್ಸ್ ವೃತ್ತಿಪರರಿಂದ ವೃತ್ತಿಪರರಿಗೆ ಅಭಿವೃದ್ಧಿ, ಪರೀಕ್ಷೆ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಪ್ರಕ್ರಿಯೆಗಳ ಏಕೀಕರಣದ ಸಮಾವೇಶವಾಗಿದೆ. ಅದಕ್ಕಾಗಿಯೇ ಅಲೆಕ್ಸಾಂಡರ್ ಮಾತನಾಡಿದ ಯೋಜನೆ? ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಮತ್ತು ಪ್ರದರ್ಶನದ ದಿನದಂದು ಎರಡು ಯಶಸ್ವಿ ಬಿಡುಗಡೆಗಳು ಇದ್ದವು. ಆನ್ RIT++ ನಲ್ಲಿ DevOps ಕಾನ್ಫ್ ಮೇ 27 ಮತ್ತು 28 ರಂದು ವೈದ್ಯರಿಂದ ಇನ್ನೂ ಹೆಚ್ಚಿನ ರೀತಿಯ ಪ್ರಕರಣಗಳು ಕಂಡುಬರುತ್ತವೆ. ನೀವು ಇನ್ನೂ ಕೊನೆಯ ಗಾಡಿಗೆ ಜಿಗಿಯಬಹುದು ಮತ್ತು ವರದಿ ಸಲ್ಲಿಸು ಅಥವಾ ನಿಮ್ಮ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ ಬುಕ್ ಮಾಡಲು ಟಿಕೆಟ್. ಸ್ಕೋಲ್ಕೊವೊದಲ್ಲಿ ನಮ್ಮನ್ನು ಭೇಟಿ ಮಾಡಿ!

ಮೂಲ: www.habr.com