ಇದು ಭಾಷಣದ ಪ್ರತಿಲಿಪಿಯಾಗಿದೆ и .
ಇದು ಸ್ವಯಂ-ಬರೆದ ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿದ ಯೋಜನೆಯ ಕಥೆಯಾಗಿದೆ ಮತ್ತು ಏಕೆ ಅನ್ಸಿಬಲ್‌ಗೆ ತೆರಳಲು 18 ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು.
ದಿನ ಸಂಖ್ಯೆ -ХХХ: ಆರಂಭದ ಮೊದಲು
ಆರಂಭದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯವು ಹೈಪರ್-ವಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅನೇಕ ಪ್ರತ್ಯೇಕ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು. ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸಲು ಹಲವು ಹಂತಗಳು ಬೇಕಾಗುತ್ತವೆ: ಡಿಸ್ಕ್ಗಳನ್ನು ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸುವುದು, DNS ಅನ್ನು ನೋಂದಾಯಿಸುವುದು, DHCP ಅನ್ನು ಕಾಯ್ದಿರಿಸುವುದು, Git ರೆಪೊಸಿಟರಿಯಲ್ಲಿ VM ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹಾಕುವುದು. ಈ ಪ್ರಕ್ರಿಯೆಯು ಭಾಗಶಃ ಯಾಂತ್ರೀಕೃತಗೊಂಡಿದೆ, ಆದರೆ ಉದಾಹರಣೆಗೆ, VM ಗಳನ್ನು ಹೋಸ್ಟ್‌ಗಳ ನಡುವೆ ಕೈಯಿಂದ ವಿತರಿಸಲಾಯಿತು. ಆದರೆ, ಉದಾಹರಣೆಗೆ, ಡೆವಲಪರ್‌ಗಳು Git ನಲ್ಲಿ VM ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು VM ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುವ ಮೂಲಕ ಅದನ್ನು ಅನ್ವಯಿಸಬಹುದು.
ಕಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಪರಿಹಾರ
ಮೂಲ ಕಲ್ಪನೆಯನ್ನು IaC ಎಂದು ಕಲ್ಪಿಸಲಾಗಿದೆ: ರೀಬೂಟ್ ಮಾಡಿದಾಗ ತಮ್ಮ ಸ್ಥಿತಿಯನ್ನು ಶೂನ್ಯಕ್ಕೆ ಮರುಹೊಂದಿಸುವ ಅನೇಕ ಸ್ಥಿತಿಯಿಲ್ಲದ VM ಗಳು. VM ಕಾನ್ಫಿಗರೇಶನ್ ನಿರ್ವಹಣೆ ಎಂದರೇನು? ಕ್ರಮಬದ್ಧವಾಗಿ ಇದು ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ:
- VM ಗಾಗಿ ಸ್ಥಿರ MAC ಅನ್ನು ಹೊಡೆಯಲಾಯಿತು.
- CoreOS ನೊಂದಿಗೆ ISO ಮತ್ತು ಬೂಟ್ ಡಿಸ್ಕ್ ಅನ್ನು VM ಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ.
- CoreOS ಅದರ IP ಅನ್ನು ಆಧರಿಸಿ WEB ಸರ್ವರ್‌ನಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ ಗ್ರಾಹಕೀಕರಣ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
- IP ವಿಳಾಸವನ್ನು ಆಧರಿಸಿ SCP ಮೂಲಕ VM ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ.
- systemd ಯುನಿಟ್ ಫೈಲ್‌ಗಳ ಫುಟ್‌ಕ್ಲಾತ್ ಮತ್ತು ಬ್ಯಾಷ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಫುಟ್‌ಕ್ಲಾತ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ.
ಈ ಪರಿಹಾರವು ಅನೇಕ ಸ್ಪಷ್ಟ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ:
- CoreOS ISO ಅನ್ನು ಅಸಮ್ಮತಿಸಲಾಗಿದೆ.
- VM ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವಾಗ/ರಚಿಸುವಾಗ ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾದ ಸ್ವಯಂಚಾಲಿತ ಕ್ರಿಯೆಗಳು ಮತ್ತು ಮ್ಯಾಜಿಕ್.
- ಅಪ್‌ಡೇಟ್ ಮಾಡುವಲ್ಲಿ ತೊಂದರೆ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯ ಅಗತ್ಯವಿರುವಾಗ. ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ಗಳೊಂದಿಗೆ ಇನ್ನಷ್ಟು ಮೋಜು.
- ಡೇಟಾ ಇಲ್ಲದೆ VM ಗಳನ್ನು ಪಡೆಯಲಾಗಿಲ್ಲ, ಅಂದರೆ. ಹೆಚ್ಚುವರಿ ಬಳಕೆದಾರ ಡೇಟಾವನ್ನು ಅಳವಡಿಸಿರುವ ಡಿಸ್ಕ್‌ನೊಂದಿಗೆ VM ಗಳು ಕಾಣಿಸಿಕೊಂಡವು.
- ಯಾರೋ ನಿರಂತರವಾಗಿ systemd ಯುನಿಟ್ ಅವಲಂಬನೆಗಳನ್ನು ತಿರುಗಿಸುತ್ತಿದ್ದರು ಮತ್ತು ರೀಬೂಟ್ ಮಾಡುವಾಗ CoreOS ಫ್ರೀಜ್ ಆಗುತ್ತದೆ. CoreOS ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಉಪಕರಣಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಹಿಡಿಯುವುದು ಕಷ್ಟಕರವಾಗಿತ್ತು.
- ರಹಸ್ಯ ನಿರ್ವಹಣೆ.
- ಸಿಎಂ ಇರಲಿಲ್ಲ. CoreOS ಗಾಗಿ ಬ್ಯಾಷ್ ಮತ್ತು YML ಸಂರಚನೆಗಳು ಇದ್ದವು.
VM ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅನ್ವಯಿಸಲು, ನೀವು ಅದನ್ನು ರೀಬೂಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಅದು ರೀಬೂಟ್ ಆಗದೇ ಇರಬಹುದು. ಇದು ಸ್ಪಷ್ಟವಾದ ಸಮಸ್ಯೆಯಂತೆ ತೋರುತ್ತದೆ, ಆದರೆ ಯಾವುದೇ ನಿರಂತರ ಡಿಸ್ಕ್ಗಳಿಲ್ಲ - ಲಾಗ್ಗಳನ್ನು ಉಳಿಸಲು ಎಲ್ಲಿಯೂ ಇಲ್ಲ. ಸರಿ, ಸರಿ, ಲಾಗ್ಗಳನ್ನು ಕಳುಹಿಸಲು ಕರ್ನಲ್ ಲೋಡಿಂಗ್ ಆಯ್ಕೆಯನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ. ಆದರೆ ಇಲ್ಲ, ಎಲ್ಲವೂ ಎಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ದಿನ #0: ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಿ
ಇದು ಸಾಮಾನ್ಯ ಅಭಿವೃದ್ಧಿ ಮೂಲಸೌಕರ್ಯವಾಗಿತ್ತು: ಜೆಂಕಿನ್ಸ್, ಪರೀಕ್ಷಾ ಪರಿಸರಗಳು, ಮೇಲ್ವಿಚಾರಣೆ, ನೋಂದಾವಣೆ. K8s ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು CoreOS ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಅಂದರೆ. CoreOS ಅನ್ನು ಹೇಗೆ ಬಳಸಲಾಗಿದೆ ಎಂಬುದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಮೊದಲ ಹಂತವು ಸ್ಟಾಕ್ ಅನ್ನು ಆರಿಸುವುದು. ನಾವು ನೆಲೆಸಿದ್ದೇವೆ:
- CentOS ಮೂಲ ವಿತರಣೆಯಾಗಿ, ಏಕೆಂದರೆ ಇದು ಉತ್ಪಾದನಾ ಪರಿಸರಕ್ಕೆ ಹತ್ತಿರದ ವಿತರಣೆಯಾಗಿದೆ.
- ಅನುಕಂಪ ಸಂರಚನಾ ನಿರ್ವಹಣೆಗಾಗಿ, ಏಕೆಂದರೆ ಅದರ ಮೇಲೆ ವ್ಯಾಪಕವಾದ ಪರೀಕ್ಷೆ ನಡೆಯಿತು.
- ಜೆಂಕಿನ್ಸ್ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಚೌಕಟ್ಟಾಗಿ, ಏಕೆಂದರೆ ಇದನ್ನು ಈಗಾಗಲೇ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲಾಗಿದೆ
- ಹೈಪರ್-ವಿ ವರ್ಚುವಲೈಸೇಶನ್ ವೇದಿಕೆಯಾಗಿ. ಕಥೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿ ಹಲವಾರು ಕಾರಣಗಳಿವೆ, ಆದರೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ - ನಾವು ಮೋಡಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ನಾವು ನಮ್ಮ ಸ್ವಂತ ಯಂತ್ರಾಂಶವನ್ನು ಬಳಸಬೇಕು.
ದಿನ ಸಂಖ್ಯೆ 30: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಪ್ಪಂದಗಳನ್ನು ಸರಿಪಡಿಸುವುದು - ಒಪ್ಪಂದಗಳು ಕೋಡ್ ಆಗಿ
ಸ್ಟಾಕ್ ಸ್ಪಷ್ಟವಾದಾಗ, ಚಲನೆಗೆ ಸಿದ್ಧತೆಗಳು ಪ್ರಾರಂಭವಾದವು. ಕೋಡ್ ರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಪ್ಪಂದಗಳನ್ನು ಸರಿಪಡಿಸುವುದು (ಕೋಡ್ ಆಗಿ ಒಪ್ಪಂದಗಳು!). ಪರಿವರ್ತನೆ ಕೈಯಿಂದ ಕೆಲಸ -> ಯಾಂತ್ರೀಕರಣ -> ಯಾಂತ್ರೀಕೃತಗೊಂಡ.
1. VM ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ
ಅನ್ಸಿಬಲ್ ಇದರಲ್ಲಿ ಉತ್ತಮ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಕನಿಷ್ಠ ದೇಹದ ಚಲನೆಗಳೊಂದಿಗೆ ನೀವು VM ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ನಿಯಂತ್ರಣವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು:
- ಜಿಟ್ ರೆಪೊಸಿಟರಿಯನ್ನು ರಚಿಸಿ.
- ನಾವು VM ಗಳ ಪಟ್ಟಿಯನ್ನು ದಾಸ್ತಾನು, ಪ್ಲೇಬುಕ್‌ಗಳು ಮತ್ತು ಪಾತ್ರಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ ಇರಿಸಿದ್ದೇವೆ.
- ನಾವು ವಿಶೇಷ ಜೆಂಕಿನ್ಸ್ ಸ್ಲೇವ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತಿದ್ದೇವೆ ಇದರಿಂದ ನೀವು ಅನ್ಸಿಬಲ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು.
- ನಾವು ಕೆಲಸವನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ.
ಮೊದಲ ಪ್ರಕ್ರಿಯೆ ಸಿದ್ಧವಾಗಿದೆ. ಒಪ್ಪಂದಗಳು ಸ್ಥಿರವಾಗಿವೆ.
2. ಹೊಸ VM ಅನ್ನು ರಚಿಸಿ
ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿರಲಿಲ್ಲ. Linux ನಿಂದ Hyper-V ನಲ್ಲಿ VM ಗಳನ್ನು ರಚಿಸಲು ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಯಾಂತ್ರಿಕಗೊಳಿಸುವ ಪ್ರಯತ್ನಗಳಲ್ಲಿ ಒಂದು:
- Ansbile WinRM ಮೂಲಕ ವಿಂಡೋಸ್ ಹೋಸ್ಟ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ.
- Ansible ಪವರ್‌ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ.
- ಪವರ್‌ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಹೊಸ VM ಅನ್ನು ರಚಿಸುತ್ತದೆ.
- Hyper-V/ScVMM ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಅತಿಥಿ OS ನಲ್ಲಿ VM ಅನ್ನು ರಚಿಸುವಾಗ, ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.
- DHCP ಗುತ್ತಿಗೆಯನ್ನು ನವೀಕರಿಸುವಾಗ, VM ತನ್ನ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
- ಡೊಮೈನ್ ಕಂಟ್ರೋಲರ್ ಬದಿಯಲ್ಲಿ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ddns & dhcp ಏಕೀಕರಣವು DNS ದಾಖಲೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ.
- ನಿಮ್ಮ ದಾಸ್ತಾನುಗಳಿಗೆ ನೀವು VM ಅನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಅದನ್ನು ಅನ್ಸಿಬಲ್‌ನೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
3.ವಿಎಂ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ರಚಿಸಿ
ಅವರು ಇಲ್ಲಿ ಏನನ್ನೂ ಆವಿಷ್ಕರಿಸಲಿಲ್ಲ - ಅವರು ಪ್ಯಾಕರ್ ತೆಗೆದುಕೊಂಡರು.
- ಪ್ಯಾಕರ್, ಕಿಕ್‌ಸ್ಟಾರ್ಟ್ ಸಂರಚನೆಯನ್ನು git ರೆಪೊಸಿಟರಿಗೆ ಸೇರಿಸಿ.
- ಹೈಪರ್-ವಿ ಮತ್ತು ಪ್ಯಾಕರ್‌ನೊಂದಿಗೆ ವಿಶೇಷ ಜೆಂಕಿನ್ಸ್ ಸ್ಲೇವ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ.
- ನಾವು ಕೆಲಸವನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ಜೆಂಕಿನ್ಸ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ.
ಈ ಲಿಂಕ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
- ಪ್ಯಾಕರ್ ಖಾಲಿ VM ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ISO ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
- VM ಬೂಟ್ ಆಗುತ್ತದೆ, ಫ್ಲಾಪಿ ಡಿಸ್ಕ್ ಅಥವಾ http ನಿಂದ ನಮ್ಮ ಕಿಕ್‌ಸ್ಟಾರ್ಟ್ ಫೈಲ್ ಅನ್ನು ಬಳಸಲು ಪ್ಯಾಕರ್ ಆಜ್ಞೆಯನ್ನು ಬೂಟ್‌ಲೋಡರ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ.
- Anaconda ಅನ್ನು ನಮ್ಮ ಸಂರಚನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಮತ್ತು ಆರಂಭಿಕ OS ಸಂರಚನೆಯನ್ನು ಮಾಡಲಾಗಿದೆ.
- VM ಲಭ್ಯವಾಗಲು ಪ್ಯಾಕರ್ ಕಾಯುತ್ತಾನೆ.
- VM ಒಳಗಿನ ಪ್ಯಾಕರ್ ಸ್ಥಳೀಯ ಕ್ರಮದಲ್ಲಿ ಅನ್ಸಿಬಲ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ.
- ಹಂತ #1 ರಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅದೇ ಪಾತ್ರಗಳನ್ನು ಅನ್ಸಿಬಲ್ ಬಳಸುತ್ತದೆ.
- ಪ್ಯಾಕರ್ VM ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ರಫ್ತು ಮಾಡುತ್ತದೆ.
ದಿನ #75: ಒಪ್ಪಂದವನ್ನು ಮುರಿಯದೆ ಮರುಫಲಕ ಮಾಡಿ = ಟೆಸ್ಟ್ ಅನ್ಸಿಬಲ್ + ಟೆಸ್ಟ್ಕಿಚನ್
ಕೋಡ್‌ನಲ್ಲಿ ಸಂಪ್ರದಾಯಗಳನ್ನು ಸೆರೆಹಿಡಿಯುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ. ಎಲ್ಲಾ ನಂತರ, ಪ್ರಕ್ರಿಯೆಯ ಒಳಹರಿವುಗಳಲ್ಲಿ ನೀವು ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಏನನ್ನಾದರೂ ಮುರಿಯಬಹುದು. ಆದ್ದರಿಂದ, ಮೂಲಸೌಕರ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಮೂಲಭೂತ ಸೌಕರ್ಯದ ಪರೀಕ್ಷೆಯು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ತಂಡದೊಳಗೆ ಜ್ಞಾನವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು, ನಾವು ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾನು ಆಳಕ್ಕೆ ಹೋಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ... ಆ ಸಮಯದಲ್ಲಿ ನಡೆದ ಘಟನೆಗಳನ್ನು ವಿವರಿಸುವ ಲೇಖನವಿದೆ (ಸ್ಪಾಯ್ಲರ್ ಇದು ಅಂತಿಮ ಆವೃತ್ತಿಯಾಗಿರಲಿಲ್ಲ ಮತ್ತು ನಂತರ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಯಿತು ).
ದಿನ #130: ಬಹುಶಃ CentOS+ansible ಅಗತ್ಯವಿಲ್ಲವೇ? ಬಹುಶಃ ಓಪನ್ ಶಿಫ್ಟ್?
ಮೂಲಸೌಕರ್ಯವನ್ನು ಪರಿಚಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಒಂದೇ ಅಲ್ಲ ಮತ್ತು ಅಡ್ಡ ಉಪಯೋಜನೆಗಳು ಇದ್ದವು ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಓಪನ್‌ಶಿಫ್ಟ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲು ವಿನಂತಿಯು ಬಂದಿತು ಮತ್ತು ಇದು ಒಂದು ವಾರಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲ ಸಂಶೋಧನೆಗೆ ಕಾರಣವಾಯಿತು ಇದು ಚಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸಿತು. ಓಪನ್‌ಶಿಫ್ಟ್ ಎಲ್ಲಾ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಎಂದು ಫಲಿತಾಂಶವು ಬದಲಾಯಿತು; ನಿಮಗೆ ನಿಜವಾದ ಹಾರ್ಡ್‌ವೇರ್ ಅಗತ್ಯವಿದೆ, ಅಥವಾ ಕನಿಷ್ಠ ಕರ್ನಲ್‌ನೊಂದಿಗೆ ಪ್ಲೇ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ.
ದಿನ #170: ಓಪನ್‌ಶಿಫ್ಟ್ ಸೂಕ್ತವಲ್ಲ, ವಿಂಡೋಸ್ ಅಜೂರ್ ಪ್ಯಾಕ್‌ನೊಂದಿಗೆ ಅವಕಾಶವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣವೇ?
ಹೈಪರ್-ವಿ ಹೆಚ್ಚು ಸ್ನೇಹಪರವಾಗಿಲ್ಲ, SCVMM ಅದನ್ನು ಹೆಚ್ಚು ಉತ್ತಮಗೊಳಿಸುವುದಿಲ್ಲ. ಆದರೆ ವಿಂಡೋಸ್ ಅಜೂರ್ ಪ್ಯಾಕ್‌ನಂತಹ ವಿಷಯವಿದೆ, ಇದು SCVMM ಗೆ ಆಡ್-ಆನ್ ಆಗಿದೆ ಮತ್ತು ಅಜೂರ್ ಅನ್ನು ಅನುಕರಿಸುತ್ತದೆ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, ಉತ್ಪನ್ನವು ಕೈಬಿಟ್ಟಂತೆ ಕಾಣುತ್ತದೆ: ದಸ್ತಾವೇಜನ್ನು ಮುರಿದ ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ತುಂಬಾ ವಿರಳವಾಗಿದೆ. ಆದರೆ ನಮ್ಮ ಮೋಡದ ಜೀವನವನ್ನು ಸರಳಗೊಳಿಸುವ ಆಯ್ಕೆಗಳ ಅಧ್ಯಯನದ ಭಾಗವಾಗಿ, ಅವರು ಅದನ್ನು ನೋಡಿದರು.
ದಿನ #250: Windows Azure Pack ತುಂಬಾ ಚೆನ್ನಾಗಿಲ್ಲ. ನಾವು SCVMM ನಲ್ಲಿಯೇ ಇರುತ್ತೇವೆ
Windows Azure Pack ಭರವಸೆಯಂತೆ ಕಂಡಿತು, ಆದರೆ ಅನಗತ್ಯ ವೈಶಿಷ್ಟ್ಯಗಳ ಸಲುವಾಗಿ WAP ಅನ್ನು ಅದರ ಸಂಕೀರ್ಣತೆಗಳೊಂದಿಗೆ ಸಿಸ್ಟಮ್‌ಗೆ ತರದಿರಲು ನಿರ್ಧರಿಸಲಾಯಿತು ಮತ್ತು SCVMM ನಲ್ಲಿ ಉಳಿಯಿತು.
ದಿನ #360: ಆನೆಯನ್ನು ತುಂಡಾಗಿ ತಿನ್ನುವುದು
ಕೇವಲ ಒಂದು ವರ್ಷದ ನಂತರ ಸ್ಥಳಾಂತರಗೊಳ್ಳಲು ವೇದಿಕೆ ಸಿದ್ಧವಾಯಿತು ಮತ್ತು ಚಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರಾರಂಭವಾಯಿತು. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, SMART ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ. ನಾವು ಎಲ್ಲಾ VM ಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಒಂದೊಂದಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಅದನ್ನು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ವಿವರಿಸಿ ಮತ್ತು ಅದನ್ನು ಪರೀಕ್ಷೆಗಳೊಂದಿಗೆ ಕವರ್ ಮಾಡಿ.
ದಿನ #450: ನೀವು ಯಾವ ರೀತಿಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೀರಿ?
ಪ್ರಕ್ರಿಯೆಯು ಸ್ವತಃ ಆಸಕ್ತಿದಾಯಕವಲ್ಲ. ಇದು ವಾಡಿಕೆಯಾಗಿದೆ, ಹೆಚ್ಚಿನ ಸಂರಚನೆಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳ ಅಥವಾ ಐಸೊಮಾರ್ಫಿಕ್ ಎಂದು ಗಮನಿಸಬಹುದು ಮತ್ತು ಪ್ಯಾರೆಟೊ ತತ್ವದ ಪ್ರಕಾರ, 80% ವಿಎಂ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗೆ 20% ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಅದೇ ತತ್ತ್ವದ ಮೂಲಕ, 80% ಸಮಯವನ್ನು ನಡೆಸುವಿಕೆಯನ್ನು ತಯಾರಿಸಲು ಖರ್ಚುಮಾಡಲಾಯಿತು ಮತ್ತು ಕೇವಲ 20% ಚಲನೆಯಲ್ಲಿಯೇ.
ದಿನ #540: ಅಂತಿಮ
18 ತಿಂಗಳಲ್ಲಿ ಏನಾಯಿತು?
- ಒಪ್ಪಂದಗಳು ಕೋಡ್ ಆದವು.
- ಹಸ್ತಚಾಲಿತ ಕೆಲಸ -> ಯಾಂತ್ರೀಕರಣ -> ಆಟೊಮೇಷನ್.
ಲಿಂಕ್ಸ್
ಮೂಲ: www.habr.com